SAP HANA: Speicherkonfigurationen für virtuelle Azure-Computer

  • Artikel

Azure bietet verschiedene geeignete Speichertypen für virtuelle Azure-Computer mit SAP HANA. Für SAP HANA-zertifizierte Azure-Speichertypen kommen unter anderem folgende Azure-Speichertypen in Frage:

Informationen zu diesen Datenträgertypen finden Sie im Artikel Azure Storage-Typen für die SAP-Workload und Auswählen eines Datenträgertyps.

Azure bietet zwei Bereitstellungsmethoden für virtuelle Festplatten (VHDs) in Azure Storage Standard und Premium v1/v2. Wir erwarten, dass Sie verwalteter Azure-Datenträger für Azure Blob Storage-Bereitstellungen nutzen.

Eine Liste der Speichertypen und deren Vereinbarungen zum Servicelevel für IOPS- und Speicherdurchsatz finden Sie in der Azure-Dokumentation für verwaltete Datenträger.

Wichtig

Unabhängig vom gewählten Azure-Speichertyp muss das Dateisystem, das für diesen Speicher verwendet wird, von SAP für das jeweilige Betriebssystem und DBMS unterstützt werden. SAP-Supporthinweis 2972496 listet die für verschiedene Betriebssysteme und Datenbanken, einschließlich SAP HANA, unterstützten Dateisysteme auf. Dies gilt für alle Volumes, auf die SAP HANA zum Lesen und Schreiben für eine beliebige Aufgabe möglicherweise zugreift. Speziell bei Verwendung von NFS in Azure für SAP HANA gelten, wie weiter unten in diesem Artikel angegeben, zusätzliche Einschränkungen der NFS-Versionen.

Die minimalen für SAP HANA zertifizierten Bedingungen für die verschiedenen Speichertypen sind:

  • Azure Storage Premium v1: /hana/log ist für die Unterstützung durch die Azure-Schreibbeschleunigung erforderlich. Das Volume /hana/data kann ohne Azure-Schreibbeschleunigung in Storage Premium v1 oder auf Disk Ultra bereitgestellt werden. Azure Storage Premium v2 oder Azure Premium SSD v2 unterstützt die Verwendung der Azure-Schreibbeschleunigung nicht.
  • Azure Disk Ultra mindestens für das Volume /hana/log. Das Volume /hana/data kann entweder ohne Azure-Schreibbeschleunigung in Storage Premium v1/v2 oder für schnellere Neustartzeiten in Disk Ultra bereitgestellt werden.
  • NFS v4.1-Volumes basierend auf Azure NetApp Files für /hana/log und /hana/data. Das Volume von „/hana/shared“ kann das Protokoll NFS v3 oder NFS v4.1 verwenden.

Basierend auf Erfahrungen mit Kunden haben wir die Unterstützung für die Kombination verschiedener Speichertypen zwischen /hana/data und /hana/loggeändert. Es wird unterstützt, die verschiedenen Azure-Blockspeicher zu kombinieren, die für HANA- und NFS-Freigaben basierend auf Azure NetApp Files zertifiziert sind. Es ist z. B. möglich, /hana/data unter Storage Premium v1 und v2 bereitzustellen, und /hana/log kann unter Disk Storage Ultra bereitgestellt werden, um die erforderliche geringe Latenz zu erzielen. Wenn Sie ein Volume basierend auf ANF für /hana/dataverwenden, kann das Volume /hana/log/log auch in einem der HANA-zertifizierten Azure-Blockspeichertypen bereitgestellt werden. Die Verwendung von NFS über ANF für eines der Volumes (z. B. /hana/data) und Azure Storage Premium v1/v2 oder Disk Ultra für das andere Volume (z. B. /hana/log) wird unterstützt.

In der lokalen Umgebung mussten Sie sich nur selten Gedanken über die E/A-Subsysteme und deren Funktionen machen. Das lag daran, dass der Hersteller des Geräts sicherstellen musste, dass die Mindestspeicheranforderungen für SAP HANA erfüllt sind. Da Sie die Azure-Infrastruktur selbst erstellen, sollten Sie mit einigen dieser SAP-Anforderungen vertraut sein. Einige der von SAP empfohlenen minimalen Durchsatzmerkmale sind:

  • Lese-/Schreibaktivität mit 250 MB/s in /hana/log bei einer E/A-Größe von 1 MB
  • Leseaktivität mit mindestens 400 MB/s in /hana/data für E/A-Größen von 16 MB und 64 MB
  • Schreibaktivität mit mindestens 250 MB/s in /hana/data für E/A-Größen von 16 MB und 64 MB

Da für DBMS-Systeme (und somit auch für SAP HANA) eine geringe Speicherlatenz wichtig ist, behalten sie Daten im Arbeitsspeicher. Der kritische Pfad beim Speichern sind in der Regel die Schreibvorgänge in das Transaktionsprotokoll der DBMS-Systeme. Aber auch Vorgänge wie das Schreiben von Sicherungspunkten oder das Laden von Daten in den Arbeitsspeicher nach der Wiederherstellung nach einem Systemabsturz können wichtig sein. Daher ist für die Volumes /hana/data und /hana/log die Verwendung von Azure Storage Premium v1/v2, Disk Ultra oder ANF zwingend erforderlich.

Einige Leitprinzipien bei der Auswahl Ihrer Speicherkonfiguration für HANA können wie folgt aufgeführt werden:

  • Entscheiden Sie sich für den Speichertyp auf der Grundlage von Azure Storage-Typen für die SAP-Workload und Auswählen eines Datenträgertyps.
  • Beachten Sie den E/A-Gesamtdurchsatz und die IOPS-Grenzwerte eines virtuellen Computers, wenn Sie die Größe festlegen oder sich für einen virtuellen Computer entscheiden. Der VM-Gesamtspeicherdurchsatz ist im Artikel Arbeitsspeicheroptimierte Größen virtueller Computer beschrieben.
  • Versuchen Sie bei der Entscheidung für die Speicherkonfiguration mit Ihrer /hana/data-Volumenkonfiguration unter dem Gesamtdurchsatz des virtuellen Computers zu bleiben. Beim Schreiben von Sicherungspunkten kann SAP HANA bei der E/A aggressiv sein. Es ist leicht möglich, beim Schreiben eines Sicherungspunkts bis an die Durchsatzgrenzen Ihres /hana/data-Volumens zu gehen. Wenn Ihre Datenträger, die das /hana/data-Volume bilden, einen höheren Durchsatz aufweisen, als Ihre VM zulässt, könnten Sie in Situationen geraten, in denen der vom Sicherungspunkt verwendete Durchsatz die Durchsatzanforderungen der Schreibvorgänge für das Wiederholungsprotokoll stört. Eine Situation, die sich auf den Durchsatz der Anwendung auswirken kann.
  • Wenn Sie die Verwendung der HANA-Systemreplikation in Betracht ziehen, muss der Speicher, der für /hana/data auf jedem Replikat verwendet wird, identisch sein, ebenso wie der Speichertyp, der für /hana/log für jedes Replikat verwendet wird. So wird beispielsweise die Verwendung von Azure Storage Premium v1 für /hana/data mit einer VM und von Azure Disk Ultra für /hana/data in einer anderen VM, auf der ein Replikat der gleichen HANA-Systemreplikationskonfiguration ausgeführt wird, nicht unterstützt.

Wichtig

Die Vorschläge für die Speicherkonfigurationen in diesem Dokument oder nachfolgenden Dokumenten sind als Anleitung für den Einstieg gedacht. Wenn Sie die Workload ausführen und Speicherauslastungsmuster analysieren, stellen Sie möglicherweise fest, dass Sie nicht die gesamte zur Verfügung gestellte Speicherbandbreite oder IOPS nutzen. Sie könnten dann eine Verkleinerung des Speichers in Betracht ziehen. Oder aber Ihre Workload benötigt bei diesen Konfigurationen möglicherweise mehr Speicherdurchsatz als vorgeschlagen. Infolgedessen müssen Sie möglicherweise mehr Kapazität, IOPS oder Durchsatz bereitstellen. Im Spannungsbereich zwischen erforderlicher Speicherkapazität, erforderlicher Speicherlatenz, erforderlichem Speicherdurchsatz und IOPS und der kostengünstigsten Konfiguration bietet Azure genügend verschiedene Speichertypen mit unterschiedlichen Fähigkeiten und Preisen, um den richtigen Kompromiss für Sie und Ihre HANA-Workload zu finden und anzupassen.

Stripesets im Vergleich zur SAP HANA-Datenvolumepartitionierung

Mit Azure Storage Premium v1 erzielen Sie das beste Preis-Leistungs-Verhältnis, wenn Sie das /hana/data- und/oder das /hana/log-Volume über mehrere Azure-Datenträger verteilen. Dies ist die Alternative zum Bereitstellen größerer Datenträgervolumes, die den zusätzlichen Bedarf an IOPS oder Durchsatz decken. Das Erstellen eines einzelnen Volumes auf mehreren Azure-Datenträgern kann mit LVM- und MDADM-Volume-Managern erreicht werden, die Teil von Linux sind. Die Methode des Datenträgerstripings ist Jahrzehnte alt und wohlbekannt. So vorteilhaft diese Stripesetvolumes sind, um Ihren IOPS- oder Durchsatzbedarf zu erfüllen, sie erhöhen auch die Komplexität der Verwaltung. Dies gilt insbesondere, wenn die Kapazität der Volumes erweitert werden muss. Zumindest für /hana/data hat SAP eine alternative Methode eingeführt, mit der Sie das gleiche Ziel erreichen wie mit dem Striping über mehrere Azure-Datenträger. Ab Version SAP HANA 2.0 SPS03 kann der HANA-Indexserver die zugehörige E/A-Aktivität per Striping auf verschiedene HANA-Datendateien verteilen, die sich auf unterschiedlichen Azure-Datenträgern befinden. Der Vorteil ist, dass Sie kein Stripesetvolume erstellen und verwalten müssen, dass sich über verschiedene Azure-Datenträger erstreckt. Die SAP HANA-Funktionalität der Datenvolumepartitionierung wird hier ausführlich beschrieben:

Wenn Sie die Details lesen, wird Ihnen klar, dass die Anwendung dieser Funktionalität der Komplexität von Stripesets auf Volume-Manager-Basis ein Ende bereitet. Sie werden auch feststellen, dass die HANA-Datenvolumepartitionierung nicht nur bei Azure-Blockspeicher wie Azure Storage Premium v1/v2 funktioniert. Sie können diese Funktionalität auch zur Verteilung auf NFS-Freigaben verwenden, falls für diese Freigaben IOPS- oder Durchsatzeinschränkungen bestehen.

E/A-Scheduler-Modus für Linux

Linux verfügt über mehrere verschiedene E/A-Scheduling-Modi. Linux-Anbieter und SAP empfehlen im Allgemeinen, den E/A-Schedulermodus für Datenträgervolumes von mq-deadline oder kyber in noop (Non-Multiqueue) oder none (Multiqueue) zu ändern, sofern dies nicht bereits durch die Saptune-Profile von SLES erfolgt ist. Details finden Sie unter den folgenden Links:

Übernehmen Sie für Red Hat die Einstellungen für die verschiedenen SAP-Anwendungen wie von den spezifischen tune-Profilen festgelegt.

Stripegrößen bei Verwendung logischer Volume-Manager

Wenn Sie LVM oder mdadm verwenden, um Stripesets über mehrere Azure Premium-Datenträger hinweg zu erstellen, müssen Sie Stripegrößen definieren. Diese Größen unterscheiden sich zwischen /hana/data und /hana/log. Empfehlung: Als Stripegrößen empfiehlt sich die Verwendung von:

  • 256 KB für /hana/data
  • 64 KB für /hana/log

Hinweis

Die Stripegröße für /hana/data wurde abweichend von früheren Empfehlungen von 64 KB oder 128 KB auf der Grundlage von Kundenerfahrungen mit neueren Linux-Versionen in 256 KB geändert. Die Größe von 256 KB bietet eine etwas bessere Leistung. Wir haben auch die Empfehlung für Stripegrößen von /hana/log von 32 KB auf 64 KB geändert, um genügend Durchsatz mit größeren E/A-Größen zu erreichen.

Hinweis

Sie müssen keine Redundanzebenen mit RAID-Volumes konfigurieren, da der Azure-Blockspeicher drei Images einer virtuellen Festplatte beibehält. Die Verwendung eines Stripesets mit Azure Premium-Datenträgern dient lediglich dazu, Volumes zu konfigurieren, die einen ausreichenden IOPS- und/oder E/A-Durchsatz bieten.

Die Kumulierung mehrerer Azure-Datenträger unter einem Stripeset ist für den IOPS- und Speicherdurchsatz kumulativ. Wenn Sie also ein Stripeset für drei P30-Datenträger mit Azure Storage Premium v1 erstellen, erhalten Sie den dreifachen IOPS- und Speicherdurchsatz eines einzelnen P30-Datenträgers mit Azure Storage Premium v1.

Wichtig

Falls Sie LVM oder mdadm als Volume-Manager verwenden, um Stripesets über mehrere Azure Premium-Datenträger zu erstellen, dürfen die drei SAP HANA FileSystems „/data“, „/log“ und „/shared“ nicht in eine Standard- oder Root-Volumegruppe positioniert werden. Es wird dringend empfohlen, den Anweisungen des Linux-Anbieters zu folgen, die normalerweise besagen, einzelne Volumegruppen für „/data“, „/log“ und „/shared“ zu erstellen.

Überlegungen für das freigegebene HANA-Dateisystem

Bei der Größenanpassung der HANA-Dateisysteme benötigen die HANA-Systeme für Daten und Protokolldateien die meiste Aufmerksamkeit. /hana/shared spielt jedoch auch eine wichtige Rolle beim Betrieb eines stabilen HANA-Systems, da dort wichtige Komponenten wie die HANA-Binärdateien gehostet werden.
Bei zu geringer Größe könnte /hana/shared aufgrund übermäßiger Lese-/Schreibvorgänge E/A-gesättigt werden – z. B. beim Schreiben eines großen Speicherabbilds, während einer intensiven Ablaufverfolgung oder wenn die Sicherung in das Dateisystem /hana/shared geschrieben wird. Die Latenz könnte ebenfalls steigen.

Wenn sich das HANA-System in einer Hochverfügbarkeitskonfiguration befindet, können langsame Antworten aus dem freigegebenen Dateisystem, d. h. /hana/shared, zu Timeouts für Clusterressourcen führen. Diese Timeouts können zu unnötigen Failovern führen, da die HANA-Ressourcen-Agents fälschlicherweise davon ausgehen könnten, dass die Datenbank nicht verfügbar ist.

Die SAP-Richtlinien für empfohlene /hana/shared-Größen würden wie folgt aussehen:

Volume Empfohlene Größe
/hana/shared hochskalieren Min(1 TB, 1 x RAM)
/hana/shared aufskalieren 1 x RAM des Workerknotens
pro vier Workerknoten

Weitere Informationen finden Sie in den folgenden SAP-Hinweisen:
3288971 – FAQ: SUSE HAE/RedHat HAA Pacemaker Cluster Resource Manager in SAP HANA System Replication Environments
1999930 – FAQ: SAP HANA I/O Analysis

Die bewährte Methode ist, die Größe von /hana/shared anzupassen, um Leistungsengpässe zu vermeiden. Denken Sie daran, dass ein /hana/shared-Dateisystem mit angemessener Größe zur Stabilität und Zuverlässigkeit Ihres SAP HANA-Systems beiträgt, insbesondere in Hochverfügbarkeitsszenarios.

Azure Storage Premium v1-Konfigurationen für HANA

Ausführliche Empfehlungen zur HANA-Speicherkonfiguration mithilfe von Azure Storage Premium v1 finden Sie im Dokument SSD Premium-Speicherkonfigurationen für Azure-VMs mit SAP HANA.

Azure SSD Premium v2-Konfigurationen für HANA

Ausführliche Empfehlungen zur HANA-Speicherkonfiguration mithilfe von Azure SSD Premium v2-Speicher finden Sie im Dokument SSD Premium v2-Speicherkonfigurationen für Azure-VMs mit SAP HANA.

Azure Ultra-Datenträgerspeicherkonfiguration für SAP HANA

Ausführliche Empfehlungen zur HANA-Speicherkonfiguration mithilfe von Azure Disk Ultra finden Sie im Dokument Disk Ultra-Speicherkonfigurationen für Azure-VMs mit SAP HANA.

NFS v4.1-Volumes unter Azure NetApp Files

Ausführliche Informationen zu Azure NetApp Files für HANA finden Sie im Dokument NFS v4.1-Volumes unter Azure NetApp Files für SAP HANA.

Nächste Schritte

Weitere Informationen finden Sie unter