Cluster de virtualisations DRBD/OCFS2/Libvirt-kvm/Pacemaker

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.

• Installez et mettez en place la configuration de base de Pacemaker.

• Installer et mettre en place 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 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

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 :

  insserv -r drbd -f
  insserv -r ocfs2 -f
  insserv -r o2cb -f

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

/etc/init.d/ocfs2 stop
/etc/init.d/o2cb stop
/etc/init.d/drbd stop

Nous pouvons maintenant configurer pacemaker afin qu'il gère pour nous ces services :

• Editer la configuration du cluster :

  crm configure edit

• Ajouter les lignes suivantes dans la configuration :

  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

• Installer et mettre en place la 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 :

  # Prevent libvirt from autostarting VMs (started by pacemaker)
  rm -f /etc/libvirt/qemu/autostart/*

• Nous allons déplacer la configuration de la libvirt dans l'espace de stockage repliqué :
  • Stopper la libvirt sur les deux machines :

    /etc/init.d/libvirt-bin stop

  • Créer le dossier qui contiendra la configuration commune des libvirt :

    mkdir -p /var/lib/libvirt/etc/libvirt/

  • Rsyncer le dossier de configuration de la libvirt d'une des deux machines dans le dossier commun :

     rsync -av /etc/libvirt/ /var/lib/libvirt/etc/libvirt/

  • Supprimer le dossier /etc/libvirt sur les deux machines :

    rm -fr /etc/libvirt/

  • Créer un lien logique /etc/libvirt vers le dossier de configuration commun /var/lib/libvirt/etc/libvirt/ sur les deux machines :

    ln -s /var/lib/libvirt/etc/libvirt/ /etc/libvirt/

  • Relancer la libvirt sur les deux machines :

    /etc/init.d/libvirt-bin start

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

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

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

      192.168.3.6     srvvirt1
      192.168.3.7     srvvirt2

  • Etablisser une première fois une connexion en tant que root vers les machines depuis les deux machines :

    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]

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 :

  insserv -r libvirt-bin

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

  /etc/init.d/libvirt-bin stop

• Configurons maintenant Pacemaker pour qu'il gère le service :
  • Editer la configuration du cluster :

    crm configure edit

  • Ajouter les lignes suivantes dans la configuration :

    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

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.

Si vous souhaitez que vos futres machines virtuelles est un accès direct à votre réseau, mettez en place des 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

• Créé la machine virtuelle sur une des machines physiques via la libvirt. Vous pouvez utiliser l'outil virt-manager (ou en ligne de commande, l'outil 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 :

  virsh define /etc/libvirt/qemu/srv1.xml

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

    crm configure edit

  • 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) :

    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

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.

Utiliser la commande suivante :

crm resource start vm-srv1

Utiliser la commande suivante :

crm resource stop vm-srv1

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 :

crm resource migrate vm-srv1 srvvirt2

Cela aura pour conséquence de créer la règle de localisation suivante dans la configuration de votre cluster :

location cli-prefer-vm-srv1 vm-srv1 \
	rule $id="cli-prefer-rule-vm-srv1" inf: #uname eq srvvirt2

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

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 :

  /etc/init.d/corosync stop

• Arrêter la libvirt :

  /etc/init.d/libvirt-bin stop

• Démonter le volume DRBD :

  umount /var/lib/libvirt

• Arrêter ocfs2 puis o2cb :

  /etc/init.d/ocfs2 stop
  /etc/init.d/o2cb stop

• Arrêter drbd :

  /etc/init.d/drbd stop

Tout les services sont ainsi arrêtés. Pour les relancés, il faut suivre la démarche inverse :

• Lancer drbd :

  /etc/init.d/drbd start

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

  cat /proc/drbd

• Lancer ensuite o2cb puis ocfs2 :

  /etc/init.d/o2cb start
  /etc/init.d/ocfs2 start

• Le volume drbd devrait être monté automatiquement au démarrage de ocfs2. Si ce n'ai pas le cas :

  mount /var/lib/libvirt

• Lancer la libvirt :

  /etc/init.d/libvirt-bin start

• Lancer pacemaker :

  /etc/init.d/corosync start

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 :

  crm configure edit

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

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

ocfs2_controld[13232]: Unable to connect to CKPT: Object does not exist

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

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

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.