Quels sont les inconvénients de l'exécution d'une base de données dans une machine virtuelle? Comment les surmonter?
Exécuter quoi que ce soit à l'intérieur d'une machine virtuelle aura un certain niveau de performances, mais dans quelle mesure cela affecte-t-il vraiment les performances d'un système de base de données?
J'ai trouvé cet article de référence académique avec des repères intéressants, mais c'était un test limité utilisant Xen et PostgreSQL uniquement. La conclusion était que l'utilisation d'un VM ne "coûte pas cher en performances" (bien que vous puissiez penser que les données réelles disent le contraire).
Quels sont les inconvénients techniques, administratifs et autres associés à l'exécution d'une base de données dans une machine virtuelle?
Veuillez poster des réponses qui peuvent être étayées par des faits objectifs, je ne suis pas intéressé par la spéculation ou tout autre argument semi-religieux (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 dans une machine virtuelle? (veuillez poster des références)
- Ces problèmes sont-ils importants?
- Sont-ils significatifs uniquement dans certains scénarios?
- Quelles sont les solutions de contournement?
Bien que de nombreux fournisseurs de bases de données aient été très lents à le faire, presque tous prennent désormais officiellement en charge leurs logiciels fonctionnant dans un environnement virtualisé.
Nous exécutons de nombreuses instances Oracle 11g sous Linux sur ESXi, et il est certainement possible d'obtenir de très bonnes performances. Comme pour toute mise à l'échelle matérielle, il vous suffit de vous assurer que la virtualisation Host dispose de nombreuses ressources (RAM, CPU) et que votre couche de disque est à la hauteur de la tâche à fournir IO performances dont vous avez besoin.
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 en cours d'exécution sur les machines virtuelles, mais je n'hésiterais pas à le faire (après un peu plus d'étude sur le sujet). Il y a certainement certaines choses à prendre en considération avant de suivre ce chemin (au moins pour SQL Server). Disque IO (comme d'autres l'ont mentionné) et allocation de mémoire ne sont que deux exemples. Les choses seront également différentes entre les différents hyperviseurs.
Brent Ozar est un expert reconnu dans la virtualisation de SQL Server, en particulier dans VMWare. Je recommanderais fortement de lire son matériel.
http://www.brentozar.com/community/virtualization-best-practices/
Il y a peut puis il y a devrait . Une corvette peut aller à 150 mph, mais devriez-vous sur les routes publiques? Vous pouvez vous blesser inutilement.
Les bases de données sont des systèmes d'exploitation invités. De par leur conception, au début, ils récupèrent 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 de disque alloué par bloc et RAM et la base de données serveur. Il ralentira. Plus vos requêtes seront inefficaces, plus elles ralentiront. Ces inefficacités peuvent être masquées aujourd'hui sur du matériel dédié, mais dès que vous introduirez l'arbitrage sur votre ressource dépendante, vous découvrirez très rapidement.
Ce que beaucoup de compteurs de bean 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 laquelle vous ne pouvez pas déplacer consolider plusieurs instances de bases 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 coalescence 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 l'accès au bloc aux ressources physiques sans que l'hyperviseur arbitraire ne soit impacté, ce qui peut parfois prendre des décisions bénéfiques et non autres.
Il en va de même pour les autres systèmes d'exploitation invités, comme Java. Les solutions de virtualisation sont généralement des environnements occupés et l'hyperviseur doit prendre beaucoup de décisions sur qui "obtient le jeton" sur une ressource. Chaque fois que vous pouvez éliminer cette couche, vous allez être mieux loti.
Fusionnez plusieurs instances en utilisant d'abord la couche de système d'exploitation invité naturel. Il y a de fortes chances que vous puissiez atteindre plus facilement les objectifs de consolidation et de performance de votre plateforme.
Il y a deux choses à réaliser ici:
- L'unité de performance DB par unité de matériel est un peu inférieure 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 performances.
- Cela ne signifie pas que le même niveau ou un niveau de performance souhaité est impossible à obtenir. Les gains que vous obtenez d'une gestion améliorée et d'autres avantages (comme une HA plus facile) sont souvent façon plus que compenser les coûts matériels légèrement augmentés.
Cela dit, où je travaille, notre installation Sql Server est l'un des deux seuls serveurs que je n'ai pas l'intention de virtualiser de sitôt (l'autre est le DC principal).
L'exécution de SQL Server est un VM sera très bien, à condition que vous puissiez fournir suffisamment de ressources au VM pour exécuter votre application. Si dans le monde physique vous avez besoin 24 cœurs et 256 Go de RAM alors vous devez fournir 24 vCPU et 256 Go de RAM dans le monde virtuel).
Je viens de a écrit un article au cours des derniers mois, le magazine SQL Server a tout expliqué sur l'exécution de SQL Server sous vSphere de VMware.
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 iSCSI SAN LUN, découpé avec des volumes logiques LVM2. La base de données MySQL est uniquement pour Cacti, et donc ne voit pas beaucoup d'utilisation du tout, et est située sur l'iSCSI LUN également.
La base de données PostgreSQL est la base de données de notre environnement de transfert, et voit donc une utilisation plus élevée que la base de données MySQL. Pour cette raison, la base de données se trouve sur un ensemble RAID10 local et DRBD est répliqué sur le deuxième nœud de cluster. Cependant, en termes de charge réelle, cette base de données intermédiaire ne voit pas du tout de charge très élevée. Ce qui, à mon avis, en fait un bon/excellent candidat à virtualiser.
Certains des avantages pour notre organisation étaient la consommation d'énergie réduite, l'espace de rack économisé et les frais administratifs administratifs du matériel.
D'un autre côté, notre base de données de production principale, je ne peux pas imaginer devenir virtuel ...
Je travaille avec des serveurs MSSQL et MySQL sur de nombreux serveurs. Il y a quelques années, j'hésitais à commencer à configurer des serveurs SQL sur des machines virtuelles parce que j'avais entendu parler des problèmes de performances liés à l'exécution d'un serveur SQL sur une machine virtuelle. Cependant, j'ai été surpris après avoir configuré mes deux premiers serveurs SQL et je n'ai vu 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 virtuellisé les serveurs SQL.
Oui, le VM ajoute des frais généraux et si vous allez héberger plusieurs VM sur une seule boîte, vous allez avoir besoin d'un serveur costaud Nice. Un problème de ressource commun à rechercher ajoute des machines virtuelles supplémentaires et réduit les ressources disponibles. Il est courant de planifier une certaine croissance, mais si vous avez acheté votre serveur pour héberger 2 ou 3 machines virtuelles et maintenant ses 10 machines virtuelles en cours d'exécution, vous verrez probablement une baisse 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 des performances médiocres, il y a probablement un problème avec l'environnement.