Quels sont les inconvénients de l’exécution d’une base de données au sein d’une machine virtuelle? Comment puis-je les surmonter? [fermé]

65

Exécuter quoi que ce soit à l'intérieur d'une machine virtuelle aura un certain impact sur les performances , mais dans quelle mesure cela impactera- t-il réellement les performances d'un système de base de données?

J'ai trouvé ce document de référence académique avec quelques points de repère intéressants, mais il s'agissait d'un test limité utilisant uniquement Xen et PostgreSQL. La conclusion était que l'utilisation d'une machine virtuelle "n'entraîne pas un coût élevé en performances" (bien que vous puissiez penser que les données réelles indiquent le contraire).

Quels sont les inconvénients techniques, administratifs et autres associés à l'exécution d'une base de données au sein d'une machine virtuelle?

S'il vous plaît, postez des réponses qui peuvent être étayées par des faits objectifs. La spéculation et tout autre argument semi-religieux ne m'intéressent pas (la passion geek est bonne à bien des égards, mais cela ne nous aidera pas ici).

Cela étant dit,

Quels problèmes apparaissent lors de l'exécution de la base de données sur une machine virtuelle? (s'il vous plaît poster des références)

Ces problèmes sont-ils importants?

Sont-ils importants uniquement dans certains scénarios?

Quelles sont les solutions de contournement?

— Russ
source

+1 Je souhaite avant tout connaître les réactions à propos des scénarios SQL Server et Windows 2008 R2

— goodguys_activate le

4

@Shane Madden - Pouvez-vous expliquer un peu la fermeture? Je m'attends à ce que la motivation ait été motivée par une réponse non spécifique (qui a ensuite été déformée dans les commentaires), pas par la question elle-même. En ce qui concerne la question, 44 votes et 12 favoris au bout d'environ un jour d'existence avant la fermeture m'impliquent qu'il s'agissait d'une bonne question avec des réponses / informations utiles (notamment par rapport à ce qui semble être typique du trafic de questions ServerFault). C’est ce que visent les différents sites SE. Auriez-vous préféré une formulation de question plus spécifique, par opposition à la phrase "comment est-elle mauvaise?".

— Russ

1

@ErikA, Shane, Womble, mikeyb, Ben - J'ai fait une modification de la communauté qui pourrait rendre cette question plus constructive. Pensez à rouvrir ceci ou à poster une question similaire sur une question nouvelle / propre.

— goodguys_activate

40

Bien que de nombreux fournisseurs de bases de données aient mis beaucoup de temps à le faire, ils prennent maintenant presque tous officiellement en charge leurs logiciels fonctionnant dans un environnement virtualisé.

Nous utilisons beaucoup d'instances Oracle 11g sous Linux en plus d'ESXi, et il est certainement possible d'obtenir de très bonnes performances. Comme pour toute mise à l'échelle matérielle, vous devez simplement vous assurer que l' hôte de virtualisation dispose de beaucoup de ressources (RAM, CPU) et que votre couche de disque est en mesure de fournir les performances d'E / S souhaitées.

— EEAA
source

7

+1 Comme indiqué, il est essentiel que les ressources soient à la hauteur de la tâche. Le disque a été le gros goulot d’étranglement pour nous et une planification minutieuse est nécessaire.

— Dave M

2

+1 Vous devez faire vos devoirs sur l' utilisation de la base de données à l' avance. Si votre boîte physique devient martelée au-dessus de 40% d’utilisation, vos avantages pour la vm commencent à se dissoudre. Cela étant dit, nous avons des tonnes de petits sql isolés spécifiques aux applications fonctionnant sur des machines virtuelles sans aucun problème. Mais nos grosses machines à usage intensif ont un matériel dédié en raison de leur manque d’avantage.

— Nate

5

Le disque dur est certainement le grand coupable, et les environnements virtualisés ont tendance à être instables.

— Lynxman

1

@lynxman - D'accord. Nous exécutons toutes nos instances Oracle sur nos disques SAN de niveau 1, soit 15 000 SAS. D'après ce que je peux dire, nous nous rapprochons de très près de la performance native.

— EEAA

10

"Une once de test vaut une livre de devinette."

— Chris B. Behrens

21

Comme le dit ErikA, cela devient de plus en plus courant. Je suis dans le camp SQL Server et je n'ai personnellement aucun système de production sous VM, mais je n'hésiterais pas à le faire (après un peu plus d'étude sur le sujet). Il y a cependant des éléments à prendre en compte avant de suivre cette voie (du moins pour SQL Server). Disque IO (comme d'autres l'ont mentionné) et l'allocation de mémoire ne sont que 2 exemples. Les choses seront différentes entre les différents hyperviseurs.

Brent Ozar est un expert reconnu de la virtualisation de SQL Server, en particulier de VMWare. Je recommanderais fortement de lire son matériel.

http://www.brentozar.com/community/virtualization-best-practices/

— écailleur
source

11

Il y a peut et alors il faut . Une corvette peut aller à 150 mph, mais devriez-vous sur les autoroutes publiques? Vous pouvez vous nuire inutilement.

Les bases de données sont des systèmes d'exploitation invités. De par leur conception, au démarrage, ils saisissent des blocs d’une ressource et la gèrent directement pour des raisons de performances. Dès que vous faites du système d'exploitation principal du serveur de base de données un invité dans un environnement d'hébergement virtualisé, vous placez une couche d'arbitrage avec l'hyperviseur entre l'élément alloué au bloc de disque et de RAM et le serveur de base de données. Ça va ralentir. Plus vos requêtes sont inefficaces, plus elles ralentiront. Aujourd'hui, ces inefficacités peuvent être masquées sur du matériel dédié, mais dès que vous introduisez l'arbitrage dans votre ressource dépendante, vous allez le découvrir très vite.

Ce que beaucoup de compteurs de beans exigeant la virtualisation ne reconnaissent pas, c'est que les serveurs de base de données, en tant que systèmes d'exploitation invités, offrent leur propre couche de consolidation. Il n'y a aucune raison pour que vous ne puissiez pas déplacer, consolider plusieurs instances de base de données logiques sur un serveur physique, même au point de déplacer des adresses IP, de configurer des noms d'hôte supplémentaires, etc., pour permettre cette fusion naturelle des services. Et, avec ce modèle, non seulement vous conservez les économies de coûts que la direction préconise pour un nombre réduit d'hôtes physiques, mais vous conservez le blocage de l'accès aux ressources physiques sans l'empiétement de l'hyperviseur arbitraire, ce qui peut parfois permettre de prendre des décisions utiles. autres.

Il en va de même pour les autres systèmes d'exploitation invités, tels que Java. Les solutions de virtualisation sont généralement des environnements très chargés et l'hyperviseur doit prendre de nombreuses décisions pour déterminer qui "reçoit le jeton" sur une ressource. Chaque fois que vous pouvez éliminer cette couche, vous vous en tirerez mieux.

Coalescez plusieurs instances en utilisant d'abord la couche du système d'exploitation invité naturel. Il est fort probable que vous pourrez atteindre plus facilement vos objectifs de consolidation de la plate-forme et de performances.

— James Pulley
source

4

Définition intéressante de "système d'exploitation invité". Bien que votre point de vue concerne les performances pures et non falsifiées, à quelle fréquence vos bases de données gênent-elles réellement le processeur? Les E / S sont beaucoup plus probables et, pour les applications hautes performances, vous partagez déjà le temps d'E / S sur un SAN. J'espère que vous reconsidérerez votre philosophie de virtualisation lorsqu'un problème de sécurité lié à une application compromet tous les hachages de mots de passe de vos bases consolidées ou lorsqu'un processus exécuté dans votre JVM consomme chaque octet d'espace disque disponible.

— Shane Madden

5

Pour être clair, je suis tout à fait d’accord pour dire qu’un serveur de base de données hautes performances, finement optimisé, très optimisé, devrait disposer de son propre matériel. Mais ce ne sont pas la norme et les autres avantages de la virtualisation l'emportent généralement sur l'impact sur les performances, impossible à distinguer de la plupart des charges de travail.

— Shane Madden

3

Je ne suis pas d'accord avec votre idée de toujours aller en premier aux couches de consolidation existantes. Parfois, cela a du sens. Mais regardez, par exemple, le compromis coût de rééquilibrage des ressources entre la consolidation de plusieurs bases de données sur un seul système d’exploitation et la consolidation de plusieurs combinaisons base de données / système d’exploitation sur un hyperviseur. Le premier est plus efficace. La seconde est beaucoup plus facile à rééquilibrer. La migration d'un système d'exploitation / base de données vers un nouvel hôte est beaucoup moins perturbante que la migration d'une base de données vers un nouveau système d'exploitation.

— Jake Oshins

Mes commentaires proviennent d'observations directes sur le terrain de la réussite ou de l'échec des migrations vers des solutions de virtualisation au cours des dix dernières années en tant qu'ingénieur de la performance. Il existe une multitude d'applications de bases de données malveillantes dont l'utilisation proche du matériel masque les problèmes de performances. Ajoutez la virtualisation et ces problèmes apparaissent. Si vous avez une application qui demande une horloge précise à des fins de chronométrage ou d’audit, alors avec le flottement de l’horloge dans la virtualisation logicielle, vous êtes hors de la chasse.

— James Pulley le

1

Wow, wow juste James. Je n’ai ni le temps ni la patience nécessaire pour expliquer tous les points que vous avez mentionnés dans votre réponse et vos commentaires ultérieurs, mais j’ai juste senti que j’avais besoin de laisser un commentaire ici pour tous ceux qui pourraient se trouver dans cette réponse. Les points de vue de James sont, bien, les siens, et ne reflètent pas ce qui est vraiment possible. Si vous êtes sursouscrit , vos performances seront médiocres. Alors ne vous inscrivez pas trop. Il est parfaitement possible d'avoir un environnement de virtualisation très performant. C'est folie de faire une recommandation générale contre elle parce qu'elle "fonctionne mal".

— EEAA

6

Il y a deux choses à réaliser ici:

L'unité de performance de base de données par unité de matériel est un peu plus basse pour une base de données virtualisée. Cela signifie que vous devez acheter un peu plus de matériel pour obtenir le même niveau de performance.
Cela ne signifie pas que le même niveau ou un niveau de performance souhaité est impossible à obtenir. Les gains obtenus grâce à une gestion améliorée et à d’autres avantages (tels que la haute disponibilité plus facile) font bien plus que compenser l’augmentation marginale des coûts matériels.

Cela dit, lorsque je travaille, notre installation Sql Server est l’un des deux serveurs que je n’ai pas l’intention de virtualiser à l’avenir (l’autre est le contrôleur de domaine principal).

— Joel Coel
source

4

Exécuter SQL Server est un ordinateur virtuel, à condition que vous puissiez lui fournir suffisamment de ressources pour exécuter votre application. Si, dans le monde physique, vous avez besoin de 24 cœurs et de 256 Go de RAM, vous devez fournir 24 vCPU et 256 Go de RAM dans le monde virtuel.

Je venais d' écrire un article dans le magazine SQL Server des derniers mois, consacré à l'exécution de SQL Server sous vSphere de VMware.

— mrdenny
source

2

J'exécute deux bases de données, une PostgreSQL et l'autre MySQL, dans un environnement virtuel (Xen) où les dom0s sont hautement disponibles. Les systèmes de fichiers domU sont tous situés sur un LUN SAN iSCSI, découpé avec des volumes logiques LVM2. La base de données MySQL est uniquement destinée à Cacti, elle n’est donc pas très utilisée et se trouve également sur le LUN iSCSI.

La base de données PostgreSQL est la base de données de notre environnement de transfert. Par conséquent, son utilisation est supérieure à celle de la base de données MySQL. Pour cette raison, la base de données est située sur un ensemble RAID10 local et DRBD est répliqué sur le deuxième nœud du cluster. Cependant, en termes de charge réelle, cette base de données de transfert ne connaît pas une charge très élevée. Ce qui, à mon avis, en fait un bon / bon candidat pour la virtualisation.

Parmi les avantages pour notre organisation, il y avait la consommation d'énergie réduite, un espace de stockage réduit et une surcharge de matériel administratif.

Notre base de données de production principale, en revanche, je ne peux pas imaginer devenir virtuelle ....

— Kendall
source

2

Je travaille avec les serveurs MSSQL et MySQL sur de nombreux serveurs. Il y a quelques années, j'hésitais à configurer des serveurs SQL sur des ordinateurs virtuels, car j'avais entendu parler des problèmes de performances liés à l'exécution d'un serveur SQL sur un ordinateur virtuel. Cependant, j'ai été surpris après l'installation de mon premier couple de serveurs SQL et je n'ai constaté aucun changement dans les performances. De plus en plus de serveurs sur lesquels je travaille sont sur VM et presque tous les grands clients d'entreprise pour lesquels je travaille ont virtuellement des serveurs SQL.

Oui, la machine virtuelle ajoute des frais généraux et si vous hébergez plusieurs machines virtuelles sur une même boîte, vous aurez besoin d’un bon serveur. Un problème de ressource commun à rechercher consiste à ajouter des machines virtuelles supplémentaires et à réduire les ressources disponibles. Il est courant de planifier une certaine croissance, mais si vous achetez votre serveur pour héberger 2 ou 3 ordinateurs virtuels et que ses 10 ordinateurs en fonctionnement sont en train de subir de graves problèmes de performances.

Je mentirais si je disais que je n'ai jamais vu de problèmes de performances lors de l'exécution d'un serveur SQL sur une machine virtuelle. Mais j’ai appris que si vous constatez de mauvaises performances, il ya probablement un problème avec l’environnement.

— Chris
source