Forum Linux.général Recherche système de fichier distribué extensible

Posté par  . Licence CC By‑SA.
Étiquettes :
2
4
mar.
2014

Bonjour à tous,

Je suis en train de refaire totalement les serveurs que j'héberge chez moi, et une idée m'est venue sans que j'arrive à vraiment trouver des info. Je pense que je ne dois pas chercher comme il faut. Alors je me tourne vers vous.
J'aimerais constituer un stockage en réseau qui puisse être distribué et extensible.
En gros, je démarre à une machine (linux ou BSD) avec gros disque dur qui expose NFS et SMB au reste du réseau. Mais si dans, 1-2 an je veux augmenter sa taille, je me dis que, plutôt que de tout racheter et migrer, je pourrais juste acheter une nouvelle machine (et y mettre linux ou BSD) avec son/ses gros disques durs et former un cluster avec la première. Genre un RAID5 ou 6 distribué entre 2 machines. Et 1-2 ans plus tard, rebelote, achat nouvelle machine, ajout au cluster de fichier, extension de la capacité de stockage.

J'ai essayé de regarder dans la direction des fs comme gluterfs, lustre, ceph, moosefs, etc… mais je n'arrive pas à trouver de la documentation claire, vraiment basique et claire, pour savoir si ce que je souhaite faire est possible, ni un exemple de déploiement de cluster de ce type.

Alors je me tourne vers vous : savez-vous où je peux trouver de la doc sur ce genre de config ?, si c'est actuellement possible ?, où je peux trouver une synthèse claire de comment ça marche, ces FS (gluterfs, lustre, etc…) ?

Merci d'avance !

  • # (DRDB ou NDB ) + LVM

    Posté par  . Évalué à 4.

    avec NDB tu exposes des "partitions" au travers du reseau
    LVM par dessus pour gerer l'ajout d'un "disque" dans une grappe.

    seulement dans ton scenario, ca veut dire que tu laisses toutes tes machines allumées, et tu ne retires pas les plus vieilles.
    pourquoi ne pas simplement faire une machine actuelle, avec 2 disques.
    puis dans 1 ou 2 ans, acheter simplement 2 autres disques, plus gros, et cloner les disques actuels vers les 2 nouveaux, puis retirer les deux anciens.

    • [^] # Re: (DRDB ou NDB ) + LVM

      Posté par  . Évalué à 2.

      En fait l'idée c'était justement de ne pas retirer les plus anciens. En 1-2 ans, ils ne sont pas encore dépassés en terme de capacité, ils sont juste pleins.

      Exemple concret, j'ai aujourd'hui un NAS avec 2 disques durs de 2To en Raid miroir, achetés en 2010. Ils sont pleins à 95%. Les disques durs d'aujourd'hui, ne sont pas beaucoup plus gros : mettons que j'en achète 2 de 4To que je mets en Raid miroir, que je clone les anciens et m'en débarrasse, je serais juste passé de 2To pleins à 95% à 4To pleins à 48%.
      Bof, quoi… Alors qu'avec un filesystem distribué et extensible, je pourrais jouir de 6To pleins à 29%.
      Voire plus, si je ne mets pas les disques en Raid miroir, mais qu'ils sont intégrés dans un filesystem global qui serait tolérant aux fautes. Il y aurait 12To potentiel de disque dur (2*2To anciens + 2*4To neufs), moins forcément les mécanismes de tolérance au fautes, et autres joyeusetés. Mais ça resterait quand même beaucoup plus élevé que juste 4To (les 2*4To neufs en raid miroir)

      Je retiens l'idée de NDB+LVM, je vais creuser ça un peu. Pour DRDB, malheureusement, pour le moment, ça ne marche que pour faire de la réplication temps-réel entre deux machines, en vue de faire de la haute-dispo. Pas trop mon cas. Ou alors, j'ai mal compris et je me ferais un plaisir de me faire corriger.

      • [^] # Re: (DRDB ou NDB ) + LVM

        Posté par  . Évalué à 3.

        DRDB c'etait pour le coté distribué, et le fait qu'il faut que ca continue de fonctionner si une machine tombe en panne.

        je viens de penser que NDB +LVM c'est une idée, mais ca ne fait pas de "redondance"
        par contre NDB + ZFS doit de permettre de creer un Zpool avec les "disques" NDB

        par contre je ne sais pas s'il peut apprecier le redemarrage d'une machine, ou l'arret de celle-ci pendant un certain temps (disque NDB indispo)

        • [^] # Re: (DRDB ou NDB ) + LVM

          Posté par  . Évalué à 1.

          J'ai regardé NDB+LVM, ça me paraît un peu overkill.
          Je me disais qu'un truc comme gnunet, mais en LAN, sans tout le chiffrement et avec un point de montage système, ça pourrait faire l'affaire. Un stockage distribué en P2P local au LAN.
          Chaque serveur NAS partagerait tout ses disques avec les autres, via ce truc. Et c'est ce logiciel qui répartirait les données, les I/O, etc… On veut ajouter de la capacité de stockage sans tout changer ? hop, nouveau serveur qui rejoint le réseau P2P.

  • # GlusterFS

    Posté par  . Évalué à 1.

    Bon, ça, ça me parle : http://www.hmarcy.com/2012/03/gluster-an-open-source-nas-solution/

    Il y a des schémas qui parlent, et des exemples super simples pour commencer à bien comprendre.
    Je vais creuser un peu dans cette direction.

    • [^] # Re: GlusterFS

      Posté par  . Évalué à 3.

      prerequis :

      Recommended configuration is to have the OS on two disks (RAID1) and the data on twelve remaining disks (RAID6).

      ca fait deja un gros NAS pour la maison s'il faut 12 disques pour les datas et 2 pour l'OS ;)

  • # une idée, sans cependant avoir creusé ...

    Posté par  . Évalué à 2.

    ISCSI + Global Filesystem, ça pourrait peut-être le faire ?

    En gros, quand tu ajoutes une nouvelle machine, tu la configures en serveur iscsi. Avec LVM + Global Filesystem, tu ajoutes tes LUNs ISCSI à un volume LVM + GFS.

    Par contre si tu multriplies trop les machine,s ça risque de devenir compliqué à gérer ..

Suivre le flux des commentaires

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