----- Original Message -----
From: "Yannick Lecaillez" <yl@???>
To: <guilde@???>
Sent: Wednesday, March 03, 2004 9:57 AM
Subject: Re: High Availability / Clustering
> Le mar 02/03/2004 à 20:10, Dominique Chabord a écrit :
> > ----- Original Message -----
> > From: "Jean-Marc Coursimault" <guilde@???>
> > To: <guilde@???>
> > Sent: Tuesday, March 02, 2004 4:42 PM
> > Subject: High Availability / Clustering
> >
> >
>
> >
> > A propos de shaman-x:
> > Le kit (appelé shaman-x_disaster_recovery_kit) que l'on s'apprête à
diffuser
> > se duplique sur n serveurs (typiquement 3 à 8) qui se surveillent
> > mutuellement. Les jeux de données sont répliqués par drbd (drbd.org)
dont
> > les couples primary/secondary se forment en fonction de la disponibilité
des
> > serveurs.
> J'avais jeté un coup d'oeil sur drbd à l'époque où je montais mes
> serveurs en Fail-Over avec heartbeat. Le principal problème qui m'a fait
> abandonner cette solution est le fait qu'il ne réplique que des
> partitions. C'est pas mal pour /home mais si on veut, dans le cas d'un
> serveur Web par exemple, répliquer les fichiers de log d'Apache situés
> dans /var/log/httpd/ c'est mort (à moins de créer une partition pour
> /var/log/httpd ou de déplacer les logs ... c'est sur). Bref, je trouvais
> cette solution trop peut flexible ...
drbd ne fait que ce qu'il sait faire: du disque répliqué à distance. C'est
peut etre heartbeat qui n'est pas assez flexible.
Il me semble logique dans ton cas de faire pointer /var/log/httpd vers une
partition répliquée. Je pense cependant que je te rejoins en cela que
répliquer des logs par le biais d'une réplication disque n'est qu'une
protection très imparfaite. En effet, la corruption de A entrine la
corruption de B.
> Comme je le disais dans un précédent post, Coda FS
> http://www.coda.cs.cmu.edu/ (ou Intermezzo mais il n'existe qu'en beta
> il me semble) m'a l'air beaucoup plus approprié étant donné qu'il sait
> bien gérer les synhcro même en cas de coupure réseau etc etc ...
> Malheureusement je n'ai pas réussi à trouver de doc simple dans le cas
> de réplication de serveur (si qqn à des sources ...).
> Je pense qu'il serait vraiment TRES intéressant d'étudier Coda FS pour
> une solution de HA car il est bien plus flexible que drbd.
Le concept de Coda FS est attractif, mais seule la simplicité est source de
robustesse.
Je prédis que la fiabilité obtenue sera plus faible que ext3+drbd, justement
parce que la flexibilité à un prix.
Au niveau fiabilité, je crois qu'on ne trouvera pas beaucoup plus sur que
ext3+rsync+tar, le cauchemar en quelque sorte ;-)
Si ça branche
> du monde on pourrait peut-être essayer de se réunir pour mettre ça en
> place ? Car il existe plein de bonne solutions pour répartir la charge
> et faire du HA (LVS notamment) mais il n'y à pas grand chose que
> j'oserais qualifier de "vraiment valable" quand on recherche à
> synchroniser deux serveurs.
Coda FS est une technologie qui n'a encore jamais été utilisée avec succès.
Elle illustre un concept prometteur, et je suis intéressé par tout projet
avancé dans ce domaine.
Si on en est à regarder le futur, je pense que le projet OpenSSI est plus
prometteur à moyen terme parce qu'il se base sur le file système des
clusters UNIX de Digital.
>
> Des amateurs ?
>
>
> P.S : Ce point de vue date d'il y à environ 10 mois : peut être que les
> choses ont évoluées depuis ce temps. Dans ce cas, je vous remercierais
> jamais assez de me contredire ! :-)
>
>
> --
> Yannick Lecaillez
> Ingénieur système d'information & sécurité
> <yl@???>
>
> http://www.seasonfive.com
> Vivaxe Interactive
> 116 bis, allée des dauphins
> 38330 Saint Ismier
> Tél: 04 76 52 95 70
>
>
