Virtualiser SQL Server : ce qu’il faut savoir avant de se lancer

Le Licencing

Commençons par aborder la question du licencing de SQL Server, qui en lui-même peut s’avérer être un cauchemar, et cela ne s’est pas arrangé depuis le lancement de SQL Server 2012. Le mode de licence SQL Server dépend directement de la version et de l’édition, du nombre de processeurs de votre machine, et si elle est physique ou virtuelle.

Par exemple, SQL Server 2012 est disponible en trois éditions : Enterprise, Business Intelligence et Standard. Chacune des éditions peut être licenciée par processeur ou par serveur. Dans ce dernier cas, vous devez également acheter une licence CAL pour chaque client et utilisateur se connectant à la solution. Si vous virtualisez SQL Server Enterprise, vous pouvez licencier le produit au niveau de la VM ou de l’hôte. Vous pouvez licencier les éditions Standard et Business Intelligence de SQL Server seulement par VM. Ce que vous pouvez faire avec chacune des versions dépend de l’édition que vous licenciez et si vous avez souscrit à la Software Assurance (SA). Par exemple, vous pouvez licencier les éditions Standard et Enterprise au nombre de coeur dans la VM, mais pas l’édition Business Intelligence. De plus, le minimum est de 4 coeurs par un mode de licence au coeur, même si vous ne faites fonctionner que deux CPUs virtuels. Si vous voulez déplacer votre VM, vous devrez également attendre 90 jours entre chaque déplacement, à moins que vous n'ayez souscrit à la SA.

Ainsi, cela signifie que votre entreprise pourrait finir par être confrontée à de nombreux coûts supplémentaires en matière le licencing de VM. Les économies générées avec la virtualisation pourraient alors être atténuées à cause de la structure du mode de licence de SQL Server. Même s’il est important de planifier et de provisioner minutieusement vos VM pour SQL Server, vous ne maîtrisez pas toujours un tel provisioning. Par exemple, si vous distribuez vos instances de SQL Server Standard sur plusieurs VM à base de seulement deux coeurs virtuels, vous risquez de payer bien plus que si vous aviez à consolider ces instances sur une unique machine physique. Les licences SQL Server s’appliquent à l’environnement OS sous-jacent, quel que soit le nombre d’instance dans cet environnement. Un serveur physique compte pour un OSE, tout comme une VM, et cela peut donc s’ajouter au final.

Résultat : ne virtualisez pas SQL Server à moins que vous compreniez parfaitement les implications du mode de licencing.

La virtualisation de SQL Server : les performances

Parce que les technologies de virtualisation ont fait de grands progrès, de nombreuses entreprises ont adopté cette technologie. Pourtant, la capacité d’une VM à pouvoir supporter votre environnement SQL Server doit être évalué avec beaucoup d’attention avant de passer le cap.

L’une des grandes préoccupations est par exemple la façon dont les VM et les données SQL Server sont stockées. Même dans les meilleures conditions, les éventuels conflits de ressources doivent être pris en compte. Existe-t-il d’autres VM qui partagent le même stockage en réseau (SAN) ? Les données sont-elles stockées au même endroit ? Si c’est le cas, votre environnement SQL Server pourrait être assujetti à ces autres machines.

Pour les implémentations de bases de données à petite échelle, les conflits de ressources ne seront probablement pas un problème, surtout avec les avancées réalisées en matière de gestion des ressources. Toutefois les grands systèmes avec de lourds traitements peuvent rapidement mettre à l’épreuve les entrées-sorties de l’hôte. Devoir reconstruire de  grands index compressés, par exemple, peut solliciter au maximum les CPU, tout comme les opérations de maintenance - comme la défragmentation. De nombreux administrateurs de bases de données recommandent d’éviter le stockage iSCSI et Gigabit Ethernet  et de n'utiliser des environnements de stockage à même de transmettre des données de façon systématique à plus de 100 Mo par secondes.

Si le stockage ne peut pas satisfaire pleinement à vos exigences, assurez-vous de disposer de suffisamment de mémoire pour compenser les éventuelles lacunes, ou alors anticipez les pics de demandes. Vos CPU doivent également être capables de supporter ces surcharges de capacités. Même si les outils de virtualisation sont capables de supporter des applications de plus en plus gourmandes, ils ont toutefois des limites en matière du nombre de CPU virtuels et de quantité de mémoire supportés.

Si vous disposez de systèmes SQL Server gourmands en CPU et en mémoire, ne les virtualisez pas à moins d’effectuer des tests adéquats et de vous assurer de bonnes performances. Si votre système est trop exigeant, au point que vous ne puissiez pas faire fonctionner d’autres VM ou instances de SQL Server sur l’hôte, vous n’aurez que peu d’avantages à opter pour la virtualisation. Si plusieurs VM tournent sur l’hôte (ce qui est la raison première de la virtualisation), un éventuel conflit de ressources est un facteur à intégrer dans vos plans. Que se passe-t-il si plusieurs applications atteignent un pic d’utilisation en même temps ? Dans un environnement virtualisé, les problèmes de conflits vont bien au-delà d’une simple base de données.

Traduit par la rédaction