J'ai forké S3QL !
Contexte : J'ai des serveurs chez des hébergeurs français, et je voulais avoir du stockage partagé entre plusieurs serveurs, sauf qu'il n'y a pas d'équivalent à Amazon EFS, et pour les petits besoins, un NAS, c'est relativement cher. C'est aussi moins souple si ces besoins varient.
S3QL est une solution sympa (pour ceux qui ne connaissent pas, c'est un système de fichiers qui repose sur un stockage objet) mais on ne peut le monter que depuis un seul serveur.
Heureux hasard, je suis à l'aise avec Python, donc j'ai commencé à hacker le truc pour voir si on peut y accéder depuis plusieurs serveurs en même temps, et après quelques mois de travail, ça a donné ça : https://github.com/stokeo/cfs/
J'utilise une base de données Cassandra à la place de SQLite, j'ai une version de démo installée chez OVH qui fonctionne correctement depuis quelques semaines, même si c'est loin d'être parfait.
Je poste ici pour voir si ce projet intéresse d'autres personnes (si c'est le cas je serai certainement plus motivé pour documenter et fignoler la chose).
# J'achète !
Posté par ptit_poulet . Évalué à 2.
Je suis carrément intéressé. Je recherche une solution similaire depuis quelques temps.
Je te laisse me confirmer que ça répond bien à mon besoin.
Je cherche à avoir par exemple 3 machines avec chacune du stockage à mettre en commun, avec de la réplication. Et la possibilité d'ajouter dans le futur des nouvelles machines pour augmenter ce stockage. Le but final étant de pouvoir mettre ce stockage à disposition d'autres PC via samba par exemple et que l'utilisation soit totalement transparente. Est-ce que tout ceci est possible ?
[^] # Re: J'achète !
Posté par LoupSolitaire . Évalué à 4.
Avec CFS les données sont sur un conteneur de stockage objet et les métadonnées sont sur une base de données Cassandra, ça n'utilise pas le disque du serveur sauf pour de la mise en cache.
Si tu veux un cluster de stockage qui utilise les disques de tes serveurs, peut-être que GlusterFS peut être une solution. Si mes souvenirs sont bons c'est assez simple à configurer et ça évite de te taper la gestion de la base Cassandra.
Ça oui ça se fait sans soucis, c'est vu comme n'importe quel système de fichiers, donc on peut le repartager par Samba, NFS ou SSHFS par exemple.
[^] # Re: J'achète !
Posté par ptit_poulet . Évalué à 2.
Mince… tant pis…
Par contre je suis intéressé par le principe sur comment procéder pour monter un tel type de système comme un FS visible et utilisable de façon transparente. Si tu as de la documentation/piste que je pourrais étudier je suis preneur ;)
[^] # Re: J'achète !
Posté par Psychofox (Mastodon) . Évalué à 4.
En général quelque soit le système utilisé tu commence par configurer chaque noeud comme serveur, puis comme client à lui-même pour monter le fs distribué.
Ça peut être un peu perturbant, par exemple sous glusterfs tu vas avoir un volume logique lvm qui va être monté et visible mais servir pour les données locales de ton volume glusterfs et en même temps tu vas avoir un point de montage vers le volume glusterfs et c'est dans celui-là que tu devras travailler pour avoir les données distribuées et ne pas corrompre ton glusterfs. Sous ceph pas besoin de point de montage pour l'OSD (le serveur de volume) mais par contre un peu plus de config à faire pour un simple point de montage distribué entre 3 serveurs.
[^] # Re: J'achète !
Posté par ptit_poulet . Évalué à 3.
Je me suis mal exprimé. En fait j'ai déjà développé une solution de stockage distribué. Mais je n'ai aucune idée de comment faire pour rendre ce stockage montable comme un FS classique. C'est cette parti qui me pose problème. J'ai bien vu FUSE mais en toute honnêteté je ne sais pas comment l'utiliser afin de l'adapter à mon besoin.
[^] # Re: J'achète !
Posté par MrBidon . Évalué à 3.
Il y a plein de projet du genre GlusferFS et Ceph par exemple sont les plus connu.
En ce moment, j'aime beaucoup Seaweedfs un petit projet à l'ancienne comme on aime, il y a aussi Minio dans le genre.
[^] # Re: J'achète !
Posté par benja . Évalué à 3. Dernière modification le 09 novembre 2021 à 22:21.
moi aussi j'aime bien seaweedfs… j'ai un peu peur que ce soit un single-man project avec de temps à autres de bugs assez "gros", mais sinon c'est sexy et assez amusant à utiliser (la réplication active-active ou active-passive du filer/s3 par bucket, la topologie flexible, miam :) .
[^] # Re: J'achète !
Posté par benja . Évalué à 2.
Au fait, seaweedfs permet depuis peu de répliquer vers un autre S3, ce qui peut être utile pour limiter les coûts quand on a beaucoup de données mais avec des besoins d'accès différents (froid/chaud).
[^] # Re: J'achète !
Posté par MrBidon . Évalué à 3. Dernière modification le 11 novembre 2021 à 11:18.
Ah un autre curieux de ce projet, pour le coté "single man", j'ai été voir dans les noms des commiteurs sur Minio ça n'est pas mieux. Ce qui est fou c'est la réactivité du commiter principal, faut pas hésiter à lui faire des suggestions ou à poser des questions.
Je n'ai pas été fouillé dans le code, je ne déploie que des versions compilées avec mes petites mains et jusqu'à présent ça marche sans sourciller.
Ce qui m'intéresse principalement dans ce projet c'est la réplication "temps réel" synchrone intra datacenter (complètement validée pour moi, mais attention à l'Erasure Ccoding) et asynchrone entre deux datacenters distants (en cours de test pour l'instant).
# chiffrement
Posté par Psychofox (Mastodon) . Évalué à 2. Dernière modification le 09 novembre 2021 à 17:34.
enfin un projet qui propose le chiffrement.
J'étais peiné de voir que par exemple nextcloud support s3 comme stockage mais que les devs du projets à priori se contrefoutent du chiffrement. Officiellement dans les issues c'est, "ton hébergeur s3, tu lui fais confiance aveuglement ou tu le quittes".
[^] # Re: chiffrement
Posté par benja . Évalué à 1. Dernière modification le 09 novembre 2021 à 22:09.
D'un autre côté…
…est-ce qu'il n'est pas plus simple de mettre le chiffrement au niveau fs ou stockage (luks) pour avoir du même coup le chiffrement de toutes les méta-données (par là j'entends les logs, la base relationnel, etc.)
…est-ce qu'il n'est pas plus simple de stocker des objects déjà chiffrés dans s3, afin de ne pas dépendre de la technologie sous-jacente ?
Ou bien tu penses plus à quelque chose du style "server side encryption" (je ne me souvient plus du nom exacte) de s3 ? À mon sens, pour le commanditaire ce n'est qu'une façon de cocher une case dans un cahier des charges, ou pour aws (d'une manière plus positive :p), une façon de te faire payer plus cher quelque chose qui a un coup marginal. Si c'est vraiment ça que tu veux, même si c'est sans doute vrai que techniquement il s'agit simplement d'envoyer une clef de chiffrement à l'object store, amha ça serait toujours un peu bancale car il manquera l'intégration du gestionnaire d'accès et de secrets qu'offre une plateforme "nuage". (pour le côté positif: la possibilité d'auditer la qualité de l'implémentation, ce que ne permet pas un provider cloud commercial… d'où mon sentiment qu'il s'agit dans la majorité des cas d'un besoin "cocher une case": si tu veux être sûr, tu chiffres avant de stocker dans s3)
[^] # Re: chiffrement
Posté par benja . Évalué à 1.
Oops pardon, j'ai lu de travers et je pensais que nextcloud proposait un service s3 et que tu critiquais le fais qu'il ne permettait pas un chiffrement au travers de ce sevice. Je suis bien d'accord avec ta critique.
# Wasabi
Posté par Julien L. . Évalué à 1.
Est ce que ça serait compatible avec le fournisseur d'espace de stockage Cloud Wasabi ?
Wasabi semble compatible S3QL.
A ce jour quel est le risque en terme de perte de données si jamais ça foire ?
[^] # Re: Wasabi
Posté par LoupSolitaire . Évalué à 1.
Si ça fonctionne avec S3QL, alors CFS devrait fonctionner aussi car je n'ai pas touché à la partie backend de S3QL (la partie qui communique avec le stockage objet).
Je précise quand même qu'il faut une base cassandra pour les métadonnées. Dans le projet original c'est SQLite, ce qui rend l'utilisation plus simple, la bascule vers une base de données réseau oblige à avoir une chose en plus à gérer.
[^] # Re: Wasabi
Posté par Psychofox (Mastodon) . Évalué à 6.
ça n'aurait pas été plus simple d'utiliser rqlite pour rester plus proche de S3QL et pouvoir proposer comme patch?
[^] # Re: Wasabi
Posté par LoupSolitaire . Évalué à 4. Dernière modification le 10 novembre 2021 à 02:57.
Tu me fais découvrir rqlite, merci :)
Par contre ce serait pas suffisant, je l'ai découvert en adaptant juste les requêtes de SQL vers CQL (ça marchait pas).
Pour expliquer rapidement, S3QL a des optimisations qu'on ne peut pas garder si on passe en FS multi-serveur. Notamment son cache en écriture agressif : les données sont envoyées de manière asynchrone vers l'object storage et la base de données. Quand on a qu'un seul serveur c'est pas grave, on tape dans le cache à tous les coups, mais quand on en a plusieurs il faut envoyer vite les écritures pour que les autres machines suivent.
Le plaisir de découvrir qu'un truc que tu pensais hacker en quelques semaines se transforme en projet complexe. Mais c'est quand même intéressant à faire.
Voir cet autre commentaire sur le même sujet : https://linuxfr.org/users/loupsolitaire/journaux/cfs-systeme-de-fichiers-sur-stockage-objet#comment-1871607
[^] # Re: Wasabi
Posté par bbo . Évalué à 4.
Merci PsychoFox de m'avoir aussi fait découvrir rqlite !
Ce qui est drôle c'est que j'ai par hasard découvert dqlite aujourd'hui. La FAQ indique les différences suivantes avec rqlite :
Pour moi, cette semaine aura été celle des SQLite distribués !
[^] # Re: Wasabi
Posté par Psychofox (Mastodon) . Évalué à 3.
ah ben du coup merci de me faire découvrir dqlite ! Il est peut-être plus robuste je vais voir ça.
Le pire c'est que j'ai du utiliser dqlite sans m'en souvenir dans le passé…via des cluster k3s.
[^] # Re: Wasabi
Posté par claudex . Évalué à 4.
Je ne connaissais pas rqlite, mais en lisant rapidement la document, il stocke un fichier au format sqlite, ce qui est assez pratique pour debugger. Avec dqlite, on est obliger de passer par l'api pour voir ce qui est stocké.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Pourquoi forker ?
Posté par xavier Granveaux . Évalué à 5.
Bonsoir,
Tout est dans le titre.
Je viens de découvrir S3QL, que je trouve plutôt pas mal, et je comprends tout à fait l'intérêt de "CFS".
En revanche, je ne comprends pas pourquoi avoir forké;
Pourquoi n'avoir pas fait évoluer l'archi de S3QL pour permettre, par config, d'évoluer vers un mode de setup multinode / db distribuée à la lace d'un setup singleNode / SQLite ?
De ce que je comprends, il y a beaucoup de fonctionalitées dans S3QL, dédup & Co … qu'il faudra systématiquement reprendre dans CFS.
Je trouve ça un peu dommage sur le long terme, d'autant que la couverture fonctionnelle semble globalement identique.
Ca permettrait de simplifier la maintenance et d'éviter de diviser une communauté qui parait déjà pas bien grosse.
[^] # Re: Pourquoi forker ?
Posté par LoupSolitaire . Évalué à 8.
Il faudrait que j'engage la discussion avec l'auteur du projet. Je suis pas hostile à l'idée mais ça risque de pas être si simple.
J'ai "forké" principalement pour bricoler dans mon coin sans rien devoir à personne au début. Je n'avais jamais fait de gros projet de développement avant, donc j'étais pas du tout sûr d'arriver à mes fins.
Il y a des raisons techniques aussi, je pensais juste avoir à remplacer les requêtes SQL vers CQL mais au fur et à mesure je me suis rendu compte que ça ne marche pas. S3QL a des caches très agressifs y compris en écriture, certaines données ne sont synchronisées vers le stockage objet que toutes les 24 heures ou au démontage, ce qui évidemment ne peut pas se faire quand plusieurs serveurs accèdent aux données.
Dans certains cas on risque des fichiers corrompus si on a deux écritures simultanément, et j'ai même rencontré un cas où une requête en lecture provoquait la création d'un bloc vide rendant le fichier illisible sur l'un des serveurs (heureusement la modif restait locale, sinon ça aurait effacé le fichier concerné pour tout le cluster).
Et il y a encore pas mal de boulot, j'ai trouvé un bug important quelques heures après avoir posté ce journal.
Il faut aussi noter que S3QL est considéré comme stable depuis un moment, intégrer des gros changements va remettre ça en cause pendant des mois, voire des années sur un projet sensible comme un système de fichiers.
# Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Autre solution qu'un fork
Posté par Psychofox (Mastodon) . Évalué à 8.
Tu perdrait beaucoup de l'intérêt de la distribution quand même avec ce point de défaillance unique et la perte de flexibilité…
[^] # Re: Autre solution qu'un fork
Posté par ptit_poulet . Évalué à 2.
Chaque nœud pour faire office de serveur Samba via un service HeartBeat ou autre par exemple. Le fonctionnement reste "simple" et il n'y a plus de POF.
[^] # Re: Autre solution qu'un fork
Posté par Psychofox (Mastodon) . Évalué à 4.
Heartbeat c'est mignon mais il y a toujours un jour où tu te retrouves avec un split brain à gérer. Et si tu pars sur des solutions de clustering type corosync + pacemaker ça devient finalement plus compliqué qu'un système distribué.
[^] # Re: Autre solution qu'un fork
Posté par barmic 🦦 . Évalué à 4. Dernière modification le 10 novembre 2021 à 11:48.
Tes accès fond un passage sur NFS puis un sur le protocole S3-like, puis tu ajoute un heart beat, puis une élection pour savoir qui prend le relais.
C'est pleins de "petits" trucs plus ou moins simple qui doivent se coordonner avec autant de chance de ne pas très bien se comporter les uns avec les autres et avec de potentiels effet de bord (au changement de serveur primaire tu démonte/remonte tous tes points de montages je présume ?).
Je suis pas sûr que ce soit simple quelque soit le sens qu'on lui donne.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3. Dernière modification le 10 novembre 2021 à 11:06.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Autre solution qu'un fork
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 10 novembre 2021 à 11:29.
Tu patches une machine et la redémarre, tu as entre quelques secondes et quelques minutes d'interruption d'accès selon que c'est une VM ou un serveur physique. Avec un volume distribué dont le client a connaissance de tous les noeuds actifs tu reboote n'importe quel noeud sans qu'il y ait d'impact niveau client, tu peux perdres connectivité à un datacenter complet sans souffrir, etc.
Et nfs et les coupures réseaux, ça n'a jamais fait hyper bon ménage et suivant l'application qui utilise ce FS ça peut être franchement pénible.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Autre solution qu'un fork
Posté par Psychofox (Mastodon) . Évalué à 5.
Raison de plus pour en limiter les possibilités quand cela est possible. Je ne vois pas en quoi monter un service plus fragile est un avancement.
Où ais-je parlé de Amazon S3?
Si je peux avoir un service qui m'offre plus de flexibilité je suis toujours preneur. Une interruption de service quelque secondes pour une vm tous les 2 mois c'est rien en soit. De multiples opérations de maintenance toutes les nuits ça l'est moins. Avoir des systèmes résilients à la perte d'un noeud, c'est moins de maintenance de nuit, des équipes plus reposées, possibilité de gérer des infras plus grandes avec moins de personnel. C'est tout bénef.
C'est hors-sujet.
Oui comme les filesystem distribués comme cephfs.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Autre solution qu'un fork
Posté par Psychofox (Mastodon) . Évalué à 2. Dernière modification le 10 novembre 2021 à 17:04.
Tu mélanges des trucs qui n'ont rien à voir. Une équipe de sysadmin a tout intérêt à diminuer son coût opérationnel pour être plus performants et avoir du temps à dédier sur des projets qui améliore le service rendu. Je ne vois pas le rapport avec ton délire sur les certificats.
Si toi tu préfères gérer tes serveurs comme des petis joujous individuels, t'es soit resté bloqué dans les années 90, soit tu es juste un hobbyiste.
Si c'est hors-sujet. Quelque soit le stockage utilisé pour tes donnérs tu dois faire des sauvegardes. Je ne vois pas pourquoi tu mets stockage objet et distribué en opposition avec les backups.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Autre solution qu'un fork
Posté par barmic 🦦 . Évalué à 3.
Ce qu'il faut voir c'est quel est le contrat qu'on te donne (en terme de fiabilité, de performance, etc) et quand tu séquence des contrats (samba puis S3QL puis S3) tu as, au mieux, le pire des contrat dans chaque domaine et sinon l’interfaçage va empirer le résultat.
Donc non rien est parfait. En soit ce sont tout un tas de techno très complexes avec pleins de possibilités de plantages et de ralentissement qui tentent de simuler un contrat avec un haut niveau de garantie mais on risque d'empirer les choses.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.