Forum Linux.général lvm + dmraid + nbd

Posté par  .
Étiquettes : aucune
0
6
mar.
2008
Salut,

j'ai 2 serveurs sous linux, l'un étant une réplique de l'autre (mais un seul tournant en prod à un instant t).
Quelle solution pour faire cette réplication en "temps réel" d'une partition, sachant que comme contrainte je dois également utiliser lvm pour les backups (snapshot) (ou autre chose si vous connaissez mieu).

Je me suis laissé dire que drdb ne marchait pas vraiment bien, surtout avec lvm, et zfs-fuse me parait encore vraiment trop beta.
Est-ce que quelqu'un a essayé de de faire un raid logiciel avec comme device, le disque physique de la machine, et de l'autre un device nbd ? Et si oui, est-ce que je pourrai profiter de son retour d'expérience ?

Merci

  • # Partage SCSI, par exemple.

    Posté par  . Évalué à 2.

    Plutôt que de faire une réplication, tu peux essayer de limiter au maximum les partitions montées en rw, de monter tout ce qui peut être ro en partageant un même bus SCSI, par exemple, entre tes deux machines et en gardant tout ce qui doit être dynamique (/var et le swap) en local, + /home en NFS si réseau d'entreprise.

    Dès lors, si ta machine principale tombe en panne, la seconde aura probablement besoin d'être redémarrée pour passer en production complète, mais guère plus.

    • [^] # Re: Partage SCSI, par exemple.

      Posté par  . Évalué à 1.

      Merci de ta réponse tout à fait censé.

      Mais en fait j'ai une grosse contrainte, c'est que je ne sais absolument pas a quoi vont servir les machines ;)
      en fait je sais juste qu'il doit y avoir un volume lvm sur opt (en rw) qui doivent être à chaque instant T identiques, et qu'elle seront sur un "site pas trop proche", et reliés soit en ethernet gigabit, soit en fiber channel. J'avais bien sur proposé un NAS où serait stocké (et donc partagé ce genre d'info), mais apparement le client ne veut pas augmenter les couts, et ne veut surtout pas centraliser... Donc en gros mon taf cest de faire le cd d'install spécifique a ces 2 machines avec ces contraintes.

      Si aucune solution ne marche vraiment bien en prod, ca finira en script avec dnotify, mais c'est vraiment crade, et ne me garanti absolument pas le coté transactionnel de la chose.

      • [^] # Re: Partage SCSI, par exemple.

        Posté par  . Évalué à 2.

        Un LVM sur /opt, déjà, ça me paraît vachement douteux ! :-)

        Effectivement, un suivi des mouvements du fs avec [di]notify vient naturellement à l'esprit, mais comme le suppute, outre les problèmes transactionnels, les temps de latence risquent de devenir insupportables et un engorgement de la file d'événement pourrait avoir des conséquences dramatiques.

        Je pense également à du raid logiciel, plutôt en fiber channel, pour que tes NBD soient directement reconnus comme tel, mais comme cette machine distante aura de toutes façons besoin d'une connexion réseau.

        C'est pour faire quoi, au fait ? Je parie que, comme d'habitude, le client est parti dès le départ sur une solution irréfléchie et veut trouver à postériori une façon de l'implémenter plutôt que de revoir le concept.

        • [^] # Re: Partage SCSI, par exemple.

          Posté par  . Évalué à 2.

          C'est pour faire quoi, au fait ? Je parie que, comme d'habitude, le client est parti dès le départ sur une solution irréfléchie et veut trouver à postériori une façon de l'implémenter plutôt que de revoir le concept.

          Ben comme souvent j'en sais rien, je pencherai pour une solution proprio qui s'installe d'elle même sur le /opt... Peut être un gestionnaire de doc ou une pki, vu les contraintes également pour le backup (l'opérateur backup ne doit en aucun cas pouvoir lire une info de la sauvegarde), enfin un truc suffisament top secret pour que je n'ai pas le droit de le savoir...
          Et effectivement, si c'est un système de mail, une db ou je ne sais quelle autre saloperie, je pourrai proposer une solution en conséquence qui serait potentiellement plus adapté...

          Bon j'ai vu également des solutions à base de coda ou de gfs, jvais maquetter un peu tout ça et voir ce qui tient le mieu

          • [^] # Re: Partage SCSI, par exemple.

            Posté par  . Évalué à 2.

            ... à base de coda ...

            Je ne sais pas si ça a été changé depuis 3/4 ans (date à laquelle j'ai touché mon dernier codafs), mais attention à la quantité de données répliquée à terme afin de correctement dimensionner les machines vis à vis du cache.

  • # drbd

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

    On utilise drbd depuis presque 1 an en prod on a pas de soucis, par contre impossible de me souvenir si ya du lvm, c'est pas sur

    Mes 2cts

    • [^] # Re: drbd

      Posté par  . Évalué à 1.

      En fait le problème de lvm + drdb, serait apparement le rajout de volume, et le redimenssionement de ceux ci, pouvant saturer les metadatas de drdb, avec comme conséquences des pertes de data. C'est du conditionnel, je n'ai pas testé moi même

    • [^] # Re: drbd

      Posté par  . Évalué à 1.

      En fait le problème de lvm + drdb, serait apparement le rajout de volume, et le redimenssionement de ceux ci, pouvant saturer les metadatas de drdb, avec comme conséquences des pertes de data. C'est du conditionnel, je n'ai pas testé moi même

Suivre le flux des commentaires

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