L’envers de la virtualisation, épisode 2

tech-presentation-2Lors du précédent article, j’ai introduit cette série d’articles par le portrait marketing de la virtualisation. Vous l’aurez sans doute compris que ce portrait se voulait ironique. L’ironie puise cependant ses origines dans la réalité. Les discours marketing sont souvent assez peu loin de ce que j’ai eu l’occasion de décrire.

Une boite noire qui fait tout

La virtualisation se vend actuellement sous forme de solutions « boite noire » qu’on installe sur un serveur standard. Cette configuration incite à faire penser qu’il est possible d’installer cette « boite noire » en mode Windows sans se poser la moindre question. Lorsque vous installez une plateforme de virtualisation, l’hyperviseur de virtualisation est la couche applicative la plus critique de votre infrastructure. Vous comprendrez donc aisément l’importance et la criticité de ce composant applicatif.

L’installation d’un hyperviseur de virtualisation doit être la plus standard possible. Vous allez sans aucun doute être amené à migrer des machines virtuelles d’un serveur à un autre. Il faut donc que la couche la plus basse soit standardisée. De plus, il est nécessaire de limiter au strict nécessaire les fonctions exécutées par la couche de virtualisation afin de limiter les possibilités de bugs.

On l’installe et on l’oublie

Au cours de l’exploitation de votre plateforme, vous serez sans aucun doute amener à rencontrer des problèmes liés à la couche de virtualisation. Penser que la virtualisation est quelque chose de parfaitement transparent est parfaitement faux. Il est nécessaire de maintenir cette plateforme. Des actions de maintenance classique sont l’analyse des performances afin de déterminer si votre plateforme est correctement dimensionnée ainsi que l’analyse des fichiers de logs.

Tous les défauts inhérents à un système d’exploitation peuvent se retrouver au niveau des couches de virtualisation. Il n’y a pas de magie spécifique qui tendrait à rendre parfait une plateforme de virtualisation. Il est nécessaire d’y porter un regard attentif et régulier.

Tout marche tout seul

Cette affirmation peut être vraie. Cependant, la limite de sa véracité se limite à la survenue du premier problème lié à la couche de virtualisation. Les problèmes vont avoir besoin de personnes pour se résoudre. Les problèmes de couche de virtualisation ne sont pas forcément simples. Il est donc nécessaire d’avoir du personnel formés à la virtualisation qui connaissent les spécificités de cet outil ainsi que son fonctionnement.

Au final, la virtualisation est une technique informatique exceptionnelle qui s’implante avec succès dans les infrastructures actuelles. Il est cependant nécessaire de prévoir soigneusement l’installation des couches de virtualisation afin d’assurer une homogénéité et d’éviter de nombreuses surprises en cas de défaillance. Il est également nécessaire de prévoir et prendre le temps d’analyser le fonctionnement quotidien de cette couche de virtualisation afin de s’assurer de sa santé et de prévoir les évolutions. De plus, une couche de virtualisation n’est pas un système d’exploitation comme un autre et nécessite une formation spécifique.

Configuration réseau d’OpenSolaris

solarisJe vous ai déjà fait une présentation succincte de Solaris et introduit la prise en main d’un tel système d’exploitation. Au fur et à mesure que je découvre, de mon coté, OpenSolaris, je rencontre différents problèmes. Un problème assez handicapant que j’ai rencontré est la configuration réseau.

Lorsque j’ai monté ma machine virtuelle OpenSolaris, j’ai fait la configuration réseau à la main rapidement via l’utilitaire ifconfig. Je ne représenterais pas cet utilitaire dans ce billet. Son fonctionnement sous Solaris est fortement similaire à son fonctionnement sous Linux. L’utilitaire route fonctionne de manière similaire pour l’ajout de routes. Il est cependant différent dans la mesure où il ne permet pas l’affichage de la table de routage via la commande route -n. Afin d’afficher la table de routage, il est nécessaire d’exécuter la commande netstat -rn.

La problématique de ce type de configuration est que la configuration n’est pas conservée après un redémarrage du système d’exploitation. Nous allons donc nous intéresser plus spécifiquement à la configuration pérenne des interfaces réseau en IP statique. La configuration se fera via le module physical:default.

Tout d’abord, vous allez devoir déclarer le nom d’hôte de votre machine. Vous remplacerez xnf0 par le nom de votre interface réseau.

echo « hostname »> /etc/hostname.xnf0

Ensuite, on sauvegarde le fichier hosts d’origine et on y insère les noms d’hôte de votre machine.

echo « 127.0.0.1 localhost »> /etc/inet/hosts

echo « 10.0.0.3 antoinebenkemoun.fr »>> /etc/inet/hosts

Nous allons ensuite spécifier le masque de sous-réseau lié à cette interface.

echo « 10.0.0.0 255.0.0.0 »>> /etc/inet/netmasks

Il nous reste plus qu’à préciser la route par défaut.

echo « 10.0.0.1 »> /etc/defaultrouter

La configuration de l’interface est désormais terminée. Il ne nous reste plus qu’à vérifier que les bon services sont activés. Nous devons activer le service physical:default et désactiver physical:nwam. Ce deuxième service est un doublon du premier, il ne faut donc en activer qu’un seul.

svcadm disable svc:/network/physical:nwam

svcadm enable svc:/network/physical:default

Afin de faire prendre en compte les modifications d’interface réseau, il est nécessaire de redémarrer le service physical:default.

svcadm restart svc:/network/physical:default

Le tour est joué ! Je pense que ce billet devrait être utile à certaines personnes démarrant sous Solaris et venant du monde de Linux. Dans tous les cas, il me sera utile pour future référence.

L’envers de la virtualisation, épisode 1

tech-presentation-2J’ai eu l’occasion d’évoquer les nombreux mérites de la virtualisation dans ce blog. La virtualisation est un des « buzzword » très à la mode actuellement. On en parle en long, en large, en travers et en profondeur (rien que ca …). Je n’évoquerais pas le « cloud computing » dans cet article car j’aurais l’occasion d’évoquer le sujet ultérieurement.

A en croire les louanges faites de la virtualisation, il serait quasiment possible de croire qu’il s’agit du paradis de l’informatique, la solution pour toutes les dominer. Dans un premier épisode, je dresserais le tableau qui est dressé par les commerciaux de produits de virtualisation. Dans un second épisode, je m’attacherais à coller plus à la réalité. Cet article se veut ironique au cas où vous auriez un doute.

En route vers le paradis

La virtualisation présente de nombreux avantages et permet de donner un nouveau souffle aux architectures informatiques. Ceci se fait essentiellement à travers la mutualisation des équipements physiques. Cette mutualisation des équipements permet donc des réductions de coûts. Vous allez juste devoir rajouter une petite « boite noire » qui se maintient automatiquement et qui permet de donner une flexibilité incroyable à votre infrastructure.

Vous allez pouvoir remplacer votre baie de serveurs physiques ayant chacun leur utilité par un petit nombre de serveurs plus puissants dotés d’une plateforme de virtualisation. Cette affirmation est exceptionnellement alléchante mais ne présente que le point de départ et le point d’arrivée. Le chemin entre les deux n’est pas sans embuche et ne s’emprunte pas aveuglément.

Vous allez pouvoir économiser de l’argent au niveau du stockage car plus les disques sont volumineux plus le prix au gigaoctet est faible. Vous allez peut être même pouvoir gagner en redondance car vous aurez plusieurs serveurs. Vous allez économiser au niveau du réseau car vous aurez besoin de moins de ports réseau.

Les nouvelles machines que vous allez acheter vont être des monstres de puissance et donc théoriquement vous aurez plus de puissance et de rapidité. De plus, vous avez lu de nombreux articles sur la virtualisation qui vous ont démontré que les performances d’un OS virtualisé sont pratiquement identiques à celles d’un OS natif. Que de bonheur !

Au final, voici un bon nombre de clichés que nous rencontrons tous les jours autour de la virtualisation. Je vous donne rendez-vous pour le second épisode qui s’attachera à donner du réalisme à toutes ces promesses.

Premiers pas sur Solaris ou OpenSolaris

solarisLors d’un précédent article, j’ai eu l’occasion de vous présenter dans les grandes lignes le système d’exploitation Solaris. Je vous ai fait une petite démonstration de tous les avantages que pouvait présenter un passage vers ce système d’exploitation. Entre temps, j’ai eu l’occasion de passer ma machine virtuelle Xen sous OpenSolaris en utilisant le processus évoqué précédemment. Je vais donc, à travers, cet article faire un petit retour d’expérience sur une première mise en place et utilisation d’OpenSolaris.

Solaris ou OpenSolaris ?

La première question que l’on se pose lorsqu’on souhaite passer à Solaris est « Dois-je choisir Solaris ou OpenSolaris ? ». Avant de pouvoir répondre à cette question, il va falloir distinguer les deux variantes. OpenSolaris n’est pas forcément beaucoup plus open source que Solaris étant donné que les deux variantes disposent plus ou moins des mêmes applications.

OpenSolaris est la version « communautaire » de Solaris. Pour faire une comparaison simpliste, OpenSolaris est à Solaris ce qu’est Debian Sid à Debian Lenny. De toute manière, les deux variantes sont disponibles gratuitement sur Internet. Une différence notable est que vous n’aurez les mises à jour de sécurité Solaris 10 que 6 mois après leur publication alors que vous aurez celles d’OpenSolaris immédiatement.

Si vous venez du monde Linux, je vous conseille fortement OpenSolaris car vous aurez plus de repères que dans Solaris.

L’installation

Je vous préviens d’entrée de jeu, OpenSolaris risque de vous décevoir à l’installation. En effet, il est nécessaire de passer par une interface graphique pour l’installer. Il faut donc 512 Mo de RAM au moins pour pouvoir l’installer. Je sais que cela va frustrer certaines personnes mais il semble un peu simpliste de s’arrêter à un tel détail. Si vous souhaitez effectuer l’installation sans interface graphique, vous pourrez toujours vous pencher sur Solaris. De toute manière, l’interface graphique est très simple à désactiver.

L’installation se déroule de manière tout à fait conventionnel avec le traditionnel « Suivant ». Je vous conseille fortement de choisir le système de fichier ZFS même si vous avez tout de même la possibilité de rester sur UFS (Unix File System). Je n’ai pas eu de difficulté particulière et je pense que vous ne devrez pas en avoir non plus.

Interface en ligne de commande

Lorsque vous avez démarré OpenSolaris, vous allez probablement supprimer le démarrage de l’interface graphique. Ceci se fait via le SMF de manière tout à fait simple. Pour lister les services, vous pourrez utiliser la commande svcs. Pour activer ou désactiver des services, vous pourrez ensuite utiliser svcadm disable/enable. Si vous cherchez les scripts init.d, il n’y en a que très peu et c’est normal. SMF remplace les scripts init.d rappellez-vous.

Vous risquez d’être assez vite frustré par le shell proposé par défaut. Le shell par défaut dans Solaris est csh. Si vous vouliez découvrir un shell utilisé par les dinosaures, vous trouverez votre bonheur. Sinon, je vous conseille de passer directement à bash en tapant la commande bash tout simplement. Vous pourrez également simplement installer zsh.

L’utilisation de vim est assez rudimentaire. Il va falloir retourner aux bases car bon nombres de raccourcis ne sont pas présents. Je ne me l’explique pas mais autant que vous soyez prévenus car c’est assez dissuasif.

Commandes qui sauvent la vie

Je vous ai déjà prévenu, lorsque vous passez à Solaris vous perdez tous les jolis automatismes que fournissent les distributions Linux standards. Le meilleur exemple est la commande halt qui disparait. Pour éteindre votre machine, il faudra forcer le run-level 0 via la commande init 0. Pour rebooter votre machine, il faudra forcer le run-level 6 via la commande init 6. Comme vous pouvez le constater, pour utiliser Solaris, il faut une connaissance approfondie d’Unix ou bien la volonté de l’acquérir.

Au final, je pense avoir fait un rapide retour d’expérience de la prise en main d’OpenSolaris/Solaris. Vous pouvez penser qu’il s’agit d’un Unix préhistorique étant donné des mécanismes assez compliqué mis en place. Vous avez cependant pas tord sur certains aspects mais vous avez totalement tord sur d’autres aspects. Je pense que les cotés « préhistoriques » sont composés par les nouveautés. Je pense également possible qu’il est possible de faire abstraction des ces problèmes et de s’adapter.

De la différenciation hyperviseur type 1 / type 2

tech-presentation-2A travers cet article, je souhaiterais exposer et argumenter mon point de vue sur les appellations d’hyperviseur qui fleurissent un peu partout sur Internet. Ceux qui suivent régulièrement ce blog doivent avoir une petite idée de mon avis sur cette appellation. Je vais essayer d’exposer mon point de vue de manière équilibrée et argumentée. Il s’agit donc ici d’un billet d’opinion.

Vous avez surement dû voir sur divers sites web l’appellation hyperviseur type 1 et hyperviseur type 2. Je ne connais pas l’origine des ces termes. Je soupçonne cependant fortement que ces deux termes soit d’origine marketing.

Note : Cet article a été publié sur le blog Orange Business Service Virtualisation le 3 Novembre 2009.

Qu’est ce qu’un hyperviseur ?

Tout d’abord, je vais m’attacher à exposer les différentes définitions de la notion d’hyperviseur. Wikipedia France nous donne la définition suivante.

En informatique, un hyperviseur est une plate-forme de virtualisation qui permet à plusieurs systèmes d’exploitation de travailler sur une machine physique en même temps.

Cette définition semble particulièrement large. Elle implique l’équivalence entre hyperviseur et application de virtualisation. Je définirais un « composant de virtualisation » en tant que n’importe quel composant applicatif permettant d’exécuter plusieurs systèmes d’exploitation sur une même machine physique. Il y a donc bien équivalence entre les deux définitions.

Qu’est ce qui définit techniquement un hyperviseur ?

Comme vous le savez, il existe de nombreuses techniques de virtualisation. Toutes ces techniques de virtualisation proposent une diversité assez large. Il me semble donc assez réducteur des les regrouper toutes sous le nom d’hyperviseur d’autant plus que l’appellation « composant de virtualisation » existe déjà.

La définition technique d’un hyperviseur est mieux illustrée à travers le fonctionnement de la paravirtualisation. Dans le cas de la paravirtualisation, l’hyperviseur est l’interface primaire et exclusive des ressources physiques principales. La notion d’hyperviseur se justifie par le fait que le noyau est historiquement le « superviseur ». Cette notion de « superviseur » est issue du mode « superviseur » des processeurs x86 car il s’agit du noyau qui va gérer les interruptions en mode superviseur. En toute logique, nous avons donc l’hyperviseur qui gère les superviseurs.

Dans le cas de la virtualisation de systèmes d’exploitation non modifiées, le « composant de virtualisation » se situe au dessus d’un système d’exploitation et donc d’un noyau. Nous avons donc une contradiction au niveau des appellations vu que l’hyperviseur va être géré par le « superviseur », à savoir, le noyau. Il y a donc une incohérence. Je vous remets, pour rappel, le schéma comparant paravirtualisation et virtualisation totale.

virtus

Quid des types d’hyperviseur

Afin de palier à cette contradiction, une différenciation a été faite et l’appellation « hyperviseur type 1 » et « hyperviseur type 2 » a vu le jour. Cette appellation ne répond cependant pas à la contradiction soulevée précédemment.

Pour rappel, un hyperviseur de « type 1 » est un hyperviseur s’exécutant directement sur la plateforme matérielle, comme dans le cas de la paravirtualisation. Un hyperviseur de « type 2 » est un hyperviseur s’exécutant par dessus un système d’exploitation invité.

Pour résumer cet article, je pense que l’appellation d’hyperviseur n’est pas adaptée aux solutions de virtualisation s’exécutant au dessus d’un système d’exploitation invité. Je pense que l’appellation « application de virtualisation » serait plus adaptée et correspondrait plus à la réalité. Je tiens également à soulever la question essentielle de cet article, peux-t’on considérer un couple système d’exploitation et application de virtualisation en tant qu’hyperviseur ? A partir de quel seuil un couple OS/application de virtualisation peut-il être considéré en tant qu’hyperviseur ?

Installation d’OpenSolaris 2009.06 sur Xen

solaris-logoDans un précédent billet, nous avons vu l‘installation de Xen ainsi que sa configuration réseau. Vous pouvez soit installer des domU Linux ce qui est particulièrement simple, voire magique, avec l’outil xen-tools. Mais étant donné que vous avez été convaincu par ma présentation de Solaris, vous allez vous lancer dans l’installation d’OpenSolaris sur votre plateforme de virtualisation Xen.

L’installation d’un domU OpenSolaris par dessus un dom0 OpenSolaris est particulièrement simple et je n’en parlerais pas ici. Nous allons nous intéresser à l’installation d’un domU OpenSolaris par dessus un dom0 Linux. Les raisons de ceci sont un plus grand challenge et la conservation des avantages d’un dom0 Linux. Cette installation n’est pas des plus simples et nécessite d’y passer un peu de temps. Nous supposerons que vous êtes en 64-bits car la quasi-totalité des plateformes s’exécutent aujourd’hui en 64-bits.

Préparation de l’installation

Pour pouvoir installer OpenSolaris, il va nous falloir OpenSolaris. Jusqu’ici rien de trop compliqué. Nous allons nous placer dans le répertoire /xen pour effectuer l’installation. Je vous laisse donc télécharger l’ISO d’OpenSolaris dans ce répertoire.

Nous allons avoir besoin de divers fichiers dans cet ISO, nous allons donc le monter en local.

cd /mnt && mkdir osol

mount -o loop /xen/osol-0906-x86.iso /mnt/osol

Ensuite, nous allons récupérer les fichiers dont nous allons avoir besoin. Ces fichiers sont un kernel minimaliste afin de pouvoir booter l’installation.

cp /mnt/osol/platform/i86xpv/kernel/amd64/unix /xen/

cp /mnt/osol/boot/x86.microroot /xen/

Nous devons ensuite créer le disque sur lequel le système d’exploitation va s’installer. Vous pouvez soit créer une partition LVM soit créer un image disque. Pour le LVM, je vous réfère à l’excellent tutoriel présent sur le site de Gayux. Pour créer une image disque, vous pourrez utiliser la commande dd comme suit. La commande suivante crée une image de 10Go.

dd if=/dev/zero of=/xen/disk.img bs=1024k count=1 seek=10000

Configuration du domU

Vous allez ensuite devoir paramétrer le domU. Les fichiers de configuration de domU se trouvent par défaut dans le répertoire /etc/xen. Vous pourrez y créer un fichier .cfg qui contiendra les informations suivantes. En ce qui concerne les pré-requis de l’installation, vous allez avoir besoin de 512Mo de RAM pour l’installation. Vous pourrez descendre en deçà par la suite mais l’installation nécessite autant de RAM étant donné qu’il est nécessaire d’exécuter Gnome. Vous devez donc créer le fichier de configuration suivant. J’ai choisi opensolaris.cfg.

name = « opensolaris-cest-trop-bien »
vcpus = 1
memory = 512
kernel = « /xen/unix »
ramdisk = « /xen/x86.microroot »
extra = « /platform/i86xpv/kernel/amd64/unix -B console=ttya,livemode=text »
disk = [‘file:/xen/osol-0906-x86.iso,6:cdrom,r’,’file:/xen/disk.img,0,w’]
vif = [ »]
on_shutdown = « destroy »
on_reboot = « destroy »
on_crash = « destroy »

Vous pouvez ensuite exécuter la VM que vous venez de créer avec la commande suivante :

xm create -c /etc/xen/opensolaris.cfg

Installation

Vous allez ensuite pouvoir démarrer l’installation via le mode ligne de commande jusqu’à ce que vous arriviez à un invite de commande standard. Vous allez pouvoir vous logguer via le compte jack et le mot de passe jack. Logique ? Non, je suis entièrement d’accord.

Nous allons donc ensuite devoir exécuter un serveur VNC afin de pouvoir faire l’installation en mode graphique. Je sais que ca vous chagrine de devoir faire une installation en mode graphique mais OpenSolaris ne fait pas d’installation en mode console. Ne vous inquiétez pas, vous allez pouvoir dégager Gnome dès l’installation finie. Avant de pouvoir activer VNC, il va vous falloir configurer votre interface réseau. Si vous êtes en DHCP, cela devrait fonctionner automatiquement. La procédure à suivre pour l’activation du serveur VNC est la suivante :

mkdir .vnc

cp .Xclients .vnc/xstartup

vncserver

Vous pouvez ensuite vous connecter en VNC directement à l’IP en question. Vous allez ensuite pouvoir faire l’installation via le mode graphique. Avant de redémarrer, vous allez devoir récupérer une petite info.

pfexec zdb -vvv rpool | grep bootfs

Vous allez récupérer une information du type « Bootfs = CHIFFRE« . Retenez bien ce numéro ou notez le sur un bout de papier ou tout autre surface.

Exécution

Il est temps de faire un petit résumé de ce que nous avons fait jusqu’à présent. Nous avons préparé l’installation afin de pouvoir exécuter notre installation d’OpenSolaris. Nous avons exécuter le domaine d’installation et mis en place un serveur VNC pour pouvoir y accéder en mode graphique. Dans ce mode graphique, nous avons fait les étapes d’installation. Il nous reste donc plus qu’à exécuter l’OS que nous venons d’installer. Pour se faire, nous allons devoir apporter quelques modifications à notre fichier de configuration.

name = « opensolaris-cest-trop-bien »
vcpus = 1
memory = 270
kernel = « /xen/unix »
ramdisk = « /xen/x86.microroot »

extra = ‘/platform/i86xpv/kernel/amd64/unix -B console=ttya,zfs-bootfs=rpool/CHIFFRE,bootpath= »/xpvd/xdf@0:a »‘
disk = [‘file:/xen/osol-0906-x86.iso,6:cdrom,r’,’file:/xen/disk.img,0,w’]
vif = [‘ip=xx.xx.xx.xx,mac=00:16:3E:FF:AB:AB’]
on_shutdown = « destroy »
on_reboot = « destroy »
on_crash = « destroy »

Vous allez ensuite pouvoir exécuter votre VM et profiter de votre nouvelle installation d’OpenSolaris !

Au final, cette installation est certes un peu fastidieuse mais permet tout de même d’installer OpenSolaris sur un dom0 Linux. Si vous avez des remarques par rapport à ce tutoriel, vous pouvez toujours me contacter via l’onglet prévu à cet effet. Amusez-vous bien sous Solaris !