Intégration continue

Une question qui revient souvent, concerne la virtualisation de SQL Server : la question précise est de savoir si SQL Server peut fonctionner sur un hôte virtuel.

Cette question est légitime lorsqu’on connaît l’engouement actuel pour la virtualisation. Certaines entreprises envisagent de virtualiser tous leurs serveurs sans exception dans le but de simplifier l’administration et d’assurer la consolidation (comprendre réduire le nombre de serveurs physiques).

Microsoft a publié un livre blanc : Ce document ne précise pas dans quelles conditions la virtualisation est conseillée. En lisant entre les lignes, il est dit que les environnements de développement ou d’intégration sont de bons candidats à la virtualisation.

Ce que ne dit pas clairement Microsoft, c’est si la virtualisation de serveurs de production est souhaitable. En fait, c’est parce que la réponse est plus complexe qu’elle n’y paraît. D’abord, toutes les versions de SQL Server ne sont pas supportées et il est nécessaire de respecter des configurations très précises. Ensuite, dans le cas de SQL Server, la virtualisation n’est pas indispensable et cela pour trois raisons :

1. La virtualisation permet de faire cohabiter sur un même hôte, des OS/applications qui n’ont pas les mêmes configurations et qui ne peuvent pas cohabiter ensemble sur un même serveur. Par rapport à ce point, en fait, par sa conception, il est tout à fait possible de faire cohabiter différentes versions/éditions/configuration de SQL Server en faisant appel à l’utilisation des multi-instances.
2. La virtualisation possède aussi des mécanismes pour déplacer rapidement (et souvent automatiquement) une machine virtuelle sur un hôte physique différent. En fait dans le cas de SQL Server, il possible d’utiliser les mécanismes de haute disponibilité avec bascule automatique (clustering et mise en miroir) pour le même résultat.
3. SQL Server supporte une couche basse particulière SQLOS. Cette couche permet, entre autres choses, d’exploiter au mieux les équipements physiques du serveur. Qui dit virtualisation, dit que le matériel est en général émulé. Cela peut coûter très cher en termes de performances à SQL Server parce que la couche physique est inaccessible, mais il faut aussi prendre en compte la charge de l’émulation. Dans le pire des cas, nous pouvons constater une perte de performances de plus de 30%.

Pour toutes ces raisons, la virtualisation n’est pas indispensable. Mais revenons à la question initiale et la réponse tient en deux points :

• Si l’environnement est critique en termes de performances. Par exemple, une instance dont la volumétrie est conséquente (par exemple plusieurs centaines de giga-octets) et qui supporte les bases de données de production. Dans ce cas, la virtualisation est à proscrire. Il est important que la couche SQLOS accède directement à la couche physique. Le travail d’un administrateur est d’optimiser au maximum les performances de SQL Server pour obtenir les meilleures performances.
• Pour les instances moins critiques (bases de données d’un service ou d’un département par exemple), la virtualisation est possible mais dans cette hypothèse, il est important et indispensable d’intégrer dans le calcul des performances, la charge inhérente à la virtualisation. Or, à l’usage, il apparaît que ce travail n’est jamais fait correctement tant elle est complexe.

Autre exemple de virtualisation : Un autre cas concerne les environnements de tests ou l’intégration continue pour les entreprises éditrices de logiciels. En effet, dans le cas l’intégration continue, il faut assurer les tests dans tous les supports prévus (OS, bases de données, etc.) Pour assurer les tests sur différentes versions de SQL Server, la virtualisation est la meilleure solution. On dispose d’autant de machines virtuelles que de versions de SQL Server à tester : il n’est pas question de disposer de serveurs physiques

Autres références : SQL Server 2008 Virtualization, white-paper, Virtualisation : Les 10 meilleures pratiques en matière de virtualisation