Azure Storage-Typen für die SAP-Workload
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 Daten-VHDs 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 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 zum Wiederholen der Protokolldatei ist LRS zurzeit die einzige unterstützte Resilienzstufe.
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 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 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 | Empfohlen2 | Nicht unterstützt |
| DBMS-Protokollvolume, SAP HANA, M/Mv2-VM-Familien | Nicht unterstützt | Nicht unterstützt | Empfohlen1 | Empfohlen | Empfohlen | Empfohlen2 | Nicht unterstützt |
| DBMS-Datenvolume, SAP HANA, Esv3/Edsv4-VM-Familien | Nicht unterstützt | Nicht unterstützt | Empfohlen | Empfohlen | Empfohlen | Empfohlen2 | Nicht unterstützt |
| DBMS-Protokollvolume, SAP HANA, Esv3/Edsv4-VM-Familien | Nicht unterstützt | Nicht unterstützt | Nicht unterstützt | Empfohlen | Empfohlen | Empfohlen2 | Nicht unterstützt |
| HANA-Freigabevolume | Nicht unterstützt | Nicht unterstützt | Empfohlen | Empfohlen | Empfohlen | Empfohlen | Empfohlen3 |
| 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
2 Für die Verwendung von ANF müssen „/hana/data“ und „/hana/log“ in ANF enthalten sein.
3 Bisher nur für SLES getestet
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 | Nein | Nein | 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 | Nein |
| Synchrone Zonalredundanz | Nicht für verwaltete Datenträger | Nicht für verwaltete Datenträger | Für DBMS nicht unterstützt | Nein | Nr. | Nein | Ja |
| Asynchrone Zonalredundanz | Nicht für verwaltete Datenträger | Nicht für verwaltete Datenträger | Für DBMS nicht unterstützt | Nein | Nein | In Vorschauversion | Nein |
| 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 Kosten hängen von bereitgestellten IOPS und Durchsatz ab.
3 Die Erstellung verschiedener ANF-Kapazitätspools garantiert nicht die Bereitstellung von Kapazitätspools in unterschiedlichen Speichereinheiten.
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 die 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 | Nein | - |
| Azure Backup-VM-Momentaufnahmen möglich | Nein | - |
| Kosten | Medium | - |
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 | Nein | - |
| Datenträger-Momentaufnahmen möglich | Nein | - |
| Azure Backup-VM-Momentaufnahmen möglich | Nein | - |
| Kosten | höher als bei Storage Premium | - |
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. Ultra-Datenträger unterstützt keine Speichermomentaufnahmen. 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 (ANF)
Azure NetApp Files ist das Ergebnis der Kooperation zwischen Microsoft und NetApp mit dem Ziel, hochleistungsfähige native NFS- und SMB-Freigaben in Azure bereitzustellen. Der Schwerpunkt liegt auf der Bereitstellung von Speicher mit hoher Bandbreite und niedriger Latenz, der DBMS-Bereitstellungsszenarien ermöglicht, und der Ermöglichung typischer Betriebsfunktionen des NetApp-Speichers über Azure im Lauf der Zeit. NFS- und SMB-Freigaben werden in drei verschiedenen Dienstebenen angeboten, die sich im Speicherdurchsatz und im Preis unterscheiden. Die Dienstebenen sind im Artikel Dienstebenen für Azure NetApp Files dokumentiert. Für die unterschiedlichen Typen von SAP-Workloads werden die folgenden Dienstebenen dringend empfohlen:
- SAP-DBMS-Workload: Leistung, idealerweise Ultra
- SAPMNT-Freigabe: Leistung, idealerweise Ultra
- Globales Transportverzeichnis: Leistung, idealerweise Ultra
Hinweis
Die minimale Bereitstellungsgröße ist eine 4-TiB-Einheit, die als Kapazitätspool bezeichnet wird. Sie erstellen dann Volumes aus diesem Kapazitätspool. Das kleinste Volume, das Sie erstellen können, hat eine Kapazität von 100 GiB. Sie können einen Kapazitätspool in TiB-Schritten erweitern. Informationen zu den Preisen finden Sie im Artikel Preise für Azure NetApp Files.
Der ANF-Speicher wird derzeit für verschiedene SAP-Workloadszenarien unterstützt:
- Bereitstellen von SMB- oder NFS-Freigaben für das globale Transportverzeichnis von SAP
- Die Freigabe sapmnt in Szenarien mit hoher Verfügbarkeit wie in:
- Hochverfügbarkeit von SAP NetWeaver auf virtuellen Azure-Computern unter Windows mit Azure NetApp Files (SMB) für SAP-Anwendungen
- Hochverfügbarkeit für SAP NetWeaver auf Azure-VMs unter SUSE Linux Enterprise Server mit Azure NetApp Files für SAP-Anwendungen
- Hochverfügbarkeit von Azure Virtual Machines für SAP NetWeaver unter Red Hat Enterprise Linux mit Azure NetApp Files für SAP-Anwendungen
- SAP HANA-Bereitstellungen mit NFS v4.1-Freigaben für „/hana/data“- und „/hana/log“-Volumes und/oder NFS v4.1- oder NFS v3-Freigaben für „/hana/shared“-Volumes, wie im Artikel SAP HANA: Speicherkonfigurationen für virtuelle Azure-Computer beschrieben
- IBM Db2 unter Suse- oder Red Hat Linux-Gastbetriebssystem
- Oracle-Bereitstellungen im Oracle Linux-Gastbetriebssystem mit dNFS für Oracle-Daten- und Wiederholungsprotokollvolumes. Weitere Informationen finden Sie im Artikel Oracle-DBMS-Bereitstellung für SAP-Workload auf Azure Virtual Machines.
- SAP ASE unter Suse- oder Red-Hat-Linux-Gastbetriebssystem
Hinweis
Bisher werden in SMB basierend auf Azure NetApp Files keine DBMS-Workloads unterstützt.
Wie bereits bei Azure Storage Premium kann eine feste oder lineare Durchsatzgröße pro GB ein Problem darstellen, wenn Sie Mindestzahlen beim Durchsatz einhalten müssen. Dies ist auch bei SAP HANA der Fall. Bei ANF kann dieses Problem stärker ausgeprägt sein als bei Azure Premium-Datenträgern. Bei der Verwendung von Azure Storage Premium können Sie bei mehreren kleineren Datenträgern mit einem relativ hohen Durchsatz pro GiB ein Stripeset über die Datenträger erstellen, um Kosteneffizienz und einen höheren Durchsatz bei geringerer Kapazität zu erzielen. Diese Art von Striping funktioniert nicht bei NFS- oder SMB-Freigaben, die unter ANF gehostet werden. Diese Einschränkung führt zur Bereitstellung von überdimensionierter Kapazität:
- Um beispielsweise einen Durchsatz von 250 MiB/s auf einem NFS-Volume zu erreichen, das unter ANF gehostet wird, müssen Sie eine Kapazität von 1,95 TiB auf der Dienstebene „Ultra“ bereitstellen.
- Um 400 MiB/s zu erreichen, müssen Sie eine Kapazität von 3,125 TiB bereitstellen. Möglicherweise benötigen Sie jedoch eine Überdimensionierung der Kapazität, um den erforderlichen Durchsatz für das Volume zu erreichen. Diese Überdimensionierung der Kapazität wirkt sich auf die Preise für kleinere HANA-Instanzen aus.
- Bei der Verwendung von NFS zusätzlich zum SAP-Verzeichnis „/sapmnt“ kommen Sie mit der Mindestkapazität von 100 GiB bis 150 GiB, die von Azure NetApp Files erzwungen wird, in der Regel sehr weit. Kundenerfahrungen haben jedoch gezeigt, dass der damit verbundene Durchsatz von 12,8 MiB/s (mit der Dienstebene „Ultra“) möglicherweise nicht ausreicht und negative Auswirkungen auf die Stabilität des SAP-Systems haben kann. In solchen Fällen können Kunden Probleme vermeiden, indem sie die Größe des „/sapmnt“-Volumes erhöhen, sodass für dieses Volume mehr Durchsatz zur Verfügung steht.
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 | SAP HANA, Oracle unter Oracle Linux, DB2 und SAP ASE unter SLES/RHEL |
| 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 v3, und NFS v4.1 |
| Resilienz | LRS und GRS | GRS verfügbar |
| Latency | Sehr niedrig | - |
| IOPS-SLA | Ja | - |
| IOPS linear zur Kapazität | streng linear | abhängig von der Dienstebene |
| Durchsatz-SLA | Ja | - |
| Durchsatz linear zur Kapazität | linear | abhängig von der Dienstebene |
| HANA-zertifiziert | Ja | - |
| Datenträger-Momentaufnahmen möglich | Ja | - |
| Azure Backup-VM-Momentaufnahmen möglich | Nein | - |
| Kosten | höher als bei Storage Premium | - |
Zusätzliche integrierte Funktionalität des ANF-Speichers:
- Möglichkeit zum Erstellen von Momentaufnahmen von Volumes
- Klonen von ANF-Volumes aus Momentaufnahmen
- Wiederherstellen von Volumes aus Momentaufnahmen (snap-revert)
- Anwendungskonsistente Snapshot-Sicherung für SAP HANA und Oracle
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 Millisekunden für HANA-Wiederholungsprotokoll-Schreibvorgänge kleinerer Größen. Um solche Latenzen zu erreichen, sehen Sie sich die folgenden Möglichkeiten an.
Wichtig
Auch bei nicht-DBMS-Verwendung sollten Sie die Vorschaufunktionalität verwenden, mit der Sie die NFS-Freigabe in demselben Azure Verfügbarkeitszonen erstellen können, in dem Sie Ihre VM(n) platziert haben, in die die NFS-Freigaben eingebunden werden sollen. Diese Funktionalität wird im Artikel Verwalten der Volumeplatzierung von Verfügbarkeitszonen für Azure NetApp Files dokumentiert. Die Motivation, diese Art der Ausrichtung der Verfügbarkeitszone zu haben, ist die Verringerung der Risikooberfläche, indem sie die NFS-Aktien noch in einer anderen AvZone teilen, in der Sie keine virtuellen Computer ausführen.
- Sie wählen die größte Nähe zwischen VM und NFS-Freigabe aus, die mithilfe von Anwendungsvolumegruppen erreicht werden kann. Der Vorteil von Anwendungsvolumegruppen besteht neben der Zuweisung der besten Nähe und damit der geringsten Latenz darin, dass Ihre verschiedenen NFS-Freigaben für SAP HANA-Bereitstellungen auf verschiedene Controller in den Azure NetApp Files-Back-End-Clustern verteilt sind. Der Nachteil dieser Methode ist, dass Sie erneut einen Einpassungsprozess durchlaufen müssen. Ein Prozess, der die Beschränkung Ihrer VM-Bereitstellung auf ein einzelnes Rechenzentrum beendet. Anstelle einer Verfügbarkeitszone, wie in der ersten Methode verwendet. Dies bedeutet weniger Flexibilität beim Ändern von VM-Größen und VM-Produktfamilien der VMs, in die die NFS-Volumes eingebunden sind.
- Aktueller Prozess, bei dem keine Verfügbarkeitsplatzierungsgruppen verwendet werden. Diese sind bisher nur für SAP HANA verfügbar. Dieser Prozess verwendet auch den gleichen manuellen Einpassungsprozess wie bei Verfügbarkeitsvolumegruppen. Diese Methode wurde in den letzten drei Jahren verwendet. Es gelten die gleichen Flexibilitätseinschränkungen wie bei Verfügbarkeitsvolumegruppen.
Als Einstellungen für die Zuordnung von NFS-Volumes basierend auf ANF für datenbankspezifische Verwendung sollten Sie zuerst versuchen, das NFS-Volume in derselben Zone wie Ihre VM zuzuordnen. Insbesondere für Nicht-HANA-Datenbanken. Nur wenn sich die Latenz als unzureichend erweist, sollten Sie einen manuellen Einpassungsprozess durchlaufen. Für kleinere HANA-Workloads oder nicht produktionsbezogene HANA-Workloads sollten Sie auch eine zonale Zuordnungsmethode verwenden. Nur in Fällen, in denen Leistung und Latenz nicht ausreichen, sollten Sie Anwendungsvolumegruppen verwenden.
Zusammenfassung: Azure NetApp Files ist ein HANA-zertifizierter Speicher mit niedriger Latenz, der die Bereitstellung von NFS- und SMB-Volumes oder NFS- und SMB-Freigaben ermöglicht. Der Speicher wird mit drei verschiedenen Dienstebenen angeboten, über die unterschiedlicher Durchsatz und unterschiedliche IOPS pro GiB Kapazität des Volumes linear bereitgestellt werden. Der ANF-Speicher ermöglicht die Bereitstellung von SAP HANA-Szenarien mit horizontaler Skalierung mit einem Standbyknoten. Der Speicher eignet sich für die Bereitstellung von Dateifreigaben, wie sie für „/sapmnt“ oder das globale SAP-Transportverzeichnis benötigt werden. Der ANF-Speicher umfasst Funktionalitätsverfügbarkeit, die als native NetApp-Funktionalität verfügbar ist.
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:
- Bereitstellen von SMB- oder NFS-Freigaben für das globale Transportverzeichnis von SAP
- Die Freigabe sapmnt in Szenarien mit hoher Verfügbarkeit wie in:
- Hochverfügbarkeit für SAP NetWeaver auf virtuellen Azure-Computern unter SUSE Linux Enterprise Server mit NFS in Azure Files
- Hochverfügbarkeit für SAP NetWeaver auf virtuellen Azure-Computern unter Red Hat Enterprise Linux mit NFS in Azure Files
- Hochverfügbarkeit für SAP NetWeaver auf Azure VMs auf Windows mit Azure Files Premium SMB für SAP-Anwendungen
- Hochverfügbarkeit für horizontal skalierte SAP HANA-Systeme mit HSR unter SUSE Linux Enterprise Server
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.
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 | Nein | - |
| 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 Latenz |
| 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 ANF. 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 ANF und Azure Files Premium wird beim Datenverkehr zu den freigegebenen Volumes die Netzwerkbandbreite der virtuellen Computer 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 kein Speicher im virtuellen Computer konfiguriert werden, da der Azure-Speicher die Daten bereits 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: