[Admin-ml] Changement de serveur...

Piel Jayce jayce at mosx.org
Lun 25 Aou 18:56:03 CEST 2008


Le 25 août 08 à 18:35, Fabrice Vincent a écrit :
> Pour un failover automatique, il faut que la baie soit joignable en
> permanence par les deux noeuds du cluster. Ça exclus donc le DAS (en
> interne, en firewire, en SCSI, etc..), car à ma connaissance on ne  
> peux pas
> connecter un DAS à plus d'un serveur à la fois. Pour ça il faut un  
> SAN ou un
> NAS...

Tout à fait.
Bien que théoriquement, un DAS avec deux connexions soit possible,  
moyennant un contrôle de l'hôte et du passage de l'un à l'autre avec  
des scripts de FailOver, je ne crois pas que qui que ce soit ait  
jamais mis ça en place.

> Avec un SAN il reste le problème de gérer les accès concurrents:  
> soit on
> utilise un contrôleur de SAN (comme par exemple Xsan), soit on monte  
> les
> volumes du SAN seulement sur le maître et on déclanche le montage sur
> l'esclave seulement dans les scripts de failover.

Avec le SAN, on retombe surtout sur le problème de dimensionnement du  
problème. Parce que seules des "vraies" machines serveurs peuvent  
servir de contrôleur SAN si j'ai bien compris.

> Dans le cas d'un NAS, je suppose que c'est l'OS du NAS qui gère la
> concurrence d'accès.

Oui. Et c'est là que le problème de compatibilité arrive... :-/

> 1) jusqu'à la 10.4.10 incluse, le failover IP ne marchait pas sur  
> plateforme
> intel (voir l'article http://docs.info.apple.com/article.html?artnum=305066)

C'est effectivement une raison valable en soi... :-)

> 2) Comme l'indiquait Franck, la gestion propre du failover et du du  
> retour à
> la normal est quelquechose d'assez délicat à gérer. La complexité  
> que cela
> apporte peut tout à fait amener plus de soucis que de solutions si  
> on ne
> fait pas très attention à bien gérer tous les cas de figures et tous  
> les
> états transitoires! Sans compter qu'il faut tout retester après  
> chaque mise
> à jours système...

Ca, c'est juste le boulot d'un admin... :-)

> 3) avec les Xserv-RAID (pour les Vpromise je sais pas), il restait à  
> ma
> connaissance encore un maillon faible (un SPOF, "Single Point Of  
> Failure",
> comme on dit): bien qu'étant équipé de deux contrôleur RAID, chaque
> contrôleur gérait sept disques et seulement ses sept disques. Du  
> coup, quand
> un contrôleur tombait on perdait l'accès aux disques qu'il  
> contrôlait...

Ce n'est plus un problème avec les Promise...

> Pour le NAS c'est encore plus simple: un NAS, c'est juste un serveur  
> qui ne
> fait que du partage de fichier. Comme  c'est un serveur, il a autant  
> de
> risque de panne que les autres. Du coup, comme on met tous les oeufs  
> dans le
> panier NAS, quand il tombe en panne ben ça fait encore plus bobo...
> Je me trompe ?

Tout à fait exact.

Et on retombe aussi sur la gestion du RAID en logiciel ou en hard. Le  
hard étant plus complexe, il y a plus de risque de panne, mais les  
perfs sont meilleures........


> Du coup, je me contente d'un failover manuel du style je débranche les
> disques (internes ou externes) du serveur en panne, pour les mettre  
> sur un
> serveur sain. Si cela arrive, je coupe le serveur de développement  
> pour
> mettre dessus les disques de prod. Mais jusqu'à présent, avec mes  
> disques en
> RAID 1, les seules pannes bloquantes que j'ai eu ont été de rare  
> kernel
> panic ou un simple reboot suffisait...


Je pense que c'est effectivement vers ça que je vais me tourner...  
Reste à trouver une solution utilisable avec un Mac Mini pour ne pas  
avoir à acheter un deuxième XServe... :-)

-- 
Piel Jayce
jayce at mosx.org








Plus d'informations sur la liste de diffusion Admin-ml