Résumé

GUSTAV propose un cadre de gestion unifiée des systèmes de fichiers d'un parc de machines virtuelles. Le contexte de cette proposition est restreint aux machines virtuelles basées sur un système ouvert et libre de type Unix supportant le système de fichiers unifiés UnionFS [1] ou Aufs [2]. L'objectif est de faciliter les mises à jour des systèmes de base (application des « patches », montée de version de « kernel » ou de distribution) applicables à tout un ensemble de machines virtuelles clonées sur un modèle commun sans avoir à appliquer ces mises à jour individuellement sur chacune des machines virtuelles. Un ensemble d'appareils virtuels (virtual appliance) peuvent maintenant descendre d'un système ancêtre commun dont les caractéristiques système (« son patrimoine génétique ») pourront être modifiées et propagées à l'ensemble de ses fils (clones). GUSTAV introduit, ainsi, une forme d'héritage système. L'étude et la mise en œuvre de GUSTAV a été opérée avec l'environnement de virtualisation KVM/QEMU (Kernel based Virtual Machine). Elle peut, certainement, être transposée aux autres environnements de virtualisation phare du marché.

Mots clefs

virtualisation, KVM, clonage de machines virtuelles, systèmes de fichiers mutualisés, fichiers COW, UnionFS, gestion unifiée, lignée de clones, mise à jour de parc de machines virtuelles, héritage système.

1Introduction

La virtualisation est une technologie de plus en plus utilisée ces dernières années. Intégrée au sein des processeurs modernes (Intel-VT, AMD-V), elle tend à se banaliser au point que certains n'hésitent pas à parler de « rupture technologique ». Des acteurs dominants ont émergé avec des solutions performantes. Le monde du logiciel libre n'est pas en reste et propose aujourd'hui des solutions tout aussi performantes. Cet engouement pour la virtualisation a bouleversé la gestion des parcs de machines dans les centres de calcul. Amorcée tout d'abord au niveau des serveurs, la virtualisation s'étend aujourd'hui aux postes de travail avec les architectures VDI (Virtual Desktop Infrastructure), sans parler du très médiatique « cloud computing ».

L'hyperviseur, sous couche système d'abstraction matérielle, apporte une flexibilité nouvelle autorisant le clonage aisé des systèmes, la migration à chaud des machines virtuelles (live migration) et bien d'autres facilités appréciées des administrateurs système. Parée de nombreuses vertus, la virtualisation n'en introduit pas moins un niveau de complexité supplémentaire, qui si on n'y prend garde, pourrait alourdir l'administration d'un parc de machines virtuelles devenu pléthorique. La multiplication des clones risque de peser lourd lorsqu'il s'agit d'appliquer rapidement un patch de sécurité ou lorsque que l'on souhaite monter de version un noyau ou une distribution sur un parc de machines virtuelles.

Les outils facilitant la gestion de parcs importants de machines virtuelles restent, pour le moment, l'apanage des acteurs dominants du marché. Ces derniers conservent une avance indéniable sur la gestion et l'administration des écosystèmes virtualisés. Le libre avance rapidement avec des projets, tels que libvirt [3] ou ovirt [4]... GUSTAV se veut être une contribution à la gestion des systèmes de fichiers de base (rootfs : root file system) des environnements libres.

Les distributions dites « live » (liveCD, liveUSB), ont permis de rendre transportables les systèmes Unix pré-packagés sans avoir à se soucier de leur installation. La distribution GNU/Linux ou *BSD est pré-assemblée sur un support portable (CD, DVD ou clé USB). Les fonctionnalités plug and play du système associées à un ensemble de scripts d'auto-configuration permettent de lancer ces systèmes sur un panel hétérogène de machines d'accueil. Les supports de type lecture seule (CD ou DVD) rendent ces distributions « logiquement inaltérables » dans la mesure, où les modifications ou altérations d'environnement restent confinées dans l'espace mémoire de la machine d'accueil et sont perdues lorsque cette dernière est réinitialisée. Afin de rendre persistant la personnalisation de l'environnement système, certains liveCD permettent d'associer un support ré-inscriptible de type clé USB sur lequel seront stockés les éléments personnels de l'utilisateur. Les systèmes de fichiers du liveCD et de la clé auxiliaire personnelle sont agrégés au démarrage du système au moyen d'outils de fusion tels UnionFS [1] ou Aufs [2]. GUSTAV est une transposition de ces mécanismes de personnalisation des liveCD aux systèmes de fichiers des machines virtuelles.

En exportant les éléments de différenciation des clones virtuels dans un espace de débordement séparé (UnionFS), il devient possible de mettre à jour le système de base commun d'un ensemble de machines virtuelles, sans à avoir mettre à jour les clones individuellement.

2Objectifs

La réduction de la dépendance des configurations système au matériel apporte une flexibilité d'administration indéniable. Ce mouvement initié grâce à l'intégration de fonctionnalités plug and play dans les systèmes modernes et à la configuration automatique du matériel, développée lors de la mise au point des distributions dites live (liveCD, liveDVD, liveUSB), améliore la portabilité des systèmes. La virtualisation apporte un niveau d'abstraction supplémentaire réduisant, encore, les liens forts qui unissent les systèmes au matériel de la machine d'accueil. La migration à chaud (live migration) des machines virtuelles, quant à elle, améliore la disponibilité globale des systèmes en réduisant la sensibilité aux aléas matériels.

En se positionnant au niveau des systèmes de fichiers des machines virtuelles, GUSTAV envisage de s'abstraire des liens qui unissent l'espace de débordement (COW Copy On Write) d'un système de fichiers cloné avec son système de référence, partagé avec les autres clones. La mise à jour ou la modification du système de fichiers commun est rendue possible sans avoir à mettre à jour les clones individuellement. On peut alors envisager la mise à jour d'une « lignée » de clones en une seule opération de mise à jour du système de référence. La modification des caractéristiques du système père (« son patrimoine génétique »), est alors propagée à l'ensemble de ses fils par un simple redémarrage des système clonés.

3Principes

3.1Root-fs et fichiers COW

Chaque machine virtuelle dispose de son système de fichiers, couramment dénommé système de fichiers racine ou rootfs en anglais (par facilité, nous utilisons cette dénomination anglo-saxonne dans la suite de cet article). Le rootfs contient l'ensemble des fichiers du système de base propre à la machine virtuelle, cela peut être un système windows ou un système de type Unix complet. Avec la plupart des environnements de virtualisation, vu de la machine réelle, c'est à dire l'hôte (host), le rootfs de la machine virtuelle peut être localisé sur un disque ou une partition de l'hôte, sur un volume logique type LVM ou déporté sur un SAN. Il peut également se trouver sous la forme d'un simple fichier de l'hôte. Comme il contient un système de fichiers complet, la taille d'un fichier rootfs d'une machine virtuelle peut être importante. Le système de virtualisation User-Mode Linux [5] a introduit la possibilité à plusieurs machines virtuelles de se partager un rootfs commun en lecture seule. Les opérations d'écriture de chacune des machines virtuelles sont déportées dans des fichiers séparés propres à chaque machine virtuelle.

Figure 1 - Partage d'un système de fichiers commun

Les machines virtuelles disposent donc d'un espace de débordement (overlay) dans lequel sont stockées les surcharges apportés au système de fichiers de référence. Ces fichiers de débordement ne contenant que les différences avec le rootfs, sont dénommés fichiers COW (abréviation de Copy On Write). Ils sont liés au fichier rootfs commun et sont de taille modeste. L'utilisation des fichiers COW permet donc de personnaliser un ensemble de machines virtuelles, partageant par ailleurs une base système commune. Le clonage d'un système de base de référence devient une opération très facile. Les machines virtuelles VM1 et VM2 de la Figure 1 disposent ainsi de leur propre système de fichiers ne contenant que les différences avec le système de fichiers de référence qu'est le rootfs.

3.2« Vachement bien » les fichiers COW

On notera que ce système de débordement a, sans nul doute, un coût en terme d'entrées/sorties du fait de l'indirection qui alourdit les accès. Cependant il n'est pas dénué d'avantages et introduit une certaine souplesse de gestion. Le premier avantage de ce système COW est l'optimisation de taille. L'unique et volumineux rootfs est partagé pour un ensemble de machines virtuelles clonées. La différentiation de ces VM est déportée dans de petits fichiers. Les environnements de virtualisation libres XEN et KVM/QEMU peuvent exploiter les fichiers COW. QEMU a même amélioré le format en créant les formats QCOW et QCOW2 qui peuvent être chiffrés et compressés.

Des effets indirects bénéfiques peuvent être tirés de cette architecture. Le premier effet est le « durcissement » des machines virtuelles. A l'instar des liveCD, le système de base contenu dans le rootfs est en lecture seule. La compromission ou l'altération d'une machine reste confinée dans son espace de débordement COW. Elle peut être annulée en créant un nouveau fichier au redémarrage de la machine virtuelle. En systématisant la création du fichier COW à chaque redémarrage de la VM, on a l'assurance qu'elle démarre toujours dans le même état initial. En poussant cette idée, il est même possible de localiser les fichiers COW en espace disque volatil, à savoir sur un RAM disk de la machine hôte ou sur l'espace de type « tmpfs » d'une machine GNU/Linux. Ainsi à chaque redémarrage de l'hôte les clones sont réinitialisés dans leur état originel. De plus ces espaces disques volatils résidant en mémoire offrent de bonnes performances d'accès.

Figure 2 - « Durcissement » des clones

Le second effet administrativement intéressant est qu'il devient possible des gérer des points de retour stables lors des opérations de mise à jour système, en gérant des versions ou des générations successives de rootfs. On diminue ainsi les risques lors de l'application des patches, de montées de version de noyau ou de système. Il est en effet possible de rétro-porter les surcharges contenues dans le fichier COW dans le rootfs de référence. Lorsqu'une opération de mise à jour est envisagée, il suffit de copier la dernière version stable du rootfs, de démarrer un machine virtuelle avec un fichier COW vierge pointant sur ce nouveau rootfs. On peut alors procéder à la mise à jour et évaluer sa stabilité. Si l'opération est un succès, il suffit de « rétro-porter » le contenu du fichier COW dans le rootfs pour disposer d'un nouvelle version de référence, qui pourra servir de matrice pour générer un clone dans une version actualisée. En cas de problème ou d'instabilité, on pourra procéder simplement à un retour à l'archive de la version stable précédente.

3.3Personnalisation durable d'une lignée de clones

Comme nous l'avons vu précédemment, la volatilité des fichiers de débordement permet de se prémunir de l'altération d'une machine. Si cette méthode est intéressante pour gérer une machine virtuelle isolée, elle s'avère problématique lorsque que l'on souhaite gérer un parc de clones issus d'un système de référence commun. En effet la différentiation de chacun des clones est portée par le fichier COW. Ainsi prenons l'exemple d'un environnement serveur web/ftp (Linux, lighttpd [7], vsftp [8]) de référence, qui va nous servir de matrice pour générer les clones des serveurs web du système d'information. La configuration particulière de chacun des serveurs web cloné sur cette référence sera localisée dans le fichier COW propre à chaque serveur virtuel. Les fichiers COW sont liés au fichier de référence par un ensemble de pointeurs internes. Ceux ci référencent les blocs de données modifiés par rapport au rootfs de référence. Ce lien fort entre le fichier COW et le rootfs de référence interdit toute modification de ce dernier. En effet en cas d'altération du système de fichiers de référence, l'ensemble des fichiers COW qui lui sont liés deviennent incohérents et inutilisables. La mise à jour du kernel ou de la distribution, l'application de patches de sécurité, doit alors être effectuée sur chacun des clones. A partir de ce moment la lignée de clones va commencer à diverger.

Pour s'affranchir de ce couplage fort, il faut déporter la spécialisation de chacun des clones dans un espace externe au fichier COW. Une première approche mise en œuvre par VNUML [6], consiste à procéder à une copie des fichiers de personnalisation de la VM dans l'espace de débordement COW, lors du démarrage du clone. Elle nécessite un ensemble de scripts de démarrage qui réaliseront la personnalisation du clone. Cette technique requiert un accès, depuis la VM, à l'espace externe où se trouvent les fichiers de personnalisation des clones. Suivant le système de virtualisation, diverses techniques de communication (pipe, socket, montage NFS ou CIFS, scp, session ssh...) peuvent être envisagées. Bien qu'il puisse être sécurisé, cet accès depuis la VM à l'espace de fichiers du système hôte n'est pas toujours souhaitable. GUSTAV propose une approche différente, en s'appuyant sur un double système de débordement.

Les fichiers COW ne sont pas les seuls systèmes de gestion d'un espace de débordement relativement à un système de fichiers de référence. Le système de fichiers UnionFS [1] dispose également de cette facilité. UnionFS est un système de fichiers « empilable » qui permet l'agrégation d'un ensemble de répertoires, appelés branches, en un système cohérent de fichiers. Il unifie le contenu de différents répertoires éclatés sur des localisations ou des supports diverses. Il peut mixer ensemble des branches communes accessibles en lecture seule avec des branches accessibles en lecture/écriture, ce qui lui procure cette fonctionnalité dite Copy On Write. Il est d'ailleurs souvent utilisé comme mécanisme COW dans les distributions de type liveCD.

Le principe de GUSTAV consiste à mixer les deux mécanismes COW et UnionFS. Les machines virtuelles disposent de deux espaces disque virtuels que nous dénommerons, selon la terminologie GNU/Linux, hda et hdb. Le disque virtuel, hda, peut être soit directement le rootfs de référence (master) en lecture seule ou un clone COW du rootfs accessible en lecture-écriture. Le disque virtuel hdb est un fichier contenant un système de fichiers dans lequel sont stockés les répertoires et fichiers propres à la différenciation de la machine virtuelle (delta). Typiquement il s'agit essentiellement d'un sous ensemble du répertoire /etc, ainsi éventuellement des répertoires /opt et /var. Pour ce disque virtuel hdb, nous utilisons un fichier système de fichiers en mode « RAW », ce qui permet le montage en mode bouclé (loop) (mount -o loop /path/to/vm-x-hdb.img  /path/to/mountpoint/). Contrairement au mode COW, le mode RAW crée un fichier dont la taille correspond strictement à la taille disque virtuel qu'il contient. Pour cette raison, le mode RAW n'est pas adapté pour les disques virtuels de grande taille, typiquement le rootfs. Le disque virtuel hdb, ne contenant que la personnalisation de la machine virtuelle, est en général de taille raisonnable. Le fait de pouvoir le monter en mode loop sur l'hôte, facilite la mise au point de la personnalisation de la machine virtuelle, sans que celle ci soit activée. Cela aura son importance dès lors que l'on voudra automatiser le clonage pour « provisionner » une nouvelle machine virtuelle. Les deux disques virtuels, hda et hdb, sont fusionnés au sein de la machine virtuelle par le mécanisme UnionFS. La différenciation de la machine virtuelle étant portée par le disque hdb, il n'a plus de liens de dépendance avec le fichier rootfs de référence. Le simple redémarrage des machines virtuelles suffit à prendre en compte une mise à jour ou l'application de patches sur le rootfs de référence.

Si l'on souhaite se prémunir de l'altération du disque virtuel hdb, on peut également le « durcir » en le clonant en mode COW en espace disque volatil (ramdisk ou tmpfs), avant chaque démarrage de la machine virtuelle. Il faut, alors, veiller à ce que le système de journalisation (généralement localisé dans le répertoire /var/log) soit déporté sur un espace accessible en lecture/écriture soit sur un troisième disque (hdc), soit sur le réseau (typiquement vers un serveur syslog), afin de conserver les traces de fonctionnement de la machine virtuelle et permettre son audit a posteriori.

Figure 3 - éco-système d'une lignée de clones

4Mise en place et administration

4.1Création du rootfs maître ( disque « master »)

Le rootfs de référence nécessite quelques aménagements pour mettre en oeuvre cette gestion unifiée des espaces de fichiers. Cela se traduit par l'ajout de deux entrées dans la table de montage (fstab) et l'élimination d'un fichier de persistance des références des interfaces ethernet.

Le rootfs est initié de manière classique en créant un disque virtuel de taille convenable pour l'installation de la distribution et des paquetages souhaités. Si on désire le créer en mode RAW, la commande dd peut être utilisée. Si on souhaite optimiser l'espace disque on peut le créer nativement en mode QCOW2 à l'aide de la commande qemu-img

qemu-img create -f qCOW2 websrv-master-hda.img.qcow2.origAAAAMMJJ 10G

Ainsi les machines virtuelles disposeront chacune d'un espace disque pouvant s'étendre jusqu'à 10 Gigaoctets. Toutefois le fichier QCOW2 commun aux machines virtuelles n'occupera, sur le disque de l'hôte que quelques centaines de méga-octets ou quelques giga-octets, car le format QCOW est optimisé pour n'occuper que l'espace disque réellement consommé.

Installer la distribution de votre choix sur ce disque virtuel, en démarrant la machine virtuelle sur le fichier iso d'installation de votre distribution, en indiquant que le disque hda est votre fichier websrv-master-hda.img.origAAAAMMJJ.

kvm -cdrom /path/to/ma-distrib/distrib-x.iso \
               -hda /path/to/websrv-master-hda.img.qcow2.origAAAAMMJJ \
               -m 512 -boot d …

Le paquetage de l'outil d'unification (UnionFS ou Aufs) doit être installé dans la distribution. La table de montage du système (fichiers /etc/fstab) doit être adaptée de la manière suivante.

1) # /etc/fstab: static file system information.
2) #
3) #<file system> <mount point> <type> <options> <dump> <pass>
4) proc       /proc         proc    defaults        0        0
5) /dev/hda1  /             ext3    defaults,errors=remount-ro 0 1
6) /dev/hdc   /media/cdrom0 udf,iso9660 user,noauto 0        0
7) /dev/hdb   /opt          ext3    defaults        0        0
8) unionfs    /etc          unionfs dirs=/dev/shm=rw:/opt/etc=ro:/etc=ro 0 0

Ainsi à l'initialisation de la machine virtuelle, le disque hdb, contenant l'arborescence de personnalisation de la machine virtuelle, sera monté sur le répertoire /opt (cf. ligne 7). Le répertoire de configuration /etc de la machine virtuelle (ligne 8) est l'union de l'espace volatil /dev/shm accessible en lecture/écriture, du répertoire /opt/etc en lecture seule et du répertoire natif /etc en lecture seule également. L'ordre de l'union a son importance, car il donne la priorité d'un fichier lorsque celui ci est présent dans les diverses branches agrégées. Dans notre cas une altération locale d'un fichier de configuration sera résidente dans l'espace volatil /dev/shm de la machine virtuelle et aura priorité sur la version résidente sur /opt/etc (hdb) qui aura elle même priorité sur la version initiale résidente nativement sur le disque master de la machine virtuelle (hda).

Avant de stopper la machine virtuelle, il est primordial d'effacer le fichier /etc/udev/rules.d.zXX_persistent-net-rules. (XX peut varier d'une distribution à l'autre). Ce fichier mémorise l'affectation des interfaces réseaux (/dev/ethn) en fonction des adresses MAC. En effet lors du démarrage de la machine virtuelle, les scripts de démarrage gérant le plug and play et le peuplement du répertoire /dev (mécanisme udev du noyau 2.6.x) sont activés très tôt dans la séquence de boot. L'adresse MAC 52:54:00:12:34:56 est l'adresse par défaut d'une machine virtuelle KVM/QEMU. Elle a été affectée à l'interface eth0 lors de l'installation de la distribution sur le disque master. Cette correspondance adresse MAC ↔ device, est mémorisée dans le fichier /etc/udev/rules.d.zXX_persistent-net-rules. S'il n'est pas supprimé du master, les interfaces des cartes Ethernet des machines virtuelles, auxquelles on aura affecté une adresse MAC autre que 52:54:00:12:34:56, seront associées aux devices eth1 et suivants. Ce décalage des références des interfaces ethernet peut conduire à un dysfonctionnement réseau de la machine virtuelle qui n'est pas facilement détectable, car le contenu du fichier rules.d.zXX_persistent-net-rules du master n'est plus visible une fois que le répertoire /etc aura été unifié. Il est donc primordial que le fichier soit inexistant ou vide, sur le master, pour que les cartes Ethernet de la machine virtuelle soient affectées en séquence à partir du device eth0 quelque soit leur adresse MAC.

4.2Personnalisation des clones (disque « delta »)

L'ensemble de la personnalisation, c'est à dire la surcharge par rapport au disque master, d'un clone sera portée sur le second disque de la machine virtuelle (hdb). Dans la suite de l'article, nous dénommerons ce disque sous le vocable delta pour le distinguer du disque master. Nous allons décrire dans ce paragraphe quel doit être le patron (template) de ce disque virtuel delta. Celui ci sera créé sous la forme d'un simple fichier disque en mode RAW, ce qui nous permettra d'y accéder par montage en boucle (mount -o loop) sans avoir à démarrer la machine virtuelle. Il faudra donc ajuster la taille de ce fichier en fonction de l'espace nécessaire aux éléments de personnalisation. La séquence de commandes suivantes crée un tel disque virtuel d'une taille de 50 méga-octets avec un système de fichiers de type ext3 que l'on monte ensuite en boucle sur le répertoire /mnt/loop.

dd if=/dev/zero of=clone-a-delta.img seek=50 count=1 bs=1M
mke2fs -j -F clone-a-delta.img

mount -o loop clone-a-delta.img /mnt/loop

Il suffit alors de créer l'arborescence contenant les fichiers de surcharge spécifiques à l'instance clone-a directement sur /mnt/loop et notamment :

• les fichiers propres à la configuration du clone dans le répertoire /mnt/loop/etc,

• les scripts de démarrage localisés dans le répertoire /mnt/loop/etc/init.d , (cf le script mountall-deltas décrit ci dessous),

• ainsi que les liens logiques vers les scripts de démarrage des différents services activés sur le clone virtuel (/mnt/loop/etc/rcx.d dans le cas d'une distribution Debian ou /mnt/loop/etc/runlevels dans le cas d'une distribution Gentoo). Les paquetages concernant ces services ont été installés au préalable sur le disque master (hda), mais chaque clone doit assurer, lui même, le démarrage de son sous ensemble de services,

• Les fichiers de données propres aux services supportés par le clone, en général un sous ensemble de répertoires sous /var.

On notera qu'UnionFS permet d'effacer logiquement un fichier existant dans une autre branche de l'union, en préfixant ce nom de fichier par « .wh. ». Ainsi, si le fichier /etc/monfic.data existe dans un autre branche de l'union et qu'on souhaite qu'il soit considéré comme logiquement effacé dans une branche plus prioritaire, il suffit de créer une instance vide de nom .wh.monfic.data dans le répertoire /mnt/loop/etc/ à l'aide de la commande suivante :

touch /mnt/loop/etc/.wh.monfic.data

Compte tenu de la remarque sur l'affectation des devices Ethernet, il est prudent d'ajouter un fichier /mnt/loop/etc/udev/rules.d/.wh.zXX_persitent-net-rules.

touch /mnt/loop/etc/udev/rules.d/.wh.zXX_persitent-net-rules

On ajoute également les répertoires spécifiques au clone. Ainsi prenons l'exemple d'un serveur web (lighttpd) et d'un serveur ftp (vsftpd) les répertoires /mnt/loop/var/www et /mnt/loop/var/ftp avec leur contenu devront être présents sur le disque delta. On suppose que les paquetages correspondants à ces services (lighttpd [7] et vsftp [8] dans notre exemple) ont été installés sur le disque master lors de l'installation de la distribution sur ce dernier.

On crée une nouvelle table de montage (/mnt/loop/etc/fstab) pour ces nouveaux répertoires. Cette table aura priorité sur la table initiale du disque master. Ainsi qu'un nouveau script d'initialisation (/mnt/loop/etc/init.d/mountall-deltas) qui assurera la prise en compte de cette nouvelle table de montage lors de la séquence d'initialisation du clone virtuel.

1)  # /etc/fstab: static file system information.
2)  #
3)  # G U S T A V : (Gestion Unifiee des Systemes de fichiers
4)  # Transposee aux Appareillages Virtuels)
5)  # GUSTAV : (Unified File System for Free Guest Systems)
6)  # GUSTAV add unionfs overlays for VM discrimenation
7)  # All specific configuration dirs (/etc and sometime /usr/local, /var or /opt)
8)  # of a VM are located on /dev/hdb disk mounted on /opt
9)  #
10) # This is the specific fstab of a lighthttpd en ftp server VM
11) #
12) # <file system> <mount point> <type> <options> <dump> <pass>
13) proc      /proc         proc    defaults          0          0
14) /dev/hda1 /             ext3    defaults,errors=remount-ro 0     1
15) /dev/hdc  /media/cdrom0 udf,iso9660 user,noauto   0          0
16) /dev/hdb  /opt          ext3  defaults            0          0
17) unionfs   /etc          unionfs dirs=/dev/shm/etc=rw:/opt/etc=ro:/etc=ro 0 0
18) unionfs   /var/log      unionfs dirs=/opt/var/log=rw:/var/log=ro 0 0
19) unionfs   /var/www      unionfs dirs=/dev/shm/var/www=rw:/opt/var/www=ro 0 0
20) unionfs   /var/ftp      unionfs dirs=/dev/shm/var/ftp=rw:/opt/var/ftp=ro 0 0

Les nouvelles entrées ajoutées dans la table sont préfixées par le type de système de fichiers unionfs. Chaque nouveau répertoire unifié est accessible en lecture/écriture sur l'espace disque volatil de la machine virtuelle /dev/shm) et en lecture seule sur le répertoire /opt (soit le disque hdb de la VM). Le répertoire /var/log est, quant à lui, laissé en lecture/ecriture sur /opt/var/log (soit hdb) pour la conservation des traces du clone sur son disque delta.

Figure 4 - arborescence unifiée de fichiers dans la machine virtuelle

Le nouveau script d'initialisation /etc/init.d/mountall-deltas, (cf ci-dessous lignes 19 à 29) crée les points de montage s'ils ne sont pas déjà existants, ainsi que leurs équivalents accessibles en lecture/écriture sur l'espace volatil de la machine virtuelle (à savoir /dev/shm). Il force ensuite (ligne 31) un montage de tous les systèmes de fichiers de type UnionFS.

1)  !/bin/sh
2)  #
3)  # G U S T A V : (Gestion Unifiee des Systemes de fichiers
4)  # Transposee aux Appareilages Virtuels)
5)  # GUSTAV : (Unified File System for Free Guest Systems)
6)  # GUSTAV add unionfs overlays for VM discrimenation
7)  # All specific configuration dirs (/etc and sometime /usr/local or /opt)
8)  # of a VM are located on /dev/hdb disk mounted on /opt
9)  # GUSTAV simple init script to mount all unionfs
10) # deltas from delta fstab
11) #
12) #Delta dirs list : eg all unionfs lines in the delta fstab
13) DD=`grep \^unionfs /etc/fstab | awk '{ print $2 }'`
14) MNTCMD="mount -a -t unionfs"
15) case "$1" in
16)   start)
17)     echo "mounting all unionfs delta dirs from delta fstab"
18)     echo "\$DD : $DD"
19)     for dir in $DD; do
20)       # create mount point if it doesn't exist
21)       echo "\$dir : $dir"
22)       if ! [ -d "$dir" ]; then
23)         mkdir -p $dir >/dev/null 2>&1
24)       fi
25)       # create /dev/shm/$dir if no exist
26)       if ! [ -d "/dev/shm/$dir" ]; then
27)         mkdir -p /dev/shm/$dir >/dev/null 2>&1
28)       fi
29)     done
30)     # remount all unionfs filesystems
31)     $MNTCMD
32)     ;;
33)     stop)
34)       echo "unmounting all unionfs delta dirs from delta fstab..."
35)       u$MNTCMD
36)       ;;
37)     restart)
38)       $0 stop
39)       sleep 1
40)       $0 start
41)       ;;
42)     *)
43)       echo "Usage: $0 {start|stop|restart}"
44)       exit 1
45) esac
46) 
47) #
48) # Ende
49) #

On prendra soin d'ajouter un lien logique pointant vers ce script dans le niveau de démarrage (runlevel) de base de la machine virtuelle, afin que l'ensemble des espaces disques unifiés soient montés lors de l'initialisation du clone virtuel. Car il faut que cette nouvelle table de montage des systèmes de fichiers soit prise en compte suffisamment tôt dans la séquence d'initialisation de la machine virtuelle. Par exemple dans le cas d'une distribution Debian, le répertoire /mnt/loop/etc/rcS.d. Debian contiendra le lien logique S36mountall-deltas, alors que dans le cas d'une distribution Gentoo le répertoire /mnt/loop/etc/runlevels/boot contiendra un lien logique nommé zzmountall-deltas.

4.3Mise à jour d'une fratrie de clones

La mise à jour d'une fratrie de clones virtuels, pour la mise à jour du noyau ou la prise en compte de patches correctifs de la distribution, consiste à modifier le patrimoine génétique de leur ancêtre commun à savoir le fichier disque master. La procédure consiste à enchainer les étapes suivantes :

• 1) créer le nouveau fichier disque master en copiant la version courante ;

cp current-websrv-master-hda.img.qcow2 websrv-master-hda.img.qcow2.savAAAAMMJJ

• 2) démarrer une machine virtuelle dont le disque hda accessible en lecture/écriture pointe sur ce nouveau disque virtuel ;

kvm -hda /path/to/websrv-master-hda.img.qcow2.savAAAAMMJJ \
            -m 512 -boot c . . .

• 3) Procéder à la mise à jour de la distribution « apt-get update; apt-get upgrade » dans le cas d'une Debian, « emerge --sync; emerge -u world » dans le cas d'une Gentoo ; effacer le fichier /etc/udev/rules.d/zXX_persistent-net-rules, puis stopper la machine virtuelle ;

• 4) Stopper l'ensemble des clones de la fratrie dont le disque hda est le lien current-websrv-master-hda.img.qcow2 ;

• 5) effacer le lien logique current-websrv-master-hda.img.qcow2 et le recréer en pointant sur le nouveau fichier disque mis à jour ;

ln -s websrv-master-hda.img.qcow2.savAAAAMMJJ current-websrv-master-hda.img.qcow2

• 6) redémarrer les clones.

On notera que la durée d'indisponibilité des clones est réduite à la durée des étapes 4, 5 et 6.

5Limites

La preuve du concept est faite, « ça mache », mais cela n'a pas été testé à grande échelle. Quelques serveurs sont maintenant opérationnels, mais il ne s'agit pas de serveurs les plus critiques pour l'exploitation.

L'objectif premier de ce travail d'intégration est la flexibilité maximale, sans viser les performances pures. Le choix des systèmes de fichiers stockés dans des fichiers est de ce point de vue probablement discutable mais il offre une grande souplesse. Des optimisations sont probablement possibles. L'unification par unionfs de partitions localisées sur un SAN associée à la disponibilité des pilotes KVM parapvirtualisés (virtio)  [9] pour les entrées/sorties des périphériques blocs, offrent des perspectives intéressantes.

A ce jour Unionfs n'est toujours pas intégré dans la branche officielle du noyau Linux, certaines distributions ne le considèrent toujours pas suffisamment mature ou stable.

6Evolutions et perspectives

A partir du cadre générique d'un disque delta, il s'agira de développer les outils (scripts) qui permettront d'automatiser la génération de disques virtuels delta de personnalisation des clones.

Afin de pouvoir prendre en compte la génération de clones dans les outils de gestion de la virtualisation tels que virsh, virtmanager, ovirt, enomalism,...il faudrait mettre en conformité l'architecture d'une machine virtuelle GUSTAV avec les spécifications de la librairie libvirt [3]. Cette dernière est, en effet, le socle de base des principaux outils libres de gestion de la virtualisation.

GUSTAV va maintenant pouvoir être utilisé dans différents projets :

• La plate-forme VIMINAL (VIrtual Model for Ip Network Architecture Lab) [10] est un environnement autonome de travaux pratiques système et réseau. Disponible sous forme de LiveDVD, elle met à disposition des maquettes réseau sur lesquelles on peut interagir avec des droits étendus. Les maquettes de VIMINAL vont migrer, à terme de l'environnement VNUML vers l'environnement KVM/QEMU assisté de libvirt et de GUSTAV.

• Le renouvellement des machines des salles de TP, banalise la diffusion des processeurs disposant des extensions HVM (Hardware Virtual Machine : extension VMX chez Intel, SVM chez AMD). Les architectures type VDI (Virtual Desktop Infrastructure), apporteront sans nul doute de la souplesse dans le déploiement des postes de TP. Des configurations spécifiques de TP bâties sur les spécifications GUSTAV pourraient être déployées rapidement en salle.

7Bibliographie

1. Unionfs: A Stackable Unification File System, http://www.filesystems.org/project-unionfs.html

2. Advanced multi layered unification filesystem version 2, http://aufs.sourceforge.net/

3. Libvirt : A toolkit to interact with the virtualization capabilities of recent versions of Linux (and other Oses), http://libvirt.org/

4. oVirt is the next step in open virtual machine management, http://ovirt.org/

5. User Mode Linux, http://user-mode-linux.sourceforge.net/

6. Virtual Network User-Mode-Linux (VNUML), http://www.dit.upm.es/vnumlwiki/index.php/Main_Page

7. Lighttpd, http://www.lighttpd.net/

8. Vsftpd : Probably the most secure and fastest FTP server for UNIX-like systems, http://vsftpd.beasts.org/

9. Virtio – KVM, http://www.linux-kvm.org/page/Virtio

10. J. Landru, J.P. Vandeborre, VIMINAL : VIrtual Model for Ip Network Architecture Lab, JRES2005, http://2005.jres.org/paper/49.pdf    http://www.telecom-lille1.eu/people/landru/viminal/

Page 10/10 JRES Décembre 2009