Forum Linux.général Recherche système de fichiers réparti, distribué, déconnecté

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
6
10
sept.
2013

Bonsoir !

J'ai deux machines sous Linux que j'utilise pour mes développements :

  • un fixe, plutôt véloce mais sans écran ni clavier/souris, qui sert de machine de build,
  • un portable, un peu plus poussif mais avec écran, clavier et souris, qui me sert de machine principale et que j'emmène en déplacement.

Lorsque je suis chez moi, j'utilise le portable uniquement pour éditer mon code, mais compile avec le fixe. En déplacement, j'utilise le portable pour éditer et compiler (car pas d'accès au fixe). Jamais les modifications ne sont faites à partir du fixe, la synchro est toujours portable -> fixe.

Pour le moment, j'utilise soit un rsync, soit un montage NFS pour accéder aux fichiers du portable depuis le fixe. C'est rébarbatif, et j'oublie parfois le rsync ; le montage NFS est barbant.

Je souhaite donc trouver un système de fichiers distribué et réparti qui fonctionne en mode déconnecté, et garde une copie des fichiers sur toutes les machines participantes :

  • je suis chez moi, le portable et le fixe partage le même système de fichiers par le réseau, tout est synchro en permanence (minus la latence du réseau à transférer les fichiers), ou en mode lazy (au besoin, ou sur timer, par exemple) ;
  • je suis en déplacement, le portable est le seul à avoir une instance du système de fichiers, et le montage ne chouine pas parce que le fixe n'est pas accessible. Par contre quand je rentre chez moi, la synchro entre les deux machines se fait aussitôt ; si je tente d'accéder à un fichier depuis le fixe, et que le système de fichiers n'a pas encore synchronisé ce fichier, c'est fait aussitôt, ou en mode lazy.

J'ai regardé des solutions styles ceph, hadoop, lustre, etc… Mais c'est la grosse artillerie orientée data-center, ça me semble un peu et je ne suis pas sûr que chacun accepte de fonctionner (correctement) en mode déconnecté.

Des idées ?
Merci ! :-)

Note: la synchro des outils (eg. toolchain et autres) n'est pas à prendre en compte : elle est effectuée de manière manuelle (les deux machines n'étant pas de la même distro).

Hop,
Moi.

  • # Quelques pistes...

    Posté par  (site web personnel, Mastodon) . Évalué à 4.

    Hello!

    Un petit bricolage: un cronjob qui lance un script qui vérifie si ton fixe est accessible, et qui le cas échéant lance un rsync.

    Un peu moins bricolage: un des nombreux Dropbox-like. Bittorrent Sync est efficace en plus d'être léger et rapide, mais il n'est pas opensource. Sinon, des choses comme DVCS-Autosync (pas testé, mais le principe est séduisant).

    Mes 2c…

    • [^] # Re: Quelques pistes...

      Posté par  . Évalué à 2.

      un cronjob

      La granularité de cron, c'est une minute. Don au pire, je devrais attendre 1 minute pour que les fichiers soient synchronisés. Trop long.

      un des nombreux Dropbox-like

      Pas question d'utiliser Dropbox : le round-trip est bien trop long. De plus, le client n'est pas libre ; ditto bittorentsync : client pas libre.

      dvcs-autosync, de mon expérience, n'est pas super fiable.

      C'est des pistes que j'ai déjà explorées, sans succès. Mais merci des suggestions! :-)

      Hop,
      Moi.

      • [^] # Re: Quelques pistes...

        Posté par  . Évalué à 5.

        inotify pour surveiller un dossier,
        rsync pour lancer la synchro (si le serveur est dispo)

  • # Mauvaise piste

    Posté par  (site web personnel) . Évalué à 6.

    Je pense que tu n'es pas forcement sur la bonne piste.

    En gros ce qu'il te faut c'est plutôt de l'intégration continue. Par exemple un jenkins (assez facile à mettre en place avec un serveur jetty) qui serait synchro sur git. Tu mets ton serveur git sur ton fixe et tu configure le tout pour que quand jenkins détecte un commit, il compile directement ton code.

    L'avantage de cette solution est que tu peux commiter ton code en mode déconnecté puis quand tu rentres chez toi tu as juste à pousser tes modifs pour que ça fonctionne. Tu n'as plus qu'un seul outil à te préoccuper qui synchronisera tout.

    Bon après je parle de jenkins et git mais tout soft d'intégration continue et gestionnaire de révision décentralisé fera l'affaire.

    • [^] # Re: Mauvaise piste

      Posté par  . Évalué à 3.

      c'est pas terrible par ce qu'il faut commiter pour builder.
      Et on sait tous qu'il ne faut pas commiter si on a pas testé et encore moins si on est même pas sur que ça compile.

      Par contre jenkins reste un outils intéressant pour justement lancer une compilation et tout une batterie de test plus poussé que le développeur n'aura pas forcement pu faire avant de comiter et détecter des problèmes dans l’œuf au boulot ça nous est très utile. Mais je ne pense pas que se soit l'outils ne plus adapté dans son cas.

      • [^] # Re: Mauvaise piste

        Posté par  (site web personnel) . Évalué à 5.

        Il est toujours possible de commiter dans une branche de dev et que jenkins ou tout autre outils merge ensuite dans une branche stable si la compilation et les test ont réussi.

        En étant un peu agile ça peut sur la méthode ça peut même apporter un plus à la manière de travailler.

    • [^] # Re: Mauvaise piste

      Posté par  . Évalué à 2.

      de l'intégration continue

      Non, ce n'est pas la même chose. Je ne veux pas commiter et pousser mes changements avant d'avoir vérifier qu'ils fonctionnent, au moins dans les cas droits.

      L'intégration continue, c'est plus pour tester les régressions sur les jeux de tests.

      Et mes développements sont déjà sous git ou Mercurial. ;-)

      Hop,
      Moi.

  • # Lua + rsync

    Posté par  . Évalué à 3.

    Et ça ?

    https://code.google.com/p/lsyncd/

    • [^] # Re: Lua + rsync

      Posté par  . Évalué à 2.

      lsyncd

      La synchro de cette manière ne me convient pas, notamment lorsque je suis en mode déconnecté.

      Je ne veux pas avoir à gérer différemment le cas "à la maison" du cas "en déplacement". Surtout, je veux que la synchro se fasse automatiquement lorsque je me retrouve de nouveau "à la maison".

      Le problème avec de la synchro applicative, c'est quand il y a une grande quantité de données à transférer. Avant de pouvoir utiliser les fichiers depuis le fixe, il faudra que j'attende que la synchro soit entièrement finie, là où un système de fichiers sera "logiquement" synchronisé (à chaque stat, il y a au moins synchro des répertoires), je pourrais utiliser les fichiers aussitôt ; si leurs contenus ne sont pas encore synchronisés, alors le FS garantit que ce sera fait, soit au besoin lors d'un open, soit en tâche de fond.

      Ceci dit, lsyncd vas me servir dans un autre cas. Donc merci pour le pointeur ! :-)

      Hop,
      Moi.

  • # glusterfs

    Posté par  . Évalué à 5. Dernière modification le 11 septembre 2013 à 14:18.

    Bon, j'ai une piste qui me semble assez prometteuse : GlusterFS / site officiel

    GlusterFS permet la duplication et le failover, et surtout semble simple à installer (là où ceph, moose, lustre et consorts semblent nécessiter un peu plus d'investissement…).

    Merci pour les suggestions dans vos messages ci-dessus. :-)

    Hop,
    Moi.

    • [^] # Re: glusterfs

      Posté par  (site web personnel) . Évalué à 2.

      testé et inutilisable si tu as plus de 1 ms de ping entre les machines.
      Sans parler qu'il est Linux only (gênant en milieu hétérogène).

      • [^] # Re: glusterfs

        Posté par  . Évalué à 3.

        inutilisable si tu as plus de 1 ms de ping entre les machines

        Bon, ça tombe bien, il y a juste un switch giga entre les deux machines.

        Linux only (gênant en milieu hétérogène)

        Bon, ça tombe bien, je suis Linux-only.

        Merci pour le retour. :-)

        Hop,
        Moi.

        • [^] # Re: glusterfs

          Posté par  . Évalué à 3.

          Je serais intéressé par le retour d'expérience.

          « 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

          • [^] # Re: glusterfs

            Posté par  . Évalué à 2.

            intéressé par le retour d'expérience

            OK, je ferais le log de mon install, et quand j'aurais un peu de recul, je ferais un petit nourjal.

            Hop,
            Moi.

  • # Distributed Replicated Block Device

    Posté par  . Évalué à 1.

    http://fr.wikipedia.org/wiki/DRBD
    http://www.drbd.org/

    Mais c'est peut être un peu trop lourd pour ce que tu veux faire.

    • [^] # Re: Distributed Replicated Block Device

      Posté par  (Mastodon) . Évalué à 2.

      Le problème de DRBD, c’est qu’il ne s’agit que d’un block device, il faut que le système de fichiers au dessus soit à même de fonctionner en mode réparti pour que ça puisse être monté en parallèle sur 2 machines. Tu ne peux pas mettre un ext* dessus et le monter sur les 2 hôtes. J’avait pensé aussi un moment lui proposer du md ou lvm en mirroir sur le réseau, mais c’est le même problème.

  • # GFS2??

    Posté par  (site web personnel) . Évalué à 1.

    Bonjour,
    j'ai testé il y a quelque temps GFS2 qui est un système de fichier clusterisé très performant et facile à mettre en place.
    Peut-être cette solution répondra t'il à ton besoin.
    J'ai rédigé un tutoriel complet sur le sujet en espérant que cela puisse t'aider:

    www.journaldunadminlinux.fr/tuto-installation-et-gestion-du-file-system-gfs2

    www.journaldunadminlinux.fr

    • [^] # Re: GFS2??

      Posté par  . Évalué à 2.

      GFS2

      Ah oui, j'avais déjà vu ton tuto. :-)

      Dans l'ensemble, GFS2 me plaît bien, mais il lui manque (comme à peu près tous les autres) le mode _déconnecté_ : il a besoin d'unmasterce qui me pose problème ; lemaster` serait mon PC fixe, mais en déplacement, c'est pas trop gérable : je n'y ai pas toujours accès.

      Merci du tuyau [*] ! :-)

      Hop,
      Moi.

      [*] Hé, c'est pas un tuyau, c'est un tuto!
      OK, je -->[] ;-)

  • # Rsync + gfs2

    Posté par  (site web personnel) . Évalué à 1.

    Dans ce cas il suffit de paramétrer un petit rync qui synchronisera tes données. Comme ça à chaque fois que tu pars en déplacement avec ton pc portable tu disposeras de données fraîches!

    www.journaldunadminlinux.fr

    • [^] # Re: Rsync + gfs2

      Posté par  . Évalué à 2.

      à chaque fois que tu pars en déplacement avec ton pc portable tu disposeras de données fraîches

      En fait, c'est l'inverse : mon potable a toujours les données fraîches. ;-)

      Ce que je cherche à faire, c'est garantir que, à chaque instant où mes deux machines sont ON, les données entre les deux sont synchro et que le PC fixe peut être absent sans mettre en péril l'intégrité des données du portable.

      Donc, "à chaque instant" implique que cron n'est pas suffisant.

      Et j'ai pas envie de le faire "à la main" (sinon à quoi ça sert d'avoir une machine à automatiser les tâches à la base ? ;-) )

      Hop,
      Moi.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 2. Dernière modification le 01 novembre 2013 à 08:38.

        Ce commentaire a été supprimé par l’équipe de modération.

  • # Coder ton truc avec du btrfs send/receive ?

    Posté par  . Évalué à 2.

    Je me suis toujours dit qu'il y aurait un truc à faire avec le fonctionnalité send/receive de btrfs (enfin, les devs même du truc ont déjà du y penser). J'ai cherché « btrfs replication » sur un moteur de recherche, et je suis tombé sur ça : http://docs.opensvc.com/storage.btrfs.html
    Ça a l'air de faire un peu usine à gaz qui fait plein d'autres trucs inutiles, et en plus ça n'a pas l'air d'être « live », mais ça peut être une idée intéressante à implémenter.

    Oui, ya du boulot :-)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.