Comparatif virtualisation : les solutions gratuites

Virtualisation, paravirtualisation : comment et pourquoi ?

La virtualisation n’est pas un concept réellement nouveau : Popek et Goldberg ont dès 1974 jeté les bases des développements futurs. Mais force est de constater que les solutions de virtualisation se sont multipliées ces dernières années, la technologie et le matériel étant arrivés à un certain degré de maturité.

Nous allons aujourd’hui nous intéresser à quatre logiciels gratuits destinés au marché des serveurs : Microsoft Hyper-V Server 2012 R2, VMWare vSphere Hypervisor (anciennement ESXi) 6.0 U1, Citrix XenServer 6.5.0 SP1 et Proxmox VE 4.0. Voyons ce que ces nouvelles solutions de virtualisation apportent comme améliorations par rapport aux précédentes versions – que nous avons également eu l’occasion de tester ces dernières années – et quelles sont leurs différences en matière de performances et de fonctionnalités…

Optimisation et réduction des coûts

L’idée principale du concept de virtualisation est d’exécuter un système d’exploitation dans une machine virtuelle, chaque machine physique – chaque serveur – étant capable de faire tourner un certain nombre de machines virtuelles. En pratique, virtualiser les serveurs d’une entreprise permet d’utiliser de façon optimale les ressources matérielles, tout en mutualisant la consommation électrique et la maintenance. Cela permet également d’optimiser l’installation, le déploiement et la migration des machines, et de faciliter la mise en production des serveurs. La virtualisation permet enfin de faciliter le dimensionnement des serveurs, la puissance CPU, l’espace de stockage ou la quantité de mémoire vive pouvant être alloué dynamiquement entre les serveurs virtuels. En résumé, la virtualisation permet de faciliter le travail d’administration d’un parc de serveurs, tout en optimisant la gestion des ressources matérielles, et donc le coût.

Comme tout système d’exploitation, un OS serveur est en charge de gérer les ressources matérielles de l’ordinateur (CPU, mémoire vive, périphériques, etc.). Il s’attend donc à avoir seul la gestion de toutes les ressources matérielles de l’ordinateur, et à pouvoir dialoguer directement avec le CPU. Dans un environnement virtualisé, il va donc falloir faire croire à chaque OS fonctionnant en parallèle qu’il est le seul à être installé sur la machine. C’est le rôle de l’hyperviseur, un système d’exploitation très simple intégrant le programme de virtualisation ou VMM (Virtual Machine Monitor). Celui-ci va se charger de simuler autant de machines virtuelles que de systèmes d’exploitation.

Virtualisation, paravirtualisation ou émulation ?

Plusieurs types de virtualisation existent, chacun ayant ses propres avantages et inconvénients. Ainsi, il existe des solutions de virtualisation complète, l’hyperviseur se chargeant de créer un environnement virtuel complet en simulant du « faux » matériel. Le système d’exploitation invité n’aura alors accès qu’à ces ressources simulées, et non aux ressources matérielles réelles. Ce type de virtualisation est toutefois limité aux systèmes d’exploitation prévus pour la même architecture matérielle (x86, x64, ARM, …) que le processeur physique de la machine hôte.

Pour dépasser cette limite, il faut faire appel à l’émulation : l’hyperviseur créé alors un environnement virtuel complet, en allant jusqu’à simuler un microprocesseur qui peut alors avoir une architecture matérielle différente de celle du CPU hôte. Le principal inconvénient de ce type de solution est alors le niveau de performances, souvent médiocre.

La paravirtualisation est un autre type de solution de virtualisation. Ici, le système d’exploitation invité est conscient de s’exécuter dans un environnement virtualisé, ce qui nécessite bien entendu certaines modifications logicielles (par exemple l’installation de pilotes ou d’une surcouche logicielle). En contrepartie, il devient capable d’interagir avec l’hyperviseur et de lui demander, le cas échéant, de transmettre directement les appels systèmes au matériel du serveur hôte. Les performances « virtuelles » sont alors théoriquement proches de celles qu’il serait possible d’atteindre avec le matériel réel.

Les quatre solutions gratuites que nous avons choisi de tester, à savoir Microsoft Hyper-V Server 2012 R2, VMWare vSphere Hypervisor 6.0 U1, Citrix XenServer 6.5.0 SP1 et Proxmox VE 4.0, font justement partie des hyperviseurs capables de prendre en charge la paravirtualisation, sous certaines conditions.

Configuration de test : le serveur

Remercions tout d’abord Fujitsu qui a mis (longuement) à notre disposition le matériel indispensable pour réaliser ce dossier. Nous avons ainsi pu bénéficier d’un serveur PRIMERGY TX2540 M1, un modèle au format tour basé sur une plateforme Fujitsu D3099-B, avec un chipset Intel C602.

Ce serveur est équipé entre autres de deux processeurs Intel Xeon E5-2420 (soit 24 cores logiques), de 48 Go de mémoire vive, de deux ports Ethernet Gigabit (Intel i210), d’un contrôleur Ethernet Gigabit supplémentaire dédié à la gestion distante (iRMC S4) et d’un contrôleur de stockage Fujitsu D2607.

Configuration et paramétrage

 

Ce serveur fait partie de la gamme de serveurs bi-CPU de Fujitsu. Comme tous les serveurs du constructeur, celui-ci bénéficie de fonctions avancées de monitoring, déploiement, contrôle et administration (Suite ServerView) permettant, grâce à un port Ethernet dédié, d’avoir un contrôle total sur le serveur (KVM IP complet, redirection de lecteurs, ISO, Floppy, contrôle des alimentations…) via un simple navigateur.

Configuration de test : réseau et stockage

Le réseau

La partie réseau a été confiée à un switch Netgear ProSafe GSM5212P (M4100-D12G-POE+). Ce switch administrable compatible PoE/PoE+ est équipé de douze ports Ethernet Gigabit (1000Base-T) et de quatre modules SFP 100/1000X partagés.

Il prend en charge l’agrégation de liens (statique et dynamique – LACP), embarque 12 Mo de mémoire tampon, 128 Mo de mémoire vive et un processeur cadencés à 600 MHz, peut gérer jusqu’à 1024 VLAN et supporte les Jumbo Frame jusqu’à 9000 octets. La liste complète des fonctionnalités et caractéristiques techniques est disponible sur le site de Netgear.

Microsoft Hyper-V Server 2012 R2

Arrivé un peu tard sur le marché de la virtualisation pour serveurs, Microsoft a rapidement proposé une solution viable baptisée Hyper-V.

A l’origine uniquement disponible en tant que rôle dans Windows Server 2008 (la version finale a été publiée sur Windows Update en juin 2008), Hyper-V a par la suite été proposé (dès octobre 2008) en version stand-alone et gratuite, puis mis à jour en version R2 en septembre 2009. La version 3 – ou Hyper-V Server 2012 – est quant à elle arrivée en 2013. Aujourd’hui, c’est donc la version 4 (Hyper-V Server 2012 R2) qui nous intéresse.

Hyper-V Server 2012 R2 est plus ou moins une version Core de Windows Server 2012 R2 avec toutes les fonctionnalités d’Hyper-V activées, les autres rôles de Windows Server étant désactivés. Il n’y a donc pas d’interface graphique à proprement parler, et tout se passe en ligne de commande classique ou via Windows Powershell.

Pré-requis à l’installation

Au niveau des ressources matérielles nécessaires pour installer et faire fonctionner l’hyperviseur, Hyper-V Server 2012 R2 demande la même chose que la version précédente : un (ou plusieurs) processeurs compatibles x64 (1,4 GHz minimum) prenant en charge VT-x ou AMD-V ainsi que le bit NX/XD, et 512 Mo de mémoire vive au minimum pour fonctionner.

La solution de Microsoft prend en charge les systèmes avec 320 CPU logiques au maximum et jusqu’à 4 To de mémoire vive. Jusqu’à 1024 machines virtuelles peuvent fonctionner sur une seule et unique machine physique, chaque VM ayant droit à un maximum de 64 processeurs virtuels et 1 To de mémoire virtuelle.

Fonctionnement et fonctionnalités

Hyper-V Server 2012 R2 fonctionne avec des unités logiques d’isolation, baptisées partitions, dans lesquelles s’exécutent les différents systèmes d’exploitation invités. Chaque partition enfant n’a accès qu’à une vue virtuelle des ressources matérielles, microprocesseur(s) compris.

L’hyperviseur est donc capable d’intercepter les interruptions du processeur pour les rediriger vers la ou les partitions adéquates. Hyper-V utilise au passage l’accélération matérielle proposée par les processeurs d’Intel et d’AMD en matière de virtualisation (Intel VT-x et AMD-V, ainsi que EPT et NPT pour la translation d’adresses mémoire entre les différents espaces d’adressage virtuels). Les appels à un périphérique virtuel réalisés par les partitions enfants sont quant à eux redirigés via le VMBus vers le périphérique réel.

Du côté des nouveautés, Hyper-V Server 2012 R2 apporte le support des derniers OS de l’éditeur (Windows 8 et 8.1, Windows 2012 et 2012 R2), un support amélioré des VM Linux (avec un nouveau pilote vidéo et le support de la mémoire dynamique), la migration à chaud et sans interruption (« Live Migration ») des VM à partir d’un hôte Hyper-V 2012, l’activation automatique des VM (technologie « Zero Touch Activation »), l’export et le clonage d’une VM à chaud, la possibilité de réduire ou d’agrandir les fichiers VHDX à chaud, le partage de fichiers VHDX entre VM (« Shared VHDX ») ou encore le QoS sur le stockage des VM.

Hyper-V 2012 R2 introduit également la technologie Remote Desktop over VMBUS. Les machines virtuelles sont quant à elles basées sur UEFI et supportent le Secure Boot. Il est possible de démarrer depuis un virtual SCSI, et de nombreux périphériques émulés ont été supprimés (CD-ROM et Controller IDE, Legacy BIOS, Legacy NIC, S3 video, PCI Bus ou encore UART).

Les principales fonctionnalités d’Hyper-V Server 2012 R2 mises en avant par Microsoft sont le format de disques virtuels VHDX (avec prise en charge des secteurs 4K et une taille maximale de 64 To), l’amélioration de l’allocation dynamique de la mémoire en fonction de la charge, l’amélioration des performances des migrations dynamiques, les « extensibles switchs », les fonctionnalités Live Storage Migration, Core Parking (permet de mettre en veille certains cœurs CPU inutilisés lorsque le nombre de VM ou leur charge diminue) et Remote FX (Remote FX Hardware GPU, Remote FX Software GPU, Remote FX Adaptive Graphics, Remote FX for WAN, Remote FX Multi-Touch, Remote FX USB Redirection ou encore Remote FX Media Remoting).

Microsoft Hyper-V Server 2012 R2 (suite)

Installation et configuration

L’installation d’Hyper-V Server 2012 R2 s’effectue en mode graphique, à l’image de celle de Windows Server 2012 R2. Après le choix de l’emplacement d’installation et la validation du CLUF, nous avons droit à la copie et la décompression des fichiers, puis à l’installation des fonctionnalités.

Après un redémarrage, le système nous demande enfin de définir le mot de passe d’administration. La configuration d’Hyper-V se déroule en revanche entièrement en ligne de commande, avec en particulier la configuration réseau (IP des cartes réseaux, DNS, …) et la possibilité de joindre un domaine Active Directory (pas obligatoire, mais très vivement conseillé, cela simplifie l’administration) ou un groupe de travail. Il est également possible – et recommandé – de télécharger et d’appliquer les mises à jour.

Stockage des VM

Les machines virtuelles vont être stockées sur les NAS Netgear sur lesquels nous avons précédemment créé un volume qui servira à les héberger. L’administration est possible en local grâce à PowerShell, ou bien à distance grâce aux outils RSAT à installer sur un poste client Windows 8.1 ou Windows 10. On peut également utiliser les outils d’administration de Windows Server 2012 R2, voire System Center 2012 R2 (mais il s’agit d’un outil payant).

Du côté de l’hyperviseur, il va falloir lancer le service Initiateur iSCSI (grâce à la commande net start MSiSCSI) ainsi que l’outil de configuration de l’Initiateur iSCSI (via la commande iscsicpl). Le service Microsoft iSCSI n’est par défaut par lancé, mais l’outil nous propose de le configurer pour qu’il se lance automatiquement. Il suffit ensuite d’aller se connecter sur les cibles créées sur les NAS (en n’oubliant pas, le cas échéant, la prise en charge de plusieurs chemins d’accès).

A l’aide des outils RSAT sur la console d’administration, il faut ensuite mettre en ligne les différents volumes physiques disponibles sur l’hyperviseur, créer des pools de stockage puis créer des disques virtuels et des volumes virtuels.

Création VM

La création d’une nouvelle VM se déroule sur la station d’administration, en utilisant le gestionnaire Hyper-V (un module optionnel qu’il faudra installer). Il est ensuite possible de se connecter à distance à l’hyperviseur afin de configurer le réseau virtuel

Nous pourrons ensuite configurer l’emplacement de stockage des machines virtuelles, et enfin créer la (ou les) nouvelle(s) machine(s) virtuelle(s). On n’oubliera pas de définir la quantité de mémoire vive virtuelle et le nombre de vCPU, de régler les paramètres réseau et de créer un fichier VHDX. Il ne restera alors plus qu’à lancer cette machine virtuelle et à installer les outils d’intégration (Integration Services). Ce sont eux qui permettent de bénéficier de la para-virtualisation…

VMWare vSphere Hypervisor 6.0 U1

VMWare est présent sur le marché de la virtualisation depuis de nombreuses années, la première version d’ESX Server datant de 2001. Une version gratuite de l’hyperviseur de VMWare, VMWare vSphere Hypervisor (anciennement ESXi), est également proposée depuis quelques années. Certaines des fonctionnalités d’ESX – rebaptisé vSphere depuis la version 4.0 – ne sont toutefois pas disponibles dans la version gratuite.

Pré-requis à l’installation

VMware vSphere Hypervisor 6 demande un (ou plusieurs) processeur(s) compatible(s) x64 (deux cores minimum, avec support du bit NX/XD) et un minimum de 4 Go de mémoire vive pour fonctionner.  Cet hyperviseur supporte en outre un nombre illimité de CPU physiques (alors que la version 5.5 était limitée à 2 CPU dans sa version gratuite), avec un nombre illimité de cores (mais jusqu’à 480 CPU logiques en tout, contre 320 CPU logiques « seulement » sous vSphere Hypervisor 5.5), un maximum de 12 To – sur systèmes OEM certifiés – de mémoire vive physique (contre 4 To avec la version précédente de l’hyperviseur) et jusqu’à 4096 vCPU en tout (1024VM maximum). Les machines virtuelles sont en revanche limitées à 8 vCPU (128 vCPU avec la version payante).

La principale difficulté réside dans la compatibilité matérielle, en particulier au niveau des contrôleurs réseau et de stockage. Il convient donc avant tout de bien vérifier sur le Guide de Compatibilité Matérielle (HCG) si le serveur hôte et ses composants sont aptes à accueillir VMware vSphere Hypervisor 6. Dans notre cas, aucun problème : le matériel que Fujitsu et Netgear nous ont confié est parfaitement pris en charge par vSphere Hypervisor 6.

Fonctionnalités

Tout comme vSphere 6 (la solution de virtualisation payante de VMWare), vSphere Hypervisor 6 repose sur le microkernel VMkernel. C’est ce dernier qui accède directement au processeur et à la mémoire de la machine hôte, utilisant au passage un mécanisme SBE (Scan-Before-Execution) pour prendre en charge certaines instructions critiques, privilégiées et/ou spéciales. Les autres ressources matérielles sont prises en charge par des modules additionnels.

L’un des avantages de vSphere Hypervisor 6.0 réside dans sa légèreté : l’hyperviseur n’occupe quelques centaines de Mo d’espace disque. vSphere Hypervisor 6 est toutefois – et c’est logique – moins complet que vSphere. Ainsi, on doit se contenter d’une console d’administration minimaliste en lieu et place d’un véritable environnement. Tous les agents VMware sont par ailleurs exécutés directement sur le VMkernel.

La version 6 de vSphere améliore un certain nombre de caractéristiques de l’hyperviseur. Il par exemple possible de migrer des VM à chaud entre deux Distributed Switch, entre deux vSwitch ou d’un vSwitch vers un Distributed Switch (mais pas l’inverse) grâce à Cross vSwitch vMotion. Il est également possible de migrer une VM d’un vCenter à un autre, même s’ils ne partagent aucun Datastores. Il est en outre possible de mettre en place du Fault Tolerance avec un maximum de 4 vCPU, contre 1 seul vCPU auparavant. Enfin, vSphere Hypervisor 6 apporte le VM Hardware en version 11 et VSAN version 6.0.

VMWare vSphere Hypervisor 6.0 U1 (suite)

Installation et configuration

L’installation de vSphere Hypervisor 6, relativement rapide, se déroule entièrement en ligne de commande, à la manière de certaines distributions Linux. elle se termine par un redémarrage et le lancement de l’hyperviseur.

Mis à part la configuration réseau et certaines opérations basiques, toutes les opérations d’administration s’effectuent à distance via une console d’administration, baptisée vSphere Client, à installer sur un poste. Très complète, cette console permet de configurer l’hyperviseur, de créer, modifier et supprimer des machines virtuelles, d’accéder aux différents logs et de surveiller des paramètres comme l’occupation CPU et mémoire, les temps d’accès et les débits.

C’est également grâce à cette console d’administration que nous allons pouvoir configurer le réseau et mettre en place des réseaux virtuels (dédiés au stockage, à l’administration, …) grâce à plusieurs vSwitch.

Stockage des VM

Les machines virtuelles vont être stockées sur le NAS Netgear, dans un volume de stockage dédié. Du côté de vSphere Hypervisor 6, il faut dans un premier temps activer l’initiateur iSCSI logiciel (désactivé par défaut), pointer le bon volume, puis formater le volume. Depuis la version 5.0, vSphere Hypervisor utilise une nouvelle version de son système de fichiers propriétaire VMFS (Virtual Machine File System). VMFS 5 apporte en particulier le support des volumes de plus de 2 To et l’optimisation de la taille des sous-blocs. VMFS permet par ailleurs à plusieurs instances de serveurs VMware vSphere d’accéder simultanément à un système de stockage de machines virtuelles partagé.

Création VM

Pour créer une VM, rien de plus simple : on se connecte à l’hyperviseur vSphere Hypervisor via vSphere Client, on attribue un nom à la machine virtuelle de destination, on spécifie la banque de données de destination et on défini certaines options comme la quantité de mémoire virtuelle et le nombre de vCPU à allouer à la future VM, ou bien le nombre de contrôleurs réseaux. La machine virtuelle est alors automatiquement créée dans vSphere Hypervisor, et apparait dans vSphere Client. Il ne reste plus qu’à la démarrer et à installer les VMWare Tools afin de profiter de la para-virtualisation…

Citrix XenServer 6.5.0 SP1

Citrix XenServer est une plateforme de virtualisation gratuite, basée sur l’hyperviseur open-source Xen. Si l’hyperviseur Xen existe depuis de nombreuses années (la version 1.0 date d’octobre 2003), le rachat de XenSource par Citrix ne date que de 2007. XenServer est disponible gratuitement, mais il faudra en revanche opter pour une licence annuelle (à partir de 345 dollars par socket) ou perpétuelle (à partir de 763 dollars par socket) pour profiter du support de Ctrix.

Pré-requis à l’installation

XenServer demande un processeur x86-64 pour fonctionner, cadencé à 1,5 GHz au minimum. Citrix recommande toutefois un (ou plusieurs) processeur cadencé à 2 GHz ou plus, et si possible multi-core. De plus, un processeur supportant les technologies Intel VT ou AMD-V est nécessaire pour faire tourner un système Windows dans une machine virtuelle. La solution de Citrix demande un minimum de 2 Go de mémoire (4 Go ou plus recommandés), et supporte jusqu’à 1 To de mémoire physique, jusqu’à 160 processeurs logiques, jusqu’à 16 interfaces réseau et jusqu’à 12 GPU. XenServer supporte désormais jusqu’à 650 VM Linux ou 500 VM Windows, et jusqu’à 96 vGPU par hôte.

Côté machines virtuelles, XenServer peut allouer un maximum de 16 vCPU (voire jusqu’à 32 pour les machines virtuelles Linux, en modifiant certains paramètres en ligne de commande), jusqu’à 192 Go et jusqu’à 96 vGPU par VM. Les disques virtuels sont limités à 2 To (-4 Go), et on ne peut allouer que 7 interfaces réseau par VM.

Fonctionnalités

Contrairement à VMWare qui fait principalement appel à un système de « translation binaire » (via le mécanisme Scan-Before-Execution), XenServer combine virtualisation matérielle et paravirtualisation. Ainsi, lorsque le système d’exploitation invité ne peut pas être totalement paravirtualisé, l’hyperviseur fait appel aux technologies de virtualisation matérielle Intel VT ou AMD-V.

Les interactions entre les machines virtuelles et le matériel sont gérées par le domaine de contrôle « Domain 0 », lui-même une machine virtuelle dotée de privilèges spéciaux. Hébergeant une instance optimisée de Linux, « Domain 0 » s’appuie sur les pilotes standards open source de Linux, offrant ainsi une compatibilité matérielle très étendue.

Citrix XenServer 6.5.0 SP1 (suite)

Installation et configuration

L’installation de XenServer est relativement rapide, Citrix parlant de « 10 minutes pour passer à Xen ». Tout se déroule en ligne de commande, dans un style qui n’est pas sans rappeler l’installation de certaines distributions Linux.

Une fois l’installation terminée, nous avons accès à une console permettant de configurer certains paramètres (en particulier au niveau du réseau et du stockage). L’interface d’administration, baptisée XenCenter, s’installe quant à elle sur n’importe quel poste Windows. Celle-ci donne accès à un certain nombre de réglages concernant l’hyperviseur. Il est également possible de créer, modifier, migrer et supprimer des machines virtuelles, ainsi que d’accéder à un certain nombre de logs et de surveiller des paramètres comme l’occupation CPU et mémoire, les temps d’accès et les débits.

Stockage des VM

XenServer est particulièrement souple au niveau du stockage des VM puisqu’il n’impose pas son propre système de fichiers sur des systèmes de stockage mais s’appuie plus directement sur les fonctionnalités de stockage natives. Nous avons donc ici aussi créé un volume de stockage dédié sur le NAS Netgear afin d’y stocker les machines virtuelles.

Création VM

La création d’une machine virtuelle passe par XenCenter. Une fois le processus terminé, il suffira de la lancer la VM. L’installation des outils Xen sur l’OS client permettra ensuite le monitoring sous XenCenter de l’occupation mémoire et CPU…

Proxmox VE 4.0

Proxmox VE (pour Virtual Environment) est une solution open source basée sur l’hyperviseur KVM et sur le système d’exploitation Debian 64 bits. Créé en 2008 par la société Proxmox Server Solutions, Proxmox VE en est aujourd’hui à la version 4.1.

Ici aussi, si la version de base est gratuite, il faudra passer par un abonnement (au CPU et par mois, entre 4,16 euros et 66,33 euros) pour bénéficier d’un support étendu (nombre annuel de tickets de support, garantie de temps de réponse,…).

Pré-requis à l’installation, fonctionnalités

Deux types de virtualisation sont supportés par Proxmox VE : une virtualisation matérielle et complète via l’hyperviseur KVM (qui permet de virtualiser des systèmes Solaris, Linux ou Windows), qui demande toutefois un (ou plusieurs) processeurs disposant des technologies Intel VT ou AMD-V, et une virtualisation par isolateur grâce à des conteneurs OpenVZ. Dans ce dernier cas, seuls des systèmes d’exploitation de type Linux peuvent être virtualisés. Pour fonctionner, Proxmox VE se contente d’un processeur x86 (64 bits, avec support VT/AMD-V pour le support KVM Full Virtualization) et de 1 Go de mémoire vive. Il s’agit toutefois de la configuration minimale : en production, l’hyperviseur s’y sentira un peu à l’étroit…

Proxmox VE propose, comme ses concurrents, une gestion optimisée de la mémoire (Kernel Samepage Merging, Memory ballooning), des snapshots de machines virtuelles, l’intégration et l’authentification avec un annuaire LDAP, le support du bonding, la prise en charge des suavegardes et des restaurations ou encore la migration à chaud. Côté limitations, Proxmox VE 4.0 supporte jusqu’à 160 CPU et jusqu’à 2 To de mémoire par hôte.

Proxmox VE 4.0 (suite)

Installation et configuration

L’installation de ProxMox VE 4.0 se déroule en mode graphique. Après avoir lu et accepté la licence, on choisi un mot de passe d’administration et on configure la partie réseau. Une fois l’installation terminée, l’hyperviseur redémarre et propose un shell qui nous confirme au passage que nous sommes bien sur une base Debian.

La configuration de l’hyperviseur (configuration complète du réseau, accès au NAS, activation du multipath iSCSI en ligne de commandes…) se déroule ensuite via un simple navigateur, à partir d’un poste client. En pratique, les VM seront stockées dans un volume de stockage dédié sur les NAS Netgear, montés en tant que LVM (Logical Volume Manager).

Création VM

Il est bien entendu possible de créer très facilement une machine virtuelle et d’installer un système d’exploitation sur cette VM.

Performances vCPU

Comparer les performances de plusieurs hyperviseurs entre eux n’est pas une tâche facile. Nous avons donc choisi d’analyser le comportement et les performances des machines virtuelles à l’aide d’un ensemble de benchs synthétiques, l’objectif étant d’essayer de mesurer les différents points critiques d’un serveur, en particulier les performances des vCPU.

Pour cela, nous avons installé plusieurs systèmes d’exploitation (Windows Server 2008 R2, 2012 R2, 2016 TP3, OpenSuse Leap 42.1 ou encore Debian 8.2) que l’on trouve aujourd’hui dans de nombreuses TPE/PME. A chaque fois, nous avons choisi d’installer le système d’exploitation directement dans une machine virtuelle. On notera au passage que XenServer ne supporte que 16 vCPU (bien qu’il soit possible d’outrepasser cette limite en ligne de commande), et que vSphere 6.0 est limité à 8 vCPU par VM dans sa version gratuite.

Notez au passage que les éditeurs recommandent de configurer le nombre de vCPU des machines virtuelles en fonction des besoins réels : attribuer le maximum possible de vCPU à une machine virtuelle n’en améliorera pas forcement les performances !

Si les performances avec un seul thread sont globalement similaires quel que soit l’hyperviseur, avec tout de même 14% d’écart entre le premier (XenServer) et le dernier (Hyper-V), il n’en est pas de même en situation Multi-core. Les performances vCPU d’Hyper-V 2012 R2 sont très sensiblement en retrait, tandis que XenServer arrive largement en tête. Du côté des performances vRAM, c’est vSphere 6 qui s’en sort le mieux en Multi-Core, alors que de manière intéressante c’est celui qui affiche les performances les plus faibles en Single-Core. Les autres hyperviseurs affichent des performances vRAM très proches.

En utilisant Debian 8.2 comme système virtualisé, on note plusieurs points intéressants : Hyper-V est encore moins bon du côté des performances vCPU, que ce soit avec un seul ou plusieurs cores. vSphere et ProxmoxVE sont en revanche plus performants, ce qui permet même à l’hyperviseur de VMWare de passer devant celui de Citrix. Il faudra donc bien faire attention au(x) système(s) à virtualiser lorsque l’on devra choisir un hyperviseur.

Bien qu’elles progressent au fur et à mesure qu’on augmente le nombre de vCPU, les performances d’Hyper-V restent en-deçà de celles de ses concurrents. A l’inverse, celles de Proxmox sont très bonnes. La limitation à seulement 8 vCPU de vSphere est ici très dommageable pour l’hyperviseur de VMWare. Notons au passage le plafonnement des performances de XenServer.

Même chose si on prend Debian 8.2 comme système virtualisé : Hyper-V est le moins performant, même si la possibilité d’allouer 24 vCPU à la machine virtuelle permet de rattraper le retard. Encore une fois, Proxmox est le plus rapide et XenServer plafonne.

Même si l’on se concentre sur un environnement virtualisé 100% Windows, le système virtualisé semble avoir une certaine importance au niveau des performances vCPU, peut-être à cause des pilotes para-virtualisés. Dans tous les cas, Hyper-V 2012 R2 est toujours derrière ses concurrents, tandis que vSphere 6 est en tête deux fois sur trois.

Si les performances CPU de vSphere 6, XenServer 6.5 et ProxmoxVE 4.0 se tiennent dans un mouchoir de poche, Hyper-V 2012 R2 reste ici encore sensiblement à la traine. Côté mémoire, c’est ProxmoxVE 4.0 qui s’en sort le mieux, suivi par vSphere 6.

Performances stockage : IOmeter

Nous nous sommes également penchés sur les débits et IOPS en lecture et en écriture avec des accès séquentiels et aléatoires (depuis et vers le NAS), grâce à trois benchs synthétiques. Commençons par IOmeter :
 

 

En lecture séquentielle, les quatre hyperviseurs affichent des performances honorables. Deux groupes semblent tout de même se dessiner : Hyper-V et Proxmox en tête, et vSphere et XenServer juste derrière.

En écriture séquentielle, les performances sont encore plus proches, avec tout de même XenServer – et Hyper-V dans un moindre mesure, uniquement avec des blocs d’une taille inférieure à 16 Ko – légèrement en retrait.

En tests « réels », c’est Proxmox qui s’en sort le mieux, surpassant de manière sensible deux fois sur trois ses concurrents. XenServer est encore une fois bon dernier, et très largement cette fois-ci puisque ses performances sont en moyenne moitié moins importantes que ses concurrents.

Performances stockage : ATTO

Continuons avec ATTO Benchmark :

Alors que Proxmox s’en sortait très bien jusqu’à présent côté stockage, voici qu’il semble avoir quelques problèmes avec ATTO, en particulier avec des blocs de données supérieurs à 256 Ko. Hyper-V affiche les meilleures performances, suivi par vSphere (malgré un effet de palier à partir de 32 Ko, avec un débit se situant de manière intéressante autour de la limite de bande passante d’un lien Gigabit) . XenServer semble de son côté avoir quelques problèmes avec le multipathing et l’agrégation de lien Ethernet.

En écriture, on prend les même et on recommence : Hyper-V arrive en tête, suivi par vSphere, toujours avec son effet « palier ». La courbe de Proxmox s’affole toujours (mais dès 128 Ko cette fois-ci), tandis que XenServer a encore une fois perdu une des deux routes vers le NAS…

Performances stockage : CrystalDiskMark

Terminons enfin par CrystalDiskMark :

Sous CrystalDiskMark, les hyperviseurs ont bien du mal à se départager sauf… Hyper-V qui fait la course très largement seul en tête en lecture séquentielle : la solution de Microsoft est près de deux fois plus performante que celles de ses concurrents ! Les débits aléatoires 4K sont en revanche anémiques, même si vSphere et XenServer font légèrement mieux que les autres.

Avec plusieurs accès en lecture (file d’attente QD32), les choses évoluent : Hyper-V est toujours performant, mais il se fait dérober la première place du podium par ProxmoxVE, que ce soit en accès séquentiel ou aléatoire 4K. vSphere ne se débrouille pas mal non plus, même s’il est un cran en retrait par rapport à Hyper-V. XenServer, encore une fois, est à la traine.

En écriture séquentielle, Hyper-V est toujours largement devant. Il est en revanche bon dernier en écriture aléatoire ! Ce sont alors vSphere et XenServer qui passent devant.

Avec une file d’attente (QD32), c’est une nouvelle fois ProxmoxVE qui se montre le plus rapide en accès séquentiel, suivi par Hyper-V et, un peu plus loin, vSphere. En accès aléatoire, le trio de tête est identique, mais c’est vSphere qui passe devant ProxmoxVE, suivi d’Hyper-V. Pour ne pas changer, XenServer est encore une fois bon dernier…

Tableau récapitulatif