Sn4kY : Page créée avec « Nous considérons ici que Xen et DRBD sont installés et fonctionnels, et qu'une VM est installée sur un block-device DRBD. Le but ici est de pouvoir effectuer des bascu... »

2018-04-12T13:57:57Z

Page créée avec « Nous considérons ici que Xen et DRBD sont installés et fonctionnels, et qu'une VM est installée sur un block-device DRBD. Le but ici est de pouvoir effectuer des bascu... »

Nouvelle page

Nous considérons ici que Xen et DRBD sont installés et fonctionnels, et qu'une VM est installée sur un block-device DRBD.

Le but ici est de pouvoir effectuer des bascules de manière semi-automatique (par déclenchement manuel)

==Modifications DRBD==
Xen a besoin de savoir si le block-device peut être écrit sur le node qui va recevoir la VM avant de procéder à la migration. Ce n'est pas le cas par défaut (<code>ro:Secondary/Primary</code>) on va donc indiquer à DRBD que la ressource peut être écrite simultanément via les deux nodes (ne vous en faites pas, Xen n'écrit JAMAIS des deux côtés simultanément)

Dans votre fichier de définition de la ressource, il faut ajouter, <code>allow-two-primaries;</code> dans la sous-section <code>net {}</code> :
#DRBD 8.3
resource testdrbd {
net {
allow-two-primaries;
}
}

#DRBD 8.4
resource testdrbd {
net {
allow-two-primaries yes;
}
}
(a faire sur les deux nodes)

Puis faire un reload de drbd
[root@node1 ~]# /etc/init.d/drbd reload
[root@node2 ~]# /etc/init.d/drbd reload

==Modifications Xend==
Pour effectuer une migration en mode Live, il faut activer la fonctionnalité, en définissant les paramètres d'interface, de port et de hosts autorisés à faire de la migration. Ces configurations sont a effectuer sur les deux nodes.

[root@nodeX ~]# vim /etc/xen/xend-config.sxp
(xend-relocation-server yes)
(xend-relocation-port 8002)
(xend-relocation-address '192.168.0.X')
(xend-relocation-hosts-allow '192.168.0.X')

Le paramètre <code>xend-relocation-address</code> permet de n'écouter que sur une interface spécifique (le laisser vide revient à écouter sur <code>0.0.0.0</code>.<br />
Le paramètre <code>xend-relocation-hosts-allow</code> permet de n'autoriser que certains nodes. L'option comprends les expressions régulières, et les FQDN. -RTFM-

Il est possible (voir fortement conseillé) de renforcer la sécurité via un coup d'iptables

Il faut restarter xend sur les deux nodes
[root@nodeX ~]# /etc/init.d/xend restart

On peut vérifier que les paramètres réseau ont bien été pris en compte :
[root@node1 ~]# netstat -lnp | grep 8002
tcp 0 0 192.168.0.1:8002 0.0.0.0:* LISTEN 3406/python2.5

[root@node2 ~]# netstat -lnp | grep 8002
tcp 0 0 192.168.0.2:8002 0.0.0.0:* LISTEN 3412/python2.5

==Modifications du domU==
La configuration de la VM reste quasi-identique. La seule modification est de spécifier le nom de la ressource drbd en utilisant le script associé (fourni dans le package drbd).

[root@nodeX ~]# vim /etc/xen/vm-testdrbd.cfg
name = 'vm-testdrbd';
disk = [ 'drbd:testdrbd,xvda1,w' ];

<code>drbd:testdrbd</code> indique à xen d'utiliser le script <code>/etc/xen/scripts/block-drbd</code> avec la ressource <script>testdrbd</script> (c'est le nom qu'on lui a donné dans le fichier de config de DRBD).

Le fichier de configuration doit, bien entendu, exister sur les deux nodes !

==hotplugpath.sh==
Il semblerait qu'un oubli ait eu lieu avec Xen 4.0, le script <code>hotplugpth.sh</code> nécessaire au script drbd.

Le symptôme :
[root@node1 ~]# xm create /etc/xen/vm-testdrbd.cfg
Using config file "/etc/xen/vm-testdrbd.cfg".
Error: Device 51714 (vbd) could not be connected. Hotplug scripts not working.

La solution :
[root@node1 ~]# cat /etc/xen/scripts/hotplugpath.sh
#!/bin/bash
#
# CAUTION: this script is manually created
# see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591456
# it should go away with xen-common 4.1.0~rc6-1
#
SBINDIR="/usr/sbin"
BINDIR="/usr/bin"
#LIBEXEC="/usr/lib/xen/bin"
LIBEXEC="/usr/lib/xen-4.0/bin"
#LIBDIR="/usr/lib64"
LIBDIR="/usr/lib"
SHAREDIR="/usr/share"
#PRIVATE_BINDIR="/usr/lib64/xen/bin"
PRIVATE_BINDIR="/usr/lib/xen-4.0/bin"
#XENFIRMWAREDIR="/usr/lib/xen/boot"
XENFIRMWAREDIR="/usr/lib/xen-4.0/boot"
XEN_CONFIG_DIR="/etc/xen"
XEN_SCRIPT_DIR="/etc/xen/scripts"

==Démarrage de la machine virtuelle==

Il est grand temps de démarrer la VM. Attention, la VM '''ne doit être démarrée que sur l'un des nodes'''. Deux VM sur le même block device endommagera sévèrement le file system.

[root@node1 ~]# xm create /etc/xen/vm-testdrbd.cfg
Using config file "/etc/xen/vm-testdrbd.cfg".
Started domain vm-testdrbd (id=1)

On vérifie le succès de l'opération
[root@node1 ~]# xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 249 4 r----- 4516.4
vm-testdrbd 1 512 1 -b---- 2.7

A ce stade, le status de DRDB est le suivant :
[root@node1 ~]# cat /proc/drbd
0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
ns:260 nr:78064 dw:78324 dr:472 al:13 bm:8 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

[root@node2 ~]# cat /proc/drbd
0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
ns:78064 nr:260 dw:78324 dr:190807 al:85 bm:82 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

==Migration de la VM==
Une fois que la VM a bien été bootée sur node1, nous pouvons procéder à sa migration vers le second node :

[root@node1 ~]# xm migrate --live vm-testdrbd node2
(<code>migrate</code> accepte une adresse IP, tout comme un FQDN)

Il est normal que cette commande n'ait pas d'output, et ne rende pas la main tout de suite : la migration est en cours.

Pendant la migration, on peut vérifier le status de la VM sur node2 :
[root@node2 ~]# xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 249 4 r----- 4434.1
vm-testdrbd 4 512 0 --p--- 0.0

Il est également intéressant de noter l'état de DRBD pendant la migration :
[root@node2 ~]# cat /proc/drbd
0: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r----
ns:78064 nr:260 dw:78324 dr:191007 al:85 bm:82 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

Une fois que node1 a rendu la main, il est simple de vérifier que la VM a bien migré d'un node à l'autre :
[root@node1 ~]# xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 249 4 r----- 4516.4

[root@node2 ~]# xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 249 4 r----- 4445.8
testdrbd 4 512 1 -b---- 0.1

A ce stade, le status de DRDB est le suivant :
[root@node1 ~]# cat /proc/drbd
0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
ns:78064 nr:260 dw:78324 dr:190807 al:85 bm:82 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

[root@node2 ~]# cat /proc/drbd
0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
ns:260 nr:78064 dw:78324 dr:472 al:13 bm:8 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

La VM a bien migré, et le script Xen DRBD a effectué toutes les étapes nécessaires à la migration de la VM :
* set both drbd nodes as primary (pour le droit en écriture à la destination !)
* migrating xen virtual machine
* set drbd node original source as secondary

==sources==

[http://www.drbd.org/users-guide/ch-xen.html]
[http://backdrift.org/live-migration-and-synchronous-replicated-storage-with-xen-drbd-and-lvm]
[http://lists.linbit.com/pipermail/drbd-user/2011-March/015879.html]

Xen Live migration avec DRBD - Historique des versions

Sn4kY : Page créée avec « Nous considérons ici que Xen et DRBD sont installés et fonctionnels, et qu'une VM est installée sur un block-device DRBD. Le but ici est de pouvoir effectuer des bascu... »

Sn4kY : Page créée avec « Nous considérons ici que Xen et DRBD sont installés et fonctionnels, et qu'une VM est installée sur un block-device DRBD. Le but ici est de pouvoir effectuer des bascu... »