Aufgezwungene Wartung, unklare Roadmaps

Die SAP-Kunden sind unzufrieden, über das Wie und Warum wurden schon viele Zeilen geschrieben. Aufgezwungene Wartung, hohe Lizenzgebühren und unklare Roadmaps sind nur einige der Punkte, die immer wieder genannt werden. Leistet aber nicht gerade in der jetzigen Zeit die Zunft der Technologieberater einen wichtigen Beitrag?

Die einem SAP-System zugrunde liegende Technologie hat sich in den vergangenen Jahren nicht verändert. Sie besteht aus einem Betriebssystem, einem Haufen ausführbarer Dateien und einer Datenbank. Das ist so, das war so und das wird auch erst einmal so bleiben. Auch der Trend zu Cloud und S/4 wird daran erst einmal nichts ändern. Ein SAP-System bleibt ein SAP-System.

Gute Voraussetzungen

Die Software wird nach wie vor von vielen Unternehmen, egal ob Inhouse oder Beratung, Schritt für Schritt manuell installiert. Automatische Tools nutzen nur die wenigsten und wenn, dann für gutes Geld. Open-Source-Tools und deren Möglichkeiten werden nicht genutzt. Gerade in Deutschland scheinen gute Lösungen immer etwas kosten zu müssen. Ist das noch zeitgemäß? Oder müssen wir den nächsten Schritt gehen?

Docker existiert seit 2013, Ansible bereits seit 2012, Kubernetes seit 2015. Nichtsdestotrotz scheint oftmals die SAP-Technologie dem Trend zu mehr Agilität und Flexibilität hinterherzulaufen. Die automatische Bereitstellung ist rudimentär ausgeprägt, der Rolling Kernel Switch wird selten genutzt. Infrastructure as Code und Containering scheinen bis jetzt an SAP komplett vorbeigegangen zu sein. Dabei bietet ein SAP-System eigentlich gute Voraussetzungen, um einen solchen Ansatz zu implementieren.

Es stellen sich also ganz simple Fragen: Haben wir alle einfach nur geschlafen? Können wir nicht heute schon SAP-Systeme automatisch deployen? Und wie tief integriert ist das automatische Deployment bereits? Lassen Sie uns doch einfach mal einen Blick auf verschiedene Aspekte eines SAP-Systems werfen. Am Anfang eines SAP-Lebens steht immer die Frage nach Aufbau und Konfiguration: Wie viele Benutzer arbeiten auf dem System? Wie viele Systeme binde ich an meinem SAP-System an und wie? Brauche ich nur ein Produktionssystem oder werden Test und Entwicklung auch benötigt?

Gerade im Mittelstand läuft es meist auf eine 3-System-Landschaft hinaus, bestehend aus einer Kombination aus Datenbank und Applikationsserver. Oft wird auch nur mit einem Applikationsserver gerechnet, auch um Kosten zu reduzieren. Im Hinblick auf Hana wird zuhauf Spitz auf Knopf kalkuliert und hauptsächlich auf die Kosten geachtet. Viele Unternehmen planen aktuell dabei noch mit eigenen Rechenzentren oder Hardware im Outsourcing.

Dabei werden oftmals die Möglichkeiten rechts und links des Mainstreams übersehen. Stellen Sie sich einmal folgendes Szenario vor: Sie sind ein mittelständisches Handelsunternehmen, welches sein SAP ECC 6.0 EHP 7 von AnyDB zukunftssicher auf Hana migrieren möchte. Die Sizing-Reports geben Ihnen einen Speicherbedarf einer Hana-Instanz von 1,5 TB an und es sollen weltweit rund 500 Benutzer auf dem System arbeiten.

Da Sie weltweiten Handel betreiben, wollen Sie natürlich Ihr Produktivsystem hochverfügbar ausgelegt wissen. Die Entwicklung haben Sie bereits extern vergeben und die Kollegen arbeiten sowieso nur zu normalen Geschäftszeiten. Sie könnten natürlich nun eine neue Virtualisierungslösung implementieren und entsprechende Hardware anschaffen. Daten, Aufbau und Wartung liegen in Ihrer Hand. Gegebenenfalls haben Sie noch einen externen Partner hinzugezogen, um sich Unterstützung zu holen.

Unvorhergesehen kam in Ihrer Fachabteilung der Wunsch nach einem Business Warehouse System auf. Dafür war Ihre Hardware aber überhaupt nicht ausgelegt.

Was tun? Weiterdenken!

Option 1: Sie schaffen neue Hardware an. Der Beschaffungsprozess wird Sie einige Zeit kosten und Sie benötigen den entsprechenden Platz im Rechenzentrum.

Option 2: Sie bauen die Systeme extern auf. Sie werden sich auf jeden Fall den langwierigen Hardware-Beschaffungsprozess sparen und geben die Verantwortung für die Hardware in andere Hände. Egal ob nun Amazon Web Services, Microsoft Azure, Google-Cloud-Plattform oder ein anderer Host, die Hardwareverantwortung liegt woanders. Viele Hoster nehmen Ihnen auch noch die Verantwortung für das Betriebssystem und die Datenbank ab. Herzlichen Glückwunsch, Sie sind im Servicedschungel angekommen. Sie dürfen das System nur noch benutzen und jede Änderung benötigt einen eigenen Change.

Option 3: Sie denken weiter. Sie haben Ihr ERP-System bisher mit einer System Replication betrieben und wollen diese auch zwingend beibehalten. Wie wäre es, wenn Sie die Replikationsseite in die Cloud auslagern? Damit erhalten Sie Platz für das gewünschte Business Warehouse und können gleichzeitig noch von den Vorteilen der Cloud profitieren.

„Aber die Kosten!“, werden jetzt sicher einige denken. Cloud ist nicht günstig, keiner der Big Three wird Ihnen Infrastruktur kostenlos zur Verfügung stellen und will natürlich noch etwas verdienen. Wenn Sie nun aber die System Replication ohne Memory Preload nutzen, bezahlen Sie zuerst einmal nur für ein relativ kleines virtuelles System und den Datenbankspeicher.

Im Falle eines Ausfalls der Hauptdatenbank kann die Cloud Virtual Machine innerhalb von Sekunden automatisiert angepasst und hochgefahren werden. Erst jetzt zahlen Sie für die gesamte Größe der Hana-Datenbank.

Wenn wir die Idee noch etwas weiterverfolgen, könnte man doch auch gleich noch Applikationsserver und eine hochverfügbare ASCS-Instanz realisieren. Wenn wir diese noch global verteilen, werden sich die Mitarbeiter in Japan und den USA auch über geringere GUI-Laufzeiten freuen. Natürlich kann man weitere Varianten noch ewig skizzieren, man landet jedoch leider relativ schnell in Regionen, die für einen Mittelständler nicht mehr tragbar und verwertbar sind.

In einem Unternehmen treten immer wieder Zeiträume auf, in denen sich der End­anwender mehr Leistung des Systems wünscht. Das schnelle Hinzuschalten eines Applikationsservers ist dabei sicher eine einfache, aber effektive Lösung. Die nötigen Schritte sind überschaubar, aber selbst versierte Techniker sind mit Bereitstellung, In­stallation und Konfiguration schon einen Tag beschäftigt. Wie wäre es denn, wenn man einen Großteil der Bereitstellung und Installation automatisieren könnte?

Geht nicht? Geht doch!

Infrastructure as a Code, Ansible und Unattended Installation sind die Zauberwörter. Das Ganze ist dabei nicht auf einen der Hyperscaler beschränkt, sondern kann auch ganz einfach auf jedem ESXi mit VSphere ausgeführt werden.

Fangen wir doch einfach mal beim Erstellen der virtuellen Maschine an. Auf VMware wird die VM meist aus einer anderen per ­Cloning-Verfahren oder aus einem Template erstellt. Anschließend erstellt man die nötigen SCSI Controller und Festplatten und bindet sie im Betriebssystem ein. Egal ob mit Befehlen oder Yast, man ist zwei bis drei Stunden allein mit diesem Schritt beschäftigt.

Mit einer Automatisierung mit Ansible können wir diesen ersten Schritt schon in wenigen Minuten erledigen. Zusätzlich können wir im gleichen Schritt bereits unsere Installationsmedien für den Applikationsserver von einer zentralen Datenablage laden und den Software-Provisioning-Manager starten. Es schadet dabei auch nicht, in die GitHub Repositories von Google und Amazon zu schauen. Hier kann man sich für eigens gebaute Skripte sicher das eine oder andere abschauen.

Die Skripte sind im Falle von Linux kein Hexenwerk und jeder, der sich bereits einmal damit beschäftigt hat, wird damit klarkommen. Das Herunterladen und Konfigurieren der benötigten SLES-Pakete wird somit zum Beispiel zu einem sehr kurzen Shell Skript. Auch die Bereitstellung der nötigen Mount-Punkte bzw. Volume Groups und Logical Volumes ist in wenigen, den meisten Linux-Kennern geläufigen Kommandos getan. Windows und auch Linux haben uns die hübschen und bunten GUIs anerzogen, dabei könnte man viele Sachen in wenigen Kommandos abhandeln. Da man diese auch noch speichern und kombinieren kann, werden zukünftige Bereitstellungen immer schneller.

Stolpersteine

Nachdem nun die VM bereitgestellt und das Betriebssystem konfiguriert ist, werden die benötigten Installationsmedien sowie der SWPM heruntergeladen. Im Falle der Goo­gle-Cloud-Plattform legen wir die benötigten Daten organisiert in einem Cloud Bucket ab und können die Daten nun über einfache gsutil-Befehle aus dem Cloud Bucket auf die neue VM laden. Diese Vorgehensweise funktioniert natürlich auch mit AWS und Azure sowie als einfacher NFS Mount im VMware-Umfeld.

Nach dem Platzieren und dem Entpacken des Software Provisioning Managers (folgend SWPM) geht es auch schon an den Aufruf. Hier lauern kleinere Stolpersteine, die man umschiffen muss. Zuerst benötigen wir ein sogenanntes inifile.params sowie die instkey.pkey-Datei. Die inifile.params beinhaltet den Content und mit welchen Medien und Passwörtern installiert werden soll.

Die Passwörter sind mit dem Schlüssel aus der instkey.pkey verschlüsselt. Um beide Dateien zu erhalten, muss initial die Installation manuell durchgeführt und in der Installationsübersicht der SWPM angehalten werden. Anschließend speichern Sie beide Dateien und heben diese gut auf. Für Folgesysteme können Sie die inifile.params einfach verändern und so Installationen und vor allem Systemkopien deutlich schneller durchführen.

Als zweiten wichtigen Punkt benötigen Sie die Product ID des zu installierenden Systems. Diese finden Sie wiederum in der inifile.params und sie ist, wie der Name schon sagt, produktspezifisch.

Nun wissen wir, dass es möglich ist, mit dem SWPM Systeme automatisch zu installieren. Aber was bringt uns das im täglichen Betrieb? Kommen wir doch einmal zurück zu unserem initialen Fallbeispiel, der Entscheidung, was mit dem neuen BW und dem alten ERP nun geschehen soll.

Wir nehmen einfach an, dass die ERP-Systeme während der Hana-Migration gleich noch zu einem der drei großen Cloud-Provider migriert werden sollen. Wenn wir uns den Aufbau eines SAP-Systems in Erinnerung rufen, können wir das Wissen nutzen, um die Migration nach Hana deutlich zu beschleunigen.

Deployments automatisieren

Ein SAP-System besteht grundlegend aus ein paar ausführbaren Dateien, den benötigten Profilen und einer Datenbank mit den Versionsinformationen. Für eine erfolgreiche Migration muss nur der Kernel zu den in der Datenbank gespeicherten Informationen passen und unser System läuft auf der neuen Hardware bzw. Datenbank. Ziel muss es sein, die Cloud-Systeme möglichst schnell per automatischen Deployment zu installieren. Anschließend kann er durch einen Datenbankrefresh per Export/Import in das entsprechende Quellsystem gewandelt werden.

Die Bereitstellung der Systeme können wir natürlich noch weiter automatisieren. So sind die Ansible Playbooks eine lohnenswerte Beschäftigung für die aktuelle Krise. Selbst für einen erfahrenen SAP-Berater wird dieses Thema erst einmal völliges Neuland sein, aber die Community und Red Hat haben die wichtigsten Funktionen vollumfänglich dokumentiert.

Die grundlegenden Funktionen zur Bereitstellung eines Systems werden in einem Playbook definiert. Umgangssprachlich ist es eine Sammlung von Aufgaben, die auf dem entsprechenden Host ausgeführt werden sollen. Von der Anlage von Volume- Gruppen über die Erstellung von Nutzern und Gruppen bis hin zum Start von Skripten ist quasi alles möglich. Ohne weiteres Zutun können wir so Systeme oder Applikationsserver installieren, Systemkopien durchführen oder auch Dinge deinstallieren.

Wie Sie sehen, habe ich Ihnen hier keine vollständige Anleitung zum automatischen Deployment von SAP-Systemen gegeben. Das ist auch nicht möglich, da jede Systemlandschaft und jede Anforderung anders ist. Der Weg und die Entscheidung, in die Cloud zu transformieren, sind so individuell, wie es Möglichkeiten gibt. Alle beschriebenen Möglichkeiten sind auch in Ihrem eigenen Rechenzentrum und mit VMWare möglich und bedürfen keiner großen Cloud-Infrastruktur. Letztendlich wird es wie so oft die hybride Systemlandschaft sein, die wir vorfinden.