Les billets précédents évoquaient l’amélioration de performances d’un site web grâce à un astucieux montage basé sur plusieurs machines virtuelles. Aujourd’hui, nous allons parler de benchmarking de site web.

Quelques rappels

L’expression « benchmarking » est devenue très populaire dans le milieu professionnelle comme de nombreux autres termes anglais cherchant à démontrer un dynamisme et une originalité. Nous parlerons ici que de sa signification originale qui est la mesure de performances.

Sur l’Internet, l’utilisateur ne demande plus rien d’autre que de l’instantané. Si votre site met plus de quelques secondes à s’afficher, l’utilisateur passera probablement son chemin malgré la qualité éventuelle du contenu.

Les outils pour mesurer les performances des sites web ne manquent pas à l’appel. On en trouve de nombreux en ligne et sous forme d’applications. Certains présentent une originalité intéressante alors que d’autres se cantonnent à des fonctionnalités basiques. L’outil le plus connu est probablement « ab » car il est souvent installé en même temps qu’Apache. Cet outil dispose de fonctionnalités intéressantes mais relativement basiques.

Tsung

Comme l’indique le titre, nous allons nous intéresser à Tsung. Il s’agit d’un projet Open Source Français développé par Nicolas Niclausse. Cette application ne se limite pas aux sites web via HTTP mais peut également benchmarker les applications Webdav, SOAP, MySQL, PostgreSQL, LDAP et Jabber/XMPP. La mesure de performances peut se faire d’une seule machine ou de tout un cluster.

Tsung permet de générer et d’exécuter des scénarios de test. Cela signifie qu’il ne se limite à charger une page web selon une fréquence définie. Vous allez pouvoir lui faire naviguer votre site et utiliser diverses fonctionnalités.

Fonctionnement

L’enregistrement de scénarios est très simple. Il vous suffit de lancer le « tsung_recorder » et de le paramétrer en tant que proxy de votre navigateur. Les actions que vous allez ensuite effectuer dans votre navigateur vont être enregistrées. Vous aurez ainsi créé une suite d’actions.

Une fois la suite d’actions créée, il sera nécessaire de paramétrer les informations relatives au scénario,  à savoir l’IP du serveur à tester, la fréquence d’exécution, etc. La documentation de ce projet est claire à l’exception du chapitre sur les fichiers de configuration de scénario. Pour cela, je vous donne un fichier de configuration de scénario complet et fonctionnel qui devrait vous permettre d’y voir un peu plus clair.

Une fois la configuration terminée, il ne vous restera plus qu’à l’exécuter et observer votre serveur travailler.

Analyse des résultats

L’exécution d’un scénario de benchmarking est une chose mais l’interprétation des résultats est essentielle. Tsung a tout prévu pour vous.

Grâce à l’utilitaire « tsung_stats », vous allez pouvoir générer une série de graphiques traduisant les résultats du test. Cet utilitaire prendra même le soin de les mettre en page dans une page web. L’image ci-dessous est un exemple (en version réduite) des graphiques en question. Un fichier vectoriel est également généré si vous souhaitez disposer d’un visuel plus flexible.

Si vous souhaitez comparer les résultats, Tsung met à votre disposition l’outil « tsplot » qui vous génèrera des graphiques comparant les différents tests que vous avez exécuté. L’image ci-dessous est un exemple de graphique généré par tsplot.

Au final, Tsung est un excellent outil permettant de créer simplement des scénarios de benchmarking complexes et de visualiser ces résultats à travers des graphiques clairs. Seul bémol, il ne s’agit pas d’un logiciel particulièrement simple à utiliser car tout se fait en ligne de commande. Cependant, un utilisateur de Linux un peu aguerri devrait pouvoir s’en sortir.

Rappels

Historiquement, les proxy HTTP ont été mis en place afin d’accélérer les chargements des pages web. A une certaine époque l’acronyme WWW pouvait avoir pour signification « World Wide Wait ». La solution apportée à ce problème a été de mettre en cache les contenus au plus proche de l’utilisateur par le biais de proxy.

La gestion du cache HTTP doit être géré du coté du fournisseur de contenu, à savoir le serveur web. En théorie, ce dernier a autorité sur les données du site qui pourront être mises en cache ou non. Ces informations sont transmises dans les en-têtes HTTP par le biais de divers champs que nous ne détaillerons pas tous ici. Un champ particulièrement intéressant est la durée de rétention dans le cache.

Par défaut, Apache n’envoie pas d’informations quant à la mise en cache du contenu ce qui signifie donc qu’en théorie les données de notre site ne seront pas mises en cache. Dans notre situation, cela signifie que Squid ne met rien en cache tant que nous n’avons pas configuré Apache pour lui indiquer qu’il est possible de le faire.

Configuration d’Apache

Nous allons donc devoir paramétrer Apache pour utiliser les en-têtes contrôlant la mise en cache de nos pages web. Ainsi, notre serveur Squid pourra prendre une partie de la charge de notre serveur web et ainsi le soulager.

Le module Apache qui nous intéresse plus particulièrement est mod_expires. Son activation est simple et, dans le cas de Debian, il est packagé avec Apache. Il suffit donc de l’activer comme suit.

# a2enmod expires

# /etc/init.d/apache2 restart

Une fois ce module activé, nous allons pouvoir le configurer.

Configuration de mod _expires

Nous allons pouvoir configurer mod_expires par le biais de fichiers .htaccess comme il est possible de le faire pour bon nombre d’autres modules. Ce module nous permet de gérer assez finement la mise en cache des fichiers. La syntaxe est simpliste mais efficace. Si vous souhaitez obtenir une explication exhaustive dans la syntaxe et de ses fonctionnalités, je vous recommande de consulter la documentation.

Pour ce site, j’ai choisi la politique suivante de mise en cache.

ExpiresActive On
ExpiresByType image/gif « access plus 1 week »
ExpiresByType image/jpeg « access plus 1 week »
ExpiresByType image/png « access plus 1 week »
ExpiresByType text/css « access plus 1 days »
ExpiresByType application/x-shockwave-flash « access plus 1 hour »

Ensuite, c’est à vous de voir ce que vous voulez que Squid mette en cache ou pas en fonction des fonctionnalités de votre site.

Vérification

Afin de vérifier si tout fonctionne correctement, je vous invite à consulter les log d’accès à votre serveur Squid. Des lignes comportant « TCP_HIT » s’afficheront lorsque Squid servira des données du cache à la place d’Apache. Si vous n’avez que des « TCP_MISS », il doit probablement manquer un élément à votre configuration.

Au final, cette méthode permet d’accélérer significativement son site web et ainsi d’améliorer son référencement sur Google. Dans mon cas, le temps de chargement de ce site a été divisé par un facteur 2 à 3 ce qui est tout de même très intéressant. Des lecteurs m’ont fait remarquer qu’il existait une alternative plus moderne à Squid, Varnish qui permettrait de définir des politiques de mise en cache plus fine. Je vous laisse donc y jeter un coup d’œil !

Contexte

L’affichage de ce blog était relativement lent. Il pouvait mettre plus de 5 secondes pour s’afficher complètement ce qui n’est pas un temps d’affichage très bon. J’ai donc entrepris de trouver une solution à ce problème.

Ce site est hébergé sur une machine virtuelle Xen dont le système d’exploitation est OpenSolaris 2009.06. Elle est globalement assez lente car relativement peu de mémoire lui est alloué. De plus, la cohabitation d’Apache et de MySQL sur le même système ne favorise clairement pas les choses. Certains médisants diront que WordPress et/ou PHP sont des facteurs de lenteur. Ils auront raison mais je n’ai aucune intention d’utiliser autre chose que WordPress car c’est un réel plaisir à l’utiliser.

Un peu de théorie

Un proxy ou en Français « serveur mandataire » est un serveur qui se place entre le client et le serveur. Le client va interroger le proxy qui va à son tour interroger le serveur. Le serveur répondra au proxy qui, à son tour, répondra au client. Ceci est le fonctionnement le plus classique mais on peut placer un proxy dans nombreuses configurations et donner au proxy une intelligence supplémentaire.

Dans le cas de proxys HTTP(S) classiques, on y ajoute des mécanismes de cache afin d’économiser de la bande passante. On peut également y ajouter des fonctions de filtrage d’URL afin d’éviter la consultation de certains sites.

L’exemple d’application du proxy qui nous intéresse ici est le reverse proxy. Le client n’aura aucune connaissance de la présence d’un proxy et pensera qu’il s’agit d’un serveur HTTP comme un autre. Le proxy interrogera ensuite le serveur web et la requête sera renvoyée au client. Dans cette situation, la fonctionnalité de cache du proxy est très intéressante car elle permet d’éviter le traitement de certaines requêtes au serveur HTTP. On pourrait également utiliser le proxy couplé à plusieurs serveurs HTTP afin d’effectuer du load balancing et de la redondance.

Une autre VM

La première étape a été de trouver une machine supplémentaire afin de ne pas faire cohabiter la pile LAMP et Squid sur le même serveur. Dans l’absolu, ce n’est pas impossible mais lorsqu’on a un serveur déjà surchargé, ce n’est peut être pas la meilleure idée.

Étant donné qu’OVH vient de lancer son offre miniCloud, ce projet était une parfaite excuse pour la tester. Le prix de cette offre est vraiment très bas. Pour une VM de 256Mo de RAM, cela revient à 8,5€/mois. J’ai donc crédité 10€ sur mon compte. L’interface de gestion n’est pas la plus esthétique ni la plus rapide mais elle fait l’affaire.

En une petite dizaine de minutes, j’avais donc à ma disposition une machine virtuelle Debian Lenny 64-bits. Le réel inconvénient de l’offre d’OVH est que l’IP de la machine virtuelle change à chaque fois que vous l’arrêtez par le biais de l’interface de gestion.

L’installation de la pile LAMP est très simple et je ne la détaillerai donc pas ici. Il existe des masses incroyables de documentation à ce sujet.

Squid

L’installation de Squid est très simple. Je l’ai installé sur OpenSolaris à partir des dépôts Blastwave via pkgutil. Dans le cas de Debian, un apt-get s’occupera de tout ca pour vous.

Une fois installé, nous pouvons passer à sa configuration. La configuration du reverse proxy est la suivante :

http_port 80 accel defaultsite=www.antoinebenkemoun.fr
visible_hostname vm.antoine.fr
cache_peer 178.32.yy.xx parent 80 0 no-query originserver name=myAccel
acl all src 0.0.0.0/0.0.0.0
cache_peer_access myAccel allow all
acl our_sites dstdomain antoinebenkemoun.fr www.antoinebenkemoun.fr antoinebenkemoun.com www.antoinebenkemoun.com
http_access allow our_sites

Tout d’abord, on indique à Squid d’écouter les requêtes sur le port 80 et que le site que l’on va proxy-er est « www.antoinebenkemoun.fr ». Ensuite, on lui indique l’IP du serveur web où est réellement hébergé le site. Il est ensuite nécessaire de définir un certain nombre d’ACL qui sont ici assez génériques et tout à fait simples. Dans l’exemple, nous avons autorisé le reverse proxy pour 4 sites et nous avons autorisé toutes les IP à visionner le site.

Il est également possible d’utiliser d’autres options afin de mieux régler votre reverse proxy. L’ajout d’un « access log » va vous permettre de voir les pages qui sont consultés mais surtout si le contenu est envoyé par Squid ou par votre serveur LAMP. Il est également possible de régler la quantité de mémoire vive utilisé pour le cache de pages web. L’espace mémoire utilisé pour le cache sera donc alloué en plus de l’espace mémoire du programme principal.

cache_mem 20 MB
cache_access_log /opt/csw/var/logs/access.log

Le chemin pour l’access log est adapté à mon OpenSolaris mais à vous de l’adapter à votre distribution. Si vous êtes sur Linux, vous voudrez surement placer les logs quelque part dans /var/log/.

Au final, nous avons installé notre serveur Squid et l’avons configuré en mode reverse-proxy. Dans le billant suivant, nous verrons les modifications qu’il faut apporter à notre serveur Apache afin d’utiliser réellement la fonctionnalité de cache du reverse proxy.

Avant de rentrer dans le vif du sujet, la présentation que nous avons effectué est disponible sur Slideshare. L’affichage des animations est quelque peu fastidieux par le biais de la visionneuse Slideshare mais ca reste assez lisible. Il s’agit d’une présentation Keynote contenant assez peu de détails car la plupart du sujet a été traité à l’oral. Pour le détail, il faudra lire les articles de cette série de billets.

Tout d’abord, nous pouvons traduire le terme « Content Delivery Network » par « Réseau de distribution de contenu ». L’adaptation de ce terme en Français me semble tout à fait satisfaisante. J’utiliserais ce terme pour la suite des billets et les autres billets à venir. Je ferais une exception pour le titre mais ça c’est pour l’indexation Google.

Les réseaux de distribution de contenu ont été conçus pour répondre à des problématiques très concrètes rencontrées sur Internet. Lors de cette introduction, nous nous attacherons à identifier ces problématiques et à les détailler. Nous distinguerons deux types de problématiques : les nouvelles problématiques et les problématiques historiques.

Nouvelles problématiques

L’utilisation de l’Internet a beaucoup évolué depuis ces dix dernières années et ces évolutions ont amené de nombreuses nouvelles problématiques.

La première grande révolution est l’introduction de la vidéo dans le navigateur web. Ceci peut paraitre tout à fait « normal » aujourd’hui mais l’intégration de contenus vidéos était quelque chose de rare il y a une dizaine d’années. Le lecteur Real Player avait permis de faire les premiers pas vers cette intégration mais son utilisation était exceptionnellement pénible. Ceux qui l’ont utilisé se souviendront probablement du casse tête entre les version gratuites et payantes ainsi que les publicités associées. Cette révolution a permis au plus grand monde d’accéder à des quantités de contenu astronomiques.

La seconde révolution est le haut débit par le biais des technologies de transmission ADSL et câble. Chaque utilisateur connecté derrière la box de son fournisseur d’accès à Internet obtient ainsi la possibilité de récupérer des données à une vitesse particulièrement élevée. Aujourd’hui, la quasi totalité des accès ADSL/Câble classiques disposent de plusieurs Mégabits de débit.

La troisième révolution a été les réseaux sociaux. Dans l’absolu, les réseaux sociaux ne sont que des sites comme des autres. Leur particularité réside dans le fait que la quantité de contenu qui y est ajouté chaque heure est colossale. De plus, ces contenus sont consultés de manière régulière par de nombreuses personnes à longueur de journée.

Pour résumer, le contenu distribué sur Internet a largement grossi à cause de la vidéo mais les utilisateurs ont également la possibilité de le récupérer à des vitesses élevés. Au final, il était nécessaire de trouver un solution efficace et le moins cher possible car tous ses contenus sont accessibles gratuitement.

Problématiques historiques

Nous venons de voir un certains nombre de facteurs récents qui ont modifié l’utilisation de l’Internet. Nous allons maintenant nous intéresser aux problématiques qui ne sont elles pas récentes.

La première problématique est le coût de la mise en place des liaisons transocéaniques et transcontinentales. L’investissement initial est élevé et la maintenance sur ces câbles est exceptionnellement compliquée. Les procédés de fabrication des fibres ont été améliorés et leur utilisation a été optimisé mais il reste nécessaire de faire traverser l’océan par un navire câblier ou bien de creuser les trous pour enfouir les fibres. Cette problématique induit le fait que plus le trafic réseau parcourt de la distance, plus les couts sont élevés.

La seconde problématique est la vitesse de la lumière. Transcrit en des termes plus informatiques, la seconde problématique est la latence. Cette dernière est bornée inéluctablement par la vitesse de propagation d’un signal dans une fibre optique qui dépend de la vitesse de la lumière. Les utilisateurs veulent non seulement du contenu mais le veulent rapidement. La latence peut devenir un problème dans le cas de liaisons transocéaniques. Des chiffres donnés par Akamai évoquent une latence de 1,6 ms pour du contenu situé à 160 Km et une latence de 96 ms pour du contenu situé sur un autre continent.

Au final, ces deux jeux de problématiques s’additionnent et viennent compliquer la vision traditionnelle de la distribution de contenu sur Internet. Les réseaux de distribution de contenu ont été créé dans l’objectif de résoudre au mieux à toutes ces problématiques.

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

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.

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.

La méthode la plus simple consiste à utiliser les outils easy-rsa en ligne de commande. Ces outils simplifient réellement la tâche par rapport à l’utilisation directe d’OpenSSL. Le problème avec l’utilisation de ces outils est la nécessité d’interagir avec le terminal. Cet outil va vous demander bon nombre de renseignements tels que le pays, la ville, l’adresse email, etc. Cette interaction rend compliquée la création par lots de certificats.

Une méthode plus compliquée, mais plus efficace, consiste à adapter les scripts easy-rsa afin de rendre leur utilisation plus linéaire et non interactive afin qu’un script puisse les exécuter. De plus, j’ai souhaité donner la possibilité de spécifier la durée de validité du certificat au cas par cas, ce qui n’est pas possible par défaut.

Le premier script, build-key-batch, permet de créer une clé en spécifiant une durée de validité. Il n’y a qu’une toute petite modification qui permet de récupérer la durée de validité passée en argument.

#!/bin/sh

if test $# -ne 2; then
     echo « usage: build-key-batch <name> <duree> »;
     exit 1
fi

if test $KEY_DIR; then
     cd $KEY_DIR && \
     openssl req -days $2 -nodes -new -keyout $1.key -out $1.csr -batch -config $KEY_CONFIG && \
     openssl ca -days $2 -out $1.crt -in $1.csr -batch -config $KEY_CONFIG && \
     chmod 0600 $1.key
else
     echo you must define KEY_DIR
fi

Par défaut, easy-rsa nécessite d’exécuter le fichier vars dont le rôle est d’exporter un certain nombre de variables d’environnement utilisées par les scripts de génération de clé. Cela ne me convenait pas car je souhaitais exécuter un seul fichier contenant toutes les informations dont je pouvais avoir besoin. J’ai donc créé un script nommé build-batch qui contient toutes les options.

#!/bin/sh
if test $# -ne 2; then
     echo « usage: batch-build <name> <duree> »;
     exit 1
else
     # Definition des variables
     export D=`pwd`
     export KEY_CONFIG=$D/openssl.cnf
     export KEY_DIR=$D/keys
     export KEY_SIZE=1024
     export KEY_COUNTRY=FR
     export KEY_PROVINCE=XX
     export KEY_CITY=Paris
     export KEY_ORG= »Keeyyyy »
     export KEY_EMAIL= »$1″
     export KEY_CNAME=$1
     ./build-key-batch $1 $2
fi

Ce script nécessite une petite modification du fichier openssl.cnf présent dans le dossier easy-rsa qui est la suivante :

commonName = Common Name (eg, your name or your server\’s hostname)
commonName_max = 64
++ commonName_default = $ENV::KEY_CNAME

Le script a exécuter afin de générer un certificat est donc build-batch suivi de deux arguments qui sont le nom du certificat et la durée de validité. Vous pourrez ainsi générer des certificats pour OpenVPN simplement et efficacement sans nécessiter une intervention humaine.

Source : insights

Vous le savez sans aucun doute tous, Oracle a racheté Sun suite à de nombreuses négociations avec les différentes autorités notamment européennes. Sun est un grand groupe informatique relativement peu connu du grand public aujourd’hui mais qui a largement participé à l’expansion de l’informatique tel que nous la connaissons aujourd’hui. Les produits les plus connus de Sun sont la base de données MySQL, le système d’exploitation Solaris et la plateforme Java. Oracle est également un grand groupe dont le cœur de métier est la base de données dans toutes ses formes.

Annonces faites par Oracle

Dès l’annonce du rachat, Oracle a manifesté un fort intérêt pour Solaris contrairement aux intentions que certains ont pu lui prêter. L’annonce d’un investissement massif, supérieur à celui de Sun, dans Solaris a rapidement été évoqué. Le futur de Solaris n’a jamais été mis en doute. La réelle modification apportée par Oracle est la suppression de la gratuité de Solaris.  Ceci se comprend dans la mesure où Solaris est un système d’exploitation réellement orienté vers les infrastructures à très haute disponibilité. Qui dit haute disponibilité, dit coûts. C’est donc une évolution relativement logique pour viabiliser cet OS.

La gestion par Sun de Solaris faisait qu’il était possible pour une société de payer une souscription Solaris pour un seul serveur et ensuite de propager toutes les mises à jour sur tous leurs serveurs. Oracle a voulu, assez logiquement, supprimer cela en introduisant la notion de contrats équivalents sur tous les serveurs. De plus, Oracle a annoncé que toutes les fonctionnalités ne seraient pas incluses dans Solaris ce qui était déjà le cas à l’époque de Sun. Il s’agit cependant de fonctionnalités ultra-spécifiques. Le cheminement naturel est plutôt d’introduire les fonctionnalités OpenSolaris vers Solaris.

La situation d’OpenSolaris

Parlons désormais d’OpenSolaris. De la même manière que GNU n’est pas Linux, OpenSolaris n’est pas Solaris. OpenSolaris est à Solaris ce qu’est Fedora à Red Hat.

OpenSolaris est effectivement un logiciel libre bien que pas sous licence GNU/GPL.  Sur les mailing-list associées à ce projet, il a été fait une étude des éléments qui seraient à recréer si Oracle reniait OpenSolaris. Seul une centaine d’éléments non critiques seraient à revoir dont une bonne partie sont déjà en cours de réécriture.

Enfin une annonce !

L’erreur d’Oracle a surement été leur mutisme par rapport au futur d’OpenSolaris. Ceci est cependant terminé car Oracle sont sortis de leur silence et ont annoncé qu’il continueraient à soutenir ce projet. Je vous laisse consulter la présentation qui a été faite afin que vous puissiez vous faire votre propre idée.

Oracle is investing more in Solaris than Sun did prior to the acquisition, and will continue to contribute innovative technologies to OpenSolaris, as Oracle already does for many other open source projects

Oracle will continue to make OpenSolaris available as open source and Oracle will continue to actively support and participate in the OpenSolaris community

Toutes les annonces de la mort d’OpenSolaris sont fausses et basées sur le simple silence d’Oracle à ce sujet. De plus, ces fausses annonces ont été fortement relayées sur tous les sites d’informatique. Par contre, lorsqu’Oracle annonce le maintien du projet, l’annonce est pratiquement inaudible et invisible.