Construisez un cluster HA avec Heartbeat, ENBD et le Raid Logiciel Introduction

Transcription

1 Construisez un cluster HA avec Heartbeat, ENBD et le Raid Logiciel Article publié dans le hors série spécial Haute Disponibilité du GNU/Linux Magazine France, numéro 18 (Février/Mars 2004). Introduction Vous avez peut être déjà été confronté au délicat problème de devoir garantir l'accès à des services réseaux critiques hébergés sur une machine ; Par exemple, un serveur web (Apache), un serveur de fichiers (Samba, Ftp) ou encore l'indispensable serveur de mails de votre entreprise (Postfix). Votre patron vous a prévenu : Si vos estimés collègues ne peuvent plus accéder à ces services, la productivité de votre entreprise va baisser et votre crédibilité va subir un sérieux coup d'arrêt (comment ça, la porte?). La contrainte posée vous impose de réagir promptement. Il vous faut en effet trouver une architecture rétablissant la disponibilité des services le plus rapidement possible en cas de panne et ce pour un coût raisonnable (c'est si souvent le cas). Si les finances de votre entreprise vous autorisent à maintenir un serveur de secours, une bonne façon de traiter efficacement le problème est d'installer à l'identique (système et configuration inclus) les mêmes services sur les deux machines (celle de secours et celle de production) afin de pouvoir démarrer à la demande l'un ou l'autre de ces serveurs. On démarre les services sur le serveur de production : Si ce dernier est indisponible, on passe sur le serveur de secours. Il existe plusieurs façons de migrer les services sur le noeud de secours en considérant que leurs points communs sont les données utilisées par vos services : Le contenu du site web pour le serveur HTTP, les données de votre société pour le serveur de fichiers ou encore les mails reçus ou à envoyer. Les données de votre serveur de production doivent en effet pouvoir être accessibles sur le serveur de secours lorsque ce dernier prend la relève : Démarrage à froid du serveur de secours : On déplace physiquement les disques durs contenant les données du serveur de production vers le serveur en attente (éteint) et on le démarre. Cela impose de dédier un disque pour le système dans chaque serveur et de placer toutes les données sur un sous-ensemble de disques que l'on va pouvoir déplacer indifféremment d'un serveur à l'autre ; On réplique à chaud les données du serveur de production vers le serveur de secours : Le serveur de secours est démarré en utilisant une adresse IP différente du serveur de production. Les données sont régulièrement (ou en temps réel) répliquées sur le serveur de secours. En cas de perte du serveur de production, on démarre les services sur le serveur en attente en prenant l'identité du serveur de production ; Les données sont présentes sur un seul support (une baie de disques par exemple) et sont partagées entre les deux machines. On parle alors de cluster en Haute Disponibilité (cluster HA) en redondance à froid ou à chaud (le terme cluster peut être traduit par grappe en français : Il désigne plusieurs machines offrant un seul et même service). Dans tous ces cas de figure, le passage d'un serveur à un autre doit être le plus transparent possible (il ne faut pas trop perturber le service vis à vis des postes clients) : Il est pour cela fortement conseillé d'utiliser le principe des adresses IP flottantes. Linux permet en effet d'associer plusieurs adresses IP à ses interfaces de façon dynamique (on parle d'alias réseaux) : Chaque machine possède sa propre adresse IP unique sur le réseau ainsi, et c'est là tout l'intérêt, que les services. La machine qui héberge un ou plusieurs services récupère aussi leur adresse IP ce qui permet de s'abstraire complètement de leur localisation physique sur le réseau. L'avantage des deux dernières solutions concerne la rapidité de rétablissement des services : La première solution est fortement dépendante du facteur humain et n'offre donc aucune souplesse. Si personne n'est présent dans les locaux pour s'occuper de cette opération, les services ne pourront pas être réactivés à temps. Elle présente néanmoins une alternative intéressante avec un effort de

2 configuration minimum (si le débit réseau entre les deux machines est trop faible, le principe même de réplication des données entre serveurs pourra être remis en question et donc imposer directement cette solution). La première solution est donc triviale à mettre en oeuvre et vous conviendrez qu'il n'est pas nécessaire d'aller plus loin dans sa description. Elle est utilisée principalement pour des applications non critiques qui s'accommodent très bien d'un arrêt de service à durée variable. La deuxième et troisième solution sont de fait celles les plus souvent mises en oeuvre pour les applications critiques : La migration des services (et des adresses IP) est alors généralement traitée par le programme Heartbeat [1] (un article lui est dédié dans ce numéro). Cette application permet de démarrer des services à la demande sur un cluster en redondance à chaud : Les services sont généralement démarrés sur un seul noeud du cluster (un noeud est le terme pour désigner une machine du cluster) ; Les deux noeuds se surveillant mutuellement par l'intermédiaire de connexions séries ou réseaux pour réagir en cas d'interruption du service. Ce programme garantie à chaque application de tourner de façon unique sur un seul des noeuds du cluster (unicité du service) : En cas de perte du noeud qui héberge les services, le noeud de secours récupère les adresses IP et redémarre les applications (il est aussi possible d'équilibrer la charge en partageant les services à égales mesures entre les deux noeuds). Nous venons de voir comment nous allons pouvoir déplacer automatiquement nos services d'un noeud à un autre grâce au logiciel Heartbeat. Il nous reste à aborder les différentes solutions permettant de répliquer les données entre les noeuds et décrire dans le détail celle que nous avons sélectionnée pour satisfaire la disponibilité de nos services (et garantir la sécurité de notre emploi!). Le choix de la technique de réplication dépend de la fréquence de mise à jour des données : Vos données sont modifiées ponctuellement comme c'est par exemple le cas d'un serveur HTTP : On va privilégier dans ce cas une synchronisation régulière des données dans la CRONTAB du système par l'intermédiaire du programme rsync (quitte à provoquer volontairement la synchronisation lorsque les données sont mises à jour) ; Vos données sont modifiées fréquemment mais de façon non régulière comme cela arrive sur un serveur de fichiers : Le système de fichiers distribué Intermezzo [2] est adapté à ce type de situation et propagera toutes les modifications sur la machine de secours. On accepte dans ce cas de perdre des données dans un volume raisonnable : La mise à jour est asynchrone ; Le débit de modification de vos données est soutenu et il est hors de question de perdre ne serait ce qu'une transaction (par exemple, dans le cas d'un serveur de mails ou d'une base de données) : La réplication des données est donc obligatoirement synchrone (on parle de mode en transaction+1 : On accepte uniquement de perdre la dernière transaction en cours). Dans cette dernière famille, il existe au moins trois approches distinctes : La réplication réseau en utilisant le driver drbd [3] : Une solution fiable et élégante qui est traitée séparément dans ce numéro ; L'utilisation du système de fichiers opengfs [4] ou tout autre méthode de partage de baie [5] pour partager une seule et même unité de stockage entre plusieurs machines : Puissant mais coûteux à mettre en oeuvre ; L'utilisation du RAID logiciel (un article lui est consacré dans ce numéro) pour maintenir l'intégrité entre les données locales et les données présentes sur un serveur distant (en exportant un device réseau) : C'est une façon ludique et peu habituelle de répliquer les données entre deux serveurs mais qui n'en est pas moins très efficace. C'est cette conjonction entre le RAID en mode miroir et la possibilité donnée au noyau Linux de pouvoir exporter un device bloc à travers le réseau, en utilisant une version améliorée du driver NBD (Network Block Device), que nous avons choisie de vous proposer dans la suite de cet article.

3 Présentation du driver ENBD Avant de pouvoir répliquer des données sur un serveur distant (le noeud de secours dans notre cluster), il faut d'abord nous y procurer un accès. Nous allons pour cela utiliser une fonctionnalité du noyau Linux qui nous autorise à exporter un device bloc à travers le réseau comme nous le ferions avec un système de fichiers en utilisant le très classique NFS (Network File System). La différence de taille se situe dans la façon dont les données sont échangées : Là où NFS exporte des fichiers ou des répertoire (la couche haute), nous allons pouvoir exporter les blocs de données (la couche basse) du disque distant. Historiquement, le driver permettant d'obtenir ce résultat sous Linux s'appelle NBD (acronyme de Network Block Device) écrit par Pavel Machek. Les principes ont été décrit dans un article du numéro 54 du LM. Ce dernier est disponible en ligne au format PDF sur [6]. NBD permet donc à une machine cliente de travailler sur un disque distant comme si nous disposions de ce dernier en local dans la machine ; Les blocs de données transitant par le réseau de façon absolument transparente pour les applications. Vous pouvez vous représenter ce principe par un tuyau reliant votre machine client à votre machine serveur : Tout vous est permis ou presque du moment que vous intégrer la latence et la bande passante naturellement réduite que peut vous offrir ce type de solution. Sauf disposer d'une connexion réseau exceptionnelle, vous n'obtiendrez pas les performances habituelles que vous pouvez obtenir en écrivant directement sur un disque local. Un autre point en faveur du driver NBD est la possibilité d'exporter non seulement un disque entier ou une partition, mais aussi un fichier (ou plusieurs fichiers/partitions en agrégeant les données). Cela va nous permettre de faire des tests sans nous imposer une configuration matérielle spécifique. Outre le driver nbd présent dans le noyau, nous disposons de deux démons client/serveur (nbd-client et nbd-server) qui vont s'occuper de transporter les données par le réseau entre nos deux machines. Le site officiel du driver NBD est disponible sur [7]. A ce stade, vous commencez sans doute à entrevoir la façon dont nous allons mettre en place notre architecture en Haute Disponibilité dans un cluster Heartbeat : Si nous pouvons créer une partition locale sur notre noeud de production et disposer d'un accès à une partition identique localisée sur le noeud de secours, l'utilisation du raid logiciel de type miroir (raid 1) va nous permettre de mettre à jour à la fois les données locales mais aussi et surtout les données présentes sur le disque distant. En cas d'indisponibilité du serveur principal, il ne restera plus qu'à redémarrer les services réseaux sur le serveur de secours pour rétablir la continuité du service : Juste le temps de détecter la panne et redémarrer les applications. Notre cahier des charges est rempli : Rétablir la disponibilité des services le plus rapidement pour un coût raisonnable (pas besoin de disposer de serveurs de haut de gamme dans ce cas). Tout serait parfait si le driver NBD présent dans les différentes versions du noyau Linux depuis la version 2.2 ne possédait pas quelques restrictions rédhibitoires dans notre utilisation comme couche transport d'un miroir raid. Il n'a en effet pas été prévu à l'origine pour fonctionner dans ce type de configuration très spécifique (même si il reste un bon choix dans une utilisation plus standard). C'est là qu'intervient le driver ENBD (Enhanced Network Block Device) : Il s'agit d'une version améliorée du driver NBD qui propose quelques améliorations majeures nous intéressant au plus haut point. Pour résumer brièvement, les modifications les plus importantes par rapport au driver original sont : Architecture asynchrone qui permet d'équilibrer la charge entre plusieurs connexions socket ; Authentification, redémarrage et reconnexion automatique des démons ; Possibilité de cryptage de la communication par SSL (Secure Socket Layer) ; Possibilité d'agréger les devices ou les fichiers coté serveur en miroir ou en striping ; Support pour les ioctls distants ; Support pour les périphériques amovibles de type cdrom ou disquette ;

4 Support pour le partitionnement du device distant (coté client) ; Et enfin, depuis la version du driver ENBD, support d'un driver raid intelligent permettant de réduire le volume de données à transporter entre le serveur et le client dans le cas d'un dysfonctionnement. Nous verrons la mise en place d'une telle solution à la fin de cet article. L'auteur du driver ENBD s'appelle Peter T. Breuer. Il maintient un site complet et très intéressant accessible sur [8]. Ce driver est le résultat d'un financement privé dans le cadre de recherches universitaires afin de développer une version plus industrielle et plus performante du driver original. Il était intéressant de le signaler. L'installation nécessite une phase de compilation (sous root) pour disposer de la version la plus récente du programme (il y a peu de chance que votre distribution contienne une version packagée). Adaptez le fichier Makefile à votre configuration (variables SMP et LINUXDIR). Vous devez en outre disposer des sources du noyau et des outils de développement GNU installés : # tar xzvf enbd tgz # cd enbd # make config all # make install Exporter une ressource locale à une machine consiste uniquement à lancer le programme serveur nbdserver (le démon serveur ne fait pas appel au driver enbd : Cela offre encore un peu plus de souplesse) : # enbd-server 8090 /root/disque1.iso -i test-ha -b 2048 Si vous souhaitez tester les exemples, il vous faudra au préalable créer un fichier en utilisant la commande dd : # dd bs=512 count=10000 if=/dev/zero of=/root/disque.iso Le prototype (simplifié) de la commande coté serveur est : # enbd-server <port> <ressources> [-l -[0 1]] [-i <auth>] [-b <size>] Le tableau suivant présente les principales options du démon serveur. Consultez le manuel (man) pour des informations plus exhaustives et plus détaillées : Options Description -l On passe plusieurs ressources locales de type disques, partitions ou fichiers que l'on souhaite agréger pour ne présenter au final qu'une seule et même ressource -0 A utiliser conjointement à l'option -l : Permet d'agréger les ressources en mode striping (le driver écrit en boucle sur toutes les ressources pour équilibrer la charge) -1 A utiliser conjointement à l'option -l : Permet d'agréger les ressources en mode miroir (les données sont dupliquées sur toutes les ressources) -i <auth> On spécifie une chaîne de caractères permettant de gérer l'authentification de la connexion du client et filtrer ainsi les connexions non désirées (nécessite un paramétrage similaire coté client). La taille peut atteindre 128 caractères. Par défaut, une signature aléatoire est générée (il est donc important de ne pas oublier cette option)

5 Options Description -b <size> Taille de blocs en octets que l'on souhaite exporter : Le principe même de NBD est de transporter sur le réseau des blocs de données présentes sur un disque ; Ce paramètre est donc essentiel et peut correspondre à la taille des blocs réels sur disque. La valeur par défaut est 1024 Coté client, il nous faut d'abord charger le driver enbd : # modprobe enbd A tout moment, vous pouvez consulter l'activité du driver en affichant le contenu du fichier virtuel / proc/nbdinfo et éventuellement le contenu du répertoire /proc/sys/dev/enbd. Il est possible de dialoguer avec le driver : Cela va nous être très utile pour la mise en place de notre cluster HA. Un bon moyen, par exemple, pour supprimer toutes les connexions réseaux consiste à initier la commande suivante : # echo 0 > /proc/nbdinfo La valeur 1 permet de forcer à zéro le compteur de référence du module enbd dans le noyau ce qui facilite son déchargement selon les circonstances (voir aussi la commande lsmod). Pour modifier un des nombreux paramètres du driver, on assigne une valeur à une commande sur tous les devices ouverts (deuxième exemple) ou sur un device en particulier (première exemple avec une lettre désignant le device). La valeur est comprise entre 0 et 1 : # echo commande[lettre]=valeur > /proc/nbdinfo # echo commande=valeur > /proc/nbdinfo Quelques commandes intéressantes : enable : On active ou désactive le ou les devices ; Dans le cas d'une agrégation des ressources en miroir (options «-l -1») : setfaulty : On simule la panne d'un device ; hotremove : On supprime à chaud un nouveau device ; hotadd : On ajoute à chaud un nouveau device. Consulter le man (man nbdinfo) pour consulter l'ensemble des options disponibles. L'accès au driver s'effectue par l'intermédiaire d'un fichier spécial, de type bloc, qui va nous permettre de disposer localement des ressources présentes sur le serveur distant. Ce fichier est de numéro majeur 43 et de numéro mineur compris entre 0 et 128 (petit rappel : tout est fichier sous Linux, en particulier l'interface de communication de l'espace utilisateur vers l'espace noyau). Si vous utilisez une distribution qui utilise devfs, les fichiers spéciaux qui vont nous permettre d'accéder à la ressource distante seront automatiquement disponibles sous : /dev/nb/[x]/[y] (ou [x] est une lettre représentant le device et [y] correspond soit à un numéro de partition, soit à l'ensemble de la ressource par la valeur 0). Pour les distributions plus classiques, il vous faudra éventuellement créer ces fichiers si ceux ci sont absents du répertoire /dev. Il est nécessaire d'en créer au moins un : # mknod /dev/nb0 b 43 0 Il nous reste à lancer le programme client enbd-client pour établir la communication réseau avec le serveur distant (je considère pour la démonstration que devfs n'est pas activé sur la machine cliente) : # enbd-client [serveur]:8090 -n 4 -i test-ha -b e /dev/nb0

6 Le prototype (simplifié) de la commande coté client est : # enbd-client <host>:<port> [-n <nb>] [-e] [-i <auth>] [-b <size>] <device> Si vous disposez de plusieurs accès physiques entre le client et le serveur, vous pouvez spécifier plusieurs noms réseaux aboutissant à la même machine (alias IP) : En conjonction avec plusieurs canaux de communications, cela peut améliorer grandement les performances et la disponibilité. Pour obtenir à peut près le même résultat, vous pouvez aussi utiliser le Channel Bonding présenté dans ce hors-série. Le tableau suivant présente les principales options du démon client. Consultez le manuel (man nbdclient) pour des informations plus exhaustives et plus détaillées : Options Description -n <nb> Nombre de canaux de communication que le client va ouvrir sur le réseau avec le serveur. Une valeur de 4 donne de bons résultats -e Permet de répercuter les erreurs directement sur une couche de haut niveau de type LVM ou RAID. Indispensable dans notre architecture -i <auth> On spécifie une chaîne de caractères permettant de gérer l'authentification du client vis à vis du serveur. La valeur doit être évidemment identique à celle configurée sur le serveur -b <size> Taille de blocs en octets que l'on souhaite importer : Le client et le serveur négocient une taille de bloc qui est la valeur maximum des deux valeurs Nous pouvons désormais utiliser le fichier spécial /dev/nb0 comme n'importe quel périphérique de type bloc. On peut formater le device ou utiliser une couche d'abstraction de plus haut niveau comme LVM ou encore du RAID logiciel. C'est cette dernière possibilité que nous allons utiliser pour implémenter notre cluster HA. Si vous disposez d'une partition locale /dev/hdb sur le noeud principal (machine de production) et d'une partition distante de même capacité sur le noeud secondaire (machine de secours), vous pouvez aisément créer un tuyau virtuel entre les deux serveurs par l'intermédiaire de la chaîne de communication enbd pour disposer en local de la partition distante en passant par le device /dev/nb0. Répliquer les données sur les deux noeuds devient un jeu d'enfants en utilisant le raid logiciel proposé en standard sous Linux (driver MD). Il reste à créer un miroir avec les devices /dev/hdb (local) et / dev/nb0 (distant) pour dupliquer en temps réel les données clients sur les deux noeuds du cluster. La perte du serveur principal pourra être compensée en montant la partition survivante puis les services réseaux sur le noeud de secours. Lorsque le noeud principal rejoindra de nouveau le cluster, il suffira alors de synchroniser les données du serveur de secours sur le disque local du serveur principal. Ce n'est qu'à ce moment précis que le cluster ne sera plus considéré comme fonctionnant en mode dégradé : Il sera de nouveau prêt à supporter la perte d'un noeud. Mise en place de notre solution Heartbeat est le mécanisme qui va nous permettre de détecter la perte d'un noeud dans notre cluster et relancer automatiquement les services sur le noeud survivant. Le driver enbd nous fournit un moyen sûr pour disposer en local d'une ressource distante de type bloc (la partition d'un disque dur, par exemple). Pour finir, le raid logiciel est la solution technique qui nous permet de synchroniser les données entre les deux noeuds du cluster : La ressource locale présente sur le noeud principal et la ressource distante localisée sur le noeud secondaire (accessible justement par l'intermédiaire du driver enbd). A partir de ces trois briques de base, nous pouvons mettre en oeuvre une solution garantissant la haute

7 disponibilité de nos applications même, et surtout, en cas de dysfonctionnement d'un des noeuds du cluster. La configuration du cluster se fait donc en quatre étapes (sur une machine que nous allons appeler "maitre" et une autre "esclave") : On configure une ressource locale à chaque machine (un disque, une partition,...) et on rend accessible sur la machine principale (par le réseau) la ressource présente sur le serveur secondaire : driver enbd ; On synchronise sur le noeud maître les deux ressources locales et distantes (miroir raid) et on formate la partition ainsi créée avec un système de fichiers journalisé (ext3, reiserfs, xfs ou jfs). On monte la partition sur le répertoire /appli ; On installe les services réseaux que l'on souhaite rendre hautement disponible sur chaque machine du cluster : Apache, Samba, Postfix... (les données seront toutes centralisées sur un même point de montage, dans notre cas /appli) ; On configure Heartbeat sur chaque noeud du cluster pour démarrer les services et gérer les différentes transitions du système. Nous avons déjà vu comme utiliser enbd pour disposer localement sur le noeud principal d'une ressource présente sur le noeud secondaire. Nous allons supposer que la ressource partagée est un fichier monté en loop-back sur le device /dev/loop0 (voir la commande losetup). Sur le noeud principal, on considère que la ressource du noeud secondaire est disponible sur le device /dev/nb0. Il nous faut maintenant utiliser le raid logiciel pour synchroniser les données : Référez-vous à l'article sur le raid logiciel pour savoir comment installer et utiliser cet outil (uniquement sur le noeud principal). Le client et le serveur enbd doivent être démarrés sur l'une et l'autre des machines. Créez sur le noeud principal un fichier /etc/raid-enbd.conf (évitez d'utiliser le fichier standard / etc/raidtab car c'est la couche Heartbeat qui doit lancer le raid et non les scripts de démarrage de votre distribution) : raiddev /dev/md0 raid-level 1 nr-raid-disks 2 nr-spare-disks 0 chunk-size 32 persistent-superblock 1 device /dev/loop0 raid-disk 0 device /dev/nb0 raid-disk 1 Exécutez ensuite les commandes suivantes :

8 # modprobe raid1 # mkraid -c /etc/raid-enbd.conf /dev/md0 On formate la partition (ici en ext3) et on la monte sur /appli : # mke2fs -j /dev/md0 # mount /dev/md0 /appli Configurez ensuite les services réseaux que vous souhaitez déployez en migrant les données dans le répertoire /appli, seul répertoire virtuellement commun aux deux noeuds du cluster. La dernière étape consiste à configurer Heartbeat. Ce travail vous sera grandement facilité par le dynamisme de la communauté du libre : Matthew Sackman maintient sur son site [9] des scripts permettant de configurer Heartbeat exactement dans le sens que nous l'entendons. Cerise sur le gateau : Peter T. Breuer intègre depuis la version de ENBD une copie retouchée de ces scripts dont nous allons nous inspirer dans notre architecture (l'approche choisie ne nous ayant pas totalement convaincue). Dans la suite de cet article, nous allons considérer que le programme est correctement installé ; En cas de nécessité, consultez l'article sur Heartbeat présent dans ce même numéro. Sur chaque noeud, éditez le fichier /etc/ha.d/haresources : esclave enbd-secondary maitre enbd-primary apache samba postfix... Remplacez les services par celui ou ceux que vous voulez rendre disponibles. La machine «maitre» ( ) est le noeud principal de votre cluster alors que la machine «esclave» ( ) est le noeud secondaire. Ils correspondent aux valeurs retournées par la commande «uname -n» sur chaque machine. Les adresses IP correspondent à celles qui seront associées aux différents scripts selon leurs localisations : Dans le cas qui nous intéresse, les services Apache, Samba ou encore Postfix seront donc constamment accessibles sur l'adresse IP (ils sont par ailleurs lancés dans cet ordre). Ces adresses IP étant flottantes entre les deux machines, il faut que chaque serveur possède sa propre adresse IP fixe. Les scripts enbd-primary et enbd-secondary (exécutés en priorité avant les services) sont destinés à être exécutés par Heartbeat pour lancer ou déplacer les services sur l'un ou l'autre des noeuds selon l'état du cluster. Ils sont copiés dans le répertoire /etc/ha.d/resources.d/. Nous avons associé une adresse IP ( ) au service enbd-secondary : Cela n'est pas utile théoriquement mais cela s'est révélé nécessaire pour le bon fonctionnement du cluster (!). Pensez à créer aussi les fichiers ha.cf et authkeys dans /etc/ha.d/. Pour comprendre comment peut fonctionner la migration des services entre nos deux machines, il nous faut d'abord balayer l'ensemble des transitions possibles. C'est généralement la première étape à faire dans ce type de configuration, même si ce travail a déjà été fait pour nous. La vision que peut avoir Heartbeat d'un cluster est relativement limitée (même si elle reste suffisante dans notre contexte) : Si un noeud est accessible, il est considéré comme actif (UP) ; Si ce n'est pas le cas, il est considéré comme inactif (DOWN). Les états intermédiaires à l'intérieur d'un noeud (perte d'un disque ou état des interfaces, par exemple) doivent être traités directement dans les scripts : Heartbeat n'offre aucune facilité de ce type.

9 Une table des transitions entre le noeud principal et le noeud secondaire va nous permettre de déterminer le comportement attendu des scripts enbd-primary et enbd-secondary. L'état implique évidemment que le service n'est plus disponible alors que l'état correspond à un fonctionnement optimal du cluster. Il nous reste alors à décrire quatre transitions dans lesquelles Heartbeat va initier des actions sur le ou les noeuds actifs : Transition (1)-(2) : Dans ce premier cas de figure, c'est le noeud principal qui devient inactif. Théoriquement, en cas de crash, ce dernier n'a pas le temps d'exécuter quoi que ce soit. On doit néanmoins prévoir les actions à mener dans le cas d'un arrêt manuel (à ce stade, Heartbeat est sensé avoir arrêté les services critiques) : fuser -muk /appli umount /appli raidstop --configfile /etc/raid-enbd.conf /dev/md0 echo "0" > /proc/nbdinfo killall --signal=term enbd-client Le noeud secondaire doit ensuite réagir en stoppant le serveur ENBD et en montant la ressource locale au serveur. On utilise à cette occasion une fonctionnalité intéressante du Raid 1 : On peut monter en direct un volume du miroir ; La couche RAID n'est donc pas nécessaire sur le noeud secondaire (ce qui nous simplifie grandement la vie). Les services critiques seront automatiquement relancés sur le serveur secondaire et accessibles sur l'adresse IP On considère que le cluster fonctionne alors en mode dégradé (il n'aura plus droit à l'erreur). killall --signal=term enbd-server sleep 2 mount -t ext3 /dev/loop0 /appli Transition (2)-(1) : Le noeud principal redevient actif. Les services critiques sont arrêtés sur le noeud secondaire et la ressource locale est démontée. Pour que le noeud secondaire retrouve sont rôle au sein du cluster, il est nécessaire de redémarrer le serveur ENBD : # fuser -muk /appli # umount /appli # enbd-server i test-ha -b 2048 /dev/loop0 Le noeud principal doit ensuite réagir en synchronisant la ressource locale (obsolète) avec la ressource distante présente sur le noeud secondaire (les services critiques sont alors redémarrés et l'adresse IP retourne sur le noeud principal) :

10 modprobe enbd enbd-client esclave:8090 -n 4 -b e -i test-ha /dev/nb0 sleep 10 mkraid --really-force --dangerous-no-resync \ --configfile /etc/raid-enbd.conf /dev/md0 raidsetfaulty --configfile /etc/raid-enbd.conf /dev/md0 /dev/loop0 raidstop --configfile /etc/raid-enbd.conf /dev/md0 raidstart --configfile /etc/raid-enbd.conf /dev/md0 raidhotadd --configfile /etc/raid-enbd.conf /dev/md0 /dev/loop0 mount -t ext3 /dev/md0 /dev/md0 /appli Transition (1)-(3) : Cette fois ci, c'est le noeud secondaire qui n'est plus accessible. Tout comme dans la transition (1)-(2), ce dernier n'a théoriquement pas le temps d'exécuter quoi que ce soit en cas de crash. Prévoyons les actions à mener dans le cas d'un arrêt volontaire : killall --signal=term enbd-server sleep 2 Les services restent sur le noeud principal et n'ont pas besoin d'être stoppés, même temporairement (pas d'arrêt de services). Ce dernier doit cependant supprimer la ressource distante présente dans son miroir et arrêter le client ENBD. Le cluster fonctionne alors en mode dégradé (un seul noeud actif) : raidsetfaulty --configfile /etc/raid-enbd.conf /dev/md0 /dev/nb0 raidhotremove --configfile /etc/raid-enbd.conf /dev/md0 /dev/nb0 echo "0" > /proc/nbdinfo killall --signal=term enbd-client Transition (3)-(1) : Le noeud secondaire est réintroduit dans notre cluster. C'est la transition la plus délicate car il va falloir réintroduire la ressource distante tout en s'assurant que cette dernière a été redémarré avant sur le noeud secondaire. Action à mener d'abord sur le noeud secondaire : enbd-server i test-ha -b 2048 /dev/loop0 Actions à mener ensuite sur le noeud principal. Le ressource distante va se synchroniser sur les données (à jour) présentes en local : echo "1" > /proc/nbdinfo rmmod enbd modprobe enbd enbd-client esclave:8090 -n 4 -b e -i test-ha /dev/nb0 sleep 10 raidhotadd --configfile /etc/raid-enbd.conf /dev/md0 /dev/nb0 Heartbeat ne nous facilite pas la vie pour mettre en oeuvre cette dernière transition. En effet, le script enbd-secondary va d'abord être stoppé sur le noeud principal pour ensuite être démarré sur le noeud secondaire. Difficile dans ce cas de réaliser dans l'ordre souhaité les deux actions présentées ci dessus (le client enbd sera en effet toujours démarré avant le serveur ce qui va entraîner un problème!). Pour contourner ce problème, nous allons extraire le démarrage du serveur ENBD du logiciel Heartbeat : Si nous pouvons lancer automatiquement le serveur enbd au démarrage de la machine secondaire (avant Heartbeat), la transition (3)-(1) sera triviale à mettre en oeuvre. Une solution générique consiste à créer un script de démarrage conforme à la norme système V :

11 #!/bin/bash # /etc/init.d/enbd-server # ### BEGIN INIT INFO # Provides: enbd-server # Required-Start: $network # Required-Stop: $heartbeat # Default-Start: 3 5 # Default-Stop: # Description: Démarrer automatiquement le serveur ENBD ### END INIT INFO case "$1" in start) enbd-server i test-ha -b 2048 /dev/loop0 ;; stop) killall -signal=term enbd-server ;; *) echo "Usage: $0 [start stop]" exit 1 esac Nous voulons appeler notre script juste après le chargement de la couche réseau dans les runlevels 3 et 5 (l'option -d permet de désactiver le démarrage du script) et juste avant Heartbeat (uniquement sur le noeud secondaire) : # chkconfig -s enbd-server 35 Cela nous permet de soulever une bonne question : Que va-t-il se passer lors du premier démarrage? Le noeud secondaire va démarrer son serveur enbd automatiquement sans action de la part de la couche Heartbeat. Le noeud principal va alors réagir comme dans le cas de la transition (2)-(1) : Il va chercher à synchroniser ses données avec celles du noeud distant. A chaque démarrage du cluster, toutes les données du serveur secondaire seront donc transférées sur le serveur principal (à moins de modifier profondément les scripts pour prendre en compte ce cas de figure). Ceci n'est gênant que pour le premier démarrage du cluster : Il est ensuite fortement conseillé de ne jamais arrêter volontairement et manuellement les deux serveurs en même temps. Si vous souhaitez malgré tout arrêter les deux machines, stoppez d'abord le noeud principal et ensuite, après quelques minutes, le noeud secondaire (lors d'un arrêt de maintenance demandant l'immobilisation simultanée des deux noeuds). Ne démarrez en tous les cas jamais le noeud principal sans le noeud secondaire (risque élevé de perte d'intégrité des données). L'inverse ne posant pas de problème, il est malgré tout conseillé de d'abord démarrer le noeud secondaire puis, quelques minutes plus tard, le noeud principal pour éviter des problèmes éventuels de synchronisation. Résumons un peu la situation : Transition Étape Machine Commande exécutée par Heartbeat (1)-(2) (1)-(3) maître esclave esclave maître enbd-primary stop enbd-primary start enbd-secondary stop enbd-secondary start

12 Transition Étape Machine Commande exécutée par Heartbeat (2)-(1) (3)-(1) esclave maître maître esclave enbd-primary stop enbd-primary start enbd-secondary stop enbd-secondary start Il est donc assez facile de concevoir les scripts enbd-primary et enbd-secondary en utilisant les commandes que nous avons décrites plus haut. Les scripts doivent pouvoir tenir compte de la machine sur laquelle ils sont lancés : Inspirez vous des scripts fournis en standard même si vous pouvez trouver une archive complète (tous les scripts utilisés dans cet article ainsi que ceux mettant en oeuvre Heartbeat) mise à disposition par votre serviteur sur [10]. Avant de finir Nous avons vu comment, en mélangeant plusieurs technologies (Raid, enbd et Heartbeat), nous pouvons mettre en place une architecture solide garantissant la disponibilité de nos services en cas de dysfonctionnement d'un des noeuds de notre cluster. Le seul point noir de l'architecture concerne la synchronisation par le réseau des données après la perte d'un noeud. Toutes les données du noeud survivant devront être mises à jour sur le noeud temporairement indisponible. Cela prend forcément un peu de temps ; Temps proportionnel à la taille des données à transférer et à la capacité du réseau : Il s'agit donc de correctement dimensionner vos données pour réduire au minimum ce temps de synchronisation. Cela peut devenir rédhibitoire dans le scénario plausible où l'une de vos machine doit être déconnectée temporairement du réseau pour une action de maintenance légère (changement d'une carte par exemple). Une solution apportée par Peter T. Breuer consiste à améliorer le driver raid standard livré dans le noyau Linux pour éviter de re-synchroniser l'ensemble du device mais uniquement les blocs qui ont changés entre-temps. On parle alors du driver intelligent fr1 pour «Fast Raid1» [11]. Ce dernier ce décompose en deux parties : un module md.o qui va se substituer à celui présent dans votre distribution (celui ci doit donc être préalablement compilé en module dans votre noyau) et un nouveau driver fr1.o. Vous pouvez tester localement ce miroir intelligent sur deux fichiers montés en loop-back (se référer pour cela à l'article sur le Raid qui utilise cette technique). Chargez les deux modules (md.o et fr1.o) et construisez un fichier de configuration /etc/raidtab mettant en oeuvre les devices /dev/loop0 et / dev/loop1 en prenant garde à ne pas activer le super-bloc persistant. Si vous désactivez un volume du miroir avec la commande raidsetfaulty suivi de la commande raidhotadd, vous indiquez au driver de réparer à chaud les données manquantes sur le device et non l'ensemble des données (ce fonctionnel est justement nouveau dans le driver fr1) : # raidsetfaulty /dev/md0 /dev/loop0 # raidhotadd /dev/md0 /dev/loop0 Si vous utilisez au milieu la commande raidhotremove, vous indiquez au driver de synchroniser l'ensemble des données : # raidsetfaulty /dev/md0 /dev/loop0 # raidhotremove /dev/md0 /dev/loop0 # raidhotadd /dev/md0 /dev/loop0

13 Si vous souhaitez utiliser cette fonctionnalité dans les scripts enbd-primary et enbd-secondary, il vous faudra bien entendu modifier ces derniers. Cela peut se révéler très utile à l'usage même si on peut facilement s'en passer en améliorant la performance du réseau entre les deux noeuds. Ce driver est par contre très jeune et il n'est pas conseillé de l'utiliser en production. Lionel Tricon Références [1] Heartbeat : [2] Inter-mezzo : [3] DRBD : [4] OpenGFS : [5] Cluster Kimberlite : [6] Article LM54 sur NBD : [7] Network Block Device : [8] Enhanced Network Block Device : [9] File system redundancy with RAID, heartbeat and ENBD : [10] Scripts utilisés : [11] Fast Raid1 driver :