J’aimerais présenter ici une idée qui me trotte dans la tête, et évaluer avec vous sa faisabilité et sa pertinence, ainsi qu’examiner les solutions existantes qui pourraient faciliter son implémentation. L’idée à terme serait d’avoir une application Yunohost permettant à un groupe d’administrateurs de serveurs de mutualiser leurs moyens, et d’être solidaires mutuellement.
Le principe CHATONS me séduit depuis toujours, et je pense qu’il devrait être possible, même en auto-hébergement, de participer à la décentralisation d’Internet, au moins de manière locale.
Si l’on vise un public de quelques centaines de personnes, un seul serveur type Olinuxino-Lime2 peut difficilement offrir un bouquet de services fiables, performants et suffisamment disponibles. Plusieurs serveurs reliés entre eux (plus ou moins spécialisés dans un type de services) peuvent en revanche faire l’affaire, surtout si l’on imagine une solution pour répartir la charge en cas de panne sur l’un des membres de ce “CHATONS collaboratif”.
L’idée est donc d’imaginer un système qui vérifie régulièrement la présence en ligne des autres serveurs, et qui mutualise les sauvegardes de chacun chez tous les membres du réseau. Les sauvegardes ne devraient être synchronisées que lorsque c’est pertinent (mise à jour du contenu ou de l’application).
Si l’un des membres du réseau disparaît temporairement (coupure de courant, d’Internet, problème de disque dur ou bug quelconque), un des autres membres du réseau pourrait (de façon automatiser grâce à un cronjob) restaurer automatiquement les applications de ce serveur absent, pour en prendre le relais. En plus des services hébergés par ce même serveur.
Pour que ce système fonctionne efficacement, il faut en définir les limites :
Entre 4 et 6 serveurs auto-hébergés maximum
Chaque serveur est géré localement par une personne compétente
Les applications à sauvegarder et à restaurer doivent être d’une taille et d’une charge raisonnables
L’usage doit rester également raisonnable : l’idée est de rester à taille humaine et d’informer le public visé que tout est plus ou moins artisanal et sans garantie.
Les principes que je souhaite voir respectés par ce système :
Distribution (autrement dit : pas de dépendance à un serveur central)
Solidarité (on assure les mêmes aides que celles qu’on est en droit de recevoir)
Équité : si plusieurs serveurs tombent en panne, cela ne doit pas être le même qui prend le relai de tous les autres.
Confiance : pour faciliter la gestion, il faut que les membres du réseau aient totalement confiance entre eux, car des données personnelles ou cruciales seront partagées entre tous et chacun doit en faire bon usage.
my 2 cents sur le sujet : on a déjà évoqué ce genre d’idée dans YunoHost sur le long terme, c’est discuté ici : nlnet old6 Milestone · GitHub
En gros l’idée serait comme tu proposes de permettre à des serveurs de s’échanger des services : monitoring que le serveur est up, mise à disposition d’espace de backup, outil de diagnostique (pour décentraliser ip.yunohost.org et autre), etc…
Pour le moment ça reste au stade d’idée / design, par manque de temps pour se pencher dessus face à tous les autres sujets en cours.
Par contre dans ce qu’on a évoqué jusqu’ici, ça reste des serveurs “indépendants” qui s’échangent juste des services de maintenance. Les applications et données ne sont pas liées entre les serveurs … Faire des applications distribuées entre plusieurs machines physiques, ça pose des problématiques qui sont d’un autre ordre de grandeur en terme de complexité technique (e.g. comment assurer que les données sont bien synchronisées entre les DB), et surtout de sécurité (comment s’assurer qu’un des admins des serveurs n’est pas malveillant pour espionner/compromettre/manipuler les données).
Mais quel intérêt pour un serveur ami de diagnostiquer un autre ? Si on peut le diagnostiquer, c’est bien qu’il est toujours accessible, n’est-ce pas ? Ou bien, c’est juste le cas où le serveur reste accessible et fonctionnel, mais qu’une des applications en particulier bug. Je n’ai pas prévu ce cas de figure.
Mon idée n’est pas tant de connecter des machines entre elles via l’API, mais d’opérer plutôt par transferts ponctuels de données (signés par GPG éventuellement, pour garantir l’authenticité). Ces données ne seraient “ouvertes” par les destinataires qu’au moment de la prise de relais, si l’expéditeur de ces données devient indisponible.
J’avais également pensé à un système comme SyncThing pour s’assurer de l’intégrité des fichiers synchronisés.
Dans un premier temps, l’idée sera surtout de s’échanger des sauvegardes, et la partie relais (restauration par un des serveurs des sauvegardes et des domaines d’un autre) pourrait se faire manuellement. Si on constate que le système fonctionne, mais manque de réactivité, alors l’automatisation deviendra nécessaire et demandera un peu plus de développement.
Est-ce que sur le principe, l’idée te semble faisable ?
Ma réponse à ce point est également évoquée dans le lien que tu m’as fourni : “allow servers (that trust each other, so typically between friends) to connect”. Il faut que chaque membre du réseau ait complètement confiance dans les autres (et, pour le temps de l’expérimentation, il ne faut pas partager de données trop sensibles ou importantes).
Autre approche, en visant des apps web sans base de données, il serait possible de partager un espace de stockage répliqué sur lequel se trouve les fichiers de l’app. Dans l’absolu je pense qu’un dokuwiki ou un grav avec syncthing pourrait fonctionner, mais y a d’autres technos faites pour partager un file system. A l’époque il y avait des vues sur tahoelafs dans yunohost.
Pour ce qui est de diagnostiquer, actuellement les instance yunohost font appels à l’infra yunohost pour diagnostiquer des problèmes de port forwarding notamment. ET oui un serveur peut être up alors qu’un des services est down.
Techniquement, borg pourrait faire ça en fait. Il serait même théoriquement possible de monter temporairement une sauvegarde avec borg mount. Mais ce genre de mécanisme implique aussi de savoir rapatrier les nouvelles données vers le serveur d’origine une fois qu’il est de nouveau up, etc. En vrai, la problématique est loin d’être simple car il faut aussi mettre à jour les DNS automatiquement, il y a la question de la répartition des backups entre le cluster, les temps de transmissions de sauvegardes, les ressources pour faire la différence/déduplication…
Le sujet est à creuser, et il y a probablement des technos qui pourrait aider à réaliser ça. Mais bon AMHA, y a beaucoup à chercher.
L’app fallback_ynh est ce qu’on a de plus proche de ce que tu décris.
Par diagnostiquer, je parle du fait que le système de diagnostique de Yunohost a besoin de discuter avec une machine externe, par exemple pour connaitre son IP globale, ou bien pour vérifier si les ports sont bien exposés sur l’internet global - et pour ça il n’y a pas trop d’autre manière que de demander à une machine “externe”.
Sauf que du coup actuellement toutes les instances yunohost utilisent des petits services hébergés sur yunohost.org, ce qui créé un point central qui pose donc des soucis lorsqu’occasionellement notre infra est dans les choux (et puis c’est pas ouf pour les questions de vie privée etc, on pourrait théoriquement indexer les instances yunohost dans la nature).
N’y a t-il pas également un problème d’ordre légale dans la mutualisation des données elles-mêmes : par exemple si l’un des utilisateurs y stocke des données passibles de sanctions légales ?
Autant sur le papier l’idée “technique” me paraît intéressante, autant sa mise en œuvre et les précautions et avertissements associés sont assez bloquants me semble-t-il.
Peut-être faudrait-il se renseigner sur les responsabilités associées à ce mode de fonctionnement en cas de problèmes/dérives/détournements.
@ljf Merci pour tes apports techniques. Oui, c’est justement fallback_ynh qui m’a inspiré, je trouvais dommage qu’il faille un serveur dédié à la sauvegarde, plutôt que plusieurs serveurs fonctionnels qui s’assurent entre eux sans perdre de leur fonctionnalité.
C’est sûr, à première vue il y a du boulot, mais c’est un projet qui me motive et je pense qu’il peut porter ses fruits ! Sauf si on découvre un obstacle insolvable auquel cas je chercherai des compromis…
@Sango et si on crée une entité (genre association, comme la plupart des CHATONS) qui chapeaute le réseau ? Dans ce cas, les différents serveurs auto-hébergés sont comme les machines d’une même société, et la responsabilité est partagée entre les membres ?
Si les membres de ce réseau sont réellement “amis” et motivés par ce système, je pense que ce n’est pas un obstacle à sa réalisation. Et, évidemment, une charte permettrait de dé-responsabiliser les gestionnaires des serveurs des éventuels abus de la part des utilisateurs… Je pense que ce genre de choses existe déjà pour n’importe quel serveur qui offre des services mutualisés.
Merci @Aleks pour tes explications, c’est beaucoup plus clair et ça ajoute de la profondeur à ma réflexion. Je pense qu’une partie de ce qu’on a évoqué pourrait être mergé dans Yunohost en lui même (le choix des serveurs amis pour le diagnostique, les sauvegardes, la maintenance) et que le reste (pointage de DNS, restauration des applications par un autre serveur, etc.) devra être une application à part entière, à laquelle s’associera la création d’un collectif avec des statuts et une charte qui en définissent les règles.