Installation de XEN dans un environnement SAN

I-A-1. SCSI▲

I-A-2. Le NAS (Network Attached System)▲

I-A-3. Le SAN (Stockage Area Network)▲

Le SAN est un réseau dédié au stockage. Le type de média utilisé est la fibre optique.
On peut trouver sur un SAN différents éléments tels que des robots de sauvegarde, des baies de disques, des commutateurs (équivalents des commutateurs Ethernet, mais dédiés à la technologie SAN) sur lesquels les différents éléments du réseau vont venir se brancher.
Chaque élément d'un SAN est identifié par un WWN (World Wide Name).
Il s'agit d'une sorte de plaque d'immatriculation pour chaque périphérique un peu à la manière des MAC adresses pour les cartes réseau, sauf que le WWN est composé de 8 octets (6 octets pour les MAC adresses).

Les avantages du SAN

• La fibre optique permet de très bons débits et la bande passante est uniquement dédiée aux opérations de lecture/écriture sur les différents éléments du réseau.
• La flexibilité : on peut décider par une technique de zoning de faire voir ou de cacher différents éléments du réseau de stockage aux serveurs qui y sont reliés.
• La flexibilité (le retour) : les possibilités d'évolution du réseau de stockage sont énormes. Tant que vous avez des ports sur votre commutateur SAN vous pouvez ajouter de la capacité de stockage.
• Redondance : plusieurs cartes adaptatrices SAN permettront à un serveur d'avoir plusieurs chemins d'accès vers un ou plusieurs éléments du réseau de stockage. Un bon logiciel de multipathing et/ou de répartition de charge sauront gérer ça à merveille.
• Partage de données : si plusieurs serveurs peuvent avoir accès au même contenu (technique de zoning) alors il nous sera facile de pouvoir monter des solutions de cluster haute disponibilité.

Les désavantages d'un SAN

• Technologie chère à mettre en œuvre.
• Requiert une formation de base avant de se lancer dans le déploiement d'un SAN.

Un hyperviseur est un système léger et adapté pour faire tourner des noyaux de systèmes invités.
On peut dire aussi des hyperviseurs qu'ils sont des minis OS légers conçus pour faire tourner plusieurs autres systèmes d'exploitation en même temps sur une même plateforme matérielle.

Aujourd'hui la virtualisation est une tendance de plus en plus à la mode, voire en plein boom.

L'intérêt de faire tourner plusieurs systèmes d'exploitation sur la même machine

• Réduction des coûts : on évite de multiplier les machines physiques, on y gagne en place, en dépenses d'électricité et la puissance de calcul des dernières machines à la mode n'est plus sous-exploitée.
• Flexibilité : les derniers hyperviseurs ont des fonctionnalités intéressantes telles que l'ajout/retrait à chaud de ressources telles que la RAM, le stockage, le nombre de cœurs CPU, etc.
  Imaginez que vous avez trois machines virtuelles fonctionnant sur votre hyperviseur, et que vous savez qu'à une certaine période de la journée vous avez un pic d'activité sur la machine 1 alors que les deux autres machines ne sont pas beaucoup sollicitées.
  Vous pouvez alors choisir grâce à votre hyperviseur d'enlever de la puissance de calcul à vos deux machines non sollicitées pour l'ajouter à la machine 1 et tout ça à chaud bien sûr.
  Une fois le pic d'activité passé vous pouvez décider de répartir les ressources équitablement entre les trois machines.
• Haute disponibilité/Redondance : bien sûr vous êtes en droit de vous demander, si ce n'est déjà fait, ce qui adviendrait de vos machines virtuelles si votre hyperviseur venait à tomber en panne ou encore plus simplement si vous deviez arrêter celui-ci pour maintenance. Et je vous répondrais immédiatement que vos machines virtuelles seraient autant indisponibles que le serait votre hyperviseur.
  Mais les formidables ingénieurs concepteurs d'hyperviseurs ont pensé à tout et ont ajouté à ceux-ci une fonctionnalité qui permet à un hyperviseur A de confier la gestion de ses machines virtuelles à un hyperviseur B et tout cela une fois de plus sans interruption de services. Cependant un espace de stockage partagé est recommandé entre les deux hyperviseurs.

On s'abstrait des notions de serveur physique, aujourd'hui une machine virtuelle tourne sur un des hyperviseurs du système d'information. On a bien sûr moyen de savoir de quel hyperviseur il s'agit, mais ce n'est pas essentiel tant que les services associés à cette machine virtuelle tournent.

Au cours de sa vie, une machine virtuelle , pour peu que vous ayez programmé des maintenances automatiques sur vos hyperviseurs, sera amenée à se déplacer d'un hyperviseur à un autre, mais une fois de plus tant qu'il n'y a pas d'interruption de services ce n'est pas un problème pour vous. À partir d'un seul poste, vous pouvez avoir accès à de multiples informations sur vos serveurs virtuels (statut du serveur, taux d'occupation de la ram, des cpus, etc.) et vous pouvez même agir sur ceux-ci.
Pratiquement, finis les déplacements en salle machine pour aller accéder à la console de la machine puisque vous y avez accès depuis votre poste.
Voilà ce qu'apporte la virtualisation et les hyperviseurs et j'en oublie certainement.

I-B-1. Différences entre les hyperviseurs de type 1 et de type 2▲

Définition d'un SAN : le SAN repose sur la fibre optique, il est un réseau à part optimisé pour le transfert à haute vitesse de blocs de données vers et en provenance d'un disque. Les baies de disques peuvent être connectées au SAN, n'encombrant pas le réseau local (LAN) dédié aux utilisateurs.

Définition d'un HBA (Host Bus Adapter) : HBA (Host Bus Adapter) se présente généralement sous forme d'une carte PCI (PCI, PCI-X, PCI-e) et permet de connecter un serveur à un réseau de stockage (notamment un réseau SAN).

Définition d'un hyperviseur (Wikipédia) : un hyperviseur est un noyau hôte allégé et optimisé pour ne faire tourner que des noyaux d'OS invités, adaptés et optimisés pour tourner sur cette architecture spécifique. Les applications en espace utilisateur des OS invités tournent ainsi sur une pile de deux noyaux optimisés, les OS invités ayant conscience d'être virtualisés.
On dit aussi que c'est une couche d'abstraction qui s'installe entre le système d'exploitation et le matériel.

Logical Unit Number : dans ce document nous appellerons LUN tout disque du réseau de stockage attribué à un serveur.

Définition d'un volume physique : les disques durs provenant d'un SAN et pris en charge par LVM (Logical Volume Management) sont appelés volumes physiques.

Définition d'un Volume Group : un Volume Group est un ensemble de volumes physiques mis côte à côte.

Définition d'un logical Volume (ou volume logique) : un volume logique est un espace découpé dans un Volume Group. Cet espace pourra alors être utilisé par le système pour y stocker un système de fichiers et des données. L'avantage du volume logique c'est qu'il peut être agrandi/réduit à chaud selon les limites de place du volume Group auquel il appartient.

Définition d'un snapshot : faire un snapshot d'un volume logique, c'est faire une photo de celui-ci à un instant T. À l'instant T le snapshot ne contient que des pointeurs sur les données du volume logique original. À l'instant T+1 lorsque le contenu du volume logique original aura changé, le snapshot stockera alors les différences entre la photo prise à l'instant T et le contenu du volume original à T+1.

Système invité : dans cet article on désignera généralement par « système invité » une machine virtuelle/paravirtuelle.

Système hôte : dans cet article on désignera généralement par « système hôte » l'OS chargé de créer/gérer les systèmes.

On l'a compris, le fait d'avoir deux contrôleurs fibre (HBA) sur nos serveurs nous permet de faire du multipathing (failover et/ou répartition de charge).
Mais concrètement comment ça va se passer au niveau de notre système Linux ?
Prenons le cas précédent où le premier disque dur vu par le système (cf. schéma ci-dessus) était accessible par /dev/sda et /dev/sdc.
Le démon multipath va faire appel au module dm-mod (device mapper) pour créer un mapping de périphérique, c'est-à-dire une couche intermédiaire, entre le disque tel qu'il est vu par le système et les données écrites réellement sur le disque.
Lorsque le système voudra écrire des données sur le disque, il adressera le nom de périphérique mappé.

Pour la lecture des données, le principe sera le même.
En fait il suffit d'adresser les données à /dev/mapper/mpathX.
Pour connaître la valeur de X, il suffit de taper la commande /sbin/multipath -ll sous root.

/sbin/multipath -ll

mpath2 (1HITACHI_D60095920137) dm-6 HITACHI,DF600F
[size=100G][features=1 queue_if_no_path][hwhandler=0]
\_ round-robin 0 [prio=2][active]
\_ 0:0:1:1 sdb 8:16 [active][ready]
\_ 1:0:0:1 sdo 8:224 [active][ready]

Dans le cas ci-dessus il y a un mapping entre /dev/mapper/mpath2 et /dev/sdb, /dev/sdo.

Nous avons donc mis en place le multipathing sur les serveurs de notre système d'information.
Pour faire tourner un système d'exploitation sur un disque distant mieux vaut prendre le plus de précautions possible.

Avantages

• Sécurité accrue. Un des contrôleurs HBA tombe, la machine virtuelle aura toujours accès à son disque système.
• Performances : un des chemins vers le disque système est encombré ? Pas grave on passe par l'autre.

Inconvénients

• Ça demande un peu plus de temps pour la mise en place de nos machines virtuelles, le temps de configurer correctement le démon multipath (/etc/multipath.conf).
• Au niveau de la migration à chaud de machines virtuelles, mais nous en reparlerons dans le chapitre qui lui est consacré.

Sous XEN il y a deux façons de faire

• Virtualisation totale.
• Paravirtualisation

Dans le premier cas le système invité n'a pas conscience d'être virtualisé puisque le système de virtualisation lui émule un vrai bios ainsi que du matériel comme une carte graphique, carte son, carte réseau , contrôleur IDE, etc.
Ainsi on peut prendre son CD et installer sa distribution Linux préférée comme s'il s'agissait d'une machine réelle.

Dans le deuxième cas, le système a conscience d'être un système invité puisque celui-ci a été adapté pour être paravirtualisé.
Le noyau utilisé pour faire tourner notre système paravirtualisé a été spécialement conçu pour communiquer avec le noyau de l'hyperviseur.
Cette fois pas question de faire voir au système une carte graphique, son, etc. … On ne s'embarrassera pas avec ce genre de détail. Un système Linux peut très bien fonctionner sans carte graphique.
Tout ce dont on a besoin après tout c'est d'un système pouvant communiquer par le réseau et qui a assez de ressources pour faire tourner nos applications.

L'avantage de la paravirtualisation est que ses performances sont très proches d'un système réel (plus proches que dans le cas d'une virtualisation totale).
Autre avantage : la flexibilité.

Comme je le disais plus haut la virtualisation totale fait croire au système virtuel qu'il fonctionne sur une vraie machine. Au niveau stockage le système virtuel verra deux contrôleurs IDE (un primaire et un secondaire).
Malheureusement ces deux contrôleurs IDE nous limitent donc à quatre disques par machine virtuelle.
Ceci n'est malheureusement pas satisfaisant pour nos besoins de développement/production.
Chez nous, une machine qu'elle soit réelle ou virtuelle peut être amenée à faire tourner beaucoup d'applications au cours de sa vie.
Ces applications grandissent, requièrent plus d'espace disque et nous ne sommes pas capables par avance d'évaluer les besoins finals en termes de stockage.
D'où l'intérêt de pouvoir attribuer de l'espace disque supplémentaire à la volée et sans limitation à une machine afin de pouvoir agrandir les espaces alloués aux applications à la demande.

Il se peut qu’à l'heure où j'écris ces lignes cette limitation soit maintenant levée.
Il me semble que sous KVM (Kernel Virtual Machine : la virtualisation native Linux) qui tout comme xen en mode virtualisation totale utilise une version modifiée de qemu, il est possible désormais d'ajouter des disques à chaud et que ceux-ci soient considérés comme disques SCSI par le système invité.
Par contre je ne sais pas ce qu'il en est pour xen.

En mode paravirtuel, il est possible :

• d'attribuer des disques supplémentaires à chaud au système invité ;
• d'augmenter la mémoire RAM à chaud ;
• d'attribuer du cpu supplémentaire ;
• d'attribuer une nouvelle interface réseau à la volée.

Bref la paravirtualisation représentait à nos yeux de meilleures performances et une flexibilité supplémentaire non négligeable.
Le choix n'aura donc pas été long, nos systèmes invités seront donc paravirtualisés.

Pour transformer votre système Linux en hyperviseur, vous devez installer un noyau spécifique patché XEN.
La plupart des distributions fournissent ce noyau dans le système de packages.
Lorsqu’ensuite vous bootez votre machine sur le noyau XEN, celui-ci va démarrer le système installé sur les disques durs de votre serveur physique et le considérer comme le premier système invité.
Il s'agit du domaine 0, le système invité à partir duquel vous allez pouvoir contrôler tous les autres.
Les systèmes invités créés à partir du domaine 0 seront les domaines utilisateurs ou plus communément appelés domU.
Dans la branche Xen 2.X il fallait un noyau spécifique pour le domaine 0 et un noyau pour domU.
Aujourd'hui vous pouvez (mais ça n'est pas une obligation) utiliser le noyau du domaine 0 pour démarrer votre domU.
Quoi qu'il en soit, il faudra toujours que le noyau que vous utilisez pour démarrer votre domU soit stocké sur le dom0.

C'est une notion que l'on retrouve dans la plupart des virtualiseurs/hyperviseurs que ce soit KVM, Vmware ou encore xen.

Ce qu'il faut retenir pour le mode NAT (Network Address Translation), c'est que la machine/l'hyperviseur sur lequel tourne votre système invité fera office de passerelle. Chaque fois que le système invité voudra envoyer des paquets sur le réseau, ceux-ci seront d'abord envoyés à la passerelle pour y subir une petite transformation.
Lorsque la passerelle recevra des paquets IP provenant du système invité et à destination du réseau elle va tout simplement remplacer l'adresse IP source de ce paquet (donc l'adresse du système invité) par la sienne (l'adresse IP de la passerelle) et ensuite envoyer le paquet sur le réseau.
Ainsi le destinataire du paquet aura toujours l'impression que le paquet a été émis directement de la passerelle et n'aura donc aucune connaissance de la machine virtuelle.

Ce qu'il faut retenir pour le mode bridgé c'est que la machine virtuelle sera sur le même réseau que sur le système hôte.
En fait en mode bridgé vous créez en quelque sorte un hub/commutateur sur lequel votre système hôte et votre système invité seront connectés. Et ce commutateur sera lui-même connecté au réseau physique.

Comme je le disais plus haut, un système Linux paravirtualisé est un système Linux modifié.
La plupart des CD-ROM d'installation des distributions installent un système Linux « normal » donc incompatible avec le système de paravirtualisation offert par xen.
La seule solution que nous ayons trouvée à ceci est d'installer le système Linux invité en mode totalement virtuel.
(Toutefois s'il s'agit d'une distribution debian ou dérivé l'utilitaire debootstrap nous permet d'éviter d'avoir à installer le système en mode totalement virtualisé).
Une fois ceci fait, nous pourrons alors « Xenifier » le système c'est-à-dire installer sur le système le noyau xen pour système invité.

Création du fichier de configuration de notre machine virtuelle.

Pas compliqué, il nous faut :

• un noyau et son image initrd sur lesquels démarrer (le noyau pour domaine Utilisateur) ;
• le nom de la machine virtuelle :
• le nombre de cœurs CPU sur lesquels la machine va tourner ;
• la quantité de RAM qui sera attribuée à la machine ;
• dans le cas où vous décidez que votre machine virtuelle sera en mode bridgé (une adresse MAC, plus le nom du pont) ;
• le disque physique sur lequel devra démarrer la machine ;
• quelques paramètres optionnels.

Voici un exemple de fichier de configuration basique :

#Je prends le noyau xen de l'hyperviseur
kernel = "/boot/vmlinuz-2.6.18-6-xen-686"
#Je prends l'initrd de l'hyperviseur
ramdisk = "/boot/initrd.img-2.6.18-6-xen-686"
# Mémoire par défaut de la machine virtuelle
memory = 2048 
# on pourra monter à chaud la mémoire jusque 4 Go
maxmem = 4096 
#Nom de l'instance de la VM
name = "virtualdebian"
#celle-ci tournera sur 2 cœurs de processeurs
vcpus = 2
#mode bridgé avec attribution d'adresse mac 
#à l'interface réseau de la VM
vif = [ 'mac=00:16:3e:00:00:01, bridge=xenbr0' ]
#ici j'attribue le volume logique lvsysteme à la machine virtuelle
#et je le fais voir en tant que premier disque dur scsi (/dev/sda) en écriture (w)
disk = [ 'phy:/dev/vgvirtualdebian/lvsysteme,sda,w'] 
#ici j'indique au noyau que la racine de mon système virtuel se trouve 
#sur le volume logique lvroot qui se trouve lui-même dans le Volume Group VolGroup00
root = "/dev/mapper/VolGroup00-lvroot ro"

V-G-1. Commentaires sur le fichier de configuration ci-dessus▲

Une fois votre fichier de configuration créé et sauvegardé il est grand temps de le tester.
Nous allons donc créer notre premier domU avec la commande suivante :

xm create -c <nom_du_fichier_de_configuration>

L'option -c nous permet de suivre à l'écran la séquence de boot de la machine virtuelle (comme si vous démarriez un serveur physique et que vous étiez derrière l'écran).
Une fois la séquence de boot terminée nous obtenons la bannière de login du système (tout comme un vrai système).

Sous xen une commande ultime à retenir :
La commande xm.
À partir d'un terminal avec cette commande vous pourrez contrôler de nombreux aspects de votre machine virtuelle/paravirtuelle (démarrage, arrêt, attribution mémoire, disque, etc.).

Démarrer une machine virtuelle :

xm create -c <nom_du_fichier_de_configuration>

le -c vous servira à suivre la séquence de boot de votre machine virtuelle en mode paravirtualisation, mais sera totalement inutile en mode virtualisation (puisque le démarrage d'une machine virtuelle va provoquer le démarrage d'une instance de qemu).

Lister les machines virtuelles en fonctionnement :

xm list
Retourne une liste de ce type:
Name     ID Mem VCPUs State
Domain-0 0  512    1  r-----
debvirt  20 2048   2 -b----

Figer une machine virtuelle :

xm pause <nom_de_machine_virtuelle>
ou
xm pause <id_machine_virtuelle>

Sauvegarder l'état d'une machine virtuelle dans un fichier :

xm save <nom_machine_virtuelle> <file>
ou
xm save <id_machine_virtuelle> <file>

Restaurer une machine virtuelle à partir d'un fichier :

xm restore <file>

Affichage de l'état des machines virtuelles un peu comme avec la commande top :

xm top

Accéder à la console d'une machine paravirtualisée :

xm console <nom_machine_virtuelle>
ou
xm console <id_machine_virtuelle>

Attacher un disque à chaud de l'hyperviseur vers une machine paravirtuelle :

xm block-attach <domain> <nom_de_peripherique_disque_sur_hyperviseur> <nom_voulu_du_peripherique_sur_VM> <mode:lecture,ecriture>

(ici domain = nom_machine_virtuelle ou id_machine_virtuelle)
Exemple :
xm block-attach 5 phy:/dev/sdb /dev/sdc w
(J'attache à la machine virtuelle dont l'ID est 5 le disque /dev/sdb et je lui fais voir en tant que disque /dev/sdc et j'autorise l'écriture).
Avec ce type de commande inutile de redémarrer la machine virtuelle, grâce à dbus et udev le disque sera vu tout de suite et un fichier /dev/sdc sera créé.

Détacher un disque à chaud d'une machine virtuelle
Si le disque en question n'est pas utilisé par la machine virtuelle vous avez la possibilité de le détacher de la machine virtuelle.

xm block-detach <id_domaine> <nom_de_péripherique>

Exemple
Détacher le disque que l'on avait alloué au-dessus avec la commande xm block-attach
xm block-detach 5 /dev/sdc

Redémarrer une machine virtuelle :

xm reboot <nom_machine_virtuelle>
ou
xm reboot <id_machine_virtuelle>

(Dans le cas d'une machine paravirtualisée sous Linux --> redémarrage Linux)

Éteindre une machine virtuelle :

xm shutdown <nom_machine_virtuelle>
ou
xm shutdown <id_machine_virtuelle>

Provoquera un arrêt classique d'une machine virtuelle : arrêt des services + extinction machine virtuelle.

Stopper immédiatement une machine virtuelle
Provoquera un arrêt brutal de votre machine virtuelle (un peu comme si vous débranchiez le câble d'alimentation).

xm destroy <nom_machine_virtuelle>
ou
xm destroy <id_machine_virtuelle>

Confier la gestion d'une machine virtuelle à un autre hyperviseur :

xm migrate [-l] <nom_ou_id_machine_virtuelle> <adresse ip ou nom réseau de l'hyperviseur cible>

Le -l permet de faire de la migration à chaud (sauvegarde des pages mémoire, figer la machine, restauration des pages mémoire sur l'hyperviseur cible, on défige la machine).
Sans le « -l » «vous éteignez la machine et vous la redémarrez sur l'hyperviseur cible.

Rappelez-vous un périphérique multipathé est généralement nommé /dev/mapper/mpathX (où X est un entier).
Donc si les partitions système de votre domU sont installées sur une lun multipathée nous aurons une ligne de ce type dans le fichier de configuration de notre domU
disk=['phy:/dev/mapper/mpath5,/dev/sda,w']

Dans ce cas-là aussi il y a un risque qu'une lun multipathée soit dénommée /dev/mapper/mpath5 sur l'hyperviseur A et /dev/mapper/mpath6 sur l'hyperviseur B.
N'étant pas intime avec le noyau Linux j'ignore comment le système décide de numéroter ses périphériques multipath.
Pour contourner le problème, nous pouvons en fonction de l'ID SCSI du disque partagé (de la lun multipathée) créer un alias.
Ceci se passe au niveau du fichier de configuration du démon multipath.
Cela consiste donc à dire que pour tout disque dont l'ID SCSI est XYZ, nous voulons que celui-ci ne soit plus nommé /dev/mapper/mpathX, mais plutôt /dev/mapper/domU-systeme_XYZ.
Il faudra alors avoir configuré le démon multipath de manière identique sur les deux hyperviseurs, donc en d'autres termes avoir le même fichier /etc/multipath.conf sur les deux serveurs physiques.