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

par guiguiabloc le 17.oct, 2008, sous architecture, linux

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é = 0×6e99170129b4bc1b774161f0c7ecf50f (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";

:debian, drbd, heartbeat, ipfailover, ipsec, ovh, sms, soap, soapi, texto, vpn

42 commentaires pour ce billet:

Superkikim
octobre 31st, 2008 le 20:46
Salut Guigui

Géniaux, tes articles, merci Manque de détails pour un noob en linux comme moi.

Pourrais-je profiter de tes lumières par MSN ou par email ?
guiguiabloc
octobre 31st, 2008 le 22:46
merci
msn c’est quoi ?
Mon email est simple a trouver, il est dans mon profil sur les forums ovh :-p
sinon mon pseudo chez free.fr
Superkikim
novembre 3rd, 2008 le 10:29
Bah, MSN, Yahoo, AIM, Skype, Ce que tu veux C’est n’égal

Pour l’instant, tout (ou presque) est en place …

Dis, puisque tu conseilles d’utiliser AES au lieu de 3DES, tu veux pas corriger l’article ? Parce que là, on fait tout, et on le voit quand on arrive en bas

Au fait, quels problèmes as-tu constaté avec 3DES ?
guiguiabloc
novembre 3rd, 2008 le 14:56
nan

Comme cela, cela force à lire tout l’article.

Problèmes de perfs réseau essentiellement (AES est plus rapide que 3DES).
Superkikim
novembre 6th, 2008 le 3:03
Attention avec les script failoverupdate.

Le nom du host ne doit pas être le nom du serveur sur lequel on a commandé l’IP failover, mais bien celui sur lequel elle est actuellement routée.

Donc dans le script ns11111 il faut mettre ns22222, et sur le script ns22222 il faut mettre ns11111.

result = soap.dedicatedFailoverUpdate( session, ‘ns22222.ovh.net’, ‘123.123.123.123′, ‘134.123.212.108′ );

Ici, extrait du script ns11111-failoverupdate.py:

l’ip failover 123.123.123.123, actuellement assignée à ns22222 doit basculer sur le host qui a l’IP 134.123.212.108
guiguiabloc
novembre 6th, 2008 le 9:16
Pas d’accord avec toi.

la variable hostname correspond au nom du serveur sur lequel est attachée “Administrativement” l’ip failvover.

Preuve en est les mails reçus par OVH a chaque bascule :
“Allocation d’IP fail-over sur ns11111.ovh.net. Bonjour,

Vous avez souscrit à notre offre d’IP fail-over sur votre
serveur dédié ns11111.ovh.net.
Nous vous informons que ce service est désormais actif.

Nous avons alloué l’IP 123.123.123.123 qui est routée sur 134.123.212.108″

Qui plus est, j’ai réalisé plus de 50 bascules dans tout les sens et avec un fonctionnement exact a 100%.

Pour être en prod avec ce script qui fonctionne parfaitement, je ne toucherais surement a rien
Superkikim
novembre 6th, 2008 le 16:08
Etonnant. Dans mon cas, les scripts fonctionnent également. Peut-être que l’indication “hostname” n’a pas d’importance.

Je ferai encore des tests pour en être sûr
Superkikim
novembre 19th, 2008 le 3:30
Bon ben là je resèche

J’ai essayé un kill
J’ai essayé un heartbeat stop sur le node primaire.

Dans les deux cas, ma resource DRBD ne remonte pas sur le second noeud.

Tout ce qu’il se passe sur le node #2 quand je fais un heartbeat stop et ensuite un heartbeat start sur le node #1, c’est ça:

Nov 19 02:49:01 ns365871 kernel: drbd0: peer( Primary -> Secondary )
Nov 19 02:55:58 ns365871 kernel: drbd0: peer( Secondary -> Primary )

C’est bien. Le node 2 est averti Mais ça me fait une belle jambe.

Mon fichier haresources contient simplement:

ns365869.ovh.net drbddisk::r0 Filesystem::dev drbd0:: vms::ext3

Bien entendu les infos sont justes, et drbd fonctionne très bien. Quant à mon fichier ha.cf, il est basé sur ton article.

Aurais-tu une piste à me suggérer ?

Bon. J’ai enlevé tous les slashs pour pouvoir poster
guiguiabloc
novembre 19th, 2008 le 8:52
le haresources doit contenir :

ns365871.ovh.net drbddisk::r0 Filesystem::/dev/drbd0::/vms::ext3

sur les 2 nodes. (si c’est bien ns365869.ovh.net qui est le noeud esclave).

Au pire pastbin tes confs drbd.conf, ha.cf et haresources
Superkikim
novembre 19th, 2008 le 11:08
Non non c’est bien l’autre le maitre. Ce que je montre, c’est le syslog du esclave. En fait, le syslog du esclave remonte un message comme quoi sur le “peer”, donc sur le maitre en l’occurence, drbd0 passe en secondary. C’est là que le bât blesse… Il passe bien en secondary sur le maitre, mais ne remonte pas en primary sur l’esclave…. Rraaaaah… M’énerve
Bon ben je creuse, je creuse… Je vais finir mineur, ou fossoyeur, à force de creuser :-p
Superkikim
novembre 19th, 2008 le 17:25
EUREKA J’AI TROUVE !!!

C’était le port udp 694 qui passait pas !!! Un petit iptables -A INPUT -s ippeer -p udp –dport 694 -j ACCEPT et le tour est joué !
guiguiabloc
novembre 19th, 2008 le 17:27
lol
Superkikim
novembre 19th, 2008 le 20:22
OUais bof. Pas lol. Ca marche toujours pas :-p
Superkikim
novembre 23rd, 2008 le 0:23
Petite erreur dans ton article:

“ucast eth0 192.168.20.20 (pour ns11111, 192.168.20.30 pour ns22222)”

C’est l’inverse. Dans la config de ns11111, il faut mettre ucast eth0 192.168.20.30 et dans la config de ns22222 il faut mettre ucast eth0 192.168.20.20

Il s’agit de l’IP vers laquelle tu veux envoyer l’ucast.
guiguiabloc
novembre 25th, 2008 le 9:33
exact, je me suis mal exprimé “pour interroger ns1111″ était plutot ce que je voulais dire.
Je corrige.
Crazysky
décembre 1st, 2008 le 14:47
Merci pour ce tutoriel !
J’ai pu installer vmware server 2 sans encombre sur un Kimsufi de base.

Il y a quelques erreurs de frappe à certain endroit, donc avis aux débutants de faire attention =)

Seul petite critique, manque les infos pour lilo.conf ; c’est bête mais le tuto permet au premier venue de compiler sans soucis mais il manque juste une partie assez importante (surtout dans le cas d’un kimsufi qui n’utilise pas la version std du noyaux.)
guiguiabloc
décembre 1st, 2008 le 22:38
De rien

Pas de soucis, c’est fait a l’arrache et justement fait pour que le “débutant” cherche un peu par lui même.

Je ne peaufine volontairement pas les trucs de base comme le lilo.conf, il y assez de tutos sur le net pour apprendre les bases d’un système linux et ce n’est pas le but de ce blog de réinventer la roue.
Ne nous méprenons pas, je n’écris pas des billets clés en main, ou serait le plaisir de la découverte sinon ?… Comme je le dis toujours, je préfère que les gens recherchent les petites briques manquantes que de fournir un mode d’emploi “vas-y copie/colle” je n’y vois aucun intéret de progression personnelle pour le lecteur
Si un de mes billets pousse le lecteur a chercher a adapter le concept et a le comprendre, ok, si c’est juste une FAQ/tutos/mode d’emploi, désolé, je ne ferais pas, cela devient de l’assistanat de base qui ne feront surement rien apprendre

Mais je note quand même la critique
Superkikim
décembre 17th, 2008 le 1:18
Hello toi….

Kikim content. Kikim avance (à petit pas). J’ai implémenté Heartbeat 2 avec Pacemaker 1. Et pour l’instant… ben… J’ai réussi à faire le faileover DRBD avec le mount. C’est pas grand chose. La galère va être de se lancer dans le management des machines vmware….

Je vais essayer de poster sur mon blog au fur et à mesure (c’est mal parti).

Merci en tout cas pour tes articles, car c’est quand meme ‘achement grace à eux que je suis allé jusque là C’est bien cool.
Haute Disponibilité de serveurs Tomcat/MySQL | Le blog de MadeInSyria
janvier 1st, 2009 le 17:17
[...] au début utiliser un système d’IP FailOver automatiser (un très bon tuto sur le sujet ICI). Cependant, cela s’est révélé impossible à cause de l’environnement Windows/Linux [...]
Stefano Bagnara
février 24th, 2009 le 16:14
Hi! I have a similar setup in a test environment and I was trying to understand how to do this inside OVH and with failover! Your info is very useful!

Are you using this for VMWareServer (1 or 2?) or you use Xen?

What kind of dedicated hosting do you have in OVH and are you satisfied with the resulting speed (network speed) between the 2 dedicated?

I wonder if this will work also for 100mbps connected dedicated or if I need a 1gbps dedicated.
guiguiabloc
février 24th, 2009 le 17:30
Thanks a lot
I’m using VMware server 2 and i’ve got 2 EG BestOf (1Gbps dedicated link).
With a 100 mbps, maybe you have to forget the Ipsec tunneling… In fact, the first synchro is the most important, in current use, the amount of data depends on what you have :-p
Stefano Bagnara
février 25th, 2009 le 17:58
@guiguiabloc I really plan to do something similar. About ipsec if I understand correctly it is hard to sniff or inject IP packets inside the OVH network as they carefully check IP/MAC everywhere, so, as my application is not security intensive I could live with no ipsec.

About the “are you satisfied with the resulting speed” I intended: is the “nominal” bandwith really available or is it slower? is the latency between different dedicated acceptable/reliable?

BTW: I’ll start some test soon with the same setup (only difference fedora9 instead of debian etch): vmware server 2 (web access disabled as I’ll use VIC and I don’t want to waste memory in the host), drbd and failover (probably no ipsec). “EG Best OF” seem the perfect companion for this solution. I’ve never seen a cheaper HA cluster with this features…

Your article (and also many other articles from your blog) will save me full days of hacking, I’m sure! THANK YOU for sharing!
guiguiabloc
février 25th, 2009 le 18:51
Well, i agree with you. Ipsec solution is just an add-on here

I’m really satisfied with the available bandwith between the two servers on the OVH LAN. I’ve got 1Gbps but only use 30MB/sec. After several month, the result is perfectly acceptable and reliable (perhaps 5 or 6 network cut by OVH when they are working on the network infrastructure).
The synchro is fast and i didn’t notice any problems during this work.
Fedora is a good choice too, i’m not a troller :-p

Thanks a lot, it’s a great pleasure to see that some people are reading my articles and, especially when they help them

Good luck for your project and give us a feed-back
Nicko
mai 5th, 2009 le 9:26
Merci Guigui pour tout ca, çà fonctionne trés bien

Il me reste juste un probleme à régler mais c’est conceptuel.

Coté VMWARE avant tout çà, je mettais mes VM derriere un IPTABLES + NAT et je faisais de la redirection de port. Ca me permets par exemple d’avoir un serveur LAMP en 192.168.101.2 sur un Host repliqué par MySQL + RSYNC sur une seconde VM en 192.168.102.2, le tout par un VPN entre les deux hosts. Je bascule l’ip FO et hop c’est fait.

Maintenant l’approche avec DRBD fait que mes VM sont identiques de chaque coté, et si je la démarre, elle n’a pas pas la bonne IP Privé, il faut que je creuse, de toute facon DRBD n’est pas la solution ultime pour tout je pense
Nas drbd « Et pourquoi pas ?
juin 5th, 2009 le 13:44
[...] des infos sur le blog de Guigui le Geek (merci à lui pour la documentation faite!). C’est ICI. Et voici donc mon fichier de config drdb.conf, très similaire à celui de Guigui pour le [...]
guillaume a
juin 5th, 2009 le 16:45
salut guiguiabloc, et bravo pour ton blog, tu portes bien ton pseudo!

par contre pour lire tes posts je désactive la CSS ça me crève les yeux sinon mais bon pas grave

j’ai une question sur ce post, j’essaie d’isntaller DRBD sur une DEBIAN 5 et lors de l’activation de modules du noyau

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

j’ai bien le “Module unloading” mais pas le “Automatic kernel module loading”

j’ai pris ce noyau : ftp://ftp.ovh.net/made-in-ovh/bzImage/linux-2.6.28.4-ovh.tar.gz et cette config : ftp://ftp.ovh.net/made-in-ovh/bzImage/2.6-config-xxxx-std-ipv4-64

aurais-tu une piste svp?

merci
guiguiabloc
juin 5th, 2009 le 18:08
Salut,
J’ai ca dans mon .config :

CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set

pour un 2.6.24.5-xxxx-std-ipv4-32, si ca peut t’aider…
guillaume a
juin 8th, 2009 le 10:14
merci pour ta réponse, en fait l’option n’apparait pas dans le menu(config) mais elle est bien présente dans le .config, donc tout roule

bonne continuation
psxweb
septembre 5th, 2009 le 21:27
hello
merci pour le tuto
j’ai bien suivi les instructions de ton tutorial
mais au moment de compiler drdb j’ai l’erreur suivante

include/asm-generic/bug.h:57:1: warning: this is the location of the previous definition
/tmp/drbd-8.0.13/drbd/drbd_receiver.c: In function ‘drbd_alloc_ee’:
/tmp/drbd-8.0.13/drbd/drbd_receiver.c:287: warning: passing argument 2 of ‘q->merge_bvec_fn’ from incompatible pointer type
/tmp/drbd-8.0.13/drbd/drbd_receiver.c:297: error: ’struct bio’ has no member named ‘bi_hw_segments’
make[2]: *** [/tmp/drbd-8.0.13/drbd/drbd_receiver.o] Erreur 1
make[1]: *** [_module_/tmp/drbd-8.0.13/drbd] Erreur 2
make[1]: quittant le répertoire « /usr/src/linux-2.6.28.4-ovh »
make: *** [kbuild] Erreur 2

je vois pas trop a quoi est du cette erreur
guiguiabloc
septembre 5th, 2009 le 22:57
Jeter un oeil sur le config.log pour plus d’infos.
The BLION Corp.
octobre 6th, 2009 le 19:12
Une petite erreur de frappe dans le guide :

drbdadm — –overwrite-data-of-peer primary r0
Il y a quatre tirets Et non pas un tiret quadratin et un tiret
guiguiabloc
octobre 6th, 2009 le 20:24
arf c’est la police qui fait ça :-p
groPepere
octobre 15th, 2009 le 22:03
Hé Guigui, tu sais quoi ? C’est exactement ce que je cherchais.
Merci !
guiguiabloc
octobre 15th, 2009 le 22:11
Content de répondre a tes besoins
freeman
novembre 24th, 2009 le 15:42
Bonjour,
Merci pour ce superbe article. Il va m’être d’un grand recours. Toujours chez OVH, est-il possible de greffer une couche Plesk / Webmin / CPanel / etc.. ?
guiguiabloc
novembre 24th, 2009 le 19:05
euh… depuis quand Plesk/Webmin/CPanel sont dépendants d’un hébergeur ^^
Un dédié t’installes ce que tu veux dessus, même ce genre de truc dont j’ai horreur.
freeman
novembre 25th, 2009 le 9:10
Effectivement, je suis d’accord avoir toi. Néanmoins, pour les non-initiés à Linux, cela permet d’administrer des taches de base au quotidien.
Je sais que Plesk/Cpanel/Webmin sont indépendant de ‘herbergeur, mais dans le cas présent.. cela ne présente t’il pas de soucis avec l’architecture que tu présente sur ce billet ?
guiguiabloc
novembre 25th, 2009 le 19:06
??? je ne vois pourquoi cela en poserais… Et honnetement, quand on s’attaque a ce genre de solution, on n’utilise pas de webmin/cpanel/etc… La plupart du temps, ce type d’archi est monté par des admins plutôt initiés qui n’ont nul besoin d’interface web d’administration.
S’il faut une interface pour administrer un serveur GNU/Linux, je déconseille fortement de se lancer dans ce projet qui demande un minimum de compétences sysadmin.
Samuel
décembre 2nd, 2009 le 18:12
Bonjour,

cet article est très intéressant et merci pour cela.

j’ai une question : est-il possible de monter en lecture la partition /dev/drbd0 sur le serveur esclace “drbd” sans passer par une solution heartbeat ?

merci
guiguiabloc
décembre 2nd, 2009 le 19:05
merci

Non, la partition esclave ne peut pas être montée.

guiguiabloc-b:~# mount -t ext3 -r /dev/drbd0 /data
mount: Mauvais type de medium
Samuel
décembre 3rd, 2009 le 16:22
Re-merci,

je suis arrivé à mes fins en utilisant drbd en primary/primary et ma partition /dev/drbd0 formatée en ocfs2 (et donc sur l’esclave je n’ai fait qu’un montage en read-only bridant ainsi les possibilités offertes par cette solution mais dont je n’ai besoin… ;-))

ton blog est vraiment super intéressant et oblige à se documenter sur les sites officiels pour toujours apporter un plus bénéfique à la connaissance personnelle de ces technologies
guiguiabloc
décembre 3rd, 2009 le 18:12
merci

Tu avais un exemple de primary/primary avec ocfs2 un peu plus loin dans le blog (http://blog.guiguiabloc.fr/index.php/2009/02/16/mise-en-oeuvre-dun-systeme-de-fichier-distribue-et-acces-concurrents-en-san-avec-drbd-iscsi-ocfs2-et-dm-multipath/).

Mais tu as raison, il faut se documenter pour pousser plus loin, ce que j’essaye modestement d’obligé les gens à faire