Nous allons étudier ici les bonnes pratiques (best practice) pour assurer les performances d’Hyper-V d’un point de vue du hardware. A l’évidence, si le matériel rencontre des problèmes de performances ou de disponibilité, l’OS et les applications sous-jacentes risquent de devenir rapidement indisponibles. La virtualisation des systèmes d’exploitation avec  Hyper-V (supervisé par SCVMM)  permet, grâce à la Live Migration, de déplacer dynamiquement, à chaud et sans interruption de service, les VM d’un serveur physique à un autre. Sous l’angle de la disponibilité des ressources, cette architecture offre d’énormes avantages par rapport aux infrastructures physiques, mais  ne résous pas pour autant la problématique des performances.  Donc, sans aller jusqu’à parler d’un crash, le matériel peut subir de fortes pointes de charge allant ainsi jusqu’à pénaliser le fonctionnement globale des VM. Voyons un peu de quoi il en retourne…

Hyper-V virtualise quatre ressources matérielles essentielles.

• La CPU
• La mémoire
• Le stockage
• Le réseau

Nous allons aborder les conséquences que vont avoir de ces différentes ressources sur les performances de la plateforme en fonction de leur mode de gestion.

LA CPU

> Petit rappel sur la CPU, les cores et les threads

La virtualisation de la CPU génère des besoins supplémentaires au niveau du système qui varient selon différents facteurs (le nombre de VM, la charge des applications,…). Au niveau du serveur de virtualisation, cela se traduit par une diminution des performances globales.

Du point de vue de la CPU, la capacité de calcul d’une machine virtuelle est très proche de celle de la machine physique (voir Hyper-V CPU BenchMark sur le site Guvirt)

Hyper-V est capable  de tirer parti des configurations multi-cœurs et multi-processeurs, ce qui permet d’exécuter des VM sollicitant beaucoup le processeur (bases de données, courrier électronique) sans affecter les performances des autres VM.

Petite parenthèse : l’OS parent ne voit ni des cores ni des CPU mais des « threads » qui sont les flux d’instructions élémentaires des applications vers la CPU.  Le fameux Hyper-Threading permet d’attribuer deux threads à chaque cœur.

A titre d’exemple, sur un serveur équipé de deux processeurs quadricœurs, il sera possible d’exécuter simultanément 16 threads (les threads peuvent correspondre à des applications différentes). Windows 2008 Server est limité à 64 threads et Windows 2008 Server R2  à 256 threads.

> Quelle est la configuration CPU minimale requise pour Hyper-V ?

Afin de faire fonctionner Hyper-V, le cahier des charges de la CPU est très précis et restrictif…

Le processeur doit :

1. être 64 bits (x64)
2. posséder un jeu d’instruction qui permet l’assistance matérielle à la virtualisation Intel VT ou AMD-V. Il faut activer cette fonctionnalité dans le BIOS.
3. posséder les instructions Data Execution Protection ou DEP. Pour ce faire, il faut activer Intel XD bit (execute disable bit) ou AMD NX bit (no execute bit) suivant la famille de votre CPU (comment déterminer si la DEP matérielle est disponible sur votre serveur ?)

En terme de vitesse, nous recommandons en général une CPU à 2 GHz minimum.

Cette configuration suffit pour installer Hyper-V, effectuer quelques tests, mais ne comptez pas  faire de la production avec !

> Quelle est la configuration CPU recommandée pour Hyper-V ?

Nous recommandons  au moins un CPU Quad-Core sachant que l’on assigne à chaque VM de façon empirique un ou deux CPU Virtuel (vCPU)

Avec un quad-core, on peut donc imaginer de faire fonctionner par exemple 4 VM mono-CPU ou 2 VM dual CPU.

MEMOIRE RAM

La couche de virtualisation exige sa propre portion de mémoire. Hyper-V ne diminue pas la quantité de mémoire requise pour faire fonctionner un système d’exploitation hôte et ses applications. Au contraire, la mémoire va être réservée par avance par l’hyperviseur.

Conséquence : si vous créez 4 VM avec chacune 2 Go de RAM il faudra quoiqu’il arrive au moins 8 Go de RAM pour les VM. C’est là une des différences fondamentales par rapport à VMWare ESX qui assigne dynamiquement la mémoire. La mémoire dynamique devrait arriver sur Hyper-V dans les prochaines versions.

La RAM détermine donc en grande partie le nombre total de VM pouvant être installées sur un même serveur Hyper-V.

> Configuration mémoire minimale et maximum

• Minimum : 1 Go
• Maximum :  32 Go (31 Go pour l’ensemble des VM + 1 Go pour l’OS parent et Hyper-V)

> Configuration mémoire recommandée

Prévoir à l’avance le nombre de VM que l’on souhaite installer sur le serveur Hyper-V, faire le calcul et prévoir un facteur de sécurité et d’évolution de 50 % au moins.

STOCKAGE ET DISQUES

> Le maillon faible

Les VM n’ont pas des besoins différents en terme de stockage comparativement à une véritable OS : il faut prévoir suffisamment de Go de stockage pour accueillir l’ensemble des VM, des fichiers applicatifs, des bases de données,…

L’exécution de plusieurs VM sur un même serveur physique, a directement un impact sur les performances des entrées/sorties des disques en raison des besoins d’accés simultanés et concurrents aux données (les benchmarks mesurent souvent les IOPS : Input/Output Operations Per Second).

Le stockage peut donc vite devenir un maillon faible pour les performances du serveur Hyper-V.

> Stockage minimal

• Minimum : 10 Go
• Recommandé : 40 Go ou plus

Attention : les serveurs comportant plus de 16 Go de RAM requièrent plus d’espace disques pour la mémoire virtuelle et les fichiers dump de la mémoire.

Pour information :

• Hyper-V en mode Windows 2008 Core à besoin nativement d’environ 3 Go d’espace disque
• Hyper-V en mode Windows 2008 en mode complet à besoin nativement d’environ 8 Go d’espace disque

> Rapidité du stockage

Globalement, pour les serveurs autonomes il est recommandé d’utiliser des disques SATA ou mieux, des SAS qui permettent d’obtenir un très bon rapport performance/prix.

La séparation classique OS / DATA est tout fait d’actualité sur un serveur Hyper-V.

Configuration minimale :

• OS parent + Hyper-V sur un volume en RAID 1.
• DATA sur un volume en RAID 5.
• Au moins un disque en spare hot plug pour la sécurité en cas de perte d’un disque.

Configuration recommandée :

• OS parent + Hyper-V sur un volume en RAID 1.
• DATA sur un volume en RAID 10 (avec autant de disques que possible !)
• Un ou deux disques en spare hot plug.

Pour diminuer les IOPS des disques et donc augmenter les performances du stockage, voici quelques pistes :

• Utiliser des technologies de disque récentes comme le SAS.
• Utiliser des systèmes RAID.
• Répartir les VM entre plusieurs disques physiques disctincts.
• Dans l’idéal, utiliser du stockage réseau de type SAN (mais plus cher et plus complexe à gérer)

LE RESEAU

Le débit réseau des VM est comparable au débit réseau des mêmes OS réels… A la différence que les flux réseau peuvent devenir un goulot d’étranglement si la gestion des cartes réseaux physique est mal gérée.

La règle idéale serait 1 VM = 1 carte réseau physique.

> Switchs virtuels

Hyper-V introduit des nouveaux périphériques virtuels, les «  switchs virtuels  » qui se comportent comme des switchs de niveaux 2.
Ces switchs virtuels supportent le VLAN Tagging ce qui permet de mutualiser plusieurs réseaux sur une même carte. Attention ! Pour mettre en oeuvre le VLAN Tagging, il faut que vos équipements réseau prennent en charge cette fonctionnalité : pour cela, vérifier qu’ils supportent les Trames 802.1.Q.

> Configuration minimale :

• Une carte réseau 100/1000 Mbps par serveur physique
• Une carte réseau virtuelle par VM

Cette configuration peut fonctionner sans problème pour quelques VM faisant peut de trafic réseau. Les soucis vont apparaître lorsque la charge réseau augmente : tout le flux passe par le même tuyau et les performances vont probablement chuter.

Autre problème : la carte réseau physique risque de couper ponctuellement ou durablement ce qui provoquera la perte de connectivé pour l’administration du serveur Hyper-V. Une bonne idée est donc de dédier une carte à l’administration et une ou plusieurs cartes pour les VM (voir ci après).

> Bien configurer les cartes réseau.

Une bonne pratique consiste à renommer les cartes réseau et à identifier celle qui sera utilisée pour l’administration et celle(s) dédiée(s) aux VM.

La carte réseau dédié aux VM n’a pas besoin d’adresse IP sur la partition parent et encore moins des services de partage de fichiers et d’imprimantes. Cela évite aussi l’enregistrement involontaire (et polluant) dans le système DNS.

Dans Hyper-V R2, l’option d’isolation est native. Il est possible de créer un réseau (externe) sans qu’il ne soit connecté à la partition parent. Pour cela il suffit de décocher la case suivante lors de la création du switch virtuel :

Swich Virtuel Hyper-V

> Configuration recommandée :

• Quatre cartes réseau 1000 Mbps par serveur physique
• Une carte réseau physique par VM
• Une carte réseau dédiée à l’administration

Petit bonus : un article intéressant à lire sur les lenteurs réseau éventuelles avec HyperV.

>> Suite du dossier : Hyper-v : performances et optimisation de l’hyperviseur.

Plan du dossier Hyper-v : performances et optimisation :

1. Introduction
2. Performances et optimisations du hardware
3. Performances et optimisations de l’hyperviseur Hyper-V
4. Performances et optimisations de l’OS parent
5. Performances et optimisations des machines virtuelles (VM)
6. Exemples