XenCenter on Zwindler's Reflection

[Test] XenServer 5.6, du solide mais de petites déceptions

Fri, 10 Dec 2010 17:05:42 +0000

Dans l’article précédent relatant la théorie et l’installation de XenServer, j’avais fais deux constats :

XenServer ce n’est pas Xen (on est pas loin d’un ESXi pour toute la couche de présentation, l’OS qui sert d’hyperviseur, et l’architecture de type Serveurs d’un côté, console de gestion unifiée de l’autre)
XenServer ça s’installe TRES vite et TRES simplement.

N’allez pas croire que je sous-entend que c’est vraiment un avantage par rapport aux concurrents. On s’en sort très bien pour installer un ESX(i) ou un Hyper-V sans aucune difficulté (il faut avoir une culture « Systèmes », quand même!) et en peu de temps, mais bon, j’ai quand même été bluffé.

Contrairement à d’autre blogs spécialisés de gens qui peuvent se permettre de présenter en détails toutes les fonctionnalités des licences payantes, je me contenterai de présenter ce que je peux voir, avec ma pauvre petite licence Express.

A partir de maintenant, on entre dans le vif du sujet, l’utilisation jour après jour des serveurs, piloté par l’intermédiaire du XenCenter.

Première chose à faire une fois le XenServer installé sur le serveur, et XenCenter sur la machine d’administration, c’est de lier le serveur au XenCenter. Ceci se fait de manière assez triviale en cliquant sur les boutons qui vont bien (Add New Server »).

De la même manière, la gestion des fermes de serveurs (on appèle ça des Pools chez Citrix) peut se faire assez facilement, en créant une ferme et en y affectant des serveurs. Attention cependant, j’ai cru comprendre qu’il fallait des serveurs identiques au sein d’une même ferme pour que cela fonctionne bien (même versions, ça c’est sûr, même hardware, je n’en suis plus certain mais ça me parait prudent).

Pour chaque serveur ou Pool, il vous est donc possible en très peu de clics de créer des VMs, mais aussi des Storages. Ce qui est plutôt chouette selon moi c’est qu’au dela des divers moyens de stocker des disques virtuels sur le réseaux (NFS, iSCSI, HBA, Advanced StorageLink), il est possible de monter des partages contenant vos isos en NFS et en CIFS (contre juste NFS pour VMware, aux dernières nouvelles). Même s’il n’est pas bien compliqué de monter un partage NFS pour un admin système, il peut être pratique d’avoir juste à créer un partage Windows depuis la machine d’administration (pour les archi de type maquette par exemple) et soyons honnête, ça ne coute pas cher à ajouter comme fonctionnalité!

L’affichage des VMs présentent sur le serveur se fait d’une manière assez classique : Un bandeau menu avec toutes les fonctionnalités disponibles, un volet de gauche qui liste les serveurs et leurs VM et un volet central qui se découpe enonglets permettant de gérer de façon plus spécifique l’élément sélectionné.

Par exemple quand on sélectionne une serveur ou un pool, on dispose d’une liste des VMs hébergées que l’on peut trier par nom, usage CPU, usage mémoire, moyenne d’accès disque ou réseau, adresse IP, uptime… Simple mais efficace. Chaque élément dispose d’un onglet Performance, qui retrace l’évolution de la métrologie dans le temps (temps relativement court dans la version Express). Un onglet Users permet de joindre un domaine AD pour accorder des droits sur les VMs, et un onglet Log permet de tracer les opérations du serveur.

Dans l’ensemble, tout ce qui est nécessaire au bon fonctionnement d’un serveur bien dimensionné et dans des conditions normale d’utilisation me semble vraiment bien ficelé. Pour tout vous dire, ma machine ainsi que ses VMs tournent depuis plusieurs mois sans problèmes, et je l’ai mise à jour, j’ai supprimé des VMs, j’en ai créé d’autre, … (oui, je n’écris l’article que maintenant)

Mais comme je l’ai dis dans le titre, tout n’est malheureusement pas rose. XenServer est clairement un produit très aboutis et qui propose gratuitement certaines fonctionnalités bien utiles (voire vitales? La gestion de serveurs en ferme et le LiveMotion gratuit, c’est vrai que ça fait envie) que VMware ne propose qu’avec un vCenter (et la licence qui va bien), et des caractéristiques techniques de même niveau sur de nombreux points (pour un avis un peu moins partial que les sites des éditeurs, voir la comparaison de VMGuru (lien mort, j’utilise Internet Archive)). En grattant un peu, on voit bien que certains points sont plus aboutis chez VMware.

La liste des systèmes d’exploitation invités supportés, par exemple. Là où j’ai eu très peu de difficultés à créer des VMs avec des OS peu courants sous ESXi, on sent bien que XenServer est plus réticent. La liste des OS supportés et vraiment faible actuellement (v5.6), proposant Windows, du Debian et du RedHat (et autres dérivés artificiels pratiquement identiques).Et encore, certaines versions uniquement (il arrive que les noyaux ‘de base’ de certaines versions récentes supportent mal XenServer)!

Autre déconvenue, quand on clique sur l’onglet Memory d’un serveur, on se retrouve malheureusement face à un message du type « Upgrade XenServer to enable Dynamic Memory Control ». Oui, la mémoire n’est pas attribuée dynamiquement. Il est donc très important de bien gérer sa RAM. J’ai très vite atteint mes 8 Go sur ma machine de test!

De la même façon, le Thin Provisionning pour l’espace disque semble ne pas être aisé à mettre en place avec la version 5.6 (et pas possible sur la 5.5 sauf tour de passe passe de sioux), qui devra être attribué avec parcimonie et justesse (la taille des disques peut être modifiée une fois les VMs éteintes, mais attention à ce que les OS le supportent!). Cependant il semblerait que le FP1 de la 5.6 corrigera bientôt ce problème (A l’installation… je pense que c’est trop tard une fois installé).

Et enfin, peut être un problème mineur la plupart du temps, mais l’utilitaire de customisation de la machine virtuelle est beaucoup plus complet sous ESX(i). Sous XenServer, c’est même minimaliste. On peut modifier les composants vitaux (CPU, HDD, RAM, cartes réseaux), mais guère plus. C’est rare, mais pourtant des fois c’est utile de pouvoir définir rapidement le nombre de ports COM de la machine virtuelle…

Voilà donc un petit tour d’horizon de mon ressenti…

[Test] Premiers pas sous XenServer & co : la théorie et ce que j’en attendais

Wed, 06 Oct 2010 17:32:33 +0000

Et oui, je fais des infidélités à VMware. Je ne vous l’avais pas dis, mais ça fait un moment déjà que j’ai arrêté de jouer sous ESXi. Je me suis lassé de devoir bidouiller pour pouvoir faire fonctionner ESXi sur du matériel non supporté, de devoir bidouiller pour trouver des workaround pour éviter les limitations de la version gratuite.

Pour être parfaitement honnête, la goûte d’eau a été le fait que ma carte réseau fonctionnait très mal (à cause du fait que j’utilisais un pilote équivalent à première vue, mais pas adapté en réalité). Sous Windows, certaines cartes virtuelles (E1000 et Flexible) ne fonctionnaient pas, et sous FreeNAS, c’était carrément impossible de faire fonctionner le réseau. Après avoir tenté d’autres OEM modifiés avec d’autres pilotes réseau, j’ai fini par abandonner (temporairement? le temps d’acheter du matériel plus pro, peut être?).

Après avoir passé pas mal de temps à étudier les concurrents, je me suis mis en tête d’installer XenServer, en espérant que mon matériel soit mieux supporté. Et je n’ai pas été déçu…

Commençons par le commencement, un peu de théorie. J’ai connu XenServer en faisant des recherches sur Xen, le paravirtualiseur libre. Depuis quelques temps, XenSource a été vendu à Citrix, qui est parti de cette base pour faire sa propre solution de virtualisation.

Les architectures de ce type fonctionnent de la façon suivante : Les diverses machines virtuelles fonctionnent au DIRECTEMENT au dessus du matériel (domU dans la terminologie Xen). Cependant, comme un seul OS peut avoir le droit d’utiliser le matériel, les ressources disponibles sont distribués à l’essemble de VMs par un OS un peu spécial, à mis chemin entre une machine virtuelle et un OS hôte (le dom0). Il s’agit souvent un noyau linux modifié, installé sur l’OS hôte initial de la machine.

La GROSSE différence entre les hyperviseurs qui font de la « virtualisation complète » (VMware) et la paravirtualisation tient du fait que dans ces derniers, les machines virtuelle non privilégiées sont « conscientes » d’être des machines virtuelles, et font donc appel au chef d’orchestre dès qu’elles ont besoin d’une ressource.

Pour éclaircir un peu mes propos, je vous propose un graphique de wikipedia, tiré de l’article parlant de Xen (ici).

Mais ce fonctionnement n’est pas aussi idéal qu’on pourrait le penser. Les noyaux de ces VMs doit être modifiés pour permettre cette « conscience ». Du coup, avec Xen, c’est surtout les noyaux linux qui fonctionnaient le plus souvent avec Xen, les sources de Windows (ou autres) étant beaucoup moins accessibles (Même si des versions récentes de Xen n’ont plus ces limitations, mais pour ne pas vous embrouiller, je n’en parlerai pas).

A l’opposé, VMware est (historiquement) plutôt partisan d’une autre approche de la virtualisation : la virtualisation complète, et plus récemment avec un hyperviseur. Contrairement à la paravirtualisation, les machines virtuelles ne sont pas directement au-dessus du matériel, elles sont séparées de celui-ci par une fine couche logicielle (l’hyperviseur) qui se charge de distribuer les ressources. L’avantage de cette technique est que les machines virtuelles n’ont alors pas besoin d’être consciente de leur virtualisation, et donc n’ont pas besoin d’un noyau modifié. L’inconvénient est que théoriquement, les performances sont un peu moindres, à cause de « l’empilage ». De ce que j’en ai compris, ce choix technique est surtout poussé par les premières versions des serveurs VMware, qui ressemblait pas mal à des émulateurs, à installer au-dessus d’un serveur Windows (VMware GSX & VMware Server 2).

Mais assez de théorie, passons à du tangible!

Pour découvrir XenServer, j’ai bêtement cliqué sur un lien nous vantant les mérites de XenDesktop (lien mort). Parce que OUI, pour tenter de prendre des parts de marché à VMware, Citrix est prêt à vous donner gratuitement :

Le serveur lui-même (XenServer, en version 5.5, même si j’utilise la 5.6, après l’avoir mis à jour)
Le poste de pilotage (XenCenter)
Les ISOs contenant les programmes nécessaires pour monter un VDI (XenDesktop), c’est-à-dire la distribution de postes de travail comme un service (jusqu’à 10 utilisateurs, avec la plupart des fonctionnalités, dont les plus utiles).

La première chose qu’on peut dire, c’est qu’on n’est pas vraiment perdu. Citrix propose une infrastructure proche de celle de VMware, avec des serveurs pilotés conjointement par un vCenter, contrairement à Xen qui se pilotait directement depuis le serveur, sans passer par l’intermédiaire d’un poste de pilotage. Vous aurez peut-être remarqué que les noms sont également très proches, par pure coïncidence certainement ;-).

Après avoir rempli quelques informations sur moi-même sur le site de Citrix, j’ai pu télécharger l’archive contenant le tout, puis commencer l’installation. Pour rappel, je dispose d’un PC de bureau qui fonctionne avec un I7 et 8Go de RAM pour la partie serveur, et un portable qui me sert de XenCenter.

Pour ce qui a été de l’installation du serveur en elle-même j’ai trouvé tout ça très intuitif. A force d’installer des distrib Linux, on finit par être habitué au beau menu texte tout bleu! Pour ceux qui voudraient plus de précision, voici un walkthrough des plus complets ici. En quelques minutes, XenServer était installé, configuré, prêt à l’emploi.

Mais ce qui choque le plus, une fois que notre XenServer a passé le boot, c’est la console de configuration…

Remplacez le bleu par du jaune, et le noir par du gris… Ça ne vous rappelle rien? Et oui, vous aurez bien sûr reconnu l’interface de configuration de VMware ESXi… Enfin bon, du coup ce n’est pas dur de s’y retrouver. D’autant plus qu’il n’y a pas vraiment de différences d’utilisation entre cette console et celle de ESXi (un peu plus fournie pour XenServer), car elle ne vous servira qu’à configurer le strict minimum, puisque le gros de l’utilisation se fera depuis le XenCenter.

Léger avantage, peut être, XenServer propose un accès à la console direct, et non pas camouflé comme VMware. J’ose donc en déduire que l’accès à la console est « autorisé », même si probablement pas supporté, au même titre que la Technical Console de VMware (l’ex « hidden console »). Vous pouvez aussi avoir un aperçu de la charge utilisée par vos VMs, mais bon, tout ça est un peu superflux une fois qu’on a ajouté l’hôte au sein du poste de commande, je trouve.

Ce qui est intéressant, ce n’est pas l’interface graphique, mais bien ce qu’il y a dessous. Et bien justement, en dessous, on est très proche d’un ESX ou d’un ESXi… Quand on explore la console, on se rend compte qu’on a affaire à un Redhat modifié pour être le plus léger possible. Alors « OUI », il s’agit ici d’un dom0, au sens OS privilégié du terme chez XenSource, mais bon, au final, on se rend compte que ce que notre XenServer fait, c’est surtout de la virtualisation complète, comme ESX(i), le Redhat ultra léger de XenServer servant d’hyperviseur « bare metal » au dessous des VMs…

Au final, en cherchant à trouver les différences techniques entre XenServer et ESXi, j’ai surtout trouvé des similitudes. Le gros point fort pour moi, c’est que ça marche parfaitement sur ma machine de test. Cependant, ce n’est pas vraiment un critère utile pour la plupart des gens qui peuvent se permettre (dans un contexte plus professionnel) d’acquérir du matériel supporté par VMware. Comme ça commence à faire un peu long comme article, j’aborderai mes impressions sur XenServer dans sa réelle utilisation (via une administration XenCenter) dans un prochain article.