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

SAP systemarchitektur

Die Hauptkomponenten eines Systems zur Überwachung der Luftfeuchtigkeit ( SAP ) 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.

Ü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 mit Hilfe der Kopie auf dem ERS neu aufgebaut, und die 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 hoch skalierbaren Satz von IBM Power Virtual Server zertifizierten Profilen für SAP HANA, die unter IBM Power Virtual Server verfügbar sind, liegt der Schwerpunkt auf einer SAP HANA Scale-Up- Installation.

  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.

SAP HANA Hochverfügbarkeitsszenarien

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

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 notfallwiederherstellungsszenarien

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

Hinweise zum Netz

In IBM Power Virtual Server ist ein Subnetz auf einen einzigen Arbeitsbereich beschränkt und kann sich nicht über mehrere Arbeitsbereiche erstrecken. Daher ist es nicht möglich, eine Dienst-IP-Adresse auf einen sekundären Arbeitsbereich zu übertragen und die Kommunikation mit diesem von IBM VPC oder einem anderen IBM Power Virtual Server Arbeitsbereich aus aufrechtzuerhalten. Der gemeinsame Linux cluster resource agent ipaddr2 kann nicht zum Verschieben der Dienst-IP-Adresse verwendet werden.

Zwei weitere Ressourcen-Agenten sind verfügbar, um eine Service-IP-Adresse in einer Umgebung mit mehreren Zonen zu verwalten: IBM Power Virtual Server.

• Ressourcen-Agent powervs-move-ip
• Ressourcen-Agent powervs-subnet

Ressourcen-Agent powervs-move-ip

Während eines Übernahme-Ereignisses aktualisiert der Ressourcen-Agent powervs-move-ip vordefinierte statische Routen im IBM Power Virtual Server und konfiguriert eine Overlay-IP-Adresse als IP-Alias-Adresse auf der virtuellen Serverinstanz.

Die folgenden Abbildungen veranschaulichen dieses Szenario für einen SAP HANA System Replication-Cluster.

• Zwei virtuelle Serverinstanzen (VSI) werden in getrennten Arbeitsbereichen bereitgestellt.
• In jedem Arbeitsbereich wird ein privates Subnetz erstellt.
• Die Instanzen, auf denen RHEL läuft, 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 eine Overlay-IP-Adresse wird mit dem Ressourcen-Agenten powervs-move-ip konfiguriert.

Das Overlay IP hat folgende Eigenschaften

• Die Overlay-IP ist nicht Teil eines CIDR-Subnetzbereichs in der Umgebung.
• Sie wird bei der Bereitstellung nicht einer Netzwerkschnittstelle zugewiesen.
• Der Ressourcen-Agent konfiguriert die Overlay-IP-Adresse als IP-Alias-Adresse auf einem Netzwerkadapter eines VSI zur Laufzeit.

In jedem Arbeitsbereich wird eine statische Route erstellt

• Das Ziel der statischen Route ist auf die Overlay-IP-Adresse festgelegt.
• Der nächste Hop für jede Route ist die primäre IP-Adresse der jeweiligen virtuellen Serverinstanz (VSI).
• Der Ressourcen-Agent aktiviert die Route zum VSI mit der primären Adresse SAP HANA und deaktiviert die Route zum VSI mit der sekundären Adresse SAP HANA.

Während des normalen Betriebs

• Die Overlay-IP-Adresse ist als IP-Alias auf VSI-1 im Arbeitsbereich 1 konfiguriert.
• Die statische Route in Arbeitsbereich 1, bei der das Ziel auf die Overlay-IP-Adresse und der nächste Hop auf die primäre IP von VSI-1 eingestellt ist, ist aktiviert.
• Die statische Route in Arbeitsbereich 2 mit demselben Ziel und dem nächsten Hop auf die primäre IP von VSI-2 ist deaktiviert.
• Der SAP HANA Primärserver ist auf VSI-1 aktiv.
• Die Sekundärseite SAP HANA ist aktiv auf VSI-2.

Nach einer Übernahme durch einen Konzern

• Die Overlay-IP-Adresse wird als IP-Alias auf VSI-2 im Arbeitsbereich 2.
• Die statische Route in Arbeitsbereich 2, bei der das Ziel auf die Overlay-IP-Adresse und der nächste Hop auf die primäre IP von VSI-2 eingestellt ist, ist aktiviert.
• Die statische Route in Arbeitsbereich 1 mit demselben Ziel und dem nächsten Hop auf der primären IP von VSI-1 ist deaktiviert.
• Der SAP HANA Primärserver ist auf VSI-2 aktiv.
• Die Sekundärseite SAP HANA ist aktiv auf VSI-1.

Ressourcen-Agent powervs-subnet

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

Die folgenden Abbildungen veranschaulichen dieses Szenario für einen SAP HANA System Replication-Cluster.

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.

Das Teilnetz Teilnetz 3 weist folgende Merkmale auf

• Der CIDR-Bereich des Subnetzes überschneidet sich nicht mit einem anderen CIDR-Subnetzblock in der Umgebung.
• Das Teilnetz ist nicht in beiden Arbeitsbereichen vorhanden
• Der Ressourcenagent erstellt das Teilnetz in einem der Arbeitsbereiche.

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.
• Der SAP HANA primary ist auf der virtuellen Serverinstanz 1 aktiv.
• Der SAP HANA Sekundärserver ist auf der virtuellen Serverinstanz 2 aktiv.

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.
• Der SAP HANA Sekundärserver ist auf der virtuellen Serverinstanz 1 aktiv.