Comparatif : les solutions gratuites de virtualisation

Des hyperviseurs gratuits ? C’est possible !

Il y a un peu plus d’un an, nous avons publié un comparatif de solutions gratuites de virtualisation qui faisait lui-même suite à un dossier « virtualisation » mis en ligne quelques mois auparavant. Depuis, les éditeurs ont bien entendu présenté de nouvelles versions de leurs solutions respectives. Il était donc temps de mettre à notre tour en ligne un dossier afin de découvrir ce que ces nouvelles versions des principaux hyperviseurs gratuits du marché apportent comme nouveautés.

Plus précisément, 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) 5.5.0, Citrix XenServer 6.2.0 SP1 et Proxmox VE 3.2. Voyons ce que ces nouvelles solutions de virtualisation apportent comme améliorations par rapport aux précédentes versions et quelles sont leurs différences en matière de performances et de fonctionnalités…

Virtualisation, paravirtualisation : comment et pourquoi ?

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.

Optimisation et réduction des coûts

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 5.5.0, Citrix XenServer 6.2.0 SP1 et Proxmox VE 3.2, font justement partie des hyperviseurs capables de prendre en charge la paravirtualisation, sous certaines conditions.

Configuration de test : le serveur

Remercions tout d’abord Acer 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 Altos R380 F2, un modèle 2U basé sur une plateforme Intel R2000GZ (et par conséquent une carte mère S2600GZ). Ce serveur est équipé entre autres de deux processeurs Intel Xeon E5-2690 (soit 32 cores logiques), de 128 Go de mémoire vive, de quatre ports Ethernet Gigabit et d’un contrôleur Intel RMS25CB080. Acer nous a également envoyé une carte Ethernet 10Gb supplémentaire afin de pouvoir réaliser certains tests de manière optimale.

Configuration et paramétrage

 

Ce serveur fait partie de la gamme de serveurs bi-CPU d’Acer. Comme tous les serveurs du constructeur, celui-ci bénéficie de fonctions avancées de monitoring (Baseboard Management Controller) et d’administration (Acer Smart Console) 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. Il est également possible de bénéficier d’une console de type iKVM (en option).

Acer Smart Setup et Smart Server Manager

Acer met tout particulièrement en avant deux services proposés en standard – et donc sans surcoût, contrairement à d’autres constructeurs – avec chacun de ses serveurs : Acer Smart Setup et Acer Smart Server Manager.

Smart Setup permet, comme son nom le laisse supposer, de simplifier et d’accélérer l’installation et le déploiement des serveurs Acer. Smart Server Manager permet de son côté d’administrer simplement un parc de serveurs (Acer ou non), ainsi qu’un parc d’ordinateurs portables ou de bureau professionnels. Seules deux fonctionnalités additionnelles sont payantes : la possibilité de flasher à distance le BIOS des machines et la possibilité de limiter la consommation énergétique d’un serveur (afin d’éviter que la consommation globale de tous les serveurs ne dépasse ce que peut fournir l’arrivée électrique de la salle).

Configuration de test : réseau et stockage

Netgear XS721TLe réseau

La partie réseau a été confiée à un switch Netgear XS712T. Ce switch administrable est équipé de douze ports Ethernet 10Gigabit (10GBase-T cuivre) et de deux modules Combo SFP+ 10Gigabit (partagés avec deux ports RJ45).

Il prend en charge l’agrégation de liens (8 groupes maximum, et 8 ports maximum par groupe), une fonctionnalité dont nous aurons besoin par la suite. Il embarque en outre 2 Mo de mémoire tampon, peut gérer jusqu’à 256 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. 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 5.5.0

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 5.5 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. Contrairement à la version 5.1, limitée à seulement 32 Go de mémoire, vSphere Hypervisor 5.5 prend en charge un maximum de 4 To de mémoire vive physique. Cet hyperviseur supporte en outre (dans sa version gratuite) 2 CPU physiques, avec un nombre illimité de cores (mais jusqu’à 320 CPU logiques) et jusqu’à 4096 vCPU en tout (512VM maximum). Les machines virtuelles sont en revanche limitées à 8 vCPU.

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 5.5. Dans notre cas, aucun problème : le matériel qu’Acer et Netgear nous ont confié est parfaitement pris en charge par vSphere Hypervisor 5.5.

Fonctionnalités

Tout comme vSphere 5.5 (la solution de virtualisation payante de VMWare), vSphere Hypervisor 5.5 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 5.5 réside dans sa légèreté : l’hyperviseur occupe en effet moins de 300 Mo d’espace disque. vSphere Hypervisor 5.5 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 5.5 de vSphere Hypervisor apporte tout de même quelques nouveautés : le support des fichiers VMDK jusqu’à 62 To (contre 2 To seulement auparavant), des améliorations au niveau des vGPU, du GPGPU et du protocole LCAP, l’accélération graphique sous Linux, le support des interface réseaux 40 Gbps et des HBA 16Gbps « End-to-end », ou encore la prise en charge du Hot-Plug pour les SSD en PCIe. vSphere Hypervisor 5.5 apporte enfin le VM Hardware en version 10.

VMWare vSphere Hypervisor 5.5.0 (suite)

Installation et configuration

L’installation de vSphere Hypervisor 5.5, 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. On noter au passage que nous avons rencontré un bug amusant : la carte 10Gb Ethernet du serveur n’est apparue dans vSphere Hypervisor qu’après avoir désactivé l’option « Memory Mapped I/O Above 4GB » au niveau de l’UEFI…

Stockage des VM

Les machines virtuelles vont être stockées sur les NAS Netgear, dans un volume de stockage dédié. Du côté de vSphere Hypervisor 5.5, il faut dans un premier temps activer l’initiateur iSCSI (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.2.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 (500 dollars par socket) ou perpétuelle (1250 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, et supporte jusqu’à 1 To de mémoire physique, jusqu’à 160 processeurs logiques et jusqu’à 12 GPU. XenServer supporte désormais jusqu’à 650 VM Linux ou 500 VM Windows par host, et un maximum de 4000 vCPU en tout.

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), et jusqu’à 128 Go 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.2.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 les 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 3.2

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 3.2.

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) 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 3.2 supporte jusqu’à 160 CPU et jusqu’à 2 To de mémoire par hôte.

Proxmox VE 3.2 (suite)

Installation et configuration

L’installation de ProxMox VE 3.2 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é Windows Server 2012 R2 en tant que serveur de fichiers, un rôle que l’on trouve aujourd’hui encore dans de nombreuses 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 (via la console d’administration XenCenter, il est possible d’aller jusqu’à 32 vCPU par VM Linux en ligne de commande), et que vSphere 5.5 est limité à 8 vCPU par VM dans sa version gratuite.

 

De manière surprenante, le serveur physique est souvent dépassé par les hyperviseurs, et ce bien que le nombre de threads de la VM soit inférieur aux 32 threads «réels » disponibles avec les deux CPU. Les hyperviseurs semblent donc capables d’optimiser tout particulièrement l’utilisation des ressources CPU disponibles.

Avec Fritz, Hyper-V et vSphere paradent en tête (et se montrent ici aussi plus rapides que le serveur physique), tandis que XenServer est légèrement à la traine. Proxmox VE est quant à lui dépassé par les évènements puisqu’il affiche un retard de 28% sur Hyper-V.

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 lectures et écritures séquentielles, avec le système de stockage interne au serveur, c’est vSphere qui se montre largement en tête tant que les blocs sont inférieurs à 64K. entre 64K et 256K, Hyper-V fait alors jeu égal avec lui. XenServer et Proxmox VE, à la traine, affichent des résultats équivalents.

Avec le NAS RN516, c’est toujours vSphere qui s’en sort le mieux en lecture ainsi qu’en écriture tant que les blocs font moins de 16K, mais les écarts sont largement moins importants. En lecture avec des blocs de 32K ou plus, tous les hyperviseurs font plus ou moins jeu égal. En écriture en revanche, c’est Hyper-V qui se montre le plus rapide.

Avec le NAS RN716X et sa connexion 10Giga, Microsoft et Hyper-V sont au coude à coude. Ici encore, XenServer et Proxmox VE sont en queue de peloton et peinent à dépasser les 6000 IOPS en lecture comme en écriture 4K (soit seulement la moitié d’Hyper-V et vSphere).

En situation “presque” réelle, les résultats changent sensiblement. Avec le système de stockage interne au serveur Acer (8 disques durs en RAID 5 sur un contrôleur Intel, pour rappel), c’est bien entendu le serveur physique qui a l’avantage, talonné par Hyper-V et vSphere qui font pratiquement jeu égal. XenServer est (encore) à la traine.

Avec le NAS RN516, on note de manière surprenante que c’est Proxmox qui se montre le plus rapide, même si ce n’est que de 3 à 5% par rapport à Hyper-V. Suivent vSphere et XenServer. Enfin, le RN716X permet à Hyper-V d’exprimer toutes ses possibilités puisqu’il est jusqu’à 11% plus rapide que vSphere. XenServer et Proxmox capitulent…

Performances stockage : ATTO

Continuons avec ATTO Benchmark :

En lecture comme en écriture avec le système RAID interne, Hyper-V est pratiquement aussi rapide que le serveur physique. Juste en dessous, on trouve vSphere, tandis que Proxmox VE et XenServer sont bien plus lents (surtout avec des blocs de plus de 32 Ko).

Ici, il semble que ce soit le RN516 qui limite les performances en lecture des hyperviseurs puisque les quatre logiciels font jeu égal, ou presque. En écriture toutefois, c’est Hyper-V qui se montre le plus rapide, même si vSphere le rattrape avec des blocs d’une taille importante (4Mo et 8 Mo).

Ici aussi, la connexion 10Giga du RN716 permet à Hyper-V de dévoiler toute sa « puissance » puisqu’il est le seul – et de loin – à dépasser 1 Go/s alors que vSphere, dans le meilleur des cas, n’atteint que 600 Mo/s. Passons rapidement sur Proxmox VE qui peine à dépasser les 400 Mo/s en lecture comme en écriture et sur XenServer qui a refusé d’aller au delà de 170 Mo/s en lecture…

Performances stockage : CrystalDiskMark

Terminons enfin par CrystalDiskMark :

Les choses se répètent avec CrystalDiskMark et le RAID interne : Hyper-V arrive largement en tête en lecture et en écriture, suivi de vSphere qui ne cède du terrain qu’en lecture aléatoire 4K. Proxmox VE essaie de suivre à distance et XenServer lâche l’affaire, sauf en accès aléatoires 4K où il se hisse au niveau de vSphere dans le meilleur des cas.

Avec le NAS RN516 de Netgear, les choses se compliquent : Hyper-V se montre le plus rapide en écriture séquentielle alors que c’est vSphere qui est le plus véloce en écriture aléatoire 512K. Globalement, Hyper-V et vSphere sont en tête, alors que Proxmox VE et XenServer – n’en déplaisent aux aficionados – jouent à « qui est le plus lent ».

Avec le RN716X enfin, vSphere passe devant Hyper-V, surtout en écriture séquentielle et aléatoire 512K. Dans le meilleur des cas, vSphere atteint tout de même 600 Mo/s ! En accès aléatoires 4K Hyper-V et vSphere font globalement jeu égal, alors que XenServer est légèrement à la traine sans non plus se montrer aussi lent que Proxmox VE.

Tableau récapitulatif