Information und Bildungsarbeit von und für die SAP-Community

Hana 3, was sonst?

Wunder werden sofort erledigt, Unmögliches dauert etwas länger. Eine detailliertere Sicht der Dinge auf die SAP-Hana-Cloud-Story.
Werner Dähn, rtdi.io
15. Mai 2020
[shutterstock.com: 80454427, Vira Mylyan-Monastyrska]
avatar

Dass Hana nicht für die Cloud gebaut wurde, ist bekannt. Doch was ist das Problem dabei? Da trifft der E-3 Artikel „Wir sind ERP“ von Autor „no/name“ aus E-3 Februar 2020 den Nagel auf den Kopf: die Betriebskosten von Hana as a Service für SAP selbst.

Eine Datenbank, die sich automatisch an die Last anpasst, wäre die optimale Lösung. Damit könnte man die Betriebskosten zu 100 Prozent im optimalen Bereich halten und keine Ressourcen verschwenden.

Der Wunsch nach unendlicher Skalierbarkeit ist naheliegend und nachvollziehbar. Ist er machbar, das ist die andere Seite der Medaille. Eine Anekdote von SAP: „Wir brauchen disruptive Lösungen, also entwickelt diese.

Los, los!“ Man soll also etwas noch nie Dagewesenes auf Zuruf erfinden, schnell umsetzen und physikalische Gesetze so nebenbei verschieben. Das ist schwierig, oder?

Bei Hana 3 berührt man genau so eine physikalische Grenze. Für die geforderte unendliche Skalierung müssen die Aufgaben (a) in unendlich kleine Teile zerlegbar sein, (b) parallel ausgeführt werden und – damit es weiterhin eine Datenbank ist – (c) trotzdem eine globale Reihenfolge/Transaktionalität beibehalten. Das geht nicht. Der innere Widerspruch der Anforderungen muss über einen Kompromiss an mindestens einer Stelle aufgelöst werden.

Aufwand und Ziel

Wenn die unendliche Skalierung aber nur eine Methode ist, wie man die Kosten reduzieren kann, gibt es vielleicht eine billigere Art und Weise? Das wurde schon einmal versucht, die Hana-Admins kennen das als Multi-Database-Container (MDC).

Dabei wurde der Indexserver als das Problem ausgemacht, der Prozess, der sich um alle Datenverarbeitungen und die Datenspeicherung in Hana kümmert.

Im Cloud-Rechenzentrum benötigt jede Hana einen dieser großen Indexserver-Prozesse. Wie wäre es also, nur eine Hana-In­stanz pro Server zu installieren und dafür unabhängige Datenbank-Container zu haben?

Die Entwicklung hat also alles aus dem Indexserver entfernt, das nicht zu einer Datenbank gehört, und in den Name-Server verlagert: Die Datenhaltung? Nein, geht nicht, das ist der Kern der Datenbank.

Die Abfragen? Das Session Management? Im Endeffekt war nichts entfernbar. Ergebnis: Auf jedem Rechner laufen die SystemDB plus ein Indexserver pro Datenbank-Con­tainer. Einsparung? Praktisch null.

Der Indexserver

Wie könnte man stattdessen den Indexserver kleiner bekommen? Im Moment ist er bei einer leeren Datenbank 4 GB groß.

Er hat eine SQL-Engine, eine Calc-Engine, Spatial Queries, Time Series und Graph Queries, Document Store. Die billige Methode wäre, Teile der Funktionalitäten zu entfernen.

Einer der Vorteile von Hana ist aber gerade die Universalität. Das steht zu Recht auf jeder Marketingfolie. Man müsste den Indexserver also irgendwie anders zerschneiden, naheliegend in eine kleine Kernfunktionalität und eine dynamische, lastabhängige Komponente.

Eine der Kernaussagen von Hasso Plattner vor zehn Jahren war, dass ein Datensatz einmal angelegt wird und Hunderte Male abgefragt wird. Daraus folgerte Plattner, dass eine Datenbank eher auf Abfragegeschwindigkeit optimiert werden sollte und Insert-Performance zweit­rangig ist.

Die komplette Hana-Datenbank sowie S/4 Hana sind rund um diese Prämisse aufgebaut und deswegen so erfolgreich.

Für unseren Indexserver bedeutet es, man schmeißt allen Code heraus, der sich um die Abfrage von Daten kümmert. Wirklich alles! Die Verantwortlichkeit des Indexservers reduziert sich damit auf die Datenverwaltung und die Durchführung der Datenänderungen.

Der Prozess besitzt also das RAM mit den Daten, er behandelt die Insert-, Update- und Delete-State­ments. Der Indexserver wäre nur noch die In-memory-Storage-Ebene.

Queries sind der komplexe Teil mit dem Query Optimizer, den verschiedenen En­gines und der hohen Gefahr, einen Bug zu haben. Diesen Funktionen genügt Read- only-Zugriff auf das RAM des Indexservers (Shared Memory) und sie können vollkommen unabhängig voneinander arbeiten.

Ein weiterer Vorteil dieses Ansatzes: Was passiert heute, wenn ein Anwender ein Query absetzt und wegen eines Bugs läuft der Code Amok? Der Indexserver stürzt ab und damit die komplette Datenbank.

Wenn das Query ein eigener Prozess ist, vielleicht sogar jedes aktuell laufende Query in einem eigenen Prozess laufen würde, bricht nur die eine User Session zusammen.

Diesen Query-Prozess gut zu gestalten ist allerdings nicht einfach.

Container

Wie würde das praktisch aussehen? Jeder Kunde besitzt ein Docker Image mit Hana. Dieses Image wird auf einem Server mit den gekauften Leistungsdaten gestartet. Da der Indexserver jetzt so klein ist, kann er sehr schnell gestartet werden, so schnell, dass die meisten Entwicklerinstanzen sogar in einen Ruhezustand gehen können und das Docker Image bei Inaktivität gestoppt wird.

Benötigt ein Kunde mehr Ressourcen, wird seine Hana-Instanz gestoppt und auf der anderen Hardware wieder hochgefahren. Oder man geht in Richtung Scale-out, startet mehrere Docker-Instanzen auf den gleichen Datenbank-Files und diese verteilen die Daten untereinander.

Wo ein Container läuft, im Cloud-Rechenzentrum oder beim Kunden, macht keinen Unterschied.

Was ich bis jetzt beschrieben habe, ist Allgemeinwissen aus dem Datenbankbau. Es wird spannend zu sehen, welchen technischen Unterbau Hana Cloud bekommt.


Fazit: Alt gegen neu

Wenn die Hana Cloud eine normale Hana-Version wäre, hätte SAP schon einiges gewonnen. Auf der obersten Ebene liegen die In-memory-Daten und dank der Hana Native Storage Extensions (NSE) können viele Daten auf Disk bleiben. Das Ganze sollte man noch in Container für ein leichteres Handling der vielen In­stanzen verpacken. Das scheint aber nur bedingt der Plan zu sein. Die angesprochene Trennung der Hana-Cloud-Entwicklung in eine eigene, zweite Codelinie hat Konsequenzen.
Zwei Codelinien bedeuten auf jeden Fall doppelte Entwicklungskosten – oder eine von beiden wird vernachlässigt. Außerdem müssen alle bestehenden Hana-Features neu implementiert werden, und da das in der kurzen Zeit nicht möglich ist, werden welche fehlen. Die Features für einen effektiven Cloud-Betrieb findet man wiederum nur in der Hana-­Cloud-Codelinie.
Zufriedene Kunden dürften so nicht zu erwarten sein. Als On-prem-Hana-Kunde sieht man die Weiterentwicklungen rund um den Datenbankbetrieb, kann sie aber nicht bei sich nutzen. Die Cloud-Anwender werden Features vermissen, die es schon lange auf der On-prem-Hana gibt, aber in der Cloud-Codeline noch nicht implementiert werden konnten.
Solange diese Situation nur kurze Zeit andauert, kann man damit umgehen. Ich habe aber noch keine Aussagen gehört, die auf eine Konvergenz dieser beiden Entwicklungen hindeuten, im Gegenteil.

avatar
Werner Dähn, rtdi.io

Werner Dähn ist Data Integration Specialist und Geschäftsführer von rtdi.io.


Schreibe einen Kommentar

Die Arbeit an der SAP-Basis ist entscheidend für die erfolgreiche S/4-Conversion. 

Damit bekommt das sogenannte Competence Center bei den SAP-Bestandskunden strategische Bedeutung. Unhabhängig vom Betriebsmodell eines S/4 Hana sind Themen wie Automatisierung, Monitoring, Security, Application Lifecycle Management und Datenmanagement die Basis für den operativen S/4-Betrieb.

Zum zweiten Mal bereits veranstaltet das E3-Magazin in Salzburg einen Summit für die SAP-Community, um sich über alle Aspekte der S/4-Hana-Basisarbeit umfassend zu informieren.

Veranstaltungsort

Mehr Informationen folgen in Kürze.

Veranstaltungsdatum

Mittwoch, 21. Mai, und
Donnerstag, 22. Mai 2025

Early-Bird-Ticket

Verfügbar bis Freitag, 24. Januar 2025
EUR 390 exkl. USt.

Reguläres Ticket

EUR 590 exkl. USt.

Veranstaltungsort

Hotel Hilton Heidelberg
Kurfürstenanlage 1
D-69115 Heidelberg

Veranstaltungsdatum

Mittwoch, 5. März, und
Donnerstag, 6. März 2025

Tickets

Reguläres Ticket
EUR 590 exkl. USt
Early-Bird-Ticket

Verfügbar bis 20. Dezember 2024

EUR 390 exkl. USt
Veranstalter ist das E3-Magazin des Verlags B4Bmedia.net AG. Die Vorträge werden von einer Ausstellung ausgewählter SAP-Partner begleitet. Der Ticketpreis beinhaltet den Besuch aller Vorträge des Steampunk und BTP Summit 2025, den Besuch des Ausstellungsbereichs, die Teilnahme an der Abendveranstaltung sowie die Verpflegung während des offiziellen Programms. Das Vortragsprogramm und die Liste der Aussteller und Sponsoren (SAP-Partner) wird zeitnah auf dieser Website veröffentlicht.