Ressources dédiées sur les machines virtuelles hébergeant SQL Server

8

Ma compréhension est que l'un des grands avantages de l'utilisation d'une machine virtuelle est que vous pouvez partager des ressources entre les machines virtuelles sur un hôte. Vous pouvez donc avoir un hôte avec 120 CPU et y mettre 5 VM avec 32 CPU chacune. Les processeurs supplémentaires sont "partagés" entre les machines virtuelles, l'hôte affectant les processeurs de manière dynamique en fonction des besoins. Idem pour la mémoire.

J'ai également compris qu'il s'agissait d'un grand non-non pour les machines virtuelles qui hébergent des serveurs SQL, mais mes administrateurs de machines virtuelles ne sont pas d'accord. Quelqu'un at-il des preuves ou des documents d'une manière ou d'une autre?

Je ne sais pas si c'est important mais nous utilisons VMWare.

sql-server virtualisation vmware

— Kenneth Fisher
source

2

curieusement, nous venons d'avoir un problème avec des basculements aléatoires sur un groupe de disponibilité virtualisé. nous avons été sursouscrits sur le processeur avec un temps prêt de ~ 8 secondes. l'écouteur ag a perdu son bail de cluster et basculerait vers l'autre nœud HA. la difficulté ici est qu'elle ne se présente pas comme une pression CPU sur l'invité, même si l'erreur est généralement associée à une pression CPU soutenue. cela conduit au plus gros problème avec la virtualisation - savoir ce qui se passe et faire confiance aux autres pour faire de même.

— swasheck

Un très bon article de blog sur les effets vNUMA enfichables à chaud du processeur VMware sur SQL Server par Jonathan Kehayias

— Kin Shah

btw: Ce n'est pas normalement "la même chose pour la mémoire". Dans la plupart des cas, vous partagez l'unité centrale de traitement, mais une quantité spécifique de mémoire est allouée à chaque machine virtuelle et cette mémoire n'est pas partagée. Le partage du processeur avec un serveur SQL peut être OK en fonction de la charge totale du processeur pour toutes vos machines virtuelles, mais le partage de la mémoire avec un serveur SQL serait mauvais dans presque tous les cas

— MTilsted

@MTilsted Désolé pour la confusion. Quand j'ai dit "Idem pour la mémoire", j'ai voulu dire spécifiquement qu'elle coulddevait être partagée. Lorsque j'ai posé la question, j'ai réalisé que cela pourrait très bien être différent pour les processeurs et la mémoire, mais que les deux étaient une option.

— Kenneth Fisher

15

Ce que vous demandez, c'est: "Est-ce que ça va si nous sur-engageons les CPU?"

Ce n'est pas grave jusqu'à ce que vous commenciez à rencontrer des goulots d'étranglement liés aux performances du processeur. La même réponse vaut également pour la sur-engagement réseau - ce n'est pas comme si vous mettiez 5 cartes Ethernet 10 Gb distinctes dans l'hôte et que vous dédiez une carte par VM. La virtualisation, c'est avant tout un engagement excessif et faire la distinction entre la disponibilité des ressources et les besoins en ressources.

De manière générale, vous ne voulez pas surcharger la mémoire, car SQL Server utilisera activement la mémoire que vous lui présenterez. Plutôt que de laisser la page des VM sur le disque de l'hôte, il vaut mieux faire une analyse VM par VM pour déterminer quelles VM peuvent vivre avec moins de mémoire, puis les configurer avec moins de mémoire pour commencer.

— Brent Ozar
source

N'oublions pas non plus l'importance de disques physiques dédiés et indépendants; un pour Data, Logs et Tempdb . :)

— Chiramisu

13

Le problème que je vois avec l'allocation dynamique de certaines ressources est qu'il conduit à des performances imprévisibles. La requête de rapport x avait 32 CPU disponibles hier et a fonctionné en 4 minutes, aujourd'hui elle n'en a que 24 et cela a pris beaucoup plus de temps. Vous pouvez également voir la latence lorsque l'invité attend que d'autres cœurs soient disponibles.

Jonathan Kehayias donne des avertissements pratiques sur la surabonnement du processeur et de la mémoire ici (et franchement, je fais confiance à son expérience et à ses conseils plus qu'à un administrateur de machine virtuelle typique, cela ne les offense pas, mais je soupçonne qu'il a une expérience beaucoup plus directe avec la combinaison):

Le DBA accidentel (Jour 5 sur 30): Considérations de virtualisation

— Aaron Bertrand
source

11

Ma compréhension est qu'un certain niveau de sur-engagement du processeur peut être parfaitement OK, mais cela dépend totalement des exigences de charge de travail de tous les invités. Consultez le blog de David Klee pour de nombreuses bonnes informations sur les VM. Spécifiquement http://www.davidklee.net/articles/sql-server-articles/cpu-overcommitment-and-its-impact-on-sql-server-performance-on-vmware/ pour l'explication du sur-engagement CPU et son impact sur SQL Server.

Le sur-engagement de mémoire est un autre animal entièrement et en général, l'hôte VM ne doit pas être sur-engagé sur la mémoire s'il exécute des serveurs SQL. Encore une fois, je vais utiliser David Klee comme référence. http://www.davidklee.net/2013/11/04/lock-pages-in-memory-in-sql-server-on-vmware-why-or-why-not/ où il explique les effets de la mémoire sur -engagement.

J'espère que cela t'aides.

— cjsommer
source