Les architectures web – le serveur dédié

icone-projet-webCet article fait suite à l’introduction sur les architectures web. La dernière fois, nous nous sommes intéressés aux composants d’une architecture web ainsi qu’à une installation basique mais limitée à un unique serveur virtuel. Nous allons maintenant nous placer dans une nouvelle situation plus exigeante. En effet, le site que vous hébergiez dans un premier temps sur un serveur virtuel est à l’étroit. Votre site a gagné en popularité et votre serveur virtuel ne vous suffit plus en terme de performances.

Regard en arrière

Afin de pouvoir étudier les possibilités d’évolution, il est intéressant de se pencher sur l’offre que vous possédez actuellement, le serveur virtuel. En effet, le serveur virtuel est une machine virtuelle hébergée sur le même serveur physique de nombreuses autres en utilisant des technologies de virtualisation telles que VMWare ou Xen. L’inconvénient majeur de ce type de solution est, selon moi, la mutualisation des ressources de disque dur.

Les disques dur à plateau sont aujourd’hui le composant informatique qui a évolué le plus lentement en terme de performances. Ceci s’explique assez simplement par des contraintes physiques extrêmement complexes liées aux composants mécaniques de très haute précision. Si en plus, vous vous retrouvez mutualisés sur un jeu de disques dur à plateau, ça commence à devenir vraiment léger en terme de performances. Évidemment, les technologies telles que le RAID10 permettent d’obtenir des performances accrues mais ça reste assez modeste par rapport ce que peuvent offrir des SSD.

Les offres de machines virtuelles hébergées sur des machines physiques dotées de SSD existent mais elles sont assez rares et souvent onéreuses.

En avant !

La première solution qui se présente à vous lorsque vous souhaitez disposer de plus de performances est la solution du serveur dédié. En effet, au lieu de partager des ressources avec vos voisins, vous allez pouvoir tout garder pour vous.

En terme de choix, vous allez avoir face à vous une offre pléthorique. Vous aurez le choix entre de très nombreux fournisseurs différents disposant de très nombreuses offres. En terme de prix, l’entrée de gamme des serveurs dédies est tout à fait abordable même pour un particulier. Si vous acceptez de mettre un budget légèrement supérieur à l’entrée de gamme, vous accéderez rapidement à une puissance de calcul tout à fait conséquente.

Le choix de l’hébergeur est à faire en fonction des critères de prix et des fonctionnalités qui vous sont proposées. Une bonne solution pour avoir des retours est d’interroger des amis qui ont eu l’occasion de louer un serveur dédié. Vous allez ainsi pouvoir avoir un retour d’expérience concret vous permettant de vous faire une idée.

Lors de cette phase, le choix du serveur se fera probablement en fonction du budget dont vous disposez. Je ne peux que vous recommander de vous pencher sur le choix d’un serveur disposant de SSD. En effet, vous allez héberger sur un même serveur toute votre architecture web ce qui va générer des IO aléatoires et concurrents importants. Or, il s’agit d’un point sur lesquels les SSD sont très significativement plus performants que les disques dur à plateau.

Au niveau du choix du système d’exploitation, je ne peux que vous recommander de choisir le système d’exploitation avec lequel vous êtes le plus à l’aise si votre objectif est d’avoir une architecture stable. Il y a tout de même une nuance à apporter à ceci. Le choix d’une distribution de type « rolling release » telle que Arch Linux ou Gentoo bien qu’agréable à utiliser car disposant de versions très récentes des applications vous rajoutera un travail d’administration conséquent. En effet, le suivi des mises à jour de sécurité et des applications a besoin d’être très régulier. De plus, contrairement à des distributions telles que Debian ou CentOS, les versions de logiciels disponibles dans les dépôts ont fait l’objet d’une procédure de test moins approfondie. Pour résumer, c’est donc à vous de voir en fonction des vos objectifs et des vos sensibilités. Il n’y a pas vraiment de bon ou de mauvais choix, tout dépend de ce que vous souhaitez réaliser.

Les spécificités

Au niveau du système d’exploitation, il y aura peu de différences entre un serveur virtuel et un serveur dédié. Toute votre pile applicative sera hébergée dans un même système d’exploitation.

Les quelques différences se situent au niveau de l’interface avec le matériel physique. Tout d’abord, vous allez devoir gérer le RAID logiciel qui sera probablement fourni avec votre serveur. La mise en place du RAID sera probablement faite par défaut par votre hébergeur ou par vous-même à travers l’interface de gestion. Je ne peux que vous recommander de vous interroger sur le schéma de partitionnement avec lequel votre serveur sera livré car il correspondra peut être pas à ce que vous souhaitez. Il serait dommage de s’en rendre compte une fois que vous aurez tout installé.

La fonctionnalité la plus intéressante à activer au niveau de mdadm est l’activation des alertes par email en cas de défaillance du RAID. Il s’agit réellement d’une fonctionnalité indispensable car découvrir que votre RAID est mort lorsque vous commencez à avoir des erreurs de disque ou des kernel panic n’est pas très agréable. Vous disposez également d’un autre outil qui vous permettra de suivre la santé de vos disques. Il s’agit de SMART. Vous avez à votre disposition sous Linux le paquet « smartmontools » qui vous permettra d’exécuter des tests manuels mais aussi de mettre en place des tests réguliers avec envoi d’alertes email si jamais les choses ne se passent pas comme elles le devraient.

Bilan

Le passage du serveur virtuel vers le serveur dédié est le premier grand pas. En effet, vous êtes désormais libres de faire ce que vous souhaitez avec le matériel mis à disposition. Vous devrez rapidement remarquer une amélioration des performances de votre site ainsi qu’une capacité d’accueil de visiteurs assoiffés de contenu accrue.

Néanmoins, votre serveur dédié reste un SPOF conséquent car vous ne disposez que de très peu de redondance dans un serveur dédié. De plus, la cohabitation entre tous les composants de votre architecture dans un même système d’exploitation peut se passer plus ou moins bien. Dans le prochain article, nous allons donc nous intéresser à la prochaine étape de l’évolution de votre architecture, le passage vers plusieurs serveurs.

SNMP : Ajouter des informations personnalisées à la MIB

Je n’ai pas encore beaucoup eu l’occasion de parler de supervision sur ce blog. C’est pourtant un sujet très intéressant et particulièrement vaste. Aujourd’hui, nous allons détailler une petite fonctionnalité de SNMP qui nous permet de faire de nombreuses choses très utiles.

Vous le savez surement déjà, SNMP (Simple Network Management Protocol) est un protocole très utile pour la supervision d’équipements informatiques que ce soit des serveurs, des équipements réseau, des sondes de température, etc. Il s’agit de la référence en la matière. Sa structure est quelque peu archaïque vis à vis des tendances actuelles mais sa pertinence est toujours d’actualité. Il existe de nombreuses ressources sur Internet au sujet de SNMP, je ne reprendrai donc pas la théorie de ce protocole.

La supervision est un domaine très vaste et surtout très compliqué. Chaque configuration et chaque équipement va avoir ses petites spécificités. De plus, chaque situation va nécessiter la supervision d’une métrique X ou Y. Concrètement, les informations que l’on souhaite superviser ne sont pas forcément présentes dans une MIB SNMP existante.

Les solutions alternatives sont nombreuses. On peut choisir de développer une application spécifique ce qui implique un travail assez colossal et une intégration dans l’application de supervision. Une autre solution est de « customiser » le serveur SNMP afin de nous envoyer des informations spécifiques. Ces informations ne feront pas partie d’une MIB standardisée mais pourront nous être très utiles. Les manipulations concernent uniquement snmpd sous Unix.

Le démon snmpd que nous utilisons comme agent SNMP sur les plateformes Unix/Linux nous renvoit par défaut un grand nombre d’informations. Il supporte également l’ajout d’informations récoltées par l’exécution de scripts tierces. Les informations renvoyées par ces scripts seront placés dans la branche « .1.3.6.1.4.1.2021.8  » de la MIB standard.

Il est nécessaire de spécifier l’exécution d’un script dans le fichier de configuration snmpd.conf. Voici un exemple de script :

exec railsversion « /bin/bash /etc/snmp/railsversion.sh »

Lors des tests que j’ai effectué, j’ai remarqué qu’il n’était pas possible d’utiliser des « pipes » dans cette commande ce qui est fort dommage. Une fois que vous avez ajouté cette ligne dans votre fichier de configuration snmpd, il est nécessaire de le redémarrer pour qu’elle soit prise en compte.

Si nous effectuons un snmpwalk sur la branche SNMP mentionnée précédemment, nous remarquons que les informations retournées par ce script son bien présentes.

root@dev:~# snmpwalk -v2c -cpublic 10.8.0.6 .1.3.6.1.4.1.2021.8
UCD-SNMP-MIB::extIndex.1 = INTEGER: 1
UCD-SNMP-MIB::extNames.1 = STRING: railsversion
UCD-SNMP-MIB::extCommand.1 = STRING: /bin/bash /etc/snmp/railsversion.sh
UCD-SNMP-MIB::extResult.1 = INTEGER: 0
UCD-SNMP-MIB::extOutput.1 = STRING: 2.1.0-7
UCD-SNMP-MIB::extErrFix.1 = INTEGER: noError(0)
UCD-SNMP-MIB::extErrFixCmd.1 = STRING:

Nous avons donc réussi à intégrer nous-même des informations dans SNMP. Ces informations ne sont pas standardisées bien évidemment mais vous permettent d’adapter votre solution à vos besoins. Il est ensuite possible de réutiliser ces informations dans Nagios par le biais de plugins « maison » assez aisément. J’en reparlerai ultérieurement.

Au final, cette petite astuce assez simple permet de se confectionner un bout de MIB personnalisé simplement et efficacement. Cette solution est largement plus efficace que le développement d’une application spécifique.

Un serveur personnel avec ZFS

Ca fait quelques temps désormais que je souhaitais faire un retour d’expérience sur le montage d’un serveur personnel. Nous allons tout d’abord étudier les contraintes d’un tel serveur et les solutions applicatives que nous pouvons proposer.

Le premier objectif d’un serveur personnel est de disposer d’un ordinateur qui permettra de rendre un certain nombre de services sur son réseau de domicile. Ces services peuvent être variés en fonction des envies et des motivations de chacun. Des exemples de services sont DHCP, DNS, Pare-feu, NFS, HTTP et bien d’autres. L’objectif secondaire inavoué, mais non moins important, est la disposition d’une machine permettant de « bidouiller » à loisir.

Objectif

Dans mon cas, l’objectif était de disposer d’une capacité de stockage convenable afin de pouvoir y stocker de nombreuses sauvegardes diverses et variées mais aussi de pouvoir héberger quelques services associés tels que NFS et HTTP. N’ayant plus que du Linux ou du MacOS, CIFS ou Samba ne m’intéressaient pas. Le besoin en puissance est donc relativement limité.

Contraintes

Les contraintes pour ce type de serveur sont cependant nombreuses. Tout d’abord, il est nécessaire que ce serveur soit assez silencieux. J’ai la possibilité de le stocker dans un placard et/ou dans un cagibi mais le problème est qu’il m’est impossible d’y amener un connexion Internet en câblé. Sa localisation sera donc sur une étagère ou entre le canapé et le mur. Le silence est donc un facteur contribuant à une non volonté d’extermination de la part de ma fiancée. Ensuite, il est nécessaire que ce serveur consomme relativement peu d’électricité. L’électricité, ça coûte cher et donc il faut en consommer le moins possible, c’est aussi simple que cela.

De plus, il faut que ce serveur ait des proportions réduites. L’espace entre le mur et le canapé est assez réduit de même pour la place sur l’étagère. Une tour moyenne sera donc bien trop grande pour ces contraintes. Je souhaitais également utiliser du ZFS pour ce serveur afin de ne pas avoir à faire du RAID logiciel standard assez douteux. Il était également nécessaire de pouvoir y placer deux disques dur de 3 pouces et demi en SATA.

Solution matérielle

La plateforme Intel Atom répond particulièrement bien à la contrainte de consommation électrique ainsi qu’à la contrainte de volume physique. C’était donc un choix évident. Le nombre d’ordinateurs de bureau Atom capables d’accommoder deux disques dur de 3 pouces et demi est relativement faible. Mon choix s’est tourné vers la plateforme MSI Nettop.

Par défaut, il n’y a qu’un seul emplacement 3 pouces et demi mais il est possible de retirer le lecteur DVD et le remplacer par un disque dur moyennant l’achat d’un petit kit adaptateur. L’alimentation électrique se fait via un transformateur qui vient fournir le PC directement en courant continu. Il dispose également d’un emplacement SD ce qui pourra éventuellement être utile pour faire de la sauvegarde sur ce type de médium.

Comme vous le savez, ZFS calcule de somme de contrôle pour toutes les données écrites sur ses volumes. Cette opération consomme de la ressource processeur. Le processeur étant un Intel Atom, il y a de quoi se poser des questions en effet. L’objectif n’étant pas de faire des gros transferts de données à la vitesse de la lumière, cela n’est pas réellement problématique. Le débit de données reste relativement correcte.

Par défaut, le MSI Nettop est fourni avec un disque dur de 160Go ce qui est trop peu. J’ai donc acheté un disque supplémentaire Western Digital de 500Go pour le remplacer.

Solution logicielle

Une des contraintes était de pouvoir disposer de ZFS. Cela laisse donc trois choix : Solaris, OpenSolaris ou FreeBSD. Étant donné l’orientation entreprise de Solaris et la nouvelle politique de support d’Oracle, il n’était pas souhaitable de l’utiliser. FreeBSD est un système d’exploitation qui ne me plait pas particulièrement et ce dernier n’est pas au niveau d’OpenSolaris en terme de versions de ZFS. Il n’y a pas de déduplication de données sur ZFS sous FreeBSD. Mon choix s’est donc naturellement tourné vers OpenSolaris.

Un autre avantage est qu’il gère directement NFS et CIFS sans avoir besoin d’applications supplémentaires. Cela rend très simple la gestion de partages réseaux par le biais de commandes simples et efficaces. La documentation Oracle est très claire à ce niveau, je vous laisse la consulter.

Utilisation

Une fois que nous avons une solution logicielle et une solution matérielle, nous allons pouvoir décider ce que nous allons en faire.

Mon serveur me sert en tant que serveur NFS afin de sauvegarder des données à la volée à partir de mes différents ordinateurs. Pour mon MacBook Pro, cela me permet d’utiliser l’excellent Time Machine. La mise en place de Time Machine sur un NFS ne se fait pas sans douleur mais il existe de nombreux tutoriels sur Internet afin de vous aider. Ce serveur effectue une sauvegarde périodique (tous les 15 minutes) de mes emails Gmail. L’application getmail permet de récupérer en POPS les nouveaux mails. La récupération initiale de mes 70.000 mails a pris une nuit sur mon ADSL 7Mbit/s et désormais il récupère juste les mails le plus récents.

Ce serveur héberge également mon blog en ce moment le temps que je réinstalle ma VM Xen. Le temps de chargement de pages web a même été amélioré par rapport à ma VM ce qui est assez impressionnant. J’ai activé la déduplication de données en même temps que j’ai écrit le tutoriel précédent. Ce serveur a été tout à fait stable. Je n’ai rencontré aucun problème depuis 2 mois que ce serveur est en place.

Activer la déduplication de données avec ZFS

Nous avons vu la dernière fois ce qu’était la déduplication de données ainsi que les applications (essentiellement libres) de cette technologie. Nous allons désormais nous intéresser à la mise en place de cette technologie dans le cas d’un système de fichiers ZFS.

Si vous avez un système de fichiers ZFS, cela signifie que vous avez soit un OpenSolaris soit un BSD. Vous ne pourrez pas faire de déduplication de données avec votre BSD car les versions actuellement implémentées ne supportent pas cette technologie. Vous devrez donc avoir un OpenSolaris sous le coude. De plus, la déduplication a été ajouté au build 128 d’OpenSolaris. Si vous avez une version 2009.06, vous allez devoir faire une mise à jour vers les dépôts de développement ou bien attendre la nouvelle version (qui aurait du être 2010.03). Je parlerais de la mise à jour très prochainement.

Vérifions donc que vous avez la bonne version d’OpenSolaris en regardant le fichier /etc/release. Vous devez avoir une information indiquant un numéro de version supérieur à 128. Dans le cas de mon OpenSolaris, ce fichier contenait, entre autre, la ligne suivante : OpenSolaris Development snv_134 X86.

Par défaut, la déduplication n’est activée sur aucun pool ZFS. Si vous avez fait la montée de version sans demander de fonctionnalités supplémentaires de ZFS, il est probable que votre version de ZFS soit antérieure à celle supportant la déduplication.

Vérifiez donc la liste des volumes ZFS à mettre à jour.

# zpool upgrade
This system is currently running ZFS pool version 22.

The following pools are out of date, and can be upgraded. After being
upgraded, these pools will no longer be accessible by older software versions.

VER POOL
— ————
14 rpool

Use ‘zpool upgrade -v’ for a list of available versions and their associated features.

Nous allons donc mettre à jour nos pools ZFS afin de pouvoir bénéficier de la déduplication.

# pfexec zpool upgrade -a
This system is currently running ZFS pool version 22.

Successfully upgraded ‘rpool’

Nous avons donc mis à jour notre pool ZFS. Il nous reste plus qu’à activer la fonctionnalité.

$ zfs get dedup rpool
NAME PROPERTY VALUE SOURCE
rpool dedup off default
$ pfexec zfs set dedup=on rpool
$ zfs get dedup rpool
NAME PROPERTY VALUE SOURCE
rpool dedup on local
$ zpool list rpool
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
rpool   19.9G 10.7G   9.19G  53% 1.00x     ONLINE       –

Le tour est joué ! Le facteur de déduplication vous indique la quantité d’espace disque que vous avez économisé. Lorsque vous activez la déduplication sur un volume, ce facteur est de 1x par défaut. Les données actuellement présentes sur le volume ne seront pas dédupliquées, il faudra attendre que de nouvelles données soient ajoutées.

Source : CTIStrategy

La déduplication de données

Profitons de cette journée pluvieuse pour parler d’un peu de stockage. J’ai relativement peu l’occasion de parler de stockage sur ce blog bien que ce soit un sujet particulièrement intéressant, surtout dans le cas des réseaux de stockage. Ce n’est cependant pas de réseaux de stockage dont nous parlerons aujourd’hui mais de déduplication de données.

Notion de duplication

La notion de duplication de données est relativement simple. Prenons un jeu de données, la duplication de ces données donne un second jeu identique de données mais sur un autre espace de stockage. Il est possible de faire de la duplication dans le cas de la copie de disques ou de DVD par exemple. Il est également intéressant de faire de la duplication de données dans le cas de la virtualisation. Lorsque des machines virtuelles sont « provisionnées » ou bien, plus simplement, créées, une technique envisageable est la duplication d’une machine virtuelle « template ».

Dans le cas de la virtualisation, de nombreuses données sont présentes en plusieurs exemplaires. Sur une plateforme de virtualisation, il va être exécuté un certain nombre de systèmes d’exploitation. Un serveur de virtualisation standard aujourd’hui est capable d’exécuter 20 à 30 machines virtuelles. Supposons que ces machines virtuelles disposent de 2-3 systèmes d’exploitation différents, cela implique que 7 à 15 copies du même système d’exploitation vont être stockées.

Définition de la duplication

La déduplication va nous permettre de solutionner en grande partie ce problème. Cette technique a pour objectif de supprimer les doublons/triplons/etc du support de stockage afin de stocker qu’une seule copie des données. Il est possible d’implémenter cette technique à plusieurs endroits et à plusieurs niveaux. Prenons tout d’abord l’exemple de la mémoire vive et ensuite, l’exemple des disques.

Déduplication de la mémoire vive

La mémoire vive est un support de stockage d’information particulièrement couteux. Nous avons donc tout intérêt à en optimiser son utilisation. L’exemple que nous avons proposé plus haut pour illustrer la duplication des données est tout à fait valable pour les informations stockées en mémoire vive.

Le système d’exploitation va calculer une empreinte (« hash » pour les anglophones) pour une certaine unité de stockage pour la totalité de la mémoire vive. Lorsque le système rencontrera deux unités présentant la même empreinte, il en supprimera une copie et fera un lien vers l’unique copie. L’unité de stockage utilisée est, souvent, la page mémoire. Une empreinte est donc calculée pour chaque page mémoire et la déduplication se fait à ce niveau.

A ma connaissance, seuls les systèmes de virtualisation utilisent cette technique pour la mémoire vive. C’est, plus particulièrement, le cas de VMWare et de Xen 4.0.

Déduplication de disques

L’exemple de la mémoire vive est transposable aux supports de disque divers. La déduplication au niveau des disques va permettre les mêmes avantages que la mémoire vive et utilisera le même fonctionnement. La différence se situe principalement au niveau de l’unité de stockage qui sera choisie pour le calcul de l’empreinte. Le bloc sera, le plus souvent, utilisé pour les disques.

Une application réelle pour la déduplication se situe d’une part dans les systèmes de virtualisation mais aussi dans les systèmes de sauvegarde dans lesquels on peut retrouver de (très) nombreuses copies d’une même copie. Les équipements qui effectuent la déduplication sont les SAN mais aussi les systèmes de fichiers (« filesystem » pour les anglophones).

Vous allez me dire « Mais mon Linux il sait pas faire ca ! » et, oui, vous avez raison. Si vous voulez effectuer de la déduplication au niveau d’un système de fichiers, il va falloir utiliser ZFS sous OpenSolaris. J’en parlerais dans un prochain billet. Il serait prévu d’inclure ce type de fonctionnalité dans Btrfs.

Au final, j’espère avoir fait un tour d’horizon assez complet de cette technique relativement récente mais que je trouve particulièrement intéressante.

Installation de Xen 4.0 sur Debian Lenny

Les tutoriels d’installation ne sont pas forcément les plus intéressants à blogger et j’en ai fait très peu pour cette raison. J’avais déjà parlé de l’installation de Xen 3.2.1 sur Debian Lenny. Au moment où j’ai écrit ce billet, cette version commençait à être relativement vieillissante. Je vais donc traiter aujourd’hui de l’installation de Xen 4.0.

Petit historique

Vous savez peut être que Xen a été quelque peu obscurcit par l’introduction de KVM dans le noyau Linux. Cette inclusion de KVM a conduit des distributions telles que Red Hat et Ubuntu à supprimer Xen de leurs distributions ou de ne laisser qu’un support pour le moins minimal. A l’époque de ces faits, Xen n’était compatible qu’avec un ou deux noyaux Linux patchés par l’équipe de Xen. Cette époque est révolue car Xen a évolué vers les noyaux dits « Paravirt Ops » ce qui signifie que la compatibilité d’un noyau Linux avec Xen ne tient plus qu’à un module de ce même noyau.

La version Xen 4.0 est particulièrement intéressante car il s’agit de la première version qui fonctionne par défaut avec les noyaux Paravirt Ops. L’installation de versions antérieures vous assurera la douleur de devoir éventuellement passer vers une version supérieure à la 4.0 lorsque vous voudrez mettre à jour vos noyaux Linux.

Installation

Nous pouvons désormais passer aux choses sérieuses. Nous allons effectuer une installation à partir des sources car il n’existe pas encore de paquets. Et puis de toute façon, une petite compilation ne vous fait pas peur !

Nous allons tout d’abord récupérer l’archive sur le site de Xen et on la dézippe :

wget http://bits.xensource.com/oss-xen/release/4.0.0/xen-4.0.0.tar.gz

tar zxvf xen-4.0.0.tar.gz

Nous allons ensuite installer tous les pré-requis et ils sont nombreux.

apt-get install bcc bin86 gawk bridge-utils iproute libcurl3 libcurl4-openssl-dev bzip2 module-init-tools transfig tgif texinfo texlive-latex-base texlive-latex-recommended texlive-fonts-extra texlive-fonts-recommended pciutils-dev mercurial build-essential make gcc libc6-dev zlib1g-dev python python-dev python-twisted libncurses5-dev patch libvncserver-dev libsdl-dev libjpeg62-dev iasl libbz2-dev e2fslibs-dev git-core uuid-dev gcc-multilib

Passons désormais à la compilation. Si vous avez une machine dotée de plusieurs cœurs / processeurs, n’hésitez surtout pas à utiliser l’option -jX où X est le nombre de cœurs que vous avez. Cette option permet de répartir la compilation sur tous les cœurs et ainsi de la finir plus rapidement. J’avais un BiQuad Core, donc ce sera 8 pour cet exemple.

make -j8 xen

make -j8 tools

make -j8 stubdom

Ensuite, on installe tout ca.

make -j8 install-xen

make -j8 install-tools

make -j8 stubdom

Grâce à toutes ces commandes, nous avons installé Xen ainsi que tous les outils associés. Il nous manque plus que le noyau Linux pour les domaines. A partir de là, vous pouvez soit créer votre propre noyau soit utiliser un noyau proposé par Xen. J’ai choisi de faire cela car c’était plus simple, plus rapide et plus pratique.

On va donc exécuter la commande qui va nous permettre de récupérer et de compiler le noyau qui va bien pour notre installation de Xen.

make -j8 world

Pour installer le noyau que vous avons compilé, il ne manque qu’à exécuter la commande suivante. On crée au passage l’initrd qui va bien.

make install

mkinitramfs -o /boot/initrd-2.6.31.13.img 2.6.31.13

Vous devez ensuite modifier Grub afin qu’il s’adapte à Xen. La configuration suivante fonctionne sur l’hyperviseur que j’ai eu l’occasion d’installer. Il faut adapter le root en fonction de votre serveur. Ici, il s’agissait d’un contrôleur RAID HP.

title           Xen 4.0.0 / Debian GNU/Linux, kernel 2.6.31.13
root            (hd0,1)
kernel          /boot/xen-4.0.0.gz
module          /boot/vmlinuz-2.6.31.13 root=/dev/cciss/c0d0p2 ro console=tty0
module          /boot/initrd-2.6.31.13.img

Vous pouvez ensuite rebooter sur votre nouvelle installation de Xen 4.0 avec votre noyau Paravirt Ops. Si vous souhaitez modifier des options à la compilation du noyau, il faut se placer dans le bon répertoire et activer les bons paramètres dans le menu.

cd build-linux-2.6-pvops_x86_64

make menuconfig

Il faut activer le support TUN/TAP si vous souhaitez exécuter des domaines HVM ainsi que le support du 802.1Q si vous souhaitez placer vos domaines sur différents VLAN. Ces deux options ne sont pas activées par défaut.

Au final, j’espère que ce tutoriel vous sera utile et que j’ai été clair. Le passage vers les noyaux en Paravirt Ops est une évolution majeure dans l’histoire de Xen et permettra une adoption nettement plus large.