SAP HANA Sizing | Memory Size | Quicksizer

(Last Updated On: 16. November 2018)

Wie sized man eigentlich eine SAP Anwendung basierend auf SAP HANA? Wenn Sie sich meinen damaligen Beitrag über das Sizing generell angesehen haben, beschäftigen Sie sich vielleicht mit dieser Folgefrage. In diesem Beitrag durchleuchten wir daher das Sizing verschiedener Hardware-Parameter speziell für SAP HANA.

SAP HANA Memory (RAM) und CPU Socket Sizing

Wie viel Arbeitsspeicher braucht die SAP HANA Datenbank? Zunächst einmal reden wir über das absolute Minimum, welches notwendig ist, um ein SAP System basierend auf SAP Netweaver ausführen zu können. Dieses absolute Minimum liegt bei 64 GB RAM, welche exklusiv der Datenbank SAP HANA zur Verfügung stehen müssen (und nicht noch von einer anderen Ressource wie dem Anwendungsserver oder dem Betriebssystem belegt werden dürfen). Zwar ist es unterhalb dieser Grenze möglich, ein SAP NetWeaver System zu starten, jedoch wird das System nach einer gewissen Zeit abstürzen. Grund hierfür ist der Versuch der HANA Datenbank, die Column Store Tabellen asynchron in den Hauptspeicher zu laden. Dieser Vorgang schlägt bei weniger als 64 GB RAM fehl. Das Problem zeigt sich häufig dadurch, dass der Dispatcher-Prozess des SAP Systems nach einiger Zeit vom Status GREEN auf YELLOW springt.

Zusätzlich dazu gilt für SAP HANA on IBM Power, dass ein SAP HANA Host auf einer LPAR mindestens 4 CPU-Kerne und 128 GB RAM zur Verfügung haben muss. Dies geht aus SAP Hinweis 2188482 hervor. Das heißt hier ist das absolute Minimum noch um einiges höher angesetzt. Bei Hitachi LPARs greift SAP Note 2063057 und fordert eine minimale Anzahl von CPU-Kernen pro CPU-Socket, die einer LPAR zugewiesen werden müssen. Bei SAP HANA on VMWare vSphere gilt derzeit SAP Note 2393917. Diese fordert wiederum mindestens 8 CPU-Kerne, zugehörig zu ein un dem selben Socket, und 128 GB RAM.

Minimale Arbeitsspeicher Anforderung für Suite oder BW on HANA

Aber wie viel GB RAM braucht mein SAP System nun wirklich? Wenn Sie bereits eine Quell-Datenbank haben, können Sie dies grundsätzlich anhand von Berechnungen und anhand von Reports erahnen. Bei einem Greenfield-Projekt bleibt Ihnen als einziger Ansatzpunkt der SAP Quick Sizer.

Im Brownfield-Umfeld gibt es zunächst einmal gibt es für verschiedene Quell-Systeme unterschiedliche Sizing Reports.

  • SAP Note 1793345: Sizing for SAP Suite on HANA
  • SAP Note 1872170: Suite on HANA memory sizing
    report
  • SAP Note 1736976: Sizing Report for BW -on- HANA
  • SAP Note 1637145 – SAP BW on HANA: Sizing SAP In-Memory Database

Diese Reports haben in der Regel eine Laufzeit zwischen 8 und 12 Stunden und sollten zuerst auf einem Testsystem ausgeführt werden, um deren Lauffähigkeit sicherzustellen. Als Ergebnis wird häufig der Memory Bedarf des Systems dargestellt. Dabei gibt es einmal ein absolutes Minimum und einmal eine Empfehlung.

Wichtig: Damit die Reports eine akkurate Aussage treffen, müssen die Datenbankstatistiken der Quelldatenbank aktuell sein. Um die Größe der Datenbank realistisch einzuschätzen, lohnt es sich auch einen Datenbank-Reorg durchzuführen. Dieser reduziert die Anzahl der Blöcke, welche für die Speicherung der Datenbankobjekte notwendig sind. Die Reports gehen außerdem von einem Unicode-System aus. Wenn Sie die Sizing-Reports auf einem Non-Unicode System ausführen, müssen Sie einen Aufschlag drauf rechnen.

Ist der aktuelle Hauptspeicherbedarf der Quelldatenbank bereits größer als 6TB, könnte der Report die Anforderungen überberechnen. Wenn es nach dem Hersteller SAP gehört, sollte man in diesem Fall einen Incident für die Komponente SV-BO erstellen, um eine letzte Empfehlung des Herstellers einzuholen.

Berechnung des statischen und dynamischen Hauptspeicherbedarfs

Zusätzlich zu diesen Reports gibt es für die unterschiedlichen HANA-fremden Quelldatenbanken (Oracle, DB2, DB6, MS SQL, MaxDB usw.) über SAP Hinweis 1514966 eine Sammlung von Skripten, die bei der Berechnung des voraussichtlichen Speicherbedarfs helfen. Dabei spielt es keine Rolle, ob die Quell-Datenbank komprimiert ist oder nicht.

Ist Ihre Quelldatenbank ebenfalls eine HANA-Datenbank, können Sie die voraussichtliche Größe der Datenbank im Arbeitsspeicher durch folgendes SQL-Statement herausfinden.

SELECT SUM
(disk_size)/1024/1024/1024
FROM
m_table_persistence_statistics
Sie haben nun den statischen Speicherbedarf der Datenbank ermittelt. Das heißt, wie viel Arbeitsspeicher braucht die Datenbank, um vollwertig im Arbeitsspeicher der SAP HANA Datenbank geladen werden zu können. Diesen statischen Wert sollten Sie mal zwei nehmen, um den sogenannten dynamischen Arbeitsspeicherbedarf zu ermitteln. Dynamisch bedeutet, dass die Datenbank dazu in der Lage ist, mit den Daten on the fly im Arbeitsspeicher Operationen durchzuführen.

Primärspeicher (RAM) Sizing über den SAP HANA Quick Sizer

Auch wenn Sie einen Brownfield-Approach fahren, sollten Sie dennoch ein Sizing über den SAP Quick Sizer zusätzlich vornehmen. So finden Sie nämlich heraus, was Ihnen der Quick Sizer bei einem Greenfield-System vorschlagen würde. Außerdem berücksichtigt der Quick Sizer das Throughput-Sizing anhand des Daten- und Benutzeraufkommens, mit dem sie ihn füttern.
Im Zweifel, wenn Sie die Auslastung Ihres Systems nicht kennen, können Sie sich an ein paar Standardempfehlungen halten. Ermitteln Sie die Anzahl der aktiven Dialogbenutzer in Ihrem System. gehen Sie von folgender Aufteilung aus
  • 70% gelegentliche Nutzer. Sie führen in der Regel nur eine Anfrage bzw. eine Transaktion pro Stunde aus, die meist eine mittlere Komplexität an Verarbeitungslogik aufweisen.
  • 25% normale Nutzer. Sie führen in der Regel elf Anfragen pro Stunde aus, die gleichmäßig einer sehr simple und ene mittlere Komplexität aufweisen
  • 5% sind Experten oder auch Power User. Sie führen in der Regel 33 Anfragen pro Stunde aus, die eine hohe Verarbeitungskomplexität aufweisen (Hintergrund-Jobs und Dialog-Programme für Experten).
  • rechnen Sie einen Puffer für langfristiges Wachstum ein, etwa ein Benutzerwachstum von 10% über zwei Jahre.
  • eine Transkation im SAP-System erstellt oder bearbeitet im Schnitt 5 Datenbankobjekte.
Mit dieser Daumenregel haben Sie eine grobe Richtlinie zum Sizing über den Quick Sizer. Meine empfehlung an Sie ist, dass Sie sowohl die Sizing Reports in den SAP-Hinweisen, die SQL-Skripte und den SAP Quick Sizer in einem Brownfield-Projekt kombinieren und dabei eine ansprechende Empfehlung für Ihr System ableiten. Nehmen Sie beispielsweise die höchste Empfehlung aus den SQL-Skripten und den Sizing-Reports für den Jetzt-Zustand. Führen Sie im Anschluss ein Sizing mit geringem Throughput und anschließend ein Sizing mit hohem User- und Datenbank-Throughput im Quick Sizer durch.
Wenn Sie den ersten und den zweiten Lauf des SAP Quick Sizers miteinander vergleichen, wissen Sie, welchen Anteil an der Hauptspeicherempfehlung des Quick Sizers die Anwender und Datenbankobjekte haben. Wenn Sie beispielsweise hier die Anzahl an Datenbankobjekte und User-Transaktionen pro Stunde eingeben, die Sie in Zukunft erwarten, haben Sie ein zukunftsorientiertes Throughput-Sizing durchgeführt. Wenn Sie nun dieses zukunftsorientierte Throughput-Sizing mit der Sizing-Empfehlung des Jetzt-Zustandes kombinieren, haben Sie einen zukunftssicheren Wert ermittelt.

Memory Sizing für SAP HANA Native

Was ist denn nun, wenn ich kein SAP-System auf der Ziel-HANA-Datenbank betreiben möchte, sondern einfach nur eine HANA Native für ein ein Non-SAP-System bereitstellen möchte? Auch hier berechnen Sie über die SQL-Skripte im Hinweis  SAP Hinweis 1514966  die zu erwartende Größe unter HANA der jetzigen Quell-Datenbank. Multiplizieren Sie das Ergebnis wie oben bereits geschildert mal zwei.

Maximum Memory für einen SAP HANA Single Host (Scale-Up)

Bisher haben wir immer nur über das Minimum an Arbeitsspeicher geredet, welches ein SAP HANA System im Verbund braucht, um die Anforderungen des Kunden zu erfüllen. In diesem Zuge unterhalten wir uns nun um den maximalen Arbeitsspeicher, den ein einzelner HANA Host haben darf. Dies ist abhängig von der jeweiligen Hardware- und/oder Virtualisierungsplattform.

Für IBM Power ist hierbei beispielsweise SAP Hinweis 2188482 ausschlaggebend. So liegt das Maximum bei POWER8 beispielsweise bei derzeit 176 Kernen und 24 TB RAM (Ausnahme im OLAP-Szenario) und bei POWER9 bei 96 Kernen und 12 TB RAM.  Für SAP HANA on VMware vSphere wird über SAP Note 2399317 eine maximale Größe von 128 vCPUs auf maximal 4 Sockets und maximal 3TB RAM (OLAP-Szenarios wie unter BW) 4TB RAM (OLTP auf Broadwell) bzw. maxiaml 6TB RAM (OLTP auf Skylake) gelistet. Wenn Sie einen höheren Bedarf haben, müssen Sie ein Scale-Out Szenario fahren und somit den Hauptspeicherbedarf des SAP HANA Systems auf mehrere Arbeitsknoten aufteilen.

Minimale Hardwareausstattung eines einzelnen Scale-Out Knotens

Freuen Sie sich, denn es wird noch komplizierter. Wenn Sie aus dem oberen Kapitel gelernt haben, dass Sie ihre technischen Anforderungen nicht mit einem einzigen Single-Host Szenario (Scale-Up) erfüllen können, müssen Sie jetzt bestimmen, was die minimalen technischen Anforderungen an Ihren SAP HANA Scale-Out Verbund sind. Der Hersteller empfiehlt nämlich, dass Sie lieber eine kleine Anzahl an großen Knoten haben, als eine hohe Anzahl an kleinen Knoten. Grund hierfür ist, dass Scale-Out in SAP HANA nach dem Prinzip der Tabellenpartitionierung funktioniert. Obwohl also die einzelnen Tabellen auf mehrere Hosts aufgeteilt werden, kann es trotzdem sein, dass ein Host, auf dem eine bestimmte Tabellengruppe residiert, wesentlich mehr Last abbekommt als die anderen Knoten im Scale-Out Verbund. Diese Anforderung nach großen Knoten bürdet Ihnen der Hersteller in Form von Mindestanforderungen für einen Scale-Out Knoten auf.

Hierzu liefert der Hersteller SAP Hinweis 2428711 – S/4HANA Scale-Out Sizing aus. Das dort angehängte PDF listet die folgenden minimalen Hardware-Konfigurationen auf.

Insgesamtes Memory SizingMinimaler Memory pro KnotenAnzahl der Knoten
6T bis 12 TB6TB bis 8 TB2
12TB bis 18TB8TB bis 12TB2
18TB bis 24TB12TB bis 16TB2 oder 3
Über 24TB12TB und mehr3 bis 4

Zusätzlich zu diesen Einschränkungen gelten die hardware-spezifischen Minima aus den SAP Hinweisen 2408419, 2111714. Demnach muss

  • ein Intel-basierender Knoten mindestens 8 CPU Sockets und 6TB Hauptspeicher zugewiesen bekommen
  • eine IBM POWER LPAR mndestens 64 Kerne pro LPAR und 6TB Hauptspeicher zugewiesen bekommen.
  • eine Fujitsu  PRIMEQUEST PPAR mindestens 8 CPU Sockets und 6 TB Hauptpseicher zugewiesen bekommen

SAPS Sizing für SAP HANA

Im oberen Kapitel haben wir uns um den Arbeitsspeicherbedarf und die Aufteilung der Rechenpower unter SAP HANA gekümmert. Es macht nämlich durchaus einen Unterschied, ob Sie eine Rechenleistung von 2.000 SAPS mit vier Kernen auf einem einzigen CPU Socket oder mit jeweils zwei Kernen auf zwei CPU Sockets erzielen. Die letztere Konfiguration hat mehr Overhead. Deswegen liefert der Hersteller diverse Hinweise über die Aufteilung der Rechenleistung auf mehrerere CPU Sockets auf, die wir weiter oben durchleuchtet haben.

Hier geht es jetzt um den eigentlichen Rechenbedarf an sich, also um die zur Verfügung stehende CPU-Zeit bei einer vorgegebenen Auslastung. Der Hersteller SAP liefert hierzu eine Maßeinheit aus. Diese nennt sich SAP Application Performance Standards, kurz SAPS. Ein SAPS sind 20 vollständig abgearbeitete Positionen in einem Sales&Distribution (SD) Order to Cash Prozess pro Stunde. Die selbe Leistung wird gebraucht, wenn SAP-Anwender 6.000 Dialogschirtte udrchführen (Bildschirmwechsel auf dem Frontend) oder 2.400 SAP Transaktionen ausführen. Dieser Standard bietet eine einfache Möglichkeit, die Rechenleistung anhand der Prozesse im Unternehmen abzuschätzen. Wenn Sie beispielsweise in Ihrem System 2000 Order to Cash Prozesse pro Stunde haben oder ihre User in einer Stunde 6.000 Bildschirmwechsel auslösen, brauchen Sie in etwa 100 SAPS. Sie können das aber auch grob auf andere Prozesse ummünzen, die sich über mehrere Transaktionen und Dialogbildschirme erstrecken.

Erwarten Sie auf keinen Fall, dass Sie unter SAP HANA weniger CPU-Rechenleistung brauchen wie bei einer klassischen relationalen Datenbank. Im Gegenteil sollten Sie hier sogar mit mehr Rechenleistung kalkulieren. Jedoch hat dies auch einen entsprechenden Vorteil. Die CPU arbeitet in einer in-Memory Datenbank mehr, weil die Datenkompression in einer spaltenorientierten in-Memory Datenbank höher ist. Zusätzlich lohnt es sich, die Verarbeitungslogik weg vom Anwendungsserver und stattdessen hin zur Datenbank zu legen. Denn eine in-Memory Datenbank pflegt alle Daten eben in-Memory und kann sie daher on the fly manipulieren und aggregieren. Ein Anwendungsserver muss die Daten erst einmal aus der Datenbank abholen und puffern. Um es einfach zu sagen: Unter HANA brauchen Sie zwar mehr Rechenleistung, aber Sie holen aus dieser Leistung mehr raus als in der alten Welt.

Ein kurzer Überblick darüber, wie viele SAPS verschiedene IT-Systeme eigentlich so schaffen

GerätCPUsAnzahl SAPS
Laptop1 Prozessor, 4 Kerne10.000 SAPS
Commodity Server2 Prozessoren, 40 Kerne90.000 SAPS
Enterprise Server16 Prozessoren, 244 Kerne500.000 SAPS

Komplette Referenzkonfigurationen, die den SAP-Benchmark durchlaufen und im Anschluss ein gewisses messbares Ergebnis vorweisen konnten, finden Sie unter www.sap.com/benchmark.

Zu guter letzt wollen wir noch kurz die Single Computing Unit Performance (SCU Performance) ansprechen. Es macht durchaus einen Unterschied, ob man eine bestimmte Taktrate oder eine bestimmte CPU-Zeit mit einem einzigen Kern oder mit mehreren Kernen bereitstellt. Selbstverständlich ist es zunächst einmal besser, wenn eine einzelne SCU (ein Thread im Hyperthreading, ein Kern oder ein einzelner CPU Socket) möglichst leistungsfähig ist. Je nach Logik der Anwendung profitiert diese besonders gut von der Leistungsfähigkeit einer einzelnen SCU. Soll heißen: Bei einigen Anwendungen ist es besonders wichtig, dass eine einzelne Computing Unit sehr performant ist, bei anderen wiederum kann man die selbe Leistung auch einfach mit zwei SCUs mit der selben Taktrate oder mit vier SCUs mit einem Viertel der Taktrate erreichen.

Der Hersteller SAP kennt hierbei drei Klassen.

  • A – das SAP-produkt profitiert von guteri SCU Performance
  • AA  -das SAP-produkt profitiert von sehr guter SCU Performance
  • AAA – das SAP-produkt profitiert von exzellenter SCU Performance.

Fällt eine SAP-Anwendung in die SCU-Klasse AAA, ist es in diesem Produkt wichtig, dass eine einzelne Recheneinheit bereits möglichst leistungsfähig ist. Es ist sehr schwerig, die gleiche Leistung mit mehreren schwächeren Recheneinheiten abzubilden. Bei einer Anwendung unter der SCU-Klasse A ist dies hingegen einfacher möglich.

SAP HANA Storage Sizing

Speicherplatz (Disk Space) für die verschiedenen Volumes

Speicherplatz für das Data Volume

Das Data Volume enthält die sogenannten Savepoint Files der einzelnen Services. Jeder SAP HANA Service hat seine eigenen Savepoint Files, in welcher er die Daten persistiert. In regelmäßigen Abständen werden die Änderungsvektoren, die sich in den Online Redo Log Files befinden, ebenfalls in die Savepoint Files geschrieben. Das Data Volume macht einen Großteil des Speicherplatzverbrauchs in der HANA-Datenbank aus.

Die Größe des Data Volmes lässt sich berechnen. Grundsätzlich handelt es sich dabei mindestens um die Größe an Arbeitsspeicher, die beim Sizing der Anwendung über den SAP Quick Sizer vorgeschlagen wurde. Dies ist das absolute Minimum an Speichergröße, welches man für das Data Volume berechnen sollte. Eine alternative Formel ist zu erwartende Größe der Datenbank, also die aufsummierte Größe aller Tabellen und Indizes + 20 % Puffer für Delta Merge Operationen. Wenn Sie von einer HANA Datenbank auf die andere migrieren, können Sie in der alten HANA DAtenbank den gesamten Speicherplatz über folgendes SQL-Statement berechnen.

SELECT SUM
(disk_size)/1024/1024/1024
FROM
m_table_persistence_statistics

Für andere Quelldatenbanken (auch wenn diese komprimiert sind) können Sie den Speicherverbauch über die Tools auf SAP Hinweis 1514966 berechnen.

Von diesen beiden Vorschlagswerten nehmen Sie nun das Maximum. Die mathematische Formel könnte also lauten:

Speicherplatz_DataVolumes = MAX(<Memory Empfehlung Quicksizer>, <unkomprimierte Größe Quelldatenbank> +20%)

die Größe zählt für das gesamte HANA System. Wenn Sie mehrere Worker Nodes haben und somit ein Scale-Out Szenario fahren, müssen Sie diesen Datenverbrauch auf die Knoten aufteilen. Dies regeln Sie über das sogenannte Table Partitioning. Vorsicht: Dieses Sizing kalkuliert nicht eventuellen Mehrverbrauch an Speicherplatz ein, den Sie beispielsweise bei einer Database Migration Option über den Software Update Manager oder allgemein ein Update brauchen, bei welchem eine Schatteninstanz aufgebaut wird.

Speicherplatz für das Log Volume

Das Log Volume sollte dazu in der Lage sein, alle Änderungsvektoren zu speichern, die zwischen zwei Savepoints anfallen. Standardmäßig wird alle 5 Minuten ein Savepoint geschrieben. Das Log Volume solle also das Datenaufkommen von fünf Minuten überbrücken können. Jedoch kann ein Savepoint bei hoher Schreiblast übersprungen werden. Das macht das System automatisch, wenn eine gewisse Schreiblast überschritten wird. Es wird dann ausschließlich in das Log Volume geschrieben, alle Savepoints werden so lange ausgesetzt, bis sich die Schreiblast wieder beruhigt.

Als Daumenregel empfiehlt die SAP die Hälfte des RAMs bei Systemen mit einem Data Volume  bis 512 GB Größe. Bei Systemen mit einem höheren Datenvolumen sollte mit 512 GB begonnen und bei Bedarf vergrößert werden. Die Formel für das Sizing des Log Volumes zu Beginn ist also

WENN(size_data_volume > 512;512;<RAM> * 0,5)

Speicherplatz für das Installationsverzeichnis

Das Installationsverzeichnis umfasst den Ordner /hana/shared/<system-id>, in welchem die Softwarebestandteile der Installation abgelegt werden. Die Größe sollte dabei bei Scale-Up mindestens die RAM-Größe, höchstens jedoch 1 TB umfassen. Also lautet die Formel

Größe_Installation = MIN(<RAM-Größe>, 1 TB)

Bei einem Scale-Out Szenario sollte die Größe pro Vierer-Verbund die Arbeitsspeicherkapazität eines Workers umfassen. Was heißt das?

  • Wenn Sie im Scale-Out 3 Hosts mit jeweils 512 GB RAM haben, sollte die Größe des Installationsverzeichnis 512 GB umfassen
  • Wenn Sie im Scale-Out 4 Hosts mit jeweils 512 GB RAM haben, sollte die Größe des Installationsverzeichnis ebenfalls 512 GB umfassen
  • Wenn sie im Sclae-Out 5 Hosts mit jeweils 512 GB RAM haben, sollte die Größe des Installationsverzeichnis 1 TB umfassen.
  • Bei 8 Hosts wären wir immer noch bei  1 TB.
  • Bei 9 Hosts wären wir bei 1,5 TB und so weiter.

Speicherplatz für Binär-Exports von Tabellen

Der Hersteller SAP verlangt für den Support außerdem das Freihalten von Speicherplatz für Binärexporte der Datenbanktabellen aus Gründen der Fehlerursachenfindung. Verlangt wird hierbei von Ihnen, dass Sie genug Speicherplatz frei halten um die größte Tabelle in der Datenbank zweimal exportieren zu können. Das heißt im Klartext

Speicherplatz_Exportreserve = größte_Tabelle * 2

Maximale Storage-Größe für einen SAP HANA Knoten

 

I/O Sizing für den SAP HANA Storage

Die technische Größe der IOPS (Input/Output Operations per Second) bestimmt im Wesentlichen, wei viele Schreib- und Lesebefehle der Storageverbund pro Sekunde entgegen nehmen kann. Die SAP HANA Datenbank hat auch hier einige Anforderungen, die sich anhand von Formeln berechnen lassen. Zunächst einmal brauchen wir ein paar Grundlagen. Wir müssen zum einen wissen, welche Art von I/O Instruktionen die Datenbank zu welcher Gelegenheit ausführt.

Grundsätzlich können Sie es sich hier einfach machen: Es sind nur zertifizierte Storage-Lösungen für SAP HANA TDI oder eine SAP HANA Appliance zugelassen. Die Erfüllung der I/O Werte wird durch das HANA Hardware Config Check Tool geprüft. Jedoch wollen wir in diesem Blog Beitrag einen Schritt weiter gehen, um das Sizing besser zu verstehen.

Offiziell listet der Hersteller SAP kein IOPS Requirement mehr. Früher fand sich diese Voraussetzung SAP HANA Server Installation Guide. Dies ist jedoch nicht mehr der Fall. Damals wurden 100.000 IOPS als Voraussetzung gelistet. Der Grund für das ausbleibende Listing ist wahrscheinlich die starke Abhängigkeit der IOPS-Zahl vom Datenaufkommen der Kunden. Die Menge an zu verarbeitenden Daten stärkt überproportional zur Steigerung des Throughputs auf den Storage Devices. Daher könnten sich Kunden, die bereits große Big Data Szenarien fahren, beim Hersteller beschweren, weil sie mit 100.000 IOPS nicht hin kommen. Aus diesem Grund geht man deswegen wohl dazu über, die entsprechenden Storage-Systeme für verschiedene Systemgrößen zu zertifizieren.

Die Anzahl der IOPS, die ein Storage-System schafft, lässt sich berechnen. Das ist dann sinnvoll, wenn der Hersteller diese nicht explizit angibt.

IOPS = (1000 / (RL + AST))

RL = Rotational Latency; AST = Average Seek Time. Je geringer die Rotationsverzögerung und die durchschnittliche Seek Time nach einem Sektor sind, desto schneller gehts. Grundsätzlich gibt es für jedes Storage Device unterschiedliche IOPS-Werte

MeasurementDescription
Total IOPSTotal number of I/O operations per second (when performing a mix of read and write tests)
Random Read IOPSAverage number of random read I/O operations per second
Random Write IOPSAverage number of random write I/O operations per second
Sequential Read IOPSAverage number of sequential read I/O operations per second
Sequential Write IOPSAverage number of sequential write I/O operations per second

dazu kommt noch die Problematik mit den RAIDS, die man einberechnen muss. Ein Schreibvorgang auf einem nicht gespiegelten System braucht 1 I/O-Operation. Bei einem RAID 1 braucht man für jeden Schreibvorgang zwei I/O-Operationen, bei einem RAID 5 sind es satte 4 I/Os. Das heißt die Anzahl der Netto-IOPS, die der HANA-Datenbank zur Verfügung steht, ist auch abhängig von der RAID-Konfiguration.

Um eine Orientierung zu schaffen, welche Storage Devices welche „Total IOPS“ Werte schaffen, gibt es auf der entsprechenden Wikipedia-Seite  entsprechende Referenzwerte. Einige sollen hier mal kurz aufgelistet werden.

  • mechanische Festplatte SATA 3 Gbit/s mit 7.2000 RPM schafft etwa 50 IOPS
  • mechanische Festplatte SATA 3 Gbit/s mit 10.000 RPM etwa 150 IOPS
  • mechanische Festplatte SAS mit 15.000 RPM etwa 210 IOPS
  • eine SSD über SATA 3 Gbit/s im unteren Preisbereich etwa 8.000 IOPS
  • eine SSD über SATA 3 Gbit/s im oberen Preisbereich bis zu 80.000 IOPS

 

ein komplettes IBM FlashSystem (typisches Storage-System für SAP HANA on IBM Power) schafft über alle Platten hinweg 1.100.000 Random Read und 600.000 Random Wripte IOPS. Von diesen Brutto-IOPS steht nur ein Bruchteil netto zur Verfügung, wenn eine entsprechende RAID-Konfiguration (siehe oben) gefahren wird. Jetzt müsste eigentlich klar sein, wie schwer es sein wird, mit normalen mechanischen Festplatten auf den IOPS-Wert von 100.000 zu kommen.

Um nun noch genauer nachvollziehen zu können, wie man die IOPS eines Storage-Systems in Zusammenhang mit SAP HANA einschätzen muss, wollen wir uns einen Überblick über die I/O-Instruktionen im HANA Umfeld schaffen.

SzenarioBeschreibung
Schreib TransaktionenAlle Änderungen an Daten werden zunächst in das Online Redo Log geschrieben. Eine I/O Operation kann hierbei Größen zwischen 4 KB und 1 MB annehmen. Eine Datenbank Transaktion ist erst dann beendet, wenn die I/O-Operation, die das Commit enthält, in das Redo Log Volume geschrieben wurde. HIerzu können mehrere I/O-Operationen notwendig sein.

In OLTP-Systemen handelt es sich hier meistens um 4 KB I/O Operationen, im OLAP Umfeld um 1 MB I/O Operationen.

SavepointEin Savepoint schreibt alle Daten seit dem letzten Savepoint in das Data Volume. Standardmäßig werden alle 5 Minuten Savepoints ausgeführt, die jedoch verzögert werden können, wenn die Datenbank gerade sehr mit Schreibvorgängen auf das Redo Log Volume zu kämpfen hat. Eine I/O Operation für einen Savepoint kann Größen von 4 KB bis 16 MB annehmen. Datenbanktransaktionen können in der Regel parallel weiterhin ausgeführt werden, weil ein Savepoint asynchron ausgeführt wird. Jedoch gibt es in einem Savepoint eine sogenannte kritische Phase, in welcher die Datenbank keine neuen Transkationen zulässt, bis der Savepoint zu Ende geschrieben wurde. Genau aus diesem Grund werden Savepoints manchmal von der Datenbank verzögert.
SnapshotDie SAP HANA Datenbank bringt eine Snapshot-Mechanik mit sich, die nach dem Copy-on-Write-Prinzip funktioniert. Snapshots werden in der Regel manuell angetriggert.

Ein Snapshot löst Schrieb-Operationen in der Größenordnung zwischen 4 KB und 64 MB aus.

Delta MergeEin Delte Marge findet nur im Arbeitsspeicher statt und hat daher keinen Einfluss auf die I/O-Performance des Storage. Hierbei werden Änderungen in den Column Store Tabellen der Datenbank im Delta Storage Bereich des Arbeitsspeichers persistiert. Während eines Delta Merge werden die Inhalte des Delta Storage in den sogenannten Main Storage umgeschrieben, da dieser für Lese-Transkationen optimiert ist. Der Delta Merge blockiert allerdings keine Lese- und Schreib-Transaktionen. Daher hat er keinen Einfluss auf die I/O-Performance
Datenbank-NeustartBei einem Neustart laden alle HANA Services ihre Row Store Tabellen und den Datenbankkatalog vom Storage in den Hauptspeicher. Zusätzlich werden alle Redo Log Einträge, die seit dem letzten Savepoint in das Log Volume persistiert wurden, geladen und im Arbeitsspeicher eingespielt. Hierbei ist schon ersichtlich, dass hier größtenteils Lese I/Os notwendig sind.

Die Daten aus den Datendateien werden mit I/Os zwischen 4 KB und 64 MB Größe gelesen, die Redo Log Volumes mit 256 KB Lese I/Os.

Column Store Table LoadColumn Store Tabellen werden nach Bedarf in den Hauptspeicher geladen (Lazy Loading). Die zuletzt geladenen Tabellen vor einem Systemstopp sind der Datenbank bekannt und werden nach einem Neustart automatisch asynchron im Hintergrund geladen.

Hierbei werden die Column Store Tabellen aus den Data Volumes mit 4KB bis 16 MB parallelen I/Os gelesen.

Erstellung eines BackupsBei einem Backup werden die aktuellen Inhalte der Data und Log Volumes asynchron gelesen und danach in das Backup Verzeichnis geschrieben. Hierbei werden die Daten der Data Volumes mit 4KB – 64 MB I/O Operationen glesen und die der Log Backups mit I/Os von 4 KB bis 128 MB Ausmaß. Data Volume Backups werden mit 512 MB I/Os geschrieben, Log Backups mit 4KB bis 128 MB I/Os.
Datenbank RecoveryBei einem Recovery Vorgang werden erst die Daten aus dem DAta Volume Backup und im Anschluss daran die Daten aus den Online und archivierten Log Volumes gelesen. Data Volume Backups werden mit 512 MB I/Os gelesen, archivierte Log Backups mit 128 MB I/Os. Das Lesen von Online Redo Logs geschieht nicht mit 128 MB, sondern mit 256 KB I/Os. Die Daten werden in beim Recovery in die Online Data Volumes der Datenbank geschrieben. Dieser Schreibvorgang geschieht mit I/Os zwsicehn 4 KB und 64 MB.

Was können Sie nun mit diesen Zahlen anfangen? Nun, mit diesen Zahlen können Sie beispielsweise berechnen, wie viele SAP HANA Datenbanken Sie auf einem einzigen Storage System gleichzeitig betreiben, wie viele sie gleichzeitig backupen und wie viele sie gleichzeitig restoren können. Wenn Sie die Größe Ihrer Datenbanken und die Netto I/Os kennen, die diesen Datenbanken zur Verfügung stehen, wissen Sie auch wie lange die einzelnen Vorgänge dauern. Das hilft Ihnen beispielsweise wieder bei der Konfiguration der Grenzwerte für Savepoints und Redo Log Backups.

SAP HANA Network Requirements

Verbindung zwischen prmärer SAP HANA Datenbank und einem SAP Anwendungsserver

Die Anforderungen an die Verbindung zwischen der SAP HANA Datenbank und einem SAP Anwendungssystem (z. B. SAP NetWeaver, SAP BW oder S/4HANA) sowie auch einem beliebigen anderen Quellsystem in einem SAP HANA Native Szenario gibt SAP Note 1514967 vor. Aktuell sollte hierzu eine dedizierte Netzwerkbandbreite von 10 Gbit/s  anliegen.

Gemäß dem SAP HANA Network Requirements Whitepaper gilt diese Anforderung auch für die Verbindung von der SAP HANA Datenbank zu den verschiedenen Frontend-Clients, welche sich beispielsweise über das SAP HANA Studio mit der Datenbank verbinden.

Verbindung zwischen SAP HANA internem Datenverkehr

Gemäß dem SAP HANA Network Requirements Whitepaper ist für die interne Kommunikation zwischen SAP HANA Knoten (sowohl innerhalb eines SAP HANA Scale-Out Verbundes oder im Rahmen von SAP HANA Host Auto-Failover oder der SAP HANA System Replication) eine Verbindung von 10 Gbit/s über nichtblockierende Switche nötig.

Verbindung netzwerkbasierter Dateisysteme

Neben den Dateisystemen ext3 und XFS, welches für interne und SAN-basierte Speichersysteme freigegeben ist, darf SAP HANA in Produktion auch auf den Dateisystemen NFS und GPFS betrieben werden. Beide Dateisysteme können über klassisches Ethernet, GPFS zusätzlich über InfiniBand betrieben werden. Auch, wenn Sie die internen Volumes eines SAP HANA Knotens (Data Volume und Log Volume) über das Netzwerk anbinden, erfordert häufig das Teilen des HANA Shared Folders (/hana/shared) sowie eventuell eines Fencing Volumes für die SAP HANA System Replication den Einsatz solcher Technologien.

Sämtliche Verzeichnisse, die Sie über eines dieser beiden netzwerkbasierten Dateisysteme abdecken, müssen gemäß SAP Hinweis 2055470 in einem dedizierten (also explizit für diese Verbindung vorgesehenem) Netzwerksegment mit 10 Gbit/s Verbindung betrieben werden. Im Endeffekt heißt das, den SAP HANA Knoten müssen für den Zugriff auf diese Dateisysteme ein 10 Gbit/s Netzwerk zur Verfügung stehen. Unklar ist hierbei meiner Ansicht nach, ob bei dieser Anforderung ein sogenannte Virtueller I/O Server (genannt VIO Server in der IBM POWER Welt) mit einkalkuliert ist. Bei Nutzung eines VIO-Servers reduziert sich die Netto-Bandbreite auf ca. 75%, womit maximal 7,5 Gbit/s verfügbar wären.

 

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

Das könnte Dich auch interessieren …

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.