Virtualisierung – aber womit?

Jede Umgebung hat eigene Adaptionen für Hochverfügbarkeit (nach SLAs), Support und Lizenzierung. Mit Hana kommen neben den Features aber auch weitere Restriktionen hinzu.

Hier muss man aufgrund der gegebenen Strukturen, Know-how sowie Größe und Komplexität der vorhandenen Systemumgebung abwägen, welche der Plattformen den Prozessen besser gerecht wird.

Diese starren Restriktionen (auch im Appliance- oder Bare-metal-TDI-Umfeld vorhanden und in der daraus resultierenden Hardware) sind für die meisten Kunden vollkommen überzogen und sorgen für Unmut.

Wenige setzen sich aufgrund der Supportthematik darüber hinweg und sind bereit, Reserven in der nötigen Größenordnung für den Supportfall vorzuhalten.

SAP und die Hardwarehersteller arbeiten an einer Lösung, die für die nötige Flexibilität sorgen soll. Wertvolle Arbeit leisten hier die User­groups, die dieses Thema bei der SAP treiben.

Besonders die Hana-­on-Power-Community und DSAG sind an kurzfristigen Optimierungen interessiert. Wann dies aber veröffentlicht wird, steht noch in den Sternen.

Beste Dynamik durch Virtualisierung

Die nötige Dynamik kann aber immer noch am besten mit Virtualisierung erreicht werden. Viele Unternehmen setzen sogar beide Virtualisierungstechniken ein.

Man sieht in solchen Umgebungen einen gemixten Betrieb aus Power-Virtualisierung via LPAR für kritische und performance­intensive Applikationen und VMware für unkritischere und kleinere Anwendungen wie z.B.: ASCS oder weitere ApplicationServer (AAS), Java-Portale, HR-Systeme (Hana Sizing <4TB vSphere 6.x oder <1TB vSphere 5.5).

Hier spielen bei der Performance die Memory-Bandbreite und die Pro-Core-­Performance bei IBM eine wesentliche Rolle, ebenso die verschiedenen RAS Features, die verschiedene Komponenten bereits hardwaretechnisch vor einem Komplettausfall bewahren.

Die Flexibilität ist durch Ressourcen-Anpassungen sowie das kurz- oder auch langfristige Zuschalten von noch nicht lizenzierten Ressourcen via CoD (capacity on demand) gegeben (testweise kostenlos; dauerhaft mit Kosten verbunden).

Für VMware spricht, auch Betriebssysteme wie Windows virtualisieren zu können. Das ist allerdings ein Aspekt, der Hana nur am Rande tangiert (z. B. als Applikationsserver oder Server für weitere Anwendungen, die mit der HDB kommunizieren, wie etwa Power Designer, Data Services etc.).

Neben der in der Tabelle gelisteten Freigabe für Hana gibt es natürlich auch Aspekte wie VMwareHA und Fault Tole­rance, die gerade beim Einsatz von Applikationsservern und ASCS zur Absicherung der Verfügbarkeit gerne genutzt werden, da der Anwender so gut wie nichts bei einem Ausfall mitbekommt.

Somit eignet sich auch dieser Hypervisor sehr wohl für kritische Anwendungen, solange die Performance genügt und das Sizing dies zulässt. Die Möglichkeiten und Einsatzzwecke sind vielseitig.

Wenn man Wert auf eine maximale Verfügbarkeit legt, muss man nicht nur alle Komponenten für einen möglichen Ausfall des Rechenzentrums hoch verfügbar halten, sondern sich auch Gedanken über deren Wartung machen.

Hier kommen Features wie System Replication (Near Zero Downtime Maintenance mit DBSL Suspend Feature) und Rolling Kernel Switch ins Spiel, die eine unterbrechungsfreie Wartung von Betriebssystem, Hana-Datenbank oder SAP-Kernel gewährleisten. Hierzu bieten beide Hypervisoren die nötige Integration.

Wer homogen bleiben möchte und seine bestehenden Windows-Server bereits virtualisiert betreibt, der greift auf VMware zurück.

Wer bereits eine Power-HW im Einsatz hat oder nun höhere SLA-Bedingungen bzw. Performance-Ansprüche hat und dies nicht mit VMware realisierbar ist, der greift auf die Lösung von IBM zurück.

Ein Mix ist, wie bereits erwähnt, die beste, aber auch teuerste Lösung. Er vereint die Vorteile beider Welten und gleicht die Nachteile aus. Dies ist denkbar, wenn man aufgrund von Hana gezwungen ist, seine VM­ware-/Power-Landschaft zu erweitern, aber sehr hohe Anforderungen an die neue Umgebung hat.

Daraus folgt: ­Abbildung des Datenbank-Layers (Hana) via LPAR und Präsentationsschicht/Clients (PAS, AAS, ASCS) mit VMware.

Beide Plattformen haben ihre Vor- und Nachteile. Am Ende müssen sich beide in bestehende Prozesse integrieren lassen.

Dabei kommt es nicht nur darauf an, was teurer oder besser performt, sondern was sich am besten in Ihre Landschaft einfügt. Schlussendlich sind es die Administratoren, die damit umgehen müssen.

Aus Erfahrung ist es wie so oft eine Philosophiefrage.