Install Party "Garage" : stockez vos données collectivement

Tech Infrastructure
1

Bonjour,

02b56acc60d793ee0d794e48704b3845

Présentation de Deuxfleurs

Je suis membre d’une association qui s’appelle Deuxfleurs dans laquelle nous voulons faire de l’auto-hébergement collectivement. Dans notre idée, plutôt que d’avoir chacun son YunoHost de son côté, on veut plutôt mettre nos machines et nos logiciels en commun. Ça nous permet de prendre soin collectivement de notre petit coin d’internet que j’appellerai notre grappe (ou cluster pour le terme anglais).

garage

Présentation de Garage

La première étape c’est de répartir les données sur toutes les machines de notre grappe. Et aussi, de les dupliquer, comme ça si une machine vient à être indisponible, la donnée continue d’être disponible et le service n’est pas impacté. Plusieurs logiciels existent déjà pour faire ça, les plus populaires sont Ceph, Openstack Swift et Minio. Mais ces logiciels posent un problème : ce sont des logiciels qui requièrent une infrastructure physique (serveurs, réseau, etc.) spécifique pour bien fonctionner, infrastructure qu’on ne trouve qu’en datacenter. Au contraire, nous nous pensons que c’est le logiciel qui doit s’adapter au matériel, et que la matériel est mieux en dehors des datacenters et partagé :slight_smile:.

Il y a un an, nous avons donc décidé de commencer le développement d’un nouveau logiciel : Garage.
Ce dernier peut fonctionner sur des boards ARM (Raspberry Pi, Odroid HC2, etc.) ou des vieilles tours x86 (par exemple des Lenovo Thinkcentre de 2010) à travers des connexions internets résidentielles (et donc des latences importantes). Bref, il peut-être déployé par n’importe quel bidouilleur ou bidouilleuse sans avoir à recréer un datacenter dans son sous-sol.

Mais vous vous demandez peut-être comment l’utiliser ? Et bien Garage expose une API standard qu’on appelle souvent S3 car conçue à l’origine par Amazon pour son service Simple Storage Service (S3 donc) mais implémentée par plein d’autres solutions, dont Garage. Grâce à cette API qui sert de « standard », Garage est déjà compatible avec plein de logiciels existants, comme Nextcloud, Matrix, Mastodon, Peertube, PixelFed, etc. pour qu’ils stockent leurs fichier sur Garage. Vous pouvez aussi utiliser des outils comme rclone pour envoyer vos backups directement sur Garage.

Enfin, Garage permet de publier vos sites web statiques (c’est une fonctionnalité qu’offre aussi Amazon S3 et que nous répliquons, pas de surprise pour celleux qui connaissent). D’ailleurs nos sites webs (deuxfleurs.fr et garagehq.deuxfleurs.fr sont tous les deux hébergés sur notre grappe garage).

En terme de stabilité, nous considérons que le logiciel est en « technical preview » : il fonctionne pour nous, nous l’utilisons en production, mais nous vous décourageons de vous lancer seul·e dans l’aventure : ça tombe bien, on a une install party et un salon Matrix pour en discuter !

À propos de l’install party

Nous organisons une install party le samedi 29 mai de 15h à 19h sur jitsi pour que toutes les personnes qui sont intéressées mais un peu effrayée par ce jeune logiciel puissent l’essayer tout en étant accompagnée par les développeur·euses.

Pour vous ce sera l’occasion d’apprendre à installer Garage sur une machine et le connecter à une grappe existante. Vous pourrez aussi poser vos questions et remonter vos remarques aux développeur·euses directement.

Pour nous ce sera l’occasion de faire connaitre un peu notre logiciel, de le tester sur du nouveau matériel, de comprendre un peu le besoin aussi des autres personnes autour de nous qui partagent des problèmes similaires.

Venez nous voir, ça nous fera très plaisir :slight_smile:

Liens utiles

7 « J'aime »
2

Bonsoir Quentin

Comme déjà partagé sur un autre sujet, le projet m’intéresse.
J’essayerais de participer en fonction de mes dispos.
Par contre, j’avais déjà regardé rapidement et j’ai certainement trop survolé, et du coup j’avais des questions par rapports au S3 et aux différents serveurs:

  • J’ai du mal à comprendre comment la répartition des données se fait en fonction de la taille des volumes, même si l’on pondère avec une valeur, que se passe t’il si l’on arrive au maximum du disque?
  • Autre point, si un des serveurs est non accessible pour une raison ou une autre que se passe t’il, est-ce qu’il y a juste plus de latence pour accéder aux fichier ? De ce que j’avais compris sur les S3 c’est une triple réplication des fichiers mais sur des disques réseaux avec un haut débit, qu’en t’il si c’est sur des connexion, dans le meilleurs des cas, fibres de chatons ?
  • si sur la grappe, il y a plusieurs type de connexion et donc débit plus ou moins rapide, comment cela se passe, est ce que le fichier est récupérer sur la connexion qui répond le « premier » ?

Peut être des questions « naïve » mais ça peut aider à comprendre et à choisir également le bon outil pour nos infra.

Dans tous les cas projet intéressant de mon point de vue et c’est encore un plus de mettre tout ceci en œuvre pour partager et faire avancer celui ci.

3

Bonsoir ManchotManosquin,

Merci pour tes questions, elles ont permis d’amorcer une discussion très intéressante dans notre salon de discussion ^^

Plutôt que de répondre point par point, je te propose la petite explication suivante qui je l’espère répondra à tes questions !

Approche théorique

Garage va découper tous tes fichiers en bloc de taille fixe (c’est configurable dans le fichier config.toml, par défaut 1Mo). Pour l’instant on impose une réplication x3, donc chaque bloc va être stocké sur 3 serveurs différents. Donc tu n’as pas à te soucier de la taille des fichiers ou des dossiers, ça va s’équilibrer tout seul sur les serveurs avec les pondérations.

Bon après il y a une subtilité, dans le cas où les 3 serveurs choisis pour stocker ton block seraient tous au même endroit : même batiment, même maison ou même datacenter, ça peut poser problème. En effet, si il y a une coupure d’électricité ou si le datacenter prend feu (toute ressemblance avec des faits réels serait fortuite) tes données peuvent devenir inaccessible voir détruites.

Pour pallier ce problème, on introduit le concept de « zones » (ou datacenter). Au moment de faire rejoindre une nouvelle instance Garage à la grappe, tu vas lui associer une zone (eg. « maison-quentin », « fablab-rennes », « maison-alice », etc.). Ensuite, au moment de stocker un block, Garage va essayer de stocker, dans la mesure du possible, les 3 réplicats sur des zones différentes.

Gestion de l’espace disque et des erreurs

Sans considérer les zones, pour peu que tu configures Garage avec les bonnes pondérations, alors tous tes disques devraient se remplir à peu prêt à la même vitesse.

Si tu as plusieurs zones, c’est plus compliqué car comme on a vu tout à l’heure, l’algo va d’abord répartir entre les zones, donc tu peux avoir une zone qui se remplit plus vite que les autres. Pour faire simple, pour l’instant, on ne supporte pas le cas des zones asymétriques : ça fonctionnerait mais tu auras peut-être pas les garanties que tu attends et donc on veut faire et tester ça proprement avant d’aller plus loin.

Dans tous les cas, il est attendu que tu monitores l’espace disque de tes serveurs pour réagir avant que le disque soit plein.

Si jamais un disque venait à être plein, alors il y a plusieurs cas possible :

  • Garage va valider ton écriture si il arrive à écrire sur au moins 2 des 3 serveurs qu’il a choisi. Donc si un seul serveur a son disque plein, la grappe va continuer à fonctionner, aucune donnée ne sera perdue, mais le cluster sera en mode dégradé (certaines données ne seront répliquées que 2x au lieu de 3x, il faudra libérer de la place et voir à réparer la grappe).
  • Si deux serveurs ont leur disque plein, alors tu ne pourras plus réaliser de nouvelles écritures, et une erreur sera retournée quand tu feras ton appel via S3.

Dans tous les cas, les lectures ne seront pas affectées.

Réflexion sur les performances

Garage écrit chaque fichier 3x, sur 3 serveurs différents mais il valide l’écriture dès que 2 des 3 serveurs ont fini leur écriture. D’un point de vue performance, ça veut dire que tu as juste besoin d’attendre les deux serveurs les plus rapides à chaque fois.
Pour ce qui est des lectures, Garage envoie une requête aux 3 serveurs impliqués de la même manière. En fonction de la donnée qui est lue, soit il attend 2 réponses (pour les métadonnées), soit il en attend qu’une seule (pour les blocs). Donc là aussi, tu n’auras jamais à attendre le serveur le plus lent. Et du coup, tu vois ici qu’un serveur lent à répondre ou inaccessible revient au même : tant qu’il y en a qu’un, tout va bien :slight_smile:

D’un point de vue plus général, Garage a besoin d’échanger beaucoup moins de messages sur le réseau que Ceph ou Minio pour pouvoir te répondre, entre autre parce qu’il n’a pas besoin de consensus (les fameux Raft et Paxos). Et c’est sur ce point qu’on compte faire la différence.

2 « J'aime »
4

Petit rappel, notre install party commence aujourd’hui à 15h (dans ~10 minutes) et on est là jusqu’à 18h/19h. Ça ne devrait pas prendre plus de 30 minutes d’installer un noeud, donc pas besoin de rester tout le temps qu’on a prévu. Et si vous voulez juste discuter un peu, c’est possible aussi.

Le tout est en ligne :