03 février 2013

Cluster basé sur Red Hat Cluster Suite

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.




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 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.


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.
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

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 :
root# yum install cman rgmanager \
       openais perl perl-Net-Telnet \
       perl-XML-LibXML perl-XML-LibXML-Common \
       perl-XML-NamespaceSupport perl-XML-SAX pexpect


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 :
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.

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...
# 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



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.
root# yum install iscsi-initiator-utils
root# service iscsi start
root# chkconfig iscsi on
Nous demandons la liste des cibles au serveur de stockage.
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
Nous nous connectons à la cible 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
Nous vérifions que les disques iSCSI sont bien vus par le système.
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
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 :
root@balthasar# mkqdisk -c /dev/sdb -l ‘magi_qdisk’
Nous vérifions la création du disque via la commande suivante (résultat identique sur les 3 nœuds) :
root# mkqdisk -
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



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 :
<?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.

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.
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
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 :
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 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 :
[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
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 :
root# yum install lvm2-cluster quota
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é.
devices { 
[...] 
       filter = [ "a/sdc/", "a/sdd/", "r/.*/" ] 
[...] 
[...] 
global { 
[...] 
       locking_type = 3 
[...] 
}
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 :
root# service clvmd start 
root# chkconfig clvmd on

2.8.2 Création des volumes
Note
L’ensemble des opérations d’évolution (augmentation, réduction, création, suppression) sur les volumes nécessitent que le cluster soit complet.
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 :
root@balthasar# pvcreate /dev/sdc /dev/sdd
Nous agrégeons l’ensemble des PV dans un unique Volume Group (VG) que nous appelons magi_vg.
root@balthasar# vgcreate magi_vg /dev/sdc /dev/sdd
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.
root@balthasar# lvcreate -n test_lv -L 1g magi_vg
Vous pouvez vérifier sur les autres nœuds du cluster que les volumes sont bien visibles.
Note
Les messages suivants dans les logs sont normaux dans le cas de VG clusterisés :
clurgmgrd: [18059]:  magi_vg is a cluster volume.        Ignoring...
Note
Par défaut, les VG sont clusterisés. Pour créer un VG local, il faut utiliser l’option -c n.

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 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.
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.
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/>.
   <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>
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 :
root@balthasar# ccs_tool update /etc/cluster/cluster.conf
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 :
#!/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
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 :
#!/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
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.
<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>
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 :
root@balthasar# mkfs.ext3 /dev/magi_vg/test_lv
Nous pouvons maintenant propager la configuration sur les autres nœuds du cluster :
root@balthasar# ccs_tool update /etc/cluster/cluster.conf
Après quelques secondes, vous pouvez vérifier que le service est connu du cluster via la commande suivante :
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      
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 :
root@balthasar# clusvcadm -e test
Local machine trying to enable service:test...Success
service:test is now running on balthasar.localdomain
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.
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

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.
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
Nous vérifions...
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
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 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.


1 commentaire :

  1. 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