SAP-Workloadkonfigurationen mit Azure-Verfügbarkeitszonen

  • Artikel

Zusätzlich zur Bereitstellung der verschiedenen SAP-Architekturebenen in Azure-Verfügbarkeitsgruppen können für SAP-Workloadbereitstellungen auch Azure-Verfügbarkeitszonen verwendet werden. 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. Auf dieser Karte sehen Sie, in welchen Regionen bereits Verfügbarkeitszonen bereitgestellt werden und für welche Regionen die Bereitstellung angekündigt ist.

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

  • SAP-Anwendungsebene, bei der es sich um einige Dutzend VMs handeln kann. Dabei geht es darum, die Wahrscheinlichkeit zu minimieren, dass VMs auf demselben Hostserver bereitgestellt werden. Zudem müssen sich diese VMs in einer akzeptablen Nähe zur DBMS-Ebene liegen, um die Netzwerklatenz in einem akzeptablen Zeitfenster zu halten.
  • 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.
  • SAP-DBMS-Ebene, 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 Stromversorgung, Kühlung oder Netzwerk geschützt ist, von denen die Rechenzentren der Zone als Ganzes betroffen sind. Positiv ist dagegen, dass die VMs an Update- und Fehlerdomänen innerhalb dieser Zone oder dieses Rechenzentrums ausgerichtet sind. Speziell für die SAP ASCS- oder DBMS-Ebene, auf der wir zwei VMs pro Verfügbarkeitssatz schützen, verhindert die Ausrichtung mit Fehler Standard verhindert, dass beide VMs auf derselben Hosthardware enden.
  • Bei der Bereitstellung von VMs über Azure Verfügbarkeitszonen und die Auswahl verschiedener Zonen (maximal drei möglich) werden die virtuellen Computer an den verschiedenen physischen Standorten bereitgestellt, und mit denen Schutz vor Energie-, Kühl- oder Netzwerkproblemen hinzugefügt wird, die sich auf die Datenzeter der Zone insgesamt auswirken. 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 DBMS-Ebene, bei der in der Regel jeweils zwei VMs bereitgestellt werden. Bei der SAP-Anwendungsschicht, in der sich wesentlich mehr als zwei VMs 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 Resilienzbereitstellungsfunktionalität hat Azure Skalierungssätze für virtuelle Computer mit flexibler Orchestrierung für SAP-Workload eingeführt. Der Skalierungssatz für virtuelle Computer stellt eine logische Gruppierung von plattformverwalteten virtuellen Computern bereit. Die flexible Orchestrierung des Skalierungssatzes virtueller Computer bietet die Möglichkeit, den Skalierungssatz innerhalb einer Region zu erstellen oder über Verfügbarkeitszonen hinweg zu erstrecken. Beim Erstellen der flexiblen Skalierung in einer Region mit platformFaultDo Standard Count>1 (FD>1) würden die im Skalierungssatz bereitgestellten VMs über die angegebene Fehleranzahl verteilt Standard in derselben Region. Andererseits würde das Erstellen des flexiblen Skalierungssatzes über Verfügbarkeitszonen hinweg mit platformFaultDo Standard Count=1 (FD=1) die virtuellen Computer über verschiedene Zonen verteilen, und der Skalierungssatz würde auch virtuelle Computer über verschiedene Fehlerbereiche verteilen Standard innerhalb jeder Zone auf bestem Aufwand. Für SAP-Workload werden nur flexible Skalierungssätze mit FD=1 unterstützt. Der Vorteil der Verwendung flexibler Skalierungssätze mit FD=1 für die domänenübergreifende Bereitstellung anstelle der herkömmlichen Bereitstellung der Verfügbarkeitszone besteht darin, dass die mit dem Skalierungssatz bereitgestellten VMs über verschiedene Fehlersätze verteilt werden Standard innerhalb der Zone auf optimale Weise verteilt werden. Weitere Informationen finden Sie im Bereitstellungshandbuch für flexible Skalierungssätze für SAP-Workload.

Überlegungen zur Bereitstellung über Verfügbarkeitszonen hinweg

Beachten Sie Folgendes, wenn Sie Verfügbarkeitszonen verwenden:

  • Die maximale Roundtrip-Netzwerklatenz zwischen Azure-Verfügbarkeitszonen ist im Dokument Regionen und Verfügbarkeitszonen angegeben.
  • 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.
  • Verfügbarkeitszonen sind keine ideale Lösung zur Notfallwiederherstellung. Naturkatastrophen können in ganzen Regionen weitreichende Schäden verursachen, einschließlich schwerer Schäden an der Energieinfrastruktur. Die Abstände zwischen verschiedenen Zonen sind möglicherweise nicht ausreichend für eine ordnungsgemäße Lösung für die Notfallwiederherstellung.
  • Die verfügbarkeitszonenübergreifende Netzwerklatenz ist nicht für alle Azure-Regionen gleich. In einigen Fällen können Sie die SAP-Anwendungsschicht in verschiedenen Zonen bereitstellen und ausführen, da die Netzwerklatenz von einer Zone zur aktiven DBMS-VM akzeptabel ist. In einigen Azure-Regionen kann die Latenzzeit jedoch zwischen der aktiven DBMS-VM und der SAP-Anwendungsinstanz bei Bereitstellung in verschiedenen Zonen für SAP-Geschäftsprozesse nicht akzeptabel sein. In diesen Fällen müssen sich die Bereitstellungsarchitekturen für eine Aktiv/Aktiv-Architektur für die Anwendung und eine Aktiv/Passiv-Architektur mit zu hoher zonenübergreifende Latenz unterscheiden.
  • 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 DBMS-Instanzen, bei denen eine synchrone Replikation erforderlich ist. Je höher die Netzwerklatenz, desto höher die Wahrscheinlichkeit einer Auswirkung auf die Skalierbarkeit Ihrer Workload.
    • Bei dem Unterschied in der Netzwerklatenz zwischen einem virtuellen Computer, der eine SAP-Dialoginstanz in derselben Zone wie die aktive DBMS-Instanz ausführt, und einer ähnlichen VM 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 der DBMS oder in einer anderen Zone ausgeführt werden.

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 DBMS-Schicht und die zentralen Dienste zonenübergreifend bereitstellen, gleichzeitig die SAP-Anwendungsschicht mit Hilfe von Verfügbarkeitsgruppen bereitstellen und dennoch große Nähe der VMs 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.

Die ideale Kombination von Verfügbarkeitszonen

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 DBMS-Ebene werden auf zwei Zonen verteilt. Die VMs, auf denen die SAP-Anwendungsschicht ausgeführt wird, werden gleichmäßig auf dieselben beiden Zonen aufgeteilt. Wenn für eine DBMS- 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 die aktive DBMS-VM und die Anwendungsinstanzen ausgeführt werden. Diese Architektur ist die bevorzugte Architektur für die zonenübergreifende Bereitstellung.
  • Aktiv/Passiv Das VM-Paar zur Ausführung von ASCS/SCS und das VM-Paar zur Ausführung der DBMS-Ebene werden auf zwei Zonen verteilt. Die VMs, auf denen die SAP-Anwendungsschicht ausgeführt wird, werden in einer der Verfügbarkeitszonen bereitgestellt. Die Anwendungsschicht wird in der Zone ausgeführt, in der sich die aktive ASCS/SCS- und DBMS-Instanz befindet. Verwenden Sie diese Bereitstellungsarchitektur, wenn die Netzwerklatenz in den verschiedenen Zonen zur Ausführung der über die Zonen verteilte Anwendungsschicht zu groß ist. Stattdessen muss die Anwendungsschicht in der Zone ausgeführt werden, in der sich die aktive ASCS/SCS- und DBMS-Instanz befindet. Wenn für eine ASCS/SCS- oder DBMS-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. In einigen Azure-Regionen ist diese Architektur die einzige geeignete Architektur, wenn Verfügbarkeitszonen verwendet werden sollen. Wenn für Sie die potenziellen Auswirkungen eines Failovers von ASCS/SCS- oder DBMS-VMs auf die sekundäre Zone nicht akzeptabel ist, sollten Sie besser bei der Bereitstellung von Verfügbarkeitsgruppen bleiben.

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 DBMS-Instanz 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 DBMS-VMs in den beiden anderen DBMS-Zonen, die Sie ausgewählt haben.
  • Verwenden Sie niping als Messtool. Dieses Tool von SAP wird in den SAP-Supporthinweisen 500235 und 1100926 beschrieben. 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 DBMS-Ebene.
  • 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.)

Berücksichtigen Sie bei diesen Entscheidungen auch die SAP-Empfehlungen zur Netzwerklatenz im SAP-Hinweis 1100926.

Wichtig

Ihre Messungen und Entscheidungen gelten für das Azure-Abonnement, mit dem Sie diese Messungen vorgenommen haben. Wenn Sie ein anderes Azure-Abonnement verwenden, kann die Zuordnung der aufgelisteten Zonen für ein anderes Azure-Abonnement abweichen. Infolgedessen müssen Sie die Messungen wiederholen oder mithilfe des Skripts Avzone Mapping die Zuordnung des neuen Abonnements zum alten Abonnement ermitteln.

Wichtig

Es ist anzunehmen, dass die Ergebnisse der oben durchgeführten Messungen in jeder Azure-Region, die Verfügbarkeitszonen unterstützt, unterschiedlich ausfallen. Auch wenn sich Ihre Anforderungen an die Netzwerklatenz nicht ändern, müssen Sie möglicherweise in verschiedenen Azure-Regionen unterschiedliche Bereitstellungsstrategien einsetzen, da die Netzwerklatenz zwischen Zonen unterschiedlich sein kann. In einigen Azure-Regionen kann die Netzwerklatenz zwischen den drei verschiedenen Zonen stark unterschiedlich ausfallen. In anderen Regionen kann die Netzwerklatenz zwischen den drei verschiedenen Zonen einheitlicher sein. Die Aussage, dass immer eine Netzwerklatenz zwischen 1 und 2 Millisekunden vorliegt, ist nicht richtig. Die Netzwerklatenz über Verfügbarkeitszonen hinweg in Azure-Regionen kann nicht verallgemeinert werden.

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 Replikation in die Warteschlange einreiht, wird zwischen zwei Zonen bereitgestellt. Dies gilt auch für die DBMS-Ebene, die über dieselben 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 und Ihre synchrone DBMS-Replikation akzeptabel ist. Sie sollten außerdem sicherstellen, dass das Delta zwischen der Netzwerklatenz in den ausgewählten Zonen und der zonenübergreifenden Netzwerklatenz nicht zu groß ist.

Es liegt in der Natur der SAP-Architektur, dass Benutzer und Batchaufträge in den verschiedenen Anwendungsinstanzen ausgeführt werden können,sofern Sie sie nicht anders konfiguriert haben. Das hat bei der Aktiv/Aktiv-Bereitstellung die Nebenwirkung, dass Batchaufträge von jeder SAP-Anwendungsinstanz ausgeführt werden können, unabhängig davon, ob sie in derselben Zone wie das aktive DBMS 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 Netzwerkverkehr 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 DBMS-Instanz 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.

In den folgenden Azure-Regionen sollte eine solche Aktiv/Aktiv-Bereitstellung ohne signifikante Laufzeit- und Durchsatzunterschiede innerhalb der Anwendungsschicht in verschiedenen Verfügbarkeitszonen möglich sein:

  • Australien, Osten (zwei der drei Zonen)
  • Brasilien, Süden (alle drei Zonen)
  • Indien, Mitte (alle drei Zonen)
  • USA, Mitte (alle drei Zonen)
  • Asien, Osten (alle drei Zonen)
  • USA, Osten (zwei der drei Zonen)
  • USA, Osten 2 (alle drei Zonen)
  • Deutschland, Westen-Mitte (alle drei Zonen)
  • Israel Central (alle drei Zonen)
  • Italien Nord (zwei der drei Zonen)
  • Südkorea, Mitte (alle drei Zonen)
  • Polen Zentral (alle drei Zonen)
  • Katar, Mitte (alle drei Zonen)
  • Europa, Norden (alle drei Zonen)
  • Norwegen Ost (zwei der drei Zonen)
  • Südafrika Nord (zwei der drei)
  • USA, Süden-Mitte (alle drei Zonen)
  • Asien, Südosten (alle drei Zonen)
  • Schweden, Mitte (alle drei Zonen)
  • Schweiz, Norden (alle drei Zonen)
  • VAE, Norden (alle drei Zonen)
  • Vereinigtes Königreich, Süden (zwei der drei Zonen)
  • Europa, Westen (zwei der drei Zonen)
  • USA, Westen 2 (alle drei Zonen)
  • USA, Westen 3 (alle drei Zonen)

Durch die bereitgestellte Regionsliste werden Sie als Kunde nicht davon entbunden, anhand von Tests Ihrer Workload zu entscheiden, ob eine Aktiv/Aktiv-Bereitstellungsarchitektur möglich ist.

In den folgenden Azure-Regionen ist eine zonenübergreifende Aktiv/Aktiv-SAP-Bereitstellungsarchitektur eventuell nicht möglich:

  • Kanada, Mitte
  • Frankreich, Mitte
  • Japan, Osten

Für Ihre individuelle Workload kann dies jedoch funktionieren. Daher sollten Sie Tests durchführen, bevor Sie sich für eine Architektur entscheiden. Azure arbeitet kontinuierlich daran, die Qualität und Latenz seiner Netzwerke zu verbessern. Messungen, die vor Jahren durchgeführt wurden, spiegeln möglicherweise nicht mehr die aktuellen Bedingungen wider.

Je nachdem, welche Abweichungen Sie bei der Laufzeit in Kauf nehmen können, kommen möglicherweise auch andere, nicht aufgeführte Regionen in Frage.

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

Active/Active zone deployment

Die folgenden Überlegungen gelten für diese Konfiguration:

Wichtig

In diesem Aktiv/Aktiv-Szenario fallen Gebühren für den zonenübergreifenden Datenverkehr an. Lesen Sie das Dokument Preisdetails zur Bandbreite. Die Datenübertragung zwischen der SAP-Anwendungsschicht und der SAP-DBMS-Schicht ist recht kostenintensiv. Daher kann das Aktiv/Aktiv-Szenario die Kosten erhöhen.

Aktiv/Passiv-Bereitstellung

Falls Sie kein akzeptables Delta zwischen der Netzwerklatenz in einer Zone und der Latenz des zonenübergreifenden Netzwerverkehrs feststellen, können Sie eine Architektur bereitstellen, die aus Sicht der SAP-Anwendungsschicht einen Aktiv/Passiv-Charakter aufweist. Sie definieren eine aktive Zone – die Zone, in der Sie die vollständige Anwendungsschicht bereitstellen und versuchen, die aktive DBMS- und 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 DBMS-Instanz ausgeführt wird bzw. das nicht der Fall ist.

In den folgenden Azure-Regionen kann diese Art von zonenübergreifender Bereitstellungsarchitektur von Vorteil sein:

  • Kanada, Mitte
  • Frankreich, Mitte
  • Japan, Osten
  • Norwegen, Osten
  • Südafrika, Norden

Das grundlegende Layout der Architektur sieht folgendermaßen aus:

Active/Passive zone deployment

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 DBMS- und SAP Central Services-Instanzen in derselben Zone zu halten wie Ihre bereitgestellte Anwendungsschicht. Bei einem Failover der SAP Central Services- oder DBMS-Instanz 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 DBMS-Ebene müssen Azure Load Balancer-Instanzen der Standard-SKU sein. Der Load Balancer Basic funktioniert nicht zonenübergreifend.
  • 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 Storage Premium, SSD Ultra-Speicher oder ANF unterstützen keinen zonenübergreifenden Speicherreplikationstyp. Bei DBMS-Bereitstellungen greifen wir auf Datenbankmethoden zurück, um Daten zonenübergreifend zu replizieren.
  • 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. Dokumente, die diese Fälle abdecken, sind:
  • 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 VMs in der (aus DBMS-Perspektive) 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, 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.

Hinweis

Es wird empfohlen, eine solche Konfiguration nur unter bestimmten Umständen zu verwenden. Beispielsweise können Sie sie verwenden, wenn Daten die Azure-Region aus Sicherheits- oder Compliancegründen nicht verlassen dürfen.

Hier ist ein Beispiel für eine solche Konfiguration:

Combined high-availability DR in zones

Die folgenden Überlegungen gelten für diese Konfiguration:

  • Entweder nehmen Sie an, dass eine signifikante Distanz zwischen den Einrichtungen, die eine Verfügbarkeitszone hosten, liegt, oder Sie sind auf eine bestimmte Azure-Region beschränkt. 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 DBMS- und SAP Central Services-Instanzen in derselben Zone zu halten wie Ihre bereitgestellte Anwendungsebene. Bei einem Failover der SAP Central Services- oder DBMS-Instanz 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.
  • In den virtuellen Computern, auf denen die aktiven QA-Anwendungsinstanzen ausgeführt werden, sollten Produktionsanwendungsinstanzen vorinstalliert sein.
  • 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 DBMS-Ebene müssen Azure Load Balancer-Instanzen der Standard-SKU sein. Der Load Balancer Basic funktioniert nicht zonenübergreifend.
  • 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 Storage Premium, SSD Ultra-Speicher oder ANF unterstützen keinen zonenübergreifenden Speicherreplikationstyp. Bei DBMS-Bereitstellungen greifen wir auf Datenbankmethoden zurück, um Daten zonenübergreifend zu replizieren.
  • 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. Dokumente, die diese Fälle abdecken, sind:
  • 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: