SAP S/4HANA in einer Hochverfügbarkeitskonfiguration laufen

Die Architektur von IBM Cloud® bietet überlegene technische Möglichkeiten, wie eine softwaredefinierbare Umgebung, die für eine Cloud-Infrastruktur entscheidend ist, programmierbare Schnittstellen und Hunderte von Hardware- und Netzwerkkonfigurationen. Es wurde entwickelt, um ein höheres Maß an Flexibilität zu bieten, indem virtuelle und dedizierte Server gemischt werden, um verschiedene Workloads, die Automatisierung von Schnittstellen und hybride Bereitstellungsoptionen zu ermöglichen. Das IBM Cloud SAP-zertifizierte Infrastrukturangebot für SAP HANA und SAP NetWeaver bietet Ihnen eine optimale Auswahl an Bare-Metal- und virtualisierungsbasierten Servern, auf denen der SAP Software-Stack ausgeführt wird.

SAP HANA ist eine von mehreren Datenbanken, die auf SAP NetWeaver im IBM Cloud® bereitgestellt werden können. SAP HANA ist eine In-Memory-Datenbank, die auf einem speziellen Datenbankserver installiert ist. Die wichtigsten Architekturen für SAP HANA sind Single-Host- oder Multiple-Host-Systeme. IBM Cloud ist zertifiziert für den Betrieb von SAP NetWeaver Application Server ABAP, Java und SAP Produkten, die auf diesen Application Server Stacks basieren.

SAP S/4 HANA-Bereitstellung in HA-Konfiguration mit mehreren Zonen

Abbildung 1. SAP S/4 HANA-Einsatz in HA-Konfiguration mit mehreren Zonen — SAP S/4 HANA-Einsatz in HA-Konfiguration mit mehreren Zonen

Der Einsatz des SAP Systems in einer Hochverfügbarkeitsumgebung basiert auf zwei Pacemaker-Cluster-Konfigurationen:

ein Cluster schützt einen einzigen Ausfallpunkt der Anwendungen SAP und der zentralen Dienste.
der zweite Cluster stellt die Verfügbarkeit der Datenbank SAP HANA sicher.

SAP technische Komponenten

Im Folgenden sind die technischen Komponenten von SAP aufgeführt, die in dieser Konfiguration eingesetzt werden:

SAP HANA datenbank - zwei Installationen auf zwei VSI mit Replikationskonfiguration für HA-Unterstützung.
SAP ASCS-Instanz, die auf einem der Knoten installiert ist. Diese Instanz enthält den Message Server und den Enqueue Server Prozess. Wird verwendet, um Sperren zu verwalten, Nachrichten auszutauschen und die Arbeitslast im SAP-System gleichmäßig zu verteilen.
SAP ERS-Instanz, die auf einem anderen Knoten installiert ist. Dieser Enqueue-Replikationsserver ist eine obligatorische Instanz in einem HA-Szenario mit der Aufgabe, ein Replikat der Enqueue-Tabelle in einem lokalen Speicher aufzubewahren.
SAP PAS, der primäre Anwendungsserver mit Dialog- und Stapelverarbeitung.
SAP AAS, ein zusätzlicher Anwendungsserver, der auf einem gegenüberliegenden, mit dem PAS verbundenen Knoten installiert ist.
SAP Router (optional), bietet gesicherte Verbindungen zum VSI und Remote-Verbindungen zur Unterstützung von SAP AG Remote Services.

VPC-Dienste und -Komponenten

Im Folgenden finden Sie die IBM Cloud VPC Dienste und Komponenten zur Unterstützung der SAP Hochverfügbarkeitskonfiguration:

Netzdienste (VPN, Public Gateway )- Bereitstellung von Kundenzugang und Internetkonnektivität.
Jumphost - für den Zugriff, das Management und die Verwaltung von SAP virtuellen Serverinstanzen aus derselben Kundenzone direkt von deren Räumlichkeiten aus.
Application Load Balancer - mit der Aufgabe, den Datenverkehr für die virtuellen Instanzen zu verteilen, die Teil der SAP und HANA-Cluster sind.
DNS Services
FileShares- bietet NFS-basierten Dateispeicher, der als gemeinsamer Speicher verwendet wird und die Anforderungen von SAP Netweaver-Dateisystemkonfigurationen unterstützt.

Clients im Customer Facing Network (CFN) verwenden eine Floating IP, um auf virtuelle Serverinstanzen innerhalb des IBM Cloud zuzugreifen. Virtuelle Serverinstanzen werden in Verfügbarkeitszonen (Rechenzentren) in geografischen Regionen gehostet.

Die virtuellen Serverinstanzen von SAP können sich in einer separaten Sicherheitszone befinden, sollten sich aber in derselben IBM Cloud Region befinden. Die Kundenverbindung zum Jumphost folgt den gleichen Regeln wie die direkte Verbindung von den Kundenstandorten zu den SAP-Instanzen der virtuellen Serverinstanz. Die Verbindung verwendet die Floating IP und die Firewall-Regeln der Sicherheitsgruppe 1 aus einem bestimmten öffentlichen Subnetz. In dieser Architektur sind zwei Sicherheitsgruppen definiert; diese Anordnung ist die einfachste Methode zum Trennen der öffentlichen und privaten Teilnetze. Sie können weitere Sicherheitsgruppen hinzufügen, wenn Sie mehr Isolation benötigen.

Hauptaspekte der Hochverfügbarkeit

Redundanz kritischer Komponenten, automatische Failover-Mechanismen und die Integration mit Clustering- und Systemreplikationstechnologien wie Pacemaker und SAP HANA System Replication sind wichtige Aspekte für die Hochverfügbarkeits-Referenzarchitektur.

Um den Zugang und die Verfügbarkeit der Anwendungsverarbeitung für die Endbenutzer aufrechtzuerhalten, wird empfohlen, die SAP Anwendungsserver redundant zu installieren. Dies kann durch die Verwendung eines primären Anwendungsservers und eines zusätzlichen Anwendungsservers mit 2 VSI erreicht werden.

Fällt einer der Knoten aus, verlieren die Benutzer den Zugriff auf den entsprechenden Anwendungsserver, der ausgefallen ist. Wenn Anmeldegruppen für den Lastausgleich verwendet werden, werden die Benutzer beim erneuten Verbindungsaufbau auf den noch verfügbaren Anwendungsserver umgeleitet.

Andere Fehlerquellen sind die ASCS-Instanz und die Datenbank SAP HANA:

Die ASCS-Instanz sollte in einem HighAvailability-Cluster eingesetzt werden. Auf diese Weise werden die vom Enqueue-Server verwalteten Sperren der Enqueue-Tabelle geschützt. Dazu wird eine ERS-Instanz auf einem anderen VSI bereitgestellt und eine replizierte Kopie der Sperrtabelle in ihrem Instanzspeicher erstellt. Wenn das ASCS ausfällt, kann die Tabelle der Warteschlangensperren anhand der replizierten Kopie der ERS-Instanz wiederhergestellt werden. Der Message Server wird neu gestartet, die Kommunikation geht verloren, aber die Datenintegrität ist gewährleistet.

Das SAP S/4 HANA System läuft standardmäßig in einer ENSA2 Konfiguration, ein Konzept, bei dem das ASCS nicht auf dem ERS-Knoten gestartet werden muss. In einer 2-Knoten-Cluster-Konfiguration wird ASCS jedoch auf demselben Knoten ausfallen, auf dem auch ERS läuft.

SAP HANA datenbanksystem wird auch durch die Installation der Datenbankinstanzen in einem Pacemaker High Availability Cluster geschützt. Die Umgebung ist als standardmäßiger Hochverfügbarkeitscluster mit zwei Knoten aufgebaut, bei dem ein Knoten aktiv ist und der andere als Sekundärknoten mit kontinuierlicher Datensynchronisierung arbeitet. Die Datenbank SAP HANA wird mit nativer HANA System Replication (HSR) im synchronen Modus (mode=sync mit aktivierter Protokollwiedergabe) konfiguriert, wodurch sichergestellt wird, dass alle festgeschriebenen Daten nahezu in Echtzeit vom primären zum sekundären Knoten repliziert werden. Die Replikation wird zwischen zwei identisch großen SAP HANA Instanzen durchgeführt. Obwohl SAP HANA sowohl Scale-Up- (vertikale Skalierung) als auch Scale-Out-Architekturen (horizontale Skalierung) zur Bewältigung großer Arbeitslasten unterstützt, konzentriert sich dieser Einsatz auf das Scale-Up-Modell.

Einfache Mount-Struktur (SUSE Linux )

In herkömmlichen HA-Konfigurationen verwaltet der Cluster das Einhängen und Aushängen von SAP Dateisystemen während der Failover-Vorgänge. Die Simple Mount Architecture geht davon aus, dass diese Dateisysteme weder umgeschaltet noch vom Pacemaker-Cluster kontrolliert werden müssen. Diese Struktur basiert auf einer externen Netzwerk-Dateifreigabe. Anstelle einer Anzahl von Dateisystemen pro SAP System und einer Anzahl von Dateisystemen pro SAP Instanz, benötigt das einfache Mount-Setup nur 2 einfache Dateisystem-Layouts: " [/sapmnt/SID] " und " [/usr/sap/SID] ". Beide NFS-Freigaben mit Instanzverzeichnissen können auf allen Knoten beim Booten statisch eingehängt werden, indem Standard-Betriebssystemmechanismen wie systemd oder fstab verwendet werden. Außerdem befindet sich die Datei " /usr/sap/sapservices” lokal auf jedem Clusterknoten. Um eine gewisse Kompatibilität mit früheren HA-Setups zu gewährleisten, verwendet diese Referenzarchitektur immer noch das "alte" Dateisystemlayout, aber die meisten Dateifreigaben werden auf beiden Knoten eingehängt, um den einfachen Einhängeansatz zu implementieren.

Abbildung 2. Einfache Mount-Architektur in SUSE Linux — Einfache Mount-Architektur in SUSE Linux

SAP Standalone-Enqueue-Server 1 ( ENSA1 ) und Standalone-Enqueue-Server 2 ( ENSA2 ) Um eine der kritischen Komponenten des SAP Systems und einen der Single Points of Failure, die Enqueue-Tabelle, zu schützen, ist eine separate Installation der Enqueue Replication Server-Instanz (ERS) erforderlich, die eine Kopie der Enqueue-Tabelle enthält.

In ENSA1-Installationen muss ASCS zu dem Knoten wechseln, auf dem ERS läuft, um seine eigene ENQ-Sperrtabelle neu aufzubauen. Dies wird durch die Synchronisierung der gemeinsamen Speichersegmente der Instanzen erreicht, weshalb ASCS zwingend auf dem Knoten gestartet werden muss, auf dem ERS läuft.

Ab SAP NW 7.52 / SAP S4 HANA ist der Standalone Enqueue Server 2 die Standardinstallation. Dieser neue Mechanismus ersetzt ENSA1 und sorgt für ein verbessertes Verhalten bei HA-Installationen und Flexibilität bei Failover-Vorgängen. Die Replikation/Kopie der ENQ-Tabelle wird nun über eine Netzwerkverbindung ausgeführt. Dies bedeutet, dass ASCS im Falle eines Failover nicht auf der ERS-Seite neu gestartet werden muss, sondern auf jedem anderen Knoten des Clusters, einschließlich des ursprünglichen Knotens. Natürlich wird ASCS in 2-Knoten-Cluster-Konfigurationen dennoch auf den gegenüberliegenden Knoten ausfallen, d. h. auf denselben Knoten, auf dem ERS läuft.

SAP HANA skalierung der Systemreplikation (Hochverfügbarkeitsszenarien)

SAP HANA System Replication in einer Scale-up-Hochverfügbarkeitskonfiguration unterstützt mehrere Bereitstellungskonfigurationen, die jeweils auf unterschiedliche geschäftliche und betriebliche Anforderungen wie Leistungsoptimierung, Kostenkontrolle und Servicekontinuität (RTO) abgestimmt sind.

HANA Performance Optimized: Die SAP HANA Installation auf dem ersten Knoten synchronisiert sich (sync mit Betriebsmodus log-replay) mit der SAP HANA Datenbank, die auf dem zweiten Knoten installiert ist. Die Übernahmezeit ist sehr kurz, da die Datenbank auf dem zweiten Knoten so konfiguriert ist, dass die Tabellen im Speicher vorgeladen werden.
HANA-Leistung optimiert, sekundärer Standort leseaktiviert: ein leistungsoptimiertes Szenario, aber mit der Möglichkeit, Lesezugriff auf den sekundären Datenbankstandort zuzulassen. Dies wird auch als Aktiv-Aktiv-Konfiguration bezeichnet.
HANA kostenoptimiert: In diesem Szenario wird die Stand-by- oder sekundäre HANA-Datenbank mit einem nicht produktiven Datenbanksystem, z. B. einem Test- oder Entwicklungssystem, zusammengelegt. Bei jeder Übernahme muss das nicht-produktive System gestoppt werden, um die notwendigen Hardware-Ressourcen für den Betrieb der produktiven HANA-Instanz freizugeben. In diesem Szenario ist die Tischvorspannung ausgeschaltet und die Übernahmezeit ist länger.

Hohe Verfügbarkeit in MultiZone (MZ) und SingleZone (SZ) Umgebungen

Die Bereitstellung von Ressourcen in mehreren Zonen innerhalb einer Region ermöglicht eine hohe Verfügbarkeit und Fehlerisolierung, da Workloads auch dann weiterlaufen können, wenn eine Zone ausfällt. Weitere Informationen finden Sie unter IBM Cloud region and data center locations for resource deployment.

Die Bereitstellung der Ressourcen in einer HA-Konfiguration ist jedoch auch mit einer einzelnen Zone innerhalb einer Region möglich.

Abbildung 3. SAP S/4 HANA-Einsatz in HA-Konfiguration Einzelzone — SAP S/4 HANA-Einsatz in HA-Konfiguration Einzelzone

Es wird nur ein privates Subnetz eingesetzt.
SAP HANA ist ein Zwei-Knoten-Cluster im selben Netzsegment.
SAP service-Instanzen ASCS/ERS sind Teil desselben Netzwerksegments und zusammen mit SAP Application Servern auf zwei VSI-Knoten untergebracht.
Virtuelle Hostnamen werden von den Clients und Anwendungen auch über einen Application Load Balancer mit Hilfe des DNS-Dienstes angesprochen.

Eine Power-Placement-Gruppe in Verbindung mit einer Platzierungsstrategie bietet zusätzlichen Schutz für VMs in einer einzelnen Zone und garantiert, dass jede Instanz auf Computer-Hosts mit separaten Stromversorgungen und Netzwerkgeräten platziert wird. Siehe die Informationen von IBM Cloud über Vermittlungsgruppen.