Überblick: Hohe Verfügbarkeit für SAP Anwendungen auf IBM Power Virtual Server

Der Betrieb von SAP auf IBM® Power® Virtual Server bietet eine konsistente Plattform für SAP HANA und herkömmliche Anwendungen, die erstklassige Leistung, Ausfallsicherheit für kritische Workloads und flexible Infrastrukturoptionen bietet.

Anhand der folgenden Informationen erfahren Sie, wie Sie Hochverfügbarkeitslösungen für SAP Systeme auf Power Virtual Server Instanzen implementieren.

SAP systemarchitektur

Die Hauptkomponenten eines SAP Systems sind wie folgt.

SAP Hana-System

Das System SAP HANA beherbergt die Mieterdatenbank, in der die Daten für die Anwendungen von SAP gespeichert sind.

SAP anwendungsserver

SAP anwendungsserver stellen die funktionalen Komponenten einer SAP S/4HANA oder einer anderen SAP Anwendungslösung bereit. Alle Anpassungs- und Anwendungsdaten werden in der Mieterdatenbank des SAP HANA Systems gespeichert.

Ein SAP Anwendungssystem wird als eine einzige Einheit installiert und konfiguriert. Es besteht aus den folgenden Anwendungsinstanzen.

  • Eine Instanz des ABAP-Systems für zentrale Dienste (ASCS-Instanz)

    • Jedes SAP Anwendungssystem umfasst eine ASCS-Instanz, die einen Message-Server und einen Enqueue-Server enthält.

  • Eine oder mehrere Anwendungsserverinstanzen (AS-Instanzen)

    • Der primäre Anwendungsserver (PAS) ist die erste AS-Instanz, die für ein ABAP-System installiert wird.
    • Zusätzliche AS-Instanzen werden als zusätzliche Anwendungsserver (AAS) bezeichnet.

Sowohl die Anwendungsserverinstanzen als auch die ASCS-Instanz benötigen Lese- und Schreibzugriff auf ein gemeinsames Dateisystem.

Gemeinsam genutztes Dateisystem : Das gemeinsame Dateisystem wird normalerweise von einem Network File System ( NFS ) Server exportiert und auf allen AS-Instanzen eingehängt.

Abbildung 1 zeigt die technischen Komponenten eines SAP Systems.

Abbildung 1. Technische Komponenten für SAP-Systeme
Technische Komponenten für SAP-Systeme

SAP überlegungen zur Hochverfügbarkeitslösung

Um eine hohe Verfügbarkeit zu gewährleisten, sollten Sie die Anwendungsserver redundant installieren. Stellen Sie mindestens zwei Anwendungsserver (PAS und AAS) bereit und konfigurieren Sie Anmeldegruppen für den Lastausgleich. Wenn ein Anwendungsserver ausfällt, werden alle aktiven Benutzersitzungen auf dieser Instanz beendet. Die Benutzer müssen sich erneut anmelden, und der Lastausgleich leitet sie zu einem anderen laufenden Anwendungsserver um.

Andere technische Komponenten wie die Datenbank SAP HANA, die ASCS-Instanz und das gemeinsam genutzte Dateisystem sind "single points of failure" und müssen geschützt werden.

SAP HANA systemschutz

Um ein SAP HANA System zu schützen, stellen Sie eine zweite SAP HANA Instanz auf einem separaten virtuellen Server bereit, aktivieren Sie die SAP HANA Systemreplikation und verwenden Sie Hochverfügbarkeits-Cluster-Software (HA) für automatisches Failover. Die Lösung hängt von der angestrebten Wiederherstellungszeit (RTO) ab.

Varianten für Hochverfügbarkeitslösungen für SAP HANA
Szenario Typische RTO Kommentar
Leistungsoptimiert Ein paar Minuten Dieses Szenario wird standardmäßig verwendet, es sei denn, es gelten besondere Anforderungen.
Aktiv/Aktiv (Lesen aktiviert) Ein paar Minuten In einer Active/Active-Konfiguration (mit Lesezugriff) ermöglicht die SAP HANA Systemreplikation den Lesezugriff auf Datenbankinhalte auf dem sekundären System.
Kostenoptimiert Ein paar Dutzend Minuten In einer kostenoptimierten Konfiguration läuft während des normalen Betriebs ein nicht produktives SAP HANA-System auf dem sekundären Knoten. Die Hardware-Ressourcen werden zwischen dem nicht produktiven System und dem sekundären Replikationssystem geteilt. Der Speicherverbrauch wird durch die Deaktivierung des Vorladens von Spaltentabellendaten reduziert. Während des Failover-Prozesses wird die nicht produktive Instanz angehalten, bevor der Knoten die Produktionsarbeitslast übernimmt. Dieser Ansatz erhöht die Übernahmezeit im Vergleich zu einer leistungsoptimierten Konfiguration.

SAP ASCS-Instanzschutz

Um die ASCS-Instanz zu schützen, stellen Sie eine Enqueue Replication Server (ERS)-Instanz auf einem separaten virtuellen Server bereit und verwenden Sie HA-Cluster-Software für automatisches Failover.

Installieren Sie die ASCS- und ERS-Instanzen auf einer gemeinsamen Festplatte, die an beide Server angeschlossen ist, oder auf einem NFS-Dateisystem.

Der Enqueue-Server in der ASCS-Instanz verwaltet die Sperrtabelle, während der ERS eine replizierte Kopie in seinem Speicher aufbewahrt. Wenn der Enqueue-Server neu gestartet wird, wird die Sperrtabelle anhand der ERS-Kopie neu aufgebaut, wobei alle Sperren erhalten bleiben.

Ein Neustart des Nachrichtenservers ist ausreichend, da keine Daten aufbewahrt werden müssen.

Gemeinsamer Schutz des Dateisystems

Um das gemeinsame Dateisystem zu schützen, erstellen Sie Dateispeicherfreigaben für VPC. File Storage für IBM Cloud® File Storage for VPC ist für hohe Verfügbarkeit ausgelegt und bietet Profile für zonale und regionale Bereitstellungen. Hängen Sie das Dateisystem auf Ihren Power Virtual Server-Instanzen ein, indem Sie die Schritte unter Zugriff auf Dateispeicherfreigaben für VPC ausführen.

Überblick über Hochverfügbarkeitscluster

Ein HA-Cluster verwendet virtuelle Serverinstanzen, um Hochverfügbarkeit für das System SAP zu gewährleisten. Kritische Komponenten von SAP laufen auf mehreren Instanzen innerhalb des Clusters. Obwohl die HA-Cluster-Software Ausfallzeiten nicht vollständig eliminiert, verwaltet und automatisiert sie Failover-Prozesse, um die Servicekontinuität aufrechtzuerhalten und Unterbrechungen im Falle eines Failovers zu minimieren.

Bei einer nicht geclusterten Bereitstellung führt der Ausfall einer kritischen Komponente oder der ihr zugrunde liegenden virtuellen Serverinstanz zu einem vollständigen Ausfall des Systems SAP. Der Administrator muss das Problem diagnostizieren, es beheben und die ausgefallene Komponente neu starten.

In einem HA-Cluster erkennt das System automatisch Hardware- oder Software-Fehler. Wenn ein Fehler auftritt, startet die HA-Cluster-Software die betroffene Komponente auf einer gesunden virtuellen Serverinstanz neu. Dieser als Failover bezeichnete Prozess erfolgt automatisch und ohne Eingreifen des Administrators, wodurch die Wiederherstellungszeit im Vergleich zu manuellen Wiederherstellungsverfahren verkürzt wird. Diese Einrichtung trägt dazu bei, die Hochverfügbarkeit des Systems SAP zu gewährleisten, wenn eine Anwendungskomponente oder eine virtuelle Serverinstanz ausfällt.

Schlüsselkomponenten in einem HA-Cluster

Um kritische Anwendungskomponenten auf mehreren Clusterknoten auszuführen, spielen die folgenden Elemente in der Regel eine Rolle bei der Ermöglichung hoher Verfügbarkeit:

Gemeinsam genutzter Speicher
Cluster-Knoten müssen auf denselben Speicher zugreifen. Beim Failover kann ein anderer Knoten die ausgefallene Komponente starten, da er auf die erforderlichen Dateien und Daten zugreifen kann.
Dienst-IP-Adresse
Client-Knoten kommunizieren mit der Anwendungskomponente über eine feste Dienst-IP-Adresse, die dem Knoten zugewiesen wird, auf dem die Komponente läuft.
Ressourcen-Agenten
Ein Ressourcenagent abstrahiert die Clusterverwaltung für die Anwendungskomponente. Sie definiert die Logik für das Starten, Stoppen und Überwachen der Komponente.

Clusterüberwachung und Fehlererkennung

Ein HA-Cluster verwendet einen Heartbeat-Mechanismus, um den Zustand und den Status der Knoten zu überwachen.

Die Clustersoftware muss ein Split-Brain-Szenario verhindern, bei dem die gesamte Heartbeat-Kommunikation ausfällt, während die Knoten aktiv bleiben. In dieser Situation könnten mehrere Knoten fälschlicherweise annehmen, dass sie aktiv sind, und doppelte Ressourcen starten, was zu Datenbeschädigungen führt.

Quorum und Knotenisolierung

Das Quorum bestimmt, ob die Knoten sicher weiterarbeiten und Ressourcen verwalten können. Knoten, die kein Quorum haben, müssen angehalten oder isoliert werden, um ein Split-Brain-Szenario zu verhindern.

Fechtmechanismen

Fencing isoliert Knoten ohne Quorum oder wenn eine Ressource nicht normal gestoppt werden kann, um sicherzustellen, dass die Ressource sicher auf einem anderen Knoten starten kann. Zwei gängige Umzäunungsmethoden sind:

Kraftvolles Fechten

Ein Fence_agent steuert Stromversorgungsgeräte, Hardware-Verwaltungskonsolen oder Hypervisor-APIs, um einen Knoten zwangsweise auszuschalten oder neu zu starten. Durch das Ausschalten des Knotens wird sichergestellt, dass er nicht auf gemeinsame Ressourcen zugreifen kann.

Power Fencing bietet eine zuverlässige Isolierung und stellt sicher, dass der Knoten ausgeschaltet ist. Die Steuerung erfolgt auf der Hardwareebene, unabhängig vom Zustand des Betriebssystems oder der Clustersoftware. Das Einschalten der Stromzufuhr nimmt jedoch Zeit in Anspruch, und die Konfiguration von Zaunagenten erfordert eine komplexere Einrichtung.

SBD (STONITH Block Device) Giftpfahlzaun

Ein gemeinsames Speichergerät ist für alle Knoten zugänglich. Die Knoten schreiben eine Giftpille auf die Festplatte, um einem anderen Knoten zu signalisieren, dass er abschalten soll.

Der sbd Daemon auf dem Zielknoten liest die Giftpille und löst einen Neustart oder ein Herunterfahren aus. Für diese Methode ist ein Watchdog erforderlich. Wenn der sbd Daemon sich aufhängt und die Giftpille nicht lesen kann, kann er auch den Watchdog-Timer nicht zurücksetzen. Wenn der Zeitgeber abläuft, startet der Watchdog den Knoten neu.

Überblick über Linux Hochverfügbarkeitscluster auf Power Virtual Server

Clusterknoten in Power Virtual Server können in einem einzigen Arbeitsbereich innerhalb einer Zone oder in zwei Arbeitsbereichen in verschiedenen Zonen laufen.

Die Netzarchitektur hängt vom jeweiligen Bereitstellungsmodell ab. In einem einzelnen Arbeitsbereich kann ein Subnetz alle Clusterknoten umfassen. Power Virtual Server erlaubt es jedoch nicht, dass ein Subnetz mehrere Arbeitsbereiche umfasst. Folglich kann der herkömmliche IPaddr2 Ressourcen-Agent nicht verwendet werden, um eine feste Service-IP für alle Arbeitsbereiche zuzuweisen.

Die Ressourcenagenten powervs-move-ip und powervs-subnet verwalten zusätzliche Subnetze oder Netzwerkrouten, wenn Clusterknoten über mehrere Arbeitsbereiche verteilt sind.

Tabelle 2 vergleicht Hochverfügbarkeits-Cluster-Konfigurationen für Implementierungen mit einem Arbeitsbereich und mehreren Zonen.

Vergleich von HA-Cluster-Konfigurationen für Einzelarbeitsplatz- und Multizonenregionsbereitstellungen
Konfiguration Einzelner Arbeitsbereich Region mit mehreren Zonen
Gemeinsam genutzter Blockspeicher Power Virtual Server bände nicht zutreffend
Gemeinsame Dateispeicherung Dateispeicherfreigaben für VPC (zonal) Dateispeicherfreigaben für VPC (regional)
Fechtmittel fence_ibm_powervs (ein Vertreter) fence_ibm_powervs (ein Agent pro Arbeitsbereich)
Gemeinsamer Speicher für SBD-Fencing Power Virtual Server bände iSCSI volumes auf VPC VSIs
Ressourcen-Agent ServiceIP ipaddr2 (empfohlen), powervs_move_ip powervs_move_ip (empfohlen), powervs_subnet

Die folgenden Abbildungen veranschaulichen die Architektur eines hochverfügbaren SAP Systems.

SAP Web Dispatcher dient als Reverse Proxy für HTTP (S) Anfragen an das SAP System. Zwei SAP Web Dispatcher laufen parallel in IBM Cloud® Virtual Private Cloud s hinter einem IBM Cloud® Load Balancer. IBM Cloud® Transit Gateway verbindet die IBM Cloud VPC mit Ressourcen in Power Virtual Server Arbeitsbereichen. Geschäftskunden greifen über die Web-Dispatcher Load Balancer und SAP auf das System SAP zu.

Abbildung 2 zeigt eine Hochverfügbarkeitseinrichtung mit dem System SAP, das in einem einzelnen Power Virtual Server Arbeitsbereich installiert ist.

Mindestens zwei Anwendungsserver laufen auf virtuellen Serverinstanzen innerhalb des Arbeitsbereichs Power Virtual Server. Die Instanzverzeichnisse für die Anwendungsserver werden auf Power Virtual Server Volumes oder einer zonalen Dateispeicherfreigabe gespeichert.

Zwei Power Virtual Server Instanzen bilden einen Cluster für ASCS und ERS. ASCS- und ERS-Instanzverzeichnisse werden auf einer zonalen Dateispeicherfreigabe gespeichert. Der Ressourcen-Agent ipaddr2 verwaltet virtuelle IP-Adressen für ASCS und ERS.

Zwei weitere Power Virtual Server Instanzen bilden einen Cluster für SAP HANA. SAP HANA läuft auf beiden Instanzen mit konfigurierter Systemreplikation. SAP HANA speicherplatz wird auf Power Virtual Server Volumes gespeichert. Der ipaddr2 resource agent verwaltet die virtuelle IP für die SAP HANA primary.

Abbildung 2. SAP an Power Virtual Server HA-Architekturübersicht
SAP an Power Virtual Server HA-Architekturübersicht

Abbildung 3 zeigt eine Hochverfügbarkeitseinrichtung mit dem System SAP, das in zwei Zonen in einer Mehrzonenregion eingesetzt wird.

Redundante Anwendungsserver laufen auf virtuellen Serverinstanzen in beiden Power Virtual Server Arbeitsbereichen. Die Verzeichnisse der Anwendungsserverinstanzen werden auf Power Virtual Server Volumes oder einer regionalen Dateispeicherfreigabe gespeichert.

Zwei Power Virtual Server Instanzen über die Arbeitsbereiche hinweg bilden einen Cluster für ASCS und ERS. Ihre Instanzverzeichnisse sind auf einer regionalen Dateifreigabe gespeichert. Der Ressourcen-Agent powervs-move-ip verwaltet statische Routen und virtuelle IP-Adressen für ASCS und ERS.

Zwei weitere Power Virtual Server Instanzen bilden einen Cluster für SAP HANA. SAP HANA läuft auf beiden Instanzen mit konfigurierter Systemreplikation. SAP HANA verwendet Power Virtual Server Volumes zur Speicherung. Der powervs-move-ip resource agent verwaltet statische Routen und die virtuelle IP für die SAP HANA primary.

Abbildung 3. SAP an Power Virtual Server HA-Architekturübersicht
SAP an Power Virtual Server HA-Architekturübersicht

Überlegungen zu einem hochverfügbaren Netzwerk

Hochverfügbarkeitsstrategien für SAP Lösungen auf IBM Power Virtual Server unterscheiden sich zwischen Einzelzonen- und Multizonen-Implementierungen.

Eine Ein-Zonen-Konfiguration bietet in der Regel bessere Latenzzeiten und schnellere Failover-Zeiten, da sich alle Komponenten in derselben Zone befinden. Es ist jedoch anfälliger für Infrastrukturausfälle auf Zonenebene.

Im Gegensatz dazu werden bei einem Multizonen-Setup die Ressourcen auf verschiedene Zonen verteilt, was die Widerstandsfähigkeit gegen zonenspezifische Ausfälle erhöht und die Fehlertoleranz insgesamt verbessert. Bei der Bereitstellung in mehreren Zonen sind weitere Netzwerkaspekte zu berücksichtigen, die durch spezielle Ressourcen-Agenten angegangen werden, die im Folgenden beschrieben werden.

Wenn Sie SAP Anwendungsserver in einer Umgebung mit mehreren Zonen einsetzen, kann die Ausführung in beiden Zonen zu Latenzzeiten zwischen den Anwendungsservern und dem aktiven Datenbankserver führen. Um diese Auswirkung zu minimieren, wird empfohlen, die Anwendungsserver zusammen mit der aktiven SAP HANA Datenbankinstanz zu platzieren.

IP-Failover in Multizonen-Umgebungen

In IBM Power Virtual Server sind Subnetze mit einem einzigen Arbeitsbereich verbunden und erstrecken sich nicht über mehrere Arbeitsbereiche. Daher können die Standard-Ressourcenagenten von Linux wie z. B ipaddr2 keine IP-Ausfallsicherung über Arbeitsbereiche hinweg bieten.

Die Aufrechterhaltung der Konnektivität von IBM Cloud VPC oder einem anderen Power Virtual Server Arbeitsbereich in einer Multizonen-Regionen-Konfiguration erfordert eine spezielle Handhabung. Um die Konnektivität zwischen IBM Cloud VPC oder einem anderen Power Virtual Server Arbeitsbereich in einer Multizonenregion aufrechtzuerhalten, sind bestimmte Konfigurationsschritte erforderlich. IBM bietet zwei benutzerdefinierte Ressourcen-Agenten, um IP-Failover in diesen Szenarien zu ermöglichen.

Ressourcen-Agent: powervs-move-ip

Dieser Ressourcen-Agent verwaltet das Failover, indem er der virtuellen Serverinstanz (VSI) eine Overlay-IP-Adresse als Alias zuweist und die statischen Routen während des Takeovers aktualisiert.

Während eines Übernahmeereignisses aktualisiert der Ressourcenagent powervs-move-ip vordefinierte statische Routen in IBM Power Virtual Server und weist der virtuellen Serverinstanz eine Overlay-IP-Adresse als IP-Alias zu.

Die folgenden Abbildungen veranschaulichen dieses Szenario in einem SAP HANA System Replication-Cluster.

  • Zwei virtuelle Serverinstanzen (VSI) werden in getrennten Arbeitsbereichen bereitgestellt.
  • In jedem Arbeitsbereich wird ein privates Subnetz erstellt.
  • Die Instanzen bilden einen RHEL High Availability Add-On-Cluster mit zwei Knoten.
  • SAP HANA ist auf beiden Instanzen installiert, und die SAP HANA Systemreplikation ist konfiguriert.
  • Eine Cluster-Ressource für die Overlay-IP-Adresse wird mit dem Ressourcen-Agenten powervs-move-ip konfiguriert.

Overlay-IP-Merkmale

  • Die Overlay-IP liegt außerhalb aller CIDR-Subnetzbereiche in der Umgebung.
  • Sie wird bei der Bereitstellung nicht einer Netzwerkschnittstelle zugewiesen.
  • Zur Laufzeit konfiguriert der Ressourcen-Agent die Overlay-IP-Adresse als IP-Alias auf einem VSI-Netzwerkadapter.
  • In jedem Arbeitsbereich wird eine statische Route konfiguriert:
    • Das Ziel jeder statischen Route ist die Overlay-IP-Adresse.
    • Der nächste Hop für jede Route ist die primäre IP-Adresse des jeweiligen VSI.
    • Der Ressourcen-Agent aktiviert die Route zu dem VSI, auf dem sich der SAP HANA primary befindet, und deaktiviert die Route zu dem VSI, auf dem sich der SAP HANA secondary befindet.

Overlay IP Normalbetrieb

  • Die Overlay-IP-Adresse ist als Alias auf VSI-1 in Arbeitsbereich 1 konfiguriert.
  • In Arbeitsbereich 1 ist die statische Route mit der Overlay-IP-Adresse als Ziel und dem nächsten Hop, der auf die primäre IP-Adresse von VSI-1 eingestellt ist, aktiviert.
  • In Arbeitsbereich 2 ist die statische Route mit demselben Ziel und dem nächsten Sprung, der auf die primäre IP-Adresse von VSI-2 eingestellt ist, deaktiviert.
  • Die Primärinstanz SAP HANA läuft auf VSI-1.
  • Die sekundäre Instanz SAP HANA läuft auf VSI-2.

Abbildung 4. SAP HANA auf Power Virtual Server in einer Multizonen-Region HA Übersicht
SAP HANA auf Power Virtual Server in einer Multizonen-Region HA Übersicht

Overlay IP nach einer Übernahme

  • Die Overlay-IP-Adresse ist als Alias auf VSI-2 in Arbeitsbereich 2 konfiguriert.
  • In Arbeitsbereich 2 ist die statische Route mit der Overlay-IP-Adresse als Ziel und dem nächsten Hop, der auf die primäre IP-Adresse von VSI-2 eingestellt ist, aktiviert.
  • In Arbeitsbereich 1 ist die statische Route mit demselben Ziel und dem nächsten Sprung auf die primäre IP-Adresse von VSI-1 deaktiviert.
  • Die Primärinstanz SAP HANA läuft auf VSI-2.
  • Die sekundäre Instanz SAP HANA läuft auf VSI-1.

Abbildung 5. SAP HANA auf Power Virtual Server im Mehrzonengebiet HA-Übernahme
SAP HANA auf Power Virtual Server im Mehrzonengebiet HA-Übernahme

Ressourcen-Agent: powervs-subnet

Während eines Übernahme-Ereignisses verschiebt der Ressourcen-Agent powervs-subnet das gesamte Subnetz, einschließlich der virtuellen IP-Adresse, von einem Arbeitsbereich zu einem anderen.

Die folgenden Abbildungen veranschaulichen dieses Szenario in einem SAP HANA System Replication-Cluster.

Zwei virtuelle Serverinstanzen werden in getrennten Arbeitsbereichen mit jeweils einem eigenen Subnetz bereitgestellt:

  • SAP HANA ist auf beiden VSI installiert und SAP HANA Systemreplikation ist konfiguriert.
  • Die beiden virtuellen Serverinstanzen bilden einen Hochverfügbarkeitscluster mit zwei Knoten, die jeweils ein eigenes Subnetz verwenden.
  • Eine Cluster-Ressource, die den Ressourcenagenten powervs-subnet verwendet, ist für Subnet 3 und IP address 3 konfiguriert. Verwenden Sie einen kleinen CIDR-Bereich. Nur IP address 3 und die Gateway-IP werden in Subnet 3 zugewiesen.
  • SAP HANA datenbank-Clients verwenden IP address 3, um sich mit der Datenbank zu verbinden.

Subnetzmerkmale verschieben

  • Der CIDR-Bereich überschneidet sich mit keinem anderen Teilnetz in der Umgebung.
  • Das Subnetz ist in beiden Arbeitsbereichen nicht vorkonfiguriert.
  • Der Ressourcen-Agent erstellt das Teilnetz in dem Arbeitsbereich, in dem sich die Primärinstanz SAP HANA befindet.

Teilnetz verschieben Normalbetrieb

  • Teilnetz 3 wird in Arbeitsbereich 1 erstellt.
  • Teilnetz 3 ist an VSI-1 angeschlossen.
  • Die IP-Adresse 3 ist auf VSI-1 konfiguriert.
  • Die Primärinstanz SAP HANA ist auf VSI-1 aktiv.
  • Die sekundäre Instanz SAP HANA ist auf VSI-2 aktiv.

Abbildung 6. SAP HANA auf Power Virtual Server in einer Multizonen-Region HA Übersicht
SAP HANA auf Power Virtual Server in einer Multizonen-Region HA Übersicht

Teilnetz nach einer Übernahme verschieben

  • Teilnetz 3 wird in Arbeitsbereich 2 erstellt.
  • Teilnetz 3 ist an VSI-2 angeschlossen.
  • Die IP-Adresse 3 ist auf VSI-2 konfiguriert.
  • Die Primärinstanz SAP HANA ist auf VSI-2 aktiv.
  • Die sekundäre Instanz SAP HANA ist auf VSI-1 aktiv.

Abbildung 7. SAP HANA auf Power Virtual Server im Mehrzonengebiet HA-Übernahme
SAP HANA auf Power Virtual Server im Mehrzonengebiet HA-Übernahme

SAP überlegungen zum Anwendungsserver in einer Region mit mehreren Zonen

Aktiv-Aktiv-Einsatz
SAP die Anwendungsserver sind auf zwei Arbeitsbereiche in verschiedenen Zonen verteilt. Mindestens zwei Anwendungsserver laufen in getrennten Arbeitsbereichen. Redundante virtuelle Serverinstanzen für SAP Central Services (CS) und das Datenbanksystem SAP HANA werden in beiden Arbeitsbereichen eingesetzt. Es sind jeweils nur eine CS-Instanz und ein SAP HANA Primärknoten aktiv. Dieser Einsatz bietet Redundanz auf der Anwendungsebene.
Aktiv-Passiv-Einsatz
SAP die Anwendungsserver sind jeweils nur in einem der beiden Arbeitsbereiche aktiv. Die Anwendungsserver im passiven Arbeitsbereich werden im Voraus bereitgestellt, bleiben aber bis zum Failover ausgeschaltet. Wie bei der aktiv-aktiven Architektur werden CS und SAP HANA in beiden Arbeitsbereichen eingesetzt, aber es sind jeweils nur eine CS-Instanz und ein primärer Knoten aktiv. Diese Bereitstellung bietet eine bessere Leistung, erhöht aber die angestrebte Wiederherstellungszeit, da die Anwendungsserver während des Failovers gestartet werden müssen.

SAP HANA notfallwiederherstellungsszenarien

Um die Datenbank zusätzlich zu schützen, replizieren Sie das System SAP HANA auf ein drittes System in einer anderen Region, indem Sie die SAP HANA Systemreplikation verwenden. Wählen Sie je nach Ihren Anforderungen eine der folgenden Topologien aus.

  • SAP HANA mehrstufige Systemreplikation

    Bei der mehrstufigen Systemreplikation werden mehrere Systeme miteinander verknüpft, um ein höheres Maß an Verfügbarkeit zu erreichen.

  • SAP HANA multi-Zielsystem-Replikation

    Die Multitarget-Systemreplikation ermöglicht es primären und sekundären Systemen, Änderungen auf mehrere Ziele zu replizieren.

Referenzen für die Einrichtung von Hochverfügbarkeitsclustern

Die folgende Tabelle enthält Links zur Dokumentation für die Konfiguration von Hochverfügbarkeits-Clustern.