Haute disponibilité

Les principes de haute disponibilité peuvent être utilisés dans de nombreux domaines. Pour le moment il ne sont pas encore en usage au laboratoire mais Benoit souhaite à terme installer deux serveurs DNS redondants.

Certes il possible d'avoir deux serveurs DNS: un primaire et un secondaire mais si le premier est en panne les machines essayeront quand même d'y accéder avant de tenter le second ( la chute de performance serais importante ).

Définition

La haute disponibilité correspond aux méthodes utilisées pour réduire au maximum les coupures du services en offrant une tolérance aux pannes la plus importante possible.

La haute disponibilité se joue du coté matériel avec l'utilisation d'onduleurs d'alimentations redondante ou de disques en RAID ainsi on augmente la disponibilité d'un serveur: Malgré ces précautions il peut toujours y avoir une panne.

Nous allons alors mettre en place des serveurs redondants avec Heartbeat et DRBD.

Lorsque l'on consulte par exemple des offres d'hébergeurs, certains peuvent annoncer "99% de disponibilité" ce qui représente plus de 3 jours de panne par an.

Pour parler du taux de disponibilité on cite parfois le nombre de 9: Celons la définition, on ne parle de "haute disponibilité" qu'a partir de trois 9, soit 99.9% de temps de fonctionnement soit au maximum 9 heures de panne par an.

Le réseau utilisé

Lien heartbeat

Installation des serveurs

Système d'exploitation

Les deux serveurs tournent sous MandrivaLinux 2006 en version stable mais il s'agit d'une maquette: les serveurs définitifs tournerons probablement sous une autre distribution

Prérequis

Comme nous faisons un cluster il faut disposer de deux serveurs.
Pour l'utilisation de heartbeat, il est conseillé d'avoir un lien très fiable pour la prise de pouls entre les deux machines. Il possible d'utiliser un simple câble série. Nous testons rapidement la liaison. 


[root@node1 ~]# echo salut > /dev/ttyS0
[root@node2 ~]# cat /dev/ttyS0
salut

DRBD

Présentation

On peut comparer DRBD (Distributed Replicated Block Device) à du RAID 1 à travers le réseau. Les données écrites sur un disque dur seront également écrites sur un autre disque. La différence viens du fait que les deux disques seront dans deux ordinateurs différents.

En plus d'offrir une sécurité de donnée en cas de panne d'un disque , ce programme permet également de passer d'un serveur à l'autre avec des données synchronisés.

Installation

Je n'est pas fait une installation depuis les sources mais directement avec les paquets fournis par Mandriva, ce programme a également besoin d'un module du noyeau pour fonctionner. Comme il est déjà présent sur Mandriva ont peut le charger simplement. modprobe drbd

Initialisation du disque

Les commandes données dans la partie si dessous ne sont qu'un "cas d'école" car elle permettent de comprendre les commandes lancés par DRBD: Par la suite nous utiliserons des scripts pour les automatiser.

J'ai mis commencé par cette façon en accord avec ce que je comprenais de la documentation que je possédait mais je n'ai pas tout de suite compris qu'elles ne marche qu'une fois. Après un redémarrage j'ai mis du temps à comprendre pourquoi plus rien ne fonctionnait

Choix de la partition

On commence par dire au système qu'elle partition servira de miroir pour le lecteur virtuel /dev/drbd0, la commande suivante va être effectuée sur les deux serveurs.

[root@node1 dev]# drbdsetup /dev/drbd0 disk /dev/hda6 internal -1

Mise en relation des 2 machines

A ce point les disques ne sont pas liés entre eux par le réseau, pour les lier nous allons une nouvelle fois utiliser la commande drbdsetup, la syntaxe est la suivante

drbdsetup périphérique_drbd net ip_locale ip_distante protocole

Dans la majorité des documentations il est conseillé d'utiliser le protocole "B". Cette option veut dire qu'une opération d'écriture seras considérée comme complète lorsqu'une confirmation de réception de la part de l'autre machine est reçue. Donc les commandes seront ( sur les deux machines )

[root@node2 dev]# drbdsetup /dev/drbd0 net node2.labo.fr node1.labo.fr B
[root@node1 dev]# drbdsetup /dev/drbd0 net node1.labo.fr node2.labo.fr B

Choix maître/esclave

Maintenant il faut choisir qu'elle machine seras maître. C'est elle qui pourra accéder la partiti

on DRBD.

Ce protocole ne servant pas aux partage de fichiers, seule la machine maître pourra à l'instant T y acceder. Dans notre cas node1 seras le maître.

[root@node1 ~]# drbdsetup /dev/drbd0 primary --do-what-I-say

L'option "--do-what-I-say" force la machine à devenir maître du cluster. Il ne faut plus l'utiliser un après la fin de sa mise en place.

Création système de fichiers

Il devient ensuite possible créer un système de fichiers comme sur n'importe qu'elle partition d'un disque dur

[root@node1 ~]# mkfs.ext3 /dev/drbd0

Vitesse de synchronisation

Si nous regardons dans /proc/drbd nous voyons qu'il est configuré et qu'une synchronisation est en train de ce faire. 


[root@node1 ~]# cat /proc/drbd
version: 0.7.11 (api:77/proto:74)
SVN Revision: 1807 build by fbl@matrix.conectiva, 2005-06-22 15:19:15
 0: cs:SyncSource st:Primary/Secondary ld:Consistent
    ns:381880 nr:0 dw:322252 dr:59696 al:126 bm:746 lo:0 pe:0 ua:0 ap:0
        [>...................] sync'ed:  0.6\% (11815/11873)M
        finish: 8:24:07 speed: 20 (228) K/sec
 1: cs:Unconfigured

Nous voyons que la vitesse maximale d'écriture pour synchroniser les données est seulement de 228Ko/sec, il est possible d'augmenter cette valeur en faisant la commande suivante sur l'un des deux hôtes: il faut veiller à ne pas choisir une valeur trop élevé pour éviter de surcharger le réseau.

[root@node1 ~]# drbdsetup /dev/drbd0 syncer -r 2048

Premiers essais

Avant d'utiliser les scripts pour initialiser DRBD à chaque démarrage il est possible de tester manuellement ce que ça donne.

A ce point heartbeat n'est pas encore fonctionnel donc nous simulerons pas encore de panne mais nous contenterons des verifier que les données sont bien synchronisés. Il convient de faire toutes les commandes à la main alors qu'elles serons exécutés par des scripts une fois Heartbeat fonctionnel

Comme DRBD ne peut être utiliser que sur une machine à la fois, démontons à la main le système DRBD

[root@node1 ~]# umount /mnt/drdb0/

Pour acceder aux données l'autre machine à besoin d'être declarée comme primaire.

[root@node2 ~]# drbdsetup /dev/drbd0 primary \end{verbatim}

Il deviens alors possible de monter le volume à la main

[root@node2 ~]# mount /dev/drbd0 /mnt/drbd0/

On constate que les fichiers depuis l'autre hôte sont bien là.

Configuration de DRBD

Les commandes si dessus doivent être éxécutés à chaque démarrage pour fonctionner. Pour l'usage courent nous allons maintenant renseigner /etc/drbd.conf pour qu'il lance automatiquement les commandes testé avant. Ce fichier basé sur celui que Benoit avait utilisé lors d'anciens essais DRBD est assez complet. Dans certaines documentations on ne retrouve pas les parties syncer, net, disk, et startup. 


resource r0 {
  protocol B;
  startup {
    wfc-timeout  0;
    degr-wfc-timeout 120;
  }

  disk {
    on-io-error   detach;
  }

  net {
    timeout 60;
    connect-int 10;
    ping-int 10;
    max-buffers 2048;
    max-epoch-size 2048;
  }

  syncer {
    # On choisit la vitesse de transfert entre les deux hôtes
    rate 10M;
    group 1;
    al-extents 257;
  }

  # On choisit les deux machines de cluster
  on node1.labo.fr {
    device     /dev/drbd0;
    disk       /dev/hda6;
    address    192.168.8.29:7788;
    meta-disk  internal;
  }

  on node2.labo.fr {
    device    /dev/drbd0;
    disk      /dev/hda6;
    address   192.168.9.44:7788;
    meta-disk internal;
  }
}

On remarque la reproduction des options qui étaient disponibles les lignes de commande avec drbdsetup

En revanche on remarque que l'on ne fait pas la différence entre maître et esclave à cet endroit.

Heartbeat

Présentation

Heartbeat est un logiciel qui doit être utilisé dans un cluster sur les deux machines: C'est un outil de surveillance qui permet de déterminer si l'autre machine avec qui il travaille est encore "en vie"

Hearbeat lui même ne fait rien mis à part surveiller l'autre machine; si un incident est détecté il lancera des scripts qui feront le reste du travail.

Installation

Encore une fois nous faisons une installation simplifiée avec urpmi. Mais nous ne pouvions pas démarrer le programme.


[root@node2 ha.d]# /etc/init.d/heartbeat start
Starting High-Availability services:
 Heartbeat failure [rc=1]. Failed.

heartbeat: 2006/03/08_15:33:47 ERROR: ERROR: cannot load generic interface manager plugin 
	[InterfaceMgr/generic]: No such plugin/interface/interface type
heartbeat: 2006/03/08_15:33:47 ERROR: Heartbeat not started: module init error.

Je n'est pas était capable de résoudre ce problème seul, Benoit m'a aidé et à réussit à trouver la solution avec la commande strace, il fallait installer heartbeat-pils.

Configuration

Les fichiers de configuration de Heartbeat sont identiques sur toutes les machines du cluster.

Il faut choisir les délais avant de détecter que l'autre machine est en panne.


keepalive 1
deadtime 3
hopfudge 1

Nous allons utiliser le lien série pour les prises de pouls. On détermine lequel utiliser ainsi que la vitesse de transfert 

serial  /dev/ttyS0
baud    19200

Le lien ethernet est également utilisé pour la surveillance. Il faut choisir quelle port UDP et quelle carte réseau utiliser 


udpport 1001
bcast   eth0

La consultation des fichiers logs vas aider a comprendre les actions effectués par hearbeat lorsqu'un problème est detecté


debugfile /var/log/ha-debug
logfile /var/log/ha-log
logfacility     local0

Le principal est /etc/ha.d/ha.cf: Il définit les machines du cluster


node    node2.labo.fr
node    node1.labo.fr

Le second fichier important est /etc/ha.d/haresources, il sert à déterminer quelle machine est maître ainsi que les scripts à lancer en cas de prise de contrôle du cluster

node1.labo.fr IPaddr::192.168.8.126 drbddisk mount_drbd

Dans ce cas node1.labo.fr va être le maître et 192.168.8.126 va l'IP commune du cluster, les autres arguments de lignes correspondent aux scripts éxecutés lors de la prise de contrôle

La scripts à lancer serons dans /etc/ha.d/resource.d/ et doivent être compatibles avec le LSB ( Linux Standard Base ), cette norme garanti que les scripts pourront être lancés en utilisant les options start, stop et status pour connaître l'état du service.

Par exemple lorsqu'un machine prend possession du cluster elle va commencer par effectuer la commande /etc/ha.d/resource.d/drbddisk start

Test de Heartbeat

Examens du cache ARP

Une fois heartbeat lancé nous allons faire des tests pour voir comment il se comporte mais avant cela nous allons examiner le cache ARP d'un poste client 


[root@alpes ~]# arp | grep cluster-eqsys
cluster-eqsys.labo.fr   ether   00:A3:14:96:ED:45   C        eth0

L'adresse MAC si dessus est celle de node1 sur ca carte réseau


eth0      Link encap:Ethernet  HWaddr 00:A3:14:96:ED:45
          inet addr:192.168.8.29  Bcast:192.168.9.255  Mask:255.255.254.0

Simulation de panne

Nous allons maintenant eteindre node1 pour voir comment node2 prend la main sur le cluster. Pour mieux comprendre ce qui ce passe, il faut consulter les logs de heartbeat dans /var/log/ha-log


heartbeat: 2006/03/09_14:52:49 info: Link node1.labo.fr:/dev/ttyS0 dead.
heartbeat: 2006/03/09_14:52:49 info: Link node1.labo.fr:eth0 dead.

Heartbeat a détecté que les deux liens sont morts: Si un seul lien aurait était coupé le logiciel aurait considéré que la machine fonctionne encore et n'aurait pas pris le cluster.


heartbeat: 2006/03/09_14:52:50 info: Acquiring resource group: node1.labo.fr
	 IPaddr::192.168.8.126 drbddisk mount_drbd apache

On reconnais ce qu'on avons mis /etc/ha.d/haresources qui est executé


heartbeat: 2006/03/09_14:52:50 info: /sbin/ifconfig eth0:0 192.168.8.126
	 netmask 255.255.254.0  broadcast 192.168.9.255

Mise à jour ARP

Il configure l'interface eth0:0 qui est un alias, la carte réseau auras donc deux addresse IP.


heartbeat: 2006/03/09_14:52:50 info: Sending Gratuitous 
	Arp for 192.168.8.126 on eth0:0 [eth0]

heartbeat: 2006/03/09_14:52:50 /usr/lib/heartbeat/send_arp -i 1010 -r 5 -p
/var/lib/heartbeat/rsctmp/send_arp/send_arp-192.168.8.126  
	eth0 192.168.8.126 auto 192.168.8.126 ffffffffffff

La commande "send_arp" est importante car elle oblige les machines à mettre à jour leur cache ARP.

Il y auras une même IP, l'adresse MAC aura changé. On peut vérifier que le contenu du cache ARP a était modifié sur la machine cliente.


[root@alpes ~]# arp | grep cluster-eqsys
cluster-eqsys.labo.fr   ether   00:A3:14:96:F3:C6   C   eth0

Il reste alors à regarder la configuration IP de node2 pour voir qu'il reste accesible avec son ancienne adresse IP mais qu'il en à aussi une nouvelle, il faut également noter qu'une fois encore il y a correspondance des adresses MAC avec le cache ARP.


[root@node2 ~]# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:A3:14:96:F3:C6
          inet addr:192.168.9.44  Bcast:192.168.9.255  Mask:255.255.254.0
          inet6 addr: fe80::2f0:1def:fb96:b3c6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:131632 errors:0 dropped:0 overruns:0 frame:0
          TX packets:38012 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:18290392 (17.4 MiB)  TX bytes:6889783 (6.5 MiB)
          Interrupt:11 Base address:0xe000

eth0:0    Link encap:Ethernet  HWaddr 00:A3:14:96:F3:C6
          inet addr:192.168.8.126  Bcast:192.168.9.255  Mask:255.255.254.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:11 Base address:0xe000

Dans cette configuration, dés que l'ancien maître revient en ligne, il reprend la main sur le cluster.

Mon

La solution si dessus peut être efficace lors d'une panne matérielle mais elle ne peut pas détecter le "plantage" sur un service DNS ou HTTP par exemple.

Le programme "MON" est constitué d'un ensemble de scripts permettant de vérifier qu'un service ( http, dns, ... ) répondent bien aux requêtes: Si le service est détecté comme mort le programme mon va arrêter heartbeat et l'autre machine ne recevant plus de réponses aux prises poul va décider de prendre l'adresse du cluster.

Je n'est pas fait moi même cette dernière partie, j'ai juste observé Benoit quand il a essayé.

Conclusion

Bien que cette solution de "Haute Disponibilité" soit intéressante elle ne représente pas une solution ultime pour deux raisons

Pas de Load Balancing

Cette solution n'est pas en mode "actif-actif" c'est à dire qu'elle n'offre pas de répartition de charge entre plusieurs machines si elle n'est pas assez puissante pour supporter toutes les requêtes.

Au début Benoit avait pensé utiliser SARU http://www.ultramonkey.org/papers/active_active/ car il permettait aux deux machines du cluster d'être actives en même temps. Malheureusement ce projet donc le dévelopement ne semble pas très avancé ne dispose pas de beaucoup de documentation et nous n'avons pas réussit à le faire fonctionner, il semble qu'il ne soit compatible qu'avec la noyaux 2.4.x

Seulement deux machines

Le logiciel HeartBeat à était prévu pour fonctionner entre deux machines. Elle ne peuvent malheureusement pas être plus dans un même cluster

Ce document proviens de mon rapport de stage de seconde année de Bac Pro MRIM. Il a était éffectué dans un laboratoire de recherche. Les serveurs sur lequels j'ai installé ces outils n'ont pas était mis en service. Le seul but était de me permetre d'aprendre



Page générée en 0,7015 s