Linux.general : Haute disponibilité et systèmes de fichiers
Posté par Julien MOROT (Jabber id, page perso, ) le 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.
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.
> Lire le message (4 commentaires, moyenne: 1).
Vous avez demandé le commentaire #747496.
Run by 
Cette page a été générée par Templeet en 0.0431s (dont 0.0037 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
je vais etre mechant...
debian etch pour des serveurs en prod ?
ok ok
je sors
=>[]
Apprendre par les autres, c'est bien.
Apprendre par soi-meme (RTFM, man, et notre ami google) c'est mieux
[^]Re: je vais etre mechant...
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.