Modification à chaud des ressources avec Xen

écrit le 25/06/2014 Par Gaël Le Mignot

Cet article explique comment modifier à chaud (sans redémarrage) les ressources (disque, CPU et RAM) allouées à des machines virtuelles Xen.

Introduction

Cet article explique comment modifier à chaud les ressources (CPU, RAM et disque) allouées à des machines virtuelles Xen.

Il a rédigé et testé sur des machines en Debian Wheezy avec des noyaux 3.2 et Xen 4.1 utilisant la pile d'outils xl. Un certain nombre de fonctionnalités ne sont pas disponibles sur des versions plus anciennes, les syntaxes peuvent changer sur d'autres distributions, versions ou piles d'outils.

Mémoire

Présentation détaillée

Commençons par le plus simple, la mémoire. La commande pour ajuster la mémoire à chaud est disponible dans la documentation Xen, elle est relativement simple :

xl mem-set <vm> <memsize>

Démarrons une machine virtuelle (que nous nommerons testwheezy) avec 1 Go de RAM, voici le fichier de configuration :

memory      = '1000'

Vérifions la mémoire disponible :

(kilobug@testwheezy) ~ $ free
             total       used       free     shared    buffers     cached
Mem:        998036     154200     843836          0       4920      45760

Et ajustons-là sur le DOM0 :

(kilobug@thelma) ~ $ sudo xl mem-set testwheezy 500

La mémoire a bien diminué sur la machine virtuelle :

(kilobug@testwheezy) ~ $ free
             total       used       free     shared    buffers     cached
Mem:        486036     192836     293200          0       5164      47936

Maintenant, nous pouvons remettre la mémoire d'origine :

(kilobug@thelma) ~ $ sudo xl mem-set testwheezy 1000
(kilobug@testwheezy) ~ $ free
             total       used       free     shared    buffers     cached
Mem:        998036     121348     876688          0       5280      50412

Bien, essayons maintenant d'augmenter la mémoire au-dessus du Go :

(kilobug@thelma) ~ $ sudo xl mem-set testwheezy 2000
libxl: error: libxl.c:2140:libxl_set_memory_target memory_dynamic_max must be less than or equal to memory_static_max

En effet, il existe en réalité deux paramètres gérant la mémoire sur une machine Xen : memory (que nous avons manipulé jusque là) et maxmem, qui lui fixe la mémoire maximale qui peut être allouée dynamiquement à la VM et ne peut pas être modifié à chaud. Si ce dernier paramètre est absent, sa valeur par défaut est celui de memory, et on ne peut donc pas augmenter la mémoire à chaud.

Ajoutons donc un maxmem dans notre configuration :

memory      = '1000'
maxmem      = '4000'

Maintenant nous pouvons redémarrer la machine virtuelle, vérifier qu'elle a bien 1 Go au démarrage :

(kilobug@testwheezy) ~ $ free
             total       used       free     shared    buffers     cached
Mem:        948932     130028     818904          0       5396      50780

Et que l'on peut désormais augmenter la RAM à chaud :

(kilobug@thelma) ~ $ sudo xl mem-set testwheezy 2000
(kilobug@testwheezy) ~ $ free
             total       used       free     shared    buffers     cached
Mem:       1972932     132896    1840036          0       5404      50820

Il reste tout de même une question : pourquoi avoir ce paramètre maxmem et ne pas mettre automatiquement un maxmem égal à la quantité de mémoire physique sur la machine ?

Un détail vous a peut-être mis sur la piste : comparez le free du départ, et celui que le paramètre maxmem. La mémoire totale disponible est passée de 998036 à 948932, quand nous sommes passés de 1000 (valeur par défaut) à 4000 pour le maxmem.

En effet, le noyau (et Xen) ont besoin d'allouer des structures de données internes (tables de pages, etc.) pour gérer la mémoire, et la taille de ces structures dépendent du maxmem. Ces structures de données font environ 1,6% de la taille du maxmem donc quand on a passé le maxmem de 1000 à 3000, elles ont grossies de 48 Mo.

En résumé

Il est possible de diminuer à chaud la mémoire sur une machine virtuelle Xen, et de l'augmenter à chaud jusqu'à la valeur du paramètre maxmem, grâce à la commande xl mem-set.

Il faut tout de même faire attention, l'allocation de structure de données internes coûte environ 1,6% de la valeur de maxmem. Nous recommandons de mettre un maxmem à entre 2x et 4x la taille initiale de la mémoire de la machine, mais la valeur exacte dépend bien sûr du type d'utilisation qui est faite.

CPU

La gestion du CPU ressemble beaucoup à celle de la mémoire. Il y a deux paramètres, maxvcpus (équivalent de maxmem) et vcpus (équivalent de memory). La commande pour changer le nombre de CPUs virtuels alloués est xl vcpu-set.

La seule subtilité supplémentaire est que lorsqu'on ajoute des CPUs, ils sont par défaut désactivés (au niveau du noyau de la machine virtuelle) et il faut donc les activer via une commande spéciale.

Considérons notre machine testwheezy configurée ainsi :

maxvcpus = '4'
vcpus = '2'

Elle a bien deux CPUs initialement :

(kilobug@testwheezy) ~ $ cat /proc/cpuinfo  | grep processor
processor      : 0
processor      : 1

Si nous ajoutons des CPUs supplémentaires :

(kilobug@thelma) ~ $ sudo xl vcpu-set testwheezy 4

Le nombre de CPUs actifs n'a pas changé :

(kilobug@testwheezy) ~ $ cat /proc/cpuinfo  | grep processor
processor      : 0
processor      : 1

Mais nous pouvons les activer à la main (en root) :

root@testwheezy:~# echo 1 > /sys/devices/system/cpu/cpu2/online
root@testwheezy:~# echo 1 > /sys/devices/system/cpu/cpu3/online

Et vérifier qu'ils ont bien été activés :

(kilobug@testwheezy) ~ $ cat /proc/cpuinfo  | grep processor
processor      : 0
processor      : 1
processor      : 2
processor      : 3

Espace disque

Pour l'espace disque, nous utilisons LVM sur le DOM0. Pour notre machine testwheezy nous avons :

testwheezy-disk  thelma -wi-ao--  20.00g
testwheezy-swap  thelma -wi-ao-- 128.00m

Qui sont exportés dans la configuration Xen ainsi :

disk        = [
                 'phy:/dev/thelma/testwheezy-disk,xvda2,w',
                 'phy:/dev/thelma/testwheezy-swap,xvda1,w',
             ]

Avec une telle configuration, l'augmentation d'espace disque est très simple, en deux étapes :

Augmenter la taille du volume LVM sur le DOM0 :

(kilobug@thelma) ~ $ sudo lvextend /dev/thelma/testwheezy-disk -L +5g
  Extending logical volume testwheezy-disk to 25.00 GiB
  Logical volume testwheezy-disk successfully resized

Redimensionner le système de fichiers sur la machine virtuelle :

(kilobug@testwheezy) ~ $ sudo resize2fs /dev/xvda2
resize2fs 1.42.5 (29-Jul-2012)
Filesystem at /dev/xvda2 is mounted on /; on-line resizing required
old_desc_blocks = 2, new_desc_blocks = 2
Performing an on-line resize of /dev/xvda2 to 6553600 (4k) blocks.
The filesystem on /dev/xvda2 is now 6553600 blocks long.
(kilobug@testwheezy) ~ $ df -h /
Filesystem      Size  Used Avail Use% Mounted on
rootfs           25G  1.4G   22G   6% /

Ajout de disque

Il est aussi possible d'ajouter à chaud un nouveau disque (nouveau volume LVM dans notre cas) à une machine virtuelle avec la commande block-attach (les paramètres suivent la même syntaxe que le fichier de configuration Xen) :

(kilobug@thelma) ~ $ sudo xl block-attach testwheezy phy:/dev/thelma/plip-disk xvda3 w

Et sur la machine on peut désormais l'utiliser :

(kilobug@testwheezy) ~ $ sudo mount /dev/xvda3 /mnt
(kilobug@testwheezy) ~ $ df -h /mnt
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda3       20G  173M   19G   1% /mnt

Et pour le retirer ensuite :

(kilobug@testwheezy) ~ $ sudo umount  /mnt
(kilobug@thelma) ~ $ sudo xl block-detach testwheezy xvda3

Conclusion

Nous avons vu comment redimensionner à chaud les ressources de machines virtuelles Xen, permettant de s'adapter de manière réactive aux besoins d'exploitation, comme par exemple :

un pic de charge prévu ou non prévu ;
un traitement lourd à effectuer ponctuellement sur une base de données ;
une augmentation régulière du volume de données.

Actions sur le document

Send this

RSS