Différences entre les versions de « Kvm Cluster & Lvm & Drdb »

Version du 12 juin 2013 à 10:41

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). Cela signifie que l'espace disque disponible correspondra à l'espace disque des 2 nodes / 2. 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.

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

# 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

drbd.conf

Meme configuration sur les 2 serveurs

#
# 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;
               device /dev/drbd0;
               meta-disk internal;
               address 172.30.136.13:7788;
       }
       on node06.c01.cloud.agarik.com {
               disk /dev/sdb1;
               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;
               device /dev/drbd1;
               meta-disk internal;
               address 172.30.136.15:7788;
       }
       on node06.c01.cloud.agarik.com {
               disk /dev/sdb2;
               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;
               device /dev/drbd2;
               meta-disk internal;
               address 172.30.136.17:7788;
       }
       on node06.c01.cloud.agarik.com {
               disk /dev/sdb3;
               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

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

pvcreate /dev/drbd0

Sur un des 2 nodes

vgcreate -cy volimages/dev/drbd0 (le -cy s'est pour cluster=yes)
vgcreate -cy volnode05 /dev/drbd1
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)

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

Les services suivant doivent tourner :

cman
messagebus
clvmd
libvirtd
libvirt-guests
rgmanager
ricci
fenced
dlm_controld
corosync

Différences entre les versions de « Kvm Cluster & Lvm & Drdb »

Version du 12 juin 2013 à 10:41

Sommaire

Lien annexe

Présentation

Installation

/etc/hosts

Kvm

Cluster

Drbd

Configuration

drbd.conf

Initialisation et creation des drbd

Intégration des nodes

cluster.conf

/usr/sbin/fence_fake

Clés ssh

Lancement du cluster

Mise en place des PV LVM en cluster

Ricci

Hack qemu-kvm

Services au démarrage

Menu de navigation

Actions de la page

Actions de la page

Outils personnels

Navigation

Rechercher

Outils

@@ Ligne 248 : / Ligne 248 : @@
 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.
 <pre>

Différences entre les versions de « Kvm Cluster & Lvm & Drdb »

Version du 12 juin 2013 à 10:41

Lien annexe

Présentation

Installation

/etc/hosts

Kvm

Cluster

Drbd

Configuration

drbd.conf

Initialisation et creation des drbd

Intégration des nodes

cluster.conf

/usr/sbin/fence_fake

Clés ssh

Lancement du cluster

Mise en place des PV LVM en cluster

Ricci

Hack qemu-kvm

Services au démarrage

Menu de navigation

Rechercher

Différences entre les versions de « Kvm Cluster & Lvm & Drdb »