OVH: MIse en place d'un cluster Haute Disponibilité

Préambule

L’objectif de cette installation est la mise en place de serveurs mettant en œuvre la haute disponibilité.
La Haute Disponibilité (HA de l’anglais High Availability) est une architecture de système ou un service désignant le fait que cette architecture ou ce service a un taux de disponibilité convenable. Dans notre cas, nous utiliserons le clustering de disques qui est en réalité la réplication en temps réel des disques ainsi que la mise en place de l’IP Failover permettant aux services web (HTTP, Mail, …) d’être routés sur un autre serveur sans avoir à attendre le temps de propagation dû au changement des DNS.
Nous mettrons donc en œuvre les éléments suivants :

Heartbeat : permettant de basculer d’un serveur à l’autre en cas de panne
DRBD : mettant en place un système RAID 1 entre 2 serveurs (réplication des données en temps réel)
VPN IPsec : permet de sécurisé les échange entre les serveurs

Les pré-requis avant toute installation proprement parlée du HA sont les suivantes :

Disposer de 2 serveurs, ils ne doivent pas être forcément identiques
Avoir une connexion de 1Gb/s entre les serveurs
Disposer d’une partition de taille identique sur chacun des serveurs
Disposer d’une adresse IP propre à chacun des serveurs – nous les nommerons adresses IP d’administration
Disposer d’une adresse IP pouvant être attribuée de manière indifféremment par le système à un serveur – nous la nommerons adresse IP publique

A mon sens, la configuration minimum chez OVH pour la mise en place d’un cluster est proposée par les serveur EG Max. Cette procédure déroule les différentes étapes d’installation sur ces serveurs, mais elle est très facilement adaptable sur les autres type de serveurs. Néanmoins, les particularités OVH sont :

Indication sur le partitionnement des disques
Indication sur la bande passante à utiliser par DRBD
Mise en place du basculement du Failover

Conventions

Répartition des adresses IP avec nom que nous utiliserons pour les nommer dans ce document :
94.0.0.1: Adresse IP associée au serveur maître – master.exemple.fr
94.0.0.2: Adresse IP associée au serveur esclave – slave.exemple.fr
91.0.0.30 : Adresse IP failover à réserver sur le manager – public.exemple.fr
Les noms de domaine doivent exister et doivent être correctement configures. Il est à noter que les services utilisant ce cluster devront être configurés sur l’adresse IP 91.0.0.30, c’est celle qui va basculer d’un serveur à l’autre en cas de panne.

Définition du nom des serveurs, il faut vérifier le nom du serveur à l’aide de

# uname -n

Pour modifier à votre convenance, modifier le fichier /etc/hostname. Il faut penser à redémarrer votre serveur pour que la modification soit prise en compte.

Choix de l’OS

L’OS choisit chez OVH pour les serveurs EG Max est une Debian 5.0 Lenny 64bits.
Mais cette procédure d’installation fonctionne correctement avec la version 32bits de Lenny.

Partitions des disques

Les disques sont partitionnés somme suit :

Type de partition	Système de fichiers	Point de montage	Taille (en Go)
Primaire	ext3	/	100
Primaire	swap	8
Primaire	ext3	/home	642

Mise à jour du serveur

La distribution installée sur le serveur n’est pas forcément à jour, il convient d’installer les derniers paquets disponibles, ceci doit être réalisé par:

# apt-get update
# apt-get upgrade

Compilation du noyau

Le noyau fourni par OVH doit être recompilé afin de permettre l’utilisation des modules.

# cd /usr/src/
# wget ftp://ftp.ovh.net/made-in-ovh/bzImage/linux-2.6.28.4-ovh.tar.gz
# tar -xzf linux-2.6.28.4-ovh.tar.gz
# ln -s linux-2.6.28.4-ovh linux
# wget ftp://ftp.ovh.net/made-in-ovh/bzImage/2.6-config-xxxx-std-ipv4-64
# cp 2.6-config-xxxx-std-ipv4-64 linux/.config
# cd linux

Adaptez le nom du noyau utilisé en fonction de la version disponible dans le dossier ftp://ftp.ovh.net/made-in-ovh/bzImage

Afin d’activer les différents éléments du noyau, il faut lancer la commande:

# make menuconfig

Les éléments suivants doivent être activés, vérifiez et activé les le cas échéant :

[*]   Enable loadable module support  --->
 	[*]   Forced module loading
 	[*]   Module unloading
 	[*]     Forced module unloading 
[*] Networking support  --->
 	       Networking options  --->
 		<*>   IP: IPsec transport mode
 		<*>   IP: IPsec tunnel mode
 		<*>   IP: IPsec BEET mode
       Device Drivers  --->
 	<*> Connector - unified userspace <-> kernelspace linker  --->
 -*- Cryptographic API  --->
 	[*]   FIPS 200 compliance
 	<*>   Null algorithms
 	<*>   CCM support
 	<*>   GCM/GMAC support
 	<*>   CTR support
 	<*>   CTS support
 	-*-   HMAC support
 	-*-   AES cipher algorithms
 	<*>   AES cipher algorithms (x86_64)
 	<*>   Anubis cipher algorithm
 	<*>   Camellia cipher algorithms
 	<*>   Pseudo Random Number Generation for Cryptographic modules

Compilation du module et installation

# make
# make modules_install
# make bzImage
# cp arch/x86_64/boot/bzImage /boot/bzImage-2.6.28.4-xxxx-std-ipv4-64
# cp System.map /boot/System.map-2.6.28.4-xxxx-std-ipv4-64

Edition de la configuration de lilo (boot loader)

# vi /etc/lilo.conf

Le fichier devra ressembler à ceci:

lba32
boot=/dev/sda
prompt
timeout=50
#Enable large memory mode.
large-memory
image=/boot/bzImage-2.6.28.4-xxxx-std-ipv4-64
        label="Linux"
        root=/dev/sda1
        read-only

Mise en place du nouveau boot

# lilo
Added Linux-modules *
Added Linux

Reboot le serveur

# reboot

VPN IPSec

Nous allons mettre en place un VPN basé sur KAME IPSec. Ceci permettra de sécuriser les échanges entre les 2 serveurs.
Notre besoin est de connecter 2 points de façon sécurisée, nous allons donc utiliser le mode Transport, comme suit :

# apt-get install ipsec-tools tcpdump

Création des clés sécurisées

Afin de pouvoir garantir la sécurité des échanges, nous devons réaliser des clés de cryptage unique pour ces serveurs.
Génération de la clé 160 bits:

# hexdump -e '8/2 "%04x"' /dev/urandom -n 20;echo

Génération de la clé 224 bits

# hexdump -e '8/2 "%04x"' /dev/urandom -n 28;echo

Le résultat de ces commandes est à reporter dans la configuration ci-dessous. La valeur sera précédée par un 0x. Pour exemple :

# hexdump -e '8/2 "%04x"' /dev/urandom -n 20;echo
eb177148a976aa0bf346dfef0f45f4d7c79bc831

La valeur de la clé 160 bits sera donc

add 94.0.0.2 94.0.0.1 ah 24500 -A hmac-sha1 0xeb177148a976aa0bf346dfef0f45f4d7c79bc831;

Configuration de IPSec

Configuration du serveur maître, dans /etc/ipsec-tools.conf :

#!/usr/sbin/setkey –f
flush;
spdflush;
# AH
add 94.0.0.2 94.0.0.1 ah 24500 -A hmac-sha1 " clé hexa 160 bits ";
add 94.0.0.1 94.0.0.2 ah 15700 -A hmac-sha1 " clé hexa 160 bits ";
# ESP
add 94.0.0.2 94.0.0.1 esp 24501 -E aes-ctr " clé hexa 224 bits ";
add 94.0.0.1 94.0.0.2 esp 15701 -E aes-ctr " clé hexa 224 bits ";
# Transport
spdadd 94.0.0.1 94.0.0.2 any -P out ipsec
           esp/transport//require
           ah/transport//require;
spdadd 94.0.0.2 94.0.0.1 any -P in ipsec
           esp/transport//require
           ah/transport//require;

Configuration du serveur esclave, dans /etc/ipsec-tools.conf :

#!/usr/sbin/setkey –f
flush;
spdflush;
# AH
add 94.0.0.2 94.0.0.1 ah 24500 -A hmac-sha1 " clé hexa 160 bits ";
add 94.0.0.1 94.0.0.2 ah 15700 -A hmac-sha1 " clé hexa 160 bits ";
# ESP
add 94.0.0.2 94.0.0.1 esp 24501 -E aes-ctr " clé hexa 224 bits ";
add 94.0.0.1 94.0.0.2 esp 15701 -E aes-ctr " clé hexa 224 bits ";
# Transport
spdadd 94.0.0.2 94.0.0.1 any -P out ipsec
           esp/transport//require
           ah/transport//require;
spdadd 94.0.0.1 94.0.0.2 any -P in ipsec
           esp/transport//require
           ah/transport//require;

Ne pas oublier de remplacer le texte clé hexa 32 bits et clé hexa 48 bits par les valeurs obtenue à l’étape précédente. Dans notre exemple, les clés sont symétriques (les mêmes sur chacun des serveurs), une clé différente peut être mise en place sur chacun des serveurs.
Sur chacun des serveurs exécuter la commande

# /etc/init.d/setkey restart

Vérification du bon fonctionnement du VPN

Afin de vérifier que le VPN est bien effectif, sur chacun des serveurs il faut effectuer un ping sur l’autre serveur et examiner les paquets échangés. Par exemple, sur le serveur maître :

Dans une fenêtre SSH exécuter
```
# ping 94.0.0.2
```

Dans une autre fenêtre

# tcpdump -n "host 94.0.0.2"
14:32:07.390136 IP 94.0.0.1 > 94.0.0.2: AH(spi=0x00003d54,seq=0x126cb): ESP(spi=0x00003d55,seq=0x126cb), length 84
14:32:07.390311 IP 94.0.0.2 > 94.0.0.1: AH(spi=0x00005fb4,seq=0x1de): ESP(spi=0x00005fb5,seq=0x1de), length 84
14:32:08.389124 IP 94.0.0.1 > 94.0.0.2: AH(spi=0x00003d54,seq=0x126cd): ESP(spi=0x00003d55,seq=0x126cd), length 84
14:32:08.389294 IP 94.0.0.2 > 94.0.0.1: AH(spi=0x00005fb4,seq=0x1e0): ESP(spi=0x00005fb5,seq=0x1e0), length 84

Faire de même sur le serveur esclave.

Heartbeat

Heartbeat est le deamon qui teste la disponibilité des serveurs et qui, le cas échéant, permet de promouvoir un serveur en tant que maître.

Installation de Heartbeat

# apt-get install heartbeat chkconfig libsoap-lite-perl
Heartbeat not configured: /etc/ha.d/ha.cf not found.
Heartbeat failure [rc=1]. Failed.

Le message d’erreur est normal
Configuration de Heartbeat sur le serveur Maître : /etc/ha.d/ha.cf

ucast eth0 94.0.0.2

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 étant mort
deadtime 10
délai avant d’envoyer un avertissement pour les pouls en retard
warntime 6
deadtime spécifique pour les configurations où le réseau met un certain temps à démarrer
initdead 60

port à utiliser pour la prise de pouls
udpport 694

uname -n pour connaitre le nom des 2 serveurs
node master.exemple.fr
node slave.exemple.fr

met la valeur on, lorsque le node maître revient dans le cluster, tout est transféré sur ce dernier
auto_failback off

Configuration de Heartbeat sur le serveur Esclave : /etc/ha.d/ha.cf

ucast eth0 94.0.0.1

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 étant mort
deadtime 10
délai avant d’envoyer un avertissement pour les pouls en retard
warntime 6
deadtime spécifique pour les configurations où le réseau met un certain temps à démarrer
initdead 60

port à utiliser pour la prise de pouls
udpport 694

uname -n pour connaitre le nom des 2 serveurs
node master.exemple.fr
node slave.exemple.fr

met la valeur on, lorsque le node maître revient dans le cluster, tout est transféré sur ce dernier
auto_failback off

Dans notre cas, il est préférable d’utiliser auto_failback off pour éviter que le Maitre ne reprenne le contrôle sur l’Esclave. Par exemple, si le Maître redémarre de manière intempestive (problème électrique, de processeur ou de barrettes mémoires), il se verra attribuer le titre de maître et si les défaillances persistes, le cluster ne fonctionnera plus au bout de quelques transferts rapprochés.
Une fois le serveur Maître stabilisé, ce sera aux administrateurs remettre le cluster dans l’état convenable.

Définition des adresses publiques

Dans la configuration ci-dessous, vous avez besoin de remplacer nic-ovh et pass-ovh par votre identifiant et votre mot de passe du manager et nsID.ovh.net par le nom OVH du serveur maître afin que la bascule de l’IP failover puisse être réalisée de manière automatique.
Sur le serveur maître, dans le fichier /etc/ha.d/haresources

master.exemple.fr IPaddr2::91.0.0.30/32/eth0:0 failoverupdate.pl::nic-ovh/pass-ovh/nsIDMaster.ovh.net/91.0.0.30/94.0.0.1

Sur le serveur esclave, dans le fichier /etc/ha.d/haresources

master.exemple.fr IPaddr2::91.0.0.30/32/eth0:0 failoverupdate.pl::nic-ovh/pass-ovh/ns205505.ovh.net/91.0.0.30/94.0.0.2

Plusieurs commandes peuvent être mises en place en les séparant par un espace (apache, mysql, …).
Au niveau de l’IP Failover bien penser à vérifier le login et mot de passe OVH, ainsi que le serveur destinataire de l’adresse de l’IP Failover.

Sur les serveurs OVH, le manager doit être averti que l’IP Failover (adresse publique) doit pointer sur un serveur en particulier, ceci est réalisé au travers des scripts ci-dessous.
Script à déposer sur les 2 serveurs, dans le fichier /etc/ha.d/resource.d/failoverupdate.pl

#!/usr/bin/perl
#
#
	
		Description: Met à jour le manager OVH en lui indiquant le nouveau serveur vers
		             lequel faire l’ip failover
	
#

	
		Author:       Pierre PINTARIC
		License:      GNU General Public License (GPL)
	
#

#

	
		      usage: failoverupdate.pl ovh-nic/ovh-password/hostname/ip-failover/ip-routedTo
		         {start|stop}
	
#

	
		      L’argument “start” lance la négociation avec le manager OVH.
#

	use strict;

use warnings;

	use SOAP::Lite;

	sub usage() {
  print “usage: failoverupdate.pl ovh-nic/ovh-password/hostname/ip-failover/ip-routedTo {start|stop}\n”;

}

	if (@ARGV != 2) {
        usage();
        exit();

}

	my args = split('/', $ARGV[0]);
if (args != 5) {
        usage();
        exit();

}

	my $hostname = $args²;

my $ipfailover = $args³;

my $iproutedto = $args⁴;

	my $command = $ARGV¹;

	if (!($command =~ m/^(start|stop)$/)) {
        usage();
        exit();

}

	if ($command =~ m/^start$/) {
        my $soap = SOAP::Lite
                -> uri(‘https://soapi.ovh.com/manager’)
                -> proxy(‘https://www.ovh.com:1664’);

        #login
        my $nic = $args⁰;
        my $password = $args¹;
        my $language = ‘fr’;
        my $multisession = 0;

        my $result = $soap->call( ‘login’ => ( $nic, $password, $language, $multisession ) );

        if ($result->fault) {
                die $result->faultcode . ‘ ‘ . $result->faultstring . “\n”;
        } else {
                print “failoverupdate.pl : login successfull\n”;
        }

        my $session = $result->result();

        #dedicatedFailoverUpdate
        $result = $soap->call( ‘dedicatedFailoverUpdate’ => ( $session, $hostname, $ipfailover, $iproutedto ) );

        if ($result->fault) {
                die $result->faultcode.’ ‘.$result->faultstring.”\n”;
        } else {
                print “failoverupdate.pl : dedicatedFailoverUpdate successfull\n”;
        }

        #logout
        $result = $soap->call( ‘logout’ => ( $session ) );

        if ($result->fault) {
                die $result->faultcode.’ ‘.$result->faultstring.”\n”;
        } else {
                print “failoverupdate.pl : logout successfull\n”;
        }
}

Rendre le script exécutable et le place au bon endroit

# chmod a+x /etc/ha.d/resource.d/failoverupdate.pl

Sécurisation de Heartbeat

Sur les 2 serveurs, dans le fichier /etc/ha.d/authkeys

auth 2
1 md5 "Mot de passe à changer"
2 crc

Ne pas oublier de modifier le mot de passe.
Puis sécurisation de l’accès au fichier:

# chmod 600 /etc/ha.d/authkeys

Démarrage du deamon

# /etc/init.d/heartbeat start

Vérification du bon fonctionnement de Heartbeat

Il faut exécuter les actions suivantes:

Au travers d’un ifconfig vérifier que l’adresse IP publique a bien été prise en compte par un des serveurs
Se connecter en SSH sur l’adresse IP publique
Exécuter uname -n afin de connaître le nom du serveur sur lequel vous êtes connecté
Couper ce serveur (arrêt du serveur, coupure électrique ou coupure de l’interface réseau – à vous de choisir)
La fenêtre SSH ne doit plus répondre
Se reconnecter en SSH sur l’adresse IP publique au bout de 1mn30 (ce temps est dû au délai nécessaire à l’infra d’OVH pour basculer l’IP failover d’un serveur vers l’autre – vous pouvez vous aider d’un ping pour vérifier quand l’adresse IP publique répond de nouveau)
Exécuter uname -n afin de vérifier que le nom du serveur a bien changé (nous avons bien la bascule automatique d’un serveur vers l’autre)
Dans la fenêtre SSH exécuter /etc/init.d/heartbeat restart afin de rendre la main au serveur précédent
La fenêtre SSH ne doit plus répondre
au bout de 1mn30, se reconnecter en SSH sur l’adresse IP publique
Exécuter uname -n afin de vérifier que le nom du serveur est bien le premier que nous avions

Si cela ne fonctionne pas, il y a les logs à consulter, c’est très verbeux

Mise en place de DRBD

2 cas son possible, la partition sur laquelle vous désirez déposer les fichiers :

N’existe pas -> il faut la créer
Existe -> il faut supprimer son montage automatique

Création des partitions de réplication sur les 2 serveurs

Ceci est à réaliser si la partition de réplication n’existe pas et qu’il faille la créer.
Pour vérifier les partitions disponibles: fdisk -l
La taille des partitions doit être identique
Création des partitions (nous partons du principe que la partition que nous allons utiliser est /dev/sda3)

# cfdisk /dev/sda3

Les choix sont les suivants :

Primary
taille de votre choix
type Linux (code 83)
no bootable

Formatage de la partition /dev/sda3

# mkfs.ext3 /dev/sda3

Suppression du point de montage automatique de la partition de réplication sur les 2 serveurs

Ceci est à réaliser si la partition de réplication existe et qu’il faille supprimer son montage automatique.
Dans le fichier /etc/fstab, commentez la ligne contenant la partition devant servir à la réplication. Dans notre cas, il s’agit de la ligne

/dev/sda3      /home   ext3    defaults        1       2

Rebooter le serveur afin de vérifier que la partition ne monte pas automatiquement.

Intsallation de DRBD

Avant d’effectuer l’installation à proprement parlé, nous avons des paquetages Debian à installer

# apt-get install flex

Dans le dossier root, nous devons récupérer l’archive, la décompresser, la compiler et l’installer (la version courante lors de la rédaction de ce billet est DRBD 8.3.0, ceci doit être adapté en fonction de la version courante lors de votre installation)

# mkdir drbd
# cd drbd
# wget http://oss.linbit.com/drbd/8.3/drbd-8.3.0.tar.gz
# tar xzf drbd-8.3.0.tar.gz
# cd drbd-8.3.0
# make
# make install

Configuration de DRBD

La configuration doit être identique sur les 2 serveurs. Dans le fichier /etc/drbd.conf :

# drbd.conf
#
global {
   usage-count yes;
}
common {
   syncer {
      rate 20M;
      verify-alg sha1;
   }
}
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;
   }
   on master.exemple.fr {
      device /dev/drbd0;
      disk /dev/sda3;
      address 94.0.0.1:7788;
      meta-disk internal;
   }
   on slave.exemple.fr {
      device /dev/drbd0;
      disk /dev/sda3;
      address 94.0.0.2:7788;
      meta-disk internal;
   }
}

Si la taille de la partition n’est pas correcte pour DRBD (à l’étape suivante)

# dd if=/dev/zero bs=1M count=1 of=/dev/sda3; sync
1+0 enregistrements lus
1+0 enregistrements écrits
1048576 bytes (1,0 MB) copied, 0,0433103 s, 24,2 MB/s

Création des metadata

# drbdadm create-md r0
Writing meta data...
initialising activity log
NOT initialized bitmap
New drbd meta data block sucessfully created.
success

Ajout du module DRBD au noyau Linux

# modprobe drbd

Association de la ressource avec les devices

# drbdadm attach r0

Mise en place des paramètres de synchronisation

# drbdadm syncer r0

Connexion entre les serveurs (exemple sur le serveur maître)

# drbdadm connect r0

Afficher l‘état du cluster

# cat /proc/drbd
version: 8.3.0 (api:88/proto:86-89)
GIT-hash: 9ba8b93e24d842f0dd3fb1f9b90e8348ddb95829 build by [email protected], 2009-03-19 18:20:51
 0: cs:Unconfigured

Démarrage du daemon DRBD

# /etc/init.d/drbd start

A partir de maintenant nous ne travaillons que sur le serveur principal (master.exemple.fr).
Initialisation de la synchronisation (à réaliser uniquement sur le serveur principal)

# drbdadm -- --overwrite-data-of-peer primary r0

La synchronisation entre les serveurs peut-être suivie avec

# cat /proc/drbd
version: 8.3.0 (api:88/proto:86-89)
GIT-hash: 9ba8b93e24d842f0dd3fb1f9b90e8348ddb95829 build by [email protected], 2009-03-19 15:23:23
 0: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r---
    ns:65536 nr:0 dw:0 dr:65536 al:0 bm:3 lo:65 pe:0 ua:64 ap:0 ep:1 wo:b oos:621896016
        [>....................] sync'ed:  0.1% (607320/607384)M
        finish: 7:54:00 speed: 21,844 (21,844) K/sec

Durant cette synchronisation, la nouvelle partition /dev/drbd0 peut être utilisée. Formatage de la nouvelle partition:

# mkfs.ext3 /dev/drbd0

Attendre la fin du formatage pour passer à l‘étape suiavnte.

Mise en place du démarrage de DRBD au boot

Afin de permettre à DRBD de démarrer au moment du boot

# update-rc.d drbd defaults
 Adding system startup for /etc/init.d/drbd ...
   /etc/rc0.d/K20drbd -> ../init.d/drbd
   /etc/rc1.d/K20drbd -> ../init.d/drbd
   /etc/rc6.d/K20drbd -> ../init.d/drbd
   /etc/rc2.d/S20drbd -> ../init.d/drbd
   /etc/rc3.d/S20drbd -> ../init.d/drbd
   /etc/rc4.d/S20drbd -> ../init.d/drbd
   /etc/rc5.d/S20drbd -> ../init.d/drbd

Montage automatique de la partition avec Heartbeat

Sur le serveur maître, dans le fichier /etc/ha.d/haresources:

master.exemple.fr IPaddr2::91.0.0.30/32/eth0:0 failoverupdate.pl::nic-ovh/pass-ovh/nsIDMaster.ovh.net/91.0.0.30/94.0.0.1 drbddisk::r0 Filesystem::/dev/drbd0::/home::ext3

Sur le serveur esclave, dans le fichier /etc/ha.d/haresources:

master.exemple.fr IPaddr2::91.0.0.30/32/eth0:0 failoverupdate.pl::nic-ovh/pass-ovh/nsIDMaster.ovh.net/91.0.0.30/94.0.0.2 drbddisk::r0 Filesystem::/dev/drbd0::/home::ext3

Recharger la configuration sur les 2 serveurs :

# /etc/init.d/heartbeat restart

Vérification hebdomadaire des partition DRBD

La vérification de la bonne synchronisation des partitions est réalisée au travers la commande :

# drbdadm verify r0

Nous pouvons l’automatiser dans une commande exécutée hebdomadairement.
Dans le fichier /etc/cron.weekly/drbdverify

#!/bin/sh
drbdadm verify all

Puis il faut rendre le script exécutable :

# chmod a+x /etc/cron.weekly/drbdverify

En cas d’erreur, le fichier de log /var/log/syslog contiendra les erreurs rencontrées.

Voilà, votre cluster est en place. Bon courage, car ceci n’est que le début de votre aventure

9 réactions

1 De tdldp - 29/12/2009, 07:36

Bonjour

Petite question, ce tuto m'interesse car je dois repliquer en instantané des données d'un serveur en prod sur un autre à titre de sécu...

Est ce possible d'installer un cluster sur un serveur en prod (avec donc des données et un montage de partition déjà utilisé) avec un deuxieme serveur non utilisé à ce jour mais disposant d'une partition en taille strictement identique ???

Y'a t'il des précautions particulière à prendre ?

Merci pour votre réponse
2 De Pierre PINTARIC - 05/01/2010, 16:00

J'avoue que je ne me suis pas posé ce genre de question, étant donné les tests à réaliser pour vérifier que tout fonctionne correctement, les utilisateurs des serveurs en production risquent de ne pas apprécier (en tout cas, c'est mon cas).

En tout cas, à mon avis ce ne sera pas possible étant donné que la partition de données doit être réservée par DRBD et que par dessus il y a le format de disque système...

A mon avis le mieux est de partir sur de nouveaux serveurs et de se servir de l'IP Failover pour basculer les choses de manière transparente, ça permet surtout de faire tous les tests tranquillement...
3 De Ben - 03/06/2010, 10:36

Bonjour,

J'essaie de mettre en place votre solution (enfin la partie avec heartbeat), mais j'ai un problème lorsque j'essaie d'exécuter le script failoverupdate.pl qui me renvoi des erreurs.
Auriez vous une idée ?

Merci
4 De Pierre PINTARIC - 03/06/2010, 10:41

Peut-être que j'ai des idées, mais pour cela faudrait connaître les erreurs renvoyées...
5 De Ben - 03/06/2010, 14:42

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
6 De Marco - 06/06/2010, 18:44

Salut,

Merci pour le tuto,

Peux tu me dire, en ce qui concerne la reprise d'un sinistre qu'est ce qui se passe ?

Si le serveur 1 tombe est que le serveur 2 prend la main, lorsque le serveur 1 revient à la vie, que ce passe-t-il ? Le serveur 1 se resaynchronise au serveur 2 et une fois la synchronisation finie il reprend la main ?

Merci d''avance.
7 De Pierre PINTARIC - 09/06/2010, 15:56

Il est tout à faut possible de configurer le fait que le serveur 1 reprenne la main dès qu'il est up, mais je le déconseille.

Le tuto va dans ce sens aussi, en effet, pour peu qu'il y ait un problème de stabilité avec serveur 1, ce dernier ne va pas arrêter de prendre la main à chaque fois qu'il redémarrera, les services ne vont pas arrêter de basculer d'un serveur à l'autre et au final, DRBD va se mettre en erreur et plus rien ne va fonctionner.

Le mieux est vraiment d'avoir 2 serveurs avec des configurations identiques afin que les bascules soient transparentes. En cas de problème du serveur 1, il ne faut pas que ce dernier reprenne la main, mais il faut analyser pourquoi il est tomber en panne afin de corriger le problème et ainsi éviter les basculement intempestifs.
8 De freeco - 07/01/2011, 17:10

Il ya une erreur dans l'article. Ce n'est pas "Durant cette synchronisation, la nouvelle partition /dev/drbd1 peut être utilisée. Formatage de la nouvelle partition:"
mais
"Durant cette synchronisation, la nouvelle partition /dev/drbd0 peut être utilisée. Formatage de la nouvelle partition:"
9 De Pierre PINTARIC - 14/01/2011, 12:53

Merci pour l'information, cela a été corrigé dans le billet

PINTARIC & Co