La Haute Disponibilité Ph. Sèvre le 26/10/2012

Quelques chiffres 99% de dispo : 3,6 j HS /an 99,9 % de dispo : 8,76 h HS /an 99,99 % de dispo : 52 mn HS /an 99,999 % de dispo : 6 mn HS /an 99,9999 % de dispo : 30 s HS /an

Les clusters à haute disponibilité (High Availability) ce sont des clusters qui permettent un fonctionnement à 100 % : solution de reprise sur incident on dispose généralement d’une machine maître et d’une machine de backup disposée à prendre le relais en cas de problème à un instant donné la charge de travail est effectuée par la seule machine maître (habituellement fonctionnement actif/passif)

La reprise sur incident (Fail-Over) C’est le procédé qui permet à un serveur de prendre le relais d’un autre en cas de panne il utilise une liaison ( HeartBeat) qui envoie périodiquement des informations de diagnostic avec le protocole UDP sur une interface dédiée (ethernet ou série) en cas de problème de liaison avec le nœud distant, la machine effectue un IP-FAILOVER qui consiste à prendre une adresse IP réservée et à lancer les services qui tournaient sur l’autre machine (ex service httpd start)

La reprise sur incident : Fail-Over permet de prendre le relais en 10 s maxi fonctionne sous Linux (package heartbeat)

Terminologie : le Split-Brain Se produit quand plusieurs éléments d’un cluster essaient de prendre le contrôle du cluster Peut produire des effets catastrophiques (p.e. écriture simultanée sur un même volume)

Terminologie : Fencing Consiste à dresser une barrière pour empêcher un nœud devenu incontrôlable d’accéder aux ressources du cluster. Utilisation de STONITH : Shoot The Other Node In The Head (p.e. piloter l’onduleur de l’autre nœud)

Terminologie : le Quorum Permet de d’éviter le split-brain en s’assurant qu’un seule partition est active à un moment donné

Terminologie : ressource critique Une ressource est dite critique quand sa panne empêche le fonctionnement du système entier Appelée SPOF : Single Point Of Failure Une bonne conception HA évite les ressources critiques (=> Redondance)

La HA Maitre mot : REDONDANCE

L’application HeartBeat Existe depuis des années (1998) Plus de 30 000 en production Très fiable Développeur principal embauché par IBM Version 2 : avec Gestionnaire de Resources Cluster (CRM) et interface graphique

L’accès aux données - 1 problème : l’accès aux données . Pour que le schéma précédent fonctionne il est impératif que chacun des nœud puisse disposer des mêmes données : quelques solutions partage NFS : peu recommandé baie de stockage SCSI externe utilisée par un seul nœud à un moment donné SAN avec périphériques FC-AL solution GFS (Global File System) sur un serveur dédié

L’accès aux données - 2 Synchronisation logicielle avec Rysnc (faisable avec un lien dédié Gigabit) Ddrbd: (~Raid 1 réseau) Attention au problème de cohérence et d’accès simultané de deux programmes à une même ressource : Dual Head quelques solutions Stonith : Shoot The Other Node In The Head WatchDog : par carte matérielle ou interruption noyau : arrête/redémarre le système si non désarmé au bout d’un temps

Présentation L’application HeartBeat permet de mettre en œuvre un cluster à haute disponibilité sous Linux Heartbeat permet à une seconde machine de prendre le relais presque instantanément en cas de problème sur la machine active HeartBeat est utilisable pour tous les protocoles classiques (www, ftp, mail, pop3, smb, DNS, …)

Exemple : cluster à haute disponibilité avec Samba

Le fonctionnement - 1 Les deux serveur sont reliés par un ou deux liens dédiés appelé heartbeat (Ethernet ou série) qui vont permettre de détecter une interruption de service sur l’autre machine Les deux serveurs disposent chacun d’une adresse IP (!) et d’un alias IP qu’ils se partagent : à un moment donné l’alias n’est activé que sur une machine. Le serveur actif écoute sur l’alias partagé et non pas sur son adresse propre Le serveur passif polle en UDP le serveur actif toutes les 10 s sur le lien heartbeat

Le fonctionnement - 2 Si le serveur inactif ne reçoit pas de réponse sur le heartbeat, il envoie un paquet ARP gratuit pour informer les clients de la nouvelle adresse MAC associée à l’alias et il active l’alias puis lance le ou les services associés (httpd, smb, ftp, …) Les clients vont alors être en liaison avec le serveur qui a pris le relais Remarque : si le protocole est un protocole orienté connxion (smb , smtp, pop3, etc) : le client devra alors se reconnecter. Attention aux informations de session (cookies) en http

Le fonctionnement – 3 Heartbeat peut fonctionner maintenant en mode Actif/Actif Il gère également avec ipfail la connectivité avec les autres machines/routeurs du réseau et peut déclencher le basculement automatique sur l'esclave

La Configuration de heartbeat 3 fichiers : /etc/ha.d/ha.cf /etc/ha.d/haresources /etc/ha.d/authkeys

Le fichier ha.cf serial /dev/ttyS0 # pour le heartbeat série udp eth1 # indique l’interface du heartbeat. keepalive 2 # délai entre les heartbeats deadtime 10 # un nœud est considéré comme mort après 10 s. baud 19200 # débit du heartbeat série. udpport 694 # N° port 694 pour udp. Le standard. auto_failback off # Optionnel. L  e maître garde les ressources jusqu’au failover , at which time the slave takes over. Q uand le maître revient en ligne, il récupère tout de l’esclave si la valeur est à On,. La vaeleur off empêche le maître de reprendre les ressources après un failover. node linuxha1.linux-ha.org # nœud correspond à ‘uname –a’ node linuxha2.linux-ha.org # idem

Le fichier haresources Haresources doit être identique sur les 2 nœuds Exemple de haresources                   linuxha1.linux-ha.org 192.168.85.3 httpd smb La ligne ci-dessus spécifie : Au démarrage le serveur linxha1.linux-ha.org utilise l’adresse 192.168.85.3 et lance apache et samba. Lors de l’arrêt, heartbeat coupe d’abord samba, puis apache, et libère l’adresse IP.  Note:  httpd et smb sont les scripts de démarrage d’Apache et Samba .  Heartbeat cherche les scripts dans les répertoires suivants :  /etc/ha.d/resource.d puis /etc/rc.d/init.d Les scripts doivent lancer les services avec «nomscript start" et les arrêter avec "nomscript stop". Il est possible d’utiliser tous les services possibles du moment qu’ils respectent les informations ci-dessus.

Le fichier authkeys Il comporte les clés d’authentification (3 méthodes : crc, md5 et sha1) Si le réseau est sécurisé (câble croisé) on peut utiliser CRC.  La méthode standard est MD5, SHA1 est pour les paranoïaques. Format du fichier : auth <number> <nombre> <méthode> [<clé>] Par exemple, pour sha1 : auth 1 1 sha1 « valeurdelaclé » Pour md5, il suffit de rmplacer sha1 par md5. Pour crc, on aura : auth 2 1 crc Les permissions doivent être en 600 pour root !

Lancements et tests Lancer heartbeat : service heartbeat start Arrêter heartbeat : service heartbeat stop Tests : Une fois le heartbeat lancé, la commande ifconfig doit donner la configuration de eth0 et de eht0:0 (Alias) Pour tester il suffit de couper le serveur maître et de voir ce qui se passe , l’esclave prend l’alias IP et prend le relias du maître

La synchronisation des données Heartbeat n’assure pas la synchronisation des données, il faudra donc envisager une solution pour que le nouveau serveur dispose des données utilisateur Quelques pistes : Partage NFS (peu recommandé : fiabilité moyenne) Utilisation de DRBD : Distributed Data Block Device (RAID 1 réseau) Baie ou disque SCSI partagé (1 seul accès en écriture à un moment donné) SAN avec switch FC-AL (cher !) Synchronisation logicielle au moyen de rsync Solution GFS (Global File System) avec un serveur de stockage

La synchronisation avec rsync - 1 Rsync est une solution open-source très efficace pour effectuer de la synchronisation de données Rsync permet de mettre à jour des fichiers/répertoires ayant changé sur deux machines mais il ne transfère que les parties de fichiers ayant changé et non la totalité du fichier => ce qui diminue la BP utilisée Il est très utilisé pour les miroirs de site web et FTP Il est disponible en rpm pour toutes les distributions Il existe une version Win32 de rsync

La synchronisation avec rsync – 2 Mise en œuvre : Rsync peut être lancé périodiquement avec une commande cron Le plus simple est d’utiliser un tunnel ssh pour le transfert des données (on créera une clé publique sur le client que l’on exportera sur le serveur maître) Exemple : rsync -az -e ssh master:/home/ /home Remarque : pour Samba, il faudra également synchroniser les fichiers /etc/passwd, /etc/group et smbpasswd

La synchronisation avec rsync – 3 Remarque : Il sera également nécessaire de prévoir des scripts pour synchroniser le maître depuis l’esclave : En effet quand le maître sera à nouveau en ligne, il devra récupérer les nouveaux fichiers depuis l’esclave.

Les tests Ils sont stratégiques mais complexes : Tester la panne de chaque nœud Tester la panne de chaque ressource Tester également dans toutes les conditions de charge

HA et PRA HA Peu cher Contraintes géographiques Temps de basculement court PRA Tres cher Temps de basculement long

Informations Linux-ha.org : une mine d’or

TP Sur 2 machines virtuelles, mettre en oeuvre un cluster HA Apache à contenu statique Tester et examiner les logs Puis modifier pour utiliser une BD et une replication de la BD DRBD