SAP HANA: Speicherkonfigurationen für virtuelle Azure-Computer

  • Artikel
  • 7 Minuten Lesedauer

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. 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 – /hana/log ist erforderlich, um von der Azure-Schreibbeschleunigung unterstützt zu werden. Das Volume /hana/data kann ohne Azure-Schreibbeschleunigung auf Storage Premium oder auf Disk Ultra platziert werden.
  • Azure Disk Ultra mindestens für das Volume /hana/log. Das Volume /hana/data kann entweder ohne Azure-Schreibbeschleunigung auf Storage Premium oder für schnellere Neustartzeiten auf Disk Ultra platziert 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.

Einige Speichertypen können kombiniert werden. Es ist z. B. möglich, /hana/data unter Storage Premium zu speichern, und /hana/log kann unter Disk Storage Ultra gespeichert werden, um die erforderliche geringe Wartezeit zu erzielen. Wenn Sie ein auf ANF basierendes Volume für /hana/data verwenden, muss das Volume /hana/log zusätzlich zu ANF auch auf NFS basieren. Die Verwendung von NFS über ANF für eines der Volumes (z. B. „/hana/data“) und Azure Storage Premium oder Disk Ultra für das andere Volume (z. B. /hana/log) wird nicht 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, 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-Speicherdurchsatz im Allgemeinen 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 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 erzielen Sie das beste Preis-/Leistungsverhältnis, wenn Sie das /hana/data- und/oder /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 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 über drei Azure Storage Premium-P30-Datenträgern platzieren, erhalten Sie den dreifachen IOPS- und den dreifachen Speicherdurchsatz eines einzelnen Azure Storage Premium-P30-Datenträgers.

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.

Azure Storage Premium-Konfigurationen für HANA

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

Azure SSD Premium v2-Konfigurationen für HANA

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

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 SAP HANA Azure-VMs.

NFS v4.1-Volumes unter Azure NetApp Files

Ausführliche Informationen zu ANF 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