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";
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 ?
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
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 ?
nan 😉
Comme cela, cela force à lire tout l’article.
Problèmes de perfs réseau essentiellement (AES est plus rapide que 3DES).
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
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 🙂
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 🙂
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
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
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
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é ! 😀
lol
OUais bof. Pas lol. Ca marche toujours pas :-p
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.
exact, je me suis mal exprimé « pour interroger ns1111 » était plutot ce que je voulais dire.
Je corrige.
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.)
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 😀
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.
Pingback: Haute Disponibilité de serveurs Tomcat/MySQL | Le blog de MadeInSyria
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.
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
@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!
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 😉
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 🙂
Pingback: Nas drbd « Et pourquoi pas ?
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
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…
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
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
Jeter un oeil sur le config.log pour plus d’infos.
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 🙂
arf c’est la police qui fait ça :-p
Hé Guigui, tu sais quoi ? C’est exactement ce que je cherchais.
Merci !
Content de répondre a tes besoins 😀
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.. ?
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.
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 ?
??? 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.
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
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
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
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 😉
Bonsoir,
Un exemple de panel clusterisé sur ce type de solutions : http://data-server.org/blog/?p=6
Dans le cas d’un Webmin / Virtualmin, c’est essentiellement une question de recopie de fichiers…
Pour d’autres panels… A voir !
Quant à l’utilité de ce genre de panels, ça permet de fournir un panel à un utilisateur non initié… sur un cluster haute disponibilité. J’ai plusieurs demandes dans ce sens. Avoir un cluster, tout en gardant le contrôle sur les opérations simples, comme rajouter une boite mail.
Bonjour et félicitation pour votre travail.
J’essaie de mettre en place chez heartbeat chez ovh mais seulement pour gérer les coupures d’apache.
J’ai donc utilisé vos scripts et seulement changé le fichier haresources pour y rajouter « apache » à la fin.
Malheureusement j’ai l’impression de rater quelque chose vu que ça ne fonctionne pas.
Auriez-vous une idée ?
Merci
Les services doivent être gérer uniquement par HB et plus au boot. Sans message d’erreur, difficile de comprendre ou est le soucis.
Merci de ta réponse mais c’est bon je suis arrivé à régler mon problème et la bascule entre les serveurs marche bien 🙂
bonjour Guigui,
j’ai mis en place cette config il y a de ça 6 mois et j’en suis ravi, merci.
Cependant, j’ai deux dédiés chez OVH avec RAID 1 hard et ô surprise quand je fais un fdisk -l je n’ai plus qu’un seul disque…
OVH me propose de faire un backup et de serrer les fesses…
penses-tu que ça puisse être lié? merci
euh, en raid 1 tu ne vois qu’un seul disque ^^
j’ai aussi des serveurs OVH en raid hard et un fdisk -l ne me sort que /dev/sda…
Ils sont visible au niveau controleur RAID:
:~# tw_cli info c0
Unit UnitType Status %Cmpl Stripe Size(GB) Cache AVerify IgnECC
——————————————————————————
u0 RAID-1 OK – – 698.637 ON – –
Port Status Unit Size Blocks Serial
—————————————————————
p0 OK u0 698.63 GB 1465149168 5QK0MBJ1
p1 OK u0 698.63 GB 1465149168 5QK0M6AF
merci guigui j’ai trouvé tw_cli dans les guides ovh juste après avoir posté sur le blog (désolé), c’est le mec d’ovh qui m’a affolé (un peu) en me disant que ça n’était pas normal
tout va bien en fait, bonne continuation
bonjour guigui,
j’ai l’architecture que tu décris dans ton billet en place depuis presque un an et j’en suis ravi.
Cependant, avec les dernières failles de sécurité du noyau linux, je voulais mettre ce dernier à jour mais… et drbd alors? je ne trouve vraiment pas grand chose là dessus, apparemment il faut recompiler les modules de drbd avec le nouveau noyau mais alors faut-il tout couper puis tout reconstruire? peut-on faire ça seulement sur le secondary?
si tu as des infos ou des liens je suis preneur
merci beaucoup