SAP-Workloadkonfigurationen mit Azure-Verfügbarkeitszonen

Die Bereitstellung der verschiedenen SAP-Architekturebenen in Azure-Verfügbarkeitszonen ist die empfohlene Architektur für SAP-Workloadbereitstellungen in Azure. Eine Azure-Verfügbarkeitszone ist wie folgt definiert: „Physische Orte innerhalb einer Region. Jede Zone besteht aus mindestens einem Rechenzentrum, dessen Stromversorgung, Kühlung und Netzwerkbetrieb unabhängig funktionieren.“ Azure-Verfügbarkeitszonen sind nicht in allen Regionen verfügbar. Azure-Regionen, die Verfügbarkeitszonen bereitstellen, finden Sie unter Karte mit Azure-Regionen. Der Artikel listet auf, welche Regionen Verfügbarkeitszonen bereitstellen. Die meisten Azure-Regionen, die zum Hosten einer größeren SAP-Workload ausgestattet sind, stellen Verfügbarkeitszonen bereit. Neue Azure-Regionen stellen von Anfang an Verfügbarkeitszonen bereit. Einige ältere Regionen waren oder sind dabei, mit Verfügbarkeitszonen nachgerüstet zu werden.

Ab der typischen SAP NetWeaver- oder S/4HANA-Architektur müssen drei verschiedene Ebenen geschützt werden:

• Die SAP-Anwendungsebene, in der sich ein bis ein paar Dutzend virtuelle Computer (Virtual Machines, VMs) befinden können. Dabei geht es darum, die Wahrscheinlichkeit zu minimieren, dass VMs auf demselben Hostserver bereitgestellt werden. Zudem müssen diese virtuellen Computer in einer akzeptablen Nähe zur Datenbankebene liegen, um die Netzwerklatenz in einem akzeptablen Zeitfenster zu halten
• Die SAP ASCS/SCS-Ebene, die einen Single Point of Failure in der SAP NetWeaver- und S/4HANA-Architektur darstellt. In der Regel geht es um zwei VMs, die mit einem Failoverframework geschützt werden sollen. Daher sollten diese VMs verschiedenen Fehlerdomänen der Infrastruktur zugeordnet werden.
• Die SAP-Datenbankebene, die ebenfalls einen Single Point of Failure darstellt. Diese besteht in der Regel aus zwei VMs, die durch ein Failoverframework geschützt werden. Daher sollten diese VMs verschiedenen Fehlerdomänen der Infrastruktur zugeordnet werden. Ausnahmen sind SAP HANA-Bereitstellungen für horizontales Skalieren, bei denen zwei VMs verwendet werden können.

Die Hauptunterschiede zwischen der Bereitstellung wichtiger VMs über Verfügbarkeitsgruppen oder Verfügbarkeitszonen:

• Bei der Bereitstellung über eine Verfügbarkeitsgruppe werden die VMs innerhalb der Gruppe in einer einzigen Zone oder einem einzigen Rechenzentrum (je nachdem, was für die jeweilige Region gilt) eingerichtet. Dies hat zur Folge, dass die Bereitstellung über die Verfügbarkeitsgruppe nicht vor Problemen mit der Stromversorgung, der Kühlung oder dem Netzwerk geschützt ist, von denen die Rechenzentren der Zone als Ganzes betroffen sind. Bei Verfügbarkeitsgruppen gibt es auch keinen erzwungenen Abgleich zwischen einem virtuellen Computer und seinen Datenträgern. Das bedeutet, dass sich die Datenträger in jedem Rechenzentrum der Azure-Region befinden können, unabhängig von der Zonenstruktur der Region. Positiv ist dagegen, dass die VMs an Update- und Fehlerdomänen innerhalb dieser Zone oder dieses Rechenzentrums ausgerichtet sind. Vor allem bei der SAP ASCS- oder SAP-Datenbankebene, auf der zwei virtuelle Computer pro Verfügbarkeitsgruppe geschützt werden, verhindert der Abgleich mit den Fehlerdomänen, dass sich beide virtuelle Computer auf der gleichen Hosthardware befinden.
• Durch die Bereitstellung von virtuellen Computern über Azure-Verfügbarkeitszonen und die Auswahl verschiedener Zonen (maximal drei) werden die virtuellen Computer an verschiedenen physischen Standorten bereitgestellt. Dies bietet zusätzlichen Schutz vor Problemen mit der Stromversorgung, der Kühlung oder dem Netzwerk, von denen die Rechenzentren der Zone als Ganzes betroffen sind. Virtuelle Computer und ihre zugehörigen Datenträger befinden sich in derselben Verfügbarkeitszone. Wenn jedoch in einer Verfügbarkeitszone mehrere VMs derselben VM-Familie bereitgestellt werden, gibt es keinen Schutz davor, dass sich diese VMs letztlich auf demselben Host oder in derselben Fehlerdomäne befinden. Daher ist die Bereitstellung über Verfügbarkeitszonen ideal für die SAP ASCS-und SAP-Datenbankebene, bei der in der Regel jeweils zwei virtuelle Computer bereitgestellt werden. Bei der SAP-Anwendungsebene, in der sich wesentlich mehr als zwei virtuelle Computer befinden können, sollten Sie auf ein anderes Bereitstellungsmodell zurückgreifen (Informationen dazu finden Sie weiter unten).

Ihre Motivation für eine Bereitstellung in Azure-Verfügbarkeitszonen sollte darin bestehen, dass Sie nicht nur vor dem Ausfall einer kritischen VM geschützt sind oder Ausfallzeiten für Softwarepatching bei einer kritischen VM reduzieren können, sondern, dass Sie auch vor größeren Infrastrukturproblemen geschützt sind, die sich auf die Verfügbarkeit eines oder mehrerer Azure-Rechenzentren auswirken können.

Als weitere Funktion zur Gewährleistung der Resilienz von Bereitstellungen hat Azure VM-Skalierungsgruppen mit flexibler Orchestrierung für SAP-Workloads eingeführt. VM-Skalierungsgruppen ermöglichen eine logische Gruppierung von plattformseitig verwalteten VMs. Die flexible Orchestrierung von VM-Skalierungsgruppen bietet die Möglichkeit, die Skalierungsgruppe innerhalb einer Region zu erstellen oder über mehrere Verfügbarkeitszonen zu erweitern. Beim Erstellen der flexiblen Skalierungsgruppe in einer Region mit platformFaultDomainCount>1 (FD>1) werden die in der Skalierungsgruppe bereitgestellten virtuellen Computer über die angegebene Anzahl von Fehlerdomänen in derselben Region verteilt. Andererseits würde das Erstellen der flexiblen Skalierungsgruppe über Verfügbarkeitszonen hinweg mit „platformFaultDomainCount=1“ (FD=1) die VMs über verschiedene Zonen verteilen, und die Skalierungsgruppe würde ebenfalls VMs möglichst auf unterschiedliche Fehlerdomänen innerhalb der Zone verteilen. Für SAP-Workloads werden nur flexible Skalierungsgruppen mit „FD=1“ unterstützt. Der Vorteil der Verwendung flexibler Skalierungsgruppen mit „FD=1“ für domänenübergreifende Bereitstellungen anstelle der herkömmlichen Bereitstellung in Verfügbarkeitszonen besteht darin, dass die mit der Skalierungsgruppe bereitgestellten VMs auf verschiedene Fehlerdomänen innerhalb der Zone verteilt werden. Weitere Informationen finden Sie im Bereitstellungsleitfaden für flexible Skalierungsgruppen für SAP-Workloads.

Überlegungen zur Bereitstellung über Verfügbarkeitszonen hinweg

Beachten Sie Folgendes, wenn Sie Verfügbarkeitszonen verwenden:

• Weitere Informationen zu Azure-Verfügbarkeitszonen werden im Dokument Regionen und Verfügbarkeitszonen aufgeführt.
• Die auftretende Roundtrip-Netzwerklatenz ist nicht unbedingt ein Indikator für die tatsächliche geografische Entfernung der Rechenzentren, die die verschiedenen Zonen bilden. Die Roundtrip-Netzwerklatenz wird auch durch die Kabelverbindungen und die Verlegung der Kabel zwischen diesen verschiedenen Rechenzentren beeinflusst.
• Wenn Sie Verfügbarkeitszonen als Lösung für die Notfallwiederherstellung (Disaster Recovery, DR) über kurze Distanzen verwenden, denken Sie daran, dass wir Naturkatastrophen erlebt haben, die in verschiedenen Regionen der Welt weitreichende Schäden verursacht haben, einschließlich schwerer und weitreichender Schäden an Stromversorgungsinfrastrukturen. Der Abstand zwischen verschiedenen Zonen ist möglicherweise nicht immer groß genug, um solche größeren Naturkatastrophen auszugleichen.
• Die verfügbarkeitszonenübergreifende Netzwerklatenz ist nicht für alle Azure-Regionen gleich. Auch innerhalb einer Azure-Region können die Netzwerklatenzen zwischen den verschiedenen Zonen variieren. Auch im schlimmsten Fall wird die synchrone Replikation auf Datenbankebene basierend auf der HANA-Systemreplikation oder SQL Server Always On funktionieren, ohne dass die Skalierbarkeit der Workload beeinträchtigt wird.
• Treffen Sie die Entscheidung, wo Sie Verfügbarkeitszonen verwenden, auf der Grundlage der Netzwerklatenz zwischen den Zonen. Die Netzwerklatenz spielt in zwei Bereichen eine wichtige Rolle:
  • Bei der Latenz zwischen den beiden Datenbankinstanzen, bei denen eine synchrone Replikation erforderlich ist. Basierend auf sehr erfolgreichen Vorgängen der größten NetWeaver- und S/4HANA-Systeme zwischen Zonen mit höheren Netzwerklatenzen (weniger als 1,5 Millisekunden) kann diese Überlegung vernachlässigt werden
  • Bei dem Unterschied in der Netzwerklatenz zwischen einem virtuellen Computer, der eine SAP-Dialoginstanz in derselben Zone wie die aktive Datenbankinstanz ausführt, und einem ähnlichen virtuellen Computer in einer anderen Zone. Wenn dieser Unterschied wächst, steigen auch die Auswirkungen auf die Ausführungszeit von Geschäftsprozessen und Batchaufträgen, abhängig davon, ob sie in der gleichen Zone wie die Datenbank oder in einer anderen Zone ausgeführt werden (Informationen dazu finden Sie weiter unten in diesem Artikel).
• Die Netzwerklatenz mit Azure-Verfügbarkeitszonen, auch in den größten Zonen, ist ausreichend niedrig, um SAP-Geschäftsprozesse auszuführen. Bisher haben wir nur einige Ausnahmefälle gesehen, in denen Kunden die SAP-Anwendungsebene und SAP-Datenbankebene unter einem einzigen Netzwerkstachel (Network Spine) des Rechenzentrums unterbringen mussten.

Bei der Bereitstellung von Azure-VMs über Verfügbarkeitszonen hinweg und der Einrichtung von Failoverlösungen innerhalb derselben Azure-Region gelten einige Einschränkungen:

• Sie müssen Azure Managed Disks verwenden, wenn Sie eine Bereitstellung in Azure-Verfügbarkeitszonen durchführen.
• Die Zuordnung der Zonenaufzählungen zu den physischen Zonen liegt auf einer Azure-Abonnementbasis fest. Wenn Sie für die Bereitstellung Ihrer SAP-Systeme verschiedene Abonnements verwenden, müssen Sie die idealen Zonen für jedes Abonnement definieren. Wenn Sie die logische Zuordnung Ihrer verschiedenen Abonnements vergleichen möchten, empfiehlt sich das Avzone-Mapping-Skript.
• Sie können Azure-Verfügbarkeitsgruppen nicht in einer Azure-Verfügbarkeitszone bereitstellen, solange Sie keine Azure-Näherungsplatzierungsgruppe verwenden. Wie Sie die SAP-Datenbankebene und die zentralen Dienste zonenübergreifend bereitstellen, gleichzeitig die SAP-Anwendungsebene mithilfe von Verfügbarkeitsgruppen bereitstellen und dennoch große Nähe der virtuellen Computer erreichen können, ist im Artikel Azure-Näherungsplatzierungsgruppen für optimale Netzwerklatenz mit SAP-Anwendungen dokumentiert. Wenn Sie keine Azure-Näherungsplatzierungsgruppen nutzen, müssen Sie eine der beiden Optionen als Bereitstellungsframework für VMs auswählen.
• Sie können den Azure Basic Load Balancer nicht zum Erstellen von Failoverclusterlösungen auf der Grundlage von Windows Server-Failoverclustering oder Pacemaker unter Linux verwenden. Stattdessen müssen Sie die Azure-SKU Load Balancer Standard verwenden.
• Sie müssen die Zonenversion des ExpressRoute-Gateways, des VPN Gateways und vonstandardmäßigen öffentlichen IP-Adressen bereitstellen, um den gewünschten Zonenschutz zu erhalten.

Die ideale Kombination von Verfügbarkeitszonen

Es sei denn, Sie konfigurieren die Geschäftsprozesszuweisung mit SAP-Funktionen wie Anmeldegruppen, RFC-Servergruppen, Batchservergruppen und ähnlichem; Geschäftsprozesse können in den verschiedenen Anwendungsinstanzen auf der gesamten SAP-Anwendungsebene ausgeführt werden. Die Nebeneffekt besteht darin, dass Batchaufträge von jeder SAP-Anwendungsinstanz ausgeführt werden können, unabhängig davon, ob sie in derselben Zone wie die aktive Datenbankinstanz ausgeführt wird. Wenn der Unterschied in der Netzwerklatenz zwischen den verschiedenen Zonen im Vergleich zur Netzwerklatenz innerhalb einer Zone gering ist, ist der Unterschied bei den Laufzeiten von Batchaufträgen möglicherweise nicht signifikant. Je größer jedoch der Unterschied der Netzwerklatenz innerhalb einer Zone im Vergleich zum zonenübergreifenden Netzwerkdatenverkehr ist, desto stärker kann die Laufzeit von Batchaufträgen beeinträchtigt werden, wenn der Auftrag in einer Zone ausgeführt wird, in der die Datenbankinstanz nicht aktiv ist. Sie als Kunde müssen entscheiden, welche Unterschiede bei der Laufzeit für Sie akzeptabel sind. Dies schließt mit ein, welche Netzwerklatenz für den zonenübergreifenden Datenverkehr für Ihre Workload tolerierbar ist. Rein technisch gesehen arbeiten die Netzwerklatenzen zwischen Azure-Verfügbarkeitszonen innerhalb einer Azure-Region für die Architektur von NetWeaver, S/4HANA oder anderen SAP-Anwendungen. Es ist auch für Sie als Kunde möglich, solche Unterschiede mithilfe der SAP-Konzepte von Anmeldegruppen, RFC-Servergruppen, Batchservergruppen und ähnlichem abzuschwächen, wenn Sie sich für eines der Bereitstellungskonzepte entscheiden, die in diesem Artikel vorgestellt werden.

Wenn Sie ein SAP NetWeaver- oder S/4HANA-System in verschiedenen Zonen bereitstellen möchten, stehen zwei Architekturmuster zur Auswahl:

• Aktiv/aktiv: Das VM-Paar zur Ausführung von ASCS/SCS und das VM-Paar zur Ausführung der Datenbankebene werden auf zwei Zonen verteilt. Die virtuellen Computer, auf denen die SAP-Anwendungsebene ausgeführt wird, werden gleichmäßig in denselben beiden Zonen bereitgestellt. Wenn für eine Datenbank- oder ASCS/SCS-VM ein Failover ausgeführt wird, wird für einige der offenen und aktiven Transaktionen möglicherweise ein Rollback ausgeführt. Benutzer sind jedoch weiterhin angemeldet. Es spielt keine Rolle, in welcher Zone der aktive virtuelle Datenbankcomputer und die Anwendungsinstanzen ausgeführt werden. Diese Architektur ist die bevorzugte Architektur für die zonenübergreifende Bereitstellung. In Fällen, in denen Netzwerklatenzen zwischen Zonen bei der Ausführung von Geschäftsprozessen größere Unterschiede verursachen, können Sie Funktionen wie SAP-Anmeldegruppen, RFC-Servergruppen, Batchservergruppen und ähnliches verwenden, um die Ausführung der Geschäftsprozesse für bestimmte Dialoginstanzen weiterzuleiten, die sich in derselben Zone mit der aktiven Datenbankinstanz befinden
• Aktiv/passiv: Das VM-Paar zur Ausführung von ASCS/SCS und das VM-Paar zur Ausführung der Datenbankebene werden auf zwei Zonen verteilt. Die virtuellen Computer, auf denen die SAP-Anwendungsebene ausgeführt wird, werden in einer der Verfügbarkeitszonen bereitgestellt. Die Anwendungsebene wird in der derselben Zone ausgeführt, in der sich die aktive ASCS/SCS- und Datenbankinstanz befinden. Sie können diese Bereitstellungsarchitektur verwenden, wenn Sie die Netzwerklatenz in den verschiedenen Zonen als zu hoch erachten und dadurch nicht hinnehmbare Unterschiede in der Laufzeit Ihrer Geschäftsprozesse verursacht werden. Oder wenn Sie Verfügbarkeitszonenbereitstellungen als Bereitstellungen für die Notfallwiederherstellung über kurze Distanzen verwenden möchten. Die Zonen. Wenn für eine ASCS/SCS- oder Datenbank-VM ein Failover auf die zweite Zone ausgeführt wird, wird die Netzwerklatenz möglicherweise größer und der Durchsatz verringert sich unter Umständen. Zudem muss die für VM, für die zuvor ein Failover ausgeführt wurde, so schnell wie möglich ein Fallback ausgeführt werden, um erneut die vorherigen Durchsatzwerte zu erreichen. Bei einem Zonenausfall muss für die Anwendungsschicht ein Failover auf die sekundäre Zone ausgeführt werden. Eine Aktivität, die Benutzer als vollständiges Herunterfahren des Systems erleben.

Bevor Sie also entscheiden, wie Sie Verfügbarkeitszonen verwenden, müssen Sie Folgendes ermitteln:

• Die Netzwerklatenz in den drei Zonen einer Azure-Region. Wenn Sie die Netzwerklatenz zwischen den Zonen einer Region kennen, können Sie die Zonen mit der geringsten Netzwerklatenz beim zonenübergreifenden Netzwerkdatenverkehr auswählen.
• Den Unterschied zwischen der VM-zu-VM-Latenz innerhalb einer der von Ihnen ausgewählten Zonen und der Netzwerklatenz zwischen den beiden ausgewählten Zonen.
• Die Festlegung, ob die VM-Typen, die bereitgestellt werden müssen, in den beiden ausgewählten Zonen verfügbar sind. Bei bestimmten VMs-SKUs kann es vorkommen, dass einige SKUs nur in zwei der drei Zonen verfügbar sind.

Netzwerklatenz zwischen und innerhalb von Zonen

Um die Latenz zwischen den verschiedenen Zonen zu ermitteln, müssen Sie Folgendes erledigen:

• Stellen Sie die VM-SKU bereit, die Sie für Ihre Datenbankinstanz in allen drei Zonen verwenden möchten. Stellen Sie sicher, dass Azure Accelerated Networking (Beschleunigter Azure-Netzwerkbetrieb) bei der Durchführung dieser Messung aktiviert ist. Der beschleunigte Netzwerkbetrieb ist seit einigen Jahren die Standardeinstellung. Stellen Sie dennoch sicher, dass die Funktion aktiviert ist und funktioniert.
• Wenn Sie die beiden Zonen mit der geringsten Netzwerklatenz ermittelt haben, stellen Sie drei weitere virtuelle Computer der VM-SKU bereit, die Sie als Anwendungsschicht-VM in den drei Verfügbarkeitszonen verwenden möchten. Messen Sie die Netzwerklatenz für die beiden Datenbank-VMs in den beiden Zonen, die Sie ausgewählt haben.
• Verwenden Sie niping als Messtool. Dieses Tool von SAP wird in den SAP-Supporthinweisen 500235 und 1100926 beschrieben. Behandeln Sie die Netzwerklatenzklassifizierung in SAP Note #1100926 als grobe Orientierung. Netzwerklatenzen, die größer als 0,7 Millisekunden sind, bedeuten nicht, dass das System technisch nicht funktioniert oder Geschäftsprozesse Ihre individuellen SLAs nicht erfüllen. Die Notiz soll nicht angeben, was von SAP und/oder Microsoft unterstützt oder nicht unterstützt wird. Konzentrieren Sie sich auf die Befehle, die für Latenzmessungen dokumentiert sind. Da ping nicht über die Codepfade des beschleunigten Azure-Netzwerkbetriebs funktioniert, wird von der Verwendung abgeraten.

Diese Tests müssen nicht manuell durchgeführt werden. Eine PowerShell-Prozedur Test der Latenz der Verfügbarkeitszonen ist verfügbar, die die beschriebenen Latenztests automatisiert.

Basierend auf Ihren Messungen und der Verfügbarkeit Ihrer VM-SKUs in den Verfügbarkeitszonen müssen Sie einige Entscheidungen treffen:

• Definieren der idealen Zonen für die Datenbankebene.
• Festlegen, ob Sie Ihre aktive SAP-Anwendungsschicht basierend auf Unterschieden in der Netzwerklatenz in einer Zone und zonenübergreifend auf eine, zwei oder alle drei Zonen verteilen möchten.
• Festlegen, ob Sie aus der Sicht einer Anwendung eine Aktiv/Passiv- oder Aktiv/Aktiv-Konfiguration bereitstellen möchten. (Diese Konfigurationen werden weiter unten in diesem Artikel erläutert.)

Aktiv/Aktiv-Bereitstellung

Diese Bereitstellungsarchitektur wird als „Aktiv/Aktiv“ bezeichnet, da Sie Ihre aktiven SAP-Anwendungsserver über zwei oder drei Zonen bereitstellen. Die SAP Central Services-Instanz, die die Enqueue-Replikation verwendet, wird in zwei Zonen bereitgestellt. Dies gilt auch für die Datenbankebene, die in denselben Zonen wie SAP Central Services bereitgestellt wird. Wenn Sie eine Konfiguration dieser Art in Erwägung ziehen, müssen Sie die beiden Verfügbarkeitszonen in Ihrer Region ermitteln, die eine zonenübergreifende Netzwerklatenz bieten, die für Ihre Workload akzeptabel ist. Sie sollten außerdem sicherstellen, dass das Delta zwischen der Netzwerklatenz in den ausgewählten Zonen und der zonenübergreifenden Netzwerklatenz für Ihre Workload akzeptabel ist.

Ein vereinfachtes Schema einer Aktiv/Aktiv-Bereitstellung über zwei Zonen könnte wie folgt aussehen:

Die folgenden Überlegungen gelten für diese Konfiguration:

• Wenn Sie keine Azure-Näherungsplatzierungsgruppe verwenden, betrachten Sie die Azure-Verfügbarkeitszonen als Fehlerdomänen für alle VMs, da Verfügbarkeitsgruppen nicht in Azure-Verfügbarkeitszonen bereitgestellt werden können.
• Wenn Sie Zonenbereitstellungen für die Datenbankebene und zentrale Dienste kombinieren möchten, aber Azure-Verfügbarkeitsgruppen für die Anwendungsebene verwenden möchten, müssen Sie Azure-Näherungsplatzierungsgruppen verwenden, wie im Artikel Azure-Näherungsplatzierungsgruppen für optimale Netzwerklatenz mit SAP-Anwendungen beschrieben.
• Die Lastenausgleichsmodule für die Failovercluster von SAP Central Services und die SAP-Datenbankebene müssen Azure Load Balancer-Instanzen der Standard-SKU sein. Das Lastenausgleichsmodul im Tarif „Basic“ funktioniert nicht zonenübergreifend.
• Sie müssen die Zonenversion des ExpressRoute-Gateways, des VPN Gateways und vonstandardmäßigen öffentlichen IP-Adressen bereitstellen, um den gewünschten Zonenschutz zu erhalten.
• Das virtuelle Azure-Netzwerk, das Sie zum Hosten des SAP-Systems bereitgestellt haben, wird gemeinsam mit seinen Subnetzen über Zonen verteilt. Sie benötigen keine separaten virtuellen Netzwerke und Subnetze für jede Zone.
• Für alle VMs, die Sie bereitstellen, müssen Sie Azure Managed Disks verwenden. Nicht verwaltete Datenträger werden für zonale Bereitstellungen nicht unterstützt.
• Azure SSD Premium v2, SSD Ultra-Speicher oder Azure NetApp Files unterstützen keine synchrone zonenübergreifende Speicherreplikation. Bei Datenbankbereitstellungen greifen wir auf Datenbankmethoden zurück, um Daten zonenübergreifend zu replizieren.
• SSD Premium v1, das die synchrone Zonenreplikation in Verfügbarkeitszonen unterstützt, wurde nicht mit der SAP-Datenbankworkload getestet. Daher muss die synchrone Zonenreplikation von Azure SSD Premium v1 als nicht für SAP-Datenbankworkloads unterstützt betrachtet werden.
• Für SMB- und NFS-Freigaben, die auf Azure Files Premium basieren, wird Zonenredundanz mit synchroner Replikation angeboten. Informieren Sie sich in diesem Dokument über die Verfügbarkeit von ZRS für Azure Files Premium in der Region, in der Sie die Bereitstellung vornehmen möchten. Die Verwendung von NFS- und SMB-Freigaben mit Zonenreplikation wird von Bereitstellungen auf SAP-Anwendungsebene und hochverfügbaren Failoverclustern für NetWeaver oder S/4HANA Central Services vollständig unterstützt. Diese Fälle werden in den folgenden Dokumenten abgedeckt:
  • Hochverfügbarkeit für SAP NetWeaver auf virtuellen Azure-Computern unter SUSE Linux Enterprise Server mit NFS in Azure Files
  • Hochverfügbarkeit von Azure Virtual Machines für SAP NetWeaver unter Red Hat Enterprise Linux mit Azure NetApp Files für SAP-Anwendungen
  • Hochverfügbarkeit für SAP NetWeaver auf Azure VMs auf Windows mit Azure Files Premium SMB für SAP-Anwendungen
• Die dritte Zone wird verwendet, um das SBD-Gerät zu hosten, falls Sie einen SUSE Linux Pacemaker-Cluster und anstelle des Azure-Umgrenzungs-Agents SBD-Geräte verwenden. Oder wenn Sie zusätzliche Anwendungsinstanzen erstellen.
• Um Laufzeitkonsistenz für unternehmenskritische Prozesse zu erreichen, können Sie versuchen, bestimmte Batchaufträge und Benutzer mithilfe von SAP-Batchservergruppen, SAP-Anmeldegruppen oder RFC-Gruppen direkt zu Anwendungsinstanzen in derselben Zone wie die aktive Datenbankinstanz zu leiten. Bei einem Zonenfailover müssen Sie diese Gruppen jedoch manuell in Instanzen verschieben, die auf VMs in der Zone mit der aktiven DB-VM ausgeführt werden.
• Möglicherweise sollten Sie ruhende Dialoginstanzen in jeder Zone bereitstellen.

Aktiv/Passiv-Bereitstellung

Wenn Sie eine Konfiguration nicht finden können, die das potenzielle Delta zur Laufzeit von SAP-Geschäftsprozessen mindert; oder wenn Sie eine Konfiguration für die Notfallwiederherstellung über kurze Distanzen zur Verfügung stellen möchten, können Sie eine Architektur bereitstellen, die einen Aktiv/Passiv-Charakter aus Sicht der SAP-Anwendungsebene aufweist. Sie definieren eine aktive Zone, in der Sie die vollständige Anwendungsebene bereitstellen und versuchen, sowohl die aktive Datenbank- als auch die SAP Central Services-Instanz auszuführen. Mit einer solchen Konfiguration müssen Sie sicherstellen, dass kein extremer Laufzeitunterschied in Geschäftstransaktionen und Batchaufträgen auftritt, wenn ein Auftrag in der Zone mit der aktiven Datenbankinstanz ausgeführt wird bzw. das nicht der Fall ist.

Das grundlegende Layout der Architektur sieht folgendermaßen aus:

Die folgenden Überlegungen gelten für diese Konfiguration:

• Verfügbarkeitsgruppen können nicht in Azure-Verfügbarkeitszonen bereitgestellt werden. Um dies zu kompensieren, können Sie Azure-Näherungsplatzierungsgruppen verwenden, wie im Artikel Azure-Näherungsplatzierungsgruppen für optimale Netzwerklatenz mit SAP-Anwendungen dokumentiert.
• Wenn Sie diese Architektur verwenden, müssen Sie den Status genau überwachen und versuchen, die aktiven Datenbank- und SAP Central Services-Instanzen in derselben Zone zu halten wie Ihre bereitgestellte Anwendungsebene. Bei einem Failover der SAP Central Services- oder Datenbankinstanz müssen Sie sicherstellen, dass Sie so schnell wie möglich ein manuelles Failback in die Zone mit der SAP-Anwendungsebene durchführen können.
• Die Lastenausgleichsmodule für die Failovercluster von SAP Central Services und die SAP-Datenbankebene müssen Azure Load Balancer-Instanzen der Standard-SKU sein. Das Lastenausgleichsmodul im Tarif „Basic“ funktioniert nicht zonenübergreifend.
• Sie müssen die Zonenversion des ExpressRoute-Gateways, des VPN Gateways und vonstandardmäßigen öffentlichen IP-Adressen bereitstellen, um den gewünschten Zonenschutz zu erhalten.
• Das virtuelle Azure-Netzwerk, das Sie zum Hosten des SAP-Systems bereitgestellt haben, wird gemeinsam mit seinen Subnetzen über Zonen verteilt. Sie benötigen keine separaten virtuellen Netzwerke für jede Zone.
• Für alle VMs, die Sie bereitstellen, müssen Sie Azure Managed Disks verwenden. Nicht verwaltete Datenträger werden für zonale Bereitstellungen nicht unterstützt.
• Azure SSD Premium v2, SSD Ultra-Speicher oder Azure NetApp Files unterstützen keine synchrone zonenübergreifende Speicherreplikation. Bei Datenbankbereitstellungen greifen wir auf Datenbankmethoden zurück, um Daten zonenübergreifend zu replizieren.
• SSD Premium v1, das die synchrone Zonenreplikation in Verfügbarkeitszonen unterstützt, wurde nicht mit der SAP-Datenbankworkload getestet. Daher muss die konfigurierbare synchrone Zonenreplikation von Azure SSD Premium v1 als nicht für SAP-Datenbankworkloads unterstützt betrachtet werden.
• Für SMB- und NFS-Freigaben, die auf Azure Files Premium basieren, wird Zonenredundanz mit synchroner Replikation angeboten. Informieren Sie sich in diesem Dokument über die Verfügbarkeit von ZRS für Azure Files Premium in der Region, in der Sie die Bereitstellung vornehmen möchten. Die Verwendung von NFS- und SMB-Freigaben mit Zonenreplikation wird von Bereitstellungen auf SAP-Anwendungsebene und hochverfügbaren Failoverclustern für NetWeaver oder S/4HANA Central Services vollständig unterstützt. Diese Fälle werden in den folgenden Dokumenten abgedeckt:
  • Hochverfügbarkeit für SAP NetWeaver auf virtuellen Azure-Computern unter SUSE Linux Enterprise Server mit NFS in Azure Files
  • Hochverfügbarkeit von Azure Virtual Machines für SAP NetWeaver unter Red Hat Enterprise Linux mit Azure NetApp Files für SAP-Anwendungen
  • Hochverfügbarkeit für SAP NetWeaver auf Azure VMs auf Windows mit Azure Files Premium SMB für SAP-Anwendungen
• Die dritte Zone wird verwendet, um das SBD-Gerät zu hosten, falls Sie einen SUSE Linux Pacemaker-Cluster und anstelle des Azure-Umgrenzungs-Agents SBD-Geräte verwenden. Oder wenn Sie zusätzliche Anwendungsinstanzen erstellen.
• Sie sollten ruhende virtuelle Computer in der (aus Perspektive der Datenbank) passiven Zone bereitstellen, damit Sie nach einem Zonenausfall Anwendungsressourcen starten können. Eine weitere Möglichkeit wäre die Verwendung von Azure Site Recovery, mit dem aktive VMs zonenübergreifend auf ruhende VMs repliziert werden können.
• Sie sollten in Automatisierung investieren, die Ihnen beim Ausfall einer Zone den automatischen Start der SAP-Anwendungsschicht in der zweiten Zone ermöglicht.

Kombinierte Konfiguration von Hochverfügbarkeit und Notfallwiederherstellung

Microsoft teilt keine Informationen zur geografischen Entfernung zwischen den Einrichtungen, die verschiedene Azure-Verfügbarkeitszonen in einer Azure-Region hosten. Trotzdem nutzen einige Kunden Zonen für eine kombinierte Hochverfügbarkeits- und Notfallwiederherstellungskonfiguration (Notfallwiederherstellung über kurze Distanzen), die ein Recovery Point Objective (RPO) von null verspricht. Ein RPO von 0 bedeutet, dass Sie selbst bei der Notfallwiederherstellung keine Datenbanktransaktionen verlieren sollten, für die ein Commit durchgeführt wurde.

Hier ist ein Beispiel für eine solche Konfiguration:

Die folgenden Überlegungen gelten für diese Konfiguration:

• Entweder nehmen Sie an, dass eine signifikante Distanz zwischen den Einrichtungen liegt, die eine Verfügbarkeitszone hosten. Oder Sie sind gezwungen, in einer bestimmten Azure-Region zu bleiben. Verfügbarkeitsgruppen können nicht in Azure-Verfügbarkeitszonen bereitgestellt werden. Um dies zu kompensieren, können Sie Azure-Näherungsplatzierungsgruppen wie im Artikel Azure-Näherungsplatzierungsgruppen für optimale Netzwerklatenz mit SAP-Anwendungen dokumentiert verwenden.
• Wenn Sie diese Architektur verwenden, müssen Sie den Status genau überwachen und versuchen, die aktiven Datenbank- und SAP Central Services-Instanzen in derselben Zone zu halten wie Ihre bereitgestellte Anwendungsebene. Bei einem Failover der SAP Central Services- oder Datenbankinstanz müssen Sie sicherstellen, dass Sie so schnell wie möglich ein manuelles Failback in die Zone mit der SAP-Anwendungsebene durchführen können.
• Sie sollten Instanzen von Produktionsanwendungen auf den VMs vorinstallieren, auf denen die aktiven QA-Anwendungsinstanzen ausgeführt werden.
• Bei einem Ausfall einer Zone müssen Sie die QA-Anwendungsinstanzen herunterfahren und stattdessen die Produktionsinstanzen starten. Damit dies funktioniert, müssen Sie virtuelle Namen für die Anwendungsinstanzen verwenden.
• Die Lastenausgleichsmodule für die Failovercluster von SAP Central Services und die SAP-Datenbankebene müssen Azure Load Balancer-Instanzen der Standard-SKU sein. Das Lastenausgleichsmodul im Tarif „Basic“ funktioniert nicht zonenübergreifend.
• Sie müssen die Zonenversion des ExpressRoute-Gateways, des VPN Gateways und vonstandardmäßigen öffentlichen IP-Adressen bereitstellen, um den gewünschten Zonenschutz zu erhalten.
• Das virtuelle Azure-Netzwerk, das Sie zum Hosten des SAP-Systems bereitgestellt haben, wird gemeinsam mit seinen Subnetzen über Zonen verteilt. Sie benötigen keine separaten virtuellen Netzwerke für jede Zone.
• Für alle VMs, die Sie bereitstellen, müssen Sie Azure Managed Disks verwenden. Nicht verwaltete Datenträger werden für zonale Bereitstellungen nicht unterstützt.
• Azure SSD Premium v2, SSD Ultra-Speicher oder Azure NetApp Files unterstützen keine synchrone zonenübergreifende Speicherreplikation. Bei Datenbankbereitstellungen greifen wir auf Datenbankmethoden zurück, um Daten zonenübergreifend zu replizieren.
• SSD Premium v1, das die synchrone Zonenreplikation in Verfügbarkeitszonen unterstützt, wurde nicht mit der SAP-Datenbankworkload getestet. Daher muss die konfigurierbare synchrone Zonenreplikation von Azure SSD Premium v1 als nicht für SAP-Datenbankworkloads unterstützt betrachtet werden.
• Für SMB- und NFS-Freigaben, die auf Azure Files Premium basieren, wird Zonenredundanz mit synchroner Replikation angeboten. Informieren Sie sich in diesem Dokument über die Verfügbarkeit von ZRS für Azure Files Premium in der Region, in der Sie die Bereitstellung vornehmen möchten. Die Verwendung von NFS- und SMB-Freigaben mit Zonenreplikation wird von Bereitstellungen auf SAP-Anwendungsebene und hochverfügbaren Failoverclustern für NetWeaver oder S/4HANA Central Services vollständig unterstützt. Diese Fälle werden in den folgenden Dokumenten abgedeckt:
  • Hochverfügbarkeit für SAP NetWeaver auf virtuellen Azure-Computern unter SUSE Linux Enterprise Server mit NFS in Azure Files
  • Hochverfügbarkeit von Azure Virtual Machines für SAP NetWeaver unter Red Hat Enterprise Linux mit Azure NetApp Files für SAP-Anwendungen
  • Hochverfügbarkeit für SAP NetWeaver auf Azure VMs auf Windows mit Azure Files Premium SMB für SAP-Anwendungen
• Die dritte Zone wird verwendet, um das SBD-Gerät zu hosten, falls Sie einen SUSE Linux Pacemaker-Cluster und anstelle des Azure-Umgrenzungs-Agents SBD-Geräte verwenden.

Nächste Schritte

Hier sind einige der nächsten Schritte für die Bereitstellung über Azure-Verfügbarkeitszonen hinweg:

• Gruppieren einer SAP ASCS/SCS-Instanz in einem Windows-Failovercluster mithilfe freigegebener Clusterdatenträger in Azure
• Vorbereiten der Azure-Infrastruktur für SAP-Hochverfügbarkeit mit einem Windows-Failovercluster und einer Dateifreigabe für SAP ASCS-/SCS-Instanzen