GuiguiAbloc

Difficile de faire plus court en titre…

Je vous préviens tout de suite, ce billet risque d’être un peu long car après tout, j’ai passé du temps dessus, autant que vous en passiez, vous aussi, a me lire

Tous ceux qui ont déjà eu à mettre en oeuvre une quelconque solution de Haute-Disponibilité, se sont retrouvés un jour devant une problématique assez angoissante :

L’accès simultané (ou concurrent) à une ressource de données.

Si en lecture cela pose rarement des problèmes, en écriture, cela comment à devenir « légèrement » complexe.

Petit exemple.

Vous avez deux serveurs load-balancés (web ou autre), si vous écrivez une information sur le premier serveur, comment être sur qu’elle soit disponible sur le deuxième, et vice-versa.

Après tout, je peux aussi bien écrire sur le serveur A que sur le serveur B.

Retour en arrière donc pour vous expliquer la progression de mon raisonnement et la solution que j’ai mise en oeuvre.

Lorsque l’on désire avoir une synchronisation parfaite des données entre deux serveurs, la première méthode est d’utiliser un mode Actif/Passif (ou maître/esclave).
Le moyen le plus simple est de se baser sur DRBD dont j’avais déjà abordé le sujet ICI qui est une sorte de RAID Over IP.

La mise en place de drbd vous donne un nouveau périphérique de stockage (ou nouveau disque pour simplifier) de type /dev/drbdX.

Exemple DRBD

En cas de panne du Maître, le service est basculé sur l’Esclave et les données accessibles par celui ci.

Bascule DRBD

Le volume DRBD, appelé par exemple /dev/drbd0 est alors « monté » en système de fichier sur la machine passive qui devient alors, active.

Je parle bien entendu de synchronisation en mode « bloc », pas d’une synchronisation de fichiers comme le fait rsync ou autre.

Dans cet exemple, le système de fichier reste standard (ext2, ext3, reiser etc…).

Si maintenant vous avez décidé de mettre en oeuvre un loadbalancing suite à la lecture de cet excellent billet , les choses se compliquent.

En effet, nous nous trouvons dans un cas de figure où les deux serveurs sont Maîtres, donc Actif.

Heureusement, depuis la version 0.8 de DRBD, les deux noeuds peuvent être « Primary ».

(nb. : la version 0.9 devrait apporter le support de plus de 2 noeuds)

Par contre, pour pouvoir utiliser ses deux noeuds en mode Primaire, il faut un système de fichier « distribué » (vous trouverez souvent le terme « shared disk file system »).

Il en existe peu et les principaux sont GFS et OCFS2.

Le premier est issu de RedHat et le second d’Oracle. Sachez que le support de ses deux systèmes de fichiers est inclus dans les noyaux Linux récents.

J’ai testé les deux quelques temps et suite à mon retour personnel d’expérience et les discussions avec d’autres « geeks » ayant joué avec les deux, j’ai une nette préférence pour OCFS2. La suite de ce billet se basera donc sur ce système de fichier.

(je vous laisse bien sûr à vos propres expériences et recherches, si vous préférez GFS ou Lustre, je ne vous jetterai pas de pierres )

Une fois mise en place, nous nous retrouvons donc avec ce type d’architecture :

OCFS2

La, on commence à être « poilu » non ?

Oui, MAIS, cette architecture est valable uniquement si on utilise les ressources locales des 2 serveurs (i.e. leurs disques durs).

Si je ne veux pas utiliser les disques durs de mes serveurs mais les disques d’un autre groupe de serveurs dédiés a cela ? Comment je fais ? HEIN ! Comment ???

Du calme, jeune Padawan, tu sais bien que Guiguiabloc est… à bloc…

Nous allons utiliser un SAN pour connecter nos disques distants à nos serveurs.

Un SAN !?! Mais j’ai pas de sous moi !!!

Allons, jeune Youngling, tu n’auras nul besoin de casser ton petit cochon qui te sert de tirelire, nous allons utiliser le protocole Iscsi.

L’ISCSI est du SCSI sur TCP/IP, nous allons connecter via ce protocole nos disques distants sur nos serveurs qui les verront comme s’il s’agissait de disques locaux.

(j’avais déjà abordé le sujet dans ce billet)

De plus en plus « poilu »… Mais pas encore assez. Poussons le bouchon un peu plus loin (hein Maurice ?) , je veux bien sûr de la redondance sur mes connexions Iscsi.

Et comment je fais de la haute disponibilité sur des iniatiators Iscsi ???

En utilisant un Device Mapper Multipath.

Bien sûr là vous vous dites : Guiguiabloc est fou/malade/a bloc/allumé (rayez les mentions inutiles) , et je vous répondrais… oui.

Schématisons le bouzin :

Schéma FS distribué

C’est beau hein ?

Après la théorie, passons à la phase la plus dure, la pratique.

• DRBD

Récuperer les souces :

http://oss.linbit.com/drbd/8.3/drbd-8.3.0.tar.gz

tar xzvf drbd-8.3.0.tar.gz
cd drbd-8.3.0
cd drbd
make
cd ..
make tools
make install
make install-tools

Edition du fichier /etc/drbd.conf (bien sur, remplacer les valeurs par les votres)

#/etc/drbd.conf
 
global {
usage-count yes;
}
 
resource r0 {
protocol C;
startup {
become-primary-on both;
}
disk {
on-io-error   detach;
}
 
net {
allow-two-primaries;
after-sb-0pri discard-least-changes;
after-sb-1pri violently-as0p;
after-sb-2pri violently-as0p;
rr-conflict violently;
}
syncer {
rate 44M;
}
 
on DISK-GUIGUIABLOC-A { # nom du serveur 1
device     /dev/drbd0;
disk       /dev/sda4; # partition a prendre en compte
address    192.168.30.1:7788; # adresse ip et port d'écoute
meta-disk  internal;
}
on DISK-GUIGUIABLOC-B { # nom du serveur 2
device    /dev/drbd0;
disk      /dev/sda3; # partition a prendre en compte
address   192.168.30.2:7788; # adresse ip et port d'écoute
meta-disk internal;
}
}

Sur chacun des noeuds :

drbdadm create-md r0
modprobe drbd
drbdadm attach r0
drbdadm connect r0
 
Puis sur le noeud1 par exemple
drbdadm -- --overwrite-data-of-peer primary r0
 
/etc/init.d/drbd start

Vous suivez la synchro via un cat /proc/drbd

Je ne m’étends pas la dessus, j’en avais déjà parlé dans un autre billet.

• ISCSI Target Entreprise

Sur les deux « serveurs disques », on va installer un Target ISCSI.

(en terminologie ISCSI, on parle de Target pour la cible (soit la machine qui « offre » son disque) et d’Initiator pour la machine qui va se connecter au Target).

Je vous invite cet excellent article :

http://www.unixgarden.com/index.php/administration-reseau/le-support-du-protocole-iscsi-dans-linux

Nous allons utiliser les sources du projet iSCSI Entreprise Target , ici en version 0.4.17.

wget http://kent.dl.sourceforge.net/sourceforge/iscsitarget/iscsitarget-0.4.17.tar.gz
tar xzvf iscsitarget-0.4.17.tar.gz
cd iscsitarget-0.4.17
make
make install

On prépare son /etc/ietd.conf (volontairement simplifié a l’extrème).

Vous remarquerez que j’exporte via ISCSI le volume DRBD0.

Target iqn.2009-02.fr.guiguiabloc:disk-a.disk
        Lun 0 Path=/dev/drbd0,Type=blockio
        Alias disk

On configure le fichier d’autorisation d’accès (comme les hosts.allow des wrappers tcp)

DISK-GUIGUIABLOC-a# cat /etc/initiators.allow
 
iqn.2009-02.fr.guiguiabloc:disk-a.disk ALL

Même chose sur le deuxième serveur (changer juste le nom du target).

on démarre /etc/init.d/iscsi-target start, et on vérifie

DISK-GUIGUIABLOC-a:/etc/iscsi/ifaces# /etc/init.d/iscsi-target status
iSCSI enterprise target is running at pid 7715
DISK-GUIGUIABLOC-a:/etc/iscsi/ifaces# cat /proc/net/iet/volume
tid:2 name:iqn.2009-02.fr.guiguiabloc:disk-a.disk
        lun:0 state:0 iotype:blockio iomode:wt path:/dev/drbd0

• Open-ISCSI

Sur nos deux serveurs srv-guiguiabloc-a et srv-guiguiabloc-b, nous allons installer l’Initiator (le client ISCSI si vous préférez).

Récupérons des sources sur le site http://www.open-iscsi.org/

wget http://www.open-iscsi.org/bits/open-iscsi-2.0-870.2.tar.gz
 
tar xzvf open-iscsi-2.0-870.2.tar.gz
 
make
 
make install

On donne un nom explicite à notre Initiator, puis on démarre le service.

srv-guiguiabloc-a:/etc/iscsi# cat initiatorname.iscsi
InitiatorName=iqn.2009-02.fr.guiguiabloc:srvA
 
srv-guiguiabloc-a:/etc/iscsi# /etc/init.d/open-iscsi start
Starting iSCSI initiator service: iscsid.
Setting up iSCSI targets:iscsiadm: No records found!

Lançons une découverte du service

srv-guiguiabloc-a:/etc/iscsi# iscsiadm -m discovery -t sendtargets -p 192.168.30.1:3260
192.168.30.1:3260,1 iqn.2009-02.fr.guiguiabloc:disk-a.disk
 
srv-guiguiabloc-a:/etc/iscsi# iscsiadm -m discovery -t sendtargets -p 192.168.30.2:3260
192.168.30.2:3260,1 iqn.2009-02.fr.guiguiabloc:disk-b.disk

Un succès

(Bien sûr vous reproduisez tout cela sur srv-guiguiabloc-b)

Maintenant, montons les sessions ISCSI sur nos deux Targets, sur nos deux serveurs

srv-guiguiabloc-a:~# iscsiadm -m node -T iqn.2009-02.fr.guiguiabloc:disk-a.disk -p 192.168.30.1 -l
Login session [iface: default, target: iqn.2009-02.fr.guiguiabloc:disk-a.disk, portal: 192.168.30.1,3260]
srv-guiguiabloc-a:~# iscsiadm -m node -T iqn.2009-02.fr.guiguiabloc:disk-b.disk -p 192.168.30.2 -l
Login session [iface: default, target: iqn.2009-02.fr.guiguiabloc:disk-b.disk, portal: 192.168.30.2,3260]
 
srv-guiguiabloc-b:~# iscsiadm -m node -T iqn.2009-02.fr.guiguiabloc:disk-a.disk -p 192.168.30.1 -l
Login session [iface: default, target: iqn.2009-02.fr.guiguiabloc:disk-a.disk, portal: 192.168.30.1,3260]
srv-guiguiabloc-b:~# iscsiadm -m node -T iiqn.2009-02.fr.guiguiabloc:disk-b.disk -p 192.168.30.2 -l
Login session [iface: default, target: iiqn.2009-02.fr.guiguiabloc:disk-b.disk, portal: 192.168.30.2,3260]
 
Vous devriez voir vos disques en local désormais :
 
srv-guiguiabloc-a:~# cat /proc/scsi/scsi
Attached devices:
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: IET      Model: VIRTUAL-DISK     Rev: 0
  Type:   Direct-Access                    ANSI SCSI revision: 04
Host: scsi2 Channel: 00 Id: 00 Lun: 00
  Vendor: IET      Model: VIRTUAL-DISK     Rev: 0
  Type:   Direct-Access                    ANSI SCSI revision: 04

Pour l’inclure en démarrage automatique :

iscsiadm -m node -T iqn.2009-02.fr.guiguiabloc:disk-a.disk -p 192.168.30.1 -o update -n « node.conn[0].startup » -v automatic

(je vous laisse lire la documentation et/ou l’article sur Unix Garden.)

• Device Mapper MULTIPATH I/O

Nous allons utiliser une des couches du système Linux, le Device Mapper.

Son rôle est tout simplement de mapper un ou plusieurs périphériques de blocs sur un autre périphérique.
En fait, vous l’utilisez souvent sans peut-être le savoir avec LVM.

Vous trouverez un excellent billet la dessus sur : http://linux-attitude.fr/post/La-carte-du-peripherique

Et l’une des fonctions offertes par DM et le ISCSI, c’est le Multipath.

C’est à dire accéder à un périphérique par plusieurs chemins différents

Vous voyez ou je veux en venir ?….

Si notre Target A tombe, pas de soucis, srv-guiguiabloc-x passera par l’autre chemin, en l’occurrence le Target B, tout cela grâce au Multipath (pas celui LA hein )

(hi hi hi, désolé, il fallait que je la fasse)

Sur Debian : apt-get install multipath-tools

Editer votre fichier /etc/multipath.conf

blacklist {
devnode "sda"   # ici le disque local que j'exclue
}
defaults {
user_friendly_names yes
}
 
srv-guiguiabloc-a:# /etc/init.d/multipath-tools restart
 
srv-guiguiabloc-a:/dev/mapper# ll
total 0
crw-rw---- 1 root root  10, 63 2009-02-14 19:57 control
brw-rw---- 1 root disk 254,  0 2009-02-16 15:16 mpath0
brw-rw---- 1 root disk 254,  1 2009-02-16 15:16 mpath1

Vous voyez vos périphériques de blocs que vous pouvez utiliser comme n’importe quel autre.
En cas de déconnexion d’un Target, Multipath retirera le périphérique de la liste automatiquement.

(bien sûr, même punition pour srv-guiguiabloc-b).

• OCFS2

On arrive « enfin » au système de fichier proprement dit.

Sur les 2 srv-guiguiabloc :

apt-get install ocfs2-tools

On créer le répertoire /etc/ocfs2

On édite un fichier cluster.conf (identique sur les deux noeuds)

node:
        ip_port = 7777
        ip_address = 192.168.30.1
        number = 0
        name = srv-guiguiabloc-a
        cluster = ocfs2
 
node:
        ip_port = 7777
        ip_address = 192.168.30.2
        number = 1
        name = srv-guiguiabloc-b
        cluster = ocfs2
 
cluster:
        node_count = 2
        name = ocfs2

Changer la valeur « O2CB_ENABLED=false » en « O2CB_ENABLED=true » dans /etc/default/o2cb

Démarrer le cluster :

srv-guiguiabloc-a:/etc/ocfs2# /etc/init.d/o2cb start
Loading module "configfs": OK
Mounting configfs filesystem at /sys/kernel/config: OK
Loading module "ocfs2_nodemanager": OK
Loading module "ocfs2_dlm": OK
Loading module "ocfs2_dlmfs": OK
Creating directory '/dlm': OK
Mounting ocfs2_dlmfs filesystem at /dlm: OK
Starting Oracle cluster ocfs2: OK

Et on formate

srv-guiguiabloc-a:/etc/ocfs2# mkdir /data
srv-guiguiabloc-a:/etc/ocfs2# mkfs -t  ocfs2 -L GUIGUIABLOCFS /dev/mapper/mpath0
mkfs.ocfs2 1.2.1
Filesystem label=GUIGUIABLOCFS
Block size=4096 (bits=12)
Cluster size=4096 (bits=12)
Volume size=1439338496 (351401 clusters) (351401 blocks)
11 cluster groups (tail covers 28841 clusters, rest cover 32256 clusters)
Journal size=67108864
Initial number of node slots: 4
Creating bitmaps: done
Initializing superblock: done
Writing system files: done
Writing superblock: done
Formatting Journals: done
Writing lost+found: done
mkfs.ocfs2 successful

Et c’est tout !

N’essayer pas de formater /dev/mapper/mpath1, ou /dev/mapper/mpath0 sur srv-guiguiabloc-b, vous aurez ce message :

srv-guiguiabloc-a:/etc/ocfs2#  mkfs -t  ocfs2 -L GUIGUIABLOCFS /dev/mapper/mpath1
mkfs.ocfs2 1.2.1
Overwriting existing ocfs2 partition.
Proceed (y/N): n
Aborting operation.
 
srv-guiguiabloc-b:/etc/ocfs2#  mkfs -t  ocfs2 -L GUIGUIABLOCFS /dev/mapper/mpath0
mkfs.ocfs2 1.2.1
Overwriting existing ocfs2 partition.
Proceed (y/N): n
Aborting operation.

Ce qui prouve bien que notre volume est bien vu de srv-guiguiabloc-b, par le chemin /dev/mapper/mpath0 ou /dev/mapper/mpath1

C’est pas magnifique tout cela ?

Et maintenant, le test final :

srv-guiguiabloc-a:/etc/ocfs2# mount /dev/mapper/mpath1 /data
srv-guiguiabloc-a:/etc/ocfs2# mount
/dev/sda1 on / type ext3 (rw,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
configfs on /sys/kernel/config type configfs (rw)
ocfs2_dlmfs on /dlm type ocfs2_dlmfs (rw)
/dev/mapper/mpath1 on /data type ocfs2 (rw,_netdev,heartbeat=local)
 
srv-guiguiabloc-b:/etc/ocfs2# mount /dev/mapper/mpath0 /data
srv-guiguiabloc-b:/etc/ocfs2# mount
/dev/sda1 on / type ext3 (rw,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
configfs on /sys/kernel/config type configfs (rw)
ocfs2_dlmfs on /dlm type ocfs2_dlmfs (rw)
/dev/mapper/mpath0 on /data type ocfs2 (rw,_netdev,heartbeat=local)
 
srv-guiguiabloc-a:/data# touch test
 
srv-guiguiabloc-b:/data# ls
test  lost+found

Vous pouvez vous amuser à écrire des deux côtés, couper un Target, vautrer un disque etc…

Après plusieurs essais intensifs, je vous avoue que j’ai été bluffé par le fonctionnement, que, je l’avoue, j’ai poussé à l’extrême.

Ne reste qu’à le greffer sur votre architecture « Altéonisée » que vous avez montée après la lecture de :

http://blog.guiguiabloc.fr/index.php/2009/01/14/switch-applicatif-avec-openbsd-un-alteon-a-la-maison/

Ce qui nous donne un joli résultat au final :

La Haute Dispo vue par Guiguiabloc

Très « poilu », non ?

Comme dirais mon pote `g0rt :

[17:53] <`g0rt> ca c’est de la redondance vindiousse

Bon courage dans le peaufinage de votre cluster

Dans la continuité de la découverte des petites spécificités de la plateforme d’hébergement dédié d’OVH, aujourd’hui l’installation de VMWare Server 2.0.

Nous allons tout d’abord voir son installation en tenant compte des particularités d’OVH, l’utilisation de l’IpFailover et/ou des blocs ip RIPE fournis avec les serveurs et pour finir, en bonus, une petite bidouille à la Guiguiabloc pour intégrer un datastore VMWare en Raid1 over ip et bascule automatique.

Bien entendu, je pars d’une distribution Linux de base (Debian Etch ici) et pas la distribution VMware que fourni OVH.

Pré-Requis : Vous avez lu CE PRECEDENT BILLET avant et donc vous avez recompilé votre noyau sur vos serveurs. (il vous faut les sources du kernel).

Les switchs OVH ont une sécurité sur leurs interfaces empêchant de faire du bridging sur l’interface eth0 de votre serveur (ce qui est très bien en soi).

En gros, vous ne pouvez pas sortir sur l’interface du switch avec une adresse MAC différente de celle de votre carte réseau, si vous brigder l’interface vmnet0 avec eth0, le switch se mettra en « défense » (scénario bien connu des bidouilleurs de Cisco ) et vous coupera le port.

A savoir que le principe est le même avec XEN donc attention a ce que vous faites…

Nous allons donc bridger VMware sur une interface bidon et configurer le Host-Only pour les interfaces réseaux de nos Machines Virtuelles.

On commence par monter une fausse interface ethernet, en éditant notre fichier /etc/network/interfaces (Debian) :

auto dummy0
iface dummy0 inet static
address 10.0.0.1 netmask 255.0.0.0 [ATTENTION CHOISIR UNE IP DE CLASSE PRIVEE]

Puis on l’active : ifup dummy0

(on vérifier par ifconfig que cette interface est bien présente).

On peut attaquer l’installation de VMware Server (je vous passe la phase de vous rendre sur le site de VMware pour récuperer le package et le numéro de série gratuit…)

tar xzvf VMware-server-2.0.0-116503.i386.tar.gz

cd vmware-server-distrib/

./vmware-install.pl
Creating a new VMware Server installer database using the tar4 format.

Installing VMware Server.

Vous répondez aux questions qui s’affichent (en changeant selon vos désirs les réponses pré-définies)

Si tout ce passe bien, vous devriez arrivé ici :

The installation of VMware Server 2.0.0 build-116503 for Linux completed
successfully. You can decide to remove this software from your system at any
time by invoking the following command: « /usr/bin/vmware-uninstall.pl ».

Before running VMware Server for the first time, you need to configure it by
invoking the following command: « /usr/bin/vmware-config.pl ». Do you want this
program to invoke the command for you now? [yes]

Vous suivez la procédure jusqu’au paramétrage du réseau :

La, on devient un peu plus attentif

Do you want networking for your virtual machines? (yes/no/help) [yes]

Configuring a bridged network for vmnet0.

Please specify a name for this network.
[Bridged]

Your computer has multiple ethernet network interfaces available: dummy0, eth0 . Which one do you want to bridge to
vmnet0? [eth0] dummy0

The following bridged networks have been defined:

. vmnet0 is bridged to dummy0

Do you wish to configure another bridged network? (yes/no) [no] no

Do you want to be able to use NAT networking in your virtual machines? (yes/no)
[yes] no

Do you want to be able to use host-only networking in your virtual machines?
[no] yes

Configuring a host-only network for vmnet1.

Please specify a name for this network.
[HostOnly]

Do you want this program to probe for an unused private subnet? (yes/no/help)
[yes] no

What will be the IP address of your host on the private
network? 192.168.1.1 [ATTENTION CHOISIR UNE IP DE CLASSE PRIVEE]

What will be the netmask of your private network? 255.255.255.0
the following host-only networks have been defined:

. vmnet1 is a host-only network on private subnet 192.168.0.

Do you wish to configure another host-only network? (yes/no) [no] (vous pouvez créer d’autres interfaces si vous le souhaitez)

None of the pre-built vmnet modules for VMware Server is suitable for your
running kernel. Do you want this program to try to build the vmnet module for
your system (you need to have a C compiler installed on your system)? [yes]

Extracting the sources of the vmnet module.

Building the vmnet module etc..

The configuration of VMware Server 2.0.0 build-116503 for Linux for this
running kernel completed successfully.

Et voila, vous pouvez faire pareil sur l’autre serveur (si vous en avez deux )

Vous pouvez vous connecter sur l’excellente interface d’administration : https://votrededieovh:8333

Lancer la création et l’installation d’une nouvelle machine virtuelle en donnant comme interface réseau, l’interface Host-only VMNET1.

(je ne parle pas du fonctionnement de VMware server ici, Google vous rapportera pleins de tutos )

• Configuration du réseau

On commence par activiter le forwarding entre vos cartes réseaux (en l’occurence etho et vmnet1 ici) :

/bin/echo « 1″ > /proc/sys/net/ipv4/ip_forward

(n’oublier pas de le mettre en dur dans votre /etc/sysctl.conf : sysctl net.ipv4.ip_forward=1)

Puis le proxy ARP :

echo "net.ipv4.conf.vmnet1.proxy_arp=1" >> /etc/sysctl.conf && sysctl -p

Sur la machine virtuelle, on configure notre ipfailover et/ou notre ip bloc RIPE :
/etc/network/interfaces :

iface eth0 inet static
address 91.x.x.x
netmask 255.255.255.240
broadcast 91.x.x.x
post-up /sbin/route add default dev eth0
Pour une IP bloc RIPE (voir les infos que vous donne OVH pour le netmask et le broadcast lorsque vous commander votre bloc ip ou utiliser l’excellent « sipcalc » pour calculer vos masques/reseau )

Pour un ipfailover (a adapter a votre ipfailover):

auto eth0
iface eth0 inet static
address 87.98.99.90
netmask 255.255.255.255
post-up /sbin/route add default dev eth0

La commande importante étant de lui spécifier eth0 comme passerelle par défaut ( /sbin/route add default dev eth0).

Sur votre dédié maintenant (le serveur VMware), il faut lui donner la route vers votre machine virtuelle :

/sbin/ip route add 87.88.89.90 dev vmnet1

Pour le rendre permanent, vous pouvez rajouter la commande dans /etc/init.d/vmware apres le chargement des modules réseaux ou vous basez sur la bidouille de Kro : http://forum.ovh.com/showthread.php?t=37645

(attention a adapter hein !!!).

EDIT : Pour l’explication détaillée pour VMWare Server 2.0, le billet de Superkikim ICI vous donnera toute satisafaction.

Voila, vous pouvez désormais pinguer le net depuis votre machine virtuelle et inversement.

(ne pas oublier le /etc/resolv.conf et tutti quanti…)

EDIT 2 : J’ai écris un billet sur la façon d’affecter une ip failover à votre VM, c’est ICI.

• Bidouille Guiguiabloc

Bon maintenant que tout cela tourne très bien, le plus « amusant » serait de pouvoir basculer notre machine virtuelle sur notre deuxième serveur en cas de crash du premier…

Je vous préviens tout de suite, cela ne sera pas transparent VMotion n’existe pas sur VMware server

Pré-requis : la lecture du précédent billet :-p (encore), un drbd actif, un heartbeat actif et une ipfailover disponible.

On se créer un volume DRBD (j’espère que vous avez prévu un stock de partitions de libre lors de l’installation de votre dédié OVH )

en éditant notre fichier /etc/drbd.conf et on ajoute :

resource r1 { (ou r0 si c’est votre premiere ressource drbd)
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 »;

}

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

disk {
on-io-error detach;

}

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

syncer {
rate 20M;
al-extents 257;
}
on ns11111 {
device /dev/drbd1;
disk /dev/sda11;
address 192.168.20.20:7789; (attention a ne pas mettre le meme port de la ressource r0)
meta-disk internal;
}

on ns22222 {
device /dev/drbd1;
disk /dev/sda11;
address 192.168.20.30:7789;
meta-disk internal;
}
}

On se coltine les définitions Maitre/Esclave (voir billet précédent), on formate /dev/drbd1.

Sur le serveur ns11111, on monte /dev/drdb1 sur /vmfs (par exemple) et on l’ajoute au datastore :

Vous devriez voir votre datastore apparaitre dans la liste :

Créer une machine virtuelle dedans ou comme moi, copier le repertoire de votre Machine Virtuelle et utilisez le « Add to Inventory » :

On stoppe VMware, on démonte /vmfs et on inverse les roles Maitre esclave :

sur ns11111 : drbdadm secondary r1

sur ns22222: drbdadm primary r1

on vérifie que l’on voit bien tout avec un cat /proc/drbd puis on monte /dev/drbd1 sur /vmfs.

Sur le VMware server de ns22222, on refait la meme manip, déclaration d’un nouveau datastore et « AddVirtual Machine to Inventory ».

• premier test

On se remet en environnement nomimal (vmware qui tourne sur ns11111, drbd1 en maitre et mount sur /vmfs)

On lance la VM sur ns11111.

On vérifie que tout marche bien et maintenant, simulons le crash manuellement.

- on kill -9 tout les process VMware (oui c’est crade, j’adore )

- on démonte /vmfs

- on bascule les ressources DrBD

- on lance vmware sur ns22222

- on lance la machine virtuelle.

Les soucis rencontrés sont les suivants :

L’uid disque a changer et il faut cliquer sur « i ‘ve copied it »

Ca c’est facile a régler, vous ajouter

uuid.action = "keep"

Dans le fichier *.vmx de votre machine virtuelle

Un répertoire « lock » verrouille le démarrage.

Il suffit de faire un petit rm -rf Guiguiabloc.vmdk.lck pour que ca parte.

Donc cela marche, mais il faut automatiser tout cela.

Heureusement, il existe les commandes vmrun.

La syntaxe est la suivante :

vmrun -T server -h https://localhost:8333/sdk -u adminvmware -p motdepasse stop « [VMFS-DRBD] Guiguiabloc/Guiguiabloc.vmx »

Pour arreter la VM par exemple (je vous laisse consulter la doc VMRUN sur le site de VMware ).

Vous avez donc tout les éléments pour inclure cela dans les scripts de Heartbeat (basez vous sur les exemples du précédent billet) :

1. bascule du DRBD et montage sur /vmfs
2. Démarrage de VMware sur le nouveau Maître
3. rm -r /vmfs/machinevirtuelle/machinevirtuellevmdk.lck
4. vmrun start

Tout bête quoi

Après plusieurs tests cela marche vraiment pas mal , bien évidemment le crash du maitre entraîne le « crash » de la VM, donc elle peut repartir un peu en vrac.

C’est pour cela que je vous conseille de programmer des « Snapshots » des VM toutes les nuits (si vous ne connaissez pas, jetez vous dessus et mangez en !!! )

Au pire vous pourrez repartir sur le snapshot de la veille.

En tout cas, avec cela l’indisponibilité est de quelques minutes…

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";