Freigeben über

Architektur und Szenarien für die Hochverfügbarkeit von SAP NetWeaver

  • Artikel

Terminologiedefinitionen

Hochverfügbarkeit: Bezieht sich auf eine Reihe von Technologien, die IT-Störungen minimieren, indem sie die Geschäftskontinuität von IT-Diensten durch redundante, fehlertolerante oder durch Failover geschützte Komponenten innerhalb desselben Rechenzentrums bereitstellen. In unserem Fall befindet sich das Rechenzentrum in einer Azure-Region.

Notfallwiederherstellung: Bezieht sich ebenfalls auf die Minimierung der Unterbrechung und Wiederherstellung von IT-Diensten, jedoch über verschiedene Rechenzentren, die möglicherweise Hunderte Kilometer voneinander entfernt liegen. In unserem Fall können die Rechenzentren in verschiedenen Azure-Regionen innerhalb derselben geopolitischen Region oder an Standorten liegen, die von Ihnen als Kunde eingerichtet wurden.

Übersicht über Hochverfügbarkeit

Hochverfügbarkeit von SAP in Azure kann in drei Typen unterteilt werden:

  • Hochverfügbarkeit der Azure-Infrastruktur:

    Hochverfügbarkeit kann beispielsweise Compute (VMs), Netzwerk und Speicher und die damit verbundenen Vorteile zur Verbesserung der SAP-Anwendungsverfügbarkeit umfassen.

  • Verwenden des VM-Neustarts der Azure-Infrastruktur zum Schutz von SAP-Anwendungen:

    Wenn Sie keine Funktionen wie Windows Server-Failoverclustering (WSFC) oder Pacemaker unter Linux verwenden möchten, wird die Azure-VM neu gestartet. Dies stellt die Funktionalität in den SAP-Systemen wieder her, wenn geplante und ungeplante Downtimes der physischen Azure-Serverinfrastruktur und der zugrunde liegenden Azure-Plattform auftreten.

  • Hochverfügbarkeit von SAP-Anwendungen:

    Für eine vollständige Hochverfügbarkeit von SAP-Systemen müssen Sie alle kritischen SAP-Systemkomponenten schützen. Beispiel:

    • Redundante SAP-Anwendungsserver
    • Einmalig auftretende Komponenten. Beispiel: eine Single Point of Failure-Komponente (SPOF) wie z.B. eine SAP ASCS/SCS-Instanz oder ein Datenbank-Managementsystem (DBMS).

Die Hochverfügbarkeit von SAP in Azure unterscheidet sich von der Hochverfügbarkeit von SAP in einer lokalen physischen oder virtuellen Umgebung.

Es gibt keine in SAP-Instanzen integrierte SAP-Hochverfügbarkeitskonfiguration für Linux, wie dies für Windows der Fall ist. Weitere Informationen zur lokalen Hochverfügbarkeit von SAP unter Linux finden Sie unter Partnerinformationen zur Hochverfügbarkeit.

Hochverfügbarkeit der Azure-Infrastruktur

SLA für virtuelle Einzelinstanzcomputer

Derzeit gibt es eine SLA mit 99,9 % für eine einzelne VM mit Storage Premium. Sie können das Produkt aus den verschiedenen verfügbaren Azure-Vereinbarungen zum Servicelevel erstellen, um einen Eindruck von der Hochverfügbarkeit eines einzelnen virtuellen Computers zu erhalten.

Als Grundlage für die Berechnung werden 30 Tage pro Monat bzw. 43.200 Minuten verwendet. Eine Ausfallzeit von 0,05 % entspricht beispielsweise 21,6 Minuten. Wie üblich wird die Verfügbarkeit der verschiedenen Dienste auf folgende Weise berechnet:

(Verfügbarkeitsdienst Nr. 1/100) x (Verfügbarkeitsdienst Nr. 2/100) x (Verfügbarkeitsdienst Nr. 3/100) *…

Zum Beispiel:

(99,95/100) x (99,9/100) x (99,9/100) = 0,9975 oder eine Gesamtverfügbarkeit von 99,75 %.

Mehrere Instanzen von virtuellen Computern in derselben Verfügbarkeitsgruppe

Für alle VMs, die über mindestens zwei bereitgestellte Instanzen in derselben Verfügbarkeitsgruppe verfügen, garantieren wir die Verfügbarkeit der VM-Verbindung mit mindestens einer Instanz während mindestens 99,95 % der Zeit.

Wenn mehrere virtuelle Computer Teil derselben Verfügbarkeitsgruppe sind, wird jeder virtuelle Computer in einer Verfügbarkeitsgruppe durch die zugrunde liegende Azure-Plattform einer Updatedomäne und einer Fehlerdomäne zugewiesen.

  • Updatedomänen garantieren, dass nicht mehrere VMs gleichzeitig während einer geplanten Wartung der Azure-Infrastruktur neu gestartet werden. Es wird immer nur jeweils ein virtueller Computer neu gestartet.
  • Fehlerdomänen garantieren, dass VMs auf Hardwarekomponenten bereitgestellt werden, die keine gemeinsame Stromquelle und keinen gemeinsamen Netzwerkswitch verwenden. Bei ungeplanten Ausfallzeiten des Servers, des Netzwerkswitches oder der Stromquelle ist nur ein virtueller Computer betroffen.

Weitere Informationen finden Sie unter Verwalten der Verfügbarkeit von VMs in Azure mithilfe von Verfügbarkeitsgruppen.

Azure-Verfügbarkeitszonen

Bei Azure wird derzeit ein Konzept von Azure-Verfügbarkeitszonen in verschiedenen Azure-Regionen ausgerollt. In Azure-Regionen, in denen Verfügbarkeitszonen angeboten werden, umfassen die Azure-Regionen mehrere Rechenzentren, die von der Stromversorgung, der Kühlung und dem Netzwerk unabhängig sind. Es werden unterschiedliche Zonen in einer einzelnen Azure-Region angeboten, um Ihnen die Bereitstellung von Anwendungen über zwei oder drei Verfügbarkeitszonen hinweg zu ermöglichen. Unter der Annahme, dass sich Probleme an Stromversorgungsquellen und/oder Netzwerken nur auf die Infrastruktur einer Verfügbarkeitszone auswirkt, ist Ihre Anwendungsbereitstellung innerhalb einer Azure-Region weiterhin voll funktionsfähig. Dies kann schließlich zu einer reduzierten Kapazität führen, da einige VMs in einer Zone verloren gehen könnten. VMs in den anderen beiden Zonen werden jedoch weiterhin ausgeführt. Die Azure-Regionen, die Zonen anbieten, sind unter Azure-Verfügbarkeitszonen aufgelistet.

Für die Verwendung von Verfügbarkeitszonen müssen einige Punkte beachtet werden. Darunter befinden sich Überlegungen wie die folgenden:

  • Sie können Azure-Verfügbarkeitsgruppen nicht in einer Verfügbarkeitszone bereitstellen. Die einzige Möglichkeit zum Kombinieren von Verfügbarkeitsgruppen und Verfügbarkeitszonen sind Näherungsplatzierungsgruppen. Weitere Informationen finden Sie im Artikel Kombinieren von Verfügbarkeitsgruppen und Verfügbarkeitszonen mit Näherungsplatzierungsgruppen.
  • Sie können den Basic-Load Balancer nicht zum Erstellen von Failoverclusterlösungen auf der Grundlage von Windows-Failoverclusterdiensten oder Linux Pacemaker verwenden. Stattdessen müssen Sie die Azure-SKU Load Balancer Standard verwenden.
  • Azure-Verfügbarkeitszonen bieten keine Garantie für eine bestimmte Entfernung zwischen den verschiedenen Zonen innerhalb einer Region.
  • Die Netzwerklatenz zwischen unterschiedlichen Azure-Verfügbarkeitszonen in den verschiedenen Azure-Regionen kann sich zwischen Azure-Regionen unterscheiden. Es könnte Fälle geben, in denen Sie als Kunde die über verschiedene Zonen hinweg bereitgestellte SAP-Anwendungsebene sinnvoll ausführen können, da die Netzwerklatenz von einer Zone zur aktiven DBMS-VM im Hinblick auf die Beeinträchtigung von Geschäftsprozessen noch akzeptabel ist. Es könnte jedoch auch Kundenszenarien geben, in denen die Latenz zwischen der aktiven DBMS-VM in einer Zone und einer SAP-Anwendungsinstanz auf einer VM in einer anderen Zone zu störend und für die SAP-Geschäftsprozesse nicht akzeptabel sein kann. Daher müssen sich die Bereitstellungsarchitekturen für eine Aktiv/Aktiv-Architektur für die Anwendung und eine Aktiv/Passiv-Architektur unterscheiden, wenn die Leselatenz zu hoch ist.
  • Die Verwendung von Azure Managed Disks ist für die Bereitstellung in Azure-Verfügbarkeitszonen obligatorisch.

VM-Skalierungsgruppe mit flexibler Orchestrierung

In Azure bietet Virtual Machine Scale Sets mit flexibler Orchestrierung eine Möglichkeit, Hochverfügbarkeit für SAP-Workloads zu erreichen, ähnlich wie andere Bereitstellungsframeworks wie Verfügbarkeitsgruppen und Verfügbarkeitszonen. Mit einer flexiblen Skalierungsgruppe können VMs über verschiedene Verfügbarkeitszonen und Fehlerdomänen verteilt werden, sodass sie eine geeignete Option für die Bereitstellung hoch verfügbarer SAP-Workloads ist.

Eine VM-Skalierungsgruppe mit flexibler Orchestrierung bietet die Flexibilität, die Skalierungsgruppe innerhalb einer Region zu erstellen oder über mehrere Verfügbarkeitszonen hinweg zu verteilen. Beim Erstellen der flexiblen Skalierungsgruppe in einer Region mit „platformFaultDomainCount>1“ (FD>1) werden die in der Skalierungsgruppe bereitgestellten VMs ü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 bestmöglich auf verschiedene Fehlerdomänen innerhalb jeder 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. Um die Einschränkungen zu vermeiden, die mit der Verwendung der Näherungsplatzierungsgruppe verbunden sind, um die Verfügbarkeit von VMs in allen Azure-Rechenzentren oder unter jedem Netzwerkrückgrat sicherzustellen, empfiehlt es sich, eine SAP-Workload über Verfügbarkeitszonen hinweg mithilfe einer flexiblen Skalierungsgruppe mit FD=1 bereitzustellen. Diese Bereitstellungsstrategie stellt sicher, dass VMs, die in jeder Zone bereitgestellt werden, nicht auf ein einzelnes Rechenzentrum oder ein Netzwerkrückgrat beschränkt sind, und alle SAP-Systemkomponenten, z. B. Datenbanken, ASCS/ERS und Anwendungsebene, werden auf Zonenebene festgelegt.

Für die Bereitstellung neuer SAP-Workloads über Verfügbarkeitszonen hinweg raten wir daher zur Verwendung einer flexiblen Skalierungsgruppe mit FD=1. Weitere Informationen finden Sie im Dokument VM-Skalierungsgruppe für SAP-Workload.

Geplante und ungeplante Wartung von virtuellen Computern

Zwei Typen von Azure-Plattformereignissen können die Verfügbarkeit Ihrer virtuellen Computer beeinflussen:

  • Geplante Wartungsereignisse sind regelmäßige Updates, die Microsoft an der zugrunde liegende Azure-Plattform vornimmt. Die Updates verbessern die allgemeine Zuverlässigkeit, Leistung und Sicherheit der Plattforminfrastruktur, in der Ihre virtuellen Computer ausgeführt werden.
  • Ungeplante Wartungsereignisse treten auf, wenn die Hardware oder physische Infrastruktur, die dem virtuellen Computer zugrunde liegt, einen Ausfall verursacht. Dies kann Ausfälle des lokalen Netzwerks oder des Datenträgers oder andere Fehler auf Rackebene umfassen. Wenn ein solcher Fehler festgestellt wird, migriert die Azure-Plattform Ihren virtuellen Computer automatisch vom fehlerhaften physischen Server, der den virtuellen Computer hostet, zu einem fehlerfreien physischen Server. Ereignisse dieser Art treten selten auf, verursachen jedoch eventuell eines Neustart des virtuellen Computers.

Weitere Informationen finden Sie unter Wartung von VMs in Azure.

Azure Storage-Redundanz

Die Daten in Ihrem Speicherkonto werden stets repliziert, um Dauerhaftigkeit und Hochverfügbarkeit sicherzustellen sowie um die Azure Storage-SLA auch bei vorübergehend auftretenden Hardwareausfällen zu erfüllen.

Da Azure Storage standardmäßig drei Images der Daten beibehält, ist die Verwendung von RAID 5 oder RAID 1 für mehrere Azure-Datenträger nicht erforderlich.

Weitere Informationen finden Sie unter Azure Storage-Replikation.

Azure Managed Disks

Managed Disks ist ein Ressourcentyp in Azure Resource Manager und ist eine empfohlene Speicheroption anstelle von VHDs (Virtual Hard Disks), die in Azure-Speicherkonten gespeichert sind. Managed Disks richten sich automatisch an der Azure-Verfügbarkeitsgruppe der VM aus, mit der sie verbunden sind. Sie erhöhen die Verfügbarkeit Ihres virtuellen Computers und der Dienste, die auf ihm ausgeführt werden.

Weitere Informationen finden Sie in der Übersicht über Azure Managed Disks.

Es wird empfohlen, verwaltete Datenträger zu verwenden, da diese die Bereitstellung und Verwaltung virtueller Computer vereinfachen.

Vergleich verschiedener Bereitstellungstypen für eine SAP-Workload

Hier ist eine kurze Zusammenfassung der verschiedenen Bereitstellungstypen, die für SAP-Workloads verfügbar sind.

Features VM-Skalierungsgruppe mit flexibler Orchestrierung (FD=1) Verfügbarkeitszone Verfügbarkeitsgruppe
Bereitstellungsverhalten Instanzen landen bestmöglich über 1, 2 oder 3 Verfügbarkeitszonen hinweg und verteilt über unterschiedliche Racks innerhalb jeder Zone Instanzen landen über 1, 2 oder 3 Verfügbarkeitszonen hinweg Instanzen landen innerhalb der Region und verteilt über verschiedene Fehler-/Updatedomänen
Zuweisen von VM und Managed Disks zu einer bestimmten Verfügbarkeitszone Ja Ja No
Fehlerdomäne – Maximale Verteilung (Azure verteilt die Instanzen maximal) Ja No Ja, basierend auf der Anzahl der Fehlerdomänen, die während der Erstellung definiert wurden.
Fehlerdomänenausrichtung von Compute zu Speicher No Nein Ja
Kapazitätsreservierung Ja (Kapazitätsreservierung auf VM-Ebene zuweisen) Ja Nein

Hinweis

Bereitstellungsoptionen für Hochverfügbarkeit für eine SAP-Workload

Bei der Bereitstellung einer hochverfügbaren SAP Workload auf Azure ist es wichtig, die verschiedenen verfügbaren Bereitstellungsarten zu berücksichtigen und zu wissen, wie sie in verschiedenen Azure-Regionen angewendet werden können (z. B. zonenübergreifend, in einer einzigen Zone oder in einer Region ohne Zonen). Die folgende Tabelle zeigt mehrere Optionen für Hochverfügbarkeit für SAP-Systeme in Azure-Regionen.

Systemtyp Über verschiedene Zonen in einer Region hinweg In einer einzelnen Zone einer Region In einer Region ohne Zonen
SAP-System mit Hochverfügbarkeit Flexible Skalierungsgruppe mit FD=1 Verfügbarkeitsgruppen mit Näherungsplatzierungsgruppen Verfügbarkeitsgruppen
Verfügbarkeitsgruppen und Verfügbarkeitszonen mit Näherungsplatzierungsgruppen Flexible Skalierungsgruppe mit FD=1 (nur eine Zone auswählen) Flexible Skalierungsgruppe mit FD=1 (es sind keine Zonen definiert)
Verfügbarkeitszonen Verfügbarkeitsgruppen
  • Bereitstellung über verschiedene Zonen in einer Region hinweg: Für die höchste Verfügbarkeit sollten SAP-Systeme über verschiedene Zonen in einer Region bereitgestellt werden. Dadurch wird sichergestellt, dass das SAP-System bei Nichtverfügbarkeit einer Zone weiterhin in einer anderen Zone verfügbar bleibt. Wenn Sie eine neue SAP-Workload über Verfügbarkeitszonen hinweg bereitstellen, empfiehlt es sich, flexible VM-Skalierungsgruppen zu verwenden, die mit der Bereitstellungsoption FD=1 festgelegt sind. Sie können so mehrere VMs über verschiedenen Zonen in einer Region bereitstellen, ohne sich Gedanken über Kapazitätsbeschränkungen oder Platzierungsgruppen machen zu müssen. Das Skalierungsgruppenframework stellt sicher, dass die mit der Skalierungsgruppe bereitgestellten VMs bestmöglich über unterschiedliche Fehlerdomänen innerhalb der Zone verteilt werden. Alle hoch verfügbaren SAP-Komponenten wie SAP ASCS/ERS oder SAP-Datenbanken werden über verschiedene Zonen verteilt, während mehrere Anwendungsserver in jeder Zone bestmöglich über verschiedene Fehlerdomänen verteilt werden.
  • Bereitstellung in einer einzelnen Zone einer Region: Um Ihr SAP-Hochverfügbarkeitssystem regional an einem Standort mit mehreren Verfügbarkeitszonen bereitzustellen, und wenn es wichtig ist, dass sich alle Komponenten des Systems in einer einzelnen Zone befinden, wird empfohlen, Verfügbarkeitsgruppen mit der Bereitstellungsoption „Näherungsplatzierungsgruppen“ zu verwenden. Mit diesem Ansatz können Sie alle SAP-Systemkomponenten in einer einzigen Verfügbarkeitszone gruppieren und so sicherstellen, dass die VMs innerhalb der Verfügbarkeitsgruppe auf verschiedene Fehler- und Updatedomänen verteilt sind. Obwohl diese Bereitstellung Fehlerdomänen für Compute zu Speicher ausrichtet, ist die Näherung nicht garantiert. Da diese Bereitstellungsoption jedoch regional ist, wird Azure Site Recovery für die Notfallwiederherstellung von Zone zu Zone nicht unterstützt. Darüber hinaus schränkt diese Option die gesamte SAP-Bereitstellung auf ein Rechenzentrum ein, was zu Kapazitätsbeschränkungen führen kann, wenn Sie die SKU-Größe ändern oder Anwendungsinstanzen horizontal skalieren müssen.
  • Bereitstellung in einer Region ohne Zonen: Wenn Sie Ihr SAP-System in einer Region bereitstellen, in der keine Zonen vorhanden sind, wird empfohlen, Verfügbarkeitsgruppen zu verwenden. Diese Option bietet Redundanz und Fehlertoleranz, indem VMs in verschiedenen Fehlerdomänen und Updatedomänen platziert werden.

Wichtig

Es sollte beachtet werden, dass die Bereitstellungsoptionen für Azure-Regionen nur Vorschläge sind. Die am besten geeignete Bereitstellungsstrategie für Ihr SAP-System wird von Ihren speziellen Anforderungen und der Umgebung abhängen.

Verwenden der Hochverfügbarkeit der Azure-Infrastruktur zum Schutz von SAP-Anwendungen

Wenn Sie Funktionen wie WSFC oder Pacemaker unter Linux (unterstützt für SUSE Linux Enterprise Server 12 und höher sowie Red Hat Enterprise Linux 7 und höher) nicht verwenden möchten, wird der Azure-VM-Neustart genutzt. Dies stellt die Funktionalität in den SAP-Systemen wieder her, wenn geplante und ungeplante Downtimes der physischen Azure-Serverinfrastruktur und der zugrunde liegenden Azure-Plattform auftreten.

Weitere Informationen zu diesem Ansatz finden Sie unter Verwenden der VM-Neustartfunktion der Azure-Infrastruktur zum Erreichen einer höheren Verfügbarkeit des SAP-Systems.

Hochverfügbarkeit von SAP-Anwendungen in Azure IaaS

Für eine vollständige Hochverfügbarkeit von SAP-Systemen müssen Sie alle kritischen SAP-Systemkomponenten schützen. Beispiel:

  • Redundante SAP-Anwendungsserver
  • Einmalig auftretende Komponenten. Beispiel: eine Single Point of Failure-Komponente (SPOF) wie z.B. eine SAP ASCS/SCS-Instanz oder ein Datenbank-Managementsystem (DBMS).

In den nächsten Abschnitten wird das Erreichen von Hochverfügbarkeit für alle drei kritischen SAP-Systemkomponenten erläutert.

Hochverfügbarkeitsarchitektur für SAP-Anwendungsserver

Windows-Logo. Windows- und Linux-Logo Linux

Für die SAP-Anwendungsserver und -Dialoginstanzen ist meist keine spezielle Lösung für Hochverfügbarkeit erforderlich. Sie erreichen Hochverfügbarkeit durch Redundanz und durch das Konfigurieren von mehreren Dialoginstanzen in verschiedenen Instanzen von virtuellen Azure-Computern. Es müssen mindestens zwei SAP-Anwendungsinstanzen auf zwei Instanzen von virtuellen Azure-Computern installiert sein.

Je nach Bereitstellungstyp (flexible Skalierungsgruppe mit FD=1, Verfügbarkeitszone oder Verfügbarkeitssatz) müssen Sie Ihre SAP-Anwendungsserverinstanzen entsprechend verteilen, um Redundanz zu erreichen.

  • Flexible Skalierungsgruppe mit platformFaultDomainCount=1 (FD=1): SAP-Anwendungsserver, die mit einer flexiblen Skalierungsgruppe (FD=1) bereitgestellt sind, verteilen die VMs über verschiedene Zonen hinweg, und die Skalierungsgruppe würde VMs ebenfalls bestmöglich über unterschiedliche Fehlerdomänen innerhalb jeder Zone verteilen. Dadurch wird sichergestellt, dass bei Nichtverfügbarkeit einer Zone die SAP-Anwendungsserver, die in einer anderen Zone bereitgestellt sind, weiterhin verfügbar sind.
  • Verfügbarkeitszone: SAP-Anwendungsserver, die über Verfügbarkeitszonen hinweg bereitgestellt werden, stellen sicher, dass VMs über verschiedene Zonen verteilt sind, um Redundanz zu erreichen. Dadurch wird sichergestellt, dass bei Nichtverfügbarkeit einer Zone die SAP-Anwendungsserver, die in einer anderen Zone bereitgestellt sind, weiterhin verfügbar sind. Weitere Informationen finden Sie unter SAP-Workloadkonfigurationen mit Azure-Verfügbarkeitszonen
  • Verfügbarkeitsgruppe: SAP-Anwendungsserver, die in einer Verfügbarkeitsgruppe bereitgestellt werden, stellen sicher, dass VMs über verschiedene Fehlerdomänen und Updatedomänen verteilt werden. Stellen Sie beim Platzieren von VMs in verschiedenen Updatedomänen sicher, dass VMs während einer geplanten Wartungsausfallzeit nicht gleichzeitig aktualisiert werden. Durch das Platzieren von VMs in verschiedenen Fehlerdomänen wird sicherstellt, dass die VM vor Hardwarefehlern oder Stromunterbrechungen innerhalb eines Rechenzentrums geschützt ist. Die Anzahl der Fehler- und Updatedomänen, die Sie in einer Azure-Verfügbarkeitsgruppe innerhalb einer Azure-Skalierungseinheit verwenden können, ist jedoch begrenzt. Wenn Sie einer einzelnen Verfügbarkeitsgruppe immer weiter VMs hinzufügen, werden schlussendlich mindestens zwei VMs in derselben Fehler- oder Updatedomäne landen. Weitere Informationen finden Sie im Abschnitt Azure-Verfügbarkeitsgruppen des Dokuments zur Planung und Implementierung von virtuellen Azure-Computern für SAP NetWeaver.

Nur nicht verwaltete Datenträger: Wenn nicht verwaltete Datenträger mit einer Verfügbarkeitsgruppe verwendet werden, ist es wichtig zu erkennen, dass das Azure-Speicherkonto zu einem Single Point of Failure wird. Daher ist es zwingend erforderlich, mindestens zwei Azure-Speicherkonten zu besitzen, auf die mindestens zwei VMs verteilt sind. In einer idealen Konfiguration würden die Datenträger jedes virtuellen Computers, auf dem eine SAP-Dialoginstanz ausgeführt wird, in einem anderen Speicherkonto bereitgestellt werden.

Wichtig

Es wird dringend empfohlen, Azure Managed Disks für Ihre SAP-Hochverfügbarkeitsinstallationen zu verwenden. Da sich verwaltete Datenträger automatisch an der Verfügbarkeitsgruppe des virtuellen Computers ausrichten, mit der sie verbunden sind, erhöhen sie die Verfügbarkeit Ihres virtuellen Computers und der auf dem virtuellen Computer ausgeführten Dienste.

Hochverfügbarkeitsarchitektur für eine SAP ASCS/SCS-Instanz unter Windows

Windows logo. Windows

Sie können eine WSFC-Lösung zum Schützen der SAP ASCS/SCS-Instanz verwenden. Basierend auf dem Typ der Clusterfreigabekonfiguration (Dateifreigabe oder freigegebener Datenträger) können Sie auf die geeignete Lösung basierend auf Ihrem Speichertyp verweisen.

Hochverfügbarkeitsarchitektur für eine SAP ASCS/SCS-Instanz unter Linux

Linux logo. Linux

Unter Linux hängt die Konfiguration des Clusterings der SAP ASCS/SCS-Instanz von der Betriebssystemverteilung und dem verwendeten Speichertyp ab. Es wird empfohlen, die geeignete Lösung gemäß dem spezifischen Clusterframework Ihres Betriebssystems zu implementieren.

SAP NetWeaver-Multi-SID-Konfiguration für SAP ASCS/SCS-Clusterinstanzen

Windows logo. Fenster

Multi-SID wird mit WSFC über Dateifreigaben und freigegebene Datenträger unterstützt. Weitere Informationen zur Multi-SID-Hochverfügbarkeitsarchitektur unter Windows finden Sie unter:

Linux logo. Linux

Multi-SID-Clustering wird auf Linux-Pacemaker-Clustern für SAP ASCS/ERS unterstützt und ist auf fünf SAP-SIDs im selben Cluster beschränkt. Weitere Informationen zur Multi-SID-Hochverfügbarkeitsarchitektur unter Linux finden Sie unter:

Hochverfügbarkeit für eine DBMS-Instanz

In einem SAP-System ist auch das DBMS ein Single Point of Failure. Daher ist es wichtig, die Datenbank durch die Implementierung einer Hochverfügbarkeitslösung zu schützen. Die Hochverfügbarkeitslösung von DBMS variiert je nach Datenbank, die für das SAP-System verwendet wird. Befolgen Sie basierend auf Ihrer Datenbank die Richtlinien zum Erreichen von Hochverfügbarkeit für Ihre Datenbank.

Datenbank Empfehlung für die Notfallwiederherstellung
SAP HANA HANA-Systemreplikation (HSR)
Oracle Oracle Data Guard
IBM DB2 Hochverfügbarkeit und Notfallwiederherstellung (HADR)
Microsoft SQL Microsoft SQL Always On
SAP ASE ASE HADR Always On