Consolidation : SQL Server et Hyper-V

Après avoir virtualisé des serveurs d’impression, des serveurs Exchange 2007 (Hub), des serveurs applicatifs divers, des postes de travail sous Windows XP, des serveurs Web, Sharepoint, etc…, pourquoi ne pas virtualiser un serveur SQL ? Certains se sont déjà posés la question.

Au premier abord, ma première pensée a été : négatif, autant profiter de toute la puissance du serveur pour ne faire tourner que SQL Server sans pâtir de la surcharge système occasionnée par la virtualisation.

Et puis j’ai testé, pour ne pas mourir idiot. D’autant plus que la virtualisation a le vent en poupe, que ce soit pour des raisons écologiques (Green IT) ou de coût (facture électrique revue à la baisse)

J’ai donc décidé de créer sur un serveur Windows 2008 avec hyper-V une machine virtuelle (Windows 2008 x64 avec 8 Gb de RAM et 4 processeurs). J’ai ensuite créé un second disque VHD afin de poser les fichiers de données de SQL Server sur un autre disque que le disque système.

J’ai récupéré une petite base de donnée (un peu plus de 7 Gb) de mon environnement de production.

Tous les tests d’accès aux données se sont révélés tout à fait corrects. Voire surprenant. A croire que les couches de virtualisation étaient transparentes… Il n’y a donc pas de contre-indication à virtualiser un serveur SQL (même avec plusieurs instances nommées). Cela ne diffère en rien d’un serveur physique, le comportement est identique.

J’ai aussi testé le backup, voici les résultats :

Sur SQL Server 2000 (environnement de production), serveur 4 processeurs, 6 Gb de RAM, disques de données et de backup sur des baies différentes au sein du même SAN, le backup a pris 6 minutes et 34 secondes.

Sur SQL Server 2008 (environnement de test Hyper-V), serveur hôte 16 cœurs, 64 Gb de RAM, machine virtuelle : 4 processeurs, 8 Gb de RAM, même fichier VHD pour les données et les backups sur une LUN du SAN, le backup a pris 1 minute et 46 secondes. Ok, j’ai un peu triché, j’ai compressé mon backup histoire de réduire les IO, mais la machine virtuelle a parfaitement encaissé la surcharge CPU et l’activité disque.

Un gain de 74% en temps d’exécution pour un backup de 7.146Gb entre mon environnement de production et mon environnement de test. Je suis presque convaincu …

Quelles sont les limites ?

La première limite concerne le nombre de CPU qui dans cette version de Hyper-V est limitée à 4.
La seconde limite concerne la taille des disques VHD. Dans Hyper-V, il n’est pas possible de passer au delà de 126Gb. Ensuite, il convient de créer plusieurs VHD et de répartir les données sur les différents disques.
Pour des environnements SQL relativement stressés au niveau CPU et réseau, une surcharge système est à prendre en considération.
Une dernière limite concerne la charge du serveur hôte lui-même. En effet, si un projet de virtualisation voit le jour, il y a fort à parier que cela est du à une volonté de consolidation de serveurs afin de réduire les couts et la consommation énergétique. Donc plusieurs machines virtuelles vont ainsi se partager les ressources disques de la LUN hébergeant les VHD (à moins de présenter plusieurs LUN au serveur hôte).

Hyper-V ne permet pas dans la version actuelle de créer un cluster pour des machines virtuelles. Tout au plus il est possible de créer un cluster Hyper-V qui en cas de panne matérielle sur un des serveurs hôtes fait basculer toutes les machines virtuelles sur le second nœud Hyper-V. Sur Hyper-V 2 qui sera prochainement disponible dans Windows 2008 R2, la possibilité de faire du Live Migration de machine virtuelle améliorera la disponibilité des serveurs virtualisés. De même l’apparition de disques cluster partagés (afin de pouvoir virtualiser des clusters CCR Exchange 2007) dans Hyper-V 2 laisse entrevoir la possibilité de créer un cluster SQL Server virtualisé  dans une prochaine version (dernière ligne de la page 11 du document SQL Server Consolidation at Microsoft ).

Quelques recommandations :

Les performances des disques VHD de taille fixe sont supérieures aux disques de taille variable.
Si vous avez besoin d’espace et de performances élevées au niveau des IO, il est intéressant d’utiliser un disque passthru. La machine virtuelle se voit ainsi présenté directement une LUN sur la SAN.
Même si le disque de boot des machines virtuelles doit être de type IDE, pensez à mettre les autres disques en SCSI …
Bien utiliser tous les drivers Synthetic de Hyper-V, ne pas laisser les legacy drivers … Cause réelle et sérieuse de ralentissements !

Conclusion :

Un excellent document sur le sujet : Running SQL Server 2008 in a Hyper-V Environment – Best Practices and Performance Recommendations.

Comment Microsoft consolide ses serveurs : SQL Server Consolidation at Microsoft

En conclusion, la virtualisation de serveur SQL m’a convaincu, enfin en ce qui concerne les serveurs de développement et de pré-production. Vu la volumétrie de stockage et l’activité de mes serveurs (parfois plus de 6500 transactions/seconde), il n’est pas question de virtualiser les serveurs de production. Enfin, pour l’instant ….

A propos Christophe

Consultant SQL Server Formateur certifié Microsoft MVP SQL Server MCM SQL Server 2008
Cet article a été publié dans SQL Server. Ajoutez ce permalien à vos favoris.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s