Virtualisation - mais avec quoi ?

Chaque environnement a ses propres adaptations pour la haute disponibilité (selon les SLA), le support et les licences. Mais avec Hana, d'autres restrictions viennent s'ajouter aux fonctionnalités.

Dans ce cas, il faut évaluer, sur la base des structures données, du savoir-faire ainsi que de la taille et de la complexité de l'environnement système existant, laquelle des plates-formes est la mieux adaptée aux processus.

Ces restrictions rigides (également présentes dans l'environnement Appliance ou Bare Metal TDI et dans le matériel qui en résulte) sont totalement excessives pour la plupart des clients et suscitent leur mécontentement.

Peu d'entre eux passent outre en raison de la thématique du support et sont prêts à conserver des réserves de l'ordre de grandeur nécessaire en cas de support.

SAP et les fabricants de matériel informatique travaillent à une solution qui doit assurer la flexibilité nécessaire. Les groupes d'utilisateurs qui animent ce thème chez SAP fournissent un travail précieux dans ce domaine.

La communauté Hana-on-Power et DSAG sont particulièrement intéressées par les optimisations à court terme. Mais on ne sait pas encore quand cela sera publié.

La meilleure dynamique grâce à la virtualisation

Mais la virtualisation reste le meilleur moyen d'obtenir la dynamique nécessaire. De nombreuses entreprises utilisent même les deux techniques de virtualisation.

On voit dans de tels environnements un fonctionnement mixte de la virtualisation de puissance via LPAR pour les applications critiques et gourmandes en performances et de VMware pour les applications moins critiques et plus petites comme p. ex : ASCS ou autres ApplicationServer (AAS), portails Java, systèmes RH (Hana Sizing <4TB vSphere 6.x ou <1TB vSphere 5.5).

La bande passante mémoire et la performance Pro-Core d'IBM jouent ici un rôle essentiel en matière de performance, tout comme les différentes fonctionnalités RAS qui préservent différents composants d'une panne complète dès la phase de conception du matériel.

La flexibilité est assurée par des adaptations des ressources ainsi que par l'ajout à court ou à long terme de ressources non encore licenciées via CoD (capacity on demand) (gratuit à titre d'essai ; durablement lié à des coûts).

Le fait de pouvoir virtualiser des systèmes d'exploitation comme Windows est un argument en faveur de VMware. Il s'agit toutefois d'un aspect qui ne touche Hana que de manière marginale (par exemple en tant que serveur d'applications ou serveur pour d'autres applications qui communiquent avec le HDB, comme Power Designer, Data Services, etc.)

Outre la validation pour Hana listée dans le tableau, il y a bien sûr aussi des aspects tels que VMwareHA et Fault Tolerance, qui sont volontiers utilisés pour assurer la disponibilité, notamment lors de l'utilisation de serveurs d'applications et d'ASCS, car l'utilisateur ne remarque pratiquement rien en cas de panne.

Cet hyperviseur est donc tout à fait adapté aux applications critiques, tant que les performances sont suffisantes et que le dimensionnement le permet. Les possibilités et les applications sont multiples.

Si l'on attache de l'importance à une disponibilité maximale, il ne suffit pas de garder tous les composants hautement disponibles pour une éventuelle panne du centre de données, mais il faut aussi penser à leur maintenance.

C'est là qu'interviennent des fonctionnalités telles que la réplication du système (Near Zero Downtime Maintenance avec DBSL Suspend Feature) et le Rolling Kernel Switch, qui garantissent une maintenance sans interruption du système d'exploitation, de la base de données Hana ou du noyau SAP. Pour ce faire, les deux hyperviseurs offrent l'intégration nécessaire.

Ceux qui souhaitent rester homogènes et qui exploitent déjà leurs serveurs Windows existants de manière virtualisée, se tournent vers VMware.

Celui qui utilise déjà un Power-HW ou qui a maintenant des conditions SLA plus élevées ou des exigences de performance et que cela n'est pas réalisable avec VMware, a recours à la solution d'IBM.

Comme nous l'avons déjà mentionné, un mélange est la meilleure solution, mais aussi la plus chère. Il réunit les avantages des deux mondes et compense les inconvénients. Cela est envisageable si l'on est contraint d'étendre son environnement VMware/Power en raison de Hana, mais que l'on a des exigences très élevées pour le nouvel environnement.

Il en résulte que : Représentation de la couche de base de données (Hana) via LPAR et couche de présentation/clients (PAS, AAS, ASCS) avec VMware.

Les deux plateformes ont leurs avantages et leurs inconvénients. Au final, toutes deux doivent pouvoir s'intégrer dans les processus existants.

Il ne s'agit pas seulement de savoir ce qui est le plus cher ou le plus performant, mais aussi ce qui s'intègre le mieux dans votre paysage. En fin de compte, ce sont les administrateurs qui doivent les gérer.

Par expérience, c'est comme souvent une question de philosophie.