informatique:systeme:ha:cluster_de_virtualisations_drbd_ocfs2_libvirt-kvm_pacemaker [Zionetrix]

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== Cluster de virtualisations DRBD/OCFS2/Libvirt-kvm/Pacemaker ======


===== Présentation de la solution =====
Ce cluster de virtualisations est basé sur la technologie KVM mettant à profit le support de la virtualisation matérielle au niveau des processeurs. Libvirt, une librairie d'abstraction de la virtualisation, est utilisée pour manipuler les machines virtuelles KVM. En cas d'incompatibilité avec la virtualisation matérielle (et donc avec KVM), qemu peut venir remplacer KVM avec des performances moindre. Un lien réseau dédié entre les machines physiques servira à la réplication DRBD, au maintien du cluster OCFS2, au communication inter-libvirt et à la surveillance de pacemaker.

Pour avoir un système de virtualisation permettant les bascules à chaud des machines virtuelles entre les machines physiques, il est nécessaire d'avoir un espace de stockage partagé et accessible depuis les deux machines physiques. Pour cela nous utiliserons DRBD (en mode primaire/primaire) et le système de fichiers répartis OCFS2. Controld est également présent afin d'avoir un mécanisme de lock partagé (=DLM). Cet espace de stockages contiendra les disques des machines virtuelles (sous la forme de fichiers) et la configuration de la libvirt commune entre les machines.

Pacemaker viendra ensuite se greffer sur l'architecture de virtualisation afin de mettre en place un système de prise de pouls permettant la haute-disponibilité des machines virtuelles. Pacemaker aura pour rôle de surveiller l'état des machines physiques afin d'assurer la reprise des machines virtuelles délaissées par une machines physiques indisponibles. Pacemaker manipulera les machines virtuelles au travers la libvirt.

<note warning>La compatibilité OCFS2/DRBD est fortement perturbée sur les derniers kernel. Il vaudrait mieux éviter ce couple à l'avenir. Une solution comme [[informatique:systeme:ha:ceth|Ceph]] (http://ceph.com/) semble une bonne alternative. Dans la mesure du possible, les clusters incluant de la réplication de système de fichiers sont bien souvent plus stable et plus facilement maintenable en mode actif/passif.</note>
===== Installation =====

==== Mise en place de la prise de pouls avec Pacemaker ====
  * Installez et mettez en place la configuration de base de [[informatique:systeme:ha:pacemaker|Pacemaker]].

==== Espace de stockage partagé ====

  * Installer et mettre en place [[informatique:systeme:ha:drbd|DRBD]]. Nous partirons du principe que vous devriez avoir un volume ///dev/drbd0// en mode primaire/primaire accessible depuis les deux machines physiques.
  * Installer et mettre en place le système de fichiers [[informatique:systeme:ha:ocfs2|OCFS2]].
  * Le volume //drbd0// doit maintenant être formaté avec le système de fichiers //OCFS2// il est donc normalement possible de monter ce volume sur les deux machines en même temps. Nous allons donc pouvoir mettre en place ce point de montage :
    * Créer le point de montage ///var/lib/libvirt// sur les deux machines

=== Gestion de l'espace partagé par Pacemaker ===

Nous allons faire en sorte que pacemaker gère toute la partie volume partagé. Pour cela, il faut commencer par désactiver le lancement automatique des services associés soit //drbd//, //o2cb// et //ocfs2//. Pour cela :
  * Supprimer les références au service dans les dossiers ///etc/rcX.d///. Pour cela, lancer les commandes suivantes :<code>insserv -r drbd -f
insserv -r ocfs2 -f
insserv -r o2cb -f</code>
  * Pour que notre modification ne soit pas écraser à chaque mise à jour, il nous faut supprimer les références à ces //runlevel// dans les headers LSB des scripts //init.d//. Pour cela, éditer les fichiers //drbd//, //o2cb// et //ocfs2// dans le dossier ///etc/init.d/// et modifier les header LSB de la manière suivante :
    * //Default-Start// : //vide//
    * //Default-Stop// : //vide//
    * //Short-Description// (si il est défini) : ajouté à la fin : //Managed by pacemaker.//
    * //Description// (si il est défini) : ajouté à la fin : //Managed by pacemaker.//


Arrêtons maintenant manuellement les services en question :<code>/etc/init.d/ocfs2 stop
/etc/init.d/o2cb stop
/etc/init.d/drbd stop</code>

Nous pouvons maintenant configurer pacemaker afin qu'il gère pour nous ces services :
  * Editer la configuration du cluster : <code>crm configure edit</code>
  * Ajouter les lignes suivantes dans la configuration : <code>primitive controld ocf:pacemaker:controld \
	op monitor interval="120s" \
	op start interval="0" timeout="90s" \
	op stop interval="0" timeout="100s"
primitive drbd0 ocf:linbit:drbd \
	params drbd_resource="r0" \
	op monitor interval="20" role="Master" timeout="20" \
	op monitor interval="30" role="Slave" timeout="20" \
	op start interval="0" timeout="240s" \
	op stop interval="0" timeout="100s"
primitive o2cb ocf:pacemaker:o2cb \
	op monitor interval="120s" \
	op start interval="0" timeout="90s" \
	op stop interval="0" timeout="100s"
primitive var_lib_libvirt ocf:heartbeat:Filesystem \
	params device="/dev/drbd/by-res/r0" directory="/var/lib/libvirt/" fstype="ocfs2" \
	op monitor interval="120s" timeout="40s" \
	op start interval="0" timeout="60s" \
	op stop interval="0" timeout="60s"
ms ms_drbd0 drbd0 \
	meta resource-stickines="100" notify="true" master-max="2" interleave="true"
clone clone_controld controld \
	meta globally-unique="false" interleave="true" clone clonepinggw pinggw target-role="Started" is-managed="true"
clone clone_o2cb o2cb \
	meta globally-unique="false" interleave="true" target-role="Started"
clone clone_var_lib_libvirt var_lib_libvirt \
	meta interleave="true" ordered="true"
colocation col_controld inf: clone_controld ms_drbd0:Master
colocation col_o2cb_controld inf: clone_o2cb clone_controld
colocation col_var_lib_libvirt_o2cb inf: clone_var_lib_libvirt clone_o2cb
order ord_controld_o2cb 0: clone_controld clone_o2cb
order ord_drbd_dlm 0: ms_drbd0:promote clone_controld
order ord_o2cb_var_lib_libvirt 0: clone_o2cb clone_var_lib_libvirt</code>
==== Mise en place de la virtualisation libvirt-kvm ====

  * Installer et mettre en place la [[informatique:systeme:virtualisation:libvirt-kvm|libvirt et kvm ]]
  * Etant donner que les machines virtuelles seront démarré par Pacemaker, nous allons neutraliser le démarrage automatique des machines virtuelles par la Libvirt en ajoutant les lignes suivantes au début du fichier ///etc/default/libvirt-bin// : <code># Prevent libvirt from autostarting VMs (started by pacemaker)
rm -f /etc/libvirt/qemu/autostart/*</code>
  * Nous allons déplacer la configuration de la libvirt dans l'espace de stockage repliqué : 
    * Stopper la libvirt sur les deux machines : <code>/etc/init.d/libvirt-bin stop</code>
    * Créer le dossier qui contiendra la configuration commune des libvirt : <code>mkdir -p /var/lib/libvirt/etc/libvirt/</code>
    * Rsyncer le dossier de configuration de la libvirt d'une des deux machines dans le dossier commun : <code> rsync -av /etc/libvirt/ /var/lib/libvirt/etc/libvirt/</code>
    * Supprimer le dossier ///etc/libvirt// sur les deux machines : <code>rm -fr /etc/libvirt/</code>
    * Créer un lien logique ///etc/libvirt// vers le dossier de configuration commun ///var/lib/libvirt/etc/libvirt/// sur les deux machines : <code>ln -s /var/lib/libvirt/etc/libvirt/ /etc/libvirt/</code>
    * Relancer la libvirt sur les deux machines : <code>/etc/init.d/libvirt-bin start</code>
  * Les migrations que les migrations entre les machines puissent être réalisées, il faut que les libvirt des deux machines puissent parler entre elles. Pour cela, des connexions SSH seront établis lorsque nécessaire entre les machines. Nous allons donc mettre en place une authentification par clé SSH entre les deux machines :
    * Sur les deux machines, en tant que root, générer une clé SSH pour l'utilisateur root avec la commande : <code>ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): [appuyer sur entrer]
Enter passphrase (empty for no passphrase): [appuyer sur entrer]
Enter same passphrase again: [appuyer sur entrer]
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
41:5a:11:73:f1:33:7c:58:74:9e:34:55:2e:a3:82:39 root@srvvirt1
The key's randomart image is:
+--[ RSA 2048]----+
|        *oo. .oo*|
|       + o o o.+o|
|      . .   * +.o|
|         +   = o |
|        E . .    |
|         . .     |
|                 |
|                 |
|                 |
+-----------------+</code>
    * Autoriser la connexion SSH en tant que root sur les deux machines avec les clés que l'on vient de générer :
      * Copier le contenu des fichiers ///root/.ssh/id_rsa.pub// dans le fichier ///root/.ssh/authorized_keys// des deux machines
      * Insérer dans le fichier ///etc/hosts// des enregistrements correspondant à vos machines physiques : <code>192.168.3.6     srvvirt1
192.168.3.7     srvvirt2</code>
    * Etablisser une première fois une connexion en tant que root vers les machines depuis les deux machines : <code>root@srvvirt1:~# ssh root@srvvirt1
The authenticity of host 'srvvirt1 (192.168.3.6)' can't be established.
RSA key fingerprint is 55:1b:dd:4c:db:d5:dd:ff:8e:42:ec:3d:f5:5f:d3:07.
Are you sure you want to continue connecting (yes/no)? [yes]
root@srvvirt1:~# [exit]
root@srvvirt1:~# ssh root@srvvirt2
The authenticity of host 'srvvirt2 (192.168.3.7)' can't be established.
RSA key fingerprint is 55:1b:dd:4c:db:d1:dd:ff:8e:42:ec:3d:ee:5f:d3:07.
Are you sure you want to continue connecting (yes/no)? [yes]
root@srvvirt2:~# [exit]</code>

De la même manière que les //drbd// et //ocfs2//, le //daemon libvirtd// sera géré par //Pacemaker//. Il faut donc désactiver le lancement automatique du service :
  * Supprimer les réfécences au service dans les dossiers /etc/rcX.d/. Pour cela, lancer la commande suivante : <code>insserv -r libvirt-bin</code>
  * Pour que notre modification ne soit pas écraser à chaque mise à jour, il nous faut supprimer les références à ces runlevel dans les headers LSB du script //init.d//. Pour cela, éditer le fichier ///etc/init.d/libvirt-bin// et modifier les header LSB de la manière suivante :
    * //Default-Start// : //vide//
    * //Default-Stop// : //vide//
    * //Short-Description// (si il est défini) : ajouté à la fin : //Managed by pacemaker.//
    * //Description// (si il est défini) : ajouté à la fin : //Managed by pacemaker.//
  * Arrêtons maintenant manuellement le service : <code>/etc/init.d/libvirt-bin stop</code>
  * Configurons maintenant //Pacemaker// pour qu'il gère le service :
    * Editer la configuration du cluster : <code>crm configure edit</code>
    * Ajouter les lignes suivantes dans la configuration : <code>primitive libvirtd lsb:libvirt-bin \
        op monitor interval="120s" \
        op start interval="0" \
        op stop interval="0"
clone clone_libvirtd libvirtd \
        meta globally-unique="false" interleave="true"
colocation col_libvirtd_var_lib_libvirt inf: clone_libvirtd clone_var_lib_libvirt
order ord_var_lib_libvirt_libvirtd 0: clone_var_lib_libvirt clone_libvirtd</code>

Pacemaker gère désormais //libvirtd// au travers son script //init//. Il ne sera lancé qu'après que le volume partagée soit pleinement fonctionnel.
===== Mise en place d'un accès direct au réseau pour les machines virtuelles =====
Si vous souhaitez que vos futres machines virtuelles est un accès direct à votre réseau, mettez en place des [[informatique:systeme:matos:interface_bridge|interfaces bridges]]. Vos interfaces bridges (//br0//, //br1//, ...) pourront ensuite être utiliser pour configurer vos machines virtuelles.



Le cluster est en place et fonctionnel. Vous pouvez dés à présent créer vos premières machines virtuelles

===== Administration du cluster =====
==== Création d'une machine virtuelle ====
  * Créé la machine virtuelle sur une des machines physiques via la libvirt. Vous pouvez utiliser l'outil [[informatique:systeme:virtualisation:libvirt-kvm:virt-manager]] (ou en ligne de commande, l'outil [[informatique:systeme:virtualisation:libvirt-kvm:virt-inst]]). Nous partons du principe que vous avez appeler cette machine virtuelle //srv1//.
  * Charger la configuration de la machine virtuelle dans la libvirt de l'autre machine physique en exécutant cette commande sur l'autre machine : <code>virsh define /etc/libvirt/qemu/srv1.xml</code>
  * Nous allons créer ensuite la ressource correspondante au niveau de pacemaker, et nous allons établir des règles de localisation de cette machine. Ces règles permettront d'établir ou tournera, en temps normal, notre machine virtuelle :
    * Editer la configuration du cluster pacemaker sur une des deux machines : <code>crm configure edit</code>
    * Ajouter la déclaration de la ressource (//primitive// au sens pacemaker) et des règles de localisation basés sur l'état de la ressource //pinggw// (reflétant l'état de la connectivité réseau des machines physiques) : <code>primitive vm-srv1 ocf:heartbeat:VirtualDomain \
        meta allow-migrate="true" \
        params config="/etc/libvirt/qemu/srv1.xml" migration_transport="ssh" \
        op start interval="0" timeout="5min" \
        op stop interval="0" timeout="5min" \
        op migrate_from interval="0" timeout="5min" \
        op migrate_to interval="0" timeout="5min"
location vm-srv1-on-srvvirt1 vm-srv1 50: srvvirt1
location vm-srv1-run-on-connected-srvvirt1 vm-srv1 \
        rule $id="vm-srv1-run-on-connected-srvvirt1-rule" -inf: not_defined pinggwval or pinggwval lt 100
order ord_libvirtd_vm-srv1 0: clone_libvirtd vm-srv1</code>

==== Démarrage, arrêt et migration d'une machine virtuelle ====
Bien qu'il est possible de démarrer ou d'arrêter une machine virtuelle en attaquant directement la libvirt de la machine la faisant ou qui doit la faire tourner, il est préférable de passer vos ordres de démarrage ou d'arrêt de votre machine virtuelle à pacemaker. Cela se justifie pour deux raisons principalement :
  * Il n'existe aucun mécanisme au niveau de la libvirt pour s'assurer que la machine ne tourne pas déjà sur l'autre machine physique au moment du démarrage. En cas de démarrage simultané de votre machine virtuelle sur les deux machines physiques, vous pourriez endommager l'image disque de celle-ci.
  * En passant vos ordres d'arrêt ou de démarage de vos machines virtuelles via pacemaker, vous vous assurez que ce dernier reste bien au courant d'où tourne ses ressources.

=== Démarrage d'une machine virtuelle ===
Utiliser la commande suivante : <code>crm resource start vm-srv1</code>

=== Arrêt d'une machine virtuelle ===
Utiliser la commande suivante : <code>crm resource stop vm-srv1</code>

=== Migration d'une machine virtuelle ===
En partant du principe que vous souhaitiez migrer la machine virtuelle //srv1// tournant actuellement sur la machine physique //srvvirt1// vers la machine physique //srvvirt2//, utilisez la commande suivante : <code>crm resource migrate vm-srv1 srvvirt2</code>

Cela aura pour conséquence de créer la règle de localisation suivante dans la configuration de votre cluster : <code>location cli-prefer-vm-srv1 vm-srv1 \
	rule $id="cli-prefer-rule-vm-srv1" inf: #uname eq srvvirt2</code>

Cette règle est créé afin de s'assurer que ce choix que vous venez de faire, sera appliqué en cas de reboot de la machine par exemple. Elle pourra être supprimée si cela n'est pas se que vous souhaitez. Si vous la supprimez cela n'aura aucune conséquence immédiate (c'est à dire que la machine ne sera pas migrer dans l'autre sens).

=== Mise en maintenance d'un serveur physique ===
A des fins de maintenance, il peut être nécessaire de devoir arrêtez toutes les machines tournant sur une machine physique. En réalité, il est plutôt préférable de migrer toutes ces machines vers l'autres serveurs.

  * Migrer toutes les machines virtuelles tournant sur la machine physique à mettre en maintenance en suivant la procédure de migration d'un machine virtuelle.
  * Arrêter pacemaker : <code>/etc/init.d/corosync stop</code>
  * Arrêter la libvirt : <code>/etc/init.d/libvirt-bin stop</code>
  * Démonter le volume DRBD : <code>umount /var/lib/libvirt</code>
  * Arrêter //ocfs2// puis //o2cb// : <code>/etc/init.d/ocfs2 stop
/etc/init.d/o2cb stop</code>
  * Arrêter //drbd// : <code>/etc/init.d/drbd stop</code>

Tout les services sont ainsi arrêtés. Pour les relancés, il faut suivre la démarche inverse :
  * Lancer //drbd// : <code>/etc/init.d/drbd start</code>
  * La réplication des données commence immédiatement. Il est nécessaire d'attendre la fin de la réplication complète des données pour pouvoir continuer. Vous pouvez la suivre avec la commance : <code>cat /proc/drbd</code>
  * Lancer ensuite //o2cb// puis //ocfs2// : <code>/etc/init.d/o2cb start
/etc/init.d/ocfs2 start</code>
  * Le volume //drbd// devrait être monté automatiquement au démarrage de //ocfs2//. Si ce n'ai pas le cas : <code>mount /var/lib/libvirt</code>
  * Lancer la //libvirt// : <code>/etc/init.d/libvirt-bin start</code>
  * Lancer //pacemaker// : <code>/etc/init.d/corosync start</code>

Le cluster est ainsi remonté. En outre les machines virtuelles tournant en temps normal sur notre machine physique sont toujours sur l'autre machine. Pour remettre tout dans un état normal :
  * Migrer les machines virtuelles via //crm// en suivant la procédure de migration
  * Editer la configuration et supprimer les règles de localisation des ressources de type //cli-prefer// créés automatiquement lors de leur migration : <code>crm configure edit</code>


===== Problème connus =====

<code>o2cb[11515]: ERROR: Setup problem: Couldn't find utility /usr/sbin/ocfs2_controld.pcmk
...
o2cb[11515]: ERROR: ocfs2_controld.pcmk did not come up</code>

Il semble que vous n'avez pas installer le paquet //dlm-pcmk//. Installer le et relancer corosync


<code>ocfs2_controld[13232]: Unable to connect to CKPT: Object does not exist</code>

Il semble que le service //cktp// fournis par corosync/openais ne soit pas disponible. Vérifier que le paquet //openais// est bien installé et que le service //cktp// est bien lancer par //corosync// (fichier ///etc/corosync/service.d/cktp//. Au besoin, référer vous au guide d'installation de [[informatique:systeme:ha:ocfs2|OCFS2]])


<code>Filesystem[27092]: INFO: Running start for /dev/drbd0 on /var/lib/libvirt
...
lrmd: [26579]: info: RA output: (var_lib_libvirt:1:start:stderr) Cluster stack specified does not match the one currently running
...
Filesystem[27092]: ERROR: Couldn't mount filesystem /dev/drbd0 on /var/lib/libvirt</code>
Cela peut arriver suite à une migration vers //openais//. Le volume //ocfs2// doit être convertie pour être géré par //openais//. Pour cela, il faut d'abord s'assurer que la partition n'est montée sur aucune des machines puis lancer la commande //fsck.ocfs2// sur le volume.