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:

• Best-Practices-Dokument von SAP zur Schaffung von Hochverfügbarkeit für SAP NetWeaver und SAP HANA unter Linux
• SAP HANA-Dokumentation

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 der folgenden Tabelle werden SAP- und Google Cloud-Features beschrieben, mit denen Hochverfügbarkeit erzielt werden kann.

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:

• Manuelle Konfiguration eines vertikal skalierbaren HA-Clusters in RHEL
• Manuelle HA-Clusterkonfiguration in SLES:
  • Bereitstellung skalieren
  • Horizontale Bereitstellung

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 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-Agents

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.

Google Cloud stellt zwei Fencing-Agents für die Verwendung mit SAP auf Linux-Betriebssystemen zur Verfügung: den Agent fence_gce, der in zertifizierten Red Hat- und SUSE-Linux-Distributionen enthalten ist, und den Legacy-Agent gcpstonith, den Sie auch für die Verwendung mit Linux-Distributionen herunterladen können, die den Agent fence_gce nicht enthalten. Wir empfehlen, den fence_gce-Agenten zu verwenden, sofern verfügbar.

Erforderliche IAM-Berechtigungen für Fencing-Agents

Die Fencing-Agents starten VMs neu. Dazu richten sie einen Aufruf zum Zurücksetzen an die Compute Engine-API. Zur Authentifizierung und Autorisierung für den Zugriff auf die API verwenden die Fence-Agents das Dienstkonto der VM. Das Dienstkonto, das ein Fence-Agent verwendet, muss mit einer Rolle ausgestattet sein, die die folgenden Berechtigungen enthält:

• compute.instances.get
• compute.instances.list
• compute.instances.reset
• compute.instances.start
• compute.instances.stop
• compute.zoneOperations.get
• logging.logEntries.create
• compute.zoneOperations.list

Die vordefinierte Rolle "Compute-Instanzadministrator" enthält alle erforderlichen Berechtigungen.

Um den Umfang der Neustartberechtigung des Agents auf den Zielknoten zu beschränken, können Sie den ressourcenbasierten Zugriff konfigurieren. Weitere Informationen finden Sie unter Ressourcenbasierten Zugriff konfigurieren.

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 Folgendes verwenden: Filestore oder die Dateifreigabelösung eines Drittanbieters wie den NetApp Cloud Volumes-Dienst für Google Cloud. 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.

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:

• Dateiserver in Compute Engine
• Compute Engine-Speicheroptionen

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 Automatisierungsskripts verwenden, werden die empfohlenen Werte für Sie 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.

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

• RHEL: Standardeinstellungen für „corosync.conf“ bearbeiten
• SLES: Corsync-Konfigurationsdateien erstellen

Zeitüberschreitung und Intervalleinstellungen für Clusterressourcen

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.

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.

Einstellungen für Fencing-Ressourcen

In den Konfigurationsleitfäden für HA-Cluster für SAP HANA empfiehlt Google Cloud mehrere Parameter für die Konfiguration der Ressourcen für das Fencing des HA-Clusters. Die empfohlenen Werte unterscheiden sich von den Standardwerten, die von Corosync oder Ihrem Linux-Betriebssystem-Verteiler festgelegt werden.

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

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 Wartungsereignis mit dem Google Cloud CLI-Befehl gcloud compute instances simulate-maintenance-event simulieren.

Logging und Monitoring

Ressourcen-Agents können Logging-Funktionen enthalten, die Logs zur Analyse an Google Cloud Observability 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:

• 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:

• Failover-Unterstützung für internen Passthrough-Netzwerk-Load-Balancer (empfohlen)
• Statische Google Cloud-Routen
• Alias-IP-Adressen von Google Cloud.

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:

• Terraform: Konfigurationsleitfaden für SAP HANA-Hochverfügbarkeitscluster
• Konfigurationsleitfaden: Hochverfügbarkeitscluster für SAP HANA unter RHEL
• Konfigurationsanleitung für Hochverfügbarkeitscluster für SAP HANA unter SLES

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.

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.

Unterstützte Versionen des Storage-Managers für SAP HANA

Versionen 2.0 und höher des Storage-Managers für SAP HANA werden unterstützt. Alle Versionen vor 2.0 wurden verworfen und werden nicht unterstützt. Aktualisieren Sie Ihr SAP HANA-System so, dass die neueste Version des Speichermanagers für SAP HANA verwendet wird, wenn Sie eine ältere Version verwenden. Siehe Storage Manager für SAP HANA aktualisieren.

Ö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. Sehen Sie sich eine verworfene Version des Storage-Managers für SAP HANA an, wenn die Versionsnummer fehlt.

"""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 Compute Engine.

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 für die Installation des Speichermanagers für SAP HANA ist die Verwendung einer automatisierten Bereitstellungsmethode, 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 Terraform-Konfigurationsdatei oder 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 keine automatisierte Bereitstellungsmethode verwenden können, sollten Sie sich an einen SAP-Lösungsberater wenden, der Ihnen bei der manuellen Installation des Storage Managers für SAP HANA hilft, z. B. über die Google Cloud Consulting-Dienste.

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 zu den automatisierten Bereitstellungsoptionen für das automatische Failover des SAP HANA-Hosts finden Sie unter Automatisierte 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 Terraform-Konfigurationsdatei oder die von Google Cloud bereitgestellte Deployment Manager-Vorlage verwenden, um ein SAP HANA-System mit der automatischen Failover-Funktion des Hosts bereitzustellen, fügt der Bereitstellungsprozess die Konfigurationsparameter für Sie zur Datei global.ini hinzu.

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_*_*__gcloudAccount = svc-acct-name@project-id.iam.gserviceaccount.com
# partition_*_data__mountOptions = -t xfs -o logbsize=256k
# partition_*_log__mountOptions = -t xfs -o logbsize=256k
# partition_*_*__fencing = disabled

[trace]
ha_gcestorageclient = info

Sudo-Zugriff für den Speichermanager für SAP HANA

Zur Verwaltung von SAP HANA-Diensten und -Speicher verwendet der Speichermanager für SAP HANA das Nutzerkonto SID_LCadm und benötigt Sudo-Zugriff auf bestimmte Systembinärdateien.

Wenn Sie die von Google Cloud bereitgestellten Automatisierungsskripts zum Bereitstellen von SAP HANA mit automatischem Host-Failover verwenden, wird der erforderliche Sudo-Zugriff für Sie konfiguriert.

Wenn Sie den Speichermanager für SAP HANA manuell installieren, verwenden Sie den Befehl visudo, um die Datei /etc/sudoers zu bearbeiten und dem Nutzerkonto SID_LCadm Sudo-Zugriff auf die folgenden erforderlichen Binärdateien zu gewähren.

Klicken Sie auf den Tab für Ihr Betriebssystem:

/bin/kill
/bin/mount
/bin/umount
/sbin/dmsetup
/sbin/lvdisplay
/sbin/lvscan
/sbin/pvscan
/sbin/vgchange
/sbin/vgscan
/usr/bin/gcloud
/usr/bin/lsof
/usr/bin/mkdir
/usr/bin/sg_persist
/usr/bin/systemctl
/usr/sbin/lsof
/usr/sbin/xfs_repair

/bin/kill
/bin/mount
/bin/umount
/sbin/dmsetup
/sbin/lvdisplay
/sbin/lvscan
/sbin/pvscan
/sbin/vgchange
/sbin/vgscan
/sbin/xfs_repair
/usr/bin/gcloud
/usr/bin/lsof
/usr/bin/mkdir
/usr/bin/sg_persist
/usr/bin/systemctl
/usr/sbin/lsof

Das folgende Beispiel zeigt einen Eintrag in der Datei /etc/sudoers. Im Beispiel wird die System-ID des zugehörigen SAP HANA-Systems durch SID_LC ersetzt. Der Beispieleintrag wurde von der Deployment Manager-Vorlage erstellt, die durch die horizontale Skalierung von Google Cloud für SAP HANA mit automatischem Host-Failover bereitgestellt wird. Der von der Deployment Manager-Vorlage erstellte Eintrag enthält Binärdateien, die nicht mehr benötigt, aber für die Abwärtskompatibilität beibehalten werden. Sie müssen nur die Binärdateien aufnehmen, die in der vorherigen Liste aufgeführt sind.

SID_LCadm ALL=NOPASSWD: /sbin/multipath,/sbin/multipathd,/etc/init.d/multipathd,/usr/bin/sg_persist,/bin/mount,/bin/umount,/bin/kill,/usr/bin/lsof,/usr/bin/systemctl,/usr/sbin/lsof,/usr/sbin/xfs_repair,/sbin/xfs_repair,/usr/bin/mkdir,/sbin/vgscan,/sbin/pvscan,/sbin/lvscan,/sbin/vgchange,/sbin/lvdisplay,/usr/bin/gcloud,/sbin/dmsetup

Dienstkonto für den Speichermanager für SAP HANA konfigurieren

Wenn Sie das automatische Host-Failover für Ihr SAP HANA-System mit horizontaler Skalierung in Google Cloud aktivieren möchten, benötigt der Speichermanager für SAP HANA ein Dienstkonto. Sie können ein spezielles Dienstkonto erstellen und ihm die erforderlichen Berechtigungen zum Ausführen von Aktionen auf Ihren SAP HANA-VMs erteilen, z. B. zum Trennen und Verknüpfen von Laufwerken während eines Failovers. Informationen zum Erstellen eines Dienstkontos finden Sie unter Dienstkonto erstellen.

Erforderliche IAM-Berechtigungen

Für das Dienstkonto, das vom Speichermanager für SAP HANA verwendet wird, müssen Sie eine Rolle mit den folgenden IAM-Berechtigungen gewähren:

• Wenn Sie eine VM-Instanz mit dem Befehl gcloud compute instances reset zurücksetzen möchten, gewähren Sie die Berechtigung compute.instances.reset.

• Wenn Sie mit dem Befehl gcloud compute disks describe Informationen zu einem Persistent Disk- oder Hyperdisk-Volume abrufen möchten, gewähren Sie die Berechtigung compute.disks.get.

• Wenn Sie ein Laufwerk mit dem Befehl gcloud compute instances attach-disk an eine VM-Instanz anhängen möchten, gewähren Sie die Berechtigung compute.instances.attachDisk.

• Wenn Sie ein Laufwerk mit dem Befehl gcloud compute instances detach-disk von einer VM-Instanz trennen möchten, gewähren Sie die Berechtigung compute.instances.detachDisk.

• Wenn Sie VM-Instanzen mit dem Befehl gcloud compute instances list auflisten möchten, gewähren Sie die Berechtigung compute.instances.list.

• Wenn Sie die Persistent Disk- oder Hyperdisk-Volumes mit dem Befehl gcloud compute disks list auflisten möchten, gewähren Sie die Berechtigung compute.disks.list.

Sie können die erforderlichen Berechtigungen über benutzerdefinierte Rollen oder andere vordefinierte Rollen gewähren.

Legen Sie außerdem den Zugriffsbereich der VM auf cloud-platform fest, damit die IAM-Berechtigungen der VM vollständig durch die IAM-Rollen bestimmt werden, die Sie dem Dienstkonto zuweisen.

Standardmäßig verwendet der Speichermanager für SAP HANA das aktive Dienstkonto oder Nutzerkonto, das die gcloud CLI auf den Hosts im skalierbaren SAP HANA-System verwenden darf.

Mit dem folgenden Befehl können Sie das aktive Konto prüfen, das vom Speichermanager für SAP HANA verwendet wird:

gcloud auth list

Weitere Informationen zu diesem Befehl finden Sie unter gcloud auth list.

So ändern Sie das Konto, das vom Speichermanager für SAP HANA verwendet wird:

1. Achten Sie darauf, dass das Dienstkonto auf jedem der Hosts im SAP HANA-System mit horizontaler Skalierung verfügbar ist:

     gcloud auth list
   

2. Aktualisieren Sie in der Datei global.ini den Abschnitt [storage] mit dem Dienstkonto:

   [storage]
   ha_provider = gceStorageClient
   ...
   partition_*_*__gcloudAccount = SERVICE_ACCOUNT
   

   Ersetzen Sie SERVICE_ACCOUNT durch den Namen des Dienstkontos im E-Mail-Adressformat, das vom Speichermanager für SAP HANA verwendet wird. Dieses Dienstkonto wird verwendet, wenn gcloud-Befehle vom Speichermanager für SAP HANA ausgeführt werden.

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 eine automatisierte Bereitstellungsmethode verwenden, geben Sie in der Bereitstellungsdatei Informationen zum NFS-Server an, um während der Bereitstellung die NFS-Verzeichnisse bereitzustellen.

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

Der Bereitstellungsprozess 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 nach Abschluss der Bereitstellung vom NFS-Server entfernen.

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

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

• RHEL für SAP 7.7 oder höher
• RHEL für SAP 8.1 oder höher
• RHEL für SAP 9.0 oder höher
  • Bevor Sie SAP-Software unter RHEL für SAP 9.x installieren, müssen Sie zusätzliche Pakete auf Ihren Hostcomputern installieren, insbesondere chkconfig und compat-openssl11. Wenn Sie ein von Compute Engine bereitgestelltes Image verwenden, werden diese Pakete automatisch für Sie installiert. Weitere Informationen von SAP finden Sie im SAP-Hinweis 3108316 – Red Hat Enterprise Linux 9.x: Installation und Konfiguration.
• SLES für SAP 12 SP5
• SLES für SAP 15 SP1 oder höher

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.

Bereitstellungsoptionen für SAP HANA-Hochverfügbarkeitskonfigurationen

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

Für die automatisierte Bereitstellung von SAP HANA-HA-Systemen können Sie entweder Terraform oder Deployment Manager verwenden.

Google Cloud bietet bereitgestellte Terraform-Konfigurationsdateien. Sie initialisieren mit Ihrem Terraform-Standardbefehl Ihr aktuelles Arbeitsverzeichnis, laden das Terraform-Plug-in und die Moduldateien für Google Cloud herunter und wenden die Konfiguration zum Bereitstellen eines SAP HANA-Systems an.

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.

Mit diesen automatisierten Bereitstellungsmethoden wird ein SAP HANA-System bereitgestellt, 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 stellen die automatisierten Bereitstellungsmethoden einen leistungsoptimierten Linux-Hochverfügbarkeitscluster bereit, der Folgendes enthält:

• 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.

Sie können eine der folgenden Bereitstellungsmethoden zum Bereitstellen eines Hochverfügbarkeitsclusters für SAP HANA verwenden:

• Informationen zum Automatisieren der Bereitstellung eines Hochverfügbarkeitsclusters für SAP HANA mit Terraform finden Sie hier:

  • Terraform: Konfigurationsleitfaden für SAP HANA-Hochverfügbarkeitscluster mit vertikaler Skalierung
  • Terraform: Konfigurationsanleitung für SAP HANA-Hochverfügbarkeitscluster mit horizontaler Skalierung

• Informationen, um den Deployment Manager zur Automatisierung der Bereitstellung eines Hochverfügbarkeitsclusters für SAP HANA zu verwenden, finden Sie in der Konfigurationsanleitung für SAP HANA-Hochverfügbarkeitscluster mit vertikaler Skalierung.

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

Sie können eine der folgenden Bereitstellungsmethoden verwenden, um SAP HANA-Systeme mit horizontaler Skalierung und automatischem Host-Failover bereitzustellen:

• Informationen, um Terraform zur Automatisierung der Bereitstellung eines Systems mit horizontaler Skalierung und Standby-Hosts zu verwenden, finden Sie hier: Terraform: Bereitstellungsanleitung für SAP HANA-Systeme zur horizontalen Skalierung mit automatischem Host-Failover.

• Informationen, um den Deployment Manager zur Automatisierung der Bereitstellung eines Systems mit horizontaler Skalierung und Standby-Hosts zu verwenden. finden Sie in der Bereitstellungsanleitung für SAP HANA-Systeme zur horizontalen Skalierung mit automatischem Host-Failover.

Bei einem SAP HANA-System mit horizontaler Skalierung, das das Feature für automatischen Failover des SAP HANA-Hosts enthält, wird die automatisierte Bereitstellungsmethode bereitgestellt:

• 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
• Google Cloud Storage Manager für SAP HANA-Standby-Knoten

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 Terraform oder 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.

Option „Aktiv/Aktiv (Lesezugriff aktiviert)“ für SAP HANA

Ab SAP HANA 2.0 SPS1 bietet SAP die Konfiguration Aktiv/Aktiv (Lesezugriff aktiviert) für SAP HANA-Systemreplikationsszenarien an. In einem Replikationssystem, das für Aktiv/Aktiv (Lesezugriff aktiviert) konfiguriert ist, sind die SQL-Ports auf dem sekundären System für den Lesezugriff geöffnet. So können Sie das sekundäre System für Lese-intensiveaufgaben verwenden und die Arbeitslasten über die Rechenressourcen hinweg besser ausbalancieren, sodass die Gesamtleistung Ihrer SAP HANA-Datenbank verbessert wird. Weitere Informationen zur Funktion „Aktiv/Aktiv (Lesen aktiviert)“ finden Sie im Administratorhandbuch für SAP HANA, das für Ihre SAP HANA-Version spezifisch ist, und in SAP-Hinweis 1999880.

Wenn Sie eine Systemreplikation konfigurieren möchten, die den Lesezugriff auf das sekundäre System ermöglicht, müssen Sie den Betriebsmodus logreplay_readaccess verwenden. Um diesen Vorgangsmodus verwenden zu können, müssen Ihre primären und sekundären Systeme dieselbe SAP HANA-Version ausführen. Daher ist der schreibgeschützte Zugriff auf das sekundäre System während eines Rolling Upgrade erst möglich, wenn beide Systeme dieselbe SAP HANA-Version ausführen.

Zum Herstellen einer Verbindung zu einem sekundären Aktiv/Aktiv-System mit Lesezugriff unterstützt SAP folgende Optionen:

• Um eine direkte Verbindung herzustellen öffnen Sie eine explizite Verbindung zum sekundären System.
• Um eine indirekte Verbindung herzustellen führen Sie eine SQL-Anweisung auf dem primären System mit einem Hinweis aus, der die Anfrage nach der Auswertung zum sekundäre System umleitet.

Das folgende Diagramm zeigt die erste Option, bei der Anwendungen direkt in einem in Google Cloud bereitgestellten Pacemaker-Cluster auf das sekundäre System zugreifen. Eine zusätzliche Floating- oder virtuelle IP-Adresse (VIP) wird für die VM-Instanz verwendet, die als Teil des SAP HANA Pacemaker-Clusters als sekundäres System bereitgestellt wird. Die VIP folgt dem sekundären System und kann die Leselast bei einem unerwarteten Ausfall oder einer geplanten Wartung von einem Clusterknoten zu einem anderen verschieben. Informationen zu den verfügbaren Methoden zur Implementierung virtueller IP-Adressen finden Sie unter Implementierung virtueller IP-Adressen in Google Cloud.

Eine Anleitung zum Konfigurieren der SAP HANA-Systemreplikation mit Aktiv/Aktiv- (Lesezugriff aktiviert) in einem Pacemaker-Cluster:

• HANA Aktiv/Aktiv (Lesezugriff aktiviert) in einem SUSE Pacemaker-Cluster konfigurieren
• HANA Aktiv/Aktiv (Lesezugriff aktiviert) in einem Red Hat Pacemaker-Cluster konfigurieren

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 in der Betriebsanleitung für SAP HANA.

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:

• Hochverfügbarkeit für SAP HANA
• SAP-Hinweis 2057595 – FAQ: Hochverfügbarkeit für SAP HANA
• Systemreplikation für SAP HANA 2.0 durchführen
• Netzwerkempfehlungen für SAP HANA Systemreplikation