Forum Linux.général Haute disponibilité et systèmes de fichiers

Posté par  (site web personnel) .
Étiquettes :
0
24
août
2006
Bonjour à tous,

Voila l'exposé de la situation. J'ai un serveur web et un serveur mail à migrer vers une solution de haute disponibilité. Les deux serveurs sont actuellement en FreeBSD et vont migrer en Debian Etch. Jusque la pas de problèmes, on double les serveurs et on rajoute un heartbeat par dessus afin que l'IP virtuelle commute si le premier serveur est défaillant.

Le principal problème que j'ai concerne la disponibilité des données. J'ai bien un NAS dans lequel les serveurs pourraient puiser leurs données mais ce n'est pas une solution que je souhaite. Mis à part que le NAS est déja bien occupé, le NAS devient un nouveau point de faiblesse en cas de panne de celui-ci. On peut toujours doubler les NAS mais d'une part je n'en ai pas le budget, d'autre part il y a toujours le problème de la réplication de données.

Donc le stockage doit forcément être local.
Du coup j'ai regardé les différentes solutions possibles avec les conclusions suivantes :
- DRDB et network raid : la conf ne me plait pas, ça ne gère pas la tolérance de pannes, limité à 2 noeuds (si je veux virer le heartbeat et passer à du DNS round robin plus tard)
- Coda FS : pas de mirroring des données
- Intermezzo : plus maintenu
- GFS : Trop orienté RedHat, la recompilation des sources des différents outils et patchs kernel et adapter ce qui devra l'être à une Debian ne me tente pas.
- Rsync : inutilisable pour le serveur mails car les mails en pop ne font que en gros rebondir sur le serveur donc inutilisable dans ce cas. Pour le serveur Web, un rsync quotidien sur plusieurs dizaines de Go de données, on a vu plus rapide.

Du coup il me reste sous la main deux systèmes de fichiers que sont Lustre et OCFS2. OCFS2 a l'avantage d'être intégré en standard dans une etch mais semble un peu jeune. Lustre n'est pas intégré en standard mais semble fiable car utilisé sur des cluster du top 500. Tous deux gèrent la reprise sur panne également.

Donc j'aurais souhaité avoir des retours d'expérience si vous avez utilisé l'un des deux, lequel vous avez choisi et pourquoi. Si vous avez choisi une autre solution vous pouvez aussi vous exprimer :)

Merci d'avance.
  • # Openssi

    Posté par  . Évalué à 1.

    cluster HA & HP
    HA :
    DRBD,OCFS,LUSTRE,OPENAFS

    * FC2/FC3 supporté
    ->pour la FC3 j'ai du mal à faire la HA avec DRBD, mais le support est en dev et sera effectif avec la version 2.0 début 2007
    * Debian (sarge) supporté

    Pour l'avoir testé sur une FC2 (2 sessions VmWare, HA avec drbd), la config est très simple et les résultats sont à la hauteur de mes besoins
    [tout est automatisé lors d'une surcharge d'un noeud ou un problème de dispo de données]

    J'attend avec impatience la version 2.0, j'ai mon système (web+messagerie) sous une fc3 et je pourrais donc mettre en place officiellement cette solution

    Pour débian, tu peux télécharger des images vmware préparées sous débian sarge avec HA DRBD ,LVS ...
    --> http://deb.openssi.org/contrib/openssi-vmware-3node.zip
    • [^] # Re: Openssi

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

      Le problème de Openssi c'est que c'est l'artillerie lourde pour faire un cluster avec un tas de choses dont je n'ai pas besoin (migration de processus, IPC, management, LVS) alors que je cherche uniquement un FS avec réplication et reprise sur panne et la dessus Openssi n'a même pas de décision tranchée car il gère notamment Lustre et GFS.
  • # je vais etre mechant...

    Posté par  . Évalué à 1.

    debian etch pour des serveurs en prod ?

    ok ok
    je sors
    =>[]
    • [^] # Re: je vais etre mechant...

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

      Bof, je ne vois pas de problèmes à coller des Debian Etch pour un serveur en cours de déploiement. La base est pratiquement freezée et les mises à jours de sécurité sont faites avec une sortie prévue en décembre (pour poursuivre le troll, l'année n'est pas précisée ;) donc je n'ai pas d'inquiétudes à avoir. Et je ne veux pas me palucher l'upgrade dans quelques mois :)
      Après il y en a bien avec des serveurs en sid! Perso je n'en prendrais pas le risque mais en suivant bien les alertes de sécurités et la liste debian-devel, si on sait ce qu'on fait j'aurais envie de dire pourquoi pas.

Suivre le flux des commentaires

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