Xen Live migration avec DRBD
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)
Sommaire
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 (ro:Secondary/Primary) 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, allow-two-primaries; dans la sous-section net {} :
#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 xend-relocation-address permet de n'écouter que sur une interface spécifique (le laisser vide revient à écouter sur 0.0.0.0.
Le paramètre xend-relocation-hosts-allow 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' ];
drbd:testdrbd indique à xen d'utiliser le script /etc/xen/scripts/block-drbd 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 hotplugpth.sh 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
(migrate 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
