Utiliser VMWare, ou tout autre solution de virtualisation avec des infrastructures x86 32 ou 64 bits a de nombreux intérêts, en particulier avec Oracle; elles permettent :

• d’utiliser au mieux les ressources des datacenters en permettant de consolider les services sur les mêmes serveurs et ainsi d’optimiser les investissements; certaines fonctions, comme VMWare DRS, permettent de déplacer les ressources d’un serveurs à un autres automatiquement et avec un impact limité
• d’apporter une grande flexibilité aux administrateurs qui peuvent créer ou utiliser des templates / gold images ou déplacer les machines virtuelles et les disques d’un serveurs à l’autre avec des solutions comme VMotion et Storage VMotion
• d’isoler les environnements les uns des autres dans des machines virtuelles séparées et ainsi, à la fois, de simplifier les installations et limiter l’impact des erreurs
• d’offrir des solutions pour reprendre automatiquement les services en cas de perte d’un serveur ou une erreur matérielle comme VMWare HA et VMWare Fault Tolerant.
• de simplifier les configurations en remplaçant des périphériques physiques (réseaux, stockage…) par des périphériques virtuels. Cela permet également d’uniformiser les infrastructures à gérer, malgré les différences des matériels et des systèmes d’exploitation.
• de maintenir des systèmes vieillissants sans avoir à mettre à jour les systèmes d’exploitation.

La plupart des entreprises utilisent la virtualisation sur x86. Cette tendance n’est pas nouvelle: il y a 7 ans j’utilisais déjà VMWare sur des environnements de test avec Oracle. Toutefois, il y a plusieurs choses à connaitre lorsque vous utilisez Oracle avec ce type de technologies…

Support et Stratégie

Commençons par l’ensemble des solutions de virtualisation supportées par les bases de données Oracle ! Vous y découvrirez qu’Oracle ne supporte aucun environnement virtualisés sur les plateformes x86 et x86_64 sauf OracleVM. Pour plus de détails, reportez-vous aux notes « 249212.1 – Support Position for Oracle Products Running on VMWare Virtualized Environments » et « 464754.1 – Certified Software on OracleVM« .

Mais de qu’est-ce que ça veut dire ? Pour résumer, si vous utilisez Oracle et rencontrez un problème connu, Oracle vous supportera. Si par contre, le problème n’est pas référencé, vous devrez apporter la preuve que ce n’est pas votre environnement virtualisé qui introduit le problème. Vous pourrez, par exemple, reproduire le-dit problème sur un environnement non virtualisé ou avec OracleVM. Et le diable étant dans les détails, il existe des différences de moins en moins subtiles entre les environnements virtualisés et ceux non virtualisés; c’est d’autant plus vrai que ces technologies s’intégrent désormais dans les puces d’Intel et d’AMD.

Changeons de point de vue; au lieu de regarder pourquoi Oracle ne supporte pas les environnements virtualisés sur x86, regardons plutôt pourquoi Oracle développe un environnement virtualisé (basé sur Xen) pour ses produits.

Une base de données repose sur des ressources avec lesquelles, les environnements virtualisés ne sont pas toujours aussi à l’aise que pour gérer de la puissance CPU:

• Oracle doit pouvoir s’appuyer sur des infrastructures de stockage performantes qu’il gère par lui même avec des composants comme ASM ou DirectNFS et en intégrant des protocoles particuliers sur des technologies comme Infiniband,
• Oracle s’appuie sur la connaissance de l’OS pour utiliser au mieux des larges segments de mémoire ou pour décider du niveau de parallelisme qu’il peut mettre en oeuvre et ainsi optimiser la gestion des ressources du serveur
• Oracle offre des fonctionnalités, au premier rang desquel le clustering, qui s’appuient sur les couches les plus profondes des OS pour gérer l’IO fencing ou assurer la cohérence d’infrastructures s’appuyant sur plusieurs serveurs.

Vu sous cet angle, il devient évident que l’infrastructure de virtualisation et la base de données ont tout intérêt à être intimement liées pour tirer le meilleur bénéfice l’un de l’autre. Alors vous direz qu’Oracle aurait pu mieux travailler avec VMware, Microsoft VirtualPC, KVM et la multitude d’autres fournisseurs d’infrastructures virtuelles, comme ils l’ont fait avant avec IBM ou Sun pour AIX et Solaris… A différentes époques différentes solutions, Oracle a choisi cette fois-ci de développer OracleVM et de racheter Virtual Iron. Ca sera peut-être aussi efficace après tout que de multiplier les partenariats pour délivrer la meilleure solution. Qui sait?

Implémenter Oracle sur des environnements x86 virtualisés

Les organisations mettent en oeuvre différents types d’environnements pour différents objectifs. Ces environnements ont des besoins distincts:

• Les environnements de développement et de tests unitaires n’ont souvent pas besoin d’être très performant, contrairement aux environnements d’intégration, de qualité (pré-production), de production ou pour le plan de reprise d’activité. Ces environnements ne contiennent souvent que de petits jeux de tests mais les développeurs aimerait toujours en avoir plus.
• Selon les cas, les développeurs voudront reconstruire des environnements de tests mensuellement, hebdomadairement ou même pour chaque série de tests. De plus, la manière de reconstruire ces environnements est souvent très différente de la manière de reconstruire un environnement de pré-production qui doit quant à lui rester le plus proche possible de la production.
• L’indisponibilité d’un environnement de production peut coûter très cher tandis que l’indisponibilité d’un environnement de test pourra avoir un impact limité dans certains cas.

Appuyez-vous sur ces besoins différents pour répartir vos environnements de manière pertinente… Ayez également à l’esprit un certain nombre de limites des environnements virtualisés sur x86:

• VMWAre, VirtualPC et les solutions basées sur Xen ne permettent pas de garantir un minimum de ressources à plusieurs Virtual Machines qui utilisent les mêmes processeurs. Si les solutions comme DRS permettent d’imaginer pouvoir rebalancer les environnements lorsque des minimas sont atteints, ses solutions sont limitées avec des bases Oracle, au moins avec les bases de production; le fait qu’OracleVM Live Migration ne soit pas encore supporté avec Oracle donne le ton… On aura donc tendance à, sinon complétement séparer les environnements de production des environnements de tests, au moins à dédier des processeurs par type d’environnements ou à permettre à dédier certains processeurs physiques à vos environnements de production^(*)
• Les autres limites de VMWare et aux autres environnements virtualisés sur x86 sont relatifs à l’utilisation de la virtualisation du stockage et militent p
  our l’utilisation des technologies de virtualisation directement au niveau d’Oracle comme ASM ou DirectNFS:
  • Un device virtuel ne peut pas être accédés directement depuis un serveur physique ce qui limite les possibilités si vous voulez pouvoir vous appuyer sur une approche V2P pour adresser un éventuel problème avec une base de données de production.
  • Comme pour les ressources CPU, si les devices virtuels partagent les même devices physiques, il n’y a pas de moyen de prioriser ou de balancer les accès disques simplement.

Mais tout ceci n’est qu’un début et Oracle a désormais les clés pour offrir le niveau suivant à la virtualisation. Il faut dire qu’avec Virtual Iron, Sun Solaris, Sun xVM, VirtualBox ou JRockit Virtual Edition et quelques milliards de cash, l’avenir sera intéressant…

(*) n’oubliez pas que virtualisation ne signifie pas seulement mutualisation et qu’il y a plusieurs avantages à avoir, pourquoi pas, un serveurs physique pour une machine virtuelle. Les capacités de clonage ou de de reprendre en quelques minutes tout un environnement virtuel sur un autre serveur sont quelques exemples des autres bénéfices de la virtualisation.