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.
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
|
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 -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
|
|
|
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.
|
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.
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
|
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é.
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.
Comme il est de coutume, Linus Torvalds a annoncé via un message
sur LKLM (Linux Kernel Mailing List) la sortie du noyau Linux 3.8.
