Faisant parti des heureux utilisateurs d’un Exadata X5-2 dans le cadre d’un très important projet, je tiens à vous faire part de quelques informations issues de la mise en place d’une architecture au quotidien.
L’Exadata X5-2 peut être utilisé comme ses prédécesseurs sans virtualisation, mais l’angle d’étude qui  m’intéresse pour cet article est justement la virtualisation que nous pouvons dorénavant mettre en œuvre sur l’Exadata. Cette fonctionnalité peut sembler étonnante sur une machine dédiée et optimisée pour des bases de données dont la consolidation peut être réalisée avec des méthodes propres aux bases de données Oracle comme le multitenant, le multi-schéma,  le multi-base, le resource manager, …

Nous allons cependant nous intéresser aux avantages de la virtualisation sur Exadata et les principes de sa mise en œuvre sur Exadata, laissant pour un prochain article son  l’implémentation technique et sa gestion.

L’Exadata en quelques mots

L’Exadata est constitué de deux types de serveurs sur-gonflés : Les database servers (dbnodes) et les storage servers (dbcell). Les dbnodes sont les serveurs physiques sur lesquels les logiciels de bases de données sont installés, les storages servers sont les serveurs de stockage, mais il ne sont pas seulement cela parce qu’ils sont optimisés de manière à ce que le stockage possède une intelligence d’accès aux données en lien avec le moteur de base de données installé sur le database server. Celui-ci lui délègue une bonne partie de  l’optimisation de la recherche des données.

Quel est l’apport de la virtualisation sur Exadata vs déploiement en environnement physique?

Deux aspects principaux qui motivent l’introduction de cette fonctionnalité majeure qu’est Oracle VM :

• L’isolation fonctionnelle
  Les dbnodes sont en nombre limité dans chaque Exadata, par exemple nous en trouvons huit sur un Exadata de type Full.
  Prenons le cas d’un Exadata 1/8 qui dispose de deux dbnodes. Nous n’avons pas la possibilité d’isoler les bases de données de développement et de production sur des dbnodes différents si elles sont gérés par un cluster deux nœuds.
  Sur ce même Exadata 1/8, si les bases de données sont en mono-instances, nous sommes obligés, pour réaliser une isolation, de répartir la production sur le dbnode 1 et le développement sur le dnode 2. Le développement utilise à lui seul un db node ce qui sera la plupart du temps surévalué, surtout d’un point de vue gestion des licences.
  Sur l’Exadata dorénavant, la virtualisation va nous donner la possibilité d’organiser la répartition des ressources différemment. Exemple : Il est possible de créer sur le dbnode 1 une machine virtuelle (VM) avec deux vcpus dédiées à l’environnement de développement. L’environnement de production disposera quant à lui de deux machines virtuelles à 4 vCPUs gérées par un cluster Oracle, réparties sur les dbnodes 1 et dbnodes 2.

• La consolidation des licences
  L’utilisation d’Oracle VM sur Exadata permet une consolidation des licences par le concept de trusted partition. Ce concept reconnait l’utilisation d’Oracle VM pour limiter le nombre de CPUs comptabilisés dans le calcul de licence. En clair, seules les ressources utilisées par les machines virtuelles sont prises en compte dans le calcul des licences.
  Parmi les règles telles qu’édictées par Oracle dans le document « http://www.oracle.com/us/corporate/pricing/partitioning-070609.pdf » nous trouvons :
  « For the purposes of licensing Oracle programs in a Trusted Partition, two(2) virtual CPUs (vCPU) are counted as equivalent to a physical core. Licenses must be procured in increments of 2 physical cores. The customer is required to license the highest number of vCPUs running at any given time (highwater mark), however they are not required to license more than the total number of physical cores in the machine. Hyper-threading must be enabled for processors when using Trusted Partitions ».
  Exemple : une machine virtuelle utilise 4 vCPus. Selon la règle énoncée ci-dessus, Cela revient à l’utilisation de deux coeurs de Cpus.

L’architecture virtuelle sur Exadata

S’il est question d’Oracle VM dans les documents de présentation d’Oracle, il s’agit plutôt dans les faits de l’utilisation de Xen sans la surcouche Oracle VM. Oracle VM n’est donc pas implémenté dans sa totalité (du moins pour l’instant) pour une raison évidente d’architecture. En effet, puisqu’il s’agit de gérer des bases de
données, la haute disponibilité des serveurs est réalisée par la mise en place de RAC, et non par Oracle VM dont les possibilités de haute disponibilités permettent de redémarrer un serveur virtuel de base de données sur un autre hyperviseur, mais avec un arrêt de celui (je parle ici de HA, non de live migration).
Chaque dbnode possède ainsi son propre repository de vm hébergé sur un disque local, donc non visible depuis un autre dbnode. De base, les machines virtuelles ne sont pas déplaçables d’un dbnode à l’autre, seule une action manuelle de recopie de disques virtuels d’un dbnode à l’autre permet de le réaliser.