The Day after Hana Going Live

Für viele ist der Umstieg auf Hana und S/4 eine enorme Umstellung, denn es ändert sich nicht nur die Datenbank, sondern ebenso das darunterliegende Betriebssystem. Der bisherige Betrieb und damit das Betriebshandbuch müssen grundlegend überarbeitet werden.

Ab hier beginnt eine Thematik, die viele in ihren Projekten oft vernachlässigen, da auch der Praxisbezug zur neuen Umgebung für viele Administratoren fehlt und dadurch einige Fallstricke erst bei Umsetzung aufgedeckt werden.

Meist existieren noch keine Konzepte für die Arbeitspakete Systemprovisionierung unter Linux, die Systemkopien mit Hana, das Monitoring, das Transportwesen der Hana-Objekte, Berechtigungen, die zyklischen Wartungen oder für die Verifikation und Validierung neuer Hana-Revisionen.

Gerade der Aufwand zum Thema Wartung sollte nicht unterschätzt werden, denn viele Komponenten besitzen untereinander Abhängigkeiten, welche vorher nicht berücksichtigt werden mussten.

Neben den allseits bekannten Restriktionen bezüglich Storage, Server und Betriebssystem gibt es auch weitere Limitierungen. Das hat zur Folge, dass viele Teams (Server, Betriebssystem, Datenbanken, SAP-Basis) sich noch stärker als vorher abstimmen müssen.

Um möglichst wenige Downtimes zu produzieren, ist es empfehlenswert, die Wartungszyklen der Komponenten zu synchronisieren. Im „Suse Linux Enterprise Server for SAP Applications“ mit dem erweiterten Support für das Produkt hat Suse dies bereits sehr erfolgreich integriert.

Hier wurde zum Beispiel das Wartungsende von Hana 2 SPS01 mit SLES for SAP 12 SP1 gekoppelt. Als Nächstes laufen SLES for SAP 12 SP2 im April 2019 und Hana 2 SPS02 aus der Wartung.

Bei einer solchen Wartung stellt sich immer wieder die Frage der technischen Verifikation und der fachlichen Validierung. Die meisten Key User haben neben der Projektarbeit und dem normalen Betrieb kaum Kapazitäten für Tests. Hier kommt das Feature „Capture & Replay“, welches kostenfrei ist – sprich bereits in der Hana-Lizenz eingepreist –, zum Zuge.

Hiermit kann man den Workload, welcher durch SQL-Statements erzeugt wurde, 1:1 auf einem weiteren System abspielen. Hat Ihr produktives ERP-System also 2000 User, so können Sie alle Transaktionen innerhalb einer definierten Zeit erneut ausführen. Voraussetzungen sind lediglich ein Backup des produktiven Systems sowie eine Aufzeichnung eines solchen Zeitraums.

Dieses Backup wird auf ein anderes System, zum Beispiel das Qualitätssicherungssystem (QAS), eingespielt. Hier können Sie dann mehrere Iterationen an Änderungen (Patch der Hana/Linux, Parameteränderungen) abbilden und bei jedem Durchlauf die Ergebnisse vergleichen, beispielsweise ob die Abfragen schneller beziehungsweise langsamer waren oder es sogar zu einem Fehler kam.

Mit diesem Verfahren können Sie die Key User entlasten und sogar einen Lasttest mit produktiven Daten inklusive 2000 Usern oder mehr durchführen. Das System muss am Ende nicht „entsorgt“, sondern kann mit den Nacharbeiten der Systemkopie als QAS wieder zurück in die Landschaft gebracht werden. Es ist also sehr sinnvoll, derartige Wartungsarbeiten an die bestehende Planung der Systemkopien zu koppeln.

Was kann „Capture & Replay“ nicht? Es ist nicht möglich, einen SAP-Kerneltausch oder Release-Wechsel zu testen.

Fazit

Durch die Komplexität und Abhängigkeiten der Hana-Systemkomponenten schreit es gerade dazu nach einer Teilautomatisierung der Tests. Durch die steigenden Anforderungen, sinkende Anzahl an Wartungsfenstern und die knackigen Release-Zyklen ist eine Optimierung des Wartungsvorgangs mehr als nur gewünscht.

Wenn man dies noch mit dem „Near Zero Downtime Maintenance“-Verfahren (Hana System Replication + DBSL Suspend) und einem Rolling Kernel Switch (RKS) kombiniert, so könnte man auch Wartungen unter der Woche nahezu ohne Auswirkung auf den Endbenutzer durchführen.