Différences entre les versions de « Kvm Cluster & Lvm & Drdb »
| (6 versions intermédiaires par 2 utilisateurs non affichées) | |||
| Ligne 91 : | Ligne 91 : | ||
* lvm.conf | * lvm.conf | ||
<pre> | <pre> | ||
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 | 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. | ||
du San /dev/mapper/VMp1. Ce qui n'est pas bon car on va avoir un PV dans un PV. | 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 | 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 | 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 | ||
| Ligne 113 : | Ligne 113 : | ||
512byte sectors |_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_| | 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. | 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 | Note: Not to scale | ||
| Ligne 123 : | Ligne 124 : | ||
512byte sectors |_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_| | 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 | 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. | |||
</pre> | </pre> | ||
| Ligne 154 : | Ligne 156 : | ||
==== drbd.conf ==== | ==== drbd.conf ==== | ||
Meme configuration sur les 2 serveurs | 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 !!! | |||
<pre> | <pre> | ||
| Ligne 312 : | Ligne 316 : | ||
<pre> | <pre> | ||
# drbdadm -- --overwrite-data-of-peer primary drbd0 | # 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) | # cat /proc/drbd (pour info, la synchronisation est entrain de se lancer) | ||
| Ligne 424 : | Ligne 433 : | ||
* Sur un node et pour chaque device (création des PV LVM) | * Sur un node et pour chaque device (création des PV LVM) | ||
#pvcreate /dev/drbd0 | #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 | * Sur un des 2 nodes | ||
| Ligne 441 : | Ligne 453 : | ||
# service ricci start | # service ricci start | ||
Mettez enfin un passwd au user ricci automatiquement créé (identique sur les 2 serveurs) | Mettez enfin un passwd au user ricci automatiquement créé (identique sur les 2 serveurs) | ||
</pre> | |||
===== 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 : | |||
<pre> | |||
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 | |||
</pre> | </pre> | ||
Version actuelle datée du 11 juin 2020 à 09:08
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[modifier]
* 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[modifier]
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.
- 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[modifier]
/etc/hosts[modifier]
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[modifier]
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[modifier]
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[modifier]
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[modifier]
Multipath & disque SAN[modifier]
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[modifier]
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[modifier]
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[modifier]
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[modifier]
# Sur les 2 noeuds :
1/ modif lvm.conf :
locking_type = 3
fallback_to_clustered_locking = 0
cluster.conf[modifier]
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[modifier]
#vim /usr/sbin/fence_fake #!/bin/sh echo "success: fence_fake $1" exit 0 chmod +x /usr/sbin/fence_fake
Clés ssh[modifier]
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[modifier]
service cman start service clvmd start service rgmanager start
Mise en place des PV LVM en cluster[modifier]
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
!! 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
- 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[modifier]
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[modifier]
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[modifier]
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[modifier]
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)
