Freigeben über

Azure Storage-Typen für die SAP-Workload

  • Artikel

Azure umfasst zahlreiche Speichertypen, die sich in den Funktionen, dem Durchsatz, der Latenz und den Preisen stark unterscheiden. Einige der Speichertypen sind für SAP-Szenarien nicht oder nur eingeschränkt verwendbar. Dagegen sind verschiedene Azure-Speichertypen für spezifische SAP-Nutzdaten-Szenarien gut geeignet und optimiert. Speziell für SAP HANA wurden einige Azure-Speichertypen für die Verwendung mit SAP HANA zertifiziert. In diesem Dokument werden die verschiedenen Speichertypen erläutert und ihre Funktionen und Verwendbarkeit mit SAP-Workloads und SAP-Komponenten beschrieben.

Anmerkung zu den in diesem Artikel verwendeten Einheiten: Die Anbieter von öffentlichen Clouds sind dazu übergegangen, GiB (Gibibyte) oder TiB (Tebibyte anstelle von Gigabyte oder Terabyte als Größeneinheiten zu verwenden. Daher werden diese Einheiten in der gesamten Dokumentation und Preisgestaltung für Azure verwendet. Im gesamten Dokument wird ausschließlich auf die Größeneinheiten MiB, GiB und TiB Bezug genommen. Möglicherweise möchten Sie mit MB, GB und TB planen. Dann sind einige kleine Unterschiede in den Berechnungen zu beachten, wenn Sie die Größenanpassung für einen Durchsatz von 400 MiB/s anstatt für einen Durchsatz von 250 MiB/s vornehmen möchten.

Microsoft Azure Storage – Resilienz

Bei der Microsoft Azure-Speicherung von HDD Standard, SSD Standard, Azure Storage Premium, SSD Premium V2 und Disk Ultra werden die Basis-VHD (mit dem Betriebssystem) und die an VMs angefügten Datenträger oder VHDs (virtuelle Festplatten) in drei Kopien in drei verschiedenen Speicherknoten aufbewahrt. Das Failover zu einem anderen Replikat und das Seeding eines neuen Replikats bei einem Ausfall eines Speicherknotens erfolgt transparent. Aufgrund dieser Redundanz ist es NICHT erforderlich, eine Speicherredundanzschicht für mehrere Azure-Datenträger zu verwenden. Das wird als „lokaler redundanter Speicher „ (LRS) bezeichnet. LRS ist die Standardeinstellung für diese Azure-Speichertypen. Azure NetApp Files bietet ausreichend Redundanz, um die gleichen SLAs (Service Level Agreements) wie bei anderen nativen Azure-Speichern zu erreichen.

Es gibt mehrere weitere Redundanzmethoden, die im Artikel Azure Storage-Replikation beschrieben werden und für einige der verschiedenen Speichertypen von Azure gelten.

Hinweis

Die Verwendung von Azure Storage zum Speichern von Datenbankdaten und Wiederherstellen der Protokolldatei ist LRS zu diesem Zeitpunkt die einzige unterstützte Resilienzebene.

Beachten Sie auch, dass sich unterschiedliche Azure-Speichertypen auf die SLAs zur Verfügbarkeit einzelner VMs auswirken (wie unter SLA für Virtuelle Computer beschrieben).

Verwaltete Azure-Datenträger

Bei verwalteten Datenträgern handelt es sich um einen Ressourcentyp in Azure Resource Manager, der anstelle von in Azure Storage-Konten gespeicherten VHDs verwendet werden kann. Verwaltete Datenträger richten sich automatisch am [availability set][virtual-machines-manage-availability] des virtuellen Computers aus, mit dem sie verbunden sind. Mit einer solchen Ausrichtung erleben Sie eine Verbesserung der Verfügbarkeit Ihres virtuellen Computers und der Dienste, die auf dem virtuellen Computer ausgeführt werden. Weitere Informationen finden Sie in diesem allgemeinen Artikel.

Hinweis

Bei neuen Bereitstellungen von VMs, auf denen Azure-Blockspeicher für die zugehörigen Datenträger verwendet wird (alle Azure-Speicher außer Azure NetApp Files und Azure Files), verwaltete Azure-Datenträger für die Basis-VHD sowie die Betriebssystemdatenträger und Datenträger verwendet werden, auf denen SAP-Datenbankdateien gespeichert werden. Dies gilt unabhängig davon, ob Sie die virtuellen Computer über Verfügbarkeitsgruppen oder Verfügbarkeitszonen bereitstellen, und unabhängig von den verwendeten Gruppen und Zonen. Datenträger zum Speichern von Sicherungen müssen nicht unbedingt als verwaltete Datenträger verwendet werden.

Speicherszenarien mit SAP-Workloads

Persistente Speicherung wird in der SAP-Workload in verschiedenen Komponenten des Stapels benötigt, den Sie in Azure bereitstellen. Diese Szenarien umfassen mindestens Folgendes:

  • Persistente Basis-VHD des virtuellen Computers, die das Betriebssystem und andere Software enthält, die Sie auf diesem Datenträger installieren. Dieser Datenträger bzw. diese VHD ist der Stamm des virtuellen Computers. Alle daran vorgenommenen Änderungen müssen persistent gespeichert werden. Wenn Sie den virtuellen Computer das nächste Mal beenden und neu starten, sind damit alle zuvor vorgenommenen Änderungen weiterhin vorhanden. Dies gilt insbesondere in den Fällen, in denen der virtuelle Computer in Azure auf einem anderen Host als dem Host bereitgestellt wird, auf dem er ursprünglich ausgeführt wurde.
  • Persistente Datenträger für Daten. Diese Datenträger sind VHDs, die Sie zum Speichern von Anwendungsdaten anfügen. Bei den Anwendungsdaten kann es sich um Daten- und Protokoll- oder Wiederholungsdateien einer Datenbank, um Sicherungsdateien oder um Softwareinstallationen handeln. Dies sind alle Datenträger außer der Basis-VHD, die das Betriebssystem enthält.
  • Dateifreigaben oder freigegebene Datenträger, die das globale Transportverzeichnis für NetWeaver oder S/4HANA enthalten. Der Inhalt dieser Freigaben wird in Software genutzt, die auf mehreren virtuellen Computern ausgeführt wird, oder zum Erstellen von Szenarien mit Hochverfügbarkeits-Failoverclustern.
  • Das Verzeichnis „/sapmnt“ oder allgemeine Dateifreigaben für EDI-Prozesse (Electronic Data Interchange) oder ähnliche Prozesse. Der Inhalt dieser Freigaben wird in Software genutzt, die auf mehreren virtuellen Computern ausgeführt wird, oder zum Erstellen von Szenarien mit Hochverfügbarkeits-Failoverclustern.

In den nächsten Abschnitten werden die verschiedenen Azure-Speichertypen und ihre Verwendbarkeit für die vier SAP-Workloadszenarien erläutert. Eine allgemeine Kategorisierung zur Verwendung der verschiedenen Azure-Speichertypen finden Sie im Artikel Welche Datenträgertypen stehen in Azure zur Verfügung? Die Empfehlungen für die Verwendung der verschiedenen Azure-Speichertypen für SAP-Workloads unterscheiden sich davon nicht wesentlich.

Informationen zu Supporteinschränkungen für Azure-Speichertypen für SAP NetWeaver/Applikationsschicht von S/4HANA finden Sie in der SAP Support Note 2015553. Lesen Sie den Artikel SAP HANA: Speicherkonfigurationen für virtuelle Azure-Computer für zertifizierte und unterstützte Azure-Speichertypen.

In den Abschnitten, in denen die verschiedenen Azure-Speichertypen beschrieben werden, erhalten Sie weitere Hintergrundinformationen zu den Einschränkungen und Möglichkeiten der Verwendung der von SAP unterstützten Speicherung.

Speicheroptionen bei Verwendung der DBMS-Replikation

Unsere Referenzarchitekturen setzen die Verwendung von DBMS-Funktionen (Datenbankverwaltungssystem) wie SQL Server Always On, HANA-Systemreplikation, DB2 HADR oder Oracle Data Guard voraus. Falls Sie diese Technologien zwischen zwei oder mehreren virtuellen Azure-Computern verwenden, müssen die für jeden virtuellen Computer ausgewählten Speichertypen identisch sein. Das bedeutet, dass die Speicherkonfiguration zwischen aktivem Knoten und Replikationsknoten in der DBMS-HA-Konfiguration identisch sein muss.

Speicherempfehlungen für SAP-Speicherszenarien

Bevor auf die Einzelheiten eingegangen wird, werden zunächst die Zusammenfassung und die Empfehlungen vorgestellt. Die Details zu den einzelnen Azure-Speichertypen folgen auf diesen Abschnitt. Die Speicherempfehlungen für die SAP-Speicherszenarien werden in der folgenden Tabelle zusammengefasst:

Verwendungsszenario HDD Standard SSD Standard Storage Premium SSD Premium v2 Ultra-Datenträger Azure NetApp Files Azure Premium-Dateien
Betriebssystem-Datenträger Nicht geeignet Bedingt geeignet (nicht in der Produktion) Empfohlen Nicht möglich Nicht möglich Nicht möglich Nicht möglich
Globales Transportverzeichnis Nicht unterstützt Nicht unterstützt Empfohlen Empfohlen Empfohlen Empfohlen Sehr empfohlen
/sapmnt Nicht geeignet Bedingt geeignet (nicht in der Produktion) Empfohlen Empfohlen Empfohlen Empfohlen Sehr empfohlen
DBMS-Datenvolume, SAP HANA, M/Mv2-VM-Familien Nicht unterstützt Nicht unterstützt Empfohlen Empfohlen Empfohlen Empfohlen Nicht unterstützt
DBMS-Protokollvolume, SAP HANA, M/Mv2-VM-Familien Nicht unterstützt Nicht unterstützt Empfohlen1 Empfohlen Empfohlen Empfohlen Nicht unterstützt
DBMS-Datenvolume, SAP HANA, Esv3/Edsv4-VM-Familien Nicht unterstützt Nicht unterstützt Empfohlen Empfohlen Empfohlen Empfohlen Nicht unterstützt
DBMS-Protokollvolume, SAP HANA, Esv3/Edsv4-VM-Familien Nicht unterstützt Nicht unterstützt Nicht unterstützt Empfohlen Empfohlen Empfohlen Nicht unterstützt
HANA-Freigabevolume Nicht unterstützt Nicht unterstützt Empfohlen Empfohlen Empfohlen Empfohlen Empfohlen
DBMS-Datenvolume, Nicht-HANA Nicht unterstützt Bedingt geeignet (nicht in der Produktion) Empfohlen Empfohlen Empfohlen Nur für bestimmte Oracle-Releases unter Oracle Linux, Db2 und SAP ASE unter SLES/RHEL Linux Nicht unterstützt
DBMS-Protokollvolume, Nicht-HANA, M/Mv2-VM-Familien Nicht unterstützt Bedingt geeignet (nicht in der Produktion) Empfohlen1 Empfohlen Empfohlen Nur für bestimmte Oracle-Releases unter Oracle Linux, Db2 und SAP ASE unter SLES/RHEL Linux Nicht unterstützt
DBMS-Protokollvolume, Nicht-HANA, Nicht-M/Mv2-VM-Familien Nicht unterstützt eingeschränkt geeignet (nicht in der Produktion) Geeignet bis zu einer mittleren Workload Empfohlen Empfohlen Nur für bestimmte Oracle-Releases unter Oracle Linux, Db2 und SAP ASE unter SLES/RHEL Linux Nicht unterstützt

1 Mit Verwendung der Azure-Schreibbeschleunigung für M/Mv2-VM-Familien für Protokoll- und Wiederholungsprotokollvolumes

Merkmale der verschiedenen Speichertypen:

Verwendungsszenario HDD Standard SSD Standard Storage Premium SSD Premium v2 Ultra-Datenträger Azure NetApp Files Azure Premium-Dateien
Durchsatz/IOPS-SLA Nein Nein Ja Ja Ja Ja Ja
Latenz Lesevorgänge High Mittel bis hoch Niedrig Weniger als eine Millisekunde Weniger als eine Millisekunde Weniger als eine Millisekunde niedrig
Latenz Schreibvorgänge High Mittel bis hoch Niedrig (weniger als eine Millisekunde1) Weniger als eine Millisekunde Weniger als eine Millisekunde Weniger als eine Millisekunde niedrig
Von HANA unterstützt Nein Nein ja1 Ja Ja Ja Nein
Datenträger-Momentaufnahmen möglich Ja Ja Ja Ja3 Nein2 Ja Nein
Zuordnung von Datenträgern in verschiedenen Speicherclustern bei Verwendung von Verfügbarkeitsgruppen Über verwaltete Datenträger Über verwaltete Datenträger Über verwaltete Datenträger Datenträgertyp wird mit über Verfügbarkeitsgruppen bereitgestellten virtuellen Computern nicht unterstützt Datenträgertyp wird mit über Verfügbarkeitsgruppen bereitgestellten virtuellen Computern nicht unterstützt Nein3 Nein
Angepasst an Verfügbarkeitszonen Ja Ja Ja Ja Ja In der öffentlichen Vorschau No
Synchrone Zonenredundanz Nicht für verwaltete Datenträger Nicht für verwaltete Datenträger Für DBMS nicht unterstützt Nein Nr. Nein Ja
Asynchrone Zonenredundanz Nicht für verwaltete Datenträger Nicht für verwaltete Datenträger Für DBMS nicht unterstützt Nein No Vorschau No
Georedundanz Nicht für verwaltete Datenträger Nicht für verwaltete Datenträger Nein Nr. Nein Möglich Nein

1 Mit Verwendung der Azure-Schreibbeschleunigung für M/Mv2-VM-Familien für Protokoll- und Wiederholungsprotokollvolumes

2 Die Erstellung verschiedener Azure NetApp Files-Kapazitätspools garantiert nicht die Bereitstellung von Kapazitätspools in unterschiedlichen Speichereinheiten.

3 (Inkrementell) Momentaufnahmen eines SSD Premium v2- oder Disk Ultra-Datenträgers können nicht sofort nach der Erstellung verwendet werden. Die Hintergrundkopie muss abgeschlossen sein, bevor Sie einen Datenträger aus der Momentaufnahme erstellen können.

Wichtig

Im Abschnitt „Azure NetApp Files“ dieses Dokuments finden Sie Einzelheiten zur Näherungsplatzierung von NFS-Volumes und VMs, wenn Latenzen von weniger als 1 Millisekunde erforderlich sind.

Azure Storage Premium

Azure Storage SSD Premium wurde mit dem Ziel eingeführt, Folgendes bereitzustellen:

  • Niedrige E/A-Latenz
  • SLAs für IOPS und Durchsatz
  • Weniger variierende E/A-Latenz

Dieser Speichertyp zielt auf DBMS-Workloads, Speicherverkehr, der niedrige Latenzen im einstelligen Millisekundenbereich aufweist, und SLAs für IOPS und Durchsatz ab. Kostenbasis für Azure Storage Premium ist nicht der tatsächliche Datenumfang, der auf diesem Datenträger gespeichert wird, sondern die Größenkategorie eines solchen Datenträgers, unabhängig von der Datenmenge, die auf dem Datenträger gespeichert wird. Sie können auch Datenträger in Storage Premium erstellen, die den im Artikel SSD Premium aufgeführten Größenkategorien nicht direkt zugeordnet sind. Aus diesem Artikel ergeben sich folgende Schlussfolgerungen:

  • Der Speicher ist in Bereichen organisiert. Datenträger im Kapazitätsbereich von 513 GiB bis 1.024 GiB haben beispielsweise die gleichen Funktionen und die gleichen monatlichen Kosten.
  • Die IOPS pro GiB verteilen sich nicht linear über die Größenkategorien. Kleinere Datenträger unter 32 GiB haben höhere IOPS-Raten pro GiB. Bei Datenträgern über 32 GiB bis 1.024 GiB liegt die IOPS-Rate pro GiB zwischen 4–5 IOPS pro GiB. Bei größeren Datenträgern bis zu 32.767 GiB sinkt die IOPS-Rate pro GiB unter 1.
  • Der E/A-Durchsatz für diesen Speicher ist nicht linear zur Größe der Datenträgerkategorie. Bei kleineren Datenträgern, z. B. der Kategorie mit einer Kapazität zwischen 65 GiB und 128 GiB, beträgt der Durchsatz ungefähr 780 KB pro GiB. Bei den extrem großen Datenträgern, z. B. mit 32.767 GiB, liegt der Durchsatz hingegen bei etwa 28 KB pro GiB.
  • Die IOPS- und Durchsatz-SLAs können nicht geändert werden, ohne die Kapazität des Datenträgers zu ändern.

Die Funktionsmatrix für die SAP-Workload sieht folgendermaßen aus:

Funktion Comment Hinweise/Links
Basis-VHD für Betriebssystem Geeignet Alle Systeme
Datenträger Geeignet Alle Systeme – speziell für SAP HANA
Globales SAP-Transportverzeichnis Ja Unterstützt
SAP-Verzeichnis „sapmnt“ Geeignet Alle Systeme
Sicherungsspeicher Geeignet Für die kurzfristige Speicherung von Sicherungen
Freigaben/freigegebener Datenträger Nicht verfügbar Azure Files Premium oder Drittanbieter erforderlich
Resilienz LRS GRS oder ZRS für Datenträger nicht verfügbar
Latency Niedrig bis mittel -
IOPS-SLA Ja -
IOPS linear zur Kapazität halblinear in Klammern Verwaltete Datenträger – Preise
Maximale Anzahl IOPS pro Datenträger 20.000, abhängig von der Größe des Datenträgers Zu berücksichtigen sind auch die Grenzwerte für virtuelle Computer
Durchsatz-SLA Ja -
Durchsatz linear zur Kapazität Halblinear in Klammern Verwaltete Datenträger – Preise
HANA-zertifiziert Ja speziell für SAP HANA
Unterstützung für Azure-Schreibbeschleunigung Nein -
Datenträgerbursting Ja -
Datenträger-Momentaufnahmen möglich Ja -
Azure Backup-VM-Momentaufnahmen möglich Ja -
Kosten Medium -

Azure Storage Premium erfüllt nicht die Speicherlatenz-KPIs für SAP HANA mit den gängigen Zwischenspeichertypen, die mit Azure Storage Premium angeboten werden. Um die Speicherlatenz-KPIs für SAP HANA-Protokollschreibvorgänge zu erfüllen, müssen Sie das im Artikel Aktivieren der Schreibbeschleunigung beschriebene Caching der Azure-Schreibbeschleunigung verwenden. Die Azure-Schreibbeschleunigung kommt allen anderen DBMS-Systemen bei den zugehörigen Schreibvorgängen für Transaktionsprotokolle und Wiederholungsprotokolle zugute. Daher wird empfohlen, sie in allen SAP-DBMS-Bereitstellungen zu verwenden. Für SAP HANA ist die Verwendung der Azure-Schreibbeschleunigung für /hana/log in Verbindung mit Azure Storage Premium obligatorisch.

Zusammenfassung: Azure Storage Premium ist einer der für SAP-Workloads empfohlenen Azure-Speichertypen. Diese Empfehlung gilt für Nicht-Produktionssysteme und für Produktionssysteme. Azure Storage Premium eignet sich für die Verarbeitung von Datenbankworkloads. Durch die Nutzung der Azure-Schreibbeschleunigung wird die Latenz von Schreibvorgängen bei Azure Premium-Datenträgern erheblich verbessert. Für DBMS-Systeme mit hohen IOPS- und Durchsatzraten müssen Sie jedoch eine zu hohe Speicherkapazität bereitstellen. Oder Sie müssen Funktionen wie Windows Storage Spaces oder logische Volume-Manager in Linux verwenden, um Stripesets zu erstellen, die Ihnen die gewünschte Kapazität auf der jeweiligen Seite bieten. Aber auch die notwendige IOPS oder der Durchsatz bei bestmöglicher Kosteneffizienz.

Azure-Burstfunktionalität für Storage Premium

Für Azure Premium-Datenträger mit einer Kapazität bis 512 GiB wird eine Burstfunktionalität angeboten. Die genaue Funktionsweise des Datenträgerbursting wird in dem Artikel Datenträgerbursting beschrieben. Wenn Sie den Artikel lesen, verstehen Sie das Konzept des Anfallens von IOPS und Durchsatz in den Zeiten, in denen Ihre E/A-Workload unter den nominalen IOPS und unter dem Durchsatz der Datenträger liegt (Einzelheiten zum nominalen Durchsatz finden Sie unter Verwaltete Datenträger – Preise). Sie werden das Delta von IOPS und Durchsatz zwischen Ihrer aktuellen Nutzung und den Nennwerten des Datenträgers ansammeln. Die Bursts sind auf maximal 30 Minuten begrenzt.

Die idealen Fälle, in denen diese Burstfunktionalität eingeplant werden kann, werden wahrscheinlich die Volumes oder Datenträger sein, die Datendateien für die verschiedenen DBMS enthalten. Die für diese Volumen zu erwartende E/A-Workload, insbesondere bei kleinen bis mittleren Systemen, wird voraussichtlich wie folgt aussehen:

  • Geringe bis mittlere Leseworkload, da die Daten idealerweise im Arbeitsspeicher zwischengespeichert werden. Oder wie bei SAP HANA vollständig im Arbeitsspeicher
  • Bursts von Schreibvorgängen, die durch Datenbankprüfpunkte oder -sicherungspunkte ausgelöst werden, die regelmäßig ausgegeben werden
  • Sicherungsworkload, die in Fällen, in denen Sicherungen nicht über Speichermomentaufnahmen ausgeführt werden, einen kontinuierlichen Datenstrom einlesen
  • Für SAP HANA: Laden der Daten in den Arbeitsspeicher nach einem Neustart der Instanz.

Insbesondere auf kleineren DBMS-Systemen, auf denen Ihre Workload nur ein paar hundert Transaktionen pro Sekunde verarbeitet, kann eine solche Burstfunktionalität auch für die Datenträger oder Volumes sinnvoll sein, die das Transaktions- oder Wiederholungsprotokoll speichern. Die erwartete Workload für einen solchen Datenträger oder solche Volumes sieht wie folgt aus:

  • Reguläre Schreibvorgänge auf dem Datenträger, die von der Workload abhängig sind, und die Art der Workload, da jeder von der Anwendung ausgegebene Commit wahrscheinlich einen E/A-Vorgang auslöst.
  • Höhere Workloads beim Durchsatz für Fälle von Betriebsaufgaben, wie das Erstellen oder Wiederherstellen von Indizes.
  • Bursts bei Lesevorgängen beim Durchführen der Sicherungen von Transaktions- oder Wiederholungsprotokollen.

Azure SSD Premium v2

Azure SSD Premium v2-Speicher ist eine neue Version von Premium-Speicher, die mit folgendem Ziel eingeführt wurde:

  • E/A-Latenz mit unter einer Millisekunde für kleinere Lese- und Schreibzugriffsgrößen
  • SLAs für IOPS und Durchsatz
  • Kostenpflichtige Kapazität durch die bereitgestellten GB
  • Bereitstellen eines Standardsatzes von IOPS und Speicherdurchsatz pro Datenträger
  • Möglichkeit, jedem Datenträger mehr IOPS und Durchsatz hinzuzufügen und für diese zusätzlich bereitgestellten Ressourcen separat zu bezahlen
  • Bestehen der SAP HANA-Zertifizierung ohne Unterstützung durch andere Funktionen wie Azure-Schreibbeschleunigung oder andere Caches

Dieser Speichertyp zielt auf DBMS-Workloads, Speicherverkehr, der niedrige Latenzen unter einer Millisekunde aufweist, und SLAs für IOPS und Durchsatz ab. Die SSD Premium v2-Datenträger werden mit einem Standardsatz von 3.000 IOPS und einem Durchsatz von 125 MBit/s geliefert. Und es gibt die Möglichkeit, mehr IOPS und Durchsatz zu einzelnen Datenträgern hinzuzufügen. Die Preise des Speichers sind so strukturiert, dass das Hinzufügen von mehr Durchsatz oder IOPS den Preis wesentlich beeinflusst. Dennoch ist es Ihnen überlassen, zu entscheiden, wie Ihre Speicherkonfiguration für SSD Premium V2 aussehen wird. Lesen Sie als Einstieg SAP HANA: SSD Premium v2-Speicherkonfigurationen für virtuelle Azure-Computer.

Für die eigentlichen Regionen, in denen dieser neue Blockspeichertyp verfügbar ist, und die aktuellen Einschränkungen lesen Sie das Dokument SSD Premium v2.

Die Funktionsmatrix für die SAP-Workload sieht folgendermaßen aus:

Funktion Comment Hinweise/Links
Basis-VHD für Betriebssystem Nicht unterstützt Kein System
Datenträger Geeignet Alle Systeme
Globales SAP-Transportverzeichnis Ja Alle Systeme
SAP-Verzeichnis „sapmnt“ Geeignet Alle Systeme
Sicherungsspeicher Geeignet Für die kurzfristige Speicherung von Sicherungen
Freigaben/freigegebener Datenträger Nicht verfügbar Azure Files Premium oder Azure NetApp Files erforderlich
Resilienz LRS GRS oder ZRS für Datenträger nicht verfügbar
Latency Weniger als eine Millisekunde -
IOPS-SLA Ja -
IOPS linear zur Kapazität Halblinear Verwaltete Datenträger – Preise
Maximale Anzahl IOPS pro Datenträger 80.000, abhängig von der Größe des Datenträgers Zu berücksichtigen sind auch die Grenzwerte für virtuelle Computer
Durchsatz-SLA Ja -
Durchsatz linear zur Kapazität Halblinear Verwaltete Datenträger – Preise
HANA-zertifiziert Ja -
Unterstützung für Azure-Schreibbeschleunigung Nein -
Datenträgerbursting Nein -
Datenträger-Momentaufnahmen möglich Ja1 -
Azure Backup-VM-Momentaufnahmen möglich Ja -
Kosten Medium -

1 (Inkrementell) Momentaufnahmen eines SSD Premium v2- oder Disk Ultra-Datenträgers können nicht sofort nach der Erstellung verwendet werden. Die Hintergrundkopie muss abgeschlossen sein, bevor Sie einen Datenträger aus der Momentaufnahme erstellen können.

Im Gegensatz zu Azure Storage Premium erfüllt Azure SSD Premium v2 die Speicherlatenz-KPIs von SAP HANA. Daher müssen Sie das Zwischenspeichern der Azure Schreibbeschleunigung nicht verwenden, wie im Artikel Aktivieren der Schreibbeschleunigung beschrieben.

Zusammenfassung: Azure SSD Premium v2 ist der Blockspeicher mit dem besten Preis-Leistungs-Verhältnis für SAP-Workloads. Azure SSD Premium v2 eignet sich für die Verarbeitung von Datenbankworkloads. Die Latenz von unter einer Millisekunde macht den Speicher ideal für anspruchsvolle DBMS-Workloads. Es handelt sich jedoch um einen neueren Speichertyp, der im November 2022 veröffentlicht wurde. Folglich kann es noch einige Einschränkungen geben, die in den nächsten Monaten behoben werden.

Azure Ultra-Datenträger

Azure Ultra-Datenträger bieten hohen Durchsatz, hohe IOPS und konsistenten Datenträgerspeicher mit niedrigen Wartezeiten für Azure IaaS-VMs. Zu den Vorteilen von Ultra-Datenträgern gehört die Möglichkeit, die IOPS und den Durchsatz des Datenträgers dynamisch in Abstimmung mit Ihren Workloads ändern zu können, ohne Ihre virtuellen Computer neu starten zu müssen. Ultra-Datenträger eignen sich für datenintensive Workloads wie z. B. eine SAP-DBMS-Workload. Ultra-Datenträger können nur als Datenträger für Daten verwendet werden und nicht als Basis-VHD-Datenträger, auf dem das Betriebssystem gespeichert ist. Wir empfehlen die Verwendung von Azure Storage Premium als Basis-VHD-Datenträger.

Beim Erstellen eines Ultra-Datenträgers können Sie drei Dimensionen definieren:

  • Die Kapazität des Datenträgers. Die Bereiche liegen zwischen 4 GiB und 65.536 GiB.
  • Bereitgestellte IOPS für den Datenträger. Abhängig von der Kapazität des Datenträgers gelten unterschiedliche Maximalwerte. Weitere Informationen finden Sie unter Ultra-Datenträger.
  • Bereitgestellte Speicherbandbreite. Abhängig von der Kapazität des Datenträgers gelten unterschiedliche maximale Bandbreiten. Weitere Informationen finden Sie unter Ultra-Datenträger.

Die Kosten für einen einzelnen Datenträger werden durch die drei Dimensionen festgelegt, die Sie für die einzelnen Datenträger separat definieren können.

Die Funktionsmatrix für die SAP-Workload sieht folgendermaßen aus:

Funktion Comment Hinweise/Links
Basis-VHD für Betriebssystem Funktioniert nicht -
Datenträger Geeignet Alle Systeme
Globales SAP-Transportverzeichnis Ja Unterstützt
SAP-Verzeichnis „sapmnt“ Geeignet Alle Systeme
Sicherungsspeicher Geeignet Für die kurzfristige Speicherung von Sicherungen
Freigaben/freigegebener Datenträger Nicht verfügbar Drittanbieter erforderlich
Resilienz LRS GRS oder ZRS für Datenträger nicht verfügbar
Latency Sehr niedrig -
IOPS-SLA Ja -
IOPS linear zur Kapazität Halblinear in Klammern Verwaltete Datenträger – Preise
Maximale Anzahl IOPS pro Datenträger 1\.200 bis 160.000 abhängig von der Datenträgerkapazität
Durchsatz-SLA Ja -
Durchsatz linear zur Kapazität Halblinear in Klammern Verwaltete Datenträger – Preise
HANA-zertifiziert Ja -
Unterstützung für Azure-Schreibbeschleunigung Nein -
Datenträgerbursting Ja -
Datenträger-Momentaufnahmen möglich Ja1 -
Azure Backup-VM-Momentaufnahmen möglich Ja -
Kosten höher als bei Storage Premium -

1 (Inkrementell) Momentaufnahmen eines SSD Premium v2- oder Disk Ultra-Datenträgers können nicht sofort nach der Erstellung verwendet werden. Die Hintergrundkopie muss abgeschlossen sein, bevor Sie einen Datenträger aus der Momentaufnahme erstellen können.

Zusammenfassung: Azure Ultra-Datenträger sind geeignete Speicher mit niedriger Latenz von unter einer Millisekunde für alle Arten von SAP-Workloads. Bislang können Ultra-Datenträger nur in Kombination mit virtuellen Computern verwendet werden, die über Verfügbarkeitszonen (Zonenbereitstellung) bereitgestellt wurden. Im Gegensatz zu allen anderen Speichertypen können Ultra-Datenträger nicht als Basis-VHD-Datenträger verwendet werden. Ultra-Datenträger eignen sich ideal für Fälle, in denen die E/A-Workload sehr stark schwankt und Sie den bereitgestellten Speicherdurchsatz oder die IOPS an die Speicherworkloadmuster anpassen möchten, anstatt die Größe für eine maximale Nutzung von Bandbreite und IOPS zu ändern.

Azure NetApp Files

Azure NetApp Files ist ein nativer Azure-Dateispeicherdienst auf Unternehmensniveau mit hoher Leistung und Zertifizierung für SAP HANA. Er stellt Volumes-as-a-Service bereit, für die Sie NetApp-Konten, Kapazitätspools und Volumes erstellen. Mit Azure NetApp Files wählen Sie Dienst- und Leistungsstufen aus und verwalten den Datenschutz, um leistungsstarke, hoch verfügbare und skalierbare Dateifreigaben zu erstellen und zu verwalten. Dazu können Sie dieselben Protokolle und Tools verwenden, mit denen Sie vertraut sind und auf denen Ihre lokalen Unternehmensanwendungen basieren.

Die folgenden Arten von SAP-Workload werden auf Azure NetApp Files-Volumes unterstützt:

  • SAP-DBMS-Workload
  • SAPMNT-Freigabe
  • Globales Transportverzeichnis

Azure NetApp Files ist in drei Dienstebenen verfügbar, jeweils mit eigenen Durchsatz- und Preisspezifikationen. Welche für Ihre Bereitstellung geeignet ist, hängt von der Größe der Bereitstellung ab. Maßgeschneiderte Empfehlungen zur Größenanpassung erhalten Sie im Schätzer für die Gesamtkosten für SAP auf Azure NetApp Files.

Informationen zu Servicelevels finden Sie unter Servicelevels für Azure NetApp Files.

Bereitstellen von Volumes

Um optimale Ergebnisse zu erzielen, verwenden Sie die Anwendungsvolumegruppe für SAP HANA zum Bereitstellen der Volumes. Die Anwendungsvolumegruppe platziert Volumes mithilfe von Affinitäts- und Anti-Affinitätsregeln an optimalen Speicherorten in der Azure-Infrastruktur, um Konflikte zu reduzieren und den besten Durchsatz sowie die geringste Latenz zu ermöglichen.

Hinweis

Kapazitätspools sind eine grundlegende Bereitstellungseinheit für Azure NetApp Files. Kapazitätspools werden ab 1 TiB angeboten; Sie können einen Kapazitätspool in 1-TiB-Schritten erweitern. Kapazitätspools sind die übergeordnete Einheit für Volumes. Informationen zu Größen finden Sie unter Ressourcengrenzwerte für Azure NetApp Files. Informationen zu den Preisen finden Sie unter Azure NetApp Files: Preise.

Azure NetApp Files wird für verschiedene SAP-Workloadszenarien unterstützt:

Hinweis

Verwenden Sie für DBMS-Workloads unter Linux NFS-basierte Volumes auf Azure NetApp Files.

Entkoppeln des Durchsatzes von der Volumegröße

Für den Speicher für Datenbankanwendungen gelten in der Regel Durchsatzanforderungen, die nicht linear mit der Größe der Volumes skaliert werden, d. h., die Protokollvolumes sind relativ klein, erfordern jedoch einen hohen Durchsatz.

Mit Azure NetApp Files können Sie den Volumedurchsatz unabhängig von den Volumegrößen zuordnen, wenn Sie einen Kapazitätspool vom Typ manueller QoS verwenden.

Ein Beispiel:

  • Ein Volume für Datenbankdateien erfordert einen Durchsatz von 500 MiB/s und eine Kapazität von 39 TiB.
  • Ein Volume für Protokolldateien erfordert einen Durchsatz von 2.000 MiB/s und eine Kapazität von 1 TiB.

Sie können in diesem Szenario einen manuellen QoS-Kapazitätspool erstellen und Durchsatz unabhängig von den Volumegrößen zuordnen. Die erforderliche Gesamtkapazität beträgt 40 TiB, und das Gesamtdurchsatzbudget beträgt 2500 MiB/s. Ein Kapazitätspool auf der Dienstebene Premium (64 MiB/s pro zugeordnetem TiB) erfüllt sowohl die Leistungs- als auch die Kapazitätsanforderungen (40 MiB × 64 MiB/s/TiB = 2560 MiB).

Eine lineare Leistungsskalierung würde eine erhebliche Überbereitstellung des Protokollvolumes erfordern, um die Durchsatzanforderung zu erfüllen. Um den Durchsatz von 2000 MiB/s für das Protokollvolume zu erreichen, müssen Sie einen Kapazitätspool auf der Dienstebene Ultra (128 MiB/s pro zugeordnetem TiB) mit 16 TiB bereitstellen, was eine Überbereitstellung bedeutet, bei der eine Kapazität von 15 TiB ungenutzt bleibt.

Verwenden Sie den Azure NetApp Files-Leistungsrechner, um eine Schätzung für Ihr Szenario zu erhalten.

Die Funktionsmatrix für die SAP-Workload auf Azure NetApp Files sieht folgendermaßen aus:

Funktion Comment Hinweise/Links
Basis-VHD für Betriebssystem Verwenden eines verwalteten Datenträgers -
Datenträger Geeignet SAP HANA, Oracle unter Oracle Linux, DB2 und SAP ASE unter SLES/RHEL, MAXDB, SQL Server
Globales SAP-Transportverzeichnis Ja SMB (nur Windows) und NFS (nur Linux)
SAP-Verzeichnis „sapmnt“ Geeignet SMB (nur Windows) oder NFS (nur Linux)
Sicherungsspeicher Geeignet Verwenden Sie Momentaufnahmen und/oder Azure NetApp Files-Sicherung; Protokollsicherung für HANA kann auch als dateibasiertes Sicherungsziel verwendet werden
Freigaben/freigegebener Datenträger Ja SMB, NFS
Resilienz LRS und GRS GRS mit regionsübergreifender Replikation; ZRS mit zonenübergreifender Replikation
Latency Sehr niedrig In der Regel weniger als 1 ms
IOPS-SLA Ja -
IOPS linear zur Kapazität Linear mit automatischem QoS; unabhängig konfigurierbar bei manuellem QoS Drei Dienstebenen verfügbar
Durchsatz-SLA Ja Empfehlungen zur Größenanpassung erhalten Sie im Schätzer für die Gesamtkosten für SAP auf Azure NetApp Files
Durchsatz linear zur Kapazität Linear mit automatischem QoS; unabhängig konfigurierbar bei manuellem QoS Drei Dienstebenen verfügbar
HANA-zertifiziert Ja -
Datenträger-Momentaufnahmen möglich Ja Siehe Wie Azure NetApp Files Snapshots funktionieren.
Anwendungskonsistente Momentaufnahme und Sicherungsorchestrierung No Verwenden von AzAcSnap oder SnapCenter
Kosten Verwenden des Schätzungstools für die Gesamtkosten Verwenden Sie den Schätzer für die Gesamtkosten für SAP auf Azure NetApp Files, und geben Sie die Größe der Landschaft ein.

Andere integrierte Funktionen des Azure NetApp Files-Speichers:

Wichtig

Insbesondere für Datenbankbereitstellungen möchten Sie niedrige Latenzen mindestens für Ihre Wiederholungsprotokolle erzielen. Insbesondere für SAP HANA erfordert SAP eine Latenz von weniger als 1 ms für kleinere Schreibvorgänge im HANA-Wiederholungsprotokoll. Um solche Latenzen zu erreichen, sehen Sie sich die folgenden Möglichkeiten an.

Wichtig

Beachten Sie bei der Bereitstellung von Azure NetApp Files-Volumes die Zone, in der die virtuellen Computer bereitgestellt sind oder werden. Stellen Sie sicher, dass Sie dieselbe Zone auswählen. Diese Funktionalität wird im Artikel Verwalten der Volumeplatzierung von Verfügbarkeitszonen für Azure NetApp Files dokumentiert. Die Anwendungsvolumegruppe für SAP HANA verwendet die gleiche Funktionalität, um die Volumes in der Nähe zu den Anwendungs-VMs bereitzustellen.

Ziel dieser Anordnung der Verfügbarkeitszone ist es, die Risikooberfläche zu verringern, indem die NFS-Freigaben in denselben Verfügbarkeitszonen wie die Anwendungs-VMs ausgeführt werden.

  • Stellen Sie Azure NetApp Files-Volumes für Ihre SAP HANA-Bereitstellung mit der Anwendungsvolumegruppe für SAP HANA bereit. Der Vorteil der Anwendungsvolumegruppe besteht darin, dass Datenvolumes über mehrere Speicherendpunkte bereitgestellt werden, wodurch die Netzwerkverknügung reduziert und die Leistung verbessert wird.

Zusammenfassung: Azure NetApp Files ist eine zertifizierte Speicherlösung mit geringer Latenz für SAP HANA. Der Dienst stellt Volumes aus einem oder mehreren Kapazitätspools bereit. Kapazitätspools sind in drei Serviceebenen verfügbar, die die insgesamt zugewiesene Kapazität und den gesamten Durchsatz definieren. Die Größe der Volumes kann geändert werden, und der zugeordnete Durchsatz kann ohne Dienstunterbrechung angepasst werden, um sich ändernde Anforderungen zu erfüllen und die Kosten zu steuern. Der Dienst bietet Funktionen zum Replizieren von Volumes in andere Regionen oder Zonen für Notfallwiederherstellung und Geschäftskontinuität.

Azure Premium-Dateien

Azure Files Premium ist ein freigegebener Speicher, der SMB und NFS für einen moderaten Preis und eine ausreichende Latenz zur Verarbeitung von Freigaben der SAP-Anwendungsebene bietet. Darüber hinaus bietet Azure Files Premium eine synchrone Zonenreplikation der Freigaben mit einem Automatismus, dass im Falle des Ausfalls eines Replikats ein anderes Replikat in einer anderen Zone übernehmen kann. Im Gegensatz zu Azure NetApp Files gibt es keine Leistungsstufen. Ein Kapazitätspool wird ebenfalls nicht benötigt. Die Verrechnung basiert auf der tatsächlich bereitgestellten Kapazität der verschiedenen Freigaben. Azure Files Premium wurde noch nicht als DBMS-Speicher für SAP-Workloads getestet. Stattdessen konzentriert sich das Nutzungsszenario für die SAP-Workload auf alle Arten von SMB- und NFS-Freigaben, da sie auf der SAP-Anwendungsebene verwendet werden. Azure Files Premium eignen sich auch zur Verwendung für /hana/shared.

Hinweis

Bislang werden keine SAP-DBMS-Workloads auf freigegebenen Volumes auf Basis von Azure Files Premium unterstützt.

SAP-Szenarien, die in der Azure Files Premium-Liste wie folgt unterstützt werden:

Azure Files Premium beginnt mit einer größeren Anzahl von IOPS mit der Mindestfreigabegröße von 100 GB im Vergleich zu Azure NetApp Files. Durch diese höhere IOPS-Zahl kann eine Überbereitstellung von Kapazität vermieden werden, um bestimmte IOPS- und Durchsatzwerte zu erreichen. Lesen Sie für IOPS- und Speicherdurchsatz den entsprechenden Abschnitt Skalierbarkeits- und Leistungsziele für Azure Files.

Hinweis

Aufgrund der mehrstufigen Architektur von Azure Premium Files ist die Wartezeit beim Zugriff auf Metadaten der in Freigaben gespeicherten Dateien wesentlich länger als bei Azure NetApp Files. Diese längere Wartezeit kann sich beispielsweise auf das Erstellen und Löschen von Dateien per Massenverarbeitung auswirken. Aber sie kann auch spürbare Auswirkungen auf die Zeit haben, die es dauert, um den Inhalt großer Verzeichnisse aufzulisten, die viele Tausend Dateien enthalten. Der Hauptanwendungsfall, auf den sich diese längere Wartezeit bei Metadaten auswirkt, ist die Verwendung als Schnittstellenfreigabe, bei der Kunden täglich viele Tausend oder sogar Millionen von Dateierstellungen und Massenlöschungen durchführen können. Daher sollten Sie die Szenarien mit einer Schnittstellenfreigabe sorgfältig testen. Wenn Sie feststellen möchten, ob Ihre Workload metadatenlastig ist, lesen Sie die Informationen unter Hohe Arbeitsauslastung bei Metadaten oder Namespace.

Die Funktionsmatrix für die SAP-Workload sieht folgendermaßen aus:

Funktion Comment Hinweise/Links
Basis-VHD für Betriebssystem Funktioniert nicht -
Datenträger Für SAP-Workloads nicht unterstützt -
Globales SAP-Transportverzeichnis Ja SMB und NFS
SAP-Verzeichnis „sapmnt“ Geeignet Alle Systeme – SMB (nur Windows) oder NFS (nur Linux)
Sicherungsspeicher Geeignet -
Freigaben/freigegebener Datenträger Ja SMB 3.0, NFS v4.1
Resilienz LRS und ZRS Kein GRS für Azure Files Premium verfügbar
Latency niedrig -
IOPS-SLA Ja -
IOPS linear zur Kapazität streng linear -
Durchsatz-SLA Ja -
Durchsatz linear zur Kapazität streng linear -
HANA-zertifiziert Nein -
Datenträger-Momentaufnahmen möglich Ja -
Azure Backup-VM-Momentaufnahmen möglich Nein -
Kosten niedrig -

Zusammenfassung: Azure Files Premium ist ein Speicher mit niedriger Latenz, der die Bereitstellung von NFS- und SMB-Volumes oder NFS- und SMB-Freigaben ermöglicht. Azure Files Premium bietet ein hervorragendes Preis-Leistungs-Verhältnis für Freigaben auf SAP-Anwendungsebene. Zudem bietet die Lösung synchrone Zonenreplikation für diese Freigaben. Bisher wird dieser Speichertyp für die SAP-DBMS-Workload nicht unterstützt. Obwohl er für /hana/freigegebene-Volumes verwendet werden kann.

Azure SSD Standard-Speicher

Im Vergleich zu Azure HDD Standard-Speichern bieten Azure SSD Standard-Speicher eine bessere Verfügbarkeit, Konsistenz, Zuverlässigkeit und Latenz. Sie sind für Workloads optimiert, die eine konsistente Leistung bei niedrigen IOPS-Werten erfordern. Dieser Speicher ist der Mindestspeicher, der für nicht produktive SAP-Systeme mit niedrigen IOPS- und Durchsatzanforderungen verwendet wird. Die Funktionsmatrix für die SAP-Workload sieht folgendermaßen aus:

Funktion Comment Hinweise/Links
Basis-VHD für Betriebssystem Bedingt geeignet Nicht-Produktionssysteme
Datenträger Bedingt geeignet Einige Nicht-Produktionssysteme mit geringen Anforderungen an IOPS und Wartezeit
Globales SAP-Transportverzeichnis Nein Nicht unterstützt
SAP-Verzeichnis „sapmnt“ Bedingt geeignet Nicht-Produktionssysteme
Sicherungsspeicher Geeignet -
Freigaben/freigegebener Datenträger Nicht verfügbar Drittanbieter erforderlich
Resilienz LRS, GRS ZRS für Datenträger nicht verfügbar
Latency high Zu hoch für das globale SAP-Transportverzeichnis oder Produktionssysteme
IOPS-SLA Nein -
Maximale Anzahl IOPS pro Datenträger 500 unabhängig von der Datenträgergröße
Durchsatz-SLA Nein -
HANA-zertifiziert Nein -
Datenträger-Momentaufnahmen möglich Ja -
Azure Backup-VM-Momentaufnahmen möglich Ja -
Kosten LOW -

Zusammenfassung:Der Azure SSD Standard-Speicher ist die Mindestempfehlung für Nicht-Produktions-VMs für Basis-VHD, eventuelle DBMS-Bereitstellungen mit relativer Latenzunempfindlichkeit oder niedrigen IOPS- und Durchsatzraten. Dieser Azure-Speichertyp wird für das Hosten des globalen SAP-Transportverzeichnisses nicht mehr unterstützt.

Azure HDD Standard-Speicher

Azure HDD Standard war der einzige verfügbare Speichertyp, als die Azure-Infrastruktur im Jahr 2014 für SAP NetWeaver-Workloads zertifiziert wurde. 2014 waren virtuelle Azure-Computer klein und boten einen niedrigen Speicherdurchsatz. Nur deshalb konnte dieser Speichertyp mit den Anforderungen Schritt halten. Der Speicher eignet sich ideal für latenzunempfindliche Workloads, die in SAP-Umgebungen kaum vorkommen. Mit dem steigenden Durchsatz von Azure-VMs und der erhöhten Workload dieser VMs wird dieser Speichertyp nicht mehr für die Verwendung in SAP-Szenarios in Betracht gezogen. Die Funktionsmatrix für die SAP-Workload sieht folgendermaßen aus:

Funktion Comment Hinweise/Links
Basis-VHD für Betriebssystem Nicht geeignet -
Datenträger Nicht geeignet -
Globales SAP-Transportverzeichnis Nein Nicht unterstützt
SAP-Verzeichnis „sapmnt“ Nein Nicht unterstützt
Sicherungsspeicher Geeignet -
Freigaben/freigegebener Datenträger Nicht verfügbar Azure Files oder Drittanbieter erforderlich
Resilienz LRS, GRS ZRS für Datenträger nicht verfügbar
Latency high Zu hoch für die DBMS-Verwendung, das globale SAP-Transportverzeichnis oder „sapmnt/saploc“
IOPS-SLA Nein -
Maximale Anzahl IOPS pro Datenträger 500 unabhängig von der Datenträgergröße
Durchsatz-SLA Nein -
HANA-zertifiziert Nein -
Datenträger-Momentaufnahmen möglich Ja -
Azure Backup-VM-Momentaufnahmen möglich Ja -
Kosten Niedrig -

Zusammenfassung: HDD Standard ist ein Azure-Speichertyp, der nur zum Speichern von SAP-Sicherungen verwendet werden sollte. Er sollte nur als Basis-VHD für eher inaktive Systeme verwendet werden, z. B. ausgediente Systeme, in denen gelegentlich nach Daten gesucht wird. Aktive Entwicklungs-, QA- oder Produktions-VMs sollten jedoch nicht auf diesem Speicher basieren. Auch Datenbankdateien sollten nicht in diesem Speicher gehostet werden.

Azure-VM-Grenzwerte für Speicherdatenverkehr

Im Unterschied zu lokalen Szenarien spielt der einzelne ausgewählte VM-Typ eine entscheidende Rolle für die erzielbare Speicherbandbreite. Bei den verschiedenen Speichertypen ist Folgendes zu beachten:

Speichertyp Linux Windows Kommentare
HDD Standard Größen für virtuelle Linux-Computer in Azure Größen für virtuelle Windows-Computer in Azure Speichergrenzwerte mittlerer oder großer virtueller Computer wahrscheinlich schwierig erreichbar
SSD Standard Größen für virtuelle Linux-Computer in Azure Größen für virtuelle Windows-Computer in Azure Speichergrenzwerte mittlerer oder großer virtueller Computer wahrscheinlich schwierig erreichbar
Storage Premium Größen für virtuelle Linux-Computer in Azure Größen für virtuelle Windows-Computer in Azure VM-Grenzwerte für IOPS oder Speicherdurchsatz mit Speicherkonfiguration einfach zu erreichen
SSD Premium v2 Größen für virtuelle Linux-Computer in Azure Größen für virtuelle Windows-Computer in Azure VM-Grenzwerte für IOPS oder Speicherdurchsatz mit Speicherkonfiguration einfach zu erreichen
Disk Storage Ultra Größen für virtuelle Linux-Computer in Azure Größen für virtuelle Windows-Computer in Azure VM-Grenzwerte für IOPS oder Speicherdurchsatz mit Speicherkonfiguration einfach zu erreichen
Azure NetApp Files Größen für virtuelle Linux-Computer in Azure Größen für virtuelle Windows-Computer in Azure Beim Speicherdatenverkehr wird die Durchsatzbandbreite des Netzwerks und nicht die Speicherbandbreite genutzt!
Azure Premium-Dateien Größen für virtuelle Linux-Computer in Azure Größen für virtuelle Windows-Computer in Azure Beim Speicherdatenverkehr wird die Durchsatzbandbreite des Netzwerks und nicht die Speicherbandbreite genutzt!

Beachten Sie folgende Einschränkungen:

  • Je kleiner der virtuelle Computer, desto weniger Datenträger können angefügt werden. Diese Einschränkung gilt nicht für Azure NetApp Files. Da NFS- oder SMB-Freigaben eingebunden werden, besteht keine Einschränkung der Anzahl der anzufügenden freigegebenen Volumes.
  • Für virtuelle Computer gelten Grenzwerte für E/A-Durchsatz und IOPS, die mit Storage Premium-Datenträgern und Ultra-Datenträgern schnell überschritten werden können.
  • Bei Azure NetApp Files und Azure Files Premium wird beim Datenverkehr zu den freigegebenen Volumes die Netzwerkbandbreite der VMs und nicht die Speicherbandbreite genutzt.
  • Bei großen NFS-Volumes mit einer Kapazität im zweistelligen TiB-Bereich ist der Durchsatz beim Zugriff auf ein solches Volume über einen einzelnen virtuellen Computer anhand der Grenzwerte von Linux für eine Einzelsitzung in Interaktion mit dem freigegebenen Volume gedeckelt.

Wenn Sie virtuelle Azure-Computer im Lebenszyklus eines SAP-Systems ausbauen, sollten Sie die Grenzwerte für IOPS und Speicherdurchsatz des neuen und größeren VM-Typs auswerten. In einigen Fällen kann es auch sinnvoll sein, die Speicherkonfiguration an die neuen Funktionen des virtuellen Azure-Computers anzupassen.

Striping oder kein Striping

Das Erstellen eines Stripesets aus mehreren Azure-Datenträgern in einem größeren Volume ermöglicht es Ihnen, die IOPS und den Durchsatz der einzelnen Datenträger in einem Volume zu kumulieren. Striping wird nur für Azure Storage Standard und Azure Storage Premium verwendet. Bei Azure Disk Ultra können Sie Durchsatz und IOPS unabhängig von der Kapazität eines Datenträgers konfigurieren, sodass die Verwendung von Stripesets nicht erforderlich ist. Für freigegebene auf NFS oder SMB basierende Volumes können keine Stripesets erstellt werden. Da der Durchsatz und die IOPS bei Azure Storage Premium nicht linear sind, können Sie eine geringere Kapazität mit den gleichen IOPS und dem gleichen Durchsatz bereitstellen wie bei großen einzelnen Azure Storage Premium-Datenträgern. Mit dieser Methode können mit Azure Storage Premium ein höherer Durchsatz oder höhere IOPS zu geringeren Kosten erreicht werden. Durch Striping über zwei Storage P15 Premium-Datenträger erreichen Sie beispielsweise einen Durchsatz von:

  • 250 MiB/s. Ein solches Volume verfügt über eine Kapazität von 512 GiB. Für einen einzelnen Datenträger mit einem Durchsatz von 250 MiB/s müssen Sie einen P40-Datenträger mit einer Kapazität von 2 TiB verwenden.
  • 400 MiB/s durch Striping von vier Storage P10 Premium-Datenträgern mit einer Gesamtkapazität von 512 GiB. Für einen einzelnen Datenträger mit einem Durchsatz von mindestens 500 MiB pro Sekunde müssen Sie einen Storage P60 Premium-Datenträger mit einer Kapazität von 8 TiB verwenden. Da die Kosten für Storage Premium nahezu linear zur Kapazität sind, sind die Kosteneinsparungen bei Verwendung von Striping klar erkennbar.

Beim Striping sind folgende Regeln zu beachten:

  • Es sollte keine Speicherredundanz auf der VM konfiguriert werden, da der Azure-Speicher die Daten bereits im Back-End des Azure-Speichers redundant hält.
  • Die Datenträger, auf die das Stripeset angewandt wird, müssen die gleiche Größe aufweisen.
  • Mit SSD Premium v2 und Ultra-Datenträger müssen die Kapazität, bereitgestellte IOPS und der bereitgestellte Durchsatz identisch sein.

Striping über mehrere kleinere Datenträger ist die beste Möglichkeit, um mit Azure Storage Premium ein gutes Preis-Leistungs-Verhältnis zu erzielen. Es ist davon auszugehen, dass Striping einen zusätzlichen Aufwand für die Bereitstellung und Verwaltung mit sich bringen kann.

Empfehlungen zur spezifischen Stripegröße finden Sie in der Dokumentation der einzelnen DBMS, z. B. unter SAP HANA: Speicherkonfigurationen für virtuelle Azure-Computer.

Nächste Schritte

Lesen Sie die folgenden Artikel: