Systèmes à haute disponibilité sous Linux

ArticleCategory: [Choose a category for your article]

System Administration

AuthorImage:[Here we need a little image form you]

TranslationInfo:[Author and translation history]

AboutTheAuthor:[A small biography about the author]

Atif est un caméléon. Il change de rôle, passant d'Administrateur Système, à programmeur, professeur, chef de projet, ou quoi que ce soit d'autre permettant l'aboutissement d'un travail.
A l'occasion, vous pouvez le trouver en train de programmer ou d'écrire de la documentation sur son portable assis sur le siège des toilettes. Atif pense qu'il doit beaucoup à Linux, à la communauté open source et à ses projets pour lui avoir servi de professeur. Pour en savoir plus, consultez sa page personnelle

Abstract:[Here you write a little summary]

Dans le cadre d'une mission sur des systèmes critiques, que ce soit au stade de la conception ou lors de l'installation physique des boîtes, câbles, etc... il faut se poser les questions suivantes :

Quelle est l'importance des services qui vont tourner sur ces machines?
Combien d'autres services dépendent du service qui va être fourni par ces machines (pensez aux serveurs NIS/NFS/DB/LDAP)?
Que se passe-t-il si une partie de la machine tombe en panne. (alimentation ,câble réseau, disque dur, etc)?
Que se passe-t-il si la machine tombe complètement en panne?

Quand je me pose ces questions, j'obtiens la même réponse la plupart du temps.
Je serais viré :)

D'un autre coté, lorsque je me pose la question "Le système d'exploitation va-t-il tomber en panne?" j'obtiens toujours cette réponse.
Non. Tu n'utilises pas l'extension 32 bits d'un patch 16 bits pour un système d'exploitation 8 bits codé à l'origine pour un microprocesseur 4 bits, écrit par une compagnie 2 bits, qui ne peut supporter 1 bit de concurrence. ( j'ai eu ça à partir d'un .sig)

Maintenant, soyons sérieux.

ArticleIllustration:[This is the title picture for your article]

High Availability systems under Linux -- Image borrowed from http://lwn.net/Gallery/i/suits.gif

ArticleBody:[The article body]

Pourquoi HD?

Même si je crois aveuglément en Linux, je ne fais pas confiance aux sociétés qui fabriquent les machines, alimentations, cartes réseaux, cartes mères, etc... et j'ai toujours peur que si l'une d'elles tombe en panne, mon système devienne inutilisable. Le service sera alors indisponible, sans parler du fait que je vais arrêter tous les services de l'entreprise, même ceux qui n'y sont pas liés directement. Par exemple :

Certains services, que je ne connais même pas, qui ne me concernent pas, peuvent devenir instables: ils ne permettent pas de trouver billingSys106.company.com. Hmmmm, laissez moi réfléchir... Quelle peut en être la raison? Oh! J'étais responsable du DNS et malgré les règles de la société, j'ai décidé de l'installer sous Linux. :)
Ou bien, quelqu'un ne peut utiliser le système SAP car mon serveur LDAP est arrêté. Oh, attends une seconde, ne me suis-je pas battu pendant 3 mois pour déplacer l'authentification SAP sous LDAP ??
Ou encore, aucune "saucisse" ne peut entrer dans sa Station Windows. Hé, nous avons seulement une machine Unix en panne, pourquoi les paramètres NT sont-ils perturbés. Oh! récemment lorsque personne ne regardait, j'ai déplacé le contrôleur de domaine NT vers Linux+Samba avec authentification LDAP.

La même chose peut, bien sûr, survenir sur un Serveur Windows mais dans ce cas, il n'y aura pas de ho! ha! parce que ces nuls y sont habitués mais soyez certains que si cela ce produit sur un système Linux, vous aurez un tas de "on ne pas faire confiance à Linux" etc, etc... de la part des responsables.

Dans une des entreprises pour laquelle j'ai travaillé, le serveur NFS fournissait des données à un serveur web interne, un serveur Intranet, un serveur de base de données et plusieurs autres services... cela provoquera sa fermeture.
Bien sûr, utiliser NFS était un mauvais choix mais c'est utile pour servir d'exemple.
Ce serveur était HD grâce à l'utilisation de clusters Sun qui coûtent les yeux de la tête.
Un autre service important était l'intranet, utilisé par plus de 1500 personnes.

Maintenant abordons le sujet un peu plus profondément.

Qu'est-ce que HD?

La Haute Disponibilité est ce qu'elle dit qu'elle est.
C'est à dire quelque chose qui est Hautement Disponible.

Certains services sont vraiment importants pour maintenir le bon fonctionnement de votre société.
Exemple:

site intranet
serveur de Fichiers
service de Courrier
service DNS

Ceux-ci peuvent tomber en panne suite à deux facteurs :

Dysfonctionnement logiciel
Dysfonctionnement matériel

Pour les dysfonctionnements matériel, beaucoup de précautions sont prises par les responsables lors de la commande du matériel. Par exemple, chaque machine devra posséder alimentation redondante, Raid 5, etc...
Les dysfonctionnements logiciel sont souvent oubliés.
Croyez le ou non, mais j'ai vu des stations Linux se geler à cause d'un problème soudain de carte réseau, de surchauffe CPU, etc...

Le grand patron ne veut pas savoir si le système est arrêté à cause d'un problème d'alimentation ou d'une carte réseau défaillante.
La seule chose que votre patron, les employés et les clients veulent c'est que le "service" soit disponible.
Notez que j'ai mis en gras le mot service.
Bien sûr, le service est fourni par une machine. Rediriger ce service et les requêtes vers une machine saine fait partie de l'art de la Haute Disponibilité.

Exemple de mise en oeuvre de HD

Dans cet exemple, nous allons créer théoriquement un cluster Actif/Passif faisant tourner un serveur apache, pour l'intranet.
Pour créer ce petit cluster, nous allons utiliser une bonne machine avec beaucoup de mémoire, plusieurs CPU et une autre avec juste ce qu'il faut de mémoire et de CPU pour fournir le service.
La première machine sera le noeud maître alors que la seconde sera le noeud de sauvegarde.
Le travail du noeud de sauvegarde est de prendre le relais des services du noeud maître si ce dernier semble ne pas répondre.

Comment cela fonctionnera-t-il?

Réfléchissons un peu sur la manière dont les utilisateurs accèdent à l'intranet.
Ils saisissent http://intranet/ sur leur navigateur et le serveur DNS les redirige vers 10.0.0.100 (IP d'exemple)

Pourquoi ne pas mettre deux serveurs fournissant ce service intranet avec des adresses IP différentes et de simplement demander au serveur DNS de le rediriger du premier, s'il tombe en panne, vers le second.
C'est, bien sûr, une des possibilités, mais il y a des informations dans le cache du DNS sur les clients et peut être que vous préférez alors lancer le serveur DNS sur un cluster HD.
Une autre possibilité, en cas d'échec du noeud maitre, est de récupérer son adresse IP pour le noeud esclave afin de permettre les réponses aux requêtes.
Cette méthode est appelée prise de contrôle IP et c'est celle que nous allons utiliser dans nos exemples. Maintenant tous les navigateurs continueront à accéder à http://intranet/ qui se traduira par 10.0.0.100, même si le noeud maitre échoue, sans faire de changements dans le DNS.

Comment dialoguent les clusters?

Comment le maître/esclave va savoir que l'autre noeud du cluster est en panne?
Ils vont dialoguer l'un avec l'autre par un câble série et un câble Ethernet croisé (pour la redondance car l'un ou l'autre peut avoir une panne) et contrôler chacun les pulsations de l'autre (oui, comme vos battements de coeur). Si vos battements cessent, alors vous êtes probablement mort.
Le programme pour surveiller les pulsations des noeuds de cluster est appelé... devinez... pulsation (heartbeat).
Heartbeat est disponible sur http://www.linux-ha.org/download/
Le programme pour la prise de contrôle de l'adresse IP est appelé fake et il est intégré dans Heartbeat.

Si vous n'avez pas de carte réseau supplémentaire à mettre dans deux machines, vous pouvez utiliser heartbeat seulement sur un câble série (null modem).
D'un autre coté, les cartes réseau étant bon marché, n'hésitez pas à en ajouter une pour la redondance.

Préparer les noeuds du cluster

Comme mentionné précédemment, nous allons utiliser une bonne machine et une autre un peu moins.
Les deux machines seront équipées de deux cartes réseau chacune et d'au moins un port série.
Nous aurons besoin d'un câble croisé cat 5 RJ45 (Ethernet) et d'un câble null modem (câble série croisé)

Nous allons utiliser la première carte réseau sur les deux machines pour leur adresse IP internet (eth0).
Nous allons utiliser la seconde carte pour faire un réseau privé, entre les deux machines, pour communiquer par udp avec Heartbeat (eth1).

Nous allons donner aux deux machines leur adresse IP et leur nom.
Par exemple pour eth0 sur les deux noeuds
clustnode1 avec l'adresse IP 10.0.0.1
clustnode2 avec l'adresse IP 10.0.0.2

Maintenant, nous réservons une adresse IP flottante (c'est l'adresse IP du service que j'ai écrit en gras précédemment)
10.0.0.100 (intranet). Nous n'avons pas besoin de l'assigner à une machine pour l'instant.

Ensuite, nous configurons les machines pour leur seconde carte réseau et leur donnons une adresse IP parmi celles qui ne sont pas utilisées.
Par exemple, pour les eth1 des deux noeuds, une adresse IP avec un masque réseau à 255.255.255.0
adresse IP de clustnode1 : 192.168.1.1
adresse IP de clustnode2 : 192.168.1.2

Enfin nous connectons le câble au port série 1 ou 2 des machines et nous vérifions qu'elles fonctionnent/communiquent bien l'une avec l'autre.
(Faites en sorte de le connecter au même numéro de port sur les deux machines, cela sera plus facile de cette manière).
Voir http://www.linux-ha.org/download/GettingStarted.html

Installer Heartbeat

Installer le logiciel est simple. Heartbeat est disponible aux formats rpm et tar.gz à la fois comme binaire ou comme source.
Si vous avez des problèmes à l'installation, vous ne devriez pas prendre la responsabilité d'installer un système HD (il ne serait plus HD mais plutôt ND)
Il existe un excellent guide Getting Started with Linux-HA dont je ne vais pas faire une copie ici.

Configurer le cluster

Configurer Hearbeat

Par exemple, si les fichiers de configuration de Heartbeat sont dans /etc/ha.d
alors
éditez le fichier /etc/ha.d/authkeys avec votre éditeur favori

#/etc/ha.d/authkeys
auth 1
1 crc
#end /etc/ha.d/authkeys

Vous pourrez passer à md5 ou sha lorsque vous serez plus à l'aise. Pour le premier test, laissez le mécanisme d'authentification à 1.

éditez /etc/ha.d/ha.cf

debugfile /var/log/ha-debug
logfile /var/log/ha-log
logfacility     local0
deadtime 10
serial /dev/ttyS3  #changez ceci par le port approprié et 
					supprimez ce commentaire
udp    eth1 #supprimez cette ligne si vous n'utilisez pas 
					de seconde carte réseau
node   clustnode1
node   clustnode2

éditez le fichier /etc/ha.d/haresources

#masternode ip-address service-name
clustnode1 10.0.0.100 httpd

Ceci définit clustnode1 comme étant le noeud maître. Par exemple, lorsque clustnode1 est arrêté, clustnode2 récupère le service mais lorsque clustnode1 est remis en route, il reprend le service. C'est la raison pour laquelle nous utilisons une bonne machine et une un peu moins bonne (clustnode1 est la bonne machine)
Le second champ définit l'adresse IP qui doit être utilisée par le service et le troisième champ définit le nom du service.
Lorsque la machine1 démarre le service, elle tentera de lancer

/etc/ha.d/httpd start

si elle ne trouve pas le fichier, elle essaiera alors

/etc/rc.d/init.d/httpd start

La même chose se produit lorsque l'on arrête un service : si clustnode2 en arrête un, il essaiera

/etc/ha.d/httpd stop

s'il ne trouve pas le fichier, il tente alors

/etc/rc.d/init.d/httpd stop

Lorsque vous avez fini la configuration sur clustnode1, vous pouvez copier les fichiers sur le noeud 2.
Dans le répertoire /etc/ha.d/rc.d vous trouverez le script appelé ip-request qui assignera l'adresse IP, etc.
Démarrez maintenant /etc/rc.d/init.d/heartbeat sur les deux machines.
Installez une page d'index différente sur les machines devant être servies par le serveur http.

Par exemple :
sur clustnode1

echo hello world à partir de clustnode1 >/votreRacineDoc/index.html
et sur clustnode2
echo hello world à partir de clustnode2 >/votreRacineDoc/index.html

Assurez-vous que sur les deux noeuds le service httpd ne se lance pas automatiquement au démarrage, enlevez les liens dans les répertoires rcN ou encore mieux, déplacez le script de démarrage "httpd" ou "apache" de /etc/rc.d/init.d/ vers /etc/ha.d/rc.d/ sur les deux machines.
Si tout est installé correctement, si Hearbeat est lancé et communique, alors clustnode1 aura l'adresse IP 10.0.0.100 et il répondra aux requêtes http.
Faites l'essai plusieurs fois et assurez-vous que vous obtenez des réponses. Si tout semble fonctionnel alors arrêtez clustnode1 et dans les 10 secondes, clustnode2 reprendra le service et l'adresse IP.
Votre temps d'arrêt maximum sera de 10 secondes.

Qu'en est-il de l'intégrité des données

Lorsque le service httpd se déplace du noeud 1 vers le noeud 2 il ne voit pas les mêmes données. Je perds tous les fichiers créés avec les scripts CGI.

Deux réponses:
1. Vous ne devriez jamais écrire dans des fichiers à partir des scripts CGI. (utilisez plutôt une base de données réseau... MySQL est très bien)
2. Vous pouvez relier les deux noeuds à un système de stockage SCSI externe et vérifier qu'un seul des deux puisse y accéder au même moment; de même vous devez régler l'id SCSI de la carte hôte à 6 sur la machine A et la laisser à 7 sur la machine B ou inversement.
J'ai fait l'essai avec des cartes Adaptec 2940 SCSI et elles permettent de changer l'id. La plupart des cartes bon marché n'autorise pas la modification.
Certains contrôleurs RAID sont censés être capables de gérer les clusters mais assurez-vous auprès du vendeur que vous pouvez changer le HOST ID de la carte sans acheter le kit cluster Microsoft.
Je possèdais deux adaptateurs NetRaid de chez HP et ils ne supportent vraiment pas Linux. Je les ai cassés pour moins culpabiliser sur l'argent dépensé.

L'étape suivante consiste à acheter des cartes, un hub et un système de stockage prévus pour la fibre optique de manière à créer un petit SAN (Storage Area Network). C'est beaucoup plus cher qu'une solution de partage SCSI mais cela reste un bon investissement.
Vous pouvez lancer GFS (Global File System, voir ci-dessous dans les ressources) sur le réseau à fibre optique, ce qui vous permet d'avoir un accès transparent au système de stockage à partir de toutes les machines comme si les données étaient en local.

Nous utilisons GFS dans un environnement de production sur 8 machines dont 2 d'entre elles ont une configuration HD identique à celle décrite ci-dessus.

Qu'en est-il pour un cluster actif/actif?

Vous pouvez facilement construire un serveur Actif/Actif si vous avez un bon système de stockage qui permette des accès simultanés. Les exemples sont la fibre optique et GFS.
Si des systèmes de fichiers réseau comme NFS vous satisfont, vous pouvez envisager cette solution mais je vous le déconseille.

Dans tous les cas, vous pouvez assigner le service A à clustnode1 et le service B à clustnode2. Voici, par exemple, mon fichier de ressource hd

clustnode2 172.23.2.13 mysql
clustnode1 172.23.2.14 ldap
clustnode2 172.23.2.15 cyrus

J'utilise GFS pour le stockage et je n'ai donc pas de problème avec l'accès simultané aux données et je peux lancer autant de services que les machines peuvent en supporter.
Ici, clustnode2 est le maître pour mysql et cyrus alors que clustnode1 l'est pour ldap.
Si clustnode2 s'arrête, clustnode1 reprend toutes les adresses IP et les services.

Ressources

Linux-HA.org: La page d'accueil de Linux HD
kimberlite clustering technology: Un Cluster Kimberlite fournit un support pour deux noeuds connectés à un SCSI partagé ou à un sous-système de stockage par fibre optique dans un environnement actif-actif à tolérance de panne . Le logiciel permet de détecter si un noeud disparaît du cluster et de lancer automatiquement les scripts de récupération qui exécutent les procédures nécessaires pour redémarrer les applications sur le noeud restant. Lorsque le noeud est réactivé sur le cluster, les applications peuvent y être renvoyées, manuellement ou automatiquement si nécessaire. Des modèles de scripts de récupération sont fournis. Kimberlite est conçu pour maintenir le plus haut niveau possible d'intégrité de données et pour être extrêmement robuste. Il convient pour un déploiement dans tous les environnements qui réclament une haute disponibilité pour les applications Linux non-modifiées.
ultra monkey: Le projet Ultra Monkey a pour but de créer un répartiteur de charge et des services à haute disponibilité sur un réseau local en utilisant les composantes Open Source du Système d'Exploitation Linux. Au stade actuel, l'accent est mis sur la production d'une ferme de serveurs web modulable et à haute disponibilité, bien que la technologie soit facilement adaptable à d'autres services tels que le courrier électronique ou FTP.
Linux Virtual Server: Linux Virtual Server est un serveur hautement modulable et à haute disponibilité basé sur un cluster de serveurs réels avec un répartiteur de charge fonctionnant sous Linux. L'architecture du cluster est transparente pour les utilisateurs. Ils ne voient qu'un simple serveur virtuel.
4U cluster / 4U SAN (Publicité honteuse): Le cluster 4U et le SAN 4U sont un cluster HD et un SAN développés par notre société 4Unet.
Si vous êtes un FAI, un transporteur, ou une compagnie de téléphone et que vous cherchiez des solutions Haute Disponibilité à concevoir et à mettre en oeuvre, alors 4Unet est le bon endroit pour le demander.
Note: 4Unet est un intégrateur, il ne vend pas de clusters ou de SAN, il les met en place pour ses clients. Toutes les technologies utilisées pour ces clusters/SAN sont open source.
Les clients désignés de 4Unet sont exclusivement les FAI, les transporteurs, et les compagnies de téléphone.
Global File System: Global File System (GFS) est un système de fichier sous Linux permettant de partager les disques d'un cluster. GFS supporte la journalisation et la récupération de données suite à des défaillances de clients. Les noeuds de cluster GFS partagent physiquement le même stockage par le biais de la fibre optique ou des périphériques SCSI partagés. Le système de fichier semble être local sur chaque noeud et GFS synchronise l'accès aux fichiers sur le cluster. GFS est complètement symétrique ce qui signifie que tous les noeuds sont équivalents et qu'il n'y a pas un serveur susceptible d'être un entonnoir ou un point de panne. GFS utilise un cache en lecture écriture tout en conservant la sémantique complète du système de fichier Unix.