Geschwindigkeitsvorteile kombiniert mit höchster AusfallsicherheitSizing-Vorteile beim Einsatz von SAP HANA auf Power9-Systemen

Generell stellt SAP HANA für Unternehmen als eine Kernplattform erhebliche Geschäfts- und IT-Vorteile zur Verfügung. Dazu ist aufgrund der Architektur der Datenbank, also das In-Memory-Computing, das Arbeiten mit Echtzeitdaten machbar, so dass auch Realtime-Analysen mit dieser Datenbank möglich sind. Um die Leistungsfähigkeit von SAP HANA voll auszuschöpfen und die Gesamtbetriebskosten zu senken, ist es wichtig, dass die Plattform für Ihre Geschäftsanforderungen richtig dimensioniert ist. Dazu stellt SAP Werkzeuge bereit, um SAP HANA richtig zu dimensionieren und eine aussagekräftige Grundlage für den Erfolg bei der digitalen Transformation eines Unternehmens zu schaffen. Große Vorteile verspricht dabei der Einsatz der Power-basierten Serversysteme aus dem Haus IBM.

Unter dem Begriff Sizing rangiert allgemein eine Vielzahl von Aspekten, die es zu beachten gilt: Dazu gehört das Bestimmen von Hardwareanforderungen, wie Speicher, CPU-Rechenleistung, Festplattenspeicher, Ein- und Ausgangskapazität und Netzwerkbandbreite. Beim Sizing handelt es sich allerdings um einen iterativen Prozess, der in letzter Konsequenz Geschäftsanforderungen in Hardwarebedarf zu übersetzen hat, und der in der Regel bereits sehr früh in einem Projekt einsetzen sollte.

SAP reklamiert für sich mehr als 40 Jahre Geschäfts- und Technologieerfahrung, die in die Entwicklung von SAP HANA eingeflossen sein sollen. Dies dient laut SAP als Argument dafür, dass SAP HANA quasi jedem Unternehmen helfen kann, die Leistungsfähigkeit all seiner Daten zu nutzen und die Echtzeit-Intelligenz der eigenen Geschäftsprozesse auch nutzbar zu machen. SAP HANA umfasst die nötigen Funktionen, um alle Daten zu verarbeiten – von Transaktionen bis hin zu erweiterten Analysen – unabhängig davon, ob sie lokal gespeichert oder virtuell verbunden sind. Und da es so konzipiert wurde, dass es Daten zuerst im Arbeitsspeicher – sprich In-Memory – benutzt und verwaltet, erreichen Anwenderunternehmen damit eine Echtzeit-Performance für Analysen und Transaktionen, ohne dass sie ein aufwändiges Tuning in der Datenbank durchführen müssten.

Das In-Memory-Konzept stellt die Weichen zu mehr Einfachheit der IT-Infrastruktur: Die Analytik- und Transaktionsaufgaben lassen sich auf nur einer Plattform abwickeln. Das führt nicht nur zu einem schnelleren Zugriff auf die Daten und den daraus abzuleitenden Erkenntnissen, sondern auch zum Entfall von komplexen Data Warehouse-Strukturen, die über aufwändige ETL-Prozesse „gefüttert“ werden müssen. Denn der große Vorteil von SAP HANA liegt darin, dass die Ausführung von Analysen bei Live-Transaktionen machbar ist. Dazu gehört nicht nur die operative Analyse strukturierter Daten (z.B. von Geschäftsvorgängen), sondern auch die erweiterte Analyseverarbeitung (z.B. Vorhersage, maschinelles Lernen oder Verarbeitung natürlicher Sprache) von strukturierten und unstrukturierten Daten (z.B. Grafik- und Geodaten, Dateien und Live-Datenströme). Aus diesem Grund ermöglicht es SAP HANA den Anwenderunternehmen, Live-Intelligenz aus allen ihren Daten zu ziehen und damit Ergebnisse abzuleiten.

Dimensionierung und die Kostenfrage

Die passende Dimensionierung und somit die Kosten erweisen sich für alle IT-Installationen als ein wesentlicher Faktor. Wäre Geld kein Thema, würden die IT-Verantwortlichen liebend gerne übergroße Kapazitäten betreiben, um bei jeder Art von Arbeitsbelastung die bestmögliche Leistung zu erbringen. Doch das lässt sich in der Realität niemals umsetzen.
Damit kommt das „Sizing“ auf die Agenda – es gilt als Synonym für die Bestimmung der richtigen Hardwarekonfiguration nicht nur für die aktuelle, sondern auch für die zukünftige Geschäftsanforderungen. Somit handelt es sich um einen iterativen Prozess, der ein Zusammenspiel zwischen dem Anwenderunternehmen, SAP und den Hardwareanbietern umfasst. Es geht darum, auf hardware- und herstellerneutrale Weise die Anzahl und Art der Komponenten festzulegen, die benötigt werden, um den angestrebten Durchsatz und die Reaktionszeit einer bestimmten Arbeitslast zu erreichen, sowie den Aufwand, den jeder Gerätetyp – einschließlich Speicher, Prozessoren, Festplatten usw. – zu erbringen hat, um diese Arbeitslast auf einem bestimmten Leistungsniveau auszuführen.

Der Aufwand kann in Bezug auf Rechenleistung, Kapazität oder andere Parameter, die häufig bei Hardware auftreten, betrachtet werden. Entscheidend ist jedoch die Fähigkeit jeder Komponente, die benötigten Ressourcen für die nächste Stufe der Berechnungskette im Moment ihres Bedarfs zur Verfügung zu stellen. Das Ziel eines jeden richtig ausgelegten Systems ist es, Wartezeiten oder Leerlaufzeiten zu vermeiden. Dies wird auch als Antwortzeitoptimierung bezeichnet. Der Sizing-Ansatz bei SAP geht von einem aus der Praxis abgeleiteten Mix aus besten, normalen und Worst-Case-Szenarien für eine bestimmte Arbeitsbelastung aus. Aus diesem Prozess heraus werden bestimmte Durchsatzmetriken definiert, wie z.B. die CPU-Leistung in den Werten des SAP Application Performance Standard (SAPS), die Speichergröße sowie die Ein- und Ausgabeoperationen pro Sekunde.

Iterativer Prozess erforderlich

Doch die Dimensionierungsergebnisse werden sich wahrscheinlich mit jeder Änderung der Arbeitslast ändern, weshalb die Dimensionierung immer ein iterativer Prozess sein wird. Die Konfiguration ist der zweite Schritt bei der Definition der Systemarchitektur und besteht aus der Übersetzung der Dimensionierungsergebnisse, um das beste herstellerspezifische Equipment zu ermitteln. Dabei wird die Entscheidung für einen Hardware-Anbieter getroffen und dessen Anpassung an bestehende Unternehmensarchitekturen bewertet. Es werden Maschinenmodelle und Spezifikationen für alle notwendigen Hardwareelemente eines ausgewählten Herstellers definiert, einschließlich der Integration mit externen Komponenten anderer Hersteller, um die beste Anpassung für das Gesamtsystem zu ermitteln.

Dabei sind auch die laufenden Kosten zu bewerten und Änderungen der Geschäftsanforderungen zu antizipieren. Für viele Anwenderunternehmen kann zwar bestehende Hardware (wie Enterprise Storage- oder Netzwerksysteme) genutzt werden, sofern sie die Konfigurationsanforderungen erfüllt. Wer für die Ausgangskonfiguration etwas „überdimensionierte Ressourcen“ vorsieht, hat zwar kurzfristig negative Auswirkungen auf die Gesamtbetriebskosten zu verzeichnen, kann aber langfristig die richtige Entscheidung getroffen haben, da genügend Kapazität für das zukünftige Arbeitsaufkommen vorhanden ist.

Bei SAP HANA hängt die erforderliche Leistungsfähigkeit jeder Ressource von der Art der auszuführenden Arbeiten ab: Um SAP HANA angemessen zu dimensionieren, konzentriert man sich bei SAP auf zwei Hauptelemente: die CPU (Prozessor-Rechenleistung) sowie den Arbeitsspeicher. Diese beiden müssen zusammenspielen, um die Workload-Anforderungen zu erfüllen. Hier kommen aber auch die Unterschiede der beiden Prozessorarchitekturen zum Tragen, für die SAP HANA zertifiziert ist: die Intel-x86-Schiene und IBMs Power-Architektur.

Auf IBMs Power-Systemen wurde eine sehr flexible und skalierbare Umgebung entwickelt, um Unternehmenskunden mit ihren geschäftskritischen In-Memory-Analysen zu helfen, Echtzeiteinblicke in ihr Business zu erzielen und Kosten zu senken. Diese Kombination, die die typischen Power- Vorteile mit Linux als Betriebssystem nutzt, biete laut IBM höchste Flexibilität, Ausfallsicherheit und Leistung. Damit erweisen sich die Power-basierten Systeme als sinnvolle Alternative zu x86-Systemen.

Tausende von globalen Organisationen, die bereits Power-basierte Systeme für klassische SAP- und auch für Nicht-SAP-Anwendungen einsetzen, können ihre bestehenden Prozesse und Prozeduren in Bereichen wie Hochverfügbarkeit, Disaster Recovery und Backup-Szenarien weiterhin nutzen. Dies bedeutet, dass in den meisten Fällen so gut wie keine Notwendigkeit besteht, neue Verfahren zu etablieren oder Mitarbeiter in komplett neue Themengebiete einzuführen. Damit können Anwenderunternehmen die Vorteile von Hana-auf-Power-Systemen (HoP) mit geringem Arbeits- und Zeitaufwand implementieren. Die generelle Akzeptanz der Power-Technologie beruht im Großen und Ganzen auf drei Säulen: höhere Flexibilität gekoppelt mit niedrigerem TCO, besserer Performance und einer Belastbarkeit, wie sie in einem professionellen Umfeld mit 24/7-Betriebsmodell nötig ist.

Die Virtualisierung auf der Power-Architektur erlaubt bis zu acht Produktions-VMs auf einem einzigen Power-Server (in „Shared Pools“ noch mehr) und somit eine sehr effiziente Workload-Konsolidierung, die den Bedarf an Servern und den damit zusammenhängenden Kosten drastisch reduziert – das führt zu einer niedrigeren TCO. Außerdem können HANA-Instanzen mit herkömmlichen Arbeitslasten auf ein und demselben Server gemischt werden.

Hinsichtlich des Arbeitsspeicher-Subsystems können Power-basierte Systeme (vor allem wenn sie auf der Power9-Linie basieren) mit großzügigen Kapazitäten und CPU-Speicherbandbreiten auftrumpfen, die keinen Flaschenhals beim Zugriff auf den Arbeitsspeicher aufkommen lassen. Man kann z. B. eine Virtuelle Maschine (VM) einrichten, um herkömmliches ECC oder CRM laufen zu lassen, und eine andere VM, um BW abzudecken, und eine weitere, um Test und Entwicklung im S/4-HANA-Bereich abzudecken, und noch einige, um virtualisierte VM-Services zu betreiben. So etwas wäre auf einer Appliance-Architektur unmöglich, denn es würde gegen alle SAP-Regeln verstoßen.

Die Core-Performance macht den Unterschied

Die Per-Core-Performance des Power-Prozessors aus der Power9-Generation liegt erheblich höher als alles, was Intel derzeit zu bieten hat. Das hängt mit dem unterschiedlichen, zweckgebundenen Design des Prozessors zusammen. Power ist für datenintensive Workloads optimiert und kann dank des Multithreadings bis zu acht simultane Rechenprozesse parallel abwickeln – viermal so viel wie der Mitbewerb. Das bedeutet weniger Cores, geringere Lizenzkosten und einen erheblich reduzierten Platzbedarf im Datacenter; desgleichen geringerer Stromverbrauch, Managementkosten etc.

Ganz wichtig in einer Realtime-Computing-Umgebung sind die Latenzzeiten, die dank physischer Ausuferung der Instanzen im Intel-Bereich immer größer werden. Sie lassen sich imPower-Umfeld mit der neuen Generation drastisch reduzieren. Zusätzlich erhöht sich die Geschwindigkeit dank großer Memory Caches.

Bereits 2016 erreichte die Ausfallsicherheit der Power-basierten Server einen Höhepunkt, als IDC sie in die höchste Kategorie der Fehlertoleranz aufnahm (Availability Level 4). Das entspricht 99,9999 Prozent Uptime. Das belegt auf die folgende Aussage. Es trat z. B. in den über 2000 HANA-Installationen auf Power nicht ein einziges infrastrukturgeneriertes Problem mit Ausfallzeit auf. Zudem lassen die Power-Server im Hintergrund heuristische Verfahren laufen, die vorausschauend Fehlerwarnungen an den Administrator liefern.

Obendrein kann im Scale- up-Modus (von SAP selbst im HANA-Umfeld empfohlen) ein Failover von einer VM auf die andere durchgeführt werden, selbst wenn die eine VM Test- oder Entwicklungsszenarien betreibt. Redundante Bauteile und die Hot-Plug-Architektur ermöglichen in vielen Bereichen eine Wartung im laufenden Betrieb. Auch das führt letztendlich zu weniger Servern und somit zu einem geringen TCO. Auch so etwas ist im Appliance-Bereich nicht verfügbar.

Die Support Services zu den Power-basierten Systemen vervollständigen die Lösung. SAP HANA gilt als ein komplexes Gebilde, das an vielen Stellen Support benötigt: bei der Konfiguration, der Implementierung, der Installation der Infrastruktur und der Applikationen. Bei IBM gibt es hierfür eine Lösung (end-to-end), die von der Planung, Installation zur Migration über den Betrieb und hin zum kontinuierlichen Benutzer-Support reicht. Dazu werden IBM-Experten aus dem Bereich Global Business Services eingesetzt.

Rainer Huttenloher

Hier geht es zu IBMs HANA-Site