Robuste Hana- Umgebungen bauen

Neben dem Implementierungsansatz der Appliance (Black Box) und der kundenspezifischen TDI (Tailored Datacenter Integration) gibt es verschiedene Formen der Verfügbarkeitsauslegung einer Hana-Landschaft.

Diese werden wiederum direkt durch die Architektur selbst beeinflusst. Dabei unterscheidet man grundsätzlich zwischen der asynchronen oder Storage-basierten High Availability (HA) und den synchronen HA-Mechanismen, die die Hana DB von Haus aus mitbringt.

Neben dem Modus „asynchron“ gibt es noch innerhalb der synchronen HA drei verschiedene Auslegungen: Sync, Sync-MEM und Full Sync. Während der Standard Sync Modus mit einer Fire-and-Forget-Methode zur Schatteninstanz verglichen werden kann, warten die anderen beiden Mechanismen darauf, dass die Spiegelseite die Datenbankbefehle entweder im Memory, im Full-Modus oder sogar bis in den Storage weggeschrieben hat.

Die daraus resultierenden erhöhten Sicherheitsstufen der Synchronität werden mit einer ebenfalls erhöhten Abhängigkeit und höheren Performanceanforderungen auf der Spiegelseite erkauft. So kann es im schlechtesten Fall beim Full Sync dazu kommen, dass eine Spiegelseite die Produktivseite ausbremsen oder komplett lahmlegen kann.

Je nach gewünschter HA-Stufe muss die Spiegelseite entsprechend performant zur Produktivseite aufgebaut werden. Zudem gibt es in Scale-out-Umgebungen die Option des Failover, um einem Serverausfall vorzubeugen.

Darüber hinaus gibt es aktuell zwei Cluster-Varianten auf Betriebssystemebene, als Ergänzung zu den Sync-Methoden der Hana selbst. Manuell (händisch bzw. skriptbasiert) oder vollautomatisch mit einem Cluster Framework (Red Hat Enterprise Linux High Availability Add-on bzw. Suse-Extension).

Demzufolge kommt schon in der Architektur- und Designphase die Frage auf: Wer führt den Takeover durch (geplant oder ungeplant)? Der DB-Admin auf Hana-Ebene oder doch der Linux-Admin im Cluster Resource Manager (Pacemaker). Spätestens für das Einstellen des DBSL Suspend Features wird zudem der SAP-Basis-Admin benötigt.

Insgesamt kann man festhalten, dass die meisten SAP-Kunden heute eine TDI-Umgebung klar einer Appliance vorziehen, zum einen, um bestehende Investitionen weiterzuverwenden, und zum anderen, um die Gesamtarchitektur robust und gemäß ihren Anforderungen anzupassen.

Bzgl. der HA-Architektur sind die Sichten so unterschiedlich wie die Bedarfe. Meistens werden Failover-Szenarien mit dem Standard-Sync-Mechanismus ergänzt, um auf HW- und SW-Ebene Vorsorge zu tragen.

Hana Lifecycle und Folgen

Durch die rasante Entwicklung der Hana-Technologie sieht der Wartungszyklus der SAP für ein SPS effektiv nur neun Monate Support vor. In Anbetracht dessen, dass man nur DSPs (Data Center Service Points) in Produktionsumgebungen einsetzen sollte (deren Freigabe ist etwa alle sechs Monate), werden die Wartungsfenster zeitlich sehr knapp.

Besonders, wenn man noch eine Testphase von ein bis zwei Monaten abzieht. Möchte man zudem Hana eigenständig installieren und betreiben, benötigt man mindestens zwei Hana-Zertifizierungen.

Neu ist allerdings, dass diese Zertifizierungen nur noch drei SPS, also ca. 3 x 6 Monate, gültig sind. Aktuell ist noch unklar (Rückfrage liegt direkt bei der SAP), ab wann die Zertifizierung gültig ist, sprich zum Zertifizierungs- oder zum Releasezeitpunkt.

Unabhängig davon resultiert aktuell ein Re-Zertifizierungs­bedarf der Mitarbeiter spätestens alle 1,5 Jahre bzgl. Hana. Bei allen anderen von SAP zugelassenen DBs (AnyDB) war dies nie der Fall. Stellt sich die Frage, ob das ein notwendiges Muss oder doch nur eine zusätzliche Einnahmequelle der SAP darstellt.

Wer ist zuständig?

Wie schon zuvor angesprochen stellen sich aufgrund der Hana-kundenindividuellen TDI-Architekturen die Zuständigkeitsfragen bzgl. des Betriebs, des Monitorings und der Wartung. Welcher Fachbereich ist wofür in der Hana-TDI zuständig? Insourcing, Outsourcing/Cloud oder Managed Services?

Bei vielen Kunden wird dies über die Hana-Einführung neu definiert. Hier empfiehlt sich, über einen Hana SLA eine RACI-Matrix zu legen, welche Aufgaben vom Linux-, HDB- oder SAP-Basis-Admin umgesetzt und verantwortet werden.

Anhand dessen kann man auch mit wenig Aufwand seine Sourcing- und Ausbildungsbedarfe ermitteln. Zudem sei erwähnt, dass ein vernünftiges und in Hana integriertes Meldewesen (Alerting) aktuell nur über den Solution Manager erreichbar ist.

Ein weiterer wichtiger Punkt ist das Hana Housekeeping. Der Backup-Katalog enthält alle wichtigen Data- und Log-Sicherungen und wird bei jedem Backup mitgesichert. Dieser sollte zyklisch bereinigt werden, da es dafür keine automatisierte Funktion in Hana gibt.

Fazit

Aus technologischer Sicht lässt sich festhalten, dass sich Hana nach wie vor in einer steilen und dynamischen Entwicklungskurve befindet. Es empfiehlt sich, sich sowohl architektonisch als auch organisatorisch nachhaltig aufzustellen, um von den Neuerungen profitieren zu können und um die Hana-Technologie als Kernkompetenz im eigenen Unternehmen zu etablieren.

Da­runter fällt auch weitsichtig das Prüfen und Scannen der bestehenden ERP-Komponenten in Richtung S/4 Hana mittels des Reports R_S4_PRE_TRANSITION_CHECKS (Hinweis 2182725), der ca. ein Jahr bestehende SAP-Systeme in Richtung S/4 Hana Readiness prüfen sollte.

Hana & Non-ERP

„Es dürfte vergleichsweise schwer hierfür werden“

meint Matthias Kneissl.

„Klar stellt SAP mit dem Hana-Stack auch eine Lösung zur Verfügung, die durchaus mit einem JBoss mehr als konkurrieren kann.

Allerdings gibt es darüber hinaus sicherlich auch das Thema hinsichtlich Preise und Lizenzierung. Darüber hinaus sind klassische Java-Enter­prise-Entwickler ihre jeweiligen Stacks gewohnt, sodass es schwierig werden dürfte, hier einen Takeout der bekannten Kandidaten JBoss oder WebSphere durchzuführen.

Damit ein Kunde den Stack tauscht – im J2EE- Umfeld ja deutlich komplizierter als in der SAP-Welt, wo eine OS/DB- Migration mit Standard-Tools möglich ist –, muss er ja deutliche Vorteile daraus ziehen.

Sicherlich sind die Bibliotheken für Textsuche und Fuzzy-Logik toll, diese werden aber unserer Ansicht nach von SAP noch nicht stark genug in der Community vermarktet. Darüber hinaus ist SAP auch in der Java Community ein neuer, bislang weitestgehend unbekannter Player.“

Guido Hoepfner ergänzt dazu, dass die Innovation bei den Q-Partners-Kunden einerseits im Bereich mobiler Lösungen, Nutzung der Fiori Apps sowie Entwicklung eigener Applikationen auf Basis SAPUI5 stattfindet.

„Im Bereich Technologie ist es tatsächlich so, dass sich eine Vielzahl unserer Kunden für das Thema SAP Hana interessiert und wir aktuell diverse Umstellungen bestehender Lösungen auf Hana durchführen“

berichtet er aus seiner beruflichen Praxis.

„Wenn dieses Fundament gelegt ist, sind die Voraussetzungen für Innovationen aufseiten der Applikation möglich. Dies ist eine Entwicklung, die wir kommen sehen. Logischer und erster Schritt ist die SAP-basistechnische Umstellung auf die neue Plattform.“

Die Herausforderungen liegen insbesondere darin, die neuen Programmiermodelle, Technologien und Architekturen zu integrieren. Aus der Historie heraus kann in Abap sowohl objektorientiert als auch historisch nicht objekt­orientiert strukturell programmiert werden.

„Dies ist ja heute noch in Reports üblich und bisweilen auch sinnvoll“

betont Kneissl.

Mit der neuen Technologie in Richtung Hana, SAPUI5 und NetWeaver Gateway muss man sich deutlich stärker in Richtung Objektorientierung bewegen.

„Dies ist insbesondere wichtig, damit Anwender die neuen Technologien sinnvoll nutzen können und auch von den Vorteilen profitieren. Dies ist natürlich schon ein deutlicher Change, den ein Anwender nicht von heute auf morgen realisiert. Im Bereich der Technologie verhält es sich ähnlich“

ergänzt Hoepfner.