Implementierung von Hochverfügbarkeit für SAP Anwendungen auf IBM Power Virtual Server

Die Ausführung von SAP auf IBM® Power® Virtual Server bietet eine konsistente Plattform für SAP HANA-basierte und traditionelle Anwendungen, eine erstklassige Leistung, Ausfallsicherheit für kritische Arbeitslasten und eine flexible Infrastruktur.

Verwenden Sie die folgenden Informationen, um zu verstehen, wie Hochverfügbarkeitslösungen für SAP-Systeme mithilfe von Power Virtual Server-Instanzen implementiert werden.

SAP systemarchitektur

Die Hauptkomponenten eines SAP Systems sind wie folgt.

SAP Hana-System

Das System SAP HANA stellt die Datenbank für die Mandanten der Anwendungsserver SAP bereit.

SAP anwendungsserver

SAP anwendungsserver stellen den funktionalen Teil einer SAP S/4HANA oder einer anderen Anwendungslösung bereit. Alle Anpassungs- und Anwendungsdaten eines SAP-Systems werden in einer Mandantendatenbank eines SAP HANA-Systems gespeichert.

Ein SAP-Anwendungssystem wird als einzelne Einheit installiert und konfiguriert und besteht aus den folgenden Anwendungsinstanzen.

Eine Instanz des ABAP-Systems für zentrale Dienste (ASCS-Instanz) Jedes SAP-Anwendungssystem verfügt über genau eine ASCS-Instanz, die aus einem Nachrichtenserver und einem Enqueue-Server besteht.
Eine oder mehrere Anwendungsserverinstanzen (AS-Instanzen)
- Der primäre Anwendungsserver (PAS) ist die erste AS-Instanz, die für ein ABAP-System installiert wird.
- Andere AS-Instanzen, die für ein ABAP-System installiert werden, werden als zusätzliche Anwendungsserver (AAS) bezeichnet.

Sowohl die Anwendungsserverinstanzen als auch die ASCS-Instanz sind von einem gemeinsam genutzten Dateisystem abhängig und benötigen Lese-/Schreibzugriff darauf.

Gemeinsam genutztes Dateisystem : In der Regel wird das gemeinsam genutzte Dateisystem auf einem NFS-Server exportiert und auf allen Instanzen bereitgestellt.

Abbildung 1 zeigt die technischen Komponenten eines SAP-Systems.

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

Überlegungen zur Implementierung einer Hochverfügbarkeitslösung für SAP

Für einen Hochverfügbarkeitsschutz wird empfohlen, Anwendungsserver redundant zu installieren. Installieren Sie mindestens zwei Anwendungsserver (PAS und AAS) und verwenden Sie Anmeldegruppen, um die Lastverteilung zu implementieren. Wenn ein Anwendungsserver ausfällt, werden alle Benutzersitzungen, die mit dieser Instanz verbunden sind, beendet. Der Benutzer meldet sich erneut an und der Lastausgleich leitet den Benutzer an einen anderen Anwendungsserver weiter, der noch läuft.

Die anderen technischen Komponenten, wie die ASCS-Instanz, die SAP HANA-Datenbank und das gemeinsam genutzte Dateisystem, sind einzelne Fehlerquellen und müssen geschützt werden.

ASCS-Instanz

Die beste Möglichkeit, die ASCS-Instanz zu schützen, besteht darin, eine Enqueue-Replikationsserver-Instanz (ERS) auf einem zusätzlichen virtuellen Server bereitzustellen und eine HA-Clustering-Software zur Automatisierung des Failovers zu verwenden.

Installieren Sie ASCS und ERS entweder auf einer gemeinsam genutzten Festplatte, die an beide virtuellen Serverinstanzen angeschlossen ist, oder auf einem NFS-Dateisystem.

Der Enqueue-Server der ASCS-Instanz verwaltet die Sperrtabelle, und das ERS erstellt eine replizierte Kopie der Sperrtabelle in seinem Hauptspeicher. Wenn der Enqueue-Server neu gestartet werden muss, wird die Sperrtabelle mithilfe der Kopie auf dem ERS neu erstellt und alle Sperren bleiben erhalten.

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

Führen Sie die Schritte unter Konfigurieren der Hochverfügbarkeit für SAP S/4HANA(ASCS und ERS)in einem Red Hat Enterprise Linux High Availability Add-On-Cluster aus, um einen HA-Cluster für die ABAP System Central Services-Instanz einzurichten.
Gemeinsam genutztes Dateisystem

Die empfohlene Methode zum Schutz des NFS-Servers ist die Implementierung einer zusätzlichen virtuellen Serverinstanz. Erstellen Sie dann die exportierten Dateisysteme NFS auf gemeinsam genutzten Festplatten, die an beide virtuellen Serverinstanzen angeschlossen sind, und automatisieren Sie das Failover mithilfe von HA-Cluster-Software.

Befolgen Sie die Schritte unter Konfigurieren eines aktiv-passiven NFS Servers in einem Red Hat Enterprise Linux High Availability Add-On-Cluster, um einen HA-Cluster für das gemeinsame Dateisystem einzurichten.
SAP Hana-System

SAP HANA bietet zwei Ansätze zur Skalierung eines Systems: Scale-up und Scale-out. Mit dem umfassenden und hochgradig skalierbaren Satz an IBM Power Virtual Server zertifizierten Profilen für SAP HANA, die in IBM Power Virtual Server verfügbar sind, liegt der Schwerpunkt auf Scale-up-Lösungen SAP HANA.

Der beste Weg, ein SAP HANA-System zu schützen, ist die Einrichtung eines sekundären SAP HANA-Systems auf einer separaten virtuellen Serverinstanz. Konfigurieren Sie dann die Systemreplikation von SAP HANA und automatisieren Sie das Failover mit der HA-Cluster-Software.

Die folgende Abbildung zeigt eine architektonische Übersicht eines hochverfügbaren SAP-Systems, das auf Power Virtual Server implementiert ist.

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

SAP HANA szenarien für Hochverfügbarkeitslösungen

Die Lösung variiert je nach angestrebter Wiederherstellungszeit (Recovery Time Objective, RTO).

Varianten für Hochverfügbarkeitslösungen für SAP HANA
Szenario	Typische RTO	Kommentar
Leistungsoptimiert	Ein paar Minuten	Sofern Sie keine besonderen Anforderungen haben, ist dieses Szenario die Standardeinstellung.
Aktiv/Aktiv (Lesen aktiviert)	Ein paar Minuten	In einer Active/Active-Konfiguration (Lesezugriff aktiviert) ermöglicht die SAP HANA-Systemreplikation den Lesezugriff auf den Datenbankinhalt auf dem sekundären System.
Kostenoptimiert	Einige zehn 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 auf dem sekundären Knoten werden zwischen dem Nicht-Produktionssystem und der sekundären SAP HANA-Systemreplikation gemeinsam genutzt. Der Speicherverbrauch der sekundären Systemreplikation der Produktion SAP HANA wird durch Deaktivieren des Vorladens von Daten in den Spaltentabellen reduziert. Bei einem Failover wird die Nicht-Produktionsinstanz automatisch gestoppt, bevor der Knoten die Produktionslast übernimmt. Die Übernahmezeit ist im Vergleich zu einer leistungsoptimierten Konfiguration länger.

Wählen Sie je nach Bedarf die Dokumentation für eines der Szenarien aus.

SAP HANA Systemreplikation – leistungsoptimiertes Szenario

Konfigurieren der SAP HANA Scale-up-Systemreplikation in einem Red Hat Enterprise Linux High Availability Add-On-Cluster.
SAP HANA Kostenoptimiertes Szenario für die Systemreplikation

Konfigurieren von SAP HANA kostenoptimierter Scale-up-Systemreplikation in einem Red Hat Enterprise Linux High Availability Add-On-Cluster.
SAP HANA Szenario "Systemreplikation Aktiv-Aktiv (Lesezugriff aktiviert)"

Konfigurieren von SAP HANA active/active(read enabled)Systemreplikation in einem Red Hat Enterprise Linux High Availability Add-On-Cluster.

SAP HANA szenarien für Lösungen zur Notfallwiederherstellung

Um das Datenbanksystem zusätzlich zu schützen, replizieren Sie das SAP HANA-System mithilfe der SAP HANA-Systemreplikation auf ein drittes System, das sich in einer anderen Region befindet. Wählen Sie je nach Bedarf eine der beiden verfügbaren Topologien aus.

SAP HANA mehrstufiges Systemreplikationsszenario

Mit der mehrstufigen Systemreplikation von SAP HANA können Sie mehrere Systeme miteinander verketten, um eine höhere Verfügbarkeit zu erreichen.

Konfigurieren der SAP HANA Multitier-Systemreplikation in einem Red Hat Enterprise Linux High Availability Add-On-Cluster.
SAP HANA multitarget-System-Replikationsszenario

Die Replikation von Multitarget-Systemen ermöglicht es primären und sekundären Systemen, Änderungen auf mehr als einem System zu replizieren.

Konfigurieren der SAP HANA Multitarget-Systemreplikation in einem Red Hat Enterprise Linux High Availability Add-On-Cluster.

SAP HANA hochverfügbarkeitslösung in einer Umgebung mit mehreren Zonen

Ein Subnetz in IBM Power Virtual Server kann nicht mehrere Arbeitsbereiche umfassen. Es ist nicht möglich, eine Service-IP-Adresse in einen zweiten Arbeitsbereich zu verschieben und sie weiterhin von VPC oder anderen Arbeitsbereichen aus zu verwenden, um auf die bereitgestellten Dienste zuzugreifen. Diese Fähigkeit ist jedoch erforderlich, um ein hochverfügbares SAP HANA-Systemreplikationsszenario in einer Umgebung mit mehreren Zonen einzurichten.

Der Ressourcenagent powervs-subnet behebt dieses Problem. Während einer Übernahmeaktion verschiebt der Ressourcenagent das gesamte Subnetz, einschließlich der IP-Adresse, von einem Arbeitsbereich in einen anderen.

Die folgenden Abbildungen veranschaulichen dieses Szenario.

Zwei virtuelle Serverinstanzen werden in separaten Arbeitsbereichen mit unterschiedlichen Subnetzen bereitgestellt.

SAP HANA ist auf beiden virtuellen Serverinstanzen installiert und die SAP HANA-Systemreplikation ist konfiguriert.
Die beiden virtuellen Serverinstanzen sind als Hochverfügbarkeitscluster mit zwei Knoten und eigenen Subnetzen konfiguriert.
Eine Cluster-Ressource, die den Ressourcenagenten powervs-subnet verwendet, ist für Subnet 3 und IP address 3 konfiguriert. Wählen Sie einen kleinen Bereich für das Classless Inter-Domain Routing (CIDR), nur IP address 3 und eine IP-Adresse für das Gateway werden in Subnet 3 zugewiesen.
SAP HANA datenbank-Clients verwenden IP address 3, um sich mit der Datenbank zu verbinden.

Während des normalen Betriebs

Subnetz 3 wird in Arbeitsbereich 1 erstellt.
Subnetz 3 ist mit der virtuellen Serverinstanz 1 verbunden.
IP-Adresse 3 ist auf der virtuellen Serverinstanz 1 konfiguriert.
Die primäre SAP HANA ist auf der virtuellen Serverinstanz 1 aktiv, die sekundäre SAP HANA ist auf der virtuellen Serverinstanz 2 aktiv.

Abbildung 3. SAP HANA auf Power Virtual Server in der Multizonenregion HA-Übersicht — SAP HANA auf Power Virtual Server in der Multizonenregion HA-Übersicht

Nach einer Übernahme durch einen Konzern

Subnetz 3 wird in Arbeitsbereich 2 erstellt.
Subnetz 3 ist mit der virtuellen Serverinstanz 2 verbunden.
IP-Adresse 3 ist auf der virtuellen Serverinstanz 2 konfiguriert.
Die SAP HANA-Primärinstanz ist auf der virtuellen Serverinstanz 2 aktiv.

Abbildung 4. SAP HANA an Power Virtual Server in der Multizone-Region HA Übernahme — SAP HANA an Power Virtual Server in der Multizone-Region HA Übernahme

Weitere Informationen zur Vorbereitung und Konfiguration eines Red Hat Enterprise Linux (RHEL) High Availability (HA) Clusters für den powervs-subnet Resource Agent finden Sie in Implementieren eines Red Hat Enterprise Linux High Availability Add-On Clusters in einer Umgebung mit mehreren Zonen.