La mode est à la virtualisation des serveurs. Mais virtualiser sans discernement, simplement parce que c’est à la mode est dangereux… Particulièrement en matière de SGBD relationnels pour lesquels les performances se dégradent très vite dans bien des cas !

Voici les préconisations de Microsoft vues aux techDays 2010 en matière de non virtualisation :

…cela en dit long sur le décalage qu’il y a entre les pros de la virtualisation qui pensent augmenter les performances de serveur déjà déficients, en optant pour la virtualisation !

Quelque soit l’outil choisit, toute solution de virtualisation (VMware, Virtual Server, Hyper V…) dégrade intrinsèquement les performances des SGBDR. L’intérêt de la virtualisation réside dans la facilité de maintenance et le lissage de charge de petits serveurs (mutualisation de ressources), ainsi que par les économies d’échelle réalisables (licences).
Ce n’est d’ailleurs pas par hasard que certains éditeurs de SGBDR proposent des solutions spécifiques de virtualisation de leurs propres SGBDR comme c’est le cas d’Oracle VM…

Le gros problème de la virtualisation se situe dans les performances du serveur de bases de données. En effet, un SGBDR n’est pas un serveur de fichier ni un serveur applicatif. Il agence ses données sous la forme d’objets logique ensemblistes structurés sous forme de pages (mémoire et disque). Chaque ensemble de données pouvant être verrouillé pour les traitements de chaque utilisateur/process et chaque process pouvant être multithreadé suivant la complexité d’accès et le volume de données à traiter, et enfin, chaque objet logique pouvant être rendu plus ou moins accessible à telle ou tel commande (SELECT, INSERT, UPDATE, DELETE) pour tel ou tel utilisateur par le biais des privilèges. On se rend compte en définitive qu’un SGBDR reproduit à son niveau ce que fait un OS, mais sur des objets logiques dont le stockage est hybride : mémoire pour la mis en cache et disque pour la persistance.

En définitive il faut comprendre qu’un SGBDR incorpore son propre OS indépendant de celui du système et assure seule et de manière autonome l’essentiel de la manipulation de la RAM, des disques et des threads… Dans SQL Server l’OS interne à pour nom SOS pour SQL Server OS.

L’avantage de cette architecture est de permettre de tirer partie du maximum de ressources par le biais d’algorithmes de bas niveau spécifique au SGBDR. L’inconvénient est que le SGBDR est à la fois aveugle de ce que fait le système et exigeant en terme de ressources lorsque cela est nécessaire. C’est pourquoi on recommande d’installer un serveur SQL sur une machine dédiée. On devra donc n’installer aucun autre applicatif ni service sur la machine, pas même antivirus ou firewal, ceci devant être géré en amont (DMZ) et dans la mesure du possible il convient de désactiver tous les services inutiles.
Dans l’ordre d’importance des ressources d’un serveur de bases de données on trouve :

• en premier la RAM qui doit être calculé par rapport à la fenêtre des données (le volume des 20% de données qui sont utilisées à 80% – Loi de Pareto…);
• en second les disques qui doivent être performants et pour lesquels on cherchera à en tirer le meilleur partit;
• et en dernier les processeurs et leur cadencement.

Les algorithmes en jeu notamment pour la mis en cache comme pour la gestion de la persistance tirent partie des accès physiques directs aux ressources. Donnons quelques exemples :

Écriture physique des données : les écritures de données dans les fichiers de la base se font depuis la mémoire et par session programmées toute les minutes. Afin d’accélérer les écritures au maximum, le process d’écriture interne des meilleurs SGBDR comme SQL Server, regroupe les écritures à effectuer par contiguïté géographique par rapport aux plateaux des disques physiques qu’utilise la base. Ceci ne permet d’accélérer réellement les performances de manière drastique que si plusieurs conditions sont respectées :

• on a affaire à des disques physiques et non des unités logiques (parallélisation des écritures)
• on a créé des fichiers de données de grande taille (en principe pour un volume expectatif de quelques années – durée de vie du serveur) réservant ainsi l’espace de stockage sur lesdits disques physiques
• et enfin on a utilisé un niveau de RAID compatible avec cette visibilité (évitez dons les RAID 5 ou 6).

Parallélisation des accès : si les index d’une table sont stockées dans un espace de stockage physiquement indépendant des lignes de la table, alors l’insertion, la modification, comme la suppression d’une ligne, alors le serveur SQL est capable de lancer deux threads permettant de manière parallèles de modifier d’un côté le fichier contenant les lignes de tables et de l’autre celui contenant les index. De la même manière si les tables et index sont stockées dans des espaces physiquement indépendant, voir si les tables et les index sont partitionnés sur plusieurs storages physiquement distincts, il sera possible d’alimenter la mémoire en cas de défaut de cache beaucoup plus rapidement par le fait que les processus de lecture pourrons être lancés en parallèle. N’oubliez jamais que tout ceci est rendu possible et grandement facilité par l’aspect ensembliste d’une base de données qui considère qu’il n’existe aucun ordre d’aucune sorte dans les lignes d’une table, ce qui permet aux traitements d’être naturellement massivement parallèle !

Grâce à cette façon de concevoir le stockage, les temps de traitement sont divisés dans un facteur important, découlant directement du niveau de parallélisation des accès physiques et du découpage des données (index, lignes de table), voire du partitionnement (découpage des tables par facteur sémantique) dans les espaces de stockage, ainsi que de la vitesse de rotation des disques.

Tous les SGBDR ont des algorithmes similaires pour la gestion de la RAM et pour le pilotage des threads. C’est pourquoi les grands éditeurs de SGBDR propose de nombreuses options de paramétrage de l’exploitation des ressources physiques du serveur sur lequel il est hébergé : quels CPU utiliser, quelle quantité de RAM allouer, comment structurer les espaces de stockage, quelles sont les limites d’utilisation en parallèle des processeurs, etc.

Compte tenu de l’extrême impact des paramètres, nous devons donc attirer votre attention sur le fait que quelque soit la couche de virtualisation, les performances des serveurs SQL sont notablement tirées vers le bas par le fait qu’il ne perçoit pas correctement l’univers physique lorsqu’il agit sur un serveur virtuel et qu’en sus il doit encaisser des temps d’attente erratique dus aux process de gestion de la couche virtuelle ainsi que des autres serveurs. Ceci fait que, sans compter les allongements de temps de process dû à la virtualisation, les transactions s’allongent, les blocages se rallongent et les interblocages (étreintes fatales ou verrous mortels) ont statistiquement plus de chance de survenir que dans le cas ou le serveur SQL agit seul sur une machine dédié.

En particulier, et comme nous venons de la dire, par sa nature ensembliste (1) de traitement de l’information, la plupart des opérations basiques qu’un SGBDR effectue peuvent être parallélisées. Encore faut-il que l’architecture du serveur le permette en prévoyant les ressources adéquates et en particulier plusieurs processeurs, plusieurs espaces de stockages physiquement indépendants voire plusieurs pans de mémoire distincts comme c’est le cas de l’architecture NUMA (2).

On aura compris que les problèmes engendrés par la virtualisation, même avec des techniques avancées de disque « pass through » (par exemple le Raw Device Mapping de VMWare), ne sont pas compatible avec des exigences en matière de temps de réponse.

Du fait que les SGBDR sont capables de déterminer sur un disque l’emplacement le meilleur pour les fichiers de la base (données et transactions), il convient de s’assurer que tout est fait dans ce sens. En particulier on veillera à prendre des disques ayant la plus grande vitesse de rotation, car elle constitue le facteur déterminant pour obtenir les meilleures performances des SGBDR.
Dans le même esprit, il ne faut pas que le SGBDR soit trompé par un SAN qui masque les accès physiques aux disques. C’est pourquoi il faut combiner ce premier paramètre avec le fait que les LUN doivent impérativement être taillé sur des disques physiques et non sur un conglomérat de disques.
Ensuite, il faut se préoccuper de la taille des strips (ou chunk) dans la configuration RAID du SAN. Par exemple MS SQL Server recommande une taille de strip de 64 Ko ou 256 Ko selon que les tables visées sont en dessous ou au dessus de la taille de 100 Mo. Enfin, il est à considérer l’alignement des partitions (3) qui dans le cas de stockage de données très importantes peut s’avérer intéressant.

En dernier recours il est possible d’utiliser une baie de disque SSD (Solid State Device) qui, bien que son prix soit prohibitif, permet de diviser par 100 les temps de réponse au niveau des IO en sus d’économiser notablement l’énergie électrique et dégager beaucoup moins de chaleur (donc moins recourir à la climatisation). Mais la durée de vies des disques SSD est incompatible avec l’intensité des écritures engendrées par un haut niveau transactionnel…

Sachez aussi que toutes les solutions de virtualisation ont des limites assez basses en terme de ressources. Par exemple Hyper V, la dernière en date, ne peut aller actuellement au delà de 4 CPU et 64 Go de mémoire (Windows Server 2008 R2) ce qui est bien trop peu pour de multiples grosses bases.

En sus, il faut savoir que certains compteurs du moniteur de performance ne présentent pas les valeurs réelles de mesure physique du fait de la couche de virtualisation. Ces mesures sont soit surestimées sous sous estimées, soit totalement fausses, ce qui fait qu’en pratique, mesurer les performances OS d’un système virtualisé est impossible !

Il arrive assez souvent que des ingénieurs systèmes, pratiquant des tests de comparaison entre une solution applicative virtualisée et la même solution en serveur physique ne constate aucune différence. C’est logique quand on sait que rare sont les ingénieurs système à savoir administrer proprement un serveur de bases de données. Comment les espaces de stockage sont-ils gérés ? Quel est le mode de journalisation choisit ? Quelle niveau de parallélisation des CPU as-t-on autorisé ?… sont des questions qui sont généralement inconnus des spécialistes systèmes. Pire, la plupart d’entre eux pensent savoir comment faire tourner un serveur SQL par analogie avec un serveur d’objet, web ou de fichier, ce qui bien évidemment n’a strictement rien à voir ! Ils sont intimement persuadés que tous les problèmes se résolvent au niveau système ou hardware. Or l’architecture interne d’un SGBDR reproduit un OS spécialisé qui n’a que peu de chose à voir avec ceux que connaissent les administrateurs systèmes. Il n’est qu’à voir les cursus d’administration que les éditeurs comme Microsoft proposent pour se convaincre que l’administration des SGBDR n’a rien à voir avec le « système ». En effet pour devenir MCDBA il faut suivre 4 à 5 cours soit environ 12 jours de formation et réussir au moins 3 examens !

http://www.microsoft.com/france/formation/cours/sql2005.mspx

Quand on voit par exemple les préconisations pour faire tourner un SQL Server un peu costaud avec Hyper V dans le monde Microsoft il me semble peu probable que cette technique soit économe en installation, administration ni en ressources…

On aura sans doute compris que je ne puis recommander la virtualisation de SQL Server lorsque :

• on attend des performances du système
• la volumétrie de données ou le nombre de transaction est important

En revanche, la solution de virtualiser est acceptable lorsque :

• les serveurs sont peu sollicité et avec des bases de faible volumétrie
• il s’agit de serveurs pour lesquels les performances n’ont pas d’importance (serveurs de développement ou de tests par exemple).

Enfin, je terminerais par le simple bon sens (4) qui permet sérieusement de mettre en doute le fait que rajouter une couche logicielle d’interface augmente les performances…

TRÈS IMPORTANT – les dangers de la virtualisation

A trop compter sur les systèmes de virtualisation pour sauvegarder les bases d’un SGBDR, il est possible et même très probable de les perdre…
Ceci arrive régulièrement à des utilisateurs peu au fait des problématiques engendrées par la virtualisation.
En effet, certains utilisateurs considèrent que faire des sauvegardes par le biais d’une copie de fichiers effectué au niveau du serveur virtuel est largement suffisant. Or ce n’est absolument pas le cas. En effet les écritures des différents fichiers d’une base (données, index, transactions…), doivent être pour certains synchrones et pour l’ensemble coordonnées, afin que la base soit intègre. Or il est fréquent que la copie faite par la machine virtuelle, ne soit pas exécutée dans le même ordre que ce que le SGBDR fait en pratique. De ce fait il est alors évident qu’une telle restauration n’aura aucune chance de permettre de restaurer la base qui sera considérée comme corrompue par le serveur et pour laquelle il est probable qu’aucune réparation ne puisse être effectuée !
Par exemple et en pratique, avec une virtualisation sous WMWare ou Hyper V, Microsoft ne garantit en aucune façon la reprise d’une base par un mécanisme de snapshot au niveau système y compris à l’aide de VSS (Volume Shadow copy Service).
Comme le dit bien David Ballafeuf :
[…]le cluster vmWare ne remplacera jamais le bon vieux backup[…]. C’est comme de dire : j’ai un RAID-10 donc je n’ai pas besoin de faire de backups.
L’alternative au backup database est d’utiliser des techniques de sauvegarde au niveau du matériel (snapshot et copie de volumes logiques) ou d’utiliser un outil tiers type backupexec ou netbackup pour faire des backups de répertoires entiers en collaboration avec VSS et SQLWriter. Mais là encore rien à voir avec des snapshots vmWare. Le snapshot vmWare ne discute pas avec SQLWriter et VSS pour faire des backups cohérents, donc la fonctionnalité n’est pas supportée. En théorie il faut stopper le guest, faire le snapshot, et redémarrer la VM pour avoir une image consistante.
Or comme on le sait, arrêter une base ou pire, un serveur, fait perdre la mise en cache des données, des procédures des plans de requêtes ainsi que des statistiques d’exécutions collectées, bref, tout ce qui fait que le serveur s’auto optimise pour assurer des performances maximales. Ce n’est donc certainement pas une bonne pratique !
Enfin, dans le cas de Microsoft, le support de SQL Server n’est pas assuré pleinement en cas de virtualisation et en cas de doute sur un problème, il vous sera demandé de reproduire l’incident sur une machine physique !!!

Autre problème, les éditeurs comme VMWare mettent en garde les utilisateurs sur le fait que l’utilisation de certaines techniques dans le SGBDR risque de rendre le système instable en cas de restauration. Il en est ainsi en cas de mise en Å“uvre du log shipping, du mirroring asynchrone et de la réplication de données…

NOTES
(1) La théorie sous jacente au SGBDR est l’algèbre relationnelle qui constitue une partie de la théorie des théories des ensembles. Or une des grandes particularités de cette théorie est l’absence d’ordre qui conduit à considérer que tout élément peut être manipulé sur le même pied d’égalité ce qui se traduit dans le monde physique par des processus tournant en parallèle aussi bien pour les opérations d’accès (lectures, écritures) que pour les opérations de traitement des données (recherches, jointures, agrégats…).
(2) NUMA : Non-Uniform Memory Access, permet de définir des affinités entre chaque processeur et un pan de la RAM qui lui affecté de manière exclusive ce qui évite les accès concurrents au même espace RAM et donc la pose de verrous en mémoire. Cette technique devient intéressante dès que le nombre de processeur atteint 8 et que le besoin de RAM est considérable.
(3) Sur ce sujet dans le cadre de l’exploitation de SQL Server, voire l’intéressante étude menée par David Barbarin : http://mikedavem.developpez.com/sqlserver/tutoriels/architecture/
(4) Qui est sans doute « la chose la mieux partagée du monde » comme le disait Descartes auquel mon prof de philosophie s’empressait de rajouter « c’est pourquoi chacun en a si peu… » !

Quelques articles sur le sujet :
Virtualisation for the DBA part 3 – SQL Server Performance
SQL Server virtualization pros and cons: Weigh the performance impact
Reasons Why You Shouldn’t Virtualize SQL Server
Three setbacks when designing Hyper-V R2 High Availability
SQL Server on VMware Server
Monitor SQL Server Performance on VMware
Support policy for Microsoft SQL Server products that are running in a hardware virtualization environment
Server Virtualization Validation Program

Pour terminer, voici un point de vue que j’ai exprimé dans un poste en date du 7 septembre 2010 :

[ les serveurs virtuels sont à bannir… Quel que soit le type de virtualisation ? ]

C’est surtout que les SGBDR utilisent un OS interne dont les caractéristiques sont incompatible avec les OS systèmes. Par exemple le pas d’horloge de l’OS SQL Server (SELECT @@TIMETICKS qui donne 31,250ms) est notablement plus lent que celui de l’OS Windows, et ainsi de suite comme la granularité de lecture des données (page de 8Ko, extensions de 64 Ko) du SGBDR contre celle de l’OS (1 à 2 Ko – formatage).

Bref, la virtualisation faite sur de tels paramètres système, contrarie systématiquement le comportement du SGBDR.

Demandez vous pourquoi chaque SGBDR possède son propre planificateur de tâche alors que maint quantité d’outil existe (du planificateur de tache de Windows aux outils comme $universe…). C’est simplement pour ques les processus planifiés puissent s’activer en se calant sur le pas d’horloge du SGBDR et non pas sur celui de l’OS afin de ne pas gêner les transactions en cours !

Enfin, et pour compléter le panorama, sachez que les snapshot systèmes effectués sur un SGBDR ne permettent pas d’obtenir une base de données saine, car le temps de « freezer » l’un après l’autre les fichiers de données et de transaction et de les copier, les fichiers peuvent se trouver désynchronisés et de ce fait la base de données devient corrompue !
A lire par exemple pour MS SQL Server : http://support.microsoft.com/kb/956893/en-us

-------- 

Frédéric Brouard, SQLpro - ARCHITECTE DE DONNÉES, http://sqlpro.developpez.com/ 

Expert bases de données relationnelles et langage SQL. MVP Microsoft SQL Server 

www.sqlspot.com : modélisation, conseil, audit, optimisation, tuning, formation 

* * * * *  Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence  * * * * *