Leitfaden zur Planung der Hochverfügbarkeit für SAP HANA

Diese Anleitung bietet einen Überblick über die Optionen, Empfehlungen und allgemeinen Konzepte, die Sie kennen sollten, bevor Sie ein SAP HANA-System mit Hochverfügbarkeit (High Availability, HA) 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 HANA-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 für die Implementierung eines SAP HANA-HA-Systems erforderlich sind, finden Sie unter:

Dieser Planungsleitfaden konzentriert sich ausschließlich auf HA für SAP HANA und behandelt keine HA für Anwendungssysteme. Informationen zu HA für SAP NetWeaver finden Sie im Leitfaden zur Planung von Hochverfügbarkeit für SAP NetWeaver in Google Cloud.

Dieser Leitfaden ersetzt keine von SAP bereitgestellte Dokumentation.

Hochverfügbarkeitsoptionen für SAP HANA in Google Cloud

Sie können eine Kombination aus Google Cloud- und SAP-Features verwenden, um eine Hochverfügbarkeitskonfiguration für SAP HANA zu erstellen, die Ausfälle auf Infrastruktur- oder Softwareebene bewältigen kann. In den folgenden Tabellen werden SAP- und Google Cloud-Features beschrieben, mit denen Hochverfügbarkeit erzielt werden kann.

Option Beschreibung
Compute Engine-Live-Migration

Compute Engine überwacht den Status der zugrunde liegenden Infrastruktur und migriert Ihre Instanz automatisch von einem Wartungsereignis der Infrastruktur fort. Dabei ist kein Nutzereingriff erforderlich.

Compute Engine führt Ihre Instanz während der Migration wenn möglich weiter aus. Bei größeren Ausfällen kann es zu einer leichten Verzögerung zwischen dem Ausfall und der Verfügbarkeit der Instanz kommen.

In Systemen mit mehreren Hosts sind freigegebene Volumes, wie das in der Bereitstellungsanleitung verwendete Volume "/hana/shared", nichtflüchtige Speicher, die an die virtuelle Maschine (VM) angehängt sind, die den Master-Host hostet. Sie werden auf den Worker-Hosts per NFS bereitgestellt. Das NFS-Volume ist im Fall einer Live-Migration des Master-Hosts bis zu einige Sekunden lang nicht erreichbar. Nachdem der Master-Host neu gestartet wurde, funktioniert das NFS-Volume auf allen Hosts wieder und es wird automatisch mit dem normalen Betrieb fortgefahren.

Eine wiederhergestellte Instanz ist mit der ursprünglichen Instanz identisch, einschließlich der Instanz-ID, der privaten IP-Adresse, aller Instanzmetadaten und des gesamten Instanzspeichers. 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.

Automatischer SAP HANA-Dienstneustart

Automatischer SAP HANA-Dienstneustart ist eine von SAP bereitgestellte Lösung zur Wiederherstellung im Fall eines Fehlers.

In SAP HANA werden jederzeit viele konfigurierte Dienste für verschiedene Aktivitäten ausgeführt. Wenn einer dieser Dienste wegen eines Softwarefehlers oder menschlichen Versagens deaktiviert wird, startet die Watchdog-Funktion des automatischen SAP HANA-Dienstneustarts ihn automatisch neu. Nachdem der Dienst neu gestartet wurde, lädt er alle erforderlichen Daten wieder in den Arbeitsspeicher und setzt seine Arbeit fort.

SAP HANA-Sicherungen

Im Rahmen von SAP HANA-Sicherungen werden Kopien der Daten in Ihrer Datenbank erstellt, mit denen ein Zustand wiederhergestellt werden kann, den die Datenbank zu einer bestimmten Zeit hatte.

Weitere Informationen zum Verwenden von SAP HANA-Sicherungen in Google Cloud finden Sie im Leitfaden für den SAP HANA-Betrieb.

SAP HANA-Speicherreplikation

Die SAP HANA-Speicherreplikation bietet Unterstützung der Notfallwiederherstellung auf Speicherebene durch bestimmte Hardwarepartner. In Google Cloud wird die SAP HANA-Speicherreplikation nicht unterstützt. Sie können stattdessen Compute Engine-Snapshots nichtflüchtiger Speicher verwenden.

Weitere Informationen dazu, wie Sie mithilfe von Snapshots nichtflüchtiger Speicher SAP HANA-Systeme in Google Cloud sichern, finden Sie in der Betriebsanleitung für SAP HANA.

Automatischer SAP HANA-Host-Failover

Der automatische SAP HANA-Host-Failover ist eine lokale Lösung zur Wiederherstellung im Fall eines Fehlers, für die ein oder mehrere SAP HANA-Standby-Hosts in einem System mit horizontaler Skalierung erforderlich sind. Wenn einer der Haupthosts ausfällt, aktiviert der automatische Host-Failover automatisch den Standby-Host und startet den ausgefallenen Host als Standby-Host neu.

Weitere Informationen

SAP HANA-Systemreplikation

Die SAP HANA-Systemreplikation ermöglicht es Ihnen, ein oder mehrere Systeme zu konfigurieren, die in Hochverfügbarkeitsszenarien oder im Fall einer Notfallwiederherstellung die Aufgaben des primären Systems übernehmen. Sie können die Replikation an die Anforderungen in Bezug auf Leistung und Failover-Zeit anpassen.

Standardmäßige HA-Cluster für SAP HANA in Google Cloud

Das Linux-Betriebssystem-Clustering bietet Anwendungs- und Gast-Awareness für Ihren Anwendungsstatus und automatisiert Wiederherstellungsaktionen im Falle eines Ausfalls.

Obwohl die Grundsätze von Hochverfügbarkeitsclustern, die in Nicht-Cloud-Umgebungen angewendet werden, allgemein für Google Cloud gelten, gibt es einige Unterschiede bei der Implementierung, z. B. von Fencing und virtuellen IP-Adressen.

Sie können entweder Red Hat- oder SUSE-Hochverfügbarkeits-Distributionen von Linux für Ihren HA-Cluster für SAP HANA in Google Cloud verwenden.

Eine Anleitung zum Bereitstellen und manuellen Konfigurieren eines HA-Clusters in Google Cloud für SAP HANA finden Sie unter:

Informationen zu den Optionen für die automatisierte Bereitstellung, die von Google Cloud bereitgestellt werden, finden Sie unter Optionen für die automatische Bereitstellung für SAP HANA-Hochverfügbarkeitskonfigurationen.

Agents für Clusterressourcen

Sowohl Red Hat als auch SUSE stellen Ressourcen-Agents für Google Cloud mit ihren Hochverfügbarkeitskonfigurationen der Pacemaker-Clustersoftware bereit. Die Ressourcen-Agents für Google Cloud verwalten STONITH-Fencing, VIPs, die entweder mit Routen oder Alias-IP-Adressen implementiert werden, und Speicheraktionen.

Zur Bereitstellung von Aktualisierungen, die noch nicht in den Ressourcen-Agents des Basisbetriebssystems enthalten sind, stellt Google Cloud regelmäßig Companion-Ressourcen-Agents für Hochverfügbarkeitscluster für SAP zur Verfügung. Wenn diese Companion-Ressourcen-Agents erforderlich sind, enthalten die Google Cloud-Bereitstellungsverfahren einen Schritt zum Herunterladen.

Fencing

Das Fencing im Sinne des Betriebssystemclusterings der Google Cloud Compute Engine erfolgt in Form von STONITH, wodurch jedes Mitglied in einem Cluster mit zwei Knoten den anderen Knoten neu starten kann.

Die Ressourcen-Agents, die sowohl Red Hat als auch SUSE bereitstellen, ermöglichen die Verwaltung von STONITH-Fencing in Google Cloud.

Virtuelle IP-Adresse

Hochverfügbarkeitscluster für SAP in Google Cloud verwenden eine virtuelle oder Floating-IP-Adresse (VIP), damit der Netzwerktraffic bei einem Failover von einem Host zu einem anderen weitergeleitet wird.

Typische cloudunabhängige Bereitstellungen kündigen die Verschiebung und Neuzuweisung einer VIP zu einer neuen MAC-Adresse mit einem Gratuitous Address Resolution Protocol (ARP) an.

In Google Cloud nutzen Sie anstelle von Gratuitous-ARP-Anfragen eine der verschiedenen Methoden, um eine VIP in einem HA-Cluster zu verschieben und neu zuzuweisen. Empfohlen wird die Verwendung eines internen TCP/UDP-Load-Balancers. Je nach Ihren Anforderungen können Sie jedoch auch eine routenbasierte VIP-Implementierung oder eine Alias-IP-basierte VIP-Implementierung verwenden.

Weitere Informationen zur VIP-Implementierung in Google Cloud finden Sie unter Implementierung virtueller IP-Adressen in Google Cloud.

Speichern und Replizieren

Eine SAP HANA-HA-Clusterkonfiguration verwendet die synchrone SAP HANA-Systemreplikation, um die primäre und sekundäre SAP HANA-Datenbank zu synchronisieren. Die standardmäßigen, vom Betriebssystem bereitgestellten Ressourcen-Agents für SAP HANA verwalten die Systemreplikation während eines Failovers. Sie starten und beenden die Replikation und entscheiden, welche Instanzen im Replikationsprozess als aktive und als Standby-Instanzen ausgeführt werden.

Wenn Sie gemeinsam genutzten Dateispeicher benötigen, können NFS- oder SMB-basierte Filer die erforderlichen Funktionen bieten.

Für eine Hochverfügbarkeitslösung mit freigegebenem Speicher können Sie Dateifreigabelösungen von Drittanbietern wie NetApp Cloud Volumes verwenden. Google Cloud bietet eine NFS-Dateiserverlösung, Filestore, aber Filestore bietet derzeit keinen zonenübergreifend hochverfügbaren Dateiserver.

Regionale nichtflüchtige Compute Engine-Speicher bieten synchron replizierten Blockspeicher über mehrere Zonen hinweg. Regionale nichtflüchtige Speicher werden für den Datenbankspeicher in SAP-HA-Systemen zwar nicht unterstützt, Sie können sie aber mit NFS-Dateiservern verwenden.

Weitere Informationen zu Speicheroptionen in Google Cloud finden Sie unter:

Konfigurationseinstellungen für HA-Cluster in Google Cloud

Google Cloud empfiehlt, die Standardwerte bestimmter Clusterkonfigurationsparameter in Werte zu ändern, die für SAP-Systeme in der Google Cloud-Umgebung besser geeignet sind. Wenn Sie die von Google Cloud bereitgestellten Deployment Manager-Vorlagen verwenden, werden die empfohlenen Werte automatisch festgelegt.

Betrachten Sie die empfohlenen Werte als Ausgangspunkt für die Feinabstimmung der Corosync-Einstellungen in Ihrem HA-Cluster. Sie müssen bestätigen, dass die Fehlererkennung und die Auslösung des Failovers für Ihre Systeme und Arbeitslasten in der Google Cloud-Umgebung geeignet sind.

Corosync-Konfigurationsparameterwerte

In den Leitfäden zur HA-Clusterkonfiguration für SAP HANA empfiehlt Google Cloud Werte für mehrere Parameter im Abschnitt totem der Konfigurationsdatei corosync.conf, die sich von den Standardwerten unterscheiden, die von Corosync oder Ihrem Linux-Händler festgelegt werden.

In der folgenden Tabelle sind die von Google Cloud empfohlenen totem-Parameter sowie die empfohlenen Werte und die Auswirkungen der Änderung des Werts aufgeführt. Die Standardwerte für die Parameter, die bei Linux-Distributionen abweichen können, finden Sie in der Dokumentation zu Ihrer Linux-Distribution.

Parameter Empfohlener Wert Auswirkungen der Änderung
join 60 (ms) Erhöht, wie lange der Knoten im Mitgliedsprotokoll auf „Join“-Nachrichten wartet.
max_messages 20 Die maximale Anzahl von Nachrichten, die vom Knoten nach Erhalt des Tokens gesendet werden können.
token 20000 (ms)

Erhöht, wie lange der Knoten auf ein Totem-Protokolltoken wartet, bis er einen Tokenverlust deklariert, einen Knotenfehler annimmt und Maßnahmen ergreift.

Wenn Sie den Wert des Parameters „token“ erhöhen, wird der Cluster ausfallsicherer gegenüber kurzzeitigen Infrastrukturereignissen wie Live-Migrationen. Es kann jedoch länger dauern, bis der Cluster einen Knotenfehler erkennt und behebt.

Der Wert des Parameters „token“ bestimmt auch den Standardwert des Parameters „consensus“. Dieser Parameter steuert, wie lange ein Knoten auf die Erzielung von Einigkeit wartet, bis er versucht, die Konfigurationsmitgliedschaft wiederherzustellen. Wenn „consens“ nicht angegeben ist, legt Corosync den Wert auf das 1,2-Fache des Werts des Parameters „token“ fest.

token_retransmits_before_loss_const 10 Erhöht die Anzahl der Token-Übertragungsversuche, die der Knoten unternimmt, bis er davon ausgeht, dass der Empfängerknoten fehlgeschlagen ist, und Maßnahmen ergreift.

Weitere Informationen zum Konfigurieren der Datei corosync.conf finden Sie im Konfigurationsleitfaden für Ihre Linux-Distribution:

Zeitüberschreitung und Intervalleinstellungen

Wenn Sie eine Clusterressource definieren, legen Sie die Werte für interval und timeout für verschiedene Ressourcenvorgänge in Sekunden fest (op). Beispiel:

primitive rsc_SAPHanaTopology_HA1_HDB00 ocf:suse:SAPHanaTopology \
 operations \$id="rsc_sap2_HA1_HDB00-operations" \
 op monitor interval="10" timeout="600" \
 op start interval="0" timeout="600" \
 op stop interval="0" timeout="300" \
 params SID="HA1" InstanceNumber="00"

clone cln_SAPHanaTopology_HA1_HDB00 rsc_SAPHanaTopology_HA1_HDB00 \
 meta is-managed="true" clone-node-max="1" target-role="Started" interleave="true"

Die timeout-Werte wirken sich auf jeden der Ressourcenvorgänge unterschiedlich aus, wie in der folgenden Tabelle dargestellt.

Ressourcenvorgang Aktion bei Zeitüberschreitung
monitor Wird das Zeitlimit überschritten, meldet der Monitoring-Status normalerweise als fehlgeschlagen und die zugehörige Ressource wird als fehlgeschlagen angesehen. Der Cluster versucht, Wiederherstellungsoptionen zu nutzen, die ein Failover beinhalten können. Der Cluster wiederholt einen fehlgeschlagenen Monitoringvorgang nicht.
start Wenn eine Ressource nicht vor Beginn der Zeitüberschreitung gestartet werden kann, versucht der Cluster, die Ressource neu zu starten. Dieses Verhalten wird durch die On-Failure-Aktion vorgegeben, die mit einer Ressource verknüpft ist.
stop Wenn eine Ressource nicht auf einen Stoppvorgang reagiert, bevor das Zeitlimit erreicht ist, wird dadurch ein Fencing-Ereignis (STONITH) ausgelöst.

Neben anderen Einstellungen für die Clusterkonfiguration steuern die Einstellungen interval und timeout der Clusterressourcen, wie schnell die Clustersoftware einen Fehler erkennt und ein Failover auslöst.

Die timeout- und interval-Werte, die von Google Cloud in den Cluster-Konfigurationsanleitungen für das SAP HANA-Konto zur Wartung der Live-Migration von Compute Engine vorgeschlagen werden.

Unabhängig davon, welche timeout- und interval-Werte Sie verwenden, müssen Sie die Werte beim Testen des Clusters auswerten, insbesondere bei Live-Migrationstests, da die Länge von Live-Migrationsereignissen geringfügig variieren kann – abhängig vom verwendeten Maschinentyp und anderen Faktoren wie der Systemauslastung.

HA-Cluster in Google Cloud testen

Nachdem der Cluster konfiguriert wurde und zusammen mit den SAP HANA-Systemen in Ihrer Testumgebung bereitgestellt wurde, müssen Sie den Cluster testen, um zu prüfen, ob das HA-System richtig konfiguriert ist und wie erwartet funktioniert.

Simulieren Sie verschiedene Fehlerszenarien mit den folgenden Aktionen, um zu prüfen, ob das Failover erwartungsgemäß funktioniert:

  • VM herunterfahren
  • Kernel Panic erstellen
  • Anwendung herunterfahren
  • Netzwerk zwischen Instanzen trennen

Simulieren Sie außerdem ein Compute Engine-Live-Migrationsereignis auf dem primären Host, um zu bestätigen, dass kein Failover ausgelöst wird. Sie können ein Failover-Ereignis mit dem Cloud SDK-Befehl gcloud compute instances simulate-maintenance-event simulieren.

Logging und Monitoring

Ressourcen-Agents können Logging-Funktionen enthalten, die Logs zur Analyse an die Operations Suite von Google Cloud weiterleiten. Jeder Ressourcen-Agent enthält Konfigurationsinformationen, mit denen Logging-Optionen identifiziert werden. Bei Bash-Implementierungen ist die Logging-Option gcloud logging.

Sie können auch den Cloud Logging-Agent installieren, um die Logausgabe von Betriebssystemprozessen zu erfassen und die Ressourcenauslastung mit Systemereignissen zu verknüpfen. Der Logging-Agent erfasst Standardsystemlogs, die Logdaten von Pacemaker und den Clustering-Diensten enthalten. Weitere Informationen finden Sie unter Informationen zum Logging-Agent.

Informationen zur Verwendung von Cloud Monitoring zum Konfigurieren von Dienstprüfungen, die die Verfügbarkeit von Dienstendpunkten überwachen, finden Sie unter Verfügbarkeitsdiagnosen verwalten.

Dienstkonten und Cluster mit Hochverfügbarkeit

Die Aktionen, die die Clustersoftware in der Google Cloud-Umgebung ausführen kann, werden durch die Berechtigungen geschützt, die dem Dienstkonto jeder Host-VM zugewiesen werden. In Hochsicherheitsumgebungen können Sie die Berechtigungen für die Dienstkonten Ihrer Host-VMs so einschränken, dass sie dem Prinzip der geringsten Berechtigung entsprechen.

Wenn Sie die Dienstkontoberechtigungen einschränken, beachten Sie, dass Ihr System möglicherweise mit Google Cloud-Diensten wie Cloud Storage interagieren kann. Daher müssen Sie möglicherweise Berechtigungen für diese Dienstinteraktionen im Dienstkonto von Host-VM einschließen.

Wenn Sie die restriktivsten Berechtigungen erteilen möchten, erstellen Sie eine benutzerdefinierte Rolle mit den erforderlichen Mindestberechtigungen. Informationen zu benutzerdefinierten Rollen finden Sie unter Benutzerdefinierte Rollen erstellen und verwalten. Sie können Berechtigungen weiter einschränken, indem Sie sie auf bestimmte Instanzen einer Ressource beschränken, z. B. auf die VM-Instanzen Ihres Hochverfügbarkeitsclusters. Fügen Sie dazu Bedingungen in den Rollenbindungen der IAM-Richtlinie einer Ressource hinzu.

Die Mindestberechtigungen, die Ihre Systeme benötigen, hängen von den Google Cloud-Ressourcen ab, auf die Ihre Systeme zugreifen, und von den Aktionen, die sie ausführen. Daher müssen Sie bei der Ermittlung der erforderlichen Mindestberechtigungen für die Host-VMs in Ihrem Hochverfügbarkeitscluster möglicherweise genau untersuchen, auf welche Ressourcen die Systeme auf der Host-VM zugreifen und welche Aktionen sie bei diesen Ressourcen ausführen.

In der folgenden Liste werden einige HA-Clusterressourcen und die damit verbundenen Berechtigungen aufgeführt:

  • STONITH-Fencing
    • compute.instances.list
    • compute.instances.get
    • compute.instances.reset
    • compute.instances.stop
    • compute.instances.start
    • logging.logEntries.create
    • compute.zones.list
  • VIP, die mithilfe einer Alias-IP implementiert wurde
    • compute.instances.list
    • compute.instances.get
    • compute.zones.list
    • logging.logEntries.create
    • compute.instances.updateNetworkInterface
    • compute.zoneOperations.get
    • logging.logEntries.create
  • VIP, die mit statischen Routen implementiert wurde
    • compute.instances.list
    • compute.instances.get
    • compute.zones.list
    • logging.logEntries.create
    • compute.routes.get
    • compute.routes.create
    • compute.routes.delete
    • compute.routes.update
    • compute.routes.list
    • compute.networks.updatePolicy
    • compute.networks.get
    • compute.globalOperations.get
    • logging.logEntries.create
  • VIP, die mithilfe eines internen Load-Balancers implementiert wurde
    • Es sind keine speziellen Berechtigungen erforderlich: Der Load-Balancer verarbeitet Systemdiagnosestatus, bei denen der Cluster nicht mit Ressourcen in Google Cloud interagieren oder diese ändern muss

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 für das interne TCP/UDP-Load-Balancing

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 TCP/UDP-Load-Balancing-Dienst 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 des internen TCP/UDP-Load-Balancings wird aus verschiedenen Gründen als VIP-Implementierung empfohlen. Dazu gehören:

  • 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 Failover-Unterstützung des internen TCP/UDP-Load-Balancings finden Sie unter Failover für internes TCP/UDP-Load-Balancing 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 internem TCP/UDP-Load-Balancing 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 des internen TCP/UDP-Load-Balancings migrieren, ohne Ihre VIP-Adresse zu ändern. Sowohl die Alias-IP als auch das interne TCP/UDP-Load-Balancing 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.

Automatischer SAP HANA-Host-Failover in Google Cloud

Google Cloud unterstützt den automatischen SAP HANA-Host-Failover, die von SAP HANA bereitgestellte lokale Lösung zur Wiederherstellung im Fall eines Fehlers. Die Lösung für automatischen Host-Failover verwendet einen oder mehrere Standby-Hosts, die in Reserve gehalten werden, um im Fall eines Hostfehlers die Aufgaben des Master-Hosts bzw. eines Worker-Hosts zu übernehmen. Die Standby-Hosts enthalten keine Daten und erledigen keine Arbeit.

Nach dem Abschluss eines Failovers wird der ausgefallene Host als Standby-Host neu gestartet.

SAP unterstützt in Systemen mit horizontaler Skalierung in Google Cloud bis zu drei Standby-Hosts. Diese werden nicht auf das Maximum von 16 aktiven Hosts angerechnet, die SAP in Systemen mit horizontaler Skalierung in Google Cloud unterstützt.

Weitere Informationen von SAP über die automatische Host-Failover-Lösung finden Sie unter Automatisches Host-Failover.

Wann wird der automatische SAP HANA-Host-Failover in Google Cloud verwendet?

Das automatische Failover des SAP HANA-Hosts schützt vor Fehlern, die einen einzelnen Knoten in einem SAP HANA-System mit horizontaler Skalierung beeinträchtigen, einschließlich folgender Fehler:

  • SAP HANA-Instanz
  • Das Hostbetriebssystem
  • Host-VM

In Bezug auf Ausfälle der Host-VM wird in Google Cloud der automatische Neustart (einschließlich der automatischen Host-Failover) in der Regel schneller wiederhergestellt. Durch die Live-Migration können Sie sowohl geplante als auch ungeplante VM-Ausfälle gemeinsam schützen. Für den VM-Schutz ist eine automatische SAP HANA-Host-Failover-Lösung nicht erforderlich.

Der automatische SAP HANA-Host-Failover schützt Sie nicht vor zonalen Fehlern, da alle Knoten eines SAP HANA-Systems mit horizontaler Skalierung in einer einzigen Zone bereitgestellt werden.

SAP HANA Host-Auto-Failover lädt keine SAP HANA-Daten in den Speicher von Standby-Knoten vor. Wenn also ein Standby-Knoten übernimmt, wird die Gesamtwiederherstellungszeit des Knotens hauptsächlich dadurch bestimmt, wie lange es dauert, die Daten in den Speicher des Standby-Knotens zu laden.

Erwägen Sie die Verwendung des automatischen Failovers des SAP HANA-Hosts in den folgenden Szenarien:

  • Ausfälle der Software oder des Betriebssystems eines SAP HANA-Knotens, die von Google Cloud möglicherweise nicht erkannt werden.
  • Lift-and-Shift-Migrationen, bei denen Sie Ihre lokale SAP HANA-Konfiguration reproduzieren müssen, bis Sie SAP HANA für Google Cloud optimieren können.
  • Wenn eine vollständig replizierte, zonenübergreifende Hochverfügbarkeitskonfiguration äußerst kostengünstig und Ihr Unternehmen tolerant ist:
    • Eine längere Wiederherstellung von Knoten aufgrund der Notwendigkeit, SAP HANA-Daten in den Arbeitsspeicher eines Standby-Knotens zu laden.
    • Das Risiko eines zonalen Ausfalls.

Speichermanager für SAP HANA

Die Volumes /hana/data und /hana/log werden nur auf dem Master-Host und den Worker-Hosts bereitgestellt. Bei einem Takeover verwendet die Lösung für automatischen Host-Failover die SAP HANA Storage Connector API und den Google Cloud Storage Manager für SAP HANA-Standby-Knoten, um die Volume-Bereitstellungen vom ausgefallenen Host in den Host-Standby zu verschieben.

In Google Cloud ist der Speichermanager für SAP HANA-Systeme erforderlich, wenn SAP HANA-Systeme mit automatischem SAP HANA-Host-Failover betrieben werden.

Einstellung von Version 1.n-Versionen des Storage-Managers für SAP HANA

Version 1.n-Versionen des Storage-Managers für SAP HANA wurden eingestellt.

Wenn Sie eine ältere Version als Version 2.0 verwenden, aktualisieren Sie Ihr SAP HANA-System auf die neueste Version des Speichermanagers für SAP HANA.

Öffnen Sie die Datei gceStorageClient.py, um festzustellen, ob Ihre Version veraltet ist. Das Standardinstallationsverzeichnis ist /hana/shared/gceStorageClient:

Ab Version 2.0 ist die Versionsnummer in den Kommentaren in der Datei gceStorageClient.py aufgeführt, wie im folgenden Beispiel gezeigt.

Wenn die Versionsnummer fehlt, sehen Sie eine verworfene Version 1.n des Speichermanagers für SAP HANA. Der Support für Version 1.n-Releases endet am 31. Dezember 2021.

"""Google Cloud Storage Manager for SAP HANA Standby Nodes.

The Storage Manager for SAP HANA implements the API from the SAP provided
StorageConnectorClient to allow attaching and detaching of disks when
running in GCE.

Build Date: Wed Jan 27 06:39:49 PST 2021
Version: 2.0.20210127.00-00

"""

Storage Manager für SAP HANA installieren

Die empfohlene Methode zum Installieren des Speichermanagers für SAP HANA ist die Verwendung der Deployment Manager-Vorlage, die von Google Cloud bereitgestellt wird, um ein SAP HANA-System mit horizontaler Skalierung bereitzustellen, das den neuesten Speichermanager für SAP HANA enthält.

Wenn Sie einem vorhandenen SAP HANA-System mit horizontaler Skalierung in Google Cloud ein automatisches Failover für den SAP HANA-Host hinzufügen möchten, ist der empfohlene Ansatz ähnlich: die von Google Cloud bereitgestellte Deployment Manager-Vorlage verwenden, ein neues horizontal skalierbares SAP HANA-System bereitstellen und die Daten anschließend aus dem vorhandenen System in das neue System laden. Zum Laden der Daten können Sie entweder die SAP HANA-Sicherungs- und Wiederherstellungsverfahren oder die SAP HANA-Systemreplikation verwenden, die die Ausfallzeiten begrenzen können. Weitere Informationen zur Systemreplikation finden Sie im SAP-Hinweis 2473002 – HANA-Systemreplikation zur Migration von horizontaler Skalierung verwenden.

Wenn Sie die Deployment Manager-Vorlage nicht verwenden können, sollten Sie sich mit einem SAP-Lösungsberater in Verbindung setzen, den Sie z. B. über Google Cloud Consulting-Dienste finden, um Hilfe bei der manuellen Installation des Speichermanagers für SAP HANA zu erhalten.

Die manuelle Installation von Speichermanager für SAP HANA in einem vorhandenen oder neuen SAP HANA-System mit horizontaler Skalierung ist derzeit nicht dokumentiert.

Weitere Informationen zur Deployment Manager-Vorlage für den automatischen SAP HANA-Host-Failover finden Sie unter Automatische Bereitstellung von SAP HANA-Systemen mit horizontaler Skalierung und automatischem SAP HANA-Host-Failover.

Storage Manager für SAP HANA aktualisieren

Zum Aktualisieren des Speichermanagers für SAP HANA müssen Sie zuerst das Installationspaket herunterladen und anschließend ein Installationsskript ausführen. Dadurch wird der Storage Manager für die SAP HANA-Ausführung im SAP HANA-Laufwerk /shared aktualisiert.

Das folgende Verfahren gilt nur für Version 2 des Speichermanagers für SAP HANA. Wenn Sie eine Version des Speichermanagers für SAP HANA verwenden, die vor dem 1. Februar 2021 heruntergeladen wurde, installieren Sie Version 2, bevor Sie den Speichermanager für SAP HANA aktualisieren.

So aktualisieren Sie den Speichermanager für SAP HANA:

  1. Überprüfen Sie die Version Ihres aktuellen Speichermanagers für SAP HANA:

    RHEL

    sudo yum check-update google-sapgcestorageclient

    SLES

    sudo zypper list-updates -r google-sapgcestorageclient
  2. Wenn ein Update vorhanden ist, installieren Sie dieses:

    RHEL

    sudo yum update google-sapgcestorageclient

    SLES

    sudo zypper update

    Der aktualisierte Speichermanager für SAP HANA ist in /usr/sap/google-sapgcestorageclient/gceStorageClient.py installiert.

  3. Ersetzen Sie die vorhandene gceStorageClient.py durch die aktualisierte Datei gceStorageClient.py:

    • Wenn sich Ihre vorhandene gceStorageClient.py-Datei in /hana/shared/gceStorageClient befindet, dem Standardinstallationsverzeichnis, aktualisieren Sie die Datei mit dem Installationsskript:

      sudo /usr/sap/google-sapgcestorageclient/install.sh
    • Wenn sich Ihre vorhandene gceStorageClient.py-Datei nicht in /hana/shared/gceStorageClient befindet, kopieren Sie die aktualisierte Datei in den selben Speicherort wie Ihre vorhandene Datei und ersetzen Sie die vorhandene Datei.

Konfigurationsparameter in der Datei global.ini

Bestimmte Konfigurationsparameter für den Speichermanager von SAP HANA, einschließlich der Aktivierung oder Deaktivierung von Fechten, werden im Abschnitt "Speicher" der SAP HANA-Datei global.ini gespeichert. Wenn Sie die von Google Cloud bereitgestellte Deployment Manager-Vorlage verwenden, um ein SAP HANA-System mit automatischer Host-Failover-Funktion bereitzustellen, fügen die Bereitstellungsskripte die Konfigurationsparameter für Sie in die Datei global.ini ein.

Das folgende Beispiel zeigt den Inhalt einer global.ini, die für den Storage Manager für SAP HANA erstellt wurde:

[persistence]
basepath_datavolumes = %BASEPATH_DATAVOLUMES%
basepath_logvolumes = %BASEPATH_LOGVOLUMES%
use_mountpoints = %USE_MOUNTPOINTS%
basepath_shared = %BASEPATH_SHARED%

[storage]
ha_provider = gceStorageClient
ha_provider_path = %STORAGE_CONNECTOR_PATH%

#
# Example configuration for 2+1 setup
#
# partition_1_*__pd = node-mnt00001
# partition_2_*__pd = node-mnt00002
# partition_3_*__pd = node-mnt00003
# partition_*_data__dev = /dev/hana/data
# partition_*_log__dev = /dev/hana/log
# partition_*_data__mountOptions = -t xfs -o logbsize=256k
# partition_*_log__mountOptions = -t xfs -o logbsize=256k
# partition_*_*__fencing = disabled

[trace]
ha_gcestorageclient = info

NFS-Speicher für den automatischen SAP HANA-Host-Failover

Ein SAP HANA-System mit horizontaler Skalierung und automatischem Host-Failover erfordert eine NFS-Lösung wie Filestore, um die Volumes /hana/shared und /hanabackup für alle Hosts freizugeben. Sie müssen die NFS-Lösung selbst einrichten.

Wenn Sie Deployment Manager verwenden, geben Sie Informationen zum NFS-Server in der Konfigurationsdatei template.yaml an, sodass Deployment Manager während der Bereitstellung die NFS-Verzeichnisse bereitstellen kann.

Das von Ihnen verwendete NFS-Volume muss leer sein. Vorhandene Dateien können einen Konflikt mit den Deployment Manager-Skripts verursachen, insbesondere wenn die Dateien oder Ordner auf die SAP-System-ID (SID) verweisen. Die Bereitstellungsskripts können nicht feststellen, ob die Dateien überschrieben werden können.

Deployment Manager speichert die Volumes /hana/shared und /hanabackup auf dem NFS-Server und stellt den NFS-Server auf allen Hosts bereit, einschließlich der Standby-Hosts. Der Master-Host verwaltet dann den NFS-Server.

Wenn Sie eine Sicherungslösung implementieren, z. B. den Cloud Storage Backint-Agent für SAP HANA, können Sie das Volume /hanabackup vom NFS-Server entfernen, nachdem Deployment Manager die Bereitstellung abgeschlossen hat.

Weitere Informationen zu den Lösungen für freigegebene Dateien, die in Google Cloud verfügbar sind, finden Sie unter Dateifreigabelösungen für SAP in Google Cloud.

Betriebssystemunterstützung

Derzeit unterstützt Google Cloud den automatischen SAP HANA-Host-Failover nur auf den folgenden Betriebssystemen:

  • RHEL für SAP 7.6 oder höher
  • RHEL für SAP 8.1 oder höher
  • SLES für SAP 12 SP2 oder höher
  • SLES for SAP 15 oder höher

für öffentliche SAP-Images, die über Compute Engine verfügbar sind. Welche öffentlichen Images über Compute Engine zur Verfügung stehen, erfahren Sie unter Images.

Architektur eines SAP HANA-Systems mit automatischem Host-Failover

Das folgende Diagramm zeigt eine Architektur mit horizontaler Skalierung in Google Cloud, die das SAP HANA-Host-Failover-Feature enthält. Im Diagramm wird der Speichermanager für SAP HANA durch den Namen der ausführbaren Datei gceStorageClient dargestellt.

Das Diagramm zeigt, dass Worker-Knoten 2 fehlschlägt und der Standby-Knoten übernimmt. Der Speichermanager für SAP HANA arbeitet mit der SAP Storage Connector API (nicht gezeigt), um die Laufwerke zu trennen, die die Volumes /hana/data und /hana/logs vom ausgefallenen Worker-Knoten enthalten. Stellen Sie sie auf dem Standby-Knoten noch einmal bereit, der dann zu Worker-Knoten 2 wird, während der ausgefallene Knoten zum Standby-Knoten wird.

Diagramm: Darstellung der Architektur eines SAP HANA-Systems mit horizontaler Skalierung, das automatischen Host-Failover unterstützt

Automatische Bereitstellung für SAP HANA-Hochverfügbarkeitskonfigurationen

Google Cloud bietet Deployment Manager-Vorlagen, mit denen Sie die Bereitstellung von SAP HANA-HA-Systemen automatisieren oder Ihre SAP HANA-HA-Systeme manuell bereitstellen können.

Die von Google Cloud bereitgestellten Deployment Manager-Vorlagen enthalten eine template.yaml-Konfigurationsdatei, die Sie ausfüllen müssen. Deployment Manager liest die Konfigurationsdatei und stellt ein SAP HANA-System bereit, das von SAP vollständig unterstützt wird und die Best Practices von SAP sowie von Google Cloud berücksichtigt.

Automatisierte Bereitstellung von Linux-Hochverfügbarkeitsclustern für SAP HANA

Für SAP HANA stellt Deployment Manager 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
  • Google Cloud-Fencing-Mechanismus
  • VM mit den erforderlichen nichtflüchtigen Speichern für jede SAP HANA-Instanz.
  • SAP HANA-Instanzen, die für die synchrone Replikation und Vorabladung von Arbeitsspeicher konfiguriert wurden.

Anleitungen für die automatisierte Bereitstellung finden Sie unter Automatisierte SAP HANA HA-Bereitstellung mit Load-Balancer-VIP-Implementierung.

Automatisierte Bereitstellung von SAP HANA-Systemen mit horizontaler Skalierung und automatischem SAP HANA-Host-Failover

Für ein SAP HANA-System mit horizontaler Skalierung, das das Feature für automatischen SAP HANA-Host-Failover beinhaltet, stellt Deployment Manager Folgendes bereit:

  • Eine SAP HANA-Master-Instanz
  • 1 bis 15 Worker-Hosts
  • 1 bis 3 Standby-Hosts
  • Eine VM für jeden SAP HANA-Host
  • Nichtflüchtige Speicher für den Master- und die Worker-Hosts

Ein SAP HANA-System mit horizontaler Skalierung und automatischem Host-Failover erfordert eine NFS-Lösung wie Filestore, um die Volumes /hana/shared und /hanabackup für alle Hosts freizugeben. Damit Deployment Manager während der Bereitstellung auch die NFS-Verzeichnisse bereitstellen kann, müssen Sie selbst die NFS-Lösung einrichten, bevor Sie das SAP HANA-System bereitstellen.

Sie können Filestore-NFS-Serverinstanzen schnell und problemlos anhand der Anleitung unter Instanzen erstellen einrichten.

Informationen dazu, wie Sie ein System mit horizontaler Skalierung und Standby-Hosts bereitstellen, finden Sie in der Bereitstellungsanleitung für SAP HANA-Systeme zur horizontalen Skalierung mit automatischem Host-Failover.

Nächste Schritte

Sowohl Google Cloud als auch SAP bieten weitere Informationen zur Hochverfügbarkeit.

Weitere Informationen von Google Cloud zur Hochverfügbarkeit

Weitere Informationen zur Hochverfügbarkeit für SAP HANA in Google Cloud finden Sie unter:

Allgemeine Informationen zum Schutz von Systemen in Google Cloud vor verschiedenen Ausfallszenarien finden Sie unter Robuste Systeme konzipieren.

Weitere Informationen von SAP zu SAP HANA-Hochverfügbarkeitsfeatures

Weitere Informationen von SAP zu SAP HANA-Hochverfügbarkeitsfeatures finden Sie in den folgenden Dokumenten: