Leitfaden zur Planung der Hochverfügbarkeit für SAP NetWeaver in Google Cloud

Dieser Leitfaden bietet einen Überblick über die Optionen, Empfehlungen und allgemeinen Konzepte, die Sie kennen sollten, bevor Sie ein SAP NetWeaver-Hochverfügbarkeitssystem in Google Cloud bereitstellen.

In diesem Leitfaden wird davon ausgegangen, dass Sie bereits mit den Konzepten und Vorgehensweisen vertraut sind, die im Allgemeinen für die Implementierung eines SAP NetWeaver-Hochverfügbarkeitssystems erforderlich sind. Daher konzentriert sich der Leitfaden hauptsächlich auf das, was Sie wissen müssen, um ein solches System in Google Cloud zu implementieren.

Weitere Informationen zu den allgemeinen Konzepten und Vorgehensweisen, die zur Implementierung eines SAP NetWeaver-HA-Systems erforderlich sind, finden Sie hier:

Dieser Planungsleitfaden befasst sich ausschließlich mit HA für SAP NetWeaver und nicht mit HA für Datenbanksysteme. Informationen zur Hochverfügbarkeit für SAP HANA finden Sie im Leitfaden zur Planung der Hochverfügbarkeit für SAP HANA.

Deployment-Architektur

Im folgenden Diagramm ist ein einfacher Linux-HA-Cluster dargestellt, der die Clustersoftware Pacemaker verwendet.

Der Cluster enthält einen primären und einen sekundären Host. Jeder Host befindet sich in einer anderen Zone innerhalb derselben Region.

Der Cluster verwendet SAP Standalone Enqueue Server 2 (ENSA2). Eine Beschreibung eines Clusters, der die frühere Version von Standalone Enqueue Server (ENSA1) verwendet, finden Sie unter Architektur von Enqueue Server (ENSA1).

Die aktive Central Services-Instanz befindet sich auf dem primären Host. Die aktive ERS-Instanz (Enqueue Replication Server 2) befindet sich auf dem sekundären Host. Central Services und ERS haben jeweils eine eigene virtuelle IP-Adresse (VIP). Im Diagramm steht "Central Services" entweder für ABAP SAP Central Services oder, bei einem Java-Stack, für SAP Central Services.

Weitere Informationen zu Standalone Enqueue Server 2 in Hochverfügbarkeitskonfigurationen finden Sie unter SAP-Hinweis 2711036 – Verwendung von Standalone Enqueue Server 2 in einer HA-Umgebung.

Eine grundlegende HA-Einrichtung für SAP NetWeaver in Google Cloud mit zwei Hosts, die sich jeweils in einer anderen Zone befinden

Architektur von Standalone Enqueue Server (ENSA1)

Im folgenden Diagramm befinden sich die aktive Central Services-Instanz mit der Sperrverwaltung oder dem Enqueue-Dienst und die inaktive ERS-Instanz (Enqueue Replication Server) auf dem primären Host. Die aktive ERS-Instanz und die inaktive Central Services-Instanz befinden sich auf dem sekundären Host. Jedes Paar aus einer Central Service- und einer ERS-Instanz hat eine eigene virtuelle IP-Adresse (VIP). Im Diagramm steht "Central Services" entweder für ABAP SAP Central Services oder, bei einem Java-Stack, für SAP Central Services.

Bei einem Ausfall muss die HA-Clustersoftware den Standalone Enqueue Server auf den Knoten verschieben, auf dem Enqueue Replication Server ausgeführt wird, um die Sperrinformationen beizubehalten. Aktualisieren Sie Ihr System auf die Verwendung von Standalone Enqueue Server 2, sofern von Ihrer Softwareversion unterstützt. Weitere Informationen finden Sie unter SAP-Hinweis 2630416 – Unterstützung für Standalone Enqueue Server 2.

Eine grundlegende HA-Einrichtung für SAP NetWeaver in Google Cloud mit zwei Hosts, die sich jeweils in einer anderen Zone befinden

Die hohe Verfügbarkeit der Google Cloud-Infrastruktur

Google Cloud ist standardmäßig hochverfügbar und hat eine redundante Infrastruktur von Rechenzentren auf der ganzen Welt, die voneinander unabhängige Zonen enthalten. Die Stromversorgung, die Kühlung sowie die Netzwerk- und Steuerebenen von Zonen sind in der Regel von anderen Zonen unabhängig. Wenn ein einzelnes Fehlerereignis auftritt, betrifft dies in den meisten Fällen nur eine einzelne Zone.

In einigen Fällen lassen sich Ihre Verfügbarkeitsanforderungen ohne die herkömmlichen lokalen Sicherheitsmaßnahmen gegen Hardware-, Speicher- und Netzwerkfehler erfüllen, wodurch Sie Zeit und Geld sparen können.

Bevor Sie Ihre Hochverfügbarkeitsstrategie in Google Cloud entwerfen und implementieren, lesen Sie die Google Cloud Service Level Agreement (SLA).

Allgemeine Informationen zu Zuverlässigkeit, Datenschutz und Sicherheit von Google Cloud finden Sie unter Zuverlässigkeit.

HA-Clustering-Optionen für SAP-Systeme in Google Cloud

Sie definieren einen Hochverfügbarkeitscluster für SAP NetWeaver in Google Cloud, wenn Sie dieselben Typen von HA-Clustersoftware von Drittanbietern verwenden, die Sie auch bei einer lokalen Installation verwenden können. Die HA-Clustersoftware überwacht den Zustand der Systeme und verwaltet das Failover, wenn Probleme auftreten.

Sie können eine Reihe verschiedener HA-Clustersoftware-Lösungen verwenden, z. B.:

  • Red Hat Enterprise Linux (RHEL) für SAP-Lösungen
  • SUSE Linux Enterprise Server (SLES) für SAP-Anwendungen
  • Windows Server Failover Clustering

Linux-HA-Clustersoftware

Neuere Versionen von RHEL und SLES enthalten eine integrierte HA-Unterstützung, die speziell für Google Cloud aktiviert ist. Wenn Sie prüfen möchten, ob Ihre Linux-Version Google Cloud-fähige Hochverfügbarkeit unterstützt, suchen Sie in der Tabelle unter Betriebssystemunterstützung für SAP NetWeaver in Google Cloud nach "GCP-HA".

Windows-HA-Clustersoftware

Unter Windows Server verwenden Sie Windows Server Failover Clustering (WSFC) zum Erstellen des HA-Clusters, wie unter Windows Server-Failoverclustering ausführen beschrieben.

In Google Cloud wird das Routing des eingehenden Traffics zum aktiven Knoten in einem WSFC-Cluster durch Cloud Load Balancing verwaltet, für das keine Alias-IP oder statische Routen-VIP-Implementierung erforderlich ist.

Cloud Load Balancing ermittelt mithilfe von Systemdiagnosen den aktiven Knoten.

Google Cloud-Zonen, -Regionen und SAP NetWeaver-HA-Bereitstellungen

Stellen Sie die Knoten Ihres HA-Clusters in zwei oder mehr Compute Engine-Zonen innerhalb derselben Region bereit. Durch die Bereitstellung der Knoten in verschiedenen Zonen wird sichergestellt, dass sie sich auf verschiedenen physischen Maschinen befinden. Es wird außerdem dem sehr unwahrscheinlichen Auftreten eines Zonenfehlers vorgebeugt.

Wenn Sie die Zonen in derselben Region belassen, sind die Knoten geografisch nah genug, um die SAP-Latenzanforderungen für Hochverfügbarkeitssysteme zu erfüllen.

Virtuelle Compute Engine-Maschinen und SAP NetWeaver-HA-Bereitstellungen

Für Compute Engine-VMs werden Live-Migration und automatischer Neustart geboten, um Hochverfügbarkeit zu gewährleisten.

Live-Migration bei Compute Engine

Compute Engine überwacht den Zustand der zugrunde liegenden Infrastruktur. Bei einem Infrastrukturwartungsereignis migriert Compute Engine Ihre Instanz automatisch an eine andere Stelle und sorgt dafür, dass die Instanz, wenn möglich, während der Migration weiter ausgeführt wird. Es ist kein Nutzereingriff erforderlich.

Bei größeren Ausfällen kann es zu einer leichten Verzögerung zwischen dem Ausfall und der Verfügbarkeit der Instanz kommen.

In den meisten Fällen wird der HA-Cluster bei einem Live-Migrationsereignis nicht beeinträchtigt. Sie sollten allerdings nach der Einrichtung Ihres HA-Clusters und dem Start der Systeme eine Live-Migration des aktiven Hosts durchführen, um den HA-Cluster zu testen, insbesondere wenn Ihr HA-Clustermonitor mit einem niedrigen Failover-Schwellenwert konfiguriert ist. Weitere Informationen zum Simulieren eines Live-Migrationsereignisses finden Sie unter Verfügbarkeitsrichtlinien testen.

Eine migrierte Instanz ist mit der ursprünglichen Instanz identisch, einschließlich der Instanz-ID, der privaten IP-Adresse sowie aller Instanzmetadaten und des Speicherinhalts.

Für Standardinstanzen ist standardmäßig Live-Migration festgelegt. Wir empfehlen, diese Einstellung nicht zu ändern.

Weitere Informationen finden Sie unter Live-Migration.

Automatischer Neustart bei Compute Engine

Wenn Ihre Instanz so eingestellt ist, dass sie bei einem Wartungsereignis beendet wird, oder wenn Ihre Instanz aufgrund eines zugrunde liegenden Hardwareproblems abstürzt, können Sie Compute Engine so einrichten, dass die Instanz automatisch neu gestartet wird. Instanzen sind standardmäßig so eingestellt, dass sie automatisch neu gestartet werden. Wir empfehlen, diese Einstellung nicht zu ändern.

Weitere Informationen zum automatischen Neustart finden Sie unter Automatischer Neustart.

Optionen für freigegebenen Speicher für HA SAP-Systeme in Google Cloud

Das globale SAP NetWeaver-Dateisystem ist ein Single Point Of Failure, der für alle SAP NetWeaver-Instanzen in Ihrem HA-System verfügbar sein muss. Damit die Verfügbarkeit des globalen Dateisystems in Google Cloud gewährleistet wird, können Sie entweder hochverfügbaren freigegebenen Speicher oder replizierte zonale nichtflüchtige Speicher verwenden.

Für eine hochverfügbare Shared Storage-Lösung können Sie Google Cloud Filestore oder Lösungen von Drittanbietern für die Dateifreigabe wie NetApp Cloud Volumes Service für Google Cloud oder NetApp Cloud Volumes ONTAP verwenden.

Die Enterprise-Stufe von Filestore kann für Bereitstellungen in mehreren Zonen und die Basisstufe von Filestore kann für Bereitstellungen in einzelnen Zonen verwendet werden.

Für die Replikation von zonalen nichtflüchtigen Speichern für Linux-Systeme können Sie mit einem Distributed Replicated Block Device (DRBD) die nichtflüchtigen Speicher replizieren, die das globale SAP-Dateisystem zwischen den Knoten in Ihrem Hochverfügbarkeitscluster enthalten.

Regionale nichtflüchtige Compute Engine-Speicher bieten zwar einen zonenübergreifenden, synchron replizierten Blockspeicher, werden jedoch derzeit für SAP NetWeaver-HA-Systeme nicht unterstützt.

Weitere Informationen zu Speicheroptionen in Google Cloud finden Sie unter:

Netzwerkoptionen für HA-SAP-Systeme

Wenn Sie Ihr Netzwerk für Ihren HA-Cluster einrichten, müssen Sie zusätzlich zu den Schritten unter Netzwerk erstellen die folgenden HA-spezifischen Aufgaben ausführen:

  • Wählen Sie Ihre VIP-Implementierung für Linux-Systeme aus. Dies wird im folgenden Abschnitt erläutert. Windows-Systeme verwenden einen internen Load-Balancer, für den nicht dieselben VIP-Lösungen wie für Linux-Systeme erforderlich sind.
  • Definieren Sie den Kommunikationspfad zwischen der SAP Central Services-Instanz und der Enqueue Replication Server-Instanz.
  • Definieren Sie Firewallregeln, die Ihre festgelegten Kommunikationspfade unterstützen.

Virtuelle IP-Implementierung in Google Cloud

Ein Hochverfügbarkeitscluster verwendet eine Floating- oder virtuelle IP-Adresse (VIP), um die Arbeitslast bei einem unerwarteten Ausfall oder einer geplanten Wartung von einem Clusterknoten zu einem anderen zu verschieben. Die IP-Adresse der VIP ändert sich nicht, sodass Clientanwendungen nicht wissen, dass die Arbeit von einem anderen Knoten bereitgestellt wird.

Eine VIP wird auch als Floating-IP-Adresse bezeichnet.

In Google Cloud werden VIPs etwas anders implementiert als bei lokalen Installationen, da bei einem Failover keine Gratuitous-ARP-Anfragen verwendet werden können, um die Änderung anzukündigen. Stattdessen können Sie eine VIP-Adresse für einen SAP-HA-Cluster mit einer der folgenden Methoden implementieren:

VIP-Implementierungen mit internem Passthrough-Network-Load-Balancer

Ein Load-Balancer verteilt den Nutzertraffic normalerweise auf mehrere Instanzen Ihrer Anwendungen, um die Arbeitslast auf mehrere aktive Systeme zu verteilen und vor einer Verlangsamung oder einem Ausfall auf einer einzelnen Instanz zu schützen.

Der interne Passthrough-Network-Load-Balancer bietet auch Failover-Unterstützung, die Sie zusammen mit Compute Engine-Systemdiagnosen verwenden können, um Fehler zu erkennen, Failover auszulösen und Traffic an ein neues primäres SAP-System in einem standardmäßigen HA-Cluster des Betriebssystems weiterzuleiten.

Die Failover-Unterstützung ist aus verschiedenen Gründen die empfohlene VIP-Implementierung. Dafür gibt es verschiedene Gründe:

  • Load-Balancing in Compute Engine bietet eine per SLA zugesagte Verfügbarkeit von 99,99 %.
  • Load-Balancing unterstützt Mehrzonencluster mit hoher Verfügbarkeit, die vor Zonenausfällen durch vorhersehbare zonenübergreifende Failover-Zeiten geschützt sind.
  • Die Verwendung des Load-Balancings reduziert die Zeit, die zum Erkennen und Auslösen eines Failovers erforderlich ist, normalerweise innerhalb von Sekunden nach dem Ausfall. Die gesamten Failover-Zeiten hängen von den Failover-Zeiten der einzelnen Komponenten im Hochverfügbarkeitssystem ab. Dazu können u. a. die Hosts, Datenbanksysteme und Anwendungssysteme gehören.
  • Load-Balancing vereinfacht die Clusterkonfiguration und reduziert Abhängigkeiten.
  • Im Gegensatz zu einer VIP-Implementierung, die Routen mit Load-Balancing verwendet, können Sie IP-Bereiche aus Ihrem eigenen VPC-Netzwerk verwenden, um sie nach Bedarf zu reservieren und zu konfigurieren.
  • Mit dem Load-Balancing lässt sich der Traffic bei geplanten Wartungsausfällen ganz einfach an ein sekundäres System weiterleiten.

Wenn Sie eine Systemdiagnose für eine Load-Balancer-Implementierung einer VIP erstellen, geben Sie den Hostport an, den die Systemdiagnose prüft, um die Integrität des Hosts zu ermitteln. Geben Sie für einen SAP HA-Cluster einen Zielhostport im privaten Bereich (49152–65535) an, damit keine Probleme mit anderen Diensten auftreten. Konfigurieren Sie auf der Host-VM den Zielport mit einem sekundären Hilfsdienst wie dem Socat-Dienstprogramm oder HAProxy.

Bei Datenbankclustern, in denen das sekundäre Standby-System online bleibt, aktivieren die Systemdiagnose und der Hilfsdienst das Load-Balancing, um Traffic an das Onlinesystem weiterzuleiten, das derzeit als primäres System im Cluster dient.

Mit dem Hilfsdienst und der Portweiterleitung können Sie einen Failover für geplante Softwarewartungen auf Ihren SAP-Systemen auslösen.

Weitere Informationen zur Unterstützung von Failover finden Sie unter Failover für internen Passthrough-Network-Load-Balancer konfigurieren.

Informationen zum Bereitstellen eines Clusters für Hochverfügbarkeit mit einer VIP-Implementierung des Load-Balancers finden Sie unter:

Statische Routen-VIPs implementieren

Die Implementierung einer statischen Route bietet auch Schutz vor Zonenausfällen, erfordert jedoch die Verwendung einer VIP außerhalb der IP-Bereiche Ihrer vorhandenen VPC-Subnetze, in denen sich die VMs befinden. Daher darf die VIP nicht mit externen IP-Adressen in Ihrem erweiterten Netzwerk in Konflikt stehen.

Statische Routenimplementierungen können außerdem komplex sein, wenn sie mit freigegebenen VPC-Konfigurationen verwendet werden, mit denen die Netzwerkkonfiguration in ein Hostprojekt unterteilt werden soll.

Wenn Sie eine statische Routenimplementierung für Ihre VIP verwenden, wenden Sie sich an Ihren Netzwerkadministrator, um eine geeignete IP-Adresse für die Implementierung einer statischen Route zu finden.

Alias-IP-VIP implementieren

Die Implementierung von Alias-IP-VIP wird für Mehrzonen-HA-Bereitstellungen nicht empfohlen, da bei einem Ausfall einer Zone die Neuzuweisung der Alias-IP zu einem Knoten in einer anderen Zone verzögert werden kann. Implementieren Sie Ihre VIP stattdessen mit einem internen Passthrough-Netzwerk-Load-Balancer mit Failover-Unterstützung.

Wenn Sie alle Knoten Ihres SAP-HA-Clusters in derselben Zone bereitstellen, können Sie eine Alias-IP verwenden, um eine VIP für den HA-Cluster zu implementieren.

Wenn Sie bestehende SAP-HA-Cluster mit mehreren Zonen haben, die eine Alias-IP-Implementierung für die VIP verwenden, können Sie zu einer Implementierung eines internen Passthrough-Network-Load-Balancers migrieren, ohne Ihre VIP-Adresse zu ändern. Sowohl Alias-IP-Adressen als auch interne Passthrough-Netzwerk-Load-Balancer verwenden IP-Bereiche aus Ihrem VPC-Netzwerk.

Alias-IP-Adressen werden für VIP-Implementierungen in Mehrzonen-HA-Clustern zwar nicht empfohlen, werden jedoch anderweitig für SAP-Bereitstellungen genutzt. Sie können beispielsweise verwendet werden, um einen logischen Hostnamen und IP-Zuweisungen für flexible SAP-Bereitstellungen zur Verfügung zu stellen, z. B. diejenigen, die von SAP Landscape Management verwaltet werden.

Allgemeine Best Practices für VIPs in Google Cloud

Weitere Informationen zu VIPs in Google Cloud finden Sie unter Best Practices für Floating-IP-Adressen.

Hochverfügbarkeitscluster für SAP NetWeaver in Google Cloud konfigurieren

Google Cloud bietet eine Terraform-Konfigurationsdatei, mit der Sie die Bereitstellung von SAP NetWeaver-Hochverfügbarkeits-Systemen automatisieren oder Ihre SAP NetWeaver-Hochverfügbarkeits-Systeme manuell bereitstellen und konfigurieren können.

Um die Bereitstellung von SAP NetWeaver-Hochverfügbarkeits-Systemen zu automatisieren, schließen Sie die Terraform-Konfigurationsdatei ab und verwenden die Standard-Terraform-Befehle, um die Konfigurationen anzuwenden. Eine Anleitung zur Bereitstellung finden Sie unter:

Die automatisierte Bereitstellungsmethode stellt die Google Cloud-Infrastruktur für ein SAP NetWeaver-System bereit, das von SAP vollständig unterstützt wird und die Best Practices von SAP sowie von Google Cloud berücksichtigt.

Für SAP NetWeaver stellt die automatisierte Bereitstellungsmethode einen leistungsoptimierten Linux-Hochverfügbarkeitscluster bereit, der Folgendes beinhaltet:

  • Automatisches Failover.
  • Automatischer Neustart.
  • Eine Reservierung der von Ihnen angegebenen virtuellen IP-Adresse (VIP).
  • Failover-Unterstützung durch internes TCP/UDP-Load-Balancing, das das Routing von der virtuellen IP-Adresse (VIP) zu den Knoten des HA-Clusters verwaltet
  • Eine Firewallregel, mit der Compute Engine-Systemdiagnosen die VM-Instanzen im Cluster überwachen können.
  • Hochverfügbarkeitsclusterressourcen-Manager von Pacemaker
  • Ein Google Cloud-Fencing-Mechanismus, den Fencing-Agent fence_gce.
  • VM mit den erforderlichen nichtflüchtigen Speichern für jede SAP NetWeaver-Instanz

Eine Anleitung zum Bereitstellen und manuellen Konfigurieren eines Hochverfügbarkeitsclusters in Google Cloud für SAP NetWeaver finden Sie unter: