Kvm Cluster & Lvm & Drdb

KVM est l'hyperviseur libre supporté par RedHat. Il est extrêmement simple et facile d'utilisation. Par rapport à Xen, il n'oblige pas de faire tourner un kernel linux spécifique et se présente sous la forme de modules kernel. Chaque VM est vu comme un process lambda sur l'hyperviseur et un "ps" permet de voir les VM qui tournent. Par défaut, il n'existe pas de commande equivalente au "xm" de Xen. Afin d'agir sur les VM KVM, il faut passer par libvirtd qui est un daemon d'abstraction multi-hyperviseur.

Cette page est une mise en pratique pour monter 2 serveurs kvm en cluster avec drbd & lvm.

Lien annexe

* Commandes Kvm cluster & généralités
* Commandes Drbd & généralités
* Commandes Lvm & généralités
* Script de vérification du drbd
* Script de vérification de l'alocation des vm

Présentation

Voilà les informations niveau serveur / ip / volume de ce tutorial. Afin de minimiser le risque d'écriture simultanée et donc de crash possible du volume drbd, on va avoir un volume "dédié" aux vm sur un noeud et un autre volume pour les vm de l'autre noeud (le volume volimages est facultatif est sert juste pour le déploiement d'images préconfigurés, il n'a pas de vocation à être souvent écris). Toutes les vm qui tournent sur node05 devront être sur le VG volnode05 et les vm qui tournent sur node06 devront etre sur volnode06. Sinon si c'est mélangé, les 2 nodes vont vouloir écrire en même temps sur le même VG / volume drbd et il y a un très fort risque de crash.

Il ne faut pas partitionner le disque en 2 partitions égales, mais en 1 partition qui fera la taille (ou un peu plus) de toutes les vm qui seront sur node05, et une 2eme partition qui fera la taille (ou un peu plus pour ne pas laisser de la place non utilisée) de toutes les vm qui seront sur node06.

Shemas drbd

 - 2 serveurs : node05.c01.cloud.agarik.com & node06.c01.cloud.agarik.com (hostname des serveurs)
 - 1 ip d'admin : 192.168.10.14 pour node05, 192.168.10.15 pour node06
 - 3 ip en alias pour chaque volume drbd (sur chaque serveur, et avec un cable en direct entre les 2 serveurs, 172.30.136.xx)
 - Ip node05 : 172.30.136.13 & 172.30.136.15 & 172.30.136.17
 - Ip node06 : 172.30.136.14 & 172.30.136.16 & 172.30.136.18
 - On a 3 VG : un pour les images (volimages), un pour les vm sur node05 (volnode05) et un pour les vm sur node06 (volnode06)
 - On a 3 volumes drbd
 - les vm seront créées sur des LV

Installation

/etc/hosts

Attention : il est très important sur la ligne avec l'ip qui sert au cluster (ip du drbd en fait) 172.30.136.1x d'avoir en premier le nom du "clusternode name" présent dans cluster.conf, sinon lorsque l'on va lancer cman, on va avoir le message "Starting cman... Cannot find node name in cluster.conf, Unable to get the configuration,Cannot find node name in cluster.conf"

Ici on utilise le hostname du serveur (node05.c01.cloud.agarik.com) qui sera présent dans cluster.conf au niveau du "clusternode name". Mais on peut très bien mettre un autre nom que le hostname du serveur dans le cluster.conf mais il faudra bien le mettre dans le /etc/hosts. C'est par cette ip que les vm vont etre migrés.

Le mieux est de définir un autre hostname lié à l'ip du drbd, et qui sera dans mis dans le fichier cluster.conf (au niveau du "clusternode name", "nodename"). Cela permet de garder un fichier /etc/hosts plus classique

# node05
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
172.30.136.13   node05.c01.cloud.agarik.com
172.30.136.14   node06.c01.cloud.agarik.com

# node06
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
172.30.136.13   node05.c01.cloud.agarik.com
172.30.136.14   node06.c01.cloud.agarik.com

Kvm

Kvm est souvent par défaut sur les distributions. Les services suivant doivent être lancés pour que kvm fonctionne : messagebus, libvirtd, libvirt-guests

Cluster

Pour les commandes liées au cluster voir cette page

Voilà les packages à installer pour la partie cluster : openais cman rgmanager lvm2-cluster gfs2-utils cluster-cim

Drbd

On peut l'installer via les packages, mais il est préférable d'installer la dernière version via les sources :
# cd /root/install/
# cd drbd-8.4.1/
# ./configure
# make rpm
# Pour que le make km-rpm ci dessous puissent fonctionner il faut installer les kernel-devel de la version du kernel qui tourne
# make km-rpm 
# cd /root/rpmbuild/RPMS/x86_64/ (vérifier où il a installé les rpm, il le marque à la fin du make km-rpm)
# rpm -Uvh drdb*

Configuration

Multipath & disque SAN

Dans les cas ou le disque où va être le drbd est un disque SAN (lun netapp par exemple) en multipath, il y a 2 modifications à faire :

• drbd.conf

Il faut faire le cfdisk sur /dev/mapper/$alias (alias défini dans le multipath.conf, ici VM) et dans le drbd.conf ne pas mettre /dev/sdX mais /dev/mapper/$alias$partition

• lvm.conf

Une fois la synchro drbd fini, on va créer le PV avec la commande pvcreate /dev/drbd0. Le soucis est qu'avec une conf lvm de base, le pv créé va s'appeler du nom du path du San /dev/mapper/VMp1.
Ce qui n'est pas bon car on va avoir un PV dans un PV. (Si c est du drbd sur des disques locaux ce n est pas la peine)
Il faut remplacer dans /etc/lvm.conf filter = [ "a/.*/" ] par filter = [ "a|drbd.*|", "r|.*|" ]. Puis relancer clvmd. On aura alors bien un PV qui va s'appeler drbdX
La modification du filtre concerne uniquement le cas ou on a un multipath.  Il serait préférable d'exclure le chemin du lun (/dev/mapper/VMp1), plutot que de n'accepter que les device
en drbd* (car si on créé un autre PV classique qui ne s'appelle pas drbdX, on ne le verra pas)

Alignement des disques

Que l'on soit sur un drbd sur des disques locaux ou sur un lun netapp monté, il est préférable de partitionner le disque en prenant soit d'avoir un alignement des blocs optimal

or those who are curious though, this is why falling on 64 KiB boundaries are important.

Imagine this misaligned scenario;

Note: Not to scale
                 ________________________________________________________________
VM File system  |~~~~~|_______|_______|_______|_______|_______|_______|_______|__
                |~~~~~|==========================================================
DRBD Partition  |~~~~~|_______|_______|_______|_______|_______|_______|_______|__
64 KiB block    |_______|_______|_______|_______|_______|_______|_______|_______|
512byte sectors |_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|

Now, when the guest wants to write one block worth of data, it actually causes two blocks to be written, causing avoidable disk I/O. That effectively doubles the number of IOPS needed, a huge waste of 
disk resources.

Note: Not to scale
                 ________________________________________________________________
VM File system  |~~~~~~~|_______|_______|_______|_______|_______|_______|_______|
                |~~~~~~~|========================================================
DRBD Partition  |~~~~~~~|_______|_______|_______|_______|_______|_______|_______|
64 KiB block    |_______|_______|_______|_______|_______|_______|_______|_______|
512byte sectors |_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|

By changing the start cylinder of our partitions to always start on 64 KiB boundaries, we're sure to keep the guest OS's file system in-line with the DRBD backing device's blocks. Thus, all reads and 
rites in the guest OS effect a matching number of real blocks, maximizing disk I/O efficiency. 

• Pour cela nous allons utiliser la commande parted :

!!! ATTENTION !!! parted est en GB (base 10) alors que LVM en GiB (base 2). If we used LVM's "xxG size notation, it will use more space than we expect, relative to our planning in the 
parted stage. LVM doesn't allow specifying new LV sizes in GB instead of GiB, so here we will specify sizes in MiB to help narrow the differences"

# parted -a optimal /dev/sda

(parted) p
Model: DELL PERC H710 (scsi)
Disk /dev/sda: 600GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type      File system     Flags
 1      32.3kB  115MB   115MB   primary   ext4            boot
 2      115MB   2270MB  2155MB  primary   linux-swap(v1)
 3      2270MB  23.8GB  21.5GB  primary   ext4
 4      23.8GB  600GB   576GB   extended

(parted) u Gib
(parted) mkpart logical 22.1GiB 122.1GiB
(parted) mkpart logical 122GiB 340GIb
(parted) mkpart logical 340GiB 558GiB 

drbd.conf

Meme configuration sur les 2 serveurs

!!! Attention à ne pas avoir d alias sur la même interfacec avec des ip de subnet différents, on a eu des pb de synchro drbd. Il vaut mieux changer les ports si on a beaucoup de noeuds !!!

#
# please have a a look at the example configuration file in
# /usr/share/doc/drbd83/drbd.conf
#

global {
        usage-count no;
        # minor-count dialog-refresh disable-ip-verification
}

common {
       protocol C;

       startup {
               wfc-timeout 300;
               degr-wfc-timeout 10;
               become-primary-on both;
       }

       disk {
               on-io-error detach;
               fencing dont-care;
       }

       syncer {
               rate 110M;
       }

       net {
               timeout 50;
               connect-int 20;
               ping-int 30;
               allow-two-primaries;
               after-sb-0pri discard-zero-changes;
               after-sb-1pri discard-secondary;
               after-sb-2pri disconnect;

       }
}

resource drbd0 {
       on node05.c01.cloud.agarik.com {
               disk /dev/sdb1;
# Ou dans le cas d'un lun en multipath
#                disk /dev/mapper/VMp1;
               device /dev/drbd0;
               meta-disk internal;
               address 172.30.136.13:7788;
       }
       on node06.c01.cloud.agarik.com {
               disk /dev/sdb1;
# Ou dans le cas d'un lun en multipath
#                disk /dev/mapper/VMp1;
               device /dev/drbd0;
               meta-disk internal;
               address 172.30.136.14:7788;
       }
       syncer {
               rate 110M;
       }

}

resource drbd1 {
       on node05.c01.cloud.agarik.com {
               disk /dev/sdb2;
# Ou dans le cas d'un lun en multipath
#                disk /dev/mapper/VMp2;
               device /dev/drbd1;
               meta-disk internal;
               address 172.30.136.15:7788;
       }
       on node06.c01.cloud.agarik.com {
               disk /dev/sdb2;
# Ou dans le cas d'un lun en multipath
#                disk /dev/mapper/VMp2;
               device /dev/drbd1;
               meta-disk internal;
               address 172.30.136.16:7788;
       }
       syncer {
               rate 110M;
       }

}

resource drbd2 {
       on node05.c01.cloud.agarik.com {
               disk /dev/sdb3;
# Ou dans le cas d'un lun en multipath
#                disk /dev/mapper/VMp3;
               device /dev/drbd2;
               meta-disk internal;
               address 172.30.136.17:7788;
       }
       on node06.c01.cloud.agarik.com {
               disk /dev/sdb3;
# Ou dans le cas d'un lun en multipath
#                disk /dev/mapper/VMp3;
               device /dev/drbd2;
               meta-disk internal;
               address 172.30.136.18:7788;
       }
       syncer {
               rate 110M;
       }

}

Initialisation et creation des drbd

Il faut juste creer les partitions avec cfdisk en type linux, ne pas les formater. Après avoir fait la conf drbd.conf, il faut démarrer /etc/init.d/drbd start sur les 2 (cela va faire des "erreurs" pendant 30 secondes et apres rendre la main), on peut alors lancer les commandes d'initialisation. Créer bien sur dans un premier temps 3 partitions (un pour chaque volume drbd) sur un disque physique différent du disque system. Ces 3 partitions seront exactement les mêmes sur les 2 serveurs (les 3 partitions peuvent ne pas avoir la même taille, mais la partition1 de node05 aura la meme taille que la partion1 de node06, et pareil pour les autres partitions).

Voilà l'état de # cat /proc/drbd juste après le start de drbd :

GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by root@kvm1.grdf.fr, 2013-06-11 17:29:52
 0: cs:Connected ro:Secondary/Secondary ds:Diskless/Diskless C r-----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
 1: cs:Connected ro:Secondary/Secondary ds:Diskless/Diskless C r-----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

• Sur chaque node et pour chaque device (synchronisation initiale des volumes DRBD)

# /etc/init.d/drbd start (si il n est pas démarré)

# drbdadm down drbd0

# cat /proc/drbd (pour info, le noeud drbd0 n'est plus visible) 
version: 8.4.3 (api:1/proto:86-101)
GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by root@kvm2.grdf.fr, 2013-06-11 17:30:01
 1: cs:Connected ro:Secondary/Secondary ds:Diskless/Diskless C r-----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

# drbdadm create-md drbd0
Writing meta data...
initializing activity log
NOT initializing bitmap
New drbd meta data block successfully created.

# drbdadm up drbd0 (Si erreur "Can not open backing device" lors du drbdadm up drbd0 voir cette [https://{{SERVERNAME}}/index.php/Drbd page])

# cat /proc/drbd (pour info, doit être en cs:Connected ro:Secondary/Secondary ds:Inconsistent/Inconsistent C r-----)
version: 8.4.3 (api:1/proto:86-101)
GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by root@kvm2.grdf.fr, 2013-06-11 17:30:01
 0: cs:Connected ro:Secondary/Secondary ds:Inconsistent/Inconsistent C r-----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:878222580

• Sur un des noeud et pour chaque device. !!! Il est préférable dans l'absolu de faire cela sur 1 premier device, attendre que la synchro soit finie, puis passer à l'autre device !!!

# drbdadm -- --overwrite-data-of-peer primary drbd0

Lorsque l'on part de disque vierge, on peut lancer cette commande (ca permet d avoir la synchro instantannée) :
# drbdadm -- --clear-bitmap new-current-uuid drbd0



# cat /proc/drbd (pour info, la synchronisation est entrain de se lancer)
 0: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r-----
    ns:321816 nr:0 dw:0 dr:322480 al:0 bm:19 lo:0 pe:36 ua:0 ap:0 ep:1 wo:f oos:877904628
        [>....................] sync'ed:  0.1% (857328/857636)M
        finish: 3:04:02 speed: 79,488 (79,488) K/sec

* Une fos la synchro finie, sur le noeud qui est en secondary (faire un cat /proc/drbd), et pour chaque device
#drbdadm primary drbd0

Le cat /proc/drbd doit remonter en cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r-----

Intégration des nodes

# Sur les 2 noeuds : 
1/ modif lvm.conf :
    locking_type = 3
    fallback_to_clustered_locking = 0

cluster.conf

Les "clusternode name" et "nodename" (ici node05|06.c01.cloud.agarik.com) doivent etre renseignés dans le /etc/hosts avec l'ip qui servira à la migration des vm / synchro drbd. Ce nom peut être différent du hostname. Le "failoverdomain name" (ici kvm_node05|06) n'a pas à être renseigné dans le /etc/hosts, il doit être différent de tous les autres noms. Même cluster.conf sur les 2 serveurs.

<?xml version="1.0"?>
<cluster config_version="02" name="agacloud001_c3">
        <clusternodes>
                <clusternode name="node05.c01.cloud.agarik.com" nodeid="1" votes="1">
                        <fence>
                                <method name="1">
                                        <device name="fence_fake" nodename="node05.c01.cloud.agarik.com"/>
                                </method>
                        </fence>
                </clusternode>
                <clusternode name="node06.c01.cloud.agarik.com" nodeid="2" votes="1">
                        <fence>
                                <method name="1">
                                        <device name="fence_fake" nodename="node06.c01.cloud.agarik.com"/>
                                </method>
                        </fence>
                </clusternode>
        </clusternodes>
        <cman expected_votes="1" two_node="1"/>
        <fencedevices>
                <fencedevice agent="fence_fake" name="fence_fake"/>
        </fencedevices>
        <rm>
                <failoverdomains>
                        <failoverdomain name="kvm_node05" nofailback="0" ordered="1" restricted="0">
                                <failoverdomainnode name="node05.c01.cloud.agarik.com" priority="1"/>
                                <failoverdomainnode name="node06.c01.cloud.agarik.com" priority="2"/>
                        </failoverdomain>
                        <failoverdomain name="kvm_node06" nofailback="0" ordered="1" restricted="0">
                                <failoverdomainnode name="node05.c01.cloud.agarik.com" priority="1"/>
                                <failoverdomainnode name="node06.c01.cloud.agarik.com" priority="2"/>
                        </failoverdomain>
                </failoverdomains>
                <resources/>
           <resources/>
<-- Exemple de conf de vm en cluster
<vm autostart="1" domain="kvm_node05" exclusive="0" hypervisor="qemu" migrate="live" name="aquarius_000200_MFA_mfa.fr_prodwsrv1.mfa.fr" path="/etc/libvirt/qemu/" recovery="relocate" 
use_virsh="1"/>
<vm autostart="1" domain="kvm_node06" exclusive="0" hypervisor="qemu" migrate="live" name="aquarius_000199_MFA_mfa.fr_prodweb1.mfa.fr" path="/etc/libvirt/qemu/" recovery="relocate" 
use_virsh="1"/>
        </rm>
</cluster>

/usr/sbin/fence_fake

#vim /usr/sbin/fence_fake

#!/bin/sh
echo "success: fence_fake $1"
exit 0

chmod +x /usr/sbin/fence_fake 

Clés ssh

Pour que les vm puisse migrer entre les 2 serveurs, il faut que les données puissent se copier en ssh

# sur node05
ssh-keygen
ssh-copy-id node06.c01.cloud.agarik.com
ssh node06.c01.cloud.agarik.com

# sur node06
ssh-keygen
ssh-copy-id node05.c01.cloud.agarik.com
ssh node05.c01.cloud.agarik.com

Il faut aussi mettre une clé en locale pour que le serveur puisse faire du ssh sur lui meme (ex : sur node05, ssh node05.c01.cloud.agarik.com)

Lancement du cluster

service cman start
service clvmd start
service rgmanager start

Mise en place des PV LVM en cluster

Avant de faire les pvcreate & vgcreate, attendre que la synchro drbd soit finie. Les services cman, clvmd et rgmanager doivent être démarrés pour que les vgcreate en cluster puissent etre créés.

• Sur un node et pour chaque device (création des PV LVM)

1. pvcreate /dev/drbd0

!! Attention sur un lun directement sans drbd, il ne faut pas faire de partition sinon le pvcreate ne passe pas !!!

• Sur un des 2 nodes

1. vgcreate -cy volimages/dev/drbd0 (le -cy s'est pour cluster=yes)
2. vgcreate -cy volnode05 /dev/drbd1
3. vgcreate -cy volnode06 /dev/drbd2

Lorsqu on créé les VG sur les drbd (vgcreate -cy volimages /dev/drbd0), le lien /dev/volimages n'existera pas tant qu on n a pas créé de LV sur le VG en question. Il est possible de faire un resize des LV(en augmentation c'est sur, en reduction cela est toujours risqué) car le drbd est au niveau des PV. On peut donc normalement faire aussi un resize des VG (pas testé) mais pas des PV

Ricci

Le script d'init code en dur le chemin vers openssl. Le lien symbolique évite de péter le script en cas d'upgrade du rpm
# ln -s /opt/applis/openssl/bin/openssl /usr/bin/openssl
# service ricci start
Mettez enfin un passwd au user ricci automatiquement créé (identique sur les 2 serveurs) 

died unexpectedly

Il peut arriver que la commande "cman_tool -r version" ou autres commandes liées à ricci envoient un "the connection to nodexxx.net died unexpectedly". Il s agit du certificat de ricci (qui est créé lors de l installation) qui a expiré. Pour remédier à cela :

Pour voir la date de validité du certificat : # openssl x509 -in /var/lib/ricci/certs/cacert.pem -text | grep "Not After"
Not After : Apr 19 16:30:56 20216 GMT

#  /etc/init.d/ricci stop
# rm -f /var/lib/ricci/certs/cacert.pem
# rm -f /var/lib/ricci/certs/privkey.pem
# rm -f /var/lib/ricci/certs/{cert8.db,key3.db,secmod.db,server.p12}

# /etc/init.d/ricci start

# openssl x509 -in /var/lib/ricci/certs/cacert.pem -text | grep "Not After"
            Not After : Apr 20 13:00:01 2022 GMT

Hack qemu-kvm

Dans certaines versions de qemu, il y'avait des problèmes de perfs des cartes réseaux

/usr/libexec/qemu-kvm.txtimer

#!/bin/sh
exec /usr/libexec/qemu-kvm `echo "$@" | sed 's|virtio-net-pci|virtio-net-pci,tx=timer|g'`

Services au démarrage

Les services dédiés au cluster doivent être configuré dans le chkconfig pour ne pas booter au démarrage. C'est un protection afin d'éviter de planter le cluster en cas de problème de synchro sur le DRBD lors d'un reboot. Si la synchro DRBD est cassé et que le cluster se lance, il y a des locks qui sont créés et il est impossible de rebooter la machine (en dehors d'un reboot hard électrique).

chkconfig cman off
chkconfig clvmd off
chkconfig rgmanager off
chkconfig ricci off
chkconfig corosync off

Il faut donc relancer manuellement les services suivant apres le démarrage :

service cman start
service clvmd start
service rgmanager start
service ricci start
service corosync start
service saslauthd start

Les services suivant doivent tourner :

cman
dlm_controld (dépend de cman)
fenced (dépend de cman)
clvmd
corosync
messagebus (servicé lancé au démarrage)
libvirtd (servicé lancé au démarrage)
libvirt-guests (servicé lancé au démarrage)
rgmanager
ricci
saslauthd (dépend de ricci)