Dans une production informatique, certains services
sont particulièrement critiques. Pour assurer la disponibilité de ces
services, nous avons à notre disposition les technologies de cluster.
Cet article présente la mise en place d’un cluster à trois nœuds pour
héberger les services critiques de notre infrastructure : nous passerons
en revue la clusterisation aussi bien de LVM que des services.
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 Non 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.
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.
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.
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 :
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 :
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...
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.
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.
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) :
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 :
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.
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.
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 :
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.
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.
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 failoverdomains 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 failoverdomains 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.
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.
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é.
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 pas é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.
|
|
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.
|
|
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.
|
root# yum install ntp
root# cat > /etc/ntp.conf << EOF
server 0.fedora.pool.ntp.org
server 1.fedora.pool.ntp.org
server 2.fedora.pool.ntp.org
driftfile /var/lib/ntp/drift
EOF
root# ntpdate -u 0.fedora.pool.ntp.org
root# service ntpd start
root# chkconfig ntpd on
|
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 :
|
root# yum install cman rgmanager \
openais perl perl-Net-Telnet \
perl-XML-LibXML perl-XML-LibXML-Common \
perl-XML-NamespaceSupport perl-XML-SAX pexpect
|
|
|
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 :
|
root# sed -i "/^\s*kernel /s/$/ acpi=off/" /boot/grub/grub.conf
root# shutdown -r now
|
|
Note
|
| Le fencing est le fait de forcer l’indisponibilité
d’une ressource pour qu’elle n’entraîne pas l’instabilité de l’ensemble.
Dans le cas d’un cluster, nous pouvons forcer l’indisponibilité de
plusieurs composants, mais le plus simple est le serveur lui-même ;
nous éteignons le serveur qui est considéré défaillant par le nœud
maître du cluster. |
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...
|
# Cluster Manager (cman)
-A INPUT -m state --state NEW -m multiport -p udp --dports 5404,5405 -j ACCEPT
-A INPUT -m addrtype --dst-type MULTICAST -m state --state NEW -m multiport
-p udp --dports 5404,5405 -j ACCEPT
# Cluster Configuration System (ccsd)
-A INPUT -m state --state NEW -m multiport -p tcp --dports 50006,50008,50009 -j ACCEPT
-A INPUT -m state --state NEW -p udp --dport 50007 -j ACCEPT
# Global Network Block Device (gnbd)
-A INPUT -m state --state NEW -p tcp --dport 14567 -j ACCEPT
# Distributed Lock Manager (dlm)
-A INPUT -m state --state NEW -p tcp --dport 21064 -j ACCEPT
|
|
|
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.
|
root# yum install iscsi-initiator-utils
root# service iscsi start
root# chkconfig iscsi on
|
|
root# iscsiadm --mode discovery --type sendtargets --portal 192.168.0.10:3260
192.168.0.10:3260,1 iqn.2010-09.localdomain:iscsi.cluster.c3fa22
|
|
root# iscsiadm --mode node --targetname iqn.2010-09.localdomain:iscsi.cluster.c3fa22 --portal 192.168.0.10:3260 --login
Logging in to [iface: default, target: iqn.2010-09.localdomain:iscsi.cluster.c3fa22, portal: 192.168.0.10,3260]
Login to [iface: default, target: iqn.2010-09.localdomain:iscsi.cluster.c3fa22, portal: 192.168.0.10,3260]: successful
|
|
root# fdisk -l
Disque /dev/sda: 8589 Mo, 8589934592 octets
255 heads, 63 sectors/track, 1044 cylinders
Unités = cylindres de 16065 * 512 = 8225280 octets
Périphérique Amorce Début Fin Blocs Id Système
/dev/sda1 * 1 1011 8120826 83 Linux
/dev/sda2 1012 1044 265072+ 82 Linux swap / Solaris
Disque /dev/sdb: 1073 Mo, 1073742336 octets
34 heads, 61 sectors/track, 1011 cylinders
Unités = cylindres de 2074 * 512 = 1061888 octets
Disque /dev/sdb ne contient pas une table de partition valide
Disque /dev/sdc: 2147 Mo, 2147484160 octets
67 heads, 62 sectors/track, 1009 cylinders
Unités = cylindres de 4154 * 512 = 2126848 octets
Disque /dev/sdc ne contient pas une table de partition valide
Disque /dev/sdd: 2147 Mo, 2147484160 octets
67 heads, 62 sectors/track, 1009 cylinders
Unités = cylindres de 4154 * 512 = 2126848 octets
Disque /dev/sdd ne contient pas une table de partition valide
|
/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 :
|
root@balthasar# mkqdisk -c /dev/sdb -l ‘magi_qdisk’
|
|
root# mkqdisk -L
mkqdisk v0.6.0
/dev/disk/by-id/scsi-36001405256945a0d44bcd487cdb322de:
/dev/disk/by-path/ip-192.168.0.10:3260-iscsi-iqn.2010-09.localdomain:iscsi.cluster.c3fa22-lun-0:
/dev/sda:
Magic: eb7a62c2
Label: magi_qdisk
Created: Fri Sep 17 22:55:51 2010
Host: balthasar
Kernel Sector Size: 512
Recorded Sector Size: 512
|
|
|
|
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 :
|
<?xml version="1.0"?>
<cluster name="magi" config_version="1">
<cman expected_votes="3" two_node="0">
<multicast addr="224.0.0.1"/>
</cman>
<quorumd interval="3" tko="20" votes="2" label="magi_qdisk"/>
<clusternodes>
<clusternode name="balthasar.localdomain" votes="1" nodeid="1">
<fence>
<method name="single">
<device name="manual"/>
</method>
</fence>
</clusternode>
<clusternode name="casper.localdomain" votes="1" nodeid="2">
<fence>
|
|
<method name="single">
<device name="manual"/>
</method>
</fence>
</clusternode>
<clusternode name="melchior.localdomain" votes="1" nodeid="3">
<fence>
<method name="single">
<device name="manual"/>
</method>
</fence>
</clusternode>
</clusternodes>
<fencedevices>
<fencedevice name="manual" agent="fence_manual"/>
</fencedevices>
<fence_daemon clean_start="0" post_fail_delay="0" post_join_delay="3"/>
<rm>
<failoverdomains/>
<resources/>
</rm>
</cluster>
|
|
Note
|
| Vous aurez peut-être remarqué que les noms des nœuds
sont des noms pleinement qualifiés (FQDN). La règle est qu’il faut que
le nom indiqué soit résolvable en une adresse IP. Libre à vous de le
renseigner dans votre DNS (conseillé) ou dans /etc/hosts, ou dans les deux. |
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.
|
root# /sbin/service qdiskd start
root# /sbin/service cman start
root# /sbin/service rgmanager start
root# /sbin/chkconfig qdiskd on
root# /sbin/chkconfig cman on
root# /sbin/chkconfig rgmanager on
|
|
root@balthasar# cman_tool status
Version: 6.2.0
Config Version: 1
Cluster Name: magi
Cluster Id: 1571
Cluster Member: Yes
Cluster Generation: 2244
Membership state: Cluster-Member
Nodes: 3
Expected votes: 3
|
|
Quorum device votes: 2
Total votes: 5
Quorum: 3
Active subsystems: 8
Flags: Dirty
Ports Bound: 0
Node name: balthasar.evenit.info
Node ID: 1
Multicast addresses: 239.192.6.41
Node addresses: 192.168.0.201
|
La commande clustat renvoie des informations sur les services hébergés par le cluster :
|
[root@balthasar ~]# clustat
Cluster Status for magi @ Sun Sep 19 22:27:04 2010
Member Status: Quorate
Member Name ID Status
------ ---- ---- ------
balthasar.evenit.info 1 Online, Local
casper.evenit.info 2 Online
melchior.evenit.info 3 Online
/dev/disk/by-id/scsi-36001405256945a0d44bcd487cdb322de 0 Online, Quorum Disk
|
|
|
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.
|
root# yum install lvm2-cluster quota
|
|
devices {
[...]
filter = [ "a/sdc/", "a/sdd/", "r/.*/" ]
[...]
}
[...]
global {
[...]
locking_type = 3
[...]
}
|
Il ne reste plus qu’à démarrer le service clvmd sur l’ensemble des nœuds :
|
root# service clvmd start
root# chkconfig clvmd on
|
|
Note
|
| L’ensemble des opérations d’évolution (augmentation,
réduction, création, suppression) sur les volumes nécessitent que le
cluster soit complet. |
|
root@balthasar# pvcreate /dev/sdc /dev/sdd
|
|
root@balthasar# vgcreate magi_vg /dev/sdc /dev/sdd
|
1 Go au LV test_lv.
|
root@balthasar# lvcreate -n test_lv -L 1g magi_vg
|
|
Note
|
|
Les messages suivants dans les logs sont normaux dans le cas de VG clusterisés :
|
|
Note
|
| Par défaut, les VG sont clusterisés. Pour créer un VG local, il faut utiliser l’option -c n. |
|
Note
|
| Le nombre maximum de failoverdomains
dans un cluster est égal au nombre de permutations sans répétition sur
l’ensemble des serveurs du cluster, soit la factorielle de n (n!). Dans le cas particulier du cluster magi, nous pourrions créer 6 failoverdomains. |
|
<rm>
<failoverdomains>
<failoverdomain name="ring01" restricted="1" ordered="1" nofailback="0">
<failoverdomainnode name="balthasar.localdomain" priority="10"/>
<failoverdomainnode name="casper.localdomain" priority="20"/>
<failoverdomainnode name="melchior.localdomain" priority="30"/>
</failoverdomain>
</failoverdomains>
<resources/>
</rm>
|
|
root@balthasar# ccs_tool update /etc/cluster/cluster.conf
|
des autres nœuds du cluster vous confirmera le bon déploiement de la configuration.
10 secondes dans un fichier. Pour cela, je me base sur le script
/usr/local/bin/test_cluster.sh, dont le code est :
|
#!/bin/bash
while /bin/true
do
echo "Date/Time :
date +’%Y-%m-%d %H:%M:%S’" > > /mnt/magi/test/test_cluster.out
sleep 10
done
|
|
#!/bin/sh
#
# description: Starts and stops a test service for cluster
# chkconfig: - 99 01
#
# Source function library
. /etc/init.d/functions
PATH=/sbin:/bin:/usr/sbin:/usr/bin
export PATH
ID=“Test Service for Cluster“
PROG=“/usr/local/bin/test_cluster.sh“
PIDFILE=/var/run/test.pid
case $1 in
start)
echo -n $“Starting $ID: „
$PROG &
echo $! > $PIDFILE
echo
;;
restart)
$0 status > /dev/null
if [ $? -ne 1 ]; then
$0 stop
fi
$0 start
;;
status)
ps -edf | grep $PROG | grep -v grep
exit $?
;;
|
|
stop)
cat $PIDFILE | xargs kill -9
rm -f $PIDFILE
;;
*)
echo „usage: $0 {start|restart|status|stop}“
exit 1
;;
esac
exit 0
|
● 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.
|
<rm>
[...]
<service name="test" autostart="1" domain="ring01" recovery="relocate">
<lvm name="tes_lv" vg_name="magi_vg" lv_name="test_lv">
<fs name="test_fs" device="/dev/magi_vg/test_lv" force_fsck="0" force_unmount="1" fstype="ext3" mountpoint="/mnt/magi/test" options="" self_fence="0">
<script name="test_svc" file="/etc/init.d/test"/>
</fs>
</lvm>
</service>
[...]
</rm>
|
● 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 :
|
root@balthasar# mkfs.ext3 /dev/magi_vg/test_lv
|
|
root@balthasar# ccs_tool update /etc/cluster/cluster.conf
|
|
root@balthasar# clustat
Cluster Status for magi @ Fri Oct 1 16:19:50 2010
Member Status: Quorate
Member Name ID Status
------ ---- ---- ------
balthasar.localdomain 1 Online, Local, rgmanager
casper.localdomain 2 Online, rgmanager
melchior.localdomain 3 Online, rgmanager
/dev/disk/by-id/scsi-36001405256945a0d44bcd487cdb322de 0 Online, Quorum Disk
Service Name Owner (Last) State
------- ---- ----- ------ -----
service:test (none) stopped
|
|
root@balthasar# clusvcadm -e test
Local machine trying to enable service:test...Success
service:test is now running on balthasar.localdomain
|
|
root@balthasar# clustat
[...]
Service Name Owner (Last) State
------- ---- ----- ------ -----
service:test balthasar.evenit.info started
root@balthasar# mount
[...]
/dev/mapper/magi_vg-test_lv on /mnt/magi/test type ext3 (rw)
root@balthasar# tail /mnt/magi/test/test_cluster.out
[...]
Date/Time : 2010-10-01 17:23:07
|
|
root@balthasar# clusvcadm -r test -m casper.localdomain
Trying to relocate service:test to casper.localdomain...Success
service:test is now running on casper.localdomain
|
|
root@balthasar# clustat
[...]
Service Name Owner (Last) State
------- ---- ----- ------ -----
service:test casper.evenit.info started
root@casper# mount
[...]
/dev/mapper/magi_vg-test_lv on /mnt/magi/test type ext3 (rw)
root@casper# tail /mnt/magi/test/test_cluster.out
|
Concernant la configuration du cluster, nous n’avons pas é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.
Je vous propose d'acheter un chargeur usb multi ports de 6 ports qui va fonctionner très bien avec ça, vous pouvez le trouver sur amazon de la marque choetech
RépondreSupprimer