Cluster basé sur Red Hat Cluster Suite

Magazine
Marque
GNU/Linux Magazine
Numéro
133
Mois de parution
décembre 2010


Résumé

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.


Body

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.

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

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

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

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.

Les messages suivants dans les logs sont normaux dans le cas de VG clusterisés :

clurgmgrd: [18059]: magi_vg is a cluster volume. Ignoring...

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

Le nombre maximum de failover domains dans un cluster est égal au nombre de permutations sans répétition sur l'ensemble des serveurs du cluster, soit factorielle de n (n!). Dans le cas particulier du cluster magi, nous pourrions créer 6 failover domains.

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

<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

[...]

Date/Time : 2010-10-01 17:28:09

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/

 



Article rédigé par

Par le(s) même(s) auteur(s)

Virtualisation basée sur les LinuX Containers, aka LXC

Magazine
Marque
GNU/Linux Magazine
Numéro
159
Mois de parution
avril 2013
Spécialité(s)
Résumé
Cet article a pour objectif de vous présenter la technologie de virtualisation LXC [0.1]. Le terme de virtualisation n'est d'ailleurs pas vraiment adapté, car il n'y a pas de création de machine virtuelle en tant que telle. La page d'accueil du projet dit que LXC est parfois décrit comme « chroot gonflé aux stéroïdes », ce qui colle bien à l'esprit du projet. Au cours des prochaines pages, nous aborderons l'installation des outils LXC, la création d'un conteneur très simple à base de Busybox, puis un conteneur plus riche basé sur CentOS 6 et nous survolerons les aspects sécurité et intégration avec Libvirt.

Architecture DNS sécurisée

Magazine
Marque
GNU/Linux Magazine
Numéro
154
Mois de parution
novembre 2012
Spécialité(s)
Résumé
Pierre angulaire de l'infrastructure réseau, le service DNS est la cible de nombreuses attaques. Certains veulent le faire taire (déni de service), d'autres le faire mentir (empoisonnement de cache) ou s'appuyer sur lui pour attaquer d'autres serveurs DNS (récursivité mal configurée). Lorsque vous mettez en place ce service, vous avez à votre disposition plusieurs mécanismes qui limitent les risques face aux méchants pirates de l'Internet. Cet article vous guidera dans l'installation d'une architecture DNS multiniveau et implémentant DNSSEC.

389 Directory Server as ISC DHCP backend

Magazine
Marque
GNU/Linux Magazine
Numéro
123
Mois de parution
janvier 2010
Résumé

Dans mon précédent article, nous avions vu comment utiliser le serveur d'annuaire 389 Directory Server (389DS) pour stocker les données d'un serveur DNS. Nous gérons aussi nos comptes utilisateurs dans cet annuaire LDAP. Nous disposons donc d'une infrastructure dont une part non négligeable des données administratives sont stockées dans un annuaire. Et nous pouvons aller au-delà : stockons nos données DHCP dans un annuaire. Cet article se propose donc de vous montrer la marche à suivre pour le faire avec 389DS, dans la foulée du serveur DNS.

Les derniers articles Premiums

Les derniers articles Premium

De la scytale au bit quantique : l’avenir de la cryptographie

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Imaginez un monde où nos données seraient aussi insaisissables que le célèbre chat de Schrödinger : à la fois sécurisées et non sécurisées jusqu'à ce qu'un cryptographe quantique décide d’y jeter un œil. Cet article nous emmène dans les méandres de la cryptographie quantique, où la physique quantique n'est pas seulement une affaire de laboratoires, mais la clé d'un futur numérique très sécurisé. Entre principes quantiques mystérieux, défis techniques, et applications pratiques, nous allons découvrir comment cette technologie s'apprête à encoder nos données dans une dimension où même les meilleurs cryptographes n’y pourraient rien faire.

Les nouvelles menaces liées à l’intelligence artificielle

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Sommes-nous proches de la singularité technologique ? Peu probable. Même si l’intelligence artificielle a fait un bond ces dernières années (elle est étudiée depuis des dizaines d’années), nous sommes loin d’en perdre le contrôle. Et pourtant, une partie de l’utilisation de l’intelligence artificielle échappe aux analystes. Eh oui ! Comme tout système, elle est utilisée par des acteurs malveillants essayant d’en tirer profit pécuniairement. Cet article met en exergue quelques-unes des applications de l’intelligence artificielle par des acteurs malveillants et décrit succinctement comment parer à leurs attaques.

Migration d’une collection Ansible à l’aide de fqcn_migration

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Distribuer du contenu Ansible réutilisable (rôle, playbooks) par l’intermédiaire d’une collection est devenu le standard dans l’écosystème de l’outil d’automatisation. Pour éviter tout conflit de noms, ces collections sont caractérisées par un nom unique, formé d’une espace de nom, qui peut-être employé par plusieurs collections (tel qu'ansible ou community) et d’un nom plus spécifique à la fonction de la collection en elle-même. Cependant, il arrive parfois qu’il faille migrer une collection d’un espace de noms à un autre, par exemple une collection personnelle ou communautaire qui passe à un espace de noms plus connus ou certifiés. De même, le nom même de la collection peut être amené à changer, si elle dépasse son périmètre d’origine ou que le produit qu’elle concerne est lui-même renommé.

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous