Virtualisation vs machine physique

Version imprimable

03/05/2011, 11h26
richy93

Virtualisation vs machine physique

Bonjour,

Je souhaiterai connaitre votre avis quant à l'utilisation de la technologie de virtualisation (plus particulièrement celle de VMWare) dans le cadre des serveurs de base de données SQL Server 2008 (et 2008 R2).
Nous avons actuellement une plateforme totalement virtualisée sur laquelle tourne :
1 serveur de distribution (pour la réplication) :
- Aucune base ne tourne autre que celle de distribution. Ce serveur est complétement dédié à son rôle de distributeur.
1 serveur abonné :
- En terme de volumétrie, on peut compter sur du 10Go de données environ (beaucoup de lignes avec un nombre important d'insertions/suppressions)

Est-ce que ces types de serveurs peuvent être virtualisés sans subir une baisse significative de performance ?

Merci d'avance,
03/05/2011, 12h13
WOLO Laurent

En général, il faut tenir compte d'autres paramètres comme le nombre de transaction/s, le nombre de processeurs, la taille de la RAM ... sur les machines physiques et virtuelles.
03/05/2011, 12h15
suchiwa

Citation:

Envoyé par richy93

Bonjour,

Je souhaiterai connaitre votre avis quant à l'utilisation de la technologie de virtualisation (plus particulièrement celle de VMWare) dans le cadre des serveurs de base de données SQL Server 2008 (et 2008 R2).
Nous avons actuellement une plateforme totalement virtualisée sur laquelle tourne :
1 serveur de distribution (pour la réplication) :
- Aucune base ne tourne autre que celle de distribution. Ce serveur est complétement dédié à son rôle de distributeur.
1 serveur abonné :
- En terme de volumétrie, on peut compter sur du 10Go de données environ (beaucoup de lignes avec un nombre important d'insertions/suppressions)

Est-ce que ces types de serveurs peuvent être virtualisés sans subir une baisse significative de performance ?

Merci d'avance,

Bonjour,

Ca dépend.

Que veux tu quantifier ? Le volume de données par jour, par mois ou par utilisateur, le nombre de requêtes simultanées ?
Quels sont les I/O de tes disques, le RAID utilisé, le type de stockage ?

Plus tu ventiles tes disques (swap, log, data, systèmes...), tu les redondent entre eux, et plus tu optimises les performances.

Au niveau logiciel, c'est SQL Server 2008 sur du Windows 2008 server R2, peux pas mieux faire ici je pense.

Ton serveur est il intégré dans un domaine ?

Personnellement, j'utilise du 2005 et du 2008, pour de nombreux clients, je ne rencontre pas de difficulté particulière avec une couche virtuelle suppémentaire. Je fais en sorte de ne pas utiliser les logs et le tempDB sur le C:\, qui grossissent de façon croissante en fonction du temps.

Pour ma part, une baisse significative des performances doit être supérieur à 10%. (ta question de départ)

Maintenant, tu as peut être besoin d'une Entreprise Edition avec un cluster à plusieurs noeuds et une latence déterminée, ton projet devient de la haute disponiblité et là, c'est une nouveau projet qui commence...

Vincent
03/05/2011, 17h02
richy93

Merci pour votre réactivité!

Pour répondre à Vincent et après m'être renseigné auprès de l'équipe système :
- Les I/O disque : entre 160 et 180 IO/s
- Le RAID utilisé : 6 disques de 400 Go en RAID 10, soit 1200 Go utiles, à 15k tr/min
- Type de stockage : Baie de stockage SAS
- Le serveur est-il dans un domaine ? Oui

Concernant la partie "BDD" :
- Le volume de données : sur le serveur de BDD, 9 To sur environ 10 jours, mais seulement 10 Go environ répliquées via la publication (filtre sur les articles, toutes les tables ne sont pas répliquées, etc).
- Nombre de requêtes simultanées, pour le moment je ne peux pas savoir, étant en début de phase de test.
- Pour le moment et dans l'état actuel du projet, pas de besoin en cluster ou haute disponibilité.

Pour simplifier un peu ma question d'origine, je souhaiterai avoir un retour d'expérience sur des personnes qui ont pu comparer les performances de serveurs de BDD sur une plateforme virtualisée, et sur une plateforme physique (à CPU, RAM, disques identiques)
03/05/2011, 19h22
iberserk

Citation:

Pour ma part, une baisse significative des performances doit être supérieur à 10%. (ta question de départ)

La perte sera surement supérieur à cette valeur en virtualisant VS machine physique...(pas drastiquement certes...)
03/05/2011, 19h43
mikedavem

Le passage à la virtualisation affecte principalement les ressources du serveur à savoir la mémoire, les processeurs, les disques et le réseau.

Est ce que votre infrastructure peut être virtualisée ? Difficile de répondre comme cela. Il faudrait probablement avoir des métriques de peformances de référence de votre environnement physique et les comparer à celles de votre virtuel.

Cependant, lorsque vous virtualisez et que vous voulez un minimum de performances il faudra compter avec le paramétrage de votre environnement virtuel et pas se focaliser uniquement sur SQL Server. En effet bien que les principaux éditeurs de virtualisation ont fait d'énormes progrès il n'en reste pas moins que de rajouter une couche virtuelle entre SQL Server et les ressources du serveur peuvent affecter les performances surtout si le serveur SQL subit une charge de travail importante.

Pour avoir fait quelques migrations d'environnements physiques à virtuels avec VMWARE et SQL Server voici quelques pistes de configuration auxquels il faut prêter attention :

- S'assurer que les ressources qui seront alloués à la machine virtuelle qui héberge SQL Server ne seront pas partagés par d'autres machines virtuelles sur le même hôte ESX. D'autres machines virtuelles qui seraient consommatrices de ressources pourraient vampiriser celles de votre instance SQL Server
- S'assurer que la technologie Intel VT ou AMD-V puisse être utilisée par les hôtes physiques ESX. En principe c'est le cas avec les serveurs récents.
- S'assurer que les datastores ne soient pas partargés par d'autres machines virtuels ce qui pourrait engendrer des problèmes de performances certains du sous système disque.
- Vérifier que le paramètre de file d'attente des IO sur Vmware soit aligné avec celui des cartes HBA dans le cas d'un stockage SAN
- Permettre dans certains cas le dialogue direct entre le sous système disque et SQL Server sans passer par la couche virtuelle (option VMWARE à activer)
- vérifier l'alignement des partitions depuis la couche OS en passant par les VMFS de VMWARE jusqu'au SAN.
- Vérifier les performances des réseaux. Je pense notamment au problème de congestion réseau dû au partage des cartes réseaux entre les machines virtuelles d'un même hôte ESX

etc ...

++
04/05/2011, 00h15
richy93

Bonsoir à tous,

Je commence à y voir un peu plus clair. Je répondrai point par point à mikedavem :

Citation:

Envoyé par mikedavem

Le passage à la virtualisation affecte principalement les ressources du serveur à savoir la mémoire, les processeurs, les disques et le réseau.
--> Pour cette partie, je me repose sur les compétences de l'équipe système en charge de la virtualisation et à laquelle je fais confiance. Nous avons la chance pour le moment de ne "pas" être limités en terme d'évolution matérielle. Je considère pour ma part que les ressources ne sont pas un facteur limitant, tant que je reste dans le raisonnable et que je ne demande pas à m'attribuer les 48 CPU, 40Go de RAM et 10To de l'ESX...

Est ce que votre infrastructure peut être virtualisée ? Difficile de répondre comme cela. Il faudrait probablement avoir des métriques de peformances de référence de votre environnement physique et les comparer à celles de votre virtuel.
--> cf ci-dessus : cette question sort de mon périmètre (de compétences et de responsabilités) car je n'ai pas de vision globale au niveau système ou réseau de notre infrastructure, mais uniquement sur la partie base de données.

Cependant, lorsque vous virtualisez et que vous voulez un minimum de performances il faudra compter avec le paramétrage de votre environnement virtuel et pas se focaliser uniquement sur SQL Server. En effet bien que les principaux éditeurs de virtualisation ont fait d'énormes progrès il n'en reste pas moins que de rajouter une couche virtuelle entre SQL Server et les ressources du serveur peuvent affecter les performances surtout si le serveur SQL subit une charge de travail importante.
--> Effectivement, l'aspect matériel compte tout autant que la partie logicielle. D'où mes questions.

Pour avoir fait quelques migrations d'environnements physiques à virtuels avec VMWARE et SQL Server voici quelques pistes de configuration auxquels il faut prêter attention :

- S'assurer que les ressources qui seront alloués à la machine virtuelle qui héberge SQL Server ne seront pas partagés par d'autres machines virtuelles sur le même hôte ESX. D'autres machines virtuelles qui seraient consommatrices de ressources pourraient vampiriser celles de votre instance SQL Server
--> En l'occurrence, c'est l'effet inverse qu'il s'est produit la semaine dernière : mon serveur de distribution de test qui monopolisait toutes les IO disques, les quelques autres serveurs virtuels de test n'ont pas trop aimé...

- S'assurer que la technologie Intel VT ou AMD-V puisse être utilisée par les hôtes physiques ESX. En principe c'est le cas avec les serveurs récents.
--> C'est le cas

- S'assurer que les datastores ne soient pas partargés par d'autres machines virtuels ce qui pourrait engendrer des problèmes de performances certains du sous système disque.
--> Je me renseignerai sur ce point, je ne sais pas ce que sont les "datastores".

- Vérifier que le paramètre de file d'attente des IO sur Vmware soit aligné avec celui des cartes HBA dans le cas d'un stockage SAN
--> Idem, je me renseignerai. Info intéressante.

- Permettre dans certains cas le dialogue direct entre le sous système disque et SQL Server sans passer par la couche virtuelle (option VMWARE à activer)
--> L'équipe système en charge de la virtualisation m'a proposé cette solution. Je ne savais pas que c'était possible.

- vérifier l'alignement des partitions depuis la couche OS en passant par les VMFS de VMWARE jusqu'au SAN.
--> Je ne vois pas ce que tu entends par "alignement" de partition, mais je lirai ton article sur developpez.com à ce sujet.

- Vérifier les performances des réseaux. Je pense notamment au problème de congestion réseau dû au partage des cartes réseaux entre les machines virtuelles d'un même hôte ESX
--> Je poserai également la question demain à l'équipe système.

etc ...
--> Merci. Pour faire un premier bilan, il n'y a pas l'air d'avoir de réelles contre-indications pour virtualiser des serveurs de base de données, contrairement à ce que je pensais. Je laisse la discussion ouverte jusqu'à la fin de la semaine prochaine dans l'espoir d'avoir d'autres retours d'expérience en la matière.
++
09/05/2011, 18h21
dbaffaleuf

Citation:

Envoyé par suchiwa

Je fais en sorte de ne pas utiliser les logs et le tempDB sur le C:\, qui grossissent de façon croissante en fonction du temps.

Un problème de mode de récupération des transactions peut être ?
09/05/2011, 18h33
dbaffaleuf

Citation:

Envoyé par mikedavem

- S'assurer que les ressources qui seront alloués à la machine virtuelle qui héberge SQL Server ne seront pas partagés par d'autres machines virtuelles sur le même hôte ESX. D'autres machines virtuelles qui seraient consommatrices de ressources pourraient vampiriser celles de votre instance SQL Server
- S'assurer que les datastores ne soient pas partargés par d'autres machines virtuels ce qui pourrait engendrer des problèmes de performances certains du sous système disque.

Je suis d'accord avec toi sur le principe mais dans la mesure où on virtualise d'abord pour consolider des environnements, ça va être dur de ne pas partager des ressources physiques à un moment ou à un autre. On va pouvoir créer des datastores dédiés mais dans la pratique ce n'est pas tellement le cas (pour ce que j'ai vu jusque là du moins). Cela dit, dans les environnements avec une politique où pour les SGBD, on va mettre du RDM plutôt que du VMFS, on observe un meilleur cloisonnement. Reste la solution DRS pour empêcher la 'vampirisation' entre VMs.

Une autre remarque, ne pas penser qu'on peut remplacer un cluster MSCS par un cluster ESX en garantissant le même niveau de disponibilité. ESX fonctionne au niveau de la VM alors de MSCS fonctionne au niveau de la ressource (disque, adresses IP, DNS, accès à SQL Server ou l'agent). Un problème de connexion à l'instance ne déclenchera pas de failover sur un cluster ESX.
10/05/2011, 17h30
suchiwa

Citation:

Envoyé par mikedavem

- Vérifier que le paramètre de file d'attente des IO sur Vmware soit aligné avec celui des cartes HBA dans le cas d'un stockage SAN

Bonjour,

Je pense que tu parles du LunQueueDepth ? Une partie au niveau HBA, et un e autre au niveau du SP (Storage Processor).

Je suis entièrement d'accord sur l'alignement du blocksize, cependant au niveau ntfs, ce n'est plus une nécessité à partir de Windows 2008 Server.
Par contre il doit toujours être fait pour la partie vmfs et au niveau du stripe.

A ce sujet, les partitions systèmes Windows 2008 Server ne sont pas alignés (uniquement système), si quelqu'un a pu le faire par le passé, je suis curieux de savoir...

Vincent.

Citation:

Envoyé par suchiwa

A ce sujet, les partitions systèmes Windows 2008 Server ne sont pas alignés (uniquement système), si quelqu'un a pu le faire par le passé, je suis curieux de savoir...Vincent.

Pour les Os qui ont été migrés et pour lesquels les partitions n'étaient pas alignées avant migration OK, mais pour les installations de 2008 ? Tu as une référence à nous donner ?

Par ex sur une 2008R2 SE:
Code:

1 2 3 4 5 6 7 8 9 10 11 $ cmd /c ver Microsoft Windows [Version 6.1.7600] $ wmic partition get BlockSize, Size, StartingOffset, Status, Type BlockSize Size StartingOffset Status Type 512 104857600 1048576 Installable File System 512 21367881728 105906176 Installable File System 512 21340618752 135266304 GPT: Basic Data 512 52477034496 135266304 GPT: Basic Data 512 10707009536 34603008 GPT: Basic Data 512 52481228800 135266304 GPT: Basic Data
La première est une partition système, elle est alignée.