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.

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:

Zeitüberschreitung und Intervalleinstellungen

Die Einstellungen für Zeitüberschreitungen und das Prüfintervall für Ressourcen-Agents und Clusterkonfiguration bestimmen, wie schnell die Clustersoftware einen Failover auslöst. Die Werte, die in der Google Cloud-Anleitung und der Automatisierung für Hochverfügbarkeitscluster verwendet werden, können sich leicht von den Standardwerten der Clustersoftware unterscheiden. In den meisten Fällen sollten jedoch beide Werte ausreichen. Sie können die Werte bei Bedarf anpassen. Testen Sie einfach die Werte, die Sie in Ihrer Umgebung verwenden, bevor Sie das System zur Nutzung freigeben.

Die von Google Cloud vorgeschlagenen Zeitüberschreitungs- und Prüfintervallwerte sind für die Wartung der Live-Migration von Google Cloud maßgeblich, deren Länge je nach verwendetem Maschinentyp und anderen Faktoren geringfügig abweichen kann. Weitere Informationen finden Sie unter Live-Migration.

Nachdem der Cluster bereitgestellt wurde, müssen Sie die Einstellungen testen. Lösen Sie dazu mit dem Cloud SDK-Befehl gcloud compute instances simulate-maintenance-event eine Live-Migration auf dem primären Host aus.

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-Balancing 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 Hochverfü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 einem internen 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.

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 das Compute Engine-gceStorageConnector-Plug-in, um diese Laufwerke vom ausgefallenen Host zum Standby-Host zu übertragen. Die Konfigurationsparameter des gceStorageConnector-Plug-ins, einschließlich der Information, ob das Fencing aktiviert oder deaktiviert ist, werden im Speicherabschnitt der SAP HANA-Datei "global.ini" gespeichert.

Die Volumes /hana/shared und /hanabackup werden auf einem NFS-Server gespeichert, der durch den Master-Host verwaltet und auf allen Hosts, einschließlich der Standby-Hosts, bereitgestellt wird.

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.

Derzeit unterstützt Google Cloud den automatischen SAP HANA-Host-Failover nur auf dem SUSE Linux Enterprise Server (SLES) für öffentliche SAP-Images, die über Compute Engine in den Image-Familien sles-12-sp3-sap und sles-12-sp2-sap verfügbar sind. Welche öffentlichen Images über Compute Engine zur Verfügung stehen, erfahren Sie unter Images.

Das folgende Diagramm zeigt eine Architektur mit mehreren Hosts in Google Cloud, die den automatischen SAP HANA-Host-Failover unterstützt. Im Diagramm fällt Worker-Host 2 aus und der Standby-Host übernimmt. Das gceStorageClient-Plug-in arbeitet mit der SAP Storage Connector API (nicht abgebildet) zusammen, um die Laufwerke zu trennen, die die Volumes /hana/data und /hana/logs des ausgefallenen Workers enthalten, und sie auf dem Standby-Host neu bereitzustellen. Der Standby-Host wird damit zu Worker-Host 2, während der ausgefallene Host zum Standby-Host wird.

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

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

  • Automatischen Failover
  • Automatischen Neustart
  • Synchrone Replikation
  • Vorabladen in den Arbeitsspeicher
  • Hochverfügbarkeitscluster-Ressourcenmanager von Pacemaker
  • Google Cloud-Fencing-Mechanismus
  • VM mit den erforderlichen nichtflüchtigen Speichern für jede SAP HANA-Instanz
  • SAP HANA-Instanz auf jeder VM

Weitere Informationen finden Sie im Bereitstellungsleitfaden für einen SAP HANA-Hochverfügbarkeitscluster.

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

Manuelle Bereitstellung von SAP HANA-Hochverfügbarkeitsclustern

Wenn Sie einen HA-Cluster manuell konfigurieren, müssen Ihre SAP HANA-Systeme die Anforderungen an den SAP-Support und die Best Practices erfüllen. Stellen Sie dazu zuerst die VMs und SAP HANA-Instanzen mithilfe der von Google Cloud zur Verfügung gestellten Deployment Manager-Vorlage bereit.

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

Weitere Informationen

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: