Cluster Haute-Disponibilité chez OVH, avec IpFailover, Heartbeat et DRBD via IPSEC

Ayant récemment commandé 2 serveurs dédiés chez OVH (des EG Best-of pour les curieux dont vous trouverez le détail ICI ), dans le but d’en faire un cluster Haute-disponibilité, voici un « petit » tuto et retour d’expérience.

 

Les configs qui suivent sont spécifiques à OVH pour la partie IP FailOver (ip load balancée) et la compilation du noyau pour DRBD mais le reste peut s’adapter à d’autres hébergeurs bien sûr (i.e Dedibox par exemple).

 

Je ne rentrerais pas dans le troll de pourquoi OVH et pas Dédibox, mais j’ai un « gros » faible pour OVH qui avec son Directeur Général des plus actifs, présent sur les forums (Octave Klaba aka Oles, le fils d’Henryk, le fondateur d’OVH (un chti lien), voila pour la partie People), une communauté de passionnés et des services hallucinant ont naturellement fait que je les préfère à son « concurrent » direct. Bref, je suis et connais OVH depuis sa « naissance » et ils ont prouvés depuis longtemps leur statut. Les agitateurs de l’hébergement c’est eux comme Free pour les FAI, mais cela reste ma propre opinion 🙂 , et puis tout le monde a ses défauts 🙁

 

Donc suite a l’acquisition de ses 2 serveurs, voici les contraintes que je me suis imposées :

 

• IP virtuelle basculable d’un serveur à l’autre
• Partition synchronisée en temps réel et utilisable par simple bascule sur un serveur ou sur l’autre
• Interruption de service < 300 secondes
• Automatisation de la bascule
• Cryptage des flux réseaux entre les 2 serveurs
• Alerte par Texto + Mail sur mon téléphone portable en cas de bascule

Bien évidemment, les surveillances Nagios des 2 serveurs ne seront pas évoqués ici, c’est de la routine 😉 (en mode nsca crypté hein 😀 )

 

Je partirai du principe que mes serveurs s’appellent ns11111 et ns22222 (nsxxxx.ovh.net étant le hostname par défaut des serveurs d’OVH, a changer bien entendu rapidement et positionner un reverse également).

On va considérer que ns11111 a l’ip 192.168..20.20 et ns22222 192.168.20.30 (c’est juste pour l’exemple hein, je vais pas mettre d’ip publiques dans le tuto 😉 vous changer par l’ip publique principale de votre serveur = eth0

On est parti, phase 1.

 

• Configuration d’un tunnel VPN IPSEC en mode transport

Pour que les échanges d’information réseau entre les deux serveurs dédiés soient un minimum sécurisé (comprendre difficilement « sniffable »), j’ai décider de monter un tunnel VPN en IPSEC entre les deux.

Les serveurs sont sous Debian Etch. (vous adapter si vous avez un autre OS)

IPSEC autorise 2 modes de communication le mode tunnel (1 serveur/réseau vers 1 réseau) et le mode Transport (1 serveur vers 1 serveur) (en résumé hein, venez pas me saouler avec mon simplicisme 😉 )

Donc le mode transport.

apt-get install ipsec-tools

 

on se configure le /etc/ipsec-tools.conf sur les deux serveurs.

ns11111 :

 

#!/usr/sbin/setkey -f 

flush;

spdflush;

# AH

add 192.168.20.30 192.168.20.20 ah 15700 -A hmac-md5 "1234567890123456";

add 192.168.20.20 192.168.20.30 ah 24500 -A hmac-md5 "1234567890123456";

# ESP

add 192.168.20.30 192.168.20.20 esp 15701 -E 3des-cbc "123456789012123456789012";

add 192.168.20.20 192.168.20.30 esp 24501 -E 3des-cbc "123456789012123456789012";

spdadd 192.168.20.20 192.168.20.30 any -P out ipsec

           esp/transport//require

           ah/transport//require;

spdadd 192.168.20.30 192.168.20.20 any -P in ipsec

           esp/transport//require

           ah/transport//require;

ns22222 :

#!/usr/sbin/setkey -f 

flush;

spdflush;

# AH

add 192.168.20.30 192.168.20.20 ah 15700 -A hmac-md5 "1234567890123456";

add 192.168.20.20 192.168.20.30 ah 24500 -A hmac-md5 "1234567890123456";

# ESP

add 192.168.20.30 192.168.20.20 esp 15701 -E 3des-cbc "123456789012123456789012";

add 192.168.20.20 192.168.20.30 esp 24501 -E 3des-cbc "123456789012123456789012";

spdadd 192.168.20.30 192.168.20.20 any -P out ipsec

        esp/transport//require

 ah/transport//require;

spdadd 192.168.20.20 192.168.20.30 any -P in ipsec

           esp/transport//require

           ah/transport//require;

Vous remarquerez que les changements portent sur les sens de trafic.

Bien évidemment, vous changez les clés (32 octets hexadecimaux, et 48 pour les clés 3des-cbc), générable faisable facilement par un :

 

hexdump -e ‘8/2 “%04x” ‘ /dev/urandom -n 16; echo (pour les 32 caractères)

hexdump -e ‘8/2 “%04x” ‘ /dev/urandom -n 24; echo (pour 48)

 

Exemple :

hexdump -e ‘8/2 « %04x » ‘ /dev/urandom -n 16; echo
6e99170129b4bc1b774161f0c7ecf50f

la clé = 0x6e99170129b4bc1b774161f0c7ecf50f (sans les guillemets).

 

Un ping vers l’autre serveur et un tcpdump vous démontreront le cryptage effectif :

 

# tcpdump -n "host 192.168.20.30"

01:23:27.996891 IP 192.168.20.20 > 192.168.20.30: AH(spi=0x00000302,seq=0x1): ESP(spi=0x00000303,seq=0x1), length 88

01:23:27.998282 IP 192.168.20.30 > 192.168.20.20: AH(spi=0x00000202,seq=0x277ac2): ESP(spi=0x00000203,seq=0x277ac2), length 88

01:23:28.999853 IP 192.168.20.20 > 192.168.20.30: AH(spi=0x00000302,seq=0x2): ESP(spi=0x00000303,seq=0x2), length 88

01:23:29.001726 IP 192.168.20.30 > 192.168.20.20: AH(spi=0x00000202,seq=0x277ac3): ESP(spi=0x00000203,seq=0x277ac3), length 88

4 packets captured

15653 packets received by filter

0 packets dropped by kernel

 

Un petit Mémo Ipsec ICI.

 

Comme nous ne faisons que du 1 pour 1, inutile de se fatiguer à installer une gestion des clés (type isakmpd ou Racoon).

 

NB : Pour sécuriser tout cela, vous peaufiner votre Iptables pour n’accepter que du trafic Ipsec entre les deux serveurs.

 

• DRBD

Pour ceux qui ne connaissent pas DRBD, il s’agit en résumé d’un RAID 1 sur IP. Comprendre une synchronisation de deux partitions via le réseau en mode bloc.

 

 

Je vous invite à consulter l’excellent site www.drbd.org pour en savoir plus.

 

Le noyau par défaut des serveurs OVH n’inclus pas le support des modules. Il faut donc le recompiler et également ajouter le driver Connector.

 

– Récupérer les sources du Kernel

cd /usr/src/
wget ftp://ftp.ovh.net/made-in-ovh/bzImage/linux-2.6.24.5-ovh.tar.bz2
tar -jxvf linux-2.6.24.5-ovh.tar.bz2
ln -s linux-2.6.24.5-ovh linux

– Récuperer le .config standard

wget ftp://ftp.ovh.net/made-in-ovh/bzImage/2.6-config-xxxx-std-ipv4-32
cp 2.6-config-xxxx-std-ipv4-32 linux/.config
cd linux

– Recompiler le noyau

make menuconfig (ou votre méthode préférée).

Activer le support des modules :
« Enable loadable module support » -> « Module unloading » et « Automatic kernel module loading »

Activer le kernel userspace connector:

Device Drivers —> Connector – unified userspace <-> kernelspace linker

make
make modules_install
cp arch/i386/bzimage /boot/vmlinux-2.6.24.5-xxxx-std-ipv4-32
cp Sytem.map /boot/System.map-2.6.24.5-xxxx-std-ipv4-32

Editer lilo.conf ou menu.lst de Grub pour pointer sur le bon kernel.

lilo -v -v ou grub-install hd0

Rebooter.

– DRBD

wget http://oss.linbit.com/drbd/8.0/drbd-8.0.13.tar.gz
tar xzvf drbd-8.0.13.tar.gz
cd drbd-8.0.13
cd drbd
make
cd ..
make tools
make install
make install-tools

Editer votre /etc/drbd.conf

 

(A adapter à votre configuration bien sur) :

#
# drbd.conf
#
global {
usage-count yes;
}

common {
syncer { rate 20M; }
}

resource r0 {

protocol C;

handlers {
pri-on-incon-degr « echo o > /proc/sysrq-trigger ; halt -f »;
pri-lost-after-sb « echo o > /proc/sysrq-trigger ; halt -f »;
local-io-error « echo o > /proc/sysrq-trigger ; halt -f »;
outdate-peer « /usr/lib/heartbeat/drbd-peer-outdater -t 5 »;
}

startup {
degr-wfc-timeout 120; # 2 minutes.
}

disk {
on-io-error detach;
}

net {
after-sb-1pri disconnect;
after-sb-2pri disconnect;
rr-conflict disconnect;
}

syncer {
rate 20M;
al-extents 257;
}

on ns11111 {
device /dev/drbd0;
disk /dev/sda10;
address 192.168.20.20:7788;
meta-disk internal;
}

on ns22222 {
device /dev/drbd0;
disk /dev/sda10;
address 192.168.20.30:7788;
meta-disk internal;
}
}

 

NB: Vous verrouillez le port 7788 dans Iptables bien sûr…

(en cas de soucis avec une partition prélablement créée, il suffit de passer un : dd if=/dev/zero bs=1M count=1 of=/dev/sdaX; sync )

A faire sur chacun des noeuds :

drbdadm create-md r0
modprobe drbd
drbdadm attach r0
drbdadm connect r0
cat /proc/drbd

/etc/init.d/drbd start
Sur le serveur primaire : drbdadm — –overwrite-data-of-peer primary r0
Pour suivre la synchro initiale :

cat /proc/drbd
Vous pouvez formater la partition :

mkfs.ext3 /dev/drbd0

 

Je vous invite à consulter Google pour pousser plus en avant votre compréhension de DRBD.

 

• Heartbeat

 

Heartbeat est un système de prise de pouls pour un cluster (définition détaillée ICI).

Il se charge de surveiller son « confrère » et d’executer certains commandes pré-définis en cas de perte de l’un des noeuds.

Sur les 2 serveurs :

apt-get install heartbeat

 

Créer le fichier /etc/ha.d/ha.cf :

 

ucast eth0 192.168.20.30 (pour ns11111, 192.168.20.20 pour ns22222)
debugfile /var/log/ha-debug
logfile /var/log/ha-log
logfacility local0
# Délai entre deux battements de pouls
keepalive 2
# Temps nécessaire avant de considérer un noeud comme mort
deadtime 30
# délai avant d'envoyer un avertissement pour les pouls en retard
warntime 6
# deadtime spécifique pour les conf ou le reseau met du temps a démarrer
initdead 60
# port a utiliser pour la prise de pouls
udpport 694
# uname -n pour connaitre le nom des serveurs
node ns11111.ovh.net
node ns22222.ovh.net
# met la valeur on, pour master auto
auto_failback off

 

Créer le fichier /etc/ha.d/authkeys :

 

auth 1
1 md5 "supermotdepasse"
2 crc

chmod 600 /etc/ha.d/authkeys

 

La partie la plus importante maintenant, les scripts à lancer :

 

/etc/ha.d/haresources :

ns11111.ovh.net IPaddrFO::10.10.10.10/32/eth0 drbddisk::r0 Filesystem::/dev/drbd0::/data::ext3

 

Petite explication sur cette ligne :

On spécifie tout d’abord le noeud Maître, ici ns11111.

Puis on utilise le script IPaddrFO (on va voir cela après) pour monter l’adresse IP 10.10.10.10 en masque 255.255.255.255 sur eth0

 

Puis on définie le DRBD comme Primaire et on monte la partition DRBD dans /data en type ext3.

 

Si le Maitre (ns11111) tombe, alors ns2222 devient le nouveau maitre et récupère l’adresse IP et la partition.

 

IPaddrFO est en fait une copie de /etc/ha.d/ressource.d/IPaddr que j’ai un peu modifier… (on voit cela plus bas).

 

• IPFailOver

 

Chez OVH, vous avez la possibilité de disposer d’ips « failover ». Explication ICI.

 

L’ipfailover est routée sur l’un ou l’autre des serveurs selon votre choix dans le « Manager », l’interface d’administration de votre compte OVH.

 

J’ai donc tout d’abord demander une IP failover pour mon serveur ns11111.ovh.net. Cette IP est 10.10.10.10 dans mon exemple.

Elle est routée sur 192.168.20.20.

 

Et là vous me dites « ahan mais c’est nul, t’es obligé d’aller dans ton interface pour affecter la nouvelle redirection, SAPU !!! Je vais pas faire ça a la main moi !!! »

 

Et ben non, jeune Padawan, on vas automatiser tout cela grace à…. SOAP.

 

Car OVH propose des API SOAP pour attaquer directement l’interface via un script perl, php, C ou python… Fort non ?

 

Le site est ici : http://www.ovh.com/soapi/fr/

 

Perso, j’ai choisi Python. Parce que Pyhon, SAYBIEN et pis c’est tout.

 

On a juste besoin de Python (dingue non ?) et de soappy suur les serveurs.

 

apt-get install python-soappy python

 

Le script que j’utilise :

 

ns11111-failoverupdate.py :

#!/usr/bin/python

from SOAPpy import WSDL

soap = WSDL.Proxy('https://www.ovh.com/soapi/ovh.wsdl')

#login
nic = 'monlogin-ovh'
password = 'xxxxxxx'

try:
 session = soap.login( nic, password )
 print "login successfull"
except:
 print "Error login"

#dedicatedFailoverUpdate
try:
 result = soap.dedicatedFailoverUpdate( session, 'ns11111.ovh.net', '10.10.10.10', '192.168.20.20' );
 print "dedicatedFailoverUpdate successfull";
 # your code here ...
except:
 print "Error dedicatedFailoverUpdate"

#logout
try:
 result = soap.logout( session )
 print "logout successfull"
except:
 print "Error logout"

 

ns22222-failoverupdate.py :

#!/usr/bin/python

from SOAPpy import WSDL

soap = WSDL.Proxy('https://www.ovh.com/soapi/ovh.wsdl')

#login
nic = 'monlogin-ovh'
password = 'xxxxx'

try:
 session = soap.login( nic, password )
 print "login successfull"
except:
 print "Error login"

#dedicatedFailoverUpdate
try:
 result = soap.dedicatedFailoverUpdate( session, 'ns11111.ovh.net', '10.10.10.10', '192.168.20.30' );
 print "dedicatedFailoverUpdate successfull";
 # your code here ...
except:
 print "Error dedicatedFailoverUpdate"

#logout
try:
 result = soap.logout( session )
 print "logout successfull"
except:
 print "Error logout"

 

Explication sur la ligne « soap.dedicatedFailoverUpdate » :

Le premier champ correspond au hostname OVH sur serveur sur lequel vous avez pris (comprendre commander) votre ip failover. Ici ns11111.ovh.net

Ensuite l’ip failover elle même.

Puis l’ip sur laquelle router la failover .

 

Facile non ?

 

On se modifie notre script /etc/ha.d/ressource.d/IPaddrFO (copie de IPaddr) :

A la fin :

case $2 in
  start)        /etc/ha.d/ns11111-failoverupdate.py
                ip_start $1;;
  stop)         /etc/ha.d/ns22222-failoverupdate.py
                ip_stop $1;;
  status)       ip_status $1;;
  monitor)      ip_monitor $1;;
  *)            usage
                exit 1
                ;;
esac

 

Vous inverser les scripts sur ns2222 bien sûr…

 

Vous pouvez maintenant lancer heartbeat sur ns1111 puis sur ns2222 et vous devriez voir les annonces défilaient dans le syslog et l’ipfailover monté sur ns11111 ainsi que le partition /data en DRBD.

 

Un reboot de ns11111 et l’ip failover bascule sur ns22222, la partition /data en DRBD monte et le script python force l’update du failover sur l’interface OVH.

 

Après de multiples tests, le plus long est cette mise à jour dans l’interface, dans l’ensemble les 2 serveurs mettent quelques secondes à basculer mais la mise à jour prend entre 60 et 90 secondes.

 

Ce qui entraine une indispo maximum d’1 minute 30. Ca va encore hein 😀

 

Dernière chose, l’alerte SMS 🙂

 

Alors là, je me suis pas foulé 😀 , autant utiliser les services de nos opérateurs de téléphonie mobile.

 

Etant chez SFR, je peux me créer une BAL type @sfr.fr consultable sur leur Webmail : http://sfr-messagerie.fr

 

Le petit plus de cette BAL c’est que lorsque vous recevez un email sur cette adresse, vous recevez un texto sur votre mobile avec le sujet du mail 😀

 

Il n’en faut pas plus pour être alerté par SMS en temps quasi réel.

 

On ajoute une entrée dans le /etc/ha.d/haresources (sur les deux serveurs) :

 

ns11111.ovh.net IPaddrFO::10.10.10.10/32/eth0 drbddisk::r0 Filesystem::/dev/drbd0::/data::ext3 MailTo::monadresse@sfr.fr::Alerte_Bascule

 

De plus, OVH vous envoie un email quand vous forcer l’update de l’ipfailover, si avec tout ca, vous n’etes pas informé que votre cluster à basculer…

 

Petite précision, dans ma configuration, j’empeche le serveur ns11111 de redevenir Maître automatiquement quand il revient (en cas de soucis électrique ou reboot en boucle par exemple), c’est a vous de vérifier que tout va bien sur ns1111 et de lancer un simple « /etc/init.d/heartbeat restart » sur ns22222 pour que les noeuds repassent en mode master/slave comme à l’origine.

 

Voila, une petite architecture poilue comme je l’aime 🙂

 

En espérant vous avoir apporter des idées et vous donner envie de découvrir Heartbeat et DRBD, car bien sur, dans mon exemple, je ne parle pas des relances de services type Mysql ou Apache en mode « cluster » 😉

 

EDIT : Suite aux différents tests via Ipsec, je vous conseille fortement d’utiliser l’algo AES plutot que 3DES pour l’ESP. Donc profiter la recompilation de votre noyau pour inclure le support crypto AES (désactivé par défaut dans la config OVH) et modifier vos conf ipsec-tools.conf ainsi :

add 192.168.20.30 192.168.20.20 esp 15701 -E rijndael-cbc "123456789012123456789012";