Suite au billet d'introduction sur la haute-disponibilité, voici le premier cas concret par la mise en place d'un serveur Samba sur un cluster à deux noeuds.
Cette première partie présentera le principe de basculement en faisant "flotter" l'adresse IP d'un serveur à l'autre.
Présentation du cluster
Ce type de cluster est le plus simple à mettre en place. Il consiste à utiliser deux machines, si possible identiques, et d'assurer un service quelconque ( samba, apache,… ) en continu. A un instant t un seul serveur est actif, en cas de défaillance, le service bascule sur l'autre serveur. Il n'y a pas de répartition de la charge.
Comme il est dit dans l'introduction sur la haute-disponibilité, le cluster doit être accessible par une adresse IP unique. Pour cela il faut en fait associer un service à une IP. Cette approche permet de s'affranchir de savoir quelle machine héberge quel service. Il suffit donc d'utiliser les adresses IP secondaires. Linux permet d'attribuer autant d'adresses IP secondaires que nécessaire sur une même carte réseau. Ainsi si l'on souhaite rendre disponible 3 services sur le cluster à deux noeuds, il faudra créer trois adresses secondaires.
Il est fait appel à deux composants logiciels :
- HEARTBEAT, qui assure la surveillance des deux nœuds du cluster et la bascule des services,
- DRBD, qui permet de synchroniser les données des deux disques via le réseau, on parle aussi de raid 1 sur IP.
Le schéma suivant montre la configuration.
Le pointillé indique l'adresse IP du cluster qui sera active sur l'un ou l'autre des noeuds. Cette bascule de l'IP est assurée par heartbeat. L'interface sera eth0. L'autre interface réseau sera eth1 et dédié à heartbeat, voir explication plus loin.
Pour tester cette configuration, le service mis en place sera Samba.
Remarque : Pour cette configuration, je suis parti de serveurs ne disposant que d'un disque dur et j'ai partitionné le disque en conséquence, notamment une partition /data de 20Go qui sera répliquée par DRBD. Il est prudent d'utiliser une partition vierge pour la mise en place de drbd, car afin de faciliter l'implantation le filesystem sera détruit. Un prochain billet présentera une solution avec DRBD sans destruction des données présentes.
Heartbeat
Il s'agit d'un composant logiciel important dans les solutions à haute disponibilité. Sa fonction est de prendre le pouls ( battement de cœur ) des nœuds du cluster et de décider si il y a lieu ou non de basculer les services. Pour cela, chaque noeud via heartbeat envoie des requêtes en udp sur le port 694 à l'autre noeud afin de tester sa présence. La surveillance des noeuds peut se faire soit par le réseau directement, soit par une carte réseau dédiée ( cable croisé ) , soit par le port série.
Le package heartbeat peut sembler désuet aujourd'hui, mais dans cette étude de cas il est suffisant, fiable, robuste et moi ça ne me dérange pas les "trucs vieillots qui marchent" !
La technique la plus fiable est via le port série en utilisant un cable null-modem. Ceci implique que les machines soient dans le même endroit, car une liaison RS232 est limité à quelques mètres.
Vu le prix d'une carte réseau ( il est inutile de prendre un GigaBit ), il est souhaitable de dédier une interface à heartbeat et de relier les deux noeud par un cable RJ45 croisé. Avec cette technique les machines peuvent être situées dans des pièces différentes.
Il existe deux versions de heartbeat, la première ne permet que la gestion de 2 noeuds et sera donc employé ici. la version 2 permet de gérer des cluster jusqu'a 16 noeuds. La version 2 est plus complexe à configurer car elle utilise un fichier XML. Dans le cas d'un cluster à 2 noeuds la version 1 de heartbeat est suffisante.
L'installation sous Debian est classique.
aptitude install heartbeat
Il est nécessaire de configurer 3 fichiers pour le fonctionnement correct de heartbeat. Ces trois fichiers doivent être identiques sur les deux nœuds du cluster. Ils sont situés dans le répertoire /etc/ha.d.
- ha.cf : le fichier principal de configuration, il décrit ce qui existe,
- haresources : défini les ressource du cluster pour lesquelles il faut assurer la disponibilité, ce qui doit exister et donc qui est “vu”,
- authkeys : défini la méthode d'authentification des nœuds. Ce fichier n'est pas obligatoire mais il permet de sécuriser l'ajout d'une machine dans le cluster.
Fichier ha.cf
bcast eth1 udpport 694 debugfile /var/log/ha-debug.log logfile /var/log/ha.log logfacility local0 keepalive 2 deadtime 10 warntime 6 initdead 60 node debian01 node debian02 auto_failback off respawn hacluster /usr/lib/heartbeat/ipfail
La directive bcast envoie les paquets udp sur l'interface eth1, qui est l'interface dédié à heartbeat. Il est possible de préférer le multicast au broadcast en utilisant plutôt la directive suivante ( la directive udpport n'est pas nécessaire alors ) :
mcast eth1 239.0.0.10 694 1 0
Si vous souhaitez utiliser une liaison série il faut rajouter les deux lignes suivantes :
baud 19200 serial /dev/ttyS0
Il est tout à fait possible de combiner les deux modes, réseau et série ( autre exemple de configuration ) :
bcast eth1 udpport 694 baud 19200 serial /dev/ttyS0 debugfile /var/log/ha-debug.log logfile /var/log/ha.log logfacility local0 keepalive 2 deadtime 10 warntime 6 initdead 60 node debian01 node debian02 auto_failback off respawn hacluster /usr/lib/heartbeat/ipfail
La directive udpport ( non utile si utilisation du multicast ) précise que le port utilisé est le 694, qui est la valeur par défaut. Il est souhaitable de configurer le fichier /etc/services en ce sens en rajoutant la ligne suivante :
heartbeat 694/udp # gestion heartbeat
Les 3 lignes suivantes concernent la gestion des fichiers de log, très utiles surtout au début.
Les unités des 4 directives suivantes sont exprimées en secondes.
- keepalive indique le temps entre 2 battements de coeur,
- deadtime le temps pour déclarer un noeud mort,
- warntime est un warning, utile dans le cas d'une supervision,
- initdead, doit être au minimum supérieur à 2 fois deadtime et n'est utilisé que lors du démarrage du cluster.
Les valeurs indiquées dans cet exemple fonctionnent parfaitement en production.
Les noms spécifiés dans la directive node doivent être le résultat de la commande uname -n. De plus chaque noeud doit pouvoir résoudre les noms. Le plus simple est de configurer correctement le fichier /etc/hosts.
127.0.0.1 localhost 192.168.1.100 debian01 192.168.1.101 debian02 …
La directive auto_failback off permet en cas de bascule du cluster sur debian02 de ne pas rendre la main au nœud debian01 quand celui-ci est de nouveau opérationnel. Il est fréquent qu'un nœud défaillant soit redémarré plusieurs fois avant d'être pleinement actif et sans cette directive, le cluster basculerait sans cesse.
La directive respawn hacluster /usr/lib/heartbeat/ipfail, permet de détecter un débranchement de la carte réseau.
Fichier haresources
Il ne contient que la ligne suivante :
debian01 IPaddr::192.168.1.102/24/eth0:0
Ce n'est pas une erreur, cette configuration indique que debian01 est le noeud qui acquiert les ressources au démarrage et qu'il porte l'IP flottante du cluster. Lors de la mise en place de drbd et de samba, cette ligne sera complétée.
Remarque : Certains tutoriaux heartbeat simplifie cette ligne ainsi :
debian01 192.168.1.102
Toutefois la syntaxe ci-dessus est plus robuste et permet de spécifier, le masque de sous réseau et quelle interface prend l'IP secondaire. IPaddr est un script qui permet la mise en place de l'IP virtuelle. Heartbeat est fournit avec un certains nombre de scripts qui se trouvent dans le répertoire /etc/ha.d/resource.d. Il existe un script IPaddr2 qui doit être utilisé si le système fournit la commande ip. Lors de la mise en place du cluster a répartion de charge, nous verrons la principale différence entre ces deux scripts.
Note : Le fichier haresources n'existe plus dans la version 2 de heartbeat, il est remplacé par un fichier xml.
Fichier authkeys
Ce fichier facultatif introduit une sécurisation entre les noeuds du cluster. Il est possible d'utiliser différents modes. Le plus simple, crc, ne fait que vérifier la non-corruption des paquets reçus. Il est possible de renforcer la sécurité en utilisant les directives md5 ou sha1.
auth 1 1 crc
Autre exemple
auth 1 1 sha1 motsecret
Il est impératif de changer les permissions de ce fichier.
chmod 0600 /etc/ha.d/authkeys
Les 3 fichiers, ha.cf, authkeys et haresources doivent être identiques sur les deux noeuds du cluster. Une fois la configuration faite, lancer heartbeat sur les deux noeuds.
/etc/init.d/heartbeat start
Patienter au moins 15 secondes avant de tester via ifconfig. Si tout ce passe bien la commande ifconfig sur debian01 doit retourner un résultat de ce type :
ifconfig eth0 Link encap:Ethernet HWaddr 00:c0:a8:7e:2b:93 inet adr:192.168.1.100 Bcast:192.168.1.255 Masque:255.255.255.0 adr inet6: fe80::2c0:a8ff:fe7e:2b93/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:54037 errors:0 dropped:0 overruns:0 frame:0 TX packets:52585 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 RX bytes:12625468 (12.0 MiB) TX bytes:12530967 (11.9 MiB) Interruption:22 Adresse de base:0xd400 eth0:0 Link encap:Ethernet HWaddr 00:c0:a8:7e:2b:93 inet adr:192.168.1.102 Bcast:192.168.1.255 Masque:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interruption:22 Adresse de base:0xd400 lo Link encap:Boucle locale inet adr:127.0.0.1 Masque:255.0.0.0 adr inet6: ::1/128 Scope:Hôte UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Sur debian02, la même commande ne montre pas eth0:0. Pour tester le fonctionnement de heartbeat, il suffit d'arrêter debian01 ( stopper heartbeat produit le même effet ) et de passer la commande ifconfig sur debian02 pour vérifier que maintenant ifconfig renvoie le résultat ci-dessus. Lors du redémarrage de debian01 celui-ci restera en attente de la défection de debian02 et ce en raison de la directive auto_failback off ( Attention, cette directive est à on par défaut ).
En cas d'erreur, consulter les fichiers de log. le plus souvent il s'agit d'une erreur de frappe dans l'un des fichiers de configuration.
La seconde partie présentera la mise en place de DRBD et son intégration avec HEARTBEAT.
