Failover OVH automatique

15 réponses

Auteur	Message
Bool \| Modérateur Inscrit le : 09/05/2005	# Le 23/08/2008 à 18:50 Hello, voici donc une procédure pour mettre en place (sur une Debian) un système de failover automatique grâce à heartbeat et l'API d'OVH. Je vais prendre comme exemple cette infra : La machine lilo.daevel.fr, de référence OVH "ks01234.kimsufi.com" ayant l'IP 10.0.0.1 La machine stitch.daevel.fr, de référence OVH "ns05678.ovh.net" ayant l'IP 10.100.0.2 Ainsi que deux IP "failover" : 10.200.0.3 et 10.200.0.4. Le but étant qu'en temps normal 10.200.0.3 pointe sur la machine lilo et 10.200.0.4 pointe sur la machine stitch. Si une des machines tombe, tout le trafic sera aiguillé sur la machine encore active. Par contre je précise de suite : ) utilisez cela à vos propres risques, je ne suis pas responsable des éventuels problèmes qui peuvent être générés par cette procédure et ces outils. ) ne vous attendez pas à une tolérance aux pannes parfaite comme chez d'autres hébergeurs, le service de failover d'OVH a un temps de réactivité de 2 à 5 minutes. ) l'API d'OVH n'indiquant pas quand une demande de bascule est en cours, si une demande contraire est faite en plein milieu Heartbeat sera quasiment à coup sûr désynchronisé... et l'IP très probablement inutilisable jusqu'à ce que vous interveniez. Installation des paquets nécessaires, sur les deux machines : aptitude install heartbeat php5-cgi Oui... l'API OVH utilisant SOAP il m'a semblé plus simple d'utiliser PHP. Configuration d'Heartbeat* (j'utilise la configuration de type v1, la v2 étant un peu beaucoup imbuvable à mon goût) On crée les deux fichiers de configurations qui devront toujours être identiques sur les deux machines. OLD_UMASK=`umask` ; umask 027 ;\ cat /usr/share/doc/heartbeat/authkeys > /etc/ha.d/authkeys ;\ cat >> /etc/ha.d/authkeys <<EOF auth 1 1 sha1 UN-LONG-MOT-DE-PASSE-COMPLIQUE EOF umask $OLD_UMASK ; zcat /usr/share/doc/heartbeat/haresources.gz > /etc/haresources ;\ cat >> /etc/haresources <<EOF lilo.daevel.fr ipFailoverOVH::10.200.0.3 10.200.0.3/32 stitch.daevel.fr ipFailoverOVH::10.200.0.4 10.200.0.4/32 EOF Pensez évidement à adapter le contenu de ces deux fichiers (pour générer un mot de passe alléatoire, vous pouvez faire un makepasswd --chars=16 après avoir installé le paquet makepasswd). Il faut ensuite créer le fichier de configuration spécifique à la machine. On commence par prendre le modèle : zcat /usr/share/doc/heartbeat/ha.cf.gz > /etc/ha.d/ha.cf Attention l'ordre des paramètres dans ce fichier est très important donc décommentez les instructions présentes, ne les ajoutez pas à la fin. Dans ce fichier vous pouvez par exemple décommenter ces valeurs : keepalive 2 deadtime 30 warntime 10 initdead 120 udpport 694 Il faut surtout penser à décommenter la ligne "ucast" pour indiquer l'ip de l'autre machine. Donc sur lilo on aurait : ucast eth0 10.100.0.2 et sur stitch : ucast eth0 10.0.0.2 Vous pouvez également pinger régulièrement les routeurs de ces machines au cas où ils rencontreraient un problème (pour vérifier l'adresse du routeur, faites un ip route show). Pour cela décommenter les lignes "ping" comme cela : Sur lilo : ping 10.0.0.254 et sur stitch : ping 10.100.0.254 Puis décommentez/modifiez la ligne : deadping 30 Ajout du script pour l'API OVH ( http://daevel.fr/ipFailoverOVH.txt ) DEST=/etc/ha.d/resource.d/ipFailoverOVH ;\ wget -O $DEST http://daevel.fr/ipFailoverOVH.txt ;\ chmod +x $DEST ; ln -s $DEST /usr/local/sbin/ Ainsi le script est également utilisable via SSH. Configuration du script Création du fichier de configuration par défaut : OLD_UMASK=`umask` ; umask 027 ;\ cat > /etc/ha.d/ovhConfig <<EOF [global] login=XX1234-OVH pass=XXXXXXX EOF umask $OLD_UMASK ; chown root.haclient /etc/ha.d/ovhConfig Si vous avez modifié l'hostname de votre machine, il faut l'indiquer dans le fichier de configuration. Dans notre infra d'exemple il faut ajouter : [alias] lilo.daevel.fr=ks01234.kimsufi.com stitch.daevel.fr=ns05678.ovh.net De même si vous avez plusieurs interfaces réseau sur vos machines, il faut indiquer sur quelle interface/IP l'IP failover doit être attribuée : [10.200.0.3] lilo.daevel.fr=10.0.0.1 stitch.daevel.fr=10.100.0.2 [10.200.0.4] lilo.daevel.fr=10.0.0.1 stitch.daevel.fr=10.100.0.2 Pour vérifier que l'API fonctionne, essayez via SSH : $ ipFailoverOVH 10.200.0.3 status 10.200.0.3 is routed on lilo.daevel.fr/10.0.0.1 Vous pouvez également utiliser le nom correspond au reverse de l'IP : $ ipFailoverOVH failover1.daevel.fr status 10.200.0.4 is routed on lilo.daevel.fr/10.0.0.1 Une fois que tout fonctionne un /etc/init.d/heartbeat restart sera nécessaire pour activer tout cela. PS : bien sûr si vous avez des suggestions quant à l'amélioration du script, je suis preneur ! daevel : infogérance et conseil \|\| moi
MathieuC \| Mathieu Modérateur Inscrit le : 15/07/2005	# Le 24/08/2008 à 16:14 Comme la tres grosse majorite des tuto technique, c'est totalement imbuvale pour quelqu'un qui ne connait pas deja les outils, c'est dommage. Il faudrait expliquer comment fonctionne le script, ce qui se passe et le but des commandes, pour que quelqu'un qui ne connaisse pas ce qu'est "failover", "heartbeat" et "API d'OVH" puisse au moins comprendre l'utilite et le fonctionnement de ce que tu presente et ainsi decider si ca peut lui etre utile. Sinon l'idée est bonne, mais moi j'aime pas les IP failover car elles mettent trop de temps a bouger, et pendant qu'une modification de pointage est en cours, on est dans le noir le plus complet, on a aucune info de la part d'OVH
darkham \| Adrien Membre Inscrit le : 11/05/2005	# Le 24/08/2008 à 16:39 Je ne trouve pas cela imbuvable perso, mais parcontre il est vrai que je ne suis pas chaud avec les ip failover !!!! Widoox : http://www.widoox.fr
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 24/08/2008 à 17:29 Tu as raison Mathieu, le but était d'indiquer une procédure plutôt que d'expliquer l'intérêt de tout cela. Donc si je reprends dans l'ordre : le but ici est de mettre en place une tolérance aux pannes ("failover"), et uniquement cela. C'est à dire que lorsque le serveur tombe en panne les visiteurs sont envoyés automatiquement vers un serveur de secours. Et c'est bien à quoi servent ces IP : la bascule ne doit être qu'occasionnelle, ce n'est certainement pas à utiliser pour faire de la répartition de charge. Heartbeat quant à lui est un outil qui permet à deux serveurs de se surveiller mutuellement afin de détecter un éventuel problème et d'agir en conséquence. Chez un hébergeur classique par exemple dès qu'Heartbeat détecte un problème (sous 2 secondes souvent), il s'attribue l'IP de l'autre serveur et ainsi il n'y a quasiment pas d'interruption de service. Le soucis dans notre cas c'est qu'OVH ne permet pas ce genre de choses et on est obligés d'avoir recours à leur service "ip failover". C'est donc là qu'intervient l'API d'OVH : elle permet plus ou moins d'automatiser cette bascule d'IP d'une machine à une autre, avec toutefois un délai de plusieurs minutes. Réduire la panne à 5 minutes au lieu de plusieurs heures/jours, c'est déjà un très bon point je trouve. Et si cela est vraiment problématique je vois deux solutions : 1) ne pas passer par un hébergeur discount, voir mieux passer par un hébergeur qui propose des services de tolérance aux pannes dans ses services. 2) mettre en place dans une baie OVH des frontaux qui n'auront ainsi pas besoin d'utiliser le service "ip failover" d'OVH ; quitte à ce que les serveurs derrière soient des dédiés en location. ========= Pour ce qui est du script en lui même, son rôle est surtout d'interfacer Heartbeat avec l'API d'OVH : heartbeat fait référence aux machines en utilisant leur nom tandis que l'API OVH utilise la codification interne d'ovh. De même l'affectation est faite par heartbeat en fonction de l'interface (eth0/eth1) tandis que l'API OVH demande l'IP principale de l'interface en question. Sinon il y a 3 cas : /etc/ha.d/resources.d/ipFailoverOVH 10.200.0.3 start Heartbeat indique ici que la machine courante chercher à prendre l'IP failover "10.200.0.3". Le script se charge donc de répercuter la demande via l'API. Le hic c'est que l'API génère une erreur si l'IP est déjà affectée au serveur indiqué. Le script va donc d'abord interroger OVH pour savoir si l'IP est déjà affectée ou non ; mais comme tu l'as souligné on a aucun moyen de connaitre l'état "intermédiaire" (c'est à dire qu'une demande est en déjà cours). Donc il se peut que le script se trompe et ignore la demande. /etc/ha.d/resources.d/ipFailoverOVH 10.200.0.3 stop Heartbeat indique ici que la machine va libérer l'IP. A cette étape le script ne fait rien, mais idéallement elle devrait refuser la demande tant que l'IP n'est pas effectivement basculée sur l'autre serveur. /etc/ha.d/resources.d/ipFailoverOVH 10.200.0.3 status Heartbeat cherche à savoir si l'IP a bien été basculée vers le serveur courant ; si ce n'est pas le cas il va libérer l'IP. Ici le script fait effectivement la demande auprès d'OVH mais ne retourne pas le résultat à Heartbeat : le temps de réactivité du système OVH est beaucoup trop lent et Heartbeat abandonne bien avant que l'IP soit correctement basculée. (la communication avec Heartbeat se fait uniquement en fonction du code de retour : 0 = OK, toute autre valeur = ERREUR) ========= Il y a donc pas mal de limitations à ce système mais je n'ai pas trouvé mieux pour le moment avec les outils "classiques" (Heartbeat et KeepAlived principalement). Une autre solution serait de développer une solution spécifique au mécanisme de failover d'OVH. Cela ferait fortement réinventer la roue, mais l'ordonnancement étant plus adapté réduirait voir supprimerait l'impact du temps de bascule. daevel : infogérance et conseil \|\| moi
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 24/08/2008 à 18:54 Je viens de faire une série d'autres tests, et ce n'est pas génial : - heartbeat veut que le "stop" fonctionne. Et même s'il ne fonctionne pas, il dégage l'IP donc l'effet est le même. - l'interface OVH se vautre de temps à autre : outre la session qui expire durant l'exécution du script, j'ai aussi eu le droit à la destruction/reconstruction de mon IP failover à la volée.... j'ai même reçu le mail d'OVH pour confirmer la création. Bref je crois qu'il va falloir se passer d'Heartbeat et développer un truc 100% maison qui tienne également compte du failover OVH. daevel : infogérance et conseil \|\| moi
MultiNetWorks \| Damien Membre Inscrit le : 13/05/2005	# Le 24/08/2008 à 20:29 Il y a une classe à la fin de la discussion pour faire le changement d'IpFailOver : http://forum.ovh.com/archive/index.php/t-16659.htm... Damien...
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 24/08/2008 à 20:53 Bah la classe ne sert plus à rien, vu qu'il y a maintenant une API pour faire ça. Le soucis c'est le "reste" justement. daevel : infogérance et conseil \|\| moi
flush \| Jean-Philippe Modérateur Inscrit le : 09/05/2005	# Le 24/08/2008 à 21:03 Bool > un petit script php avec un file('http://') qui récupère un hash Le tout lancé dans un cron toutes les minutes ... Vu le fail over qui est très long ... on est plus à 30 secondes près de perdu ! @+ Jean-Philippe
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 24/08/2008 à 21:34 Oui c'est sûr, mais ça ne fait qu'un seul contrôle. Le problème c'est que si le cron tourne sur les machines elles même, on a aucune vérification du réseau. Et si le script est centralisé sur une autre machine, on devient dépendant de celle ci. Ce n'est pas pour rien qu'il y a des outils plus élaborés comme heartbeat. Mais oui comme je disais, plus ça va et plus je pense qu'un script maison serait plus adapté. daevel : infogérance et conseil \|\| moi
abravanel666 \| Sylvain Modérateur Inscrit le : 19/07/2009	# Le 08/09/2009 à 11:21 Hello Je suis en train de mettre en place du failover sur mes 2 serveurs Y a t'il eu une conclusion sur le sujet ? http://www.magasins-usine.info http://www.shoppingactu.com
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 08/09/2009 à 11:31 L'offre VLAN devrait bientôt sortir, et ainsi permettre l'utilisation de "vraies" solutions de failover. daevel : infogérance et conseil \|\| moi
Julgates \| Julien Administrateur Inscrit le : 09/03/2005	# Le 08/09/2009 à 11:32 Bah ca serait pas trop tot, car la le débit entre les machines est horrible. Shopping Time Network - Founder / CTO
Julgates \| Julien Administrateur Inscrit le : 09/03/2005	# Le 08/09/2009 à 11:48 A ca sera pas physique ? Shopping Time Network - Founder / CTO
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 08/09/2009 à 12:11 Mais tu satures vraiment le réseau Gigabit Julgates ? daevel : infogérance et conseil \|\| moi
Julgates \| Julien Administrateur Inscrit le : 09/03/2005	# Le 08/09/2009 à 12:20 Je le sature pas, je pense que c'est le switch qui est plus ou moins saturé, j'ai des latences pas possibles entre les serveurs, par exemple c'est pas rare qu'un rsync s'interrompe puis redémarre, comme si le réseau faisait une pause. Shopping Time Network - Founder / CTO
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 08/09/2009 à 12:29 Euh ouais là t'as un sérieux problème je pense. Je fais même du 400Mbps entre RBX1 et RBX2, et j'ai pas remarqué de problème, bien que ce ne soit pas un transfert permanent. daevel : infogérance et conseil \|\| moi

Auteur

Message

Bool |
Modérateur

Inscrit le : 09/05/2005

# Le 23/08/2008 à 18:50

Hello,

voici donc une procédure pour mettre en place (sur une Debian) un système de failover automatique grâce à heartbeat et l'API d'OVH.

Je vais prendre comme exemple cette infra :
La machine lilo.daevel.fr, de référence OVH "ks01234.kimsufi.com" ayant l'IP 10.0.0.1
La machine stitch.daevel.fr, de référence OVH "ns05678.ovh.net" ayant l'IP 10.100.0.2

Ainsi que deux IP "failover" : 10.200.0.3 et 10.200.0.4.

Le but étant qu'en temps normal 10.200.0.3 pointe sur la machine lilo et 10.200.0.4 pointe sur la machine stitch.
Si une des machines tombe, tout le trafic sera aiguillé sur la machine encore active.

Par contre je précise de suite :
*) utilisez cela à vos propres risques, je ne suis pas responsable des éventuels problèmes qui peuvent être générés par cette procédure et ces outils.
*) ne vous attendez pas à une tolérance aux pannes parfaite comme chez d'autres hébergeurs, le service de failover d'OVH a un temps de réactivité de 2 à 5 minutes.
*) l'API d'OVH n'indiquant pas quand une demande de bascule est en cours, si une demande contraire est faite en plein milieu Heartbeat sera quasiment à coup sûr désynchronisé... et l'IP très probablement inutilisable jusqu'à ce que vous interveniez.

Installation des paquets nécessaires, sur les deux machines :

aptitude install heartbeat php5-cgi

Oui... l'API OVH utilisant SOAP il m'a semblé plus simple d'utiliser PHP.

Configuration d'Heartbeat
(j'utilise la configuration de type v1, la v2 étant un peu beaucoup imbuvable à mon goût)

On crée les deux fichiers de configurations qui devront toujours être identiques sur les deux machines.

OLD_UMASK=`umask` ; umask 027 ;\

cat /usr/share/doc/heartbeat/authkeys > /etc/ha.d/authkeys ;\

cat >> /etc/ha.d/authkeys <<EOF

auth 1

1 sha1 UN-LONG-MOT-DE-PASSE-COMPLIQUE

EOF



umask $OLD_UMASK ; zcat /usr/share/doc/heartbeat/haresources.gz > /etc/haresources ;\

cat >> /etc/haresources <<EOF

lilo.daevel.fr ipFailoverOVH::10.200.0.3 10.200.0.3/32

stitch.daevel.fr ipFailoverOVH::10.200.0.4 10.200.0.4/32

EOF

Pensez évidement à adapter le contenu de ces deux fichiers (pour générer un mot de passe alléatoire, vous pouvez faire un makepasswd --chars=16 après avoir installé le paquet makepasswd).

Il faut ensuite créer le fichier de configuration spécifique à la machine. On commence par prendre le modèle :

zcat /usr/share/doc/heartbeat/ha.cf.gz > /etc/ha.d/ha.cf

Attention l'ordre des paramètres dans ce fichier est très important donc décommentez les instructions présentes, ne les ajoutez pas à la fin.

Dans ce fichier vous pouvez par exemple décommenter ces valeurs :

keepalive 2

deadtime 30

warntime 10

initdead 120

udpport        694

Il faut surtout penser à décommenter la ligne "ucast" pour indiquer l'ip de l'autre machine.
Donc sur lilo on aurait :

ucast eth0 10.100.0.2

et sur stitch :

ucast eth0 10.0.0.2

Vous pouvez également pinger régulièrement les routeurs de ces machines au cas où ils rencontreraient un problème (pour vérifier l'adresse du routeur, faites un ip route show). Pour cela décommenter les lignes "ping" comme cela :
Sur lilo :

ping 10.0.0.254

et sur stitch :

ping 10.100.0.254

Puis décommentez/modifiez la ligne :

deadping 30

Ajout du script pour l'API OVH ( http://daevel.fr/ipFailoverOVH.txt

)

DEST=/etc/ha.d/resource.d/ipFailoverOVH ;\

wget -O $DEST http://daevel.fr/ipFailoverOVH.txt  ;\

chmod +x $DEST ; ln -s $DEST /usr/local/sbin/

Ainsi le script est également utilisable via SSH.

Configuration du script
Création du fichier de configuration par défaut :

OLD_UMASK=`umask` ; umask 027 ;\

cat > /etc/ha.d/ovhConfig <<EOF

[global]

login=XX1234-OVH

pass=XXXXXXX

EOF



umask $OLD_UMASK ; chown root.haclient /etc/ha.d/ovhConfig

Si vous avez modifié l'hostname de votre machine, il faut l'indiquer dans le fichier de configuration. Dans notre infra d'exemple il faut ajouter :

[alias]

lilo.daevel.fr=ks01234.kimsufi.com

stitch.daevel.fr=ns05678.ovh.net

De même si vous avez plusieurs interfaces réseau sur vos machines, il faut indiquer sur quelle interface/IP l'IP failover doit être attribuée :

[10.200.0.3]

lilo.daevel.fr=10.0.0.1

stitch.daevel.fr=10.100.0.2



[10.200.0.4]

lilo.daevel.fr=10.0.0.1

stitch.daevel.fr=10.100.0.2

Pour vérifier que l'API fonctionne, essayez via SSH :

$ ipFailoverOVH 10.200.0.3 status
10.200.0.3 is routed on lilo.daevel.fr/10.0.0.1

Vous pouvez également utiliser le nom correspond au reverse de l'IP :

$ ipFailoverOVH failover1.daevel.fr status
10.200.0.4 is routed on lilo.daevel.fr/10.0.0.1

Une fois que tout fonctionne un /etc/init.d/heartbeat restart sera nécessaire pour activer tout cela.

PS : bien sûr si vous avez des suggestions quant à l'amélioration du script, je suis preneur !

daevel : infogérance et conseil || moi

MathieuC | Mathieu
Modérateur

Inscrit le : 15/07/2005

# Le 24/08/2008 à 16:14

Comme la tres grosse majorite des tuto technique, c'est totalement imbuvale pour quelqu'un qui ne connait pas deja les outils, c'est dommage.

Il faudrait expliquer comment fonctionne le script, ce qui se passe et le but des commandes, pour que quelqu'un qui ne connaisse pas ce qu'est "failover", "heartbeat" et "API d'OVH" puisse au moins comprendre l'utilite et le fonctionnement de ce que tu presente et ainsi decider si ca peut lui etre utile.

Sinon l'idée est bonne, mais moi j'aime pas les IP failover car elles mettent trop de temps a bouger, et pendant qu'une modification de pointage est en cours, on est dans le noir le plus complet, on a aucune info de la part d'OVH

darkham | Adrien
Membre

Inscrit le : 11/05/2005

# Le 24/08/2008 à 16:39

Je ne trouve pas cela imbuvable perso, mais parcontre il est vrai que je ne suis pas chaud avec les ip failover !!!!

Widoox : http://www.widoox.fr

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 24/08/2008 à 17:29

Tu as raison Mathieu, le but était d'indiquer une procédure plutôt que d'expliquer l'intérêt de tout cela.

Donc si je reprends dans l'ordre : le but ici est de mettre en place une tolérance aux pannes ("failover"), et uniquement cela.
C'est à dire que lorsque le serveur tombe en panne les visiteurs sont envoyés automatiquement vers un serveur de secours.

Et c'est bien à quoi servent ces IP : la bascule ne doit être qu'occasionnelle, ce n'est certainement pas à utiliser pour faire de la répartition de charge.

Heartbeat quant à lui est un outil qui permet à deux serveurs de se surveiller mutuellement afin de détecter un éventuel problème et d'agir en conséquence.
Chez un hébergeur classique par exemple dès qu'Heartbeat détecte un problème (sous 2 secondes souvent), il s'attribue l'IP de l'autre serveur et ainsi il n'y a quasiment pas d'interruption de service. Le soucis dans notre cas c'est qu'OVH ne permet pas ce genre de choses et on est obligés d'avoir recours à leur service "ip failover".

C'est donc là qu'intervient l'API d'OVH : elle permet plus ou moins d'automatiser cette bascule d'IP d'une machine à une autre, avec toutefois un délai de plusieurs minutes.
Réduire la panne à 5 minutes au lieu de plusieurs heures/jours, c'est déjà un très bon point je trouve.

Et si cela est vraiment problématique je vois deux solutions :
1) ne pas passer par un hébergeur discount, voir mieux passer par un hébergeur qui propose des services de tolérance aux pannes dans ses services.
2) mettre en place dans une baie OVH des frontaux qui n'auront ainsi pas besoin d'utiliser le service "ip failover" d'OVH ; quitte à ce que les serveurs derrière soient des dédiés en location.

=========

Pour ce qui est du script en lui même, son rôle est surtout d'interfacer Heartbeat avec l'API d'OVH : heartbeat fait référence aux machines en utilisant leur nom tandis que l'API OVH utilise la codification interne d'ovh. De même l'affectation est faite par heartbeat en fonction de l'interface (eth0/eth1) tandis que l'API OVH demande l'IP principale de l'interface en question.

Sinon il y a 3 cas :
/etc/ha.d/resources.d/ipFailoverOVH 10.200.0.3 start
Heartbeat indique ici que la machine courante chercher à prendre l'IP failover "10.200.0.3". Le script se charge donc de répercuter la demande via l'API.
Le hic c'est que l'API génère une erreur si l'IP est déjà affectée au serveur indiqué.
Le script va donc d'abord interroger OVH pour savoir si l'IP est déjà affectée ou non ; mais comme tu l'as souligné on a aucun moyen de connaitre l'état "intermédiaire" (c'est à dire qu'une demande est en déjà cours). Donc il se peut que le script se trompe et ignore la demande.

/etc/ha.d/resources.d/ipFailoverOVH 10.200.0.3 stop
Heartbeat indique ici que la machine va libérer l'IP. A cette étape le script ne fait rien, mais idéallement elle devrait refuser la demande tant que l'IP n'est pas effectivement basculée sur l'autre serveur.

/etc/ha.d/resources.d/ipFailoverOVH 10.200.0.3 status
Heartbeat cherche à savoir si l'IP a bien été basculée vers le serveur courant ; si ce n'est pas le cas il va libérer l'IP.
Ici le script fait effectivement la demande auprès d'OVH mais ne retourne pas le résultat à Heartbeat : le temps de réactivité du système OVH est beaucoup trop lent et Heartbeat abandonne bien avant que l'IP soit correctement basculée.

(la communication avec Heartbeat se fait uniquement en fonction du code de retour : 0 = OK, toute autre valeur = ERREUR)

=========

Il y a donc pas mal de limitations à ce système mais je n'ai pas trouvé mieux pour le moment avec les outils "classiques" (Heartbeat et KeepAlived principalement).

Une autre solution serait de développer une solution spécifique au mécanisme de failover d'OVH. Cela ferait fortement réinventer la roue, mais l'ordonnancement étant plus adapté réduirait voir supprimerait l'impact du temps de bascule.

daevel : infogérance et conseil || moi

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 24/08/2008 à 18:54

Je viens de faire une série d'autres tests, et ce n'est pas génial :
- heartbeat veut que le "stop" fonctionne. Et même s'il ne fonctionne pas, il dégage l'IP donc l'effet est le même.
- l'interface OVH se vautre de temps à autre : outre la session qui expire durant l'exécution du script, j'ai aussi eu le droit à la destruction/reconstruction de mon IP failover à la volée.... j'ai même reçu le mail d'OVH pour confirmer la création.

Bref je crois qu'il va falloir se passer d'Heartbeat et développer un truc 100% maison qui tienne également compte du failover OVH.

daevel : infogérance et conseil || moi

MultiNetWorks | Damien
Membre

Inscrit le : 13/05/2005

# Le 24/08/2008 à 20:29

Il y a une classe à la fin de la discussion pour faire le changement d'IpFailOver :
http://forum.ovh.com/archive/index.php/t-16659.htm...

Damien...

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 24/08/2008 à 20:53

Bah la classe ne sert plus à rien, vu qu'il y a maintenant une API pour faire ça.
Le soucis c'est le "reste" justement.

daevel : infogérance et conseil || moi

flush | Jean-Philippe
Modérateur

Inscrit le : 09/05/2005

# Le 24/08/2008 à 21:03

Bool > un petit script php avec un file('http://')

qui récupère un hash

Le tout lancé dans un cron toutes les minutes ...

Vu le fail over qui est très long ... on est plus à 30 secondes près de perdu !

@+ Jean-Philippe

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 24/08/2008 à 21:34

Oui c'est sûr, mais ça ne fait qu'un seul contrôle.

Le problème c'est que si le cron tourne sur les machines elles même, on a aucune vérification du réseau. Et si le script est centralisé sur une autre machine, on devient dépendant de celle ci.
Ce n'est pas pour rien qu'il y a des outils plus élaborés comme heartbeat.

Mais oui comme je disais, plus ça va et plus je pense qu'un script maison serait plus adapté.

daevel : infogérance et conseil || moi

abravanel666 | Sylvain
Modérateur

Inscrit le : 19/07/2009

# Le 08/09/2009 à 11:21

Hello

Je suis en train de mettre en place du failover sur mes 2 serveurs
Y a t'il eu une conclusion sur le sujet ?

http://www.magasins-usine.info http://www.shoppingactu.com

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 08/09/2009 à 11:31

L'offre VLAN devrait bientôt sortir, et ainsi permettre l'utilisation de "vraies" solutions de failover.

daevel : infogérance et conseil || moi

Julgates | Julien
Administrateur

Inscrit le : 09/03/2005

# Le 08/09/2009 à 11:32

Bah ca serait pas trop tot, car la le débit entre les machines est horrible.

Shopping Time Network - Founder / CTO

Julgates | Julien
Administrateur

Inscrit le : 09/03/2005

# Le 08/09/2009 à 11:48

A ca sera pas physique ?

Shopping Time Network - Founder / CTO

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 08/09/2009 à 12:11

Mais tu satures vraiment le réseau Gigabit Julgates ?

daevel : infogérance et conseil || moi

Julgates | Julien
Administrateur

Inscrit le : 09/03/2005

# Le 08/09/2009 à 12:20

Je le sature pas, je pense que c'est le switch qui est plus ou moins saturé, j'ai des latences pas possibles entre les serveurs, par exemple c'est pas rare qu'un rsync s'interrompe puis redémarre, comme si le réseau faisait une pause.

Shopping Time Network - Founder / CTO

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 08/09/2009 à 12:29

Euh ouais là t'as un sérieux problème je pense. Je fais même du 400Mbps entre RBX1 et RBX2, et j'ai pas remarqué de problème, bien que ce ne soit pas un transfert permanent.

daevel : infogérance et conseil || moi

Répondre

Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.