Discussion :

[servertum]

Bonjour,

J'ai des lenteurs très importantes sur mon application qui utilise une base de données SQL SERVER
SQL server 2008 R2 est installé sur une machine virtuelle windows 2012 (8 GO de RAM, 1 processeur, 120 GO de disque) la virtualisation est géré par hyper V2012.
dès les premiers tests après le déploiement des lenteurs ont été signalées. je vais voir sur sql server manager, j’exécute la commande "Affichier les 1000 premieres lignes" sur une vue, ça met 25 secondes pour afficher 660 lignes. Le code SQL de la vue fait des jointures mais je serait étonné de savoir que c'est à cause de ça, ma base ne contient pas bcp de données, les tables sont quasi vides. je n'arrive pas à comprendre si la perte de perf est due à un pb d'optimisation de la base ou bien c'est à cause du fait que SQL server tourne sur une serveur virtuel (j'ai lu dans des articles que la couche virtualisation affecte les performances des SGBD relationnels y compris SQL server)?
j'ai augmenté la RAM de serveur jusqu'à 20 GO, désactivé le parallélisme sur Sql server ça n'a rien changé, j'ai mis le nombre processeur à 2 mais ça n'a rien changé.

comment vérifier si c'est l'une ou l'autre des causes?
et surtout comment faire pour résoudre le pb? (l'application est inexploitable dans son état actuel à cause de ce pb).

le prestataire qui a développé l'appli dit que lorsqu'il déploie ma base sur ses plateformes, il ne constate pas les même lenteurs. en plus c'est lui qui m'a recommandé la virtualisation

D'avance merci pour votre aide.

[servertum]

Dans la continuité de mes tests, j'installe ma base de données sur une machine physique et surprise, pas de problème de performance, les exécutions de requêtes qui mettaient 25s pour deviennent instantanées. Maintenant, c'est clair c'est la couche virtualisation qui cause les pb de perf. La question maintenant est : Microsoft n'a rien prévu pour le déploiement de sql server dans un environnement virtualisé? j'ai quand même suivi les instructions sur le site.
y'aurai pas une solution pour réconcilier sql server avec la virtualisation?
Quelqu'un a déjà rencontré ce problème?

Merci.

[hmira]

Je ne suis pas spécialiste en visualisation (pas encore !) Le présent post n'est donc pas une réponse directe à votre problème, mais sachez juste que selon les résultats d'une enquête que j'ai lus récemment, la virtualisation ne représente que 2% des causes possibles des problèmes de performance SQL Server. Ceci dit, il n'est pas impossible que les problèmes que vous rencontrez soit dans cette mince frange.

Ces dessous les résultats de cette enquêtes :
"Quelles sont les causes profondes des problèmes de performances de SQL Server, que vous avez décelées" :

Code T-SQL mal écrit (voire très mal écrit ) --> 26%
Manque ou absence totale de stratégie d'indexation --> 19%
Problèmes lié au sous système I/O --> 16%
Code de l'Application mal écrit, non optimisé, .. --> 12%
Mauvaise Conception de la base de données (modèle, structure des tables etc.) --> 10%
Statistiques (statistics) non mises à jour ou manquantes --> 9%
Mauvaise Configuration du Serveur / Base de données --> 3%
Problèmes liés à la Virtualisation --> 2%
Autres problèmes matériels ou OS --> 2%
Économie d'énergie CPU (CPU power saving) --> 2%

PS : Les systèmes sont de plus en plus virtualisés, il se peut donc que ce pourcentage de 2% (pb virtualisation) soit en constante progression (?)

Personnellement, je n'hésite pas à utiliser le résultat de cette enquête, chaque fois que j'entends des réponses stupides, non argumentées, non justifiées, de type "t'inquiètes .., il suffit de rajouter de la RAM pour que tous les problèmes soient résolus ..."

A+

[SQLpro]

Dans la continuité de mes tests, j'installe ma base de données sur une machine physique et surprise, pas de problème de performance, les exécutions de requêtes qui mettaient 25s pour deviennent instantanées. Maintenant, c'est clair c'est la couche virtualisation qui cause les pb de perf. La question maintenant est : Microsoft n'a rien prévu pour le déploiement de sql server dans un environnement virtualisé? j'ai quand même suivi les instructions sur le site.
y'aurai pas une solution pour réconcilier sql server avec la virtualisation?
Quelqu'un a déjà rencontré ce problème?

Merci.

Les 2% c'est ce que vends WMWare, mais ceci ne concerne que la partie CPU. La réalité est plus proche de 8 à 12% avec SQL Server.
Mais le pire c'est le stockage virtualisé ou, dans une moindre mesure, les SAN non dédiés. Là les performances peuvent chuter de manière fantastiques....

MS tout comme Oracle, ne "supportent" pas la virtualisation des serveurs de bases de données. Entendez par là que si vous avez des problèmes avec un SQL virtualisé, MS jettera un coup d'oeuil mais vous conseillera de commencer par dévirtualiser afin de reproduire le problème de manière à le traiter sans la couche de virtualisation !

Lisez ce que j'ai écrit à ce sujet dans mon ouvrage sur SQL Server http://www.amazon.fr/SQL-Server-2014.../dp/2212135920. Il y a un chapitre consacré au paramétrage de SQL Server et je parle de la virtualisation et un autre consacré exclusivement au stockage.

A +

[hmira]

Merci SQLPro pour ce complément d'information ayant trait à la virtualisation. Je pourrais ainsi affiner mon argumentaire concernant les causes possibles des problèmes de performances sous SQL Server.

Concernant votre livre, j'attends toujours avec impatience la livraison de votre livre "SQL Server 2014" que j'ai commandé le 18 octobre 2014 (c'est vrai, c'était dès la toute première annonce). Je croyais l'avoir comme cadeau de noël (cadeau que je m'eusse offert !).
Maintenant Amazon m'annonce le livre pour début janvier 2015 (pile le jour de mon anniversaire !).
Mais comme dit le proverbe "Tout vient à point à qui sait attendre".

Merci,

A+

[SQLpro]

En fait il sera disponible le 31 décembre.....

Le temps de le mettre en rayon et de l'envoyer.... compter début janvier !

A +

[servertum]

Je vous remercie pour l'intérêt que vous avez donné à mon problème.
Entre temps j'ai installé sql server 2012 et j'ai redémarré mon serveur de BDD, et donc je constate une amélioration des temps de réponse, mnt c'est quasiment les mêmes temps de réponse que à partir du serveur physique, je n'ai pas tout chronométré mais déjà l'affichage de certaines listes qui prenait 1mn met mnt 2s. Etrange! je n'ai pas d'explication, mais le problème n'est plus là.
J'ai contacté l'éditeur, il m'a confirmé qu'il a mis ma base de données sur un serveur virtualisé et ça fonctionne bien. Alors est ce que c'est la version de sql server qui ne suit pas? je ne sais pas. Maintenant, ma base n'est pas de grande taille, peut être lorsque le volume des données augmente, les soucis se verront.
SQLPro, je n'ai pas encore pris votre livre, je vais le lire
Merci encore.

[mikedavem]

Entre temps j'ai installé sql server 2012 et j'ai redémarré mon serveur de BDD, et donc je constate une amélioration des temps de réponse, mnt c'est quasiment les mêmes temps de réponse que à partir du serveur physique

La virtualisation n'est pas forcément l'ennemi de la performance comme on peut le voir souvent (on bénéficie souvent de bien plus de ressources sur un environnement virtualisé que sur un environnement physique en général) .. cependant tout dépend de comment le paramétrage a été effectué. Je ne vais pas développer sur ce point de détail car il y aurait beaucoup à dire. Ceci dit virtualisation va souvent de paire avec partage des ressources et c'est souvent là que le bât blesse dans la plupart des cas .. pas forcément le fait de partager les ressources à proprement parlé mais de le faire de manière inefficace. Pour te rendre compte du problème que tu avais il faudrait plutôt aller investiguer du côté de la couche virtuelle car du point du vue OS tu ne verras rien de plausible. Est-ce que ton hôte ESX était surchargé au moment de ton problème? CPU ? RAM ? Swapping ? Problème stockage saturé ? etc ... autant de questions pour lesquelles tu ne trouveras malheureusement réponse qu'en faisant un tour dans les couches basses ...

++

[hmira]

En complément des remarques pertinentes de mikedavem, vous trouvez ci-dessous, dans le même esprit, un lien très instructif sur ce sujet subtile et délicat, consacré principalement à Hyper-V :

http://msdn.microsoft.com/en-us/libr...v=bts.10).aspx

A+

[SQLpro]

La virtualisation n'est pas forcément l'ennemi de la performance comme on peut le voir souvent (on bénéficie souvent de bien plus de ressources sur un environnement virtualisé que sur un environnement physique en général) .. cependant tout dépend de comment le paramétrage a été effectué. Je ne vais pas développer sur ce point de détail car il y aurait beaucoup à dire. Ceci dit virtualisation va souvent de paire avec partage des ressources et c'est souvent là que le bât blesse dans la plupart des cas .. pas forcément le fait de partager les ressources à proprement parlé mais de le faire de manière inefficace. Pour te rendre compte du problème que tu avais il faudrait plutôt aller investiguer du côté de la couche virtuelle car du point du vue OS tu ne verras rien de plausible. Est-ce que ton hôte ESX était surchargé au moment de ton problème? CPU ? RAM ? Swapping ? Problème stockage saturé ? etc ... autant de questions pour lesquelles tu ne trouveras malheureusement réponse qu'en faisant un tour dans les couches basses ...

++

David, il faut arrêter de dire des conneries et surtout tout et son contraire !!! (triens ça pourrait être une bonne résolution pour 2015...)
OUI, la virtualisation fait perdre des performances.... et pas peu... BEAUCOUP !

Lorsque tu dis :

La virtualisation n'est pas forcément l'ennemi de la performance comme on peut le voir souvent (on bénéficie souvent de bien plus de ressources sur un environnement virtualisé que sur un environnement physique en général)

tu n'es pas clair. Si je place une instance de SQL Server sur une machine physique donnée, sans couche VM, et si je refais les tests avec la même machine physique cette fois ci avec une couche de virtualisation tu ne vas tout de même pas me dire que ça améliore les performances ! Or c'est exactement le genre de phase trompeuse que tu es en train de distiller ! (au passage de t'ai mis un point négatif !!!).

NON LA VIRTUALISATION N'AMÉLIORE PAS LES PERFORMANCES !

Mais il se trouve que souvent, les gens achètent un serveur plus performant pour mettre leurs VM et constate que cela a améliorer les choses.... C'est comme si je disais :
En utilisant une Porsche Cayenne avec 3 passagers dedans, je vais plus vite qu'avec ma 2 CV Citroën ou je suis seul dedans... (les 3 passagers étant la couche de VM).
La tout le monde comprendrais qu'on prends les gens pour des cons !

A +

[mikedavem]

Hello Fred,

En forme pour 2015 Sujet toujours épineux n'est-ce pas `?

NON LA VIRTUALISATION N'AMÉLIORE PAS LES PERFORMANCES !

Je n'ai rien dit de tel ou du moins tout dépend du contexte concerné car si ta vision de la virtualisation s'arrête au sens strict de ce que tu dis ici ...

tu n'es pas clair. Si je place une instance de SQL Server sur une machine physique donnée, sans couche VM, et si je refais les tests avec la même machine physique cette fois ci avec une couche de virtualisation tu ne vas tout de même pas me dire que ça améliore les performances !

... aors effectivement je suis tout à fait d'accord avec toi .. arrêtons les frais et laissons notre serveur SQL tel quel. Maintenant si nous allons au delà de cette vision du 1 pour 1 la réalité est tout autre. Nous avons bien souvent à faire à des infrastructures dimensionnées pour la virtualisation et qui doivent gérer non pas une mais plusieurs machines (virtuelles).

Je dis simplement ici que la virtualisation n'est pas l'ennemi de la performance comme on a tendance à le voir beaucoup sur ce forum. J'ai pu voir des environnements virtuels qui sont configurés pour la performance et qui tiennent très bien la route. J'ai eu des expériences clients qui viennent confirmer ce que je dis plus haut où le fait d'avoir virtualisé leur environnement de bases de données avait amélioré les performances (temps de réponse, nb de transactions/s etc ... c'est vrai avec des ressources plus importantes mais qui restent partagés avec le reste des VM mais la virtualisation a eu du bon dans ce cas précis ... on a gagné en performance et on a tiré meilleure partie de la virtualisation et des ressources qui sont partagés et utilisés de manière plus efficiente avec plus de machines) .. J'ai eu également d'autres cas clients qui ont virtualisé et qui ont obtenu des performances tout à fait acceptable avec un overhead plus ou moins faible (en fonction de la configuration) - ils n'avaient pas forcément besoin d'extrême performance et la capacité de leur environnement virtuel était plus que suffisant. Finalement j'en ai eu mais peu de cas où la "dévirtualisation" ou l'adoption à la virtualisation était remise en cause du fait de la nature de la charge de travail à consommer les ressources et des SLAs liées à la performance applicative. Le tout nécessitait soit un re-design complet avec un coût beaucoup trop élevé et des ressources trop importantes.

Je vois sur le forum beaucoup de messages véhiculées où il est dit qu'un serveur SQL ne doit pas être virtualisé et je ne suis pas entièrement d'accord avec cela car le message est beaucoup trop radical et pas du tout en phase avec la réalité du marché malheureusement. Je doute que tous les internautes qui passent ici sont dans un cas d'extrême performance avec des environnements à 64 cœurs, 512 GB de mémoire utilisés à leur plein potentiel toute une journée et qui remettrait en cause la question de la virtualisation. Celle-ci apporte bon nombre d'avantages aux entreprises (pourquoi nos clients s'acharneraient à vouloir virtualiser sinon) que nous DBA, consultants, experts en bases de données devont prendre en contre (réduction CAPEX, OPEX, HA, SLAs etc... je ne développe pas). Il faudrait plutôt dire qu'il y a des scénarios / contextes où la virtualisation conviendra très bien (et même lorsqu'on parle de performance) et d'autres non (l'extrême performance peut être un cas mais le ratio est plutôt faible). Tout comme un serveur physique, lorsqu'on veut de la performance il faut s'en donner les moyens et à tous les niveaux ... Tous les problèmes de performances dans un environnement virtuel ne se sont pas forcément liés à la couche virtuelle et j'ai la nette impression que sur ce forum on a tendance à vite faire la confusion.

Mon message (si pas bien compris jusqu'ici) serait plutôt celui-ci : virtualiser SQL Server ok mais faites le correctement pour avoir vu bon nombres d'environnements où on laissait tout par défaut en espérant que tout fonctionne par magie ... (en somme plus un problème de configuration qu'un vrai problème liée à une quelconque limite de capacité liée à la virtualisation elle même)

++

[SQLpro]

J'ai eu des expériences clients qui viennent confirmer ce que je dis plus haut où le fait d'avoir virtualisé leur environnement de bases de données avait amélioré les performances (temps de réponse, nb de transactions/s etc ... c'est vrai avec des ressources plus importantes mais qui restent partagés avec le reste des VM mais la virtualisation a eu du bon dans ce cas précis ... on a gagné en performance et on a tiré meilleure partie de la virtualisation et des ressources qui sont partagés et utilisés de manière plus efficiente avec plus de machines) ..

En changeant de machine, comme c'est le cas que tu défends, tu aurais obtenu globalement la même chose si tu avait mutualisé plusieurs instances de SQL Server, ou mieux si tu avais mutualisé plusieurs bases sur cette même machine !
Or la couche de VM te fais toujours perdre du temps de calcul !

Je vois sur le forum beaucoup de messages véhiculées où il est dit qu'un serveur SQL ne doit pas être virtualisé et je ne suis pas entièrement d'accord avec cela car le message est beaucoup trop radical et pas du tout en phase avec la réalité du marché malheureusement.

Sauf que tu oublie que la raison essentielle de leur venue ici est justement de médiocre perf parce qu'on leur a fait croire que la VM allait leur faire gagner en perf ! Alors que c'est bien entendu totalement faux et les exemples tu les connais aussi bien que moi.... Or il faut bien contrebalancer le discours des marqueteux !

Je doute que tous les internautes qui passent ici sont dans un cas d'extrême performance avec des environnements à 64 cœurs, 512 GB de mémoire utilisés à leur plein potentiel toute une journée et qui remettrait en cause la question de la virtualisation. Celle-ci apporte bon nombre d'avantages aux entreprises (pourquoi nos clients s'acharneraient à vouloir virtualiser sinon) que nous DBA, consultants, experts en bases de données devont prendre en contre (réduction CAPEX, OPEX, HA, SLAs etc... je ne développe pas).

Sauf que la plupart du temps, ils virtualisent pour de mauvaise raisons : dans bien des cas c'est du 1 pour 1 (la même machine à laquelle on a rajouté une couche de VM). En effet, ce n'est généralement pas pour la mutualisation des instances et des bases que l'on utilise des VM, mais la plupart du temps (en tout cas de la part des internautes qui postent sur ce forum) pour assurer une haute dispo parce que les ingé système ne savent pas faire de la haute dispo avec les outils internes à MS SQL Server et qu'aucune ressource n'est alloué pour faire du DBA !

Il faudrait plutôt dire qu'il y a des scénarios / contextes où la virtualisation conviendra très bien (et même lorsqu'on parle de performance) et d'autres non (l'extrême performance peut être un cas mais le ratio est plutôt faible). Tout comme un serveur physique, lorsqu'on veut de la performance il faut s'en donner les moyens et à tous les niveaux ... Tous les problèmes de performances dans un environnement virtuel ne se sont pas forcément liés à la couche virtuelle et j'ai la nette impression que sur ce forum on a tendance à vite faire la confusion.

Tout à fait d'accord... C'est d'ailleurs bien plus la couche stockage qui est en cause que la VM proprement dite...

Mon message (si pas bien compris jusqu'ici) serait plutôt celui-ci : virtualiser SQL Server ok mais faites le correctement pour avoir vu bon nombres d'environnements où on laissait tout par défaut en espérant que tout fonctionne par magie ... (en somme plus un problème de configuration qu'un vrai problème liée à une quelconque limite de capacité liée à la virtualisation elle même)

Et surtout, ne faite pas de la virtualisation pour de mauvaises raisons, comme faire de la haute dispo par la VM, ce qui est une hérésie, une imbécilité et techniquement une foutaise !

A +

[mikedavem]

En changeant de machine, comme c'est le cas que tu défends, tu aurais obtenu globalement la même chose si tu avait mutualisé plusieurs instances de SQL Server, ou mieux si tu avais mutualisé plusieurs bases sur cette même machine !
Or la couche de VM te fais toujours perdre du temps de calcul !

C'est probablement vrai mais si l'on avait gardé un serveur physique nous n'aurions pas bénéficier des avantages de la virtualisation :

- ROI plus important
- Protection contre les pannes matérielles et les downtime non planifiés
- Scale-in plus contraignant puisque il engendrerait des interruptions de service (ajout à chaud de CPU, RAM ...)

Comme je disais précédemment dans ce cas nous avons gagné en performance en ayant un ROI plus intéressant.

Sauf que tu oublie que la raison essentielle de leur venue ici est justement de médiocre perf parce qu'on leur a fait croire que la VM allait leur faire gagner en perf ! Alors que c'est bien entendu totalement faux et les exemples tu les connais aussi bien que moi.... Or il faut bien contrebalancer le discours des marqueteux !

Je n'ai pas vu souvent de personnes affirmant qu'on leur avait promis une telle chose mais je me peux tromper. La plupart des problèmes que j'ai vu n'étaient d'ailleurs pas forcément liés à la virtualisation elle même mais plus à un problème de configuration ou un problème complétement autre .. j'admets volontiers que nous sommes à la merci des administrateurs de la virtualisation qui ne savent en général pas configurer leurs environnement pour la performance (de mon expérience en tout cas j'ai travaillé avec très peu d'administrateurs qui étaient affutés à cela). Mais je pense qu'on est tous d'accord qu'on ne virtualise pas un environnement SQL Server comment on pourrait le faire avec un serveur de fichiers ou un serveur applicatif. Il y a des bonnes pratiques et des points de configuration à prendre en compte et soyons honnête cela embête beaucoup nos administrateurs virtuels car cela introduit des "exceptions" dans leur configuration.

Sauf que la plupart du temps, ils virtualisent pour de mauvaise raisons : dans bien des cas c'est du 1 pour 1 (la même machine à laquelle on a rajouté une couche de VM). En effet, ce n'est généralement pas pour la mutualisation des instances et des bases que l'on utilise des VM, mais la plupart du temps (en tout cas de la part des internautes qui postent sur ce forum) pour assurer une haute dispo parce que les ingé système ne savent pas faire de la haute dispo avec les outils internes à MS SQL Server et qu'aucune ressource n'est alloué pour faire du DBA !

De mon point de vue la première cause de virtualisation est le coût et pas forcément la haute disponibilité (du moins de ce que j'ai pu voir de mes expériences sur le sujet).
Comment justifier auprès d'une direction que le serveur que nous avons provisionné pour notre activité de bases de données est utilisé uniquement à 5% de ces capacités alors que nous avons d'autres serveurs qui pourraient bénéficier des 90 - 95% perdus pendant ce temps .... réapprovisionner les ressources dans un environnement purement physique peut être difficile alors que dans un environnement virtuel ce n'est pas le cas. La mutualisation et le partage des ressources devient un facteur d'adoption certain ici pour nos financiers ...

Après je suis d'accord avec toi si on prend la machine et qu'on lui affecte les mêmes ressources dans un environnement virtualisé et que l'on ne réfléchit pas il y aura très probablement des conséquences. Dans certains cas cela fonctionnera très bien et d'en d'autres beaucoup moins et il faudra probablement faire quelques réglages pour y remédier (voir envisager une dé-virtualisation si cela s'avère nécessaire)

Et surtout, ne faite pas de la virtualisation pour de mauvaises raisons, comme faire de la haute dispo par la VM, ce qui est une hérésie, une imbécilité et techniquement une foutaise !

Je dirai oui et non puisque virtualiser permet de réduire drastiquement les coûts à la base et d'augmenter le ROI. De plus on bénéficie déjà d'une architecture HA en général. En fonction du RTO / RPO bien sûr cela peut être une solution tout à fait viable. La composante performance doit bien évidement rester un aspect important dans ce cas et peut venir contrebalancer si l'architecture virtuelle ne respecte pas les exigences de performances liées aux applications concernées.

A +

[SQLpro]

C'est probablement vrai mais si l'on avait gardé un serveur physique nous n'aurions pas bénéficier des avantages de la virtualisation :

- ROI plus important

Dépend de la config et des circonstances.... et dans bien des cas la VM n'apporte aucun gain de ROI, car la VM nécessite de licencier même les cœurs hyperthreadés et il faut compter le coût de la VM elle même, souvent ignoré !

- Protection contre les pannes matérielles

Non, si ton matériel tombe en panne, c'est pire, toutes les VM sont HS.... Rapelle toi ce qui est arrivé à l'éditeur allemand il y a quelques années et que nous a raconté Fred Pichaut...

et les downtime non planifiés

Avec du mirroring ou alwaysOn tu fais la même chose

- Scale-in plus contraignant puisque il engendrerait des interruptions de service (ajout à chaud de CPU, RAM ...)

Tu oublie que la version Enterprise avec les bons serveur est capable de faire du hardware à chaud (ajout de CPU, RAM...)[QUOTE]

A +

[mikedavem]

Dépend de la config et des circonstances.... et dans bien des cas la VM n'apporte aucun gain de ROI, car la VM nécessite de licencier même les cœurs hyperthreadés et il faut compter le coût de la VM elle même, souvent ignoré !

Prenons un cas simple ... cas souvent vécu .. on prend un serveur physique et on le dédie à SQL Server ... premier challenge : le dimensionnement des ressources .. et il faut prendre en compte une augmentation de la charge dans le temps pour pouvoir être tranquille quelques années ou du moins jusqu'à que le contrat de maintenance de la machine se termine .. on avisera à ce moment et on budgétisera le temps venu. On s'est fait plaisir .. on a pris un DL380 G6 avec 2 x Intel® Xeon® CPU E-2667 2.90GHz et 32 GB de mémoire.

Cependant mauvaise pioche (du moins tout dépend de quel côté on se place) on utilise que 30% des ressources au bout de 2 ans. Hors ces ressources auraient pu être utilisés de manière plus efficace avec d'autres serveurs.
Le fait de virtualiser est un avantage certain sans pour autant charger la mule avec plus de machines virtuelles que la machine peut gérer. Plus de machines sur un même serveur physique, un seul contrat de maintenance pour cette machine physique, une administration centralisée et simplifiée pour les administrateurs, provisionning de machines virtuelles beaucoup plus rapide etc. je pense que cela peut faire réfléchir un DSI ...

Concernant le licenciement si tu es dans un cas où ton serveur SQL ne consomme qu'une petite partie du serveur physique, même avec un licenciement par cœur tu devrais être gagnant. Si je prends le cas d'une utilisation à 30% avec 2 x Intel® Xeon® CPU E-2667 (chacun ayant 6 cœurs et 12 threads) je te laisse imaginer le montant de la facture pour un serveur physique dédié. En environnement virtualisé on utilisera probablement 4 cœurs pour commencer donc on licenciera 4 VCPU (il faut un minimum de 4 VCPU en mode de licence par cœur de toute façon sauf erreur de ma part) et en fonction de l'augmentation de la charge on pourra ajuster les ressources et le mode de licence.

Non, si ton matériel tombe en panne, c'est pire, toutes les VM sont HS.... Rapelle toi ce qui est arrivé à l'éditeur allemand il y a quelques années et que nous a raconté Fred Pichaut

On est bien d'accord que dans un environnement virtualisé sérieux, il existe une certaine redondance avec l'emploi de clusters (VMware ou Hyper-V ou autre) avec plusieurs serveurs hôtes sur lesquelles les machines virtuelles peuvent basculer. J'ai déjà assisté à pas mal des simulations de panne et de DR où cela fonctionnait très bien. Comme de partout il existe des exceptions mais je n'ai plus en tête le détail de l'origine du problème évoqué par Fred et il ne s'en rappelle plus (pour lui avoir re-demander) .. c'est bien dommage. Mais je peux dire que j'ai déjà vu aussi des cas où la bascule des instances SQL Server / bases de données ne fonctionnaient pas comme il le faudrait même avec les systèmes natifs SQL Server .. que ce soit en mirroring, clustering et même avec les groupes de disponibilités.

...Avec du mirroring ou alwaysOn tu fais la même

Oui sauf qu'en fonction du RPO/ RTO il ne sera pas toujours judicieux de proposer ce genre de mécanisme au client. Un client qui affirme que ses exigences en HA restent modestes (RPO = 1 journée et RTO = 1 journée par exemple) et qu'il n'a pas vraiment de DBA dans son équipe IT, on pourrait exclure les solutions de type mirroring et groupes de disponibilités qui restent onéreuses (Edition Enterprise pour les AAGs) et difficilement maintenable par ses équipes en cas de problème. Je serais plus tenté de proposer à ce même client de migrer son instance SQL Server vers son environnement virtuel s'il en a un et de profiter de HA native + procédure de restauration en cas de crash (tout en gardant en vue l'aspect performance nous sommes d'accord).

Tu oublie que la version Enterprise avec les bons serveur est capable de faire du hardware à chaud (ajout de CPU, RAM...)

Exactement mais comme tu le précises il faut avoir une l'édition adéquate pour cela et avoir des serveurs qui le permettent. Hors tous les clients n'ont pas forcément les 2.


Bon je pense qu'il y aurait beaucoup à dire que ce soit de ton côté que du mien et on risque de polluer le thread de servertum au final. Si tu passes sur Genève à l'occasion, je serai ravi d'en parler avec toi autour d'un verre de vin et d'une bonne fondue

++

[StringBuilder]

La virtualisation, c'est comme le cloud... C'est avant tout purement marketing, pour faire du mutualisé sans le dire.

Absolument rien dans la virtualisation ne me convainc.

- T'as un serveur physique sous-dimensionné ? Qu'est-ce qui t'empêche de joindre à ton cluster de nouveaux serveurs plus puissants, et shooter les anciens serveurs une fois la réplication effectuée ?
- T'as des serveurs physiques sur-dimensionnés ? Qu'est-ce qui t'empêche de faire la démarche inverse, ou simplement mutualiser le serveur en lui ajoutant d'autres bases de données ?

Dans tous les cas, si c'est SQL Server qui s'occupe de gérer les accès disques/CPU/mémoire directement, ce sera forcément plus performant que si c'est la couche VM, puisque dans ses algos, non seulement il sait qu'il doit écrire telle information à tel endroit, mais aussi lire telle autre information à côté, et donc ordonnancer les IO de façon à ce qu'elles soient les plus performantes possibles (réduire l'amplitude des mouvements des têtes).
La VM, elle, va alterner les accès disques entre les différentes VM, et donc foutre en l'air tout le boulot de SQL Server : pire, SQL Server aura fait des choix d'ordonnancement des IO qui pourront même dégrader les performances, au final, si les têtes de lecture ne sont pas à la position prévue.

Exemple bête.

J'ai un HD physique, qu'on va découper en 5 "zones" pour l'exemple (5 gros fichiers, 5 partitions ce que vous voulez)

Le journal des transactions de la base 1 est dans la zone 2, et son fichier de données dans la zone 5 : pour effectuer une transaction, on doit écrire dans la zone 1, puis dans la zone 5.
Le fichier de données de la base 2 se trouve dans la zone 3. On doit répondre à une requête de lecture, et charger ce qui s'y trouve.

SQL Server va vraisemblablement se dire :

Ecrire zone 2
Ecrire zone 5
Lire zone 3

Hmmmm... zone 2 et 3 sont contiguës... donc :

Ecrire zone 2
Lire zone 3
Ecrire zone 5

Ainsi, plus que deux mouvements de tête, gain de plusieurs milli-secondes, si ce n'est des dizaines.

Mais voilà. C'est virtualisé.

Et là, la VM 2 arrive, et dit "hey les gars, moi je dois écrire dans la zone 4 et lire dans la zone 1.

Donc SQL Server de la VM2 va ordonnancer tout ça : (aucun changement, pas moyen de regrouper quoi que ce soit, les zone 4 et 1 sont trop éloignées)

Ecrire zone 4
Lire zone 1

Et il envoie ça à la VM en même temps.

Et la VM elle fait :

Ecrire zone 2
Ecrire zone 4
Lire zone 3
Lire zone 1
Ecrire zone 5

La VM vient de tout saboter.

Alors après, on va dire "ouais, mais la VM, elle a un cache IO et va tout arranger".
Faux. Les accès IO sur une base de données sont souvent très volumineux. Il faudrait un cache monstrueux (plusieurs Go gaspillées à cet effet).
Et même si c'est le cas, combien de cycles CPU gaspillés en plus de la mémoire pour refaire le boulot qu'on déjà fait chacun des deux SQL Server ?

Alors on va me dire "ouais, mais la carte RAID a du cache aussi, et les disques aussi". Ouais, quelques Mo pour les disques, quelques dizaines voir centaines pour la carte RAID. Rien de folichon quand on se tape des lectures et écritures sur des fichiers de données de plusieurs centaines de Go et qu'on passe son temps à aller écrire de l'autre côté du disque.

Sans oublier au final que si l'hôte de la VM réordonnance les accès physiques sur le disque, c'est tout le comportement de SQL Server qui risque d'être remis en cause, car si SQL Server a décidé qu'il avait le temps de faire une lecture entre deux écritures (faut pas oublier que tout est parallélisé sur un SGBD), il n'a pas forcément le temps de faire 12 lectures/écritures entre ces deux opérations. Du coup, il attend désespérément la confirmation des écritures sur le disque avant de passer à autre-chose et on augmente la durée des verrous, s'exposant à des dead locks et autres timeout.


Sinon, pur le coup des licences, c'est pas parce que le serveur à 32 cœurs que je suis obligé d'avoir 32 licences... Si je n'en ai besoin que de 4, j'achète 4 licences, et je n'active que 4 cœurs dans la config de SQL Server... La VM n'apporte pas un kopeck à ce niveau.

En revanche, si j'ai 5 VM, j'ai besoin de 5 Windows Server. Là où un unique serveur mutualisé avec 5 bases n'aurait besoin que d'un Windows Server...

[SQLpro]

Sinon, pur le coup des licences, c'est pas parce que le serveur à 32 cœurs que je suis obligé d'avoir 32 licences... Si je n'en ai besoin que de 4, j'achète 4 licences, et je n'active que 4 cœurs dans la config de SQL Server... La VM n'apporte pas un kopeck à ce niveau.

Hélas, ce n'est pas ce que dit la licence Microsoft !!!

A +

[StringBuilder]

Ah, désolé, je croyais

[mikedavem]

Désolé de déterrer ce topic (un petit moment que je ne suis pas passé sur le forum)

- T'as un serveur physique sous-dimensionné ? Qu'est-ce qui t'empêche de joindre à ton cluster de nouveaux serveurs plus puissants, et shooter les anciens serveurs une fois la réplication effectuée ?
- T'as des serveurs physiques sur-dimensionnés ? Qu'est-ce qui t'empêche de faire la démarche inverse, ou simplement mutualiser le serveur en lui ajoutant d'autres bases de données ?

Rien du tout effectivement mais je pense que la virtualisation te sera plus profitable si l'on regarde le CAPEX / OPEX. Mais encore une fois il ne faut pas se réduire à une vision base de données mais à l'ensemble des serveur du systèmes d'information (serveurs de mail, serveurs applicatifs, contrôleurs de domaine etc ...)

Prenons l'exemple d'un serveur sous-dimensionné. Que fait-on dans le cas où je n'ai pas d'autres serveurs ou bases à consolider à un instant T ? J'achète un serveur moins puissant et j'utilise le plus puissant pour mutualiser d'autres choses? On perd du point de vue CAPEX (achat des serveurs) et OPEX (coût de la maintenance du serveur, coût des employées à installer, déployer ou migrer ton serveur de bases de données etc ...) Que fait-on maintenant si mon serveur SQL que j'ai mutualisé avec d'autres instances SQL Server ne suffit plus? J'achète de nouveau un serveur et je dispatche mes bases données sur ceux-ci? Même chose ici pour le CAPEX et OPEX.

Avec la virtualisation j'ai une certaine souplesse d'architecture que je peux partager avec l'ensemble de mes serveurs, diminuer mes ressources quand je sais que mon serveur n'en aura pas besoin ou les augmenter provisoirement pendant une grosse période d'activité ciblée ...

Pensez bien que je ne suis pas en train de convaincre de virtualiser à tout prix .. simplement prendre en compte la virtualisation dans certains où celle-ci permet de répondre à un besoin client

Dans tous les cas, si c'est SQL Server qui s'occupe de gérer les accès disques/CPU/mémoire directement, ce sera forcément plus performant que si c'est la couche VM, puisque dans ses algos, non seulement il sait qu'il doit écrire telle information à tel endroit, mais aussi lire telle autre information à côté, et donc ordonnancer les IO de façon à ce qu'elles soient les plus performantes possibles (réduire l'amplitude des mouvements des têtes).

Je prends l'exemple de VMware qui est tout à fait capable de gérer les CPU de manière efficiente avec SQL Server. Par exemple lors que le nombre de VCPU est inférieur au nombre de processeurs sur un nœud NUMA alors les threads allouées à SQL Server seront automatiquement localisés sur un seul nœud NUMA avec un accès direct à sa mémoire locale. Si le nombre de VCPU devient supérieure, il est possible d'activer pour la VM l'accès à l'architecture physique et laisser SQL Server de gérer ses propres ressources en fonction de la nouvelle configuration.

Dire que SQL Server puisse écrire et optimiser les écritures sur disque avec gestion des têtes de lectures relève presque du mythe maintenant. En effet depuis l'apparition des contrôleurs RAID et des stockages d'entreprises où l'écriture des données sont en généralement directement acquittées depuis les caches SQL Server n'est plus au courant de l'architecture disque sous jacente. Par ailleurs les différentes contrôleurs et cache des stockages possèdent leurs propre algorithmes de répartition des blocs de données sur disque. Ils sont capables par exemple de rassembler plusieurs blocs et d'optimiser les débits d'écritures en faisant du séquentiel (vs aléatoire)

Alors après, on va dire "ouais, mais la VM, elle a un cache IO et va tout arranger".

Ceci relève également du mythe car VMware (et sûrement Hyper-V .. à vérifier) ne cachent pas les IO avec des hôtes Windows. Le fait de buffériser impliquerait la question suivante : que se passe-t-il en cas de crash ? Est-ce que je reste intègre? VMware répond à la question avec le KB 1008542

On Windows hosts, VMware hosted products use unbuffered IO by default.

et ici

VMware ESX acknowledges a write or read to a guest operating system only after that write or read is acknowledged by the hardware controller to ESX. Applications running inside virtual machines on ESX are afforded the same crash consistency guarantees as applications running on physical machines or physical disk controllers.

Sinon, pur le coup des licences, c'est pas parce que le serveur à 32 cœurs que je suis obligé d'avoir 32 licences... Si je n'en ai besoin que de 4, j'achète 4 licences, et je n'active que 4 cœurs dans la config de SQL Server... La VM n'apporte pas un kopeck à ce niveau.

SQLPro a déjà bien répondu à la question donc on revient au point 1 qui fait que la virtualisation peut être plus intéressante du point de vue CAPEX ici.

++

[SQLpro]

Dire que SQL Server puisse écrire et optimiser les écritures sur disque avec gestion des têtes de lectures relève presque du mythe maintenant. En effet depuis l'apparition des contrôleurs RAID et des stockages d'entreprises où l'écriture des données sont en généralement directement acquittées depuis les caches SQL Server n'est plus au courant de l'architecture disque sous jacente. Par ailleurs les différentes contrôleurs et cache des stockages possèdent leurs propre algorithmes de répartition des blocs de données sur disque. Ils sont capables par exemple de rassembler plusieurs blocs et d'optimiser les débits d'écritures en faisant du séquentiel (vs aléatoire)

He bien ça c'est faux !!!

En effet, SQL Server sait parfaitement ou placer physiquement les informations sur les plateaux des disques à deux conditions :
1) que le niveau de RAID ne propose pas d'entrelacement (donc exit le RAID 5 et tout ses dérivés, 50, 6, 60, DP...)
2) que les agrégats (LUN) soient alignés sur des disques physiques et non taillés dans la masse

Et ceci même sur un SAN externe !

A +