Nous vous proposons de conjuguer différentes technologies libres. L’idée est d’obtenir une petite installation de virtualisation de serveurs en haute disponibilité. Si nous parlons de petite installation, c’est que nous ne prévoyons que deux serveurs de virtualisation sans stockage partagé (type sans iscsi). Nous utiliserons donc un mécanisme de réplication des données. Pour ce test, nous allons utiliser les logiciels Pacemaker, DRBD et Xen.
Nous avons installé une distribution CentOS sur des serveurs ayant accès à Internet pour faciliter l’obtention des logiciels. Nous passerons outre l’installation et la configuration de base des trois logiciels, de nombreux tutoriaux sont disponibles sur Internet (lire notre encadré).
Fonctionnement de Pacemaker
L'affichage de l'état des ressources.
Nous vous présentons le principe de configuration des ressources mais sans vouloir être exhaustif. Ces éléments vous permettront de mieux comprendre la configuration de Pacemaker. Un peu de théorie. La confi guration du cluster est contenue dans un Cluster Information Base (cib). Il est possible d’en créer de nouveaux pour effectuer des tests sans influer sur la confi guration en production.
Le cluster fonctionne par événements pour gérer l’exécution des ressources. Il prend également en compte les préférences d’exécution sur un noeud ou l’autre suivant un mécanisme de pondération des ressources.
Cette pondération peut avoir une valeur positive ou négative :
• + infinie : obligation d’exécution de la ressource (valeur noté ‘inf’ dans les commandes)
• Valeur comprise entre 0 et + l’infinie : préférence d’exécution de la ressource
• Valeur comprise entre - l’infinie et 0 : préférence de non-exécution de la ressource
• - infinie : interdiction d’exécution de la ressource (valeur noté ‘-inf’ dans les commandes)
Shell de configuration
Le shell du cluster resource manager est un moyen de s’interfacer avec la base de configuration en xml. Il intègre la complétion des commandes lorsqu’on appuie deux fois sur la touche tabulation. Cela est pratique pour connaître les commandes ou paramètres possibles.
Il est possible de créer des cib temporaires (Cluster Information Base) qui permettent de tester une configuration sans l’appliquer directement sur la configuration active.
La création d’une ressource s’effectue avec une entrée nommée « primitive » dans la cib. Cette « primitive » fait appel à un script d’application correspondant à l’application à protéger. Il faut choisir ocf ou lsb, le premier correspond aux scripts développés pour pacemaker, le second correspond aux scripts de démarrage de Linux. Cependant, il faut vérifi er leur compatibilité au préalable. On indique ensuite des paramètres propres à l’application à protéger – ici encore la double tabulation listera les possibilités –, ainsi que des opérations (monitor, start, stop, etc). Il est ensuite possible de définir des contraintes qui vont moduler l’exécution des ressources :
• contrainte locative : elle permet de définir une préférence ou une obligation d’exécution d’une ressource sur un noeud ;
• contrainte colocative : elle permet d’obliger une ressource à fonctionner sur le même noeud où s’exécute une autre ressource (l’obligation peut être une interdiction ou autre, suivant la <valeur> de la pondération) ;
• contrainte d’ordre : elle permet d’ordonner le démarrage / arrêt des ressources.
Toute modification dans la cib doit être appliquée à la cib courante pour la rendre effective. À ce stade, nous avons configuré drbd comme suit :
[root@srvdb ~]# cat /etc/drbd.conf
#
# please have a a look at the example configuration file in
# /usr/share/doc/drbd83/drbd.conf
#
global {
usage-count no;
}
common {
protocol C;
syncer {rate 150M;}
}
}
resource drbd0 {
device /dev/drbd0;
disk /dev/hdc1;
meta-disk internal;
on srvdb { address 10.0.0.1:7788; }
on srvdb2 { address 10.0.0.2:7788; }
}
Et intégrer une partie des ressources dans Pacemaker :
crm(live)confi gure# show
node srvdb
node srvdb2
primitive drbd_xen ocf:linbit:drbd \
params drbd_resource="drbd0" \
op monitor interval="15s"
primitive xen_fs ocf:heartbeat:Filesystem \
params device="/dev/drbd0"
directory="/SrvTest" fstype="ext3"
ms ms_drbd_xen drbd_xen \
meta master-max="1" master-nodemax="1" clone-max="2" clone-nodeR
max="1" notify="true"
colocation xfs_avec_drbd inf: xen_fs
ms_drbd_xen:Master
order xfs_apres_drbd inf: ms_drbd_
xen:promote xen_fs:start
property $id="cib-bootstrap-options" \
dc-version="1.0.10-da7075976b5ff0bee71074385f8fd02f296ec8a3"\
cluster-infrastructure="openais" \
expected-quorum-votes="2" \
last-lrm-refresh="1295386489" \
no-quorum-policy="ignore" \
stonith-enabled="false" \
default-resource-stickiness="1000"
Utilisation de Xen
Pour la partie hyperviseur, nous avons utilisé une plate-forme CentOS à partir de laquelle nous avons installé Xen et les outils de gestions libvirt inclus dans les dépôts. Ces outils comportent des commandes en ligne et de shell (virt-install, virsh, etc), ainsi qu’un outil graphique (virtmanager). Nous avons utilisé les deux. Même s’il faut reconnaître que la console graphique est plus facile à utiliser, l’usage des lignes de commandes ne présentent pas de difficultés particulières.
Création d’un serveur virtuel
Nous avons donc créé un serveur linux, toujours sur base cent os, en ligne de commande à partir des sites miroirs disponibles sur Internet :
#> virt-install \
–name srv2 \
–ram 256 \
– disk path=/SrvTest/srv2.img,size=3 \
–location http://mirrors.centos.org/
centos/5/os/i386
L’exécution de cette commande nous envoie sur le processus d’installation de la distribution Linux.
Intégration à pacemaker
Il ne reste plus qu’à créer une ressource pour protéger ce serveur virtuel à l’aide de pacemaker. Pour cela, nous rajoutons une primitive dans la configuration ainsi que des contraintes pour que cette ressource
s’exécute sur le même noeud où la ressource drbd est maître. Voici la sortie de la commande « crm configure show ». Ce qui suit est la configuration complète du cluster.
node srvdb
node srvdb2
primitive drbd_xen ocf:linbit:drbd \
params drbd_resource="drbd0" \
op monitor interval="15s"
primitive srv2 ocf:heartbeat:Xen \
params xmfi le="/etc/xen/srv2" \
op monitor interval="20s"
primitive xen_fs ocf:heartbeat:Filesystem\
params device="/dev/drbd0"
directory="/SrvTest" fstype="ext3"
ms ms_drbd_xen drbd_xen \
meta master-max="1" master-nodemax="
1" clone-max="2" clone-nodemax="
1" notify="true"
colocation srv2_avec_xfs inf: srv2
xen_fs
colocation xfs_avec_drbd inf: xen_fs
ms_drbd_xen:Master
order srv2_apres_xfs inf: xen_fs:start
srv2:start
order xfs_apres_drbd inf: ms_drbd_
xen:promote xen_fs:start
property $id="cib-bootstrap-options" \
dc-version="1.0.10-da7075976b5ff0bee71074385f8fd02f296ec8a3"\
cluster-infrastructure="openais" \
expected-quorum-votes="2" \
last-lrm-refresh="1295386489" \
no-quorum-policy="ignore" \
stonith-enabled="false" \
default-resource-stickiness="1000"
Utilisation d’une interface graphique
La console de migration.
L’interface graphique utilisée est celle développée par les développeurs de DRBD. Elle permet de gérer également pacemaker. Vous pouvez la télécharger à l’adresse suivante :
http://www.drbd.org/download/drbd-mc/
L’applet fonctionne aussi bien sur Windows que sur Linux. Sous Windows, double-cliquez sur l’applet pour la lancer. Sous Linux, exécutez la commande suivante :
#> /chemin_vers_java/java –jar /
chemin_ver_applet/DMC-xxx.jar
Des assistants permettent de vous connecter aux noeuds puis de créer un cluster (pour récupérer la configuration déjà effectuée sur le cluster).
Conclusion
Finalement, lorsque l’on comprend les différentes technologies utilisées ici, l’ensemble est plutôt cohérent et parvient à fonctionner de concert. Il faut garder à l’esprit qu’il existe une barrière entre les deux fonctions de la plate-forme : haute disponibilité et virtualisation. Chacune de ces fonctions nécessitent des tâches spécifiques avec des outils spécifiques. On ne bénéficie pas ici de l’intégration d’un outil packagé dans une offre commerciale.
Pour avoir fait subir le test de mettre en cluster un serveur virtuel à un novice de ces deux technologies (ce qui s’est terminé par un échec), nous pouvons vous conseiller d’aborder chaque domaine (ha, xen) séparément et la tête reposée, car ils nécessitent chacun un temps d’apprentissage. Une fois ces deux apprentissages réalisés, la mise en cluster de xen s’effectue réellement très simplement. Un point important sera donc de bien documenter son travail pour que quiconque devra y toucher puisse comprendre ce que vous avez fait. L’administration d’une telle plate-forme n’est pas neutre. Le transfert de compétences à vos collègues sera important si vous tenez à pouvoir partir en vacances sereinement. Pacemaker est une solution de haute disponibilité très puissante et offre de nombreuses possibilités d’automatisation suivant des événements et des états. Il est intéressant de s’y essayer pour réaliser à quel point il est important de commencer avec une configuration simple et cohérente dont vous pourrez anticiper les réactions.
POUR ALLER PLUS LOIN
www.clusterlabs.org : la haute disponibilité avec Pacemaker.
www.drbd.org : le système de réplication – et la console d’administration.
www.xen.org : pour toute référence à l’hyperviseur.
www.centos.org : pour la distribution utilisée ici – choix purement arbitraire.
Pour en savoir plus
L’Informaticien et le Competence Center, de Non Stop Systems, sont
partenaires pour la réalisation de tests de logiciels, de matériels ou de
services du marché. Si vous souhaitez obtenir davantage d’informations
sur ces tests, n’hésitez pas à contacter Non Stop Systems à cette adresse :
ZI de la Madeleine, 27, rue de la Maison-Rouge, 77185 LOGNES
Tél. : +33 (0)1 60 95 08 80
Fax : +33 (0)1 60 95 08 81
ou sur le site
www.nonstop.fr