Cluster basé sur Red Hat Cluster Suite

1. Environnement de travail

Pour la rédaction de cet article, je me suis basé sur des machines virtuelles identiques : 1 processeur virtuel, 128 Mo de mémoire et disque dur virtuel de 8 Go. Dans un environnement de production, vous disposerez probablement de machines plus performantes et proposant de la redondance sur leurs composants matériels : disques durs en RAID, cartes réseau en bonding, alimentations redondées échangeables à chaud... Pour leurs petits noms, je les ai baptisées : balthasar, casper et melchior ; ce sont les noms des trois rois mages (en anglais) et surtout les ordinateurs composant MAGI, le super-ordinateur du manga Neon Genesis Evangelion [1] (que je ne saurais que vous recommander...). Le cluster s'appellera assez logiquement magi.

Pour le stockage, j'ai la chance de disposer d'un serveur NAS à domicile qui me fournit des targets iSCSI. Ces targets iSCSI font d'excellents périphériques partagés pour la mise en cluster de volumes LVM. L'étape de configuration des périphériques iSCSI n'étant pas la priorité de cet article, je me contenterai par la suite des commandes essentielles. Une fois encore, dans un environnement de production, vous disposerez de plusieurs serveurs NAS offrant la redondance de l'accès aux targets iSCSI ou un environnement SAN avec une configuration en Multipath [2].

J'ai basé mon article sur la distribution CentOS 5.5 en version i386. J'ai fait ce choix car je ne dispose pas de licence Red Hat Enterprise Linux à titre personnel et que la distribution Fedora n'est pas aussi représentée en production. Les logiciels utilisés sont identiques : vous pourrez donc adapter facilement cet article à votre cas si vous utilisez Red Hat Enterprise Linux. Pour info, j'ai fait l'installation à partir de Cobbler [3], en choisissant un profil aussi réduit que possible, puis j'ai utilisé la fonction de clonage de virt-manager.

2. Mise en route du cluster

Dans un premier temps, j'explicite l'ensemble des étapes d'initialisation du cluster. Je pars de serveurs avec une installation minimale et je décris la configuration des serveurs jusqu'à ce qu'ils soient intégrés au cluster. Cela inclut la configuration des targets iSCSI pour une utilisation partagée et la mise en œuvre des services de clusterisation. Au terme de cette section, les serveurs seront liés et communiqueront sur leur état. L'implémentation des services pourra donc avoir lieu.

2.1 Configuration de NTP

Un point important dans un cluster est la synchronisation entre les nœuds. Pour s'assurer de la bonne cohésion de l'ensemble des nœuds, ceux-ci échangent des messages horodatés : la non-réponse d'un nœud dans le délai imparti entraîne son éviction du cluster. Nous devons donc configurer le service NTP pour que tous les nœuds soient à la même heure. Pour cela, nous installons le package ntp, puis le configurons via le fichier /etc/ntp.conf, et enfin, le démarrons.

2.2 Installation des packages

La distribution fournit les packages de gestion de cluster dans son dépôt principal. Pour les distributions RedHat Enterprise Linux, ces packages sont disponibles au travers de deux dépôts additionnels soumis à souscription : rhel-x86_64-server-cluster-5 et rhel-x86_64-server-cluster-storage-5. Il faut ensuite simplement installer les packages suivants :

2.3 Désactivation de l'ACPI

Pour que le fencing puisse fonctionner, nous devons désactiver la gestion logicielle de l'ACPI. En effet, l'interruption logicielle des signaux ACPI peut empêcher le fencing de fonctionner et donc entraîner un état instable du cluster. J'ai choisi de désactiver la gestion de l'ACPI directement au niveau du noyau en modifiant les paramètres de boot :

2.4 Configuration du filtrage réseau

Nous ajoutons dés maintenant les règles de filtrage pour ouvrir les flux liés aux échanges entre les nœuds du cluster, via le fichier /etc/sysconfig/iptables. En effet, les prochaines étapes nécessitent des communications entre les serveurs ; il est donc intéressant de ne pas être bloqué par le filtrage réseau...

2.5 Disque de quorum

Configurer qdiskd n'est pas nécessaire, excepté si vous avez des besoins spéciaux pour la santé des nœuds. Un exemple de besoin spécial est une configuration « tous sauf un » . Dans une configuration tous sauf un, qdiskd est configuré pour fournir suffisamment de votes de quorum pour maintenir le quorum même si un seul nœud est fonctionnel (RedHat Cluster Suite 5, Configuration Guide, §2.7 [4]).

Le disque de quorum est un périphérique physique partagé par l'ensemble des serveurs et disposant d'un nombre arbitraire de votes dans le cluster. Concrètement, il permet de maintenir le cluster en état opérationnel lorsque plusieurs nœuds sont défaillants et que le quorum n'est plus atteint. Ainsi, sur un cluster de trois nœuds, si deux nœuds sont défaillants, le quorum n'est plus atteint ; donner deux votes au disque de quorum permet au dernier nœud du cluster d'assurer le service seul. Et c'est exactement ce que nous souhaitons pour le cluster magi.

2.5.1 Configuration du disque iSCSI

Comme je l'ai indiqué plus tôt, je me concentre sur les commandes essentielles. Nous commençons donc par installer le package de l'initiateur iSCSI et nous démarrons le service.

Nous demandons la liste des cibles au serveur de stockage.

Nous nous connectons à la cible iqn.2010-09.localdomain:iscsi.cluster.c3fa22.

Nous vérifions que les disques iSCSI sont bien vus par le système.

Les disques iSCSI n'ont pas de tables de partition et nous ne les créons pas.

2.5.2 Configuration du disque de quorum

Le périphérique utilisé comme disque de quorum est /dev/sdb ; la taille recommandée est de 100 Mo (mon NAS ne fait pas moins de 1 Go par LUN). Nous créons la structure du disque de quorum par la commande suivante :

Nous vérifions la création du disque via la commande suivante (résultat identique sur les 3 nœuds) :

2.6 Instanciation de la configuration du cluster

La configuration du cluster se fait par l'intermédiaire d'un seul et unique fichier : /etc/cluster/cluster.conf. Le fichier ci-dessous est celui qui correspond au cluster fraîchement installé et il définit :

* la configuration générale du cluster :

- le nom du cluster : name. Nous mettons logiquement magi.

- la version de la configuration : config_version. C'est une valeur similaire au serial de la configuration de Bind. Chaque modification du fichier doit entraîner une incrémentation de ce champ pour que la configuration puisse être propagée sur les nœuds.

* la configuration du gestionnaire de cluster : cman

- le nombre de votes nécessaires pour le quorum : expected_votes. Cela correspond au nombre de votes minimum pour que le cluster fonctionne. Dans notre cas, il s'agit du cas où un seul nœud est actif avec le disque de quorum, soit 3 votes (voir ci-dessous).

- s'il s'agit ou non d'un cluster à deux nœuds. Les clusters à deux nœuds sont des cas particuliers, que nous n'aborderons pas ici. Nous mettons donc la valeur 0.

* la configuration du gestionnaire de disque de quorum : quorumd

- l'intervalle de vérification du disque en secondes : interval. Nous vérifions le fonctionnement du disque toutes les 3 secondes. Avec un tko à 20, cela nous donne une minute pour confirmer la défaillance.

- le nombre de vérifications en échec avant de déclarer le disque de quorum hors service : tko (Technical Knock Out). Par défaut, le nombre de réussite pour considérer le disque fonctionnel est tko/3.

- l'étiquette du périphérique à utiliser : label. Bien évidemment, nous mettons la valeur que nous avons renseignée précédemment : magi_qdisk.

* la configuration des nœuds :

- l'identifiant unique du nœud ;

- le nom complet (FQDN) du nœud ;

- le nombre de votes pour le nœud ;

- le périphérique de fencing à utiliser : manual. La configuration de ce périphérique est explicitée juste après.

* la configuration des périphériques de fencing : fencedevices. J'utilise le périphérique fence_manual car je ne dispose pas de périphériques utilisables dans mon environnement de test. Néanmoins, en production, j'aurais tendance à utiliser fence_ipmi, qui effectue un shutdown via une commande IPMI [5].

* la configuration du démon de fencing : fence_daemon.

Cela donne le fichier suivant :

2.7 Démarrage du cluster

Il ne nous reste plus qu'à démarrer les services et les configurer pour qu'ils démarrent au boot. Le premier service à démarrer est qdiskd, afin que le disque de quorum soit visible aux nœuds du cluster. Chaque service doit être démarré sur tous les nœuds du cluster avant de démarrer le suivant. On constate un service supplémentaire qui s'appelle rgmanager et qui gère les ressources hébergées par le cluster.

Après quelques instants, le cluster est actif. Nous pouvons suivre son démarrage dans les fichiers /var/log/messages des nœuds, puis vérifier son état par la commande cman_tool :

La commande renvoie le nom du cluster (Cluster Name), le nombre de nœuds (Nodes, le nombre de votes associés au disque de quorum (Quorum device votes), le nombre total de votes (Total votes).

La commande clustat renvoie des informations sur les services hébergés par le cluster :

La sortie de cette commande indique l'état du cluster ainsi que celui des nœuds individuellement. On peut noter que le nœud qui lance la commande est différencié des autres par la mention Local. Nous voyons aussi l'état du disque de quorum. Nous verrons à nouveau la sortie de cette commande après avoir ajouté des services dans le cluster.

2.8 Gestion du stockage via CLVM

Nous disposons de deux disques iSCSI supplémentaires accessibles à l'ensemble des serveurs : /dev/sdc et /dev/sdd. L'idée est de pouvoir moduler l'espace de stockage en ajoutant/supprimant des disques iSCSI et en gérant leur agrégation au travers de LVM. Or, les trois serveurs du cluster doivent avoir accès à cet espace de stockage : nous utilisons donc Clustered LVM, qui est une surcouche à LVM qui réplique les métadonnées entre les nœuds du cluster.

2.8.1 Configuration de CLVM

La première étape est l'installation des packages :

Nous devons ensuite modifier la configuration de LVM pour qu'il fonctionne en mode cluster et qu'il utilise les disques iSCSI. Cela se fait dans le fichier de configuration /etc/lvm/lvm.conf. Le champ filter permet de spécifier la liste des périphériques qui doivent être gérés par LVM : il s'agit d'un tableau indiquant pour chaque périphérique ou motif de périphérique s'il doit être ajouté (a devant le nom) ou supprimé (r devant le nom) des périphériques à gérer. Le champ locking_type serre quant à lui à spécifier le mécanisme de lock : 3, le mécanisme clusterisé.

Je n'ai pas utilisé LVM lors de l'installation du système, mon disque système n'apparaît donc pas dans le champ filter. Si vous utilisez LVM, pensez bien à faire apparaître vos disques dans le filter.

Il ne reste plus qu'à démarrer le service clvmd sur l'ensemble des nœuds :

2.8.2 Création des volumes

Chaque LUN est considéré comme un Physical Volume (PV). Nous créons les métadonnées sur l'ensemble des LUN avec la commande suivante :

Nous agrégeons l'ensemble des PV dans un unique Volume Group (VG) que nous appelons magi_vg.

Nous pouvons maintenant créer des Logical Volumes (LV) sur le VG. L'exemple ci-dessous (utilisé plus tard) alloue 1 Go au LV test_lv.

Vous pouvez vérifier sur les autres nœuds du cluster que les volumes sont bien visibles.

3. Configuration de l'hébergement de services

Maintenant que notre cluster est fonctionnel, nous passons à l'hébergement des services eux-mêmes. En effet, installer un mécanisme de redondance n'a d'intérêt que pour les services que nous pouvons protéger. Pour cet article, j'ai choisi d'implémenter un service « bidon » : test.

3.1 Création de failover domains

Lorsqu'un serveur du cluster défaille, il faut que les services qu'il hébergeait soit relancés sur un autre serveur. Pour que le gestionnaire de ressources (Resources Manager : RG) du cluster sache sur quel serveur relocaliser le service, nous spécifions des failover domains qui regroupent les serveurs par ordre de priorité d'exécution. À titre d'exemple, le failover domain ring01 créé ci-dessous indique que la priorité du serveur balthasar est 10, celle de casper 20 et celle de melchior 30 ; le serveur le plus prioritaire a la plus petite valeur de priorité (ici, balthasar). Un service associé au failover domain ring01 sera donc exécuté en priorité sur le serveur balthasar, puis en cas de défaillance du serveur balthasar sur le serveur casper, puis sur melchior en cas de défaillance de casper. Le retour du service sur son serveur de prédilection, suite à sa remise en état, peut être automatique ou non : cela se configure pour chaque service.

La configuration des failover domains se fait dans le fichier /etc/cluster/cluster.conf, tout comme le reste de la configuration du cluster. En reprenant le fichier commencé plus tôt, nous ouvrons la balise <rm/>.

Pour que la configuration puisse être propagée aux autres nœuds du cluster, il faut incrémenter le champ config_version et lancer la commande suivante :

Un coup d'œil sur le fichier /etc/cluster/cluster.conf des autres nœuds du cluster vous confirmera le bon déploiement de la configuration.

3.2 Service de test

Pour simplifier l'exemple, j'ai choisi de créer un service qui ne fait qu'une chose : écrire la date toutes les 10 secondes dans un fichier. Pour cela, je me base sur le script /usr/local/bin/test_cluster.sh, dont le code est :

Pour qu'il soit considéré comme un service, je l'intègre au dépôt de scripts d'init via le fichier /etc/init.d/test, dont le code est :

Nous n'ajoutons pas test aux services gérés via chkconfig, car il sera géré par le cluster. Nous ajoutons donc le service au cluster. La configuration du service consiste en l'association de 4 ressources :

- le Logical Volume qui stocke les données ;

- le filesystem créé sur ce LV ;

- le script de démarrage du service.

Nous complétons à nouveau le fichier /etc/cluster/cluster.conf, mais cette fois-ci, nous ajoutons une entité <service> à l'intérieur de la balise rm.

Ces quelques lignes de configuration indiquent que le service test est rattaché au failover domain ring01, ce qui signifie qu'il tourne prioritairement sur balthasar. Les éléments suivants sont associés au service :

- le volume logique test_lv hébergé par le VG magi_vg et auquel on rattache le filesystem /dev/magi_vg/test_vg monté sur /mnt/magi/test ;

- le script de démarrage /etc/init.d/test qui est utilisé pour gérer le service.

L'imbrication des éléments est liée à leur interdépendance. En effet, le script a besoin du filesystem, qui a lui même besoin du LV.

Nous formatons le filesystem pour qu'il soit utilisable par le service :

Nous pouvons maintenant propager la configuration sur les autres nœuds du cluster :

Après quelques secondes, vous pouvez vérifier que le service est connu du cluster via la commande suivante :

Vous constatez que le service n'est pas démarré. Bien qu'il soit en mode autostart="1", il faut le démarrer manuellement la première fois :

Nous pouvons vérifier que le service est bien démarré via clustat et en regardant le système. En effet, le LV test_lv doit être monté dans /mnt/magi/test et il doit contenir le fichier test_cluster.out qui se remplit au fur et à mesure, et cela uniquement sur balthasar.

3.3 Migration du service

Pour terminer, nous allons déplacer le service sur un autre nœud du cluster, casper, par exemple, pour confirmer que tout va bien.

Nous vérifions...

Le service a correctement migré.

Conclusion

Tout au long de cet article, nous avons pu aborder les commandes et les fichiers de configuration principaux. Néanmoins, ce n'est que la partie émergée de l'iceberg. La mise en place d'un cluster est délicate car la stabilité est fragile. Il est donc important de sécuriser au maximum les différents composants par de la redondance ou des procédures de reprise d'activité particulièrement bien rodées.

Concernant la configuration du cluster, nous n'avons été très en profondeur car le service n'est pas complexe et qu'il fonctionne en mode actif-passif. Il est aussi possible de configurer des services en mode actif-actif avec Linux Virtual Server (LVS), qui est fourni parmi les outils de la suite Red Hat Cluster. Certains types de services, tels que Apache et MySQL, disposent d'objets préconfigurés qui simplifient un peu leur configuration dans le cluster.

J'aurais encore pu écrire pas mal de lignes sur ces sujets, mais je vous laisse les découvrir par vous-même.

Références

[1] Wikipedia : Neon Genesis Evangelion - http://fr.wikipedia.org/wiki/Neon_Genesis_Evangelion

[2] Using Device-Mapper Multipath - http://www.centos.org/docs/5/html/5.2/DM_Multipath/

[3] GNU/Linux Magazine Francen°118 - Gestion de configuration centralisée

[4] Configuring and Managing a RedHat Cluster - http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Cluster_Administration/index.html

[5] GNU/Linux Magazine Francen°118 - I can haz IPMI ? Ou comment gérer l’aspect matériel de ses serveurs

[6] http://code.google.com/p/php-syslog-ng/