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. Sie stellt Funktionen in den SAP-Systemen wieder her, wenn geplante und ungeplante Ausfallzeiten der Azure-physischen Serverinfrastruktur und der insgesamt zugrunde liegenden Azure-Plattform vorhanden sind.

  • 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 sapinst-integrierte SAP-Hochverfügbarkeitskonfiguration für Linux wie für Windows. 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 einem einzigen virtuellen Computer von 99,9 % mit Premium-Speicher. 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) *...

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 virtuellen Computer mit mindestens zwei Instanzen, die in demselben Verfügbarkeitssatz bereitgestellt wurden, garantieren wir, dass Sie über eine Verbindung zwischen virtuellen Computern und mindestens 99,95 % der Zeit verfügen.

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.

  • Update do Standard s garantiert, dass mehrere VMs während der geplanten Standard Tenance einer Azure-Infrastruktur nicht gleichzeitig neu gestartet werden. Es wird immer nur jeweils ein virtueller Computer neu gestartet.
  • Fehler Standard garantieren, dass VMs auf Hardwarekomponenten bereitgestellt werden, die keine gemeinsame Stromversorgung und einen Netzwerkswitch gemeinsam nutzen. 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 virtueller Computer in Azure mithilfe des Verfügbarkeitssatzes.

Azure-Verfügbarkeitszonen

Azure ist dabei, ein Konzept von Azure Verfügbarkeitszonen in verschiedenen Azure-Regionen zu einführen. 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.

Bei der Verwendung von Verfügbarkeitszonen gibt es einige Dinge, die Sie berücksichtigen sollten. 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ügbarkeitssätzen 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 Load Balancer Standard-SKU verwenden.
  • Azure Verfügbarkeitszonen bieten keine Garantien für einen bestimmten Abstand 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 gibt Fälle, in denen Sie als Kunde die SAP-Anwendungsschicht, die über verschiedene Zonen hinweg bereitgestellt wird, ausführen können, da die Netzwerklatenz von einer Zone bis zur aktiven DBMS-VM weiterhin von einer Geschäftsprozesswirkung aus akzeptabel ist. Es kann jedoch Kundenszenarien geben, in denen die Latenz zwischen der aktiven DBMS-VM in einer Zone und einer SAP-Anwendungsinstanz in einer VM in einer anderen Zone zu aufdringlich 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 von Azure verwalteten Datenträgern ist für die Bereitstellung in Azure Verfügbarkeitszonen obligatorisch.

Skalierungssatz für virtuelle Maschinen mit flexibler Orchestrierung

In Azure bietet Virtual Machine Scale Sets mit flexibler Orchestrierung eine Möglichkeit, hohe Verfügbarkeit für SAP-Workloads zu erreichen, ähnlich wie andere Bereitstellungsframeworks wie Verfügbarkeitssätze und Verfügbarkeitszonen. Mit einem flexiblen Skalierungssatz können VMs über verschiedene Verfügbarkeitszonen verteilt werden und Fehler tun Standard, sodass sie eine geeignete Option für die Bereitstellung hochverfühbarer SAP-Workloads bietet.

Der Skalierungssatz virtueller Maschinen mit flexibler Orchestrierung bietet die Flexibilität, 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 VMs über verschiedene Zonen verteilen, und der Skalierungssatz würde auch VMs über verschiedene Fehlerfehler hinweg verteilen Standard innerhalb jeder Zone auf best-effort-Basis. 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. Um die Einschränkungen zu vermeiden, die mit der Verwendung der Näherungsplatzierungsgruppe verbunden sind, um die Verfügbarkeit von virtuellen Computern in allen Azure-Rechenzentren oder unter jeder Netzwerkstachel sicherzustellen, empfiehlt es sich, SAP-Workload über Verfügbarkeitszonen hinweg mithilfe eines flexiblen Skalierungssatzes mit FD=1 bereitzustellen. Diese Bereitstellungsstrategie stellt sicher, dass in jeder Zone bereitgestellte VMs nicht auf ein einzelnes Rechenzentrum oder eine Netzwerkstachel beschränkt sind, und alle SAP-Systemkomponenten, z. B. Datenbanken, ASCS/ERS und Anwendungsebene, sind auf Zonalebene beschränkt.

Für die neue BEREITSTELLUNG von SAP-Workload in allen Verfügbarkeitszonen empfehlen wir daher, flexible Skalierungssätze mit FD=1 zu verwenden. Weitere Informationen finden Sie im Skalierungssatz für den VIRTUELLEN Computer für das SAP-Workloaddokument .

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 Standard Anz virtueller Computer 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

Verwaltete Datenträger sind ein Ressourcentyp in Azure Resource Manager, eine empfohlene Speicheroption anstelle von virtuellen Festplatten (VHDs), die in Azure-Speicherkonten gespeichert sind. Verwaltete Datenträger richten sich automatisch an eine Azure-Verfügbarkeitsgruppe des virtuellen Computers, an den sie angefügt 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 SAP-Workload

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

Funktionen Vm Scale Set mit flexibler Orchestrierung (FD=1) Verfügbarkeitszone Verfügbarkeitsgruppe
Bereitstellungsverhalten Instanzen landen über 1, 2 oder 3 Verfügbarkeitszonen und verteilt über unterschiedliche Racks innerhalb jeder Zone auf best-effort-Basis Instanzen landen über 1, 2 oder 3 Verfügbarkeitszonen Instanzen landen innerhalb der Region und verteilt über verschiedene Fehler/Aktualisierungen Standard
Zuweisen von VM- und verwalteten Datenträgern zu einer bestimmten Verfügbarkeitszone Ja Ja Nein
Fehler Standard – Maximale Verbreitung (Azure verteilt Instanzen maximal) Ja Nein Ja, basierend auf der Fehleranzahl Standard die während der Erstellung definiert wurden.
Fehler beim Berechnen des Speichers Standard Ausrichtung Nein Nein Ja
Kapazitätsreservierung Ja (Kapazitätsreservierung auf VM-Ebene zuweisen) Ja Nein

Hinweis

Bereitstellungsoptionen für hohe Verfügbarkeit für SAP-Workload

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

Systemtyp Über verschiedene Zonen in einer Region hinweg In einer Singezone eines Bereichs In einer Region ohne Zonen
Hochverfügbarkeits-SAP-System Flexible Skalierungssatz mit FD=1 Verfügbarkeitssätze mit Näherungsplatzierungsgruppen Verfügbarkeitsgruppen
Verfügbarkeitssätze und Verfügbarkeitszonen mit Näherungsplatzierungsgruppen Flexibler Skalierungssatz mit FD=1 (nur eine Zone auswählen) Flexibler Skalierungssatz mit FD=1 (keine Zonen sind definiert)
Verfügbarkeitszonen Verfügbarkeitsgruppen
  • Bereitstellung in verschiedenen Zonen in einer Region: Für die höchste Verfügbarkeit sollten SAP-Systeme in verschiedenen Zonen in einer Region bereitgestellt werden. Dadurch wird sichergestellt, dass das SAP-System, wenn eine Zone nicht verfügbar ist, weiterhin in einer anderen Zone verfügbar ist. Wenn Sie neue SAP-Workload über Verfügbarkeitszonen hinweg bereitstellen, empfiehlt es sich, flexible vm-Skalierungen zu verwenden, die mit der FD=1-Bereitstellungsoption festgelegt sind. Sie können mehrere virtuelle Computer in verschiedenen Zonen in einer Region bereitstellen, ohne sich Gedanken über Kapazitätsbeschränkungen oder Platzierungsgruppen machen zu müssen. Das Skalierungssatzframework stellt sicher, dass die mit dem Skalierungssatz bereitgestellten VMs über verschiedene Fehler verteilt werden Standard innerhalb der Zone auf optimale Weise. Alle hoch verfügbaren SAP-Komponenten wie SAP ASCS/ERS, SAP-Datenbanken werden über verschiedene Zonen verteilt, während mehrere Anwendungsserver in jeder Zone über verschiedene Fehler verteilt werden Standard auf Best-Effort-Basis.
  • Bereitstellung in einer einzelnen Zone einer Region: Um Ihr hochverfügbarkeits-SAP-System 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ügbarkeitssätze mit Bereitstellungsoption für Näherungsgruppen zu verwenden. Mit diesem Ansatz können Sie alle SAP-Systemkomponenten in einer einzigen Verfügbarkeitszone gruppieren und sicherstellen, dass die virtuellen Computer innerhalb des Verfügbarkeitssatzes auf verschiedene Fehler und Aktualisierungen verteilt sind Standard s. Während diese Bereitstellung die Berechnung auf die Fehler bei der Speicherung ausgerichtet ist Standard ist die Näherung nicht garantiert. Da diese Bereitstellungsoption jedoch regional ist, wird Azure Site Recovery nicht für die Notfallwiederherstellung in Zone-zu-Zone 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 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ügbarkeitssätze zu verwenden. Diese Option bietet Redundanz und Fehlertoleranz, indem VMs in verschiedene Fehler do Standard s und Update do Standard s 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 hängt von Ihren speziellen Anforderungen und Umgebungen ab.

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

Wenn Sie sich entscheiden, keine Funktionen wie WSFC oder Pacemaker unter Linux zu verwenden (unterstützt für SUSE Linux Enterprise Server 12 und höher und Red Hat Enterprise Linux 7 und höher), wird der Azure-VM-Neustart verwendet. Sie stellt Funktionen in den SAP-Systemen wieder her, wenn geplante und ungeplante Ausfallzeiten der Azure-physischen Serverinfrastruktur und der insgesamt zugrunde liegenden Azure-Plattform vorhanden sind.

Weitere Informationen zum Ansatz finden Sie unter Verwenden des NEUSTARTs der Azure-Infrastruktur-VM, um eine höhere Verfügbarkeit des SAP-Systems zu erzielen.

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 (flexibler Skalierungssatz mit FD=1, Verfügbarkeitszone oder Verfügbarkeitssatz) müssen Sie Ihre SAP-Anwendungsserverinstanzen entsprechend verteilen, um Redundanz zu erzielen.

  • Flexibler Skalierungssatz mit platformFaultDo Standard Count=1 (FD=1): SAP-Anwendungsserver, die mit flexiblem Skalierungssatz (FD=1) bereitgestellt werden, verteilen die virtuellen Computer über verschiedene Verfügbarkeitszonen, und die Skalierungssätze würden auch VMs über verschiedene Fehler do Standard s innerhalb jeder Zone verteilt. Dadurch wird sichergestellt, dass die sap-Anwendungsserver, die in einer anderen Zone bereitgestellt werden, weiterhin verfügbar sind, wenn eine Zone nicht verfügbar ist.
  • Verfügbarkeitszone: Sap-Anwendungsserver, die über Verfügbarkeitszonen bereitgestellt werden, stellen sicher, dass VMs über verschiedene Zonen verteilt sind, um Redundanz zu erzielen. Dadurch wird sichergestellt, dass die sap-Anwendungsserver, die in einer anderen Zone bereitgestellt werden, weiterhin verfügbar sind, wenn eine Zone nicht verfügbar ist. Weitere Informationen finden Sie unter SAP-Workloadkonfigurationen mit Azure Verfügbarkeitszonen
  • Verfügbarkeitssatz: SAP-Anwendungsserver, die im Verfügbarkeitssatz bereitgestellt werden, stellen sicher, dass VMs über verschiedene Fehler verteilt werden Standard s und Aktualisierungen Standard s. Stellen Sie beim Platzieren von VMs über verschiedene Updates hinweg sicher Standard, dass VMs während geplanter Standard Unterbrechungen nicht gleichzeitig aktualisiert werden. Während das Platzieren von VMs in unterschiedlichen Fehlern Standard sicherstellen, dass der virtuelle Computer vor Hardwareausfällen oder Stromunterbrechungen innerhalb eines Rechenzentrums geschützt ist. Aber die Anzahl der Fehler und Aktualisierungen Standard, die Sie in Azure-Verfügbarkeitssatz innerhalb einer Azure-Skalierungseinheit verwenden können, ist begrenzt. Wenn Sie einem einzelnen Verfügbarkeitssatz weiterhin VMs hinzufügen, würden zwei oder mehr virtuelle Computer letztendlich in demselben Fehler oder Update enden Standard. 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 Verfügbarkeitssatz verwendet werden, ist es wichtig zu erkennen, dass das Azure-Speicherkonto zu einem einzigen Fehlerpunkt wird. Daher müssen mindestens zwei Azure-Speicherkonten verwendet werden, in denen mindestens zwei virtuelle Computer verteilt werden. 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 entsprechende 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 SAP ASCS/SCS-Instanzclusterings von der Betriebssystemverteilung und dem verwendeten Speichertyp ab. Es wird empfohlen, die geeignete Lösung gemäß Ihrem spezifischen Betriebssystemclusterframework 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:

Hohe Verfügbarkeit der DBMS-Instanz

In einem SAP-System werden auch die DBMS-Server als Einzelner Fehlerpunkt verwendet. 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 SAP-System verwendet wird. Befolgen Sie basierend auf Ihrer Datenbank die Richtlinien, um eine hohe Verfügbarkeit ihrer Datenbank zu erzielen.

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