Garage, stocker des données en dehors des datacenters

Tech Infrastructure
2

Hello,

Merci pour la présentation! Je ne connaissais ni deuxfleurs ni Garage (et je me demande comment je suis passé à côté).

Un peu HS, mais je suis vraiment impressionné par la qualité de votre documentation et l’intelligence des outils que vous avez développé. J’ai beaucoup aimé votre post de blog sur l’autogestion.

Je vais jeter un oeil plus qu’intéressé à Garage, puisque je fais un état de l’art des systèmes de backup et de stockage distribué en vue de créer un système de sauvegarde solidaire, où les acteurs s’échangent leurs sauvegardes (c’est un projet de recherche).

1 « J'aime »
3

Oui, stockons nos données par nous même.
Par contre, avec garage, on doit gérer des « cluster »,

Connaissez-vous IPFS?

https://www.youtube.com/watch?v=7MGMkGq60VU

https://github.com/anthonybudd/S4

Puet-être est-ce possible de rendre garage compatible?

4

On prépare une revue assez large des différentes techno de stockage distribué car c’est vrai que c’est une question qui revient souvent. On a donc connaissance de Ceph, Riak CS, Openstack Swift, Minio, OpenIO, GlusterFS, SeaweedFS, Tahoe-LAFS, IPFS, Freenet, HDFS, etc. En attendant, pas mal des différences avec ces projets sont expliquées dans les commentaires de ce fil Hacker News.

Pour IPFS et Content-based addressing, je ne suis pas expert donc c’est peut-être imprécis. Il me semble que ce sont des techniques qui s’adressent à du contenu public : les autres nœuds du réseau peuvent, si ils le souhaitent, mettre en cache le contenu.

Premier point : si ils le souhaitent, si personne n’est intéressé par mon contenu, il n’y aura pas de copie dans le réseau, et donc je risque de perdre mes données en cas de défaillance de mon noeud.

Deuxième point : on doit stocker du contenu privé comme des emails, des photos privées partagées dans notre outil de chat, etc. Ces contenus privés n’ont pas vocation à se retrouver sur le réseau.

Le projet IPFS est conscient de ces 2 limitations et propose IPFS Cluster avec 2 modes : un strong consistency avec Raft, un autre eventual consistency. Le premier, avec Raft, aura les mêmes problèmes que Minio (cf notre benchmark), le second, à cause de l’eventual consistency, ne fonctionnera pas avec les applications existantes (quand tu créer un fichier, il n’est pas visible tout de suite). Avec Garage, on arrive à fournir le bon niveau de cohérence sans avoir à recourir à Raft.

Après, rien ne t’empêche d’interconnecter une instance Garage au reste du réseau IPFS à travers la passerelle ipfs/go-ds-s3.

Et tu peux très bien décider d’exposer une instance Garage à travers Tor, il te suffit de configurer un Onion Service (avant ça s’appelait Hidden Service) dans la configuration de ton daemon Tor. Si des personnes ici sont intéressées, je peux donner les étapes détaillées.

Ton lien « S4 » semble être un assemblage de technologies : Tor, IPFS, ipfs/go-ds-s3, minio, docker, etc. selon le schéma du dépôt. Dans ce schéma, tu peux remplacer Minio par Garage de manière assez transparente, et tu ne perds rien au passage tout en profitant des qualités et défauts de Garage, et voilàaaa :slight_smile:

Par contre je ne peux m’empêcher de penser que les performances d’un tel empilement de technologies sur un pauvre raspberry pi doivent être abyssalement mauvaises, je déconseille fortement de se lancer dans de tel projets pour des services importants ^^

2 « J'aime »
5

En participant à l’expérience « Astroport 20;12 », je suis depuis quelques mois en mode « OffGrid » avec une connexion à l’Internet global intermittente.

On explore la culture sur sol vivant, et une nouvelle organisation qui permette de vivre sur la planète sans devoir en consommer 5. Dans ce cadre on expérimente ipfs pour assure la propagation des données façon « pigeon voyageur » entre Oasis et Astronautes :wink:

ipfs arrive a fonctionner sur RaspberryPi Zero. Cela nous permet d’explorer une structure totalement pair à pair du réseau.

On utilise Nextcloud pour synchroniser les smartphone et collecter les vidéos
Une chaine Youtube a démarré

https://www.youtube.com/watch?v=qg8VVyTnyeU

Tu crois qu’on pourrait introcuire Garage dans ce contexte?

6

On vient de publier une nouvelle version (0.7.0) de Garage avec le support de la télémétrie, l’integration de Kubernetes et des bugfixes. Le détail est dans notre billet de blog ici : Garage - An open-source distributed storage service - Bonne lecture !

@qo-op j’ai pas vraiment de réponse idéale à te donner pour Garage. Je pense qu’il y a pas mal de choses dans la sphère Device to Device (D2D) qui est plus prévu pour que notre logiciel. Je serais curieux d’avoir ton retour sur Manyverse (Secure Scuttlebutt). Une fois installé sur ton Android, tu peux te synchroniser directement de téléphone en téléphone. Donc si Alice s’est synchro avec Bob, puis plus tard Bob avec Charle, Charle pourra récupérer les messages de Alice en même temps que ceux de Bob. D’ailleurs son créateur vit sur un voilier. Après, pour revenir sur Garage, un point que j’ai pas encore testé, ce serait de prendre un vieux téléphone, compiler Garage pour le faire tourner dessus, et comme ça tu as une petite plateforme autonome qui consomme rien sur laquelle tu peux stocker des données et les partager, y compris à travers du web. Et pour pousser l’idée jusqu’au bout, associer plusieurs téléphones sur un réseau local (voire maillé, à la B.A.T.M.A.N.) qui forment une seule grappe Garage. Là on est clairement dans le hack car on a pas prévu Garage pour ce cas d’usage ! Mais si tu fais ça, on prend les retours ! PS : je suis allé voir tes vidéos, et je pense que créer un réseau alternatif aux réseaux opérateurs 3GPP (LTE, 5GNR, etc.) serait un beau projet dans la continuité de ton initiative, donc wifi maillé, communication opportunistes, radioamateur, lorawan, il y a plein de possibles à explorer :slight_smile:

7

Hello @quentin,

J’ai parcouru votre doc, c’est super intéressant et ça me semble déjà pas mal abouti, félicitations !

Par contre, le premier cas d’usage qui m’est venu en tête, c’est de monter un cluster avec des amis à coup de raspberry sur nos connexions internet personnelles, mais en lisant le point suivant dans la doc, j’ai l’impression que ce n’est pas possible pour le moment :

  • Each machine has a public IP address which is reachable by other machines. Running behind a NAT is likely to be possible but hasn’t been tested for the latest version (TODO).

Dans mon cas, je n’ai pas d’IP fixe mais du DNS dynamique, et encore moins d’IP publique par machine. Est-ce qu’il y a quand même un moyen de faire fonctionner Garage dans ces conditions ?

8

Garage peut fonctionner avec des IPs dynamique pour peu qu’elles ne changent pas toutes en même temps. Aujourd’hui, dans pas mal d’endroits en France, tu as de l’IPv6 chez toi, ce qui in-fine te donne bien 1 IPv6 publique par machine. Ce serait vraiment l’idéal pour ton déploiement, après certains opérateurs sont encore à la traîne malgré les directives de l’ARCEP, et je le déplore. Si tu as seulement de l’IPv4 mais que tu as du NAT hairpinning sur ta box, tu peux aussi mettre tes instances Garage locales sur des ports différents (~4 ports / instance), et ensuite les NATer dans ta box. Encore une fois, tant que les différents IPv4 publiques de ton réseau ne changent pas en même temps, c’est bon. Dans la doc, on a voulu rester simple en décrivant un déploiement idéal.

Si vraiment ce n’est pas possible d’avoir d’IP publique, tu peux mettre en place un VPN entre tes machines, comme Wireguard (ou sa version commerciale Tailscale), ou plus expérimental mais en mode « maillé », Yggdrasil. Il y a bientôt un an de ça, on avait fait un test avec Yggdrasil et un serveur en 4G, ça avait fonctionné correctement dans le cadre du test.

Si jamais tu as des questions, par exemple sur comment Garage fait pour gérer les IP dynamiques (mon fameux "ne pas changer toutes les IP dynamiques en meme temps), je peux t’expliquer ça plus en détails.

1 « J'aime »
9

Merci pour toutes ces informations !

Je n’ai pas d’IPv6 hélas, par contre je peux faire du NAT (sans hairpinning) mais j’imagine que si j’ai qu’une seule instance chez moi, et les autres sur une autre IP publique, ça devrait le faire non ?

10

Oui, ça devrait le faire ! Si jamais tu as un problème, n’hésite pas à passer sur nos salons Matrix (#garage:deuxfleurs.fr ou #tech:deuxfleurs.fr), on pourra débugger ça ensemble.

1 « J'aime »
11

Quelques informations sur l’avancement de notre projet.

La dernière version en date de Garage est la v0.7.2. Par rapport à la v0.7.0 elle inclut pas mal de correction de bugs et une API REST pour l’administration qui devrait faciliter largement le scripting des déploiements (par exemple avec Ansible). Pour rappel, on considère encore le logiciel en beta, et l’API REST pourrait être amenée à changer d’ici la version stable.

Deuxfleurs était invité dans l’émission Open Tech Will Save Us #16 de la fondation Matrix avec Nathan Freitas du Guardian Project pour parler de nos visions de la résilience. Ils ont un projet très intéressant de réseaux déconnectés basés sur un Raspberry Pi et F-Droid. Pour en savoir plus : https://likebutter.app et https://gitlab.com/guardianproject/wind/wind-offline-fdroid-repo-on-rp - Et on a parlé du collectif CHATONS :slight_smile:

Si vous êtes chercheuse ou chercheur en informatique et que ça vous parle ce qu’on fait, on est intéressé pour faire une demande de projet ANR (ou équivalent) avec Deuxfleurs comme partenaire privé. Avec Garage, on a des problématiques de calcul/système distribué (modèle de cohérence, contraintes de notre environnement), optimisation (comment répartir les donnés de manière optimale sur le cluster tout en garantissant certaines propriétés), et de théorie du contrôle (gestion dynamique des timeouts comme détecteur de faute, etc.). En particulier, on a déjà des trucs qui marchent (exemple) et qu’on aimerait formaliser dans des papiers.

3 « J'aime »
12

Coucou.

De retour « OnGrid », je reviens faire un tour sur le Web2.0 :wink:

L’expérience Geconomicus en « Habitat Foret Jardin » a planté des graines.
Bases d’une société « auto-suffisante » établie sur des logiciels et technologies libres:
https://ipfs.copylaradio.com/ipfs/QmUtGpGeMZvwp47ftqebVmoFWCmvroy5wEtWsKvWvDWJpR/Foret%20Enchantée%20-%20PROJET%20ASTROPORT.pdf

Avec NextCloud et IPFS nous avons pu continuer à utiliser nos smartphones et portables en mode ‹ OffGrid ›. Et même établir les règles d’un jeu mettant en pratique le DU(G1) selon 2 masses monétaires.

Nous avons essayé pas mal d’applications pair à pair… Dont « Manyverse »

SSB est un excellent protocole de structuration de PKI

En ce qui concerne Manyverse et plus généralement le protocole SSB. Comme chaque clef « transporte » toutes ses données (limités à 8Mo) dans son « Architecture Kappa » il en résulte des temps de synchronisation très longs lorsque de nouvelles connexions se font!!

Pour y remédier, nous avons prototypé une application à partir de TiddlyWiki enregistré dans IPFS.
Dans ce cas, l’index à partager lors des synchronisations entre « clefs amies » n’est que de qq 10aine de Mo. Le cliqué/glissé des Tiddlers permet de picorer les « index de ses amis » en conservant les données sur sa « passerelle ipfs ».

https://talk.tiddlywiki.org/t/tiddlywiki-and-the-ipfs-video-wall-experiment/4978

Pour aller plus loin dans l’intégration du protocole SSB sur IPFS, nous aurions besoin d’un coup de pouce. Il manque une librairie de chiffrement compatible « ed25519 » embarquée dans TW. https://talk.tiddlywiki.org/t/adding-a-new-cryptographic-library-as-tw-plugin/5266

Justement.

L’utilisation de IPFS comme service de stockage et partage inter « node » combiné à la distribution de clef de chiffrement nous en offre l’opportunité.

Il reste à tisser une « Toile de Confiance Technique », un cercle de confiance d’administrateurs systèmes et réseau qui permette de mettre en commun nos diverses ressources et services du réseau de chatons. Nous pourrions utiliser le système déployé autour de la G1 pour unifier la crypto et devenir co-créateur monétaire. La question est lancée ici : https://forum.duniter.org/t/il-manque-une-tdc-a-notre-tdc/10500?u=frederic_renault

Nous avons commencé à mettre en ligne en « DNS Round Robin » & « IP Dynamique » quelques :heart:BOX pour copier, héberger, partager ses vidéos Youtube favorites… Utilisant Docker et construit avec Duniter et la base GChange+. Enfin. Les données de toutes les applications qui comporte une « clef publique » associé à son utilisateur sont récupérables.

@quentin merci pour la découverte.
Avec https://github.com/ipfs/go-ds-s3 on pourrait proposer à des développeurs d’application de stocker dans ce « meta datacenter hébergé chez nous tous ».
[edit] En fait, non. go-ds-s3 permet de sauvegarder le datastore ipfs sur S3…
C’est là que Garage peut jouer? Dans ce cas on pourrait partager le même datastore entre plusieurs passerelles ipfs?

1 « J'aime »
13

J’aimerais me mettre à Garage pour backup mon VPS et des serveurs d’ARN sur un netbook yunohost chez moi.
Existe-t-il une initiative au niveau CHATONS ? Un noeud à rejoindre ? Ou vaut-il mieux que j’essaye quelque-chose à l’échelle d’ARN ? Backup mutualisés entre adhérent.es ARN avec Garage - Infra - Alsace Réseau Neutre

1 « J'aime »
14

ça fait un moment que je veux m’y mettre, j’ai pas encore démarré avec garage@yunohost, mais une initiative CHATONS peut ptêtre me motiver. :wink:

15

Côté cloud girofle je suis aussi entrain de tester garage (entre autre pour le stockage nextcloud).

S’il y a une initiative commune je suis assez intéressé pour participer.

1 « J'aime »
16

ping @quentin :smiley:

17

Merci pour votre intérêt et le ping @GautGaut. Je fais une pause Deuxfleurs/CHATONS jusqu’en mars prochain pour me concentrer sur le boulot (subvention Aerogramme). En mars, je pourrai mettre en place une (petite) machine chez moi et animer la création d’un premier cluster CHATONS dit « expérimental » si vous voulez : avec la volonté de mettre de la vraie donnée dessus mais avec une tolérance à l’erreur. Ça pourrait être une porte d’entrée, avec l’idée qu’une fois que les gens se sont fait la main, puissent discuter pour quitter ce cluster et se faire ensemble leur propre cluster.

3 « J'aime »
18

Salut, c’est super chouette que des gens soient intéressés ! En tant que dev de garage, si jamais vous faites un atelier je peux passer pour discuter et donner des infos. J’ai pas vraiment le temps d’organiser quoi que ce soit moi-même mais j’ai l’impression que si plusieurs personnes ont du stockage disponible qu’iels veulent mettre en commun, il suffirait de choisir une date en visio pour monter un premier cluster tous ensemble.

1 « J'aime »
19

Qu’entendez-vous par « une tolérance à l’erreur ». Si je mets mes backups dessus je préférerais qu’il n’y ait pas de corruption de données ;). Mais supposant suffisamment de redondance des backup (via un autre système que garage) pourquoi pas.

Je pense qu’on peut attendre Mars prochain pour lancer un premier cluster officiellement, et éventuellement commencer avec un cluster de test dans les prochains mois. Je devrais avoir un peu d’espace dispo sur un serveur dès ce WE.

20

ça m’intéresse aussi malheureusement, que ce soit sur l’infra de katzei ou la mienne (en pratique c’est les mêmes machines physiques) il n’y a plus de place et pas vraiment d’option pour rajouter des HDD.

21

Je pense que c’est une politique à définir ensemble justement. Dans mon idée, ce sera de proposer un cluster pour celles et ceux qui veulent une première expérience de prod’ avec Garage. Là où je nuance la proposition de LX, c’est qu’il y aura certaines pratiques à suivre. Par exemple : dire quand on va faire des modifications, alerter en cas de problème technique, etc. Toutes ces pratiques humaines c’est ce qui fait ou non la résilience de ton cluster. Par contre, ben peut-être que quelqu’un va se planter et lancer un scrub qui va bouffer trop de ressources et va timeout des requests. Peut-être que quelqu’un va déclencher un rebalance au mauvais moment, etc. Bref, quand on apprend à opérer un logiciel, et même après, il y a des erreurs, et perso je suis intéressé par animer un cluster d’apprentissage où on peut s’autoriser ces erreurs, où on est pas paralysé à l’idée d’en faire. Le tout sera de définir la part d’erreur qu’on s’autorise, et de laisser les gens choisir ce qu’ils trouvent OK ou non. Si c’est pas des backups qu’on host sur ce cluster expérimental, ça pourra être des tiles SVG Openstreetmap, un miroir de distro Linux, whatever. Il y a des trucs pas trop critiques qu’on peut héberger de manière utile.

3 « J'aime »