Konfigurationsanleitung für vertikale skalierbares Hochverfügbarkeitscluster für SAP HANA unter SLES

In dieser Anleitung erfahren Sie, wie Sie einen leistungsoptimierten SLES-Hochverfügbarkeitscluster (SUSE Linux Enterprise Server) für ein vertikal skalierbares SAP HANA-System in Google Cloud bereitstellen und konfigurieren.

Die Anleitung umfasst folgende Schritte:

• Internen Passthrough-Network-Load-Balancer konfigurieren, um Traffic bei einem Ausfall umzuleiten
• Pacemaker-Cluster unter SLES konfigurieren, um die SAP-Systeme und andere Ressourcen während eines Failovers zu verwalten

Diese Anleitung enthält auch Schritte zur Konfiguration der SAP HANA-Systemreplikation. Eine ausführliche Anleitung finden Sie in der SAP-Dokumentation.

Wenn Sie ein SAP HANA-System ohne Linux-Hochverfügbarkeitscluster oder einen Standby-Knotenhost bereitstellen möchten, verwenden Sie die Bereitstellungsanleitung für SAP HANA.

Informationen zum Konfigurieren eines Hochverfügbarkeitsclusters für SAP HANA unter Red Hat Enterprise Linux (RHEL) finden Sie in der Konfigurationsanleitung für Hochverfügbarkeitscluster für die vertikale Skalierung von SAP HANA unter RHEL.

Diese Anleitung richtet sich an fortgeschrittene SAP HANA-Nutzer, die mit Linux-Hochverfügbarkeitskonfigurationen für SAP HANA vertraut sind.

System, das in dieser Anleitung bereitgestellt wird

In dieser Anleitung stellen Sie zwei SAP HANA-Instanzen bereit und richten einen Hochverfügbarkeitscluster unter SLES ein. Sie stellen jede SAP HANA-Instanz auf einer Compute Engine-VM in einer anderen Zone innerhalb derselben Region bereit. Eine Hochverfügbarkeitsinstallation von SAP NetWeaver wird in dieser Anleitung nicht behandelt.

Der bereitgestellte Cluster enthält die folgenden Funktionen und Features:

• Zwei Host-VMs mit jeweils einer Instanz von SAP HANA
• Synchrone SAP HANA-Systemreplikation
• Hochverfügbarkeitsclusterressourcen-Manager von Pacemaker
• STONITH-Fencing-Mechanismus
• Automatischer Neustart der fehlgeschlagenen Instanz als neue sekundäre Instanz

In dieser Anleitung verwenden Sie die von Google Cloud zur Verfügung gestellten Cloud Deployment Manager-Vorlagen, um die Compute Engine-VMs und die SAP HANA-Instanzen bereitzustellen. Dadurch wird gewährleistet, dass die VMs und die SAP HANA-Basissysteme die Anforderungen der SAP-Unterstützung erfüllen und den aktuellen Best Practices entsprechen.

In dieser Anleitung wird SAP HANA Studio zum Testen der SAP HANA-Systemreplikation verwendet. Wenn Sie möchten, können Sie stattdessen auch SAP HANA Cockpit verwenden. Informationen zur Installation von SAP HANA Studio finden Sie hier:

• SAP HANA Studio auf einer Compute Engine-Windows-VM installieren
• Installations- und Aktualisierungsanleitung für SAP HANA Studio

Vorbereitung

Vor dem Erstellen eines SAP HANA-Hochverfügbarkeitsclusters sind die folgenden Voraussetzungen zu erfüllen:

• Sie haben den Planungsleitfaden für SAP HANA und den Planungsleitfaden für SAP HANA – Hochverfügbarkeit gelesen.
• Sie oder Ihre Organisation haben ein Google Cloud-Konto. Außerdem haben Sie ein Projekt für die SAP HANA-Bereitstellung erstellt. Informationen zum Erstellen von Google Cloud-Konten und -Projekten finden Sie unter Google-Konto einrichten in der Bereitstellungsanleitung für SAP HANA.
• Wenn Ihre SAP-Arbeitslast die Anforderungen an den Datenstandort, die Zugriffssteuerung oder die Supportmitarbeiter oder gesetzliche Anforderungen erfüllen muss, müssen Sie den erforderlichen Assured Workloads-Ordner erstellen. Weitere Informationen finden Sie unter Compliance und Steuerung der Datenhoheit für SAP in Google Cloud.

• Die SAP HANA-Installationsmedien sind in einem Cloud Storage-Bucket gespeichert, der in Ihrem Bereitstellungsprojekt und Ihrer Region verfügbar ist. Informationen zum Hochladen von SAP HANA-Installationsmedien in einen Cloud Storage-Bucket finden Sie in der Anleitung zur Bereitstellung von SAP HANA unter SAP HANA herunterladen.

• Wenn OS Login in den Projektmetadaten aktiviert ist, müssen Sie OS Login vorübergehend deaktivieren, bis die Bereitstellung abgeschlossen ist. Für die Bereitstellung konfiguriert dieses Verfahren SSH-Schlüssel in Instanzmetadaten. Bei aktiviertem OS Login sind metadatenbasierte SSH-Schlüsselkonfigurationen deaktiviert und diese Bereitstellung schlägt fehl. Nach Abschluss der Bereitstellung können Sie die OS Login-Funktion wieder aktivieren.

  Weitere Informationen finden Sie unter:

  • OS Login aktivieren oder deaktivieren
  • SSH-Schlüssel zu VMs hinzufügen, die metadatenbasierte SSH-Schlüssel verwenden

• Bei einem internen VPC-DNS muss der Wert der Variable vmDnsSetting in Ihren Projektmetadaten entweder GlobalOnly oder ZonalPreferred sein, damit die Knotennamen zonenübergreifend aufgelöst werden können. Die Standardeinstellung von vmDnsSetting ist ZonalOnly. Weitere Informationen finden Sie unter:

  • DNS-Namen für Projekte oder Instanzen konfigurieren
  • Benutzerdefinierte Metadaten abfragen
  • Benutzerdefinierte Metadaten für das gesamte Projekt einrichten

Folgen Sie diesen Empfehlungen, um zu vermeiden, dass Ihre VM-Instanz versehentlich im Internet veröffentlicht wird:

• Verwenden Sie ein NAT-Gateway.
• Erstellen Sie Firewallregeln, die den gesamten externen Zugriff blockieren, den Sie nicht benötigen.
• Gehen Sie beim Erstellen Ihrer VMs so vor:
  • Geben Sie für jede VM ein Netzwerk-Tag zur Verwendung in Routing- und Firewallregeln an. Wenn Sie die von Google Cloud bereitgestellte Deployment Manager-Vorlage nutzen, legen Sie Tags mit networkTag: [TAG] fest.
  • Erstellen Sie die VMs ohne externe IP-Adresse. Wenn Sie die von Google Cloud bereitgestellten Deployment Manager-Vorlagen verwenden, geben Sie publicIP: No an.

Netzwerk erstellen

Erstellen Sie aus Sicherheitsgründen ein neues Netzwerk. Durch das Festlegen von Firewallregeln oder die Nutzung eines anderen Verfahrens der Zugriffskontrolle steuern Sie, wer Zugriff hat.

Wenn Ihr Projekt ein Standard-VPC-Netzwerk (Virtual Private Cloud) hat, verwenden Sie es nicht. Erstellen Sie stattdessen Ihr eigenes VPC-Netzwerk, sodass nur die von Ihnen explizit formulierten Firewallregeln gelten.

Während der Bereitstellung müssen VM-Instanzen normalerweise auf das Internet zugreifen können, um den Google Cloud-Agent für SAP herunterzuladen. Wenn Sie eines der von SAP zertifizierten Linux-Images verwenden, die in Google Cloud verfügbar sind, benötigen die VM-Instanzen außerdem einen Internetzugang, um die Lizenz zu registrieren und auf Repositories von Betriebssystemanbietern zuzugreifen. Eine Konfiguration mit einem NAT-Gateway und VM-Netzwerk-Tags unterstützt diesen Zugriff selbst dann, wenn die Ziel-VMs keine externen IP-Adressen haben.

So richten Sie das Netzwerk ein:

Console

1. Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.

   Zur Seite VPC-Netzwerke

2. Klicken Sie auf VPC-Netzwerk erstellen.
3. Geben Sie einen Namen für das Netzwerk ein.

   Der Name muss der Namenskonvention entsprechen. VPC-Netzwerke verwenden die Namenskonvention von Compute Engine.

4. Wählen Sie unter Modus für Subnetzerstellung die Option Benutzerdefiniert aus.
5. Legen Sie im Abschnitt Neues Subnetz folgende Konfigurationsparameter für das Subnetz fest:
   1. Geben Sie einen Namen für das Subnetz ein.
   2. Wählen Sie unter Region die Compute Engine-Region aus, in der Sie das Subnetz erstellen möchten.
   3. Wählen Sie für IP-Stack-Typ die Option IPv4 (einzelner Stack) aus und geben Sie dann einen IP-Adressbereich im CIDR-Format ein, z. B. 10.1.0.0/24.

      Dies ist der primäre IPv4-Bereich für das Subnetz. Wenn Sie mehrere Subnetze erstellen möchten, weisen Sie den Subnetzen im Netzwerk nicht überlappende CIDR-IP-Adressbereiche zu. Beachten Sie, dass jedes Subnetz und seine internen IP-Adressbereiche einer einzelnen Region zugeordnet sind.

   4. Klicken Sie auf Fertig.
6. Klicken Sie auf Subnetz hinzufügen und wiederholen Sie die vorherigen Schritte, um weitere Subnetze zu erstellen. Sie können dem Netzwerk weitere Subnetze hinzufügen, nachdem Sie das Netzwerk erstellt haben.
7. Klicken Sie auf Erstellen.

gcloud

1. Rufen Sie Cloud Shell auf.

   Zu Cloud Shell

2. Führen Sie den folgenden Befehl aus, um ein neues Netzwerk im benutzerdefinierten Subnetzwerkmodus zu erstellen:

   gcloud compute networks create NETWORK_NAME --subnet-mode custom

   Ersetzen Sie NETWORK_NAME durch den Namen des neuen Clusters. Der Name muss der Namenskonvention entsprechen. VPC-Netzwerke verwenden die Namenskonvention von Compute Engine.

   Geben Sie --subnet-mode custom an und deaktivieren Sie so den standardmäßigen automatischen Modus. Ansonsten würde durch diesen Modus automatisch in jeder Compute Engine-Region ein Subnetz erstellt werden. Weitere Informationen dazu finden Sie unter Modus für Subnetzerstellung.

3. Erstellen Sie ein Subnetzwerk und geben Sie die Region und den IP-Adressbereich an:

   gcloud compute networks subnets create SUBNETWORK_NAME \
       --network NETWORK_NAME --region REGION --range RANGE

   Dabei gilt:

   • SUBNETWORK_NAME: der Name des neuen Subnetzwerks.
   • NETWORK_NAME: der Name des Netzwerks, das Sie im vorherigen Schritt erstellt haben.
   • REGION: die Region, in der sich das Subnetzwerk befinden soll
   • RANGE: der im CIDR-Format angegebene IP-Adressbereich, z. B. 10.1.0.0/24

     Wenn Sie mehrere Subnetzwerke hinzufügen möchten, weisen Sie den Subnetzwerken im Netzwerk nicht überlappende CIDR-IP-Adressbereiche zu. Beachten Sie, dass jedes Subnetzwerk und seine internen IP-Adressbereiche einer einzelnen Region zugeordnet sind.

4. Wiederholen Sie den vorherigen Schritt, falls Sie weitere Subnetze erstellen möchten.

NAT-Gateway einrichten

Wenn Sie eine oder mehrere VMs ohne öffentliche IP-Adressen erstellen müssen, müssen Sie die Network Address Translation (NAT) verwenden, damit die VMs auf das Internet zugreifen können. Verwenden Sie Cloud NAT, einen verteilten, softwarebasierten verwalteten Dienst von Google Cloud, der es VMs ermöglicht, ausgehende Pakete an das Internet zu senden und entsprechende eingehende Antwortpakete zu empfangen. Alternativ können Sie eine separate VM als NAT-Gateway einrichten.

Wichtiger Hinweis: Wenn Sie Cloud NAT konfigurieren, geben Sie mindestens 160 als Mindestanzahl von Ports pro VM an. Bestimmte Betriebssystem-Updates führen gleichzeitige Prozesse aus, die möglicherweise den Cloud NAT-Standardwert für die Anzahl der Ports überschreiten, was zu Aktivierungs- oder Downloadfehlern führen kann.

Wenn Sie eine Cloud NAT-Instanz erstellen, geben Sie die Anzahl der Ports im Feld Mindestanzahl an Ports pro VM unter Erweiterte Konfigurationen auf der Seite „NAT-Gateway erstellen“ in der Google Cloud Console ein.

Informationen zum Erstellen einer Cloud NAT-Instanz für Ihr Projekt finden Sie unter Cloud NAT verwenden.

Nachdem Sie Cloud NAT für Ihr Projekt konfiguriert haben, können Ihre VM-Instanzen ohne öffentliche IP-Adressen sicher auf das Internet zugreifen.

Firewallregeln hinzufügen

Standardmäßig verhindert eine implizite Firewallregel eingehende Verbindungen von außerhalb Ihres VPC-Netzwerks. Wenn Sie eingehende Verbindungen zulassen möchten, richten Sie für Ihre VM eine entsprechende Firewallregel ein. Wenn eine eingehende Verbindung zu einer VM hergestellt wurde, ist Traffic über diese Verbindung in beide Richtungen zulässig.

Sie können auch eine Firewallregel erstellen, um externen Zugriff auf bestimmte Ports zuzulassen oder Zugriff zwischen VMs im selben Netzwerk einzuschränken. Wenn der VPC-Netzwerktyp default verwendet wird, gelten auch einige zusätzliche Standardregeln. So etwa die Regel default-allow-internal, die den Zugriff zwischen VMs im selben Netzwerk an allen Ports erlaubt.

Abhängig von der für Ihre Umgebung geltenden IT-Richtlinie müssen Sie möglicherweise die Konnektivität zu Ihrem Datenbankhost isolieren oder anderweitig einschränken. Dazu erstellen Sie Firewallregeln.

Je nach Szenario können Sie Firewallregeln erstellen, die den Zugriff für Folgendes erlauben:

• SAP-Standardports, die unter TCP/IP-Ports aller SAP-Produkte aufgeführt sind.
• Verbindungen von Ihrem Computer oder dem Unternehmensnetzwerk aus zu Ihrer Compute Engine-VM-Instanz. Wenn Sie sich nicht sicher sind, welche IP-Adresse Sie verwenden sollen, wenden Sie sich an den Netzwerkadministrator Ihres Unternehmens.
• Kommunikation zwischen VMs im SAP HANA-Subnetzwerk, einschließlich der Kommunikation zwischen Knoten in einem SAP HANA-System mit horizontaler Skalierung oder Kommunikation zwischen dem Datenbankserver und Anwendungsservern in einer dreistufigen Architektur.Kommunikation zwischen VMs im SAP HANA-Subnetzwerk, einschließlich der Kommunikation zwischen Knoten in einem SAP HANA-System mit horizontaler Skalierung oder Kommunikation zwischen dem Datenbankserver und Anwendungsservern in einer dreistufigen Architektur. Sie können die Kommunikation zwischen VMs aktivieren, indem Sie eine Firewallregel erstellen, die Traffic aus dem Subnetzwerk zulässt.

Hinweis: Das folgende Verfahren ist eine vereinfachte Version der Anleitung für das Erstellen von Firewallregeln. Eine ausführlichere Anleitung finden Sie unter Firewallregeln erstellen.

So erstellen Sie eine Firewallregel:

Console

1. Rufen Sie in der Google Cloud Console die Seite Firewall des VPC-Netzwerks auf.

   Zur Firewall

2. Klicken Sie oben auf der Seite auf Firewallregel erstellen.

   • Wählen Sie im Feld Netzwerk das Netzwerk aus, in dem sich die VM befindet.
   • Geben Sie im Feld Ziele die Ressourcen in Google Cloud an, für die diese Regel gelten soll. Legen Sie beispielsweise Alle Instanzen im Netzwerk fest. Sie können unter Angegebene Ziel-Tags auch Tags eingeben, um die Regel auf bestimmte Instanzen in Google Cloud zu beschränken.
   • Wählen Sie im Feld Quellfilter eine der folgenden Optionen aus:
     • IP-Bereiche, um eingehenden Traffic von bestimmten IP-Adressen zuzulassen. Geben Sie den IP-Adressbereich im Feld Quell-IP-Bereiche an.
     • Subnetze, um eingehenden Traffic von einem bestimmten Subnetz zuzulassen. Geben Sie den Namen des Subnetzwerks im folgenden Feld Subnetze an. Mit dieser Option können Sie den Zugriff zwischen den VMs in einer dreistufigen oder einer horizontal skalierbaren Konfiguration zulassen.
   • Wählen Sie im Bereich Protokolle und Ports die Option Angegebene Protokolle und Ports aus und geben Sie tcp:PORT_NUMBER ein.

3. Klicken Sie auf Erstellen, um die Firewallregel anzulegen.

gcloud

Erstellen Sie mit dem folgenden Befehl eine Firewallregel:

$ gcloud compute firewall-rules create FIREWALL_NAME
--direction=INGRESS --priority=1000 \
--network=NETWORK_NAME --action=ALLOW --rules=PROTOCOL:PORT \
--source-ranges IP_RANGE --target-tags=NETWORK_TAGS

VMs und SAP HANA bereitstellen

Bevor Sie mit der Konfiguration des Hochverfügbarkeitsclusters beginnen, müssen Sie die VM-Instanzen und die SAP HANA-Systeme definieren und bereitstellen, die als primäre und sekundäre Knoten in Ihrem Hochverfügbarkeitscluster dienen.

Zum Definieren und Bereitstellen der Systeme verwenden Sie dieselbe Cloud Deployment Manager-Vorlage, die Sie zum Bereitstellen eines SAP HANA-Systems in der Bereitstellungsanleitung für SAP HANA verwenden.

Wenn Sie jedoch statt eines Systems zwei bereitstellen möchten, müssen Sie die Definition für das zweite System der Konfigurationsdatei hinzufügen. Kopieren Sie hierfür die Definition des ersten Systems und fügen Sie sie ein. Nachdem Sie die zweite Definition erstellt haben, müssen Sie die Ressourcen- und Instanznamen in der zweiten Definition ändern. Geben Sie zum Schutz vor einem Zonenausfall eine andere Zone in derselben Region an. Alle anderen Attributwerte in den beiden Definitionen bleiben unverändert.

Nachdem die SAP HANA-Systeme erfolgreich bereitgestellt wurden, definieren und konfigurieren Sie den Hochverfügbarkeitscluster.

In der folgenden Anleitung wird Cloud Shell verwendet, sie ist aber allgemein auf Google Cloud-CLI anwendbar.

1. Prüfen Sie, ob Ihre aktuellen Kontingente für Ressourcen wie nichtflüchtige Speicher und CPUs für das zu installierende SAP HANA-System ausreichen. Bei unzureichenden Kontingenten schlägt die Bereitstellung fehl. Welche Kontingente Sie für SAP HANA benötigen, erfahren Sie unter Überlegungen zu Preisen und Kontingenten für SAP HANA.

   Zur Seite "Kontingente"

2. Öffnen Sie die Cloud Shell. Wenn Sie die gcloud CLI auf Ihrer lokalen Workstation installiert haben, können Sie stattdessen auch ein Terminal öffnen.

   Zu Cloud Shell

3. Laden Sie die Konfigurationsdateivorlage template.yaml für den SAP HANA-Hochverfügbarkeitscluster in Ihr Arbeitsverzeichnis herunter. Geben Sie dafür den folgenden Befehl in Cloud Shell oder in der gcloud CLI ein:

   wget https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/template.yaml

4. Sie können die Datei template.yaml so umbenennen, dass die von ihr definierte Konfiguration im Namen erkennbar ist.

5. Öffnen Sie die Datei template.yaml im Cloud Shell-Code-Editor bzw. bei Verwendung der gcloud CLI in Ihrem bevorzugten Texteditor.

   Klicken Sie zum Öffnen des Code-Editors auf das Stiftsymbol oben rechts im Cloud Shell-Terminalfenster.

6. Erstellen Sie in der Datei template.yaml die Definition des primären SAP HANA-Systems. Geben Sie die Attributwerte an, indem Sie die Klammern und ihren Inhalt durch die Werte für Ihre Installation ersetzen. Die Attribute sind in der folgenden Tabelle beschrieben.

   Wenn Sie die VM-Instanzen ohne Installation von SAP HANA erstellen möchten, löschen Sie alle Zeilen, die mit sap_hana_ beginnen, oder kommentieren Sie diese aus.

   Attribut	Datentyp	Beschreibung
   Typ	String	Gibt Speicherort, Typ und Version der Deployment Manager-Vorlage an, die während der Bereitstellung verwendet werden sollen. Die YAML-Datei enthält zwei type-Spezifikationen, von denen eine auskommentiert ist. Für die standardmäßig aktive type-Spezifikation ist die Vorlagenversion als latest angegeben. Die auskommentierte type-Spezifikation gibt eine bestimmte Vorlagenversion mit einem Zeitstempel an. Wenn Sie möchten, dass alle Ihre Bereitstellungen die gleiche Vorlagenversion nutzen, verwenden Sie die type-Spezifikation, die den Zeitstempel enthält.
   instanceName	String	Der Name der VM-Instanz, die derzeit definiert ist. Geben Sie in der primären und sekundären VM-Definition unterschiedliche Namen an. Namen dürfen nur Kleinbuchstaben, Ziffern und Bindestriche enthalten.
   instanceType	String	Der Typ der virtuellen Maschine in Compute Engine, auf der Sie SAP HANA ausführen müssen. Wenn Sie einen benutzerdefinierten VM-Typ benötigen, geben Sie einen vordefinierten VM-Typ mit einer Anzahl an vCPUs an, die der benötigten Anzahl am nächsten kommt, aber noch darüber liegt. Wenn die Bereitstellung abgeschlossen ist, ändern Sie die Anzahl der vCPUs und den Umfang des Arbeitsspeichers.
   zone	String	Die Google Cloud-Zone, in der die von Ihnen definierte VM-Instanz bereitgestellt werden soll. Geben Sie für die primäre und sekundäre HANA-Definition verschiedene Zonen in derselben Region an. Die Zonen müssen sich in derselben Region befinden, die Sie für Ihr Subnetz ausgewählt haben.
   subnetwork	String	Name des Subnetzes, das Sie in einem vorherigen Schritt erstellt haben. Wenn das Deployment in einer freigegebenen VPC erfolgt, geben Sie diesen Wert im Format [SHAREDVPC_PROJECT]/[SUBNETWORK] an. Beispiel: myproject/network1.
   linuxImage	String	Der Name des Linux-Betriebssystem-Images bzw. der Linux-Image-Familie, die Sie mit SAP HANA verwenden. Wenn Sie eine Image-Familie angeben möchten, ergänzen Sie den Familiennamen durch das Präfix family/. Beispiel: family/sles-15-sp1-sap. Wenn Sie ein bestimmtes Image verwenden möchten, geben Sie nur dessen Namen an. Eine Liste der verfügbaren Images und Familien finden Sie in der Google Cloud Console auf der Seite „Images“.
   linuxImageProject	String	Das Google Cloud-Projekt, das das zu verwendende Image enthält. Dies kann Ihr eigenes Projekt oder ein Google Cloud-Image-Projekt wie suse-sap-cloud sein. Weitere Informationen zu Google Cloud-Image-Projekten finden Sie in der Compute Engine-Dokumentation auf der Seite Images.
   sap_hana_deployment_bucket	String	Name des Cloud Storage-Buckets in Ihrem Projekt, der die von Ihnen in einem vorherigen Schritt hochgeladenen SAP HANA-Installations- und Aktualisierungsdateien enthält. Alle aktualisierten Dateiversionen im Bucket werden während des Bereitstellungsprozesses auf SAP HANA angewendet.
   sap_hana_sid	String	Die ID des SAP HANA-Systems (SID). Die ID muss aus drei alphanumerischen Zeichen bestehen und mit einem Buchstaben beginnen. Alle Buchstaben müssen Großbuchstaben sein.
   sap_hana_instance_number	Ganzzahl	Instanznummer (0 bis 99) des SAP HANA-Systems. Der Standardwert ist 0.
   sap_hana_sidadm_password	String	Das Passwort für den Betriebssystemadministrator. Passwörter müssen mindestens acht Zeichen lang sein und mindestens einen Großbuchstaben, einen Kleinbuchstaben und eine Ziffer enthalten. Achtung: Ändern Sie das Passwort nach Abschluss der Installation.
   sap_hana_system_password	String	Das Passwort für den Datenbank-Superuser. Passwörter müssen mindestens acht Zeichen lang sein und mindestens einen Großbuchstaben, einen Kleinbuchstaben und eine Ziffer enthalten. Achtung: Ändern Sie das Passwort nach Abschluss der Installation.
   sap_hana_sidadm_uid	Ganzzahl	Der Standardwert für die SID_LCadm-Nutzer-ID lautet 900, um zu verhindern, dass von Nutzern erstellte Gruppen im Konflikt mit SAP HANA stehen. Sie können diesen Wert bei Bedarf ändern.
   sap_hana_sapsys_gid	Ganzzahl	Die Standard-Gruppen-ID für sapsys ist 79. Durch Angabe eines höheren Werts können Sie diesen Wert entsprechend Ihren Anforderungen überschreiben.
   sap_hana_scaleout_nodes	Ganzzahl	Geben Sie 0 an. Diese Anleitung gilt nur für vertikal skalierbare SAP HANA-Systeme.
   networkTag	String	Ein Netzwerk-Tag, das Ihre VM-Instanz für Firewall- oder Routing-Zwecke repräsentiert. Wenn Sie zwar publicIP: No, aber kein Netzwerk-Tag angeben, müssen Sie eine andere Möglichkeit für den Zugriff auf das Internet bereitstellen.
   nic_type	String	Optional, aber empfohlen, sofern für die Zielmaschine und die Betriebssystemversion verfügbar. Gibt die Netzwerkschnittstelle an, die mit der VM-Instanz verwendet werden soll. Sie können den Wert GVNIC oder VIRTIO_NET angeben. Wenn Sie eine Google Virtual NIC (gVNIC) verwenden möchten, müssen Sie ein Betriebssystem-Image angeben, das gVNIC als Wert für das Attribut linuxImage unterstützt. Eine Liste der Betriebssystem-Images finden Sie unter Details zu Betriebssystemen. Wenn Sie für dieses Attribut keinen Wert angeben, wird die Netzwerkschnittstelle automatisch basierend auf dem Maschinentyp ausgewählt, den Sie für das Attribut instanceType angeben. Dieses Argument ist in den Deployment Manager-Vorlagenversionen 202302060649 oder höher verfügbar.
   publicIP	Boolesch	Optional. Legt fest, ob Ihre VM-Instanz eine öffentliche IP-Adresse erhält. Der Standardwert ist Yes. Hinweis: Geben Sie No nur an, wenn Sie ein NAT-Gateway mit einem für die VM definierten Netzwerk-Tag konfiguriert oder für die VM eine andere Route zum Internet bereitgestellt haben. Wenn keine Route zum Internet angegeben ist, schlägt die Installation fehl.
   serviceAccount	String	Optional. Gibt ein Dienstkonto an, das von den Host-VMs und den darauf ausgeführten Programmen verwendet werden soll. Geben Sie die E-Mail-Adresse des Dienstkontos an. Beispiel: [e-mail]. Standardmäßig wird das Compute Engine-Standarddienstkonto verwendet. Weitere Informationen finden Sie unter Identitäts- und Zugriffsverwaltung für SAP-Programme in Google Cloud.

7. Erstellen Sie die Definition des sekundären SAP HANA-Systems, indem Sie die Definition des primären SAP HANA-Systems kopieren und nach der Definition des primären SAP HANA-Systems einfügen. Das nach diesen Schritten folgende Beispiel veranschaulicht dies.

8. Geben Sie in der Definition des sekundären SAP HANA-Systems für die folgenden Attribute andere Werte als in der primären SAP HANA-Systemdefinition an:

   • name
   • instanceName
   • zone

9. Erstellen Sie die Instanzen:

   gcloud deployment-manager deployments create DEPLOYMENT_NAME --config TEMPLATE_NAME.yaml

   Der obige Befehl ruft Deployment Manager auf, um die VMs gemäß den Angaben in der Datei template.yaml bereitzustellen, die SAP HANA-Software aus dem Speicher-Bucket herunterzuladen und SAP HANA zu installieren.

   Die Bereitstellungsverarbeitung umfasst zwei Phasen. In der ersten Phase schreibt Deployment Manager seinen Status in die Konsole. In der zweiten Phase schreiben die Bereitstellungsskripts ihren Status in Cloud Logging.

Beispiel für eine vollständige template.yaml-Konfigurationsdatei

Das folgende Beispiel zeigt eine fertige template.yaml-Konfigurationsdatei, die zwei VM-Instanzen mit einem installierten SAP HANA-System bereitstellt.

Die Datei enthält die Definitionen der beiden Ressourcen, die bereitgestellt werden sollen: sap_hana_primary und sap_hana_secondary. Jede Ressourcendefinition enthält die Definitionen für eine VM und eine SAP HANA-Instanz.

Die Ressourcendefinition sap_hana_secondary wurde erstellt, indem die erste Definition kopiert und eingefügt und dann die Werte der Attribute name, instanceName und zone geändert wurden. Alle anderen Attributwerte in den beiden Ressourcendefinitionen sind identisch.

Die Attribute networkTag, serviceAccount, sap_hana_sidadm_uid und sap_hana_sapsys_gid stammen aus dem Abschnitt "Erweiterte Optionen" der Vorlage für die Konfigurationsdatei. Die Attribute sap_hana_sidadm_uid und sap_hana_sapsys_gid werden eingeschlossen, um ihre Standardwerte anzugeben, die verwendet werden, da die Attribute auskommentiert sind.

resources:
- name: sap_hana_primary
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/sap_hana.py
  #
  # By default, this configuration file uses the latest release of the deployment
  # scripts for SAP on Google Cloud.  To fix your deployments to a specific release
  # of the scripts, comment out the type property above and uncomment the type property below.
  #
  # type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/yyyymmddhhmm/dm-templates/sap_hana/sap_hana.py
  #
  properties:
    instanceName: hana-ha-vm-1
    instanceType: n2-highmem-32
    zone: us-central1-a
    subnetwork: example-subnet-us-central1
    linuxImage: family/sles-15-sp1-sap
    linuxImageProject: suse-sap-cloud
    sap_hana_deployment_bucket: hana2-sp4-rev46
    sap_hana_sid: HA1
    sap_hana_instance_number: 22
    sap_hana_sidadm_password: Tempa55word
    sap_hana_system_password: Tempa55word
    sap_hana_scaleout_nodes: 0
    networkTag: cluster-ntwk-tag
    serviceAccount: [e-mail]
    # sap_hana_sidadm_uid: 900
    # sap_hana_sapsys_gid: 79

- name: sap_hana_secondary
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/sap_hana.py
  #
  # By default, this configuration file uses the latest release of the deployment
  # scripts for SAP on Google Cloud.  To fix your deployments to a specific release
  # of the scripts, comment out the type property above and uncomment the type property below.
  #
  # type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/yyyymmddhhmm/dm-templates/sap_hana/sap_hana.py
  #
  properties:
    instanceName: hana-ha-vm-2
    instanceType: n2-highmem-32
    zone: us-central1-c
    subnetwork: example-subnet-us-central1
    linuxImage: family/sles-15-sp1-sap
    linuxImageProject: suse-sap-cloud
    sap_hana_deployment_bucket: hana2-sp4-rev46
    sap_hana_sid: HA1
    sap_hana_instance_number: 22
    sap_hana_sidadm_password: Google123
    sap_hana_system_password: Google123
    sap_hana_scaleout_nodes: 0
    networkTag: cluster-ntwk-tag
    serviceAccount: [e-mail]
    # sap_hana_sidadm_uid: 900
    # sap_hana_sapsys_gid: 79
    

Firewallregeln erstellen, die den Zugriff auf die Host-VMs zulassen

Erstellen Sie gegebenenfalls Firewallregeln, die von den folgenden Quellen Zugriff auf jede Host-VM erlauben:

• Zu Konfigurationszwecken von Ihrer lokalen Workstation, einem Bastion Host oder Jump-Server
• Für den Zugriff zwischen den Clusterknoten von den anderen Host-VMs im Hochverfügbarkeitscluster

Wenn Sie VPC-Firewallregeln erstellen, geben Sie die Netzwerk-Tags an, die Sie in der Konfigurationsdatei template.yaml definiert haben, um Ihre Host-VMs als Ziel für die Regel festzulegen.

Definieren Sie zum Prüfen der Bereitstellung eine Regel, die SSH-Verbindungen von einem Bastion Host oder Ihrer lokalen Workstation an Port 22 zulässt.

Fügen Sie für den Zugriff zwischen den Clusterknoten eine Firewallregel hinzu, die alle Verbindungstypen von anderen VMs im selben Subnetzwerk an allen Ports zulässt.

Achten Sie darauf, die Firewallregeln zum Prüfen der Bereitstellung und für die Kommunikation zwischen den Clustern zu erstellen, bevor Sie mit dem nächsten Abschnitt fortfahren. Eine Anleitung finden Sie unter Firewallregeln hinzufügen.

Bereitstellung der VMs und von SAP HANA prüfen

Prüfen Sie zum Überprüfen der Bereitstellung die Bereitstellungslogs in Cloud Logging sowie die Laufwerke und Dienste auf den VMs des primären und sekundären Hosts.

1. Öffnen Sie in der Google Cloud Console „Cloud Logging“, um den Installationsfortschritt zu überwachen und nach Fehlern zu suchen.

   Hinweis: Wenn Sie diesen Schritt in Cloud Logging ausführen, können Kosten anfallen. Weitere Informationen finden Sie unter Cloud Logging – Preise.

   Zu Cloud Logging

2. Filtern Sie die Logs:

   Log-Explorer

   1. Wechseln Sie auf der Seite Log-Explorer zum Bereich Abfrage.

   2. Wählen Sie im Drop-down-Menü Ressource die Option Global aus und klicken Sie dann auf Hinzufügen.

      Wenn die Option Global nicht angezeigt wird, geben Sie im Abfrageeditor die folgende Abfrage ein:

      resource.type="global"
      "Deployment"
      

   3. Klicken Sie auf Abfrage ausführen.

   Legacy-Loganzeige

   • Wählen Sie auf der Seite Legacy-Loganzeige im einfachen Auswahlmenü die Option Global als Logging-Ressource aus.

3. Analysieren Sie die gefilterten Logs:

   • Wenn "--- Finished" angezeigt wird, ist die Verarbeitung des Deployments abgeschlossen und Sie können mit dem nächsten Schritt fortfahren.

   • Wenn ein Kontingentfehler auftritt:

     1. Erhöhen Sie auf der Seite IAM & Verwaltung > Kontingente alle Kontingente, die nicht die im Planungsleitfaden für SAP HANA aufgeführten Anforderungen erfüllen.

     2. Löschen Sie in Deployment Manager auf der Seite Deployments die Bereitstellung, um VMs und nichtflüchtige Speicher von der fehlgeschlagenen Installation zu bereinigen.

     3. Führen Sie die Bereitstellung noch einmal aus.

Konfiguration der VMs und von SAP HANA prüfen

1. Wenn das SAP HANA-System fehlerfrei bereitgestellt wurde, stellen Sie eine SSH-Verbindung zu jeder VM her. Sie können hierfür wahlweise in Compute Engine auf der Seite mit den VM-Instanzen neben jeder VM-Instanz auf die Schaltfläche "SSH" klicken oder Ihre bevorzugte SSH-Methode verwenden.

   

2. Wechseln Sie zum Root-Nutzer.

   $ sudo su -

3. Geben Sie bei der Eingabeaufforderung df -h ein. Achten Sie darauf, dass Sie auf jeder VM die /hana-Verzeichnisse sehen, z. B. /hana/data.

   Filesystem                        Size  Used Avail Use% Mounted on
   /dev/sda2                          30G  4.0G   26G  14% /
   devtmpfs                          126G     0  126G   0% /dev
   tmpfs                             126G     0  126G   0% /dev/shm
   tmpfs                             126G   17M  126G   1% /run
   tmpfs                             126G     0  126G   0% /sys/fs/cgroup
   /dev/sda1                         200M  9.7M  191M   5% /boot/efi
   /dev/mapper/vg_hana-shared        251G   49G  203G  20% /hana/shared
   /dev/mapper/vg_hana-sap            32G  240M   32G   1% /usr/sap
   /dev/mapper/vg_hana-data          426G  7.0G  419G   2% /hana/data
   /dev/mapper/vg_hana-log           125G  4.2G  121G   4% /hana/log
   /dev/mapper/vg_hanabackup-backup  512G   33M  512G   1% /hanabackup
   tmpfs                              26G     0   26G   0% /run/user/900
   tmpfs                              26G     0   26G   0% /run/user/899
   tmpfs                              26G     0   26G   0% /run/user/1000

4. Wechseln Sie zum SAP-Administrator. Ersetzen Sie dazu im folgenden Befehl SID_LC durch die System-ID, die Sie in der Vorlage für die Konfigurationsdatei angegeben haben. Verwenden Sie Kleinschreibung für Buchstaben.

   # su - SID_LCadm

5. Prüfen Sie, ob die SAP HANA-Dienste wie u. a. hdbnameserver und hdbindexserver auf der Instanz ausgeführt werden. Geben Sie dazu den folgenden Befehl ein:

   > HDB info

6. Wenn Sie RHEL für SAP 9.0 oder höher verwenden, achten Sie darauf, dass die Pakete chkconfig und compat-openssl11 auf Ihrer VM-Instanz installiert sind.

   Weitere Informationen von SAP finden Sie im SAP-Hinweis 3108316 – Red Hat Enterprise Linux 9.x: Installation und Konfiguration.

Installation des Google Cloud-Agents für SAP prüfen

Nachdem Sie eine VM bereitgestellt und Ihr SAP-System installiert haben, prüfen Sie, ob der Google Cloud-Agent für SAP ordnungsgemäß funktioniert.

Ausführung des Google Cloud-Agents für SAP prüfen

So prüfen Sie, ob der Agent ausgeführt wird:

1. Stellen Sie eine SSH-Verbindung zu Ihrer Compute Engine-Instanz her.

2. Führen Sie dazu diesen Befehl aus:

   systemctl status google-cloud-sap-agent

   Wenn der Agent ordnungsgemäß funktioniert, enthält die Ausgabe active (running). Beispiel:

   google-cloud-sap-agent.service - Google Cloud Agent for SAP
   Loaded: loaded (/usr/lib/systemd/system/google-cloud-sap-agent.service; enabled; vendor preset: disabled)
   Active:  active (running)  since Fri 2022-12-02 07:21:42 UTC; 4 days ago
   Main PID: 1337673 (google-cloud-sa)
   Tasks: 9 (limit: 100427)
   Memory: 22.4 M (max: 1.0G limit: 1.0G)
   CGroup: /system.slice/google-cloud-sap-agent.service
          └─1337673 /usr/bin/google-cloud-sap-agent
   

Wenn der Agent nicht ausgeführt wird, starten Sie den Agent neu.

Prüfen, ob der SAP-Host-Agent Messwerte empfängt

Führen Sie die folgenden Schritte aus, um zu prüfen, ob die Infrastrukturmesswerte vom Agent von Google Cloud für SAP erfasst und korrekt an den SAP-Host-Agent gesendet werden:

1. Geben Sie in Ihrem SAP-System Transaktion ST06 ein.

2. Kontrollieren Sie im Übersichtsbereich die Verfügbarkeit und den Inhalt der folgenden Felder, um die korrekte End-to-End-Einrichtung der SAP- und Google-Monitoring-Infrastruktur zu überprüfen:

   • Cloud-Anbieter: Google Cloud Platform
   • Zugriff für erweitertes Monitoring: TRUE
   • Details für erweitertes Monitoring: ACTIVE

Monitoring für SAP HANA einrichten

Optional können Sie Ihre SAP HANA-Instanzen mit dem Google Cloud-Agent für SAP überwachen. In Version 2.0 können Sie den Agent so konfigurieren, dass er die SAP HANA-Monitoring-Messwerte erfasst und an Cloud Monitoring sendet. Mit Cloud Monitoring lassen sich Dashboards erstellen, um diese Messwerte zu visualisieren, Benachrichtigungen anhand von Messwertschwellen einzurichten und vieles mehr.

Weitere Informationen zur Erfassung von SAP HANA-Monitoring-Messwerten mit dem Google Cloud-Agent für SAP finden Sie unter SAP HANA-Monitoring-Messwerte erfassen.

Autostart von SAP HANA deaktivieren

Für jede SAP HANA-Instanz im Cluster muss der Autostart von SAP HANA deaktiviert sein. Bei Failovers verwaltet Pacemaker das Starten und Stoppen der SAP HANA-Instanzen in einem Cluster.

1. Beenden Sie auf jedem Host als SID_LCadm SAP HANA:

   > HDB stop

2. Öffnen Sie auf jedem Host das SAP HANA-Profil mit einem Editor wie vi:

   vi /usr/sap/SID/SYS/profile/SID_HDBINST_NUM_HOST_NAME

3. Setzen Sie das Attribut Autostart auf 0:

   Autostart=0

4. Speichern Sie das Profil.

5. Starten Sie auf jedem Host als SID_LCadm SAP HANA:

   > HDB start

SAP HANA Fast Restart aktivieren

Google Cloud empfiehlt dringend die Aktivierung von SAP HANA Fast Restart für jede Instanz von SAP HANA, insbesondere bei größeren Instanzen. SAP HANA Fast Restart verkürzt die Neustartzeit, wenn SAP HANA beendet wird, das Betriebssystem jedoch weiter ausgeführt wird.

Hinweis: Wenn Sie SAP HANA mit dem Terraform-Modul sap_hana oder sap_hana_ha von Google Cloud, Version 202309280828 oder höher bereitstellen, ist Fast Restart automatisch aktiviert.

In der Konfiguration der von Google Cloud bereitgestellten Automatisierungsskripts unterstützen die Betriebssystem- und Kerneleinstellungen bereits SAP HANA Fast Restart. Sie müssen das tmpfs-Dateisystem definieren und SAP HANA konfigurieren.

Zum Definieren des Dateisystems tmpfs und zum Konfigurieren von SAP HANA können Sie den manuellen Schritten folgen oder das von Google Cloud bereitgestellte Automatisierungsskript verwenden, um SAP HANA Fast Restart zu aktivieren. Weitere Informationen finden Sie hier:

• Manuelle Schritte: SAP HANA Fast Restart aktivieren
• Automatisierte Schritte: SAP HANA Fast Restart aktivieren

Die Anleitungen für SAP HANA Fast Restart finden Sie in der Dokumentation zu SAP HANA Fast Restart.

Manuelle Schritte

tmpfs-Dateisystem konfigurieren

Nachdem die Host-VMs und die SAP HANA-Basissysteme erfolgreich bereitgestellt wurden, müssen Sie Verzeichnisse für die NUMA-Knoten im tmpfs-Dateisystem erstellen und bereitstellen.

NUMA-Topologie Ihrer VM anzeigen lassen

Bevor Sie das erforderliche tmpfs-Dateisystem zuordnen können, müssen Sie wissen, wie viele NUMA-Knoten Ihre VM hat. Geben Sie den folgenden Befehl ein, um die verfügbaren NUMA-Knoten auf einer Compute Engine-VM anzeigen zu lassen:

lscpu | grep NUMA

Der VM-Typ m2-ultramem-208 hat beispielsweise vier NUMA-Knoten mit der Nummerierung 0–3, wie im folgenden Beispiel gezeigt:

NUMA node(s):        4
NUMA node0 CPU(s):   0-25,104-129
NUMA node1 CPU(s):   26-51,130-155
NUMA node2 CPU(s):   52-77,156-181
NUMA node3 CPU(s):   78-103,182-207

NUMA-Knotenverzeichnisse erstellen

Erstellen Sie ein Verzeichnis für jeden NUMA-Knoten in Ihrer VM und legen Sie die Berechtigungen fest.

Beispiel für vier NUMA-Knoten mit der Nummerierung 0–3:

mkdir -pv /hana/tmpfs{0..3}/SID
chown -R SID_LCadm:sapsys /hana/tmpfs*/SID
chmod 777 -R /hana/tmpfs*/SID

NUMA-Knotenverzeichnisse unter tmpfs bereitstellen

Stellen Sie die Verzeichnisse des tmpfs-Dateisystems bereit und geben Sie für mpol=prefer jeweils eine NUMA-Knoteneinstellung an:

SID: Geben Sie die SID in Großbuchstaben an.

mount tmpfsSID0 -t tmpfs -o mpol=prefer:0 /hana/tmpfs0/SID
mount tmpfsSID1 -t tmpfs -o mpol=prefer:1 /hana/tmpfs1/SID
mount tmpfsSID2 -t tmpfs -o mpol=prefer:2 /hana/tmpfs2/SID
mount tmpfsSID3 -t tmpfs -o mpol=prefer:3 /hana/tmpfs3/SID

Hinweis: Wenn Sie die Maschinentypen ändern und sich die Anzahl der NUMA-Knoten erhöht oder verringert, müssen Sie das tmpfs-Dateisystem und den Abschnitt [persistence] der SAP HANA-INI-Datei ändern, wie im nächsten Abschnitt dargestellt, um die neue Anzahl von NUMA-Knoten abzugleichen.

/etc/fstab aktualisieren

Fügen Sie der Dateisystemtabelle /etc/fstab Einträge hinzu, damit die Bereitstellungspunkte nach dem Neustart eines Betriebssystems verfügbar sind:

tmpfsSID0 /hana/tmpfs0/SID tmpfs rw,relatime,mpol=prefer:0
tmpfsSID1 /hana/tmpfs1/SID tmpfs rw,relatime,mpol=prefer:1
tmpfsSID1 /hana/tmpfs2/SID tmpfs rw,relatime,mpol=prefer:2
tmpfsSID1 /hana/tmpfs3/SID tmpfs rw,relatime,mpol=prefer:3

Optional: Limits für die Speichernutzung festlegen

Das tmpfs-Dateisystem kann dynamisch wachsen und schrumpfen.

Wenn Sie den vom tmpfs-Dateisystem verwendeten Speicher begrenzen möchten, können Sie mit der Option size eine Größenbeschränkung für ein NUMA-Knoten-Volume festlegen. Beispiel:

mount tmpfsSID0 -t tmpfs -o mpol=prefer:0,size=250G /hana/tmpfs0/SID

Sie können auch die tmpfs-Speichernutzung für alle NUMA-Knoten für eine bestimmte SAP-HANA-Instanz und einen bestimmten Serverknoten begrenzen, indem Sie den Parameter persistent_memory_global_allocation_limit im Abschnitt [memorymanager] der Datei global.ini festlegen.

SAP HANA-Konfiguration für Fast Restart

Um SAP HANA für Fast Restart zu konfigurieren, aktualisieren Sie die Datei global.ini und geben Sie die Tabellen an, die im nichtflüchtigen Speicher gespeichert werden sollen.

Aktualisieren Sie den Abschnitt [persistence] in der Datei global.ini.

Konfigurieren Sie den Abschnitt [persistence] in der SAP HANA-Datei global.ini, um auf die tmpfs-Standorte zu verweisen. Trennen Sie die einzelnen tmpfs-Standorte durch ein Semikolon:

[persistence]
basepath_datavolumes = /hana/data
basepath_logvolumes = /hana/log
basepath_persistent_memory_volumes = /hana/tmpfs0/SID;/hana/tmpfs1/SID;/hana/tmpfs2/SID;/hana/tmpfs3/SID

Im vorherigen Beispiel werden vier Arbeitsspeicher-Volumes für vier NUMA-Knoten angegeben, die m2-ultramem-208 entspricht. Bei der Ausführung auf m2-ultramem-416 müssten Sie acht Arbeitsspeicher-Volumes (0..7) konfigurieren.

Starten Sie SAP HANA neu, nachdem Sie die Datei global.ini geändert haben.

SAP HANA kann jetzt den Standort tmpfs als nichtflüchtigen Speicherbereich verwenden.

Tabellen angeben, die im nichtflüchtigen Speicher gespeichert werden sollen

Geben Sie bestimmte Spaltentabellen oder Partitionen an, die im nichtflüchtigen Speicher gespeichert werden sollen.

Wenn Sie beispielsweise nichtflüchtigen Speicher für eine vorhandene Tabelle aktivieren möchten, führen Sie diese SQL-Abfrage aus:

ALTER TABLE exampletable persistent memory ON immediate CASCADE

Um den Standardwert für neue Tabellen zu ändern, fügen Sie den Parameter table_default zur Datei indexserver.ini hinzu. Beispiel:

[persistent_memory]
table_default = ON

Weitere Informationen zur Steuerung von Spalten, Tabellen und dazu, welche Monitoringansichten detaillierte Informationen enthalten, finden Sie unter Nichtflüchtiger SAP HANA-Speicher.

Automatisierte Schritte

Das von Google Cloud bereitgestellte Automatisierungsskript zum Aktivieren von SAP HANA Fast Restart nimmt Änderungen an den Verzeichnissen /hana/tmpfs*, der Datei /etc/fstab und der SAP HANA-Konfiguration vor. Wenn Sie das Script ausführen, müssen Sie möglicherweise zusätzliche Schritte ausführen, je nachdem, ob es sich um die anfängliche Bereitstellung Ihres SAP HANA-Systems handelt oder Sie die Größe Ihrer Maschine in eine andere NUMA-Größe ändern.

Achten Sie bei der ersten Bereitstellung Ihres SAP HANA-Systems oder bei der Größenanpassung der Maschine zur Erhöhung der Anzahl der NUMA-Knoten darauf, dass SAP HANA während der Ausführung des Automatisierungsskripts ausgeführt wird, das Google Cloud zur Aktivierung von SAP HANA Fast Restart bereitstellt.

Wenn Sie die Größe der Maschine ändern, um die Anzahl der NUMA-Knoten zu verringern, müssen Sie darauf achten, dass SAP HANA während der Ausführung des Automatisierungsskripts gestoppt wird, das Google Cloud zur Aktivierung von SAP HANA Fast Restart bereitstellt. Nachdem das Script ausgeführt wurde, müssen Sie die SAP HANA-Konfiguration manuell aktualisieren, um die Einrichtung von SAP HANA Fast Restart abzuschließen. Weitere Informationen finden Sie unter SAP HANA-Konfiguration für Fast Restart.

Hinweis: Wir empfehlen dringend, das von Google Cloud bereitgestellte Script auszuführen, um SAP HANA Fast Restart in einer Nicht-Produktionsumgebung zu aktivieren, und die Ergebnisse vor der Ausführung des Script in Produktionsumgebungen sorgfältig zu prüfen. Sie übernehmen die Verantwortung für die ordnungsgemäße Aktivierung von SAP HANA Fast Restart.

So aktivieren Sie SAP HANA Fast Restart:

1. Stellen Sie eine SSH-Verbindung zu Ihrer Host-VM her.

2. Wechseln Sie zum Root:

   sudo su -

3. Laden Sie das sap_lib_hdbfr.sh-Skript herunter:

   wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/lib/sap_lib_hdbfr.sh

4. Machen Sie die Datei ausführbar:

   chmod +x sap_lib_hdbfr.sh

5. Prüfen Sie, ob das Script Fehler enthält:

   vi sap_lib_hdbfr.sh
   ./sap_lib_hdbfr.sh -help

   Wenn der Befehl einen Fehler zurückgibt, wenden Sie sich an Cloud Customer Care. Weitere Informationen zur Kontaktaufnahme mit Customer Care finden Sie unter Support für SAP in Google Cloud.

6. Führen Sie das Script aus, nachdem Sie die SAP HANA-System-ID (SID) und das Passwort für den SYSTEM-Nutzer der SAP HANA-Datenbank ersetzt haben. Damit Sie das Passwort sicher bereitstellen können, empfehlen wir die Verwendung eines Secrets in Secret Manager.

   Führen Sie das Script mit dem Namen eines Secrets in Secret Manager aus. Dieses Secret muss in dem Google Cloud-Projekt vorhanden sein, das Ihre Host-VM-Instanz enthält.

   sudo ./sap_lib_hdbfr.sh -h 'SID' -s SECRET_NAME 

   Ersetzen Sie Folgendes:

   • SID: Geben Sie die SID in Großbuchstaben an. Beispiel: AHA.
   • SECRET_NAME: Geben Sie den Namen des Secrets an, das dem Passwort für den SYSTEM-Nutzer der SAP HANA-Datenbank entspricht. Dieses Secret muss in dem Google Cloud-Projekt vorhanden sein, das Ihre Host-VM-Instanz enthält.

   Alternativ können Sie das Script mit einem Nur-Text-Passwort ausführen. Nachdem SAP HANA Fast Restart aktiviert wurde, müssen Sie Ihr Passwort ändern. Die Verwendung eines Nur-Text-Passworts wird nicht empfohlen, da Ihr Passwort im Befehlszeilenverlauf Ihrer VM aufgezeichnet werden würde.

   sudo ./sap_lib_hdbfr.sh -h 'SID' -p 'PASSWORD'

   Ersetzen Sie Folgendes:

   • SID: Geben Sie die SID in Großbuchstaben an. Beispiel: AHA.
   • PASSWORD: Geben Sie das Passwort für den SYSTEM-Nutzer der SAP HANA-Datenbank an.

Bei einer erfolgreichen ersten Ausführung sollte die Ausgabe in etwa so aussehen:

INFO - Script is running in standalone mode
ls: cannot access '/hana/tmpfs*': No such file or directory
INFO - Setting up HANA Fast Restart for system 'TST/00'.
INFO - Number of NUMA nodes is 2
INFO - Number of directories /hana/tmpfs* is 0
INFO - HANA version 2.57
INFO - No directories /hana/tmpfs* exist. Assuming initial setup.
INFO - Creating 2 directories /hana/tmpfs* and mounting them
INFO - Adding /hana/tmpfs* entries to /etc/fstab. Copy is in /etc/fstab.20220625_030839
INFO - Updating the HANA configuration.
INFO - Running command: select * from dummy
DUMMY
"X"
1 row selected (overall time 4124 usec; server time 130 usec)

INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') SET ('persistence', 'basepath_persistent_memory_volumes') = '/hana/tmpfs0/TST;/hana/tmpfs1/TST;'
0 rows affected (overall time 3570 usec; server time 2239 usec)

INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') SET ('persistent_memory', 'table_unload_action') = 'retain';
0 rows affected (overall time 4308 usec; server time 2441 usec)

INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('indexserver.ini', 'SYSTEM') SET ('persistent_memory', 'table_default') = 'ON';
0 rows affected (overall time 3422 usec; server time 2152 usec)

SSH-Schlüssel auf den primären und sekundären VMs konfigurieren

Die Schlüssel des sicheren SAP HANA-Speichers (Secure Storage in File System, SSFS) müssen im Hochverfügbarkeitscluster zwischen den Hosts synchronisiert werden. Damit die Synchronisierung vereinfacht und das Kopieren von Dateien wie Sicherungen zwischen den Hosts im Hochverfügbarkeitscluster ermöglicht wird, müssen Sie in dieser Anleitung Root-SSH-Verbindungen zwischen den beiden Hosts erstellen.

In Ihrer Organisation gelten wahrscheinlich Richtlinien, die die interne Netzwerkkommunikation regeln. Bei Bedarf können Sie nach Abschluss der Bereitstellung die Metadaten aus den VMs und die Schlüssel aus dem Verzeichnis authorized_keys entfernen.

Wenn das Einrichten direkter SSH-Verbindungen nicht den Richtlinien Ihrer Organisation entspricht, können Sie die SSFS-Schlüssel synchronisieren und Dateien mit anderen Methoden übertragen. Beispiele:

• Übertragen Sie kleinere Dateien über Ihre lokale Workstation mithilfe der Cloud Shell-Menüoptionen Datei hochladen und Datei herunterladen. Siehe dazu Dateien mit Cloud Shell verwalten.
• Tauschen Sie Dateien mithilfe eines Google Cloud Storage-Buckets aus. Siehe dazu Mit Objekten arbeiten in der Cloud Storage-Dokumentation.
• Verwenden Sie den Cloud Storage-Backint-Agent für SAP HANA, um HANA-Datenbanken zu sichern und wiederherzustellen. Siehe dazu Cloud Storage-Backint-Agent für SAP HANA.
• Verwenden Sie eine Dateispeicherlösung wie Filestore oder den NetApp Cloud Volumes-Dienst, um einen freigegebenen Ordner zu erstellen. Siehe Dateiserveroptionen.

So aktivieren Sie SSH-Verbindungen zwischen der primären und der sekundären Instanz:

1. Auf der primären Host-VM:

   1. Stellen Sie eine SSH-Verbindung zur VM her.

   2. Wechseln Sie zum Root:

   $ sudo su -

   1. Generieren Sie als Root einen SSH-Schlüssel.

      # ssh-keygen

   2. Aktualisieren Sie die Metadaten der primären VM mit Informationen zum SSH-Schlüssel für die sekundäre VM.

      # gcloud compute instances add-metadata secondary-host-name \
      --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" --zone secondary-zone

   3. Autorisieren Sie die primäre VM für sich selbst.

      # cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

2. Auf der sekundären Host-VM:

   1. Stellen Sie eine SSH-Verbindung zur VM her.

   2. Wechseln Sie zum Root:

   $ sudo su -

   1. Generieren Sie als Root einen SSH-Schlüssel.

      # ssh-keygen

   2. Aktualisieren Sie die Metadaten der sekundären VM mit Informationen zum SSH-Schlüssel für die primäre VM.

      # gcloud compute instances add-metadata primary-host-name \
      --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" --zone primary-zone

   3. Autorisieren Sie die sekundäre VM für sich selbst.

      # cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

   4. Prüfen Sie, ob die SSH-Schlüssel ordnungsgemäß eingerichtet sind. Stellen Sie dazu eine SSH-Verbindung vom sekundären zum primären System her.

      # ssh primary-host-name

3. Prüfen Sie als Root auf der primären Host-VM die Verbindung, indem Sie eine SSH-Verbindung zur sekundären Host-VM herstellen:

   # ssh secondary-host-name

SAP HANA-Datenbanknutzer zum Monitoring des Clusterstatus erstellen

1. Melden Sie sich auf dem primären Host als SID_LCadm im interaktiven Terminal der SAP HANA-Datenbank an:

   > hdbsql -u system -p "system-password" -i inst_num

2. Erstellen Sie im interaktiven Terminal den Datenbanknutzer slehasync:

   => CREATE USER slehasync PASSWORD "hdb-user-password";
   => GRANT CATALOG READ TO slehasync;
   => GRANT MONITOR ADMIN TO slehasync;
   => ALTER USER slehasync DISABLE PASSWORD LIFETIME;

3. Definieren Sie als SID_LCadm den Nutzerschlüssel SLEHALOC im sicheren SAP HANA-Nutzerspeicher (hdbuserstore):

   > PATH="$PATH:/usr/sap/SID/HDBinst_num/exe"
   > hdbuserstore SET SLEHALOC localhost:3inst_num15 slehasync hdb-user-password

Datenbanken sichern

Erstellen Sie Sicherungen Ihrer Datenbanken, um das Datenbank-Logging für die SAP HANA-Systemreplikation zu initiieren und einen Wiederherstellungspunkt zu erstellen.

Wenn Sie in einer MDC-Konfiguration mehrere Mandantendatenbanken haben, sichern Sie sie alle.

Die Deployment Manager-Vorlage verwendet /hanabackup/data/SID als Standardsicherungsverzeichnis.

So erstellen Sie Sicherungen von neuen SAP HANA-Datenbanken:

1. Wechseln Sie auf dem primären Host zu SID_LCadm. Je nach Betriebssystem-Image kann der Befehl unterschiedlich sein.

   sudo -i -u SID_LCadm

2. Erstellen Sie die Datenbanksicherungen:

   • Für ein SAP HANA-System mit Container für eine einzelne Datenbank:

     > hdbsql -t -u system -p SYSTEM_PASSWORD -i INST_NUM \
       "backup data using file ('full')"

     Das folgende Beispiel zeigt eine positive Antwort von einem neuen SAP HANA-System:

     0 rows affected (overall time 18.416058 sec; server time 18.414209 sec)

   • Erstellen Sie für ein SAP HANA-System mit Container für mehrere Datenbanken (MDC) eine Sicherung der Systemdatenbank sowie aller Mandantendatenbanken:

     > hdbsql -t -d SYSTEMDB -u system -p SYSTEM_PASSWORD -i INST_NUM \
       "backup data using file ('full')"

     > hdbsql -t -d SID -u system -p SYSTEM_PASSWORD -i INST_NUM \
       "backup data using file ('full')"

   Das folgende Beispiel zeigt eine positive Antwort von einem neuen SAP HANA-System:

   0 rows affected (overall time 16.590498 sec; server time 16.588806 sec)

3. Prüfen Sie, ob der Logging-Modus auf "normal" eingestellt ist:

   > hdbsql -u system -p SYSTEM_PASSWORD -i INST_NUM \
     "select value from "SYS"."M_INIFILE_CONTENTS" where key='log_mode'"

   Hier sollten Sie das sehen:

   VALUE
   "normal"

SAP HANA-Systemreplikation aktivieren

Im Rahmen der Aktivierung der SAP HANA-Systemreplikation müssen Sie die Daten und Schlüsseldateien für die sicheren SAP HANA-Speicher im Dateisystem (Secure Storage in File System, SSFS) vom primären zum sekundären Host kopieren. Die hier beschriebene Methode zum Kopieren der Dateien ist nur eine von mehreren möglichen Optionen.

1. Aktivieren Sie als SID_LCadm auf dem primären Host die Systemreplikation:

   > hdbnsutil -sr_enable --name=PRIMARY_HOST_NAME

2. Auf dem sekundären Host:

   1. Beenden Sie SAP HANA als SID_LCadm:

      > HDB stop

   2. Archivieren Sie als Root die vorhandene SSFS-Datendatei und die SSFS-Schlüsseldatei:

      # cd /usr/sap/SID/SYS/global/security/rsecssfs/
      # mv data/SSFS_SID.DAT data/SSFS_SID.DAT-ARC
      # mv key/SSFS_SID.KEY key/SSFS_SID.KEY-ARC

   3. Kopieren Sie die Datendatei vom primären Host:

      # scp -o StrictHostKeyChecking=no \
      PRIMARY_HOST_NAME:/usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT \
      /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT

   4. Kopieren Sie die Schlüsseldatei vom primären Host:

      # scp -o StrictHostKeyChecking=no \
      PRIMARY_HOST_NAME:/usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY \
      /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY

   5. Aktualisieren Sie die Eigentümerschaft für die Dateien:

      # chown SID_LCadm:sapsys /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT
      # chown SID_LCadm:sapsys /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY

   6. Aktualisieren Sie die Berechtigungen für die Dateien:

      # chmod 644 /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT
      # chmod 640 /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY

   7. Registrieren Sie als SID_LCadm das sekundäre SAP HANA-System bei der SAP HANA-Systemreplikation:

      > hdbnsutil -sr_register --remoteHost=PRIMARY_HOST_NAME --remoteInstance=INST_NUM \
      --replicationMode=syncmem --operationMode=logreplay --name=SECONDARY_HOST_NAME

   8. Starten Sie SAP HANA als SID_LCadm:

      > HDB start

Systemreplikation validieren

Prüfen Sie auf dem primären Host als SID_LCadm, ob die SAP HANA-Systemreplikation aktiv ist. Führen Sie dazu das folgende Python-Script aus:

$ python $DIR_INSTANCE/exe/python_support/systemReplicationStatus.py

Wenn die Replikation ordnungsgemäß eingerichtet ist, werden unter anderem für die Dienste xsengine, nameserver und indexserver die folgenden Werte angezeigt:

• Der Secondary Active Status ist YES.
• Der Replication Status ist ACTIVE.

Außerdem wird der overall system replication status als ACTIVE angezeigt.

Erforderliche HA-Pakete installieren

Für SLES for SAP 15 SP6 oder höher wird die Verwendung des Pakets SAPHanaSR-angi empfohlen. Für SLES for SAP 15 SP5 oder niedriger können Sie das Paket SAPHanaSR verwenden.

• Führen Sie als Root-Nutzer den folgenden Befehl aus, um das SAPHanaSR-Paket zu installieren:

  zypper install SAPHanaSR

• Führen Sie den folgenden Befehl als Root-Nutzer aus, um das SAPHanaSR-angi-Paket zu installieren:

  1. Wenn die SAPHanaSR- oder SAPHanaSR-doc-Pakete bereits installiert sind, entfernen Sie sie:

     zypper remove SAPHanaSR SAPHanaSR-doc

  2. Installieren Sie das Paket SAPHanaSR-angi:

     zypper install SAPHanaSR-angi

Provider-Hooks für SAP HANA HA/DR aktivieren

SUSE empfiehlt, die Provider-Hooks für SAP HANA-HA/DR zu aktivieren. Dadurch kann SAP HANA Benachrichtigungen für bestimmte Ereignisse senden und die Fehlererkennung verbessern. Die Provider-Hooks für SAP HANA HA/DR erfordern SAP HANA 2.0 SPS 03 oder höher für den SAPHanaSR-Hook und SAP HANA 2.0 SPS 05 oder höher für den SAPHanaSR-angi-Hook.

Hinweis: Wenn Sie die HA/DR-Provider-Hooks auf einem vorhandenen SAP HANA-System mit Ausfallzeiten von fast null implementieren möchten, lesen Sie stattdessen die Informationen unter Betriebsanleitung für SAP HANA.

Führen Sie sowohl auf der primären als auch auf der sekundären Website die folgenden Schritte aus:

1. Beenden Sie SAP HANA als SID_LCadm:

   > HDB stop

1. Öffnen Sie als Root oder SID_LCadm die Datei global.ini zur Bearbeitung:

   > vi /hana/shared/SID/global/hdb/custom/config/global.ini

2. Fügen Sie der Datei global.ini die folgenden Definitionen hinzu:

   SLES for SAP 15 SP5 oder niedriger

   [ha_dr_provider_SAPHanaSR]
   provider = SAPHanaSR
   path = /usr/share/SAPHanaSR/
   execution_order = 1
   
   [ha_dr_provider_suschksrv]
   provider = susChkSrv
   path = /usr/share/SAPHanaSR/
   execution_order = 3
   action_on_lost = stop
   
   
   [trace]
   ha_dr_saphanasr = info
   

   SLES for SAP 15 SP6 oder höher

   [ha_dr_provider_susHanaSR]
   provider = susHanaSR
   path = /usr/share/SAPHanaSR-angi
   execution_order = 1
   
   [ha_dr_provider_suschksrv]
   provider = susChkSrv
   path = /usr/share/SAPHanaSR-angi
   execution_order = 3
   action_on_lost = stop
   
   [ha_dr_provider_susTkOver]
   provider = susTkOver
   path = /usr/share/SAPHanaSR-angi
   execution_order = 1
   sustkover_timeout = 30
   
   [trace]
   ha_dr_sushanasr = info
   ha_dr_suschksrv = info
   ha_dr_sustkover = info

3. Erstellen Sie als Root eine benutzerdefinierte Konfigurationsdatei im Verzeichnis /etc/sudoers.d. Führen Sie dazu den folgenden Befehl aus. Mit dieser neuen Konfigurationsdatei kann der Nutzer SID_LCadm beim Aufrufen der Hook-Methode srConnectionChanged() auf die Clusterknotenattribute zugreifen.

   > sudo visudo -f /etc/sudoers.d/SAPHanaSR

4. Fügen Sie in der Datei /etc/sudoers.d/SAPHanaSR den folgenden Text hinzu:

   SLES for SAP 15 SP5 oder niedriger

   Ersetzen Sie Folgendes:

   • SITE_A: Standortname des primären SAP HANA-Servers.
   • SITE_B: Standortname des sekundären SAP HANA-Servers.
   • SID_LC: die SID, die in Kleinbuchstaben angegeben wird

   Zum Aufrufen der Websitenamen können Sie den Befehl crm_mon -A1 | grep site als Root-Nutzer entweder auf dem primären SAP HANA-Server oder auf dem sekundären Server ausführen.

   Cmnd_Alias SOK_SITEA = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_A -v SOK -t crm_config -s SAPHanaSR
   Cmnd_Alias SFAIL_SITEA = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_A -v SFAIL -t crm_config -s SAPHanaSR
   Cmnd_Alias SOK_SITEB = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_B -v SOK -t crm_config -s SAPHanaSR
   Cmnd_Alias SFAIL_SITEB = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_B -v SFAIL -t crm_config -s SAPHanaSR
   SID_LCadm ALL=(ALL) NOPASSWD: SOK_SITEA, SFAIL_SITEA, SOK_SITEB, SFAIL_SITEB

   SLES for SAP 15 SP6 oder höher

   Ersetzen Sie Folgendes:

   • SITE_A: Standortname des primären SAP HANA-Servers.
   • SITE_B: Standortname des sekundären SAP HANA-Servers.
   • SID_LC: die SID, die in Kleinbuchstaben angegeben wird

   Zum Aufrufen der Websitenamen können Sie den Befehl crm_mon -A1 | grep site als Root-Nutzer entweder auf dem primären SAP HANA-Server oder auf dem sekundären Server ausführen.

   Cmnd_Alias SOK_SITEA = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_A -v SOK -t crm_config -s SAPHanaSR
   Cmnd_Alias SFAIL_SITEA = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_A -v SFAIL -t crm_config -s SAPHanaSR
   Cmnd_Alias SOK_SITEB = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_B -v SOK -t crm_config -s SAPHanaSR
   Cmnd_Alias SFAIL_SITEB = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_B -v SFAIL -t crm_config -s SAPHanaSR
   Cmnd_Alias HOOK_HELPER = /usr/bin/SAPHanaSR-hookHelper --sid=SID --case=*
   SID_LCadm ALL=(ALL) NOPASSWD: SOK_SITEA, SFAIL_SITEA, SOK_SITEB, SFAIL_SITEB

5. Achten Sie darauf, dass in der Datei /etc/sudoers der folgende Text enthalten ist:

   • Für SLES for SAP 15 SP3 und höher:

     @includedir /etc/sudoers.d

   • Für Versionen bis SLES for SAP 15 SP2:

     #includedir /etc/sudoers.d

     Beachten Sie, dass die Datei # in diesem Text Teil der Syntax ist und nicht bedeutet, dass die Zeile ein Kommentar ist.

   Hinweis: Das Verfahren in diesem Abschnitt wird zwar von SUSE empfohlen, Sie können jedoch auch einen alternativen Ansatz verwenden. Anstatt eine Drop-in-Konfigurationsdatei zu erstellen, können Sie den erforderlichen Zugriff direkt auf die Datei /etc/sudoers einfügen.

6. Starten Sie SAP HANA als SID_LCadm:

   > HDB start

7. Nachdem Sie die Clusterkonfiguration für SAP HANA abgeschlossen haben, können Sie prüfen, ob der Hook während eines Failover-Tests ordnungsgemäß funktioniert, wie unter Fehlerbehebung für den SAPHanaSR-Python-Hook und HA-Cluster-Übernahme dauert zu lange bei einem HANA-Indexserverfehler beschrieben.

Failover-Unterstützung für Cloud Load Balancing konfigurieren

Der interne Passthrough-Network-Load-Balancer-Dienst mit Failover-Unterstützung leitet den Traffic basierend auf einem Systemdiagnosedienst an den aktiven Host in einem SAP HANA-Cluster weiter.

IP-Adresse für die virtuelle IP-Adresse reservieren

Die virtuelle IP-Adresse (VIP), die manchmal auch als Floating-IP-Adresse bezeichnet wird, folgt dem aktiven SAP HANA-System. Der Load-Balancer leitet den an die VIP gesendeten Traffic an die VM weiter, die derzeit das aktive SAP HANA-System hostet.

1. Öffnen Sie Cloud Shell:

   Zu Cloud Shell

2. IP-Adresse für die virtuelle IP-Adresse reservieren. Dies ist die IP-Adresse, mit der Anwendungen auf SAP HANA zugreifen. Wenn Sie das Flag --addresses weglassen, wird im angegebenen Subnetz automatisch eine IP-Adresse ausgewählt:

   $ gcloud compute addresses create VIP_NAME \
     --region CLUSTER_REGION --subnet CLUSTER_SUBNET \
     --addresses VIP_ADDRESS

   Weitere Informationen zum Reservieren einer statischen IP-Adresse finden Sie unter Statische interne IP-Adresse reservieren.

3. Bestätigen Sie die Reservierung der IP-Adresse:

   $ gcloud compute addresses describe VIP_NAME \
     --region CLUSTER_REGION

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

   address: 10.0.0.19
   addressType: INTERNAL
   creationTimestamp: '2020-05-20T14:19:03.109-07:00'
   description: ''
   id: '8961491304398200872'
   kind: compute#address
   name: vip-for-hana-ha
   networkTier: PREMIUM
   purpose: GCE_ENDPOINT
   region: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1
   selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/addresses/vip-for-hana-ha
   status: RESERVED
   subnetwork: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/subnetworks/example-subnet-us-central1

Instanzgruppen für Host-VMs erstellen

1. Erstellen Sie in Cloud Shell zwei nicht verwaltete Instanzgruppen und weisen Sie die primäre Master-Host-VM der einen und die sekundäre Master-Host-VM der anderen zu:

   $ gcloud compute instance-groups unmanaged create PRIMARY_IG_NAME \
     --zone=PRIMARY_ZONE
   $ gcloud compute instance-groups unmanaged add-instances PRIMARY_IG_NAME \
     --zone=PRIMARY_ZONE \
     --instances=PRIMARY_HOST_NAME
   $ gcloud compute instance-groups unmanaged create SECONDARY_IG_NAME \
     --zone=SECONDARY_ZONE
   $ gcloud compute instance-groups unmanaged add-instances SECONDARY_IG_NAME \
     --zone=SECONDARY_ZONE \
     --instances=SECONDARY_HOST_NAME
   

2. Bestätigen Sie die Erstellung der Instanzgruppen:

   $ gcloud compute instance-groups unmanaged list

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

   NAME          ZONE           NETWORK          NETWORK_PROJECT        MANAGED  INSTANCES
   hana-ha-ig-1  us-central1-a  example-network  example-project-123456 No       1
   hana-ha-ig-2  us-central1-c  example-network  example-project-123456 No       1

Compute Engine-Systemdiagnose erstellen

1. Erstellen Sie die Systemdiagnose in Cloud Shell: Wählen Sie für die Systemdiagnose einen Port aus dem privaten Bereich 49152-65535 aus, um Konflikte mit anderen Diensten zu vermeiden. Die Werte für Prüfintervall und Zeitlimit sind etwas länger als die Standardwerte, um die Failover-Toleranz während Compute Engine-Live-Migrationsereignissen zu erhöhen. Sie können die Werte bei Bedarf anpassen:

   $ gcloud compute health-checks create tcp HEALTH_CHECK_NAME --port=HEALTHCHECK_PORT_NUM \
     --proxy-header=NONE --check-interval=10 --timeout=10 --unhealthy-threshold=2 \
     --healthy-threshold=2

2. Bestätigen Sie die Erstellung der Systemdiagnose:

   $ gcloud compute health-checks describe HEALTH_CHECK_NAME

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

   checkIntervalSec: 10
   creationTimestamp: '2020-05-20T21:03:06.924-07:00'
   healthyThreshold: 2
   id: '4963070308818371477'
   kind: compute#healthCheck
   name: hana-health-check
   selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/hana-health-check
   tcpHealthCheck:
    port: 60000
    portSpecification: USE_FIXED_PORT
    proxyHeader: NONE
   timeoutSec: 10
   type: TCP
   unhealthyThreshold: 2

Firewallregel für die Systemdiagnosen erstellen

Definieren Sie eine Firewallregel für einen Port im privaten Bereich, die den Zugriff auf Ihre Host-VMs aus den IP-Bereichen ermöglicht, die von Compute Engine-Systemdiagnosen verwendet werden: 35.191.0.0/16 und 130.211.0.0/22. Weitere Informationen finden Sie unter Firewallregeln für Systemdiagnosen erstellen.

1. Fügen Sie Ihren Host-VMs ein Netzwerk-Tag hinzu, falls noch keines vorhanden ist. Dieses Netzwerk-Tag wird von der Firewallregel für Systemdiagnosen verwendet.

   $ gcloud compute instances add-tags PRIMARY_HOST_NAME \
     --tags NETWORK_TAGS \
     --zone PRIMARY_ZONE
   $ gcloud compute instances add-tags SECONDARY_HOST_NAME \
     --tags NETWORK_TAGS \
     --zone SECONDARY_ZONE
   

2. Wenn Sie noch keine haben, erstellen Sie eine Firewallregel, um die Systemdiagnosen zuzulassen:

   $ gcloud compute firewall-rules create RULE_NAME \
     --network NETWORK_NAME \
     --action ALLOW \
     --direction INGRESS \
     --source-ranges 35.191.0.0/16,130.211.0.0/22 \
     --target-tags NETWORK_TAGS \
     --rules tcp:HLTH_CHK_PORT_NUM

   Beispiel:

   gcloud compute firewall-rules create  fw-allow-health-checks \
   --network example-network \
   --action ALLOW \
   --direction INGRESS \
   --source-ranges 35.191.0.0/16,130.211.0.0/22 \
   --target-tags cluster-ntwk-tag \
   --rules tcp:60000

Load-Balancer und Failover-Gruppe konfigurieren

1. Erstellen Sie den Back-End-Dienst des Load-Balancers:

   $ gcloud compute backend-services create BACKEND_SERVICE_NAME \
     --load-balancing-scheme internal \
     --health-checks HEALTH_CHECK_NAME \
     --no-connection-drain-on-failover \
     --drop-traffic-if-unhealthy \
     --failover-ratio 1.0 \
     --region CLUSTER_REGION \
     --global-health-checks

2. Fügen Sie die primäre Instanzgruppe dem Back-End-Dienst hinzu:

   $ gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
     --instance-group PRIMARY_IG_NAME \
     --instance-group-zone PRIMARY_ZONE \
     --region CLUSTER_REGION

3. Fügen Sie die sekundäre Failover-Instanzgruppe dem Back-End-Dienst hinzu:

   $ gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
     --instance-group SECONDARY_IG_NAME \
     --instance-group-zone SECONDARY_ZONE \
     --failover \
     --region CLUSTER_REGION

4. Erstellen Sie eine Weiterleitungsregel. Geben Sie darin die IP-Adresse an, die Sie für die VIP reserviert haben: Wenn Sie von außerhalb der unten angegebenen Region auf das SAP HANA-System zugreifen müssen, fügen Sie das Flag --allow-global-access in die Definition ein:

   $ gcloud compute forwarding-rules create RULE_NAME \
     --load-balancing-scheme internal \
     --address VIP_ADDRESS \
     --subnet CLUSTER_SUBNET \
     --region CLUSTER_REGION \
     --backend-service BACKEND_SERVICE_NAME \
     --ports ALL

   Weitere Informationen zum regionenübergreifenden Zugriff auf Ihr SAP HANA-Hochverfügbarkeitssystem finden Sie unter Internes TCP/UDP-Load-Balancing.

Note: Your backend instance groups won't register as healthy until you have completed the Pacemaker cluster configuration.

Konfiguration des Load-Balancers testen

Auch wenn Ihre Back-End-Instanzgruppen erst später als fehlerfrei registriert werden, können Sie die Konfiguration des Load-Balancers testen. Richten Sie dazu einen Listener ein, der auf die Systemdiagnosen reagiert. Wenn der Load-Balancer nach der Einrichtung eines Listeners korrekt konfiguriert ist, ändert sich der Status der Back-End-Instanzgruppen in "fehlerfrei".

In den folgenden Abschnitten werden verschiedene Methoden vorgestellt, mit denen Sie die Konfiguration testen können.

Load-Balancer mit dem socat-Dienstprogramm testen

Mit dem socat-Dienstprogramm können Sie vorübergehend den Port der Systemdiagnose beobachten. Sie müssen das socat-Dienstprogramm ohnehin installieren, da Sie es später beim Konfigurieren von Clusterressourcen benötigen.

1. Installieren Sie als Root auf beiden Host-VMs das socat-Dienstprogramm:

   # zypper install -y socat

2. Starten Sie einen socat-Prozess, um 60 Sekunden lang den Port der Systemdiagnose zu überwachen:

   # timeout 60s socat - TCP-LISTEN:HLTH_CHK_PORT_NUM,fork

3. Warten Sie in Cloud Shell einige Sekunden, bis die Systemdiagnose den Listener erkennt, und prüfen Sie dann den Status Ihrer Back-End-Instanzgruppen:

   $ gcloud compute backend-services get-health BACKEND_SERVICE_NAME \
     --region CLUSTER_REGION

   Die Ausgabe sollte in etwa so aussehen:

   ---
   backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/hana-ha-ig-1
   status:
    healthStatus:
    ‐ healthState: HEALTHY
      instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-ha-vm-1
      ipAddress: 10.0.0.35
      port: 80
    kind: compute#backendServiceGroupHealth
   ---
   backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/hana-ha-ig-2
   status:
    healthStatus:
    ‐ healthState: HEALTHY
      instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/hana-ha-vm-2
      ipAddress: 10.0.0.34
      port: 80
    kind: compute#backendServiceGroupHealth

Load-Balancer über Port 22 testen

Wenn Port 22 für SSH-Verbindungen auf Ihren Host-VMs geöffnet ist, können Sie die Systemdiagnose so bearbeiten, dass vorübergehend Port 22 verwendet wird, da hier ein Listener konfiguriert ist, der auf die Systemdiagnose reagieren kann.

So verwenden Sie vorübergehend Port 22:

1. Klicken Sie in der Konsole auf Ihre Systemdiagnose:

   Zur Seite "Systemdiagnosen"

2. Klicken Sie auf Bearbeiten.

3. Ändern Sie im Feld Port die Portnummer in 22.

4. Klicken Sie auf Speichern und warten Sie ein bis zwei Minuten.

5. Prüfen Sie in Cloud Shell den Status Ihrer Back-End-Instanzgruppen:

   $ gcloud compute backend-services get-health BACKEND_SERVICE_NAME \
     --region CLUSTER_REGION

   Die Ausgabe sollte in etwa so aussehen:

   ---
   backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/hana-ha-ig-1
   status:
    healthStatus:
    ‐ healthState: HEALTHY
      instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-ha-vm-1
      ipAddress: 10.0.0.35
      port: 80
    kind: compute#backendServiceGroupHealth
   ---
   backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/hana-ha-ig-2
   status:
    healthStatus:
    ‐ healthState: HEALTHY
      instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/hana-ha-vm-2
      ipAddress: 10.0.0.34
      port: 80
    kind: compute#backendServiceGroupHealth

6. Wenn Sie fertig sind, ändern Sie die Portnummer der Systemdiagnose wieder in die ursprüngliche Portnummer.

Pacemaker einrichten

Mit dem folgenden Verfahren wird die SUSE-Implementierung eines Pacemaker-Clusters auf Compute Engine-VMs für SAP HANA konfiguriert.

Weitere Informationen zum Konfigurieren von Hochverfügbarkeitsclustern unter SLES finden Sie in der Dokumentation zu SUSE Linux Enterprise High Availability Extension für Ihre SLES-Version.

Corosync-Konfigurationsdateien erstellen

1. Erstellen Sie eine Corosync-Konfigurationsdatei auf dem primären Host:

   1. Erstellen Sie die folgende Datei:

       vi /etc/corosync/corosync.conf

   2. Fügen Sie auf dem primären Host in der Datei corosync.conf die folgende Konfiguration hinzu und ersetzen Sie den kursiv geschriebenen Variablentext durch Ihre Werte:

      totem {
       version: 2
       secauth: off
       crypto_hash: sha1
       crypto_cipher: aes256
       cluster_name: hacluster
       clear_node_high_bit: yes
       token: 20000
       token_retransmits_before_loss_const: 10
       join: 60
       max_messages:  20
       transport: udpu
       interface {
         ringnumber: 0
         Bindnetaddr: static-ip-of-hdb-on-this-host
         mcastport: 5405
         ttl: 1
       }
      }
      logging {
       fileline:  off
       to_stderr: no
       to_logfile: no
       logfile: /var/log/cluster/corosync.log
       to_syslog: yes
       debug: off
       timestamp: on
       logger_subsys {
         subsys: QUORUM
         debug: off
       }
      }
      nodelist {
       node {
         ring0_addr: this-host-name
         nodeid: 1
       }
       node {
         ring0_addr: other-host-name
         nodeid: 2
       }
      }
      quorum {
       provider: corosync_votequorum
       expected_votes: 2
       two_node: 1
      }

2. Erstellen Sie eine Corosync-Konfigurationsdatei auf dem sekundären Host. Wiederholen Sie dazu die Schritte, die Sie für den primären Host verwendet haben. Mit Ausnahme der statischen IP-Adresse der HDB für das Attribut Bindnetaddr und der Reihenfolge der Hostnamen in der nodelist sind die Attributwerte der Konfigurationsdatei für die Hosts identisch.

Cluster initialisieren

1. Als Root auf dem primären Host:

   1. Ändern Sie das Passwort für den Nutzer hacluster:

      # passwd hacluster

   2. Initialisieren Sie den Cluster:

      # corosync-keygen
      # crm cluster init --yes ssh
      # crm cluster init -y csync2

   3. Starten Sie Pacemaker auf dem primären Host:

      # systemctl enable pacemaker
      # systemctl start pacemaker

2. Als Root auf dem sekundären Host:

   1. Ändern Sie das Passwort für den Nutzer hacluster:

      # passwd hacluster

   2. Fügen Sie den sekundären Host dem Cluster hinzu, der auf dem primären Host initialisiert wird:

      # crm cluster join --yes ssh
      # crm cluster join -y -c primary-host-name csync2

   3. Starten Sie Pacemaker auf dem sekundären Host:

      # systemctl enable pacemaker
      # systemctl start pacemaker

3. Prüfen Sie als Root auf jedem Host, ob für den Cluster beide Knoten angezeigt werden:

   # crm_mon -s

   Die Ausgabe sollte in etwa so aussehen:

   CLUSTER OK: 2 nodes online, 0 resources configured

Fencing einrichten

Definieren Sie für jede Host-VM eine Cluster-Ressource mit einem Fencing-Agent, um Fencing einzurichten.

Um die korrekte Abfolge der Ereignisse nach einer Fencing-Aktion sicherzustellen, konfigurieren Sie das Betriebssystem auch so, dass der Neustart von Corosync nach dem Fencing einer VM verzögert wird. Sie können auch das Pacemaker-Zeitlimit für Neustarts anpassen, um die Verzögerung zu berücksichtigen.

Ressourcen für Fencing-Geräte erstellen

1. Erstellen Sie als Root auf dem primären Host die Fencing-Ressourcen:

   # crm configure primitive STONITH-"primary-host-name" stonith:fence_gce \
       op monitor interval="300s" timeout="120s" \
       op start interval="0" timeout="60s" \
       params port="primary-host-name" zone="primary-zone" project="project_id" \
       pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30

   # crm configure primitive STONITH-"secondary-host-name" stonith:fence_gce \
       op monitor interval="300s" timeout="120s" \
       op start interval="0" timeout="60s" \
       params port="secondary-host-name" zone="secondary-zone" project="project_id" \
       pcmk_reboot_timeout=300 pcmk_monitor_retries=4

2. Legen Sie den Standort der einzelnen Fencing-Geräte fest:

   # crm configure location LOC_STONITH_"primary-host-name" \
       STONITH-"primary-host-name" -inf: "primary-host-name"

   # crm configure location LOC_STONITH_"secondary-host-name" \
       STONITH-"secondary-host-name" -inf: "secondary-host-name"

Cluster konfigurieren

Zur Konfiguration des Clusters definieren Sie allgemeine Clusterattribute und die einfachen Clusterressourcen.

Wartungsmodus aktivieren

1. Versetzen Sie den Cluster als Root auf einem der Hosts in den Wartungsmodus:

   # crm configure property maintenance-mode="true"

Allgemeine Clusterattribute konfigurieren

1. Legen Sie auf dem primären Host die allgemeinen Clusterattribute fest:

   # crm configure property stonith-timeout="300s"
   # crm configure property stonith-enabled="true"
   # crm configure rsc_defaults resource-stickiness="1000"
   # crm configure rsc_defaults migration-threshold="5000"
   # crm configure op_defaults timeout="600"

Verzögerung für den Neustart von Corosync festlegen

1. Erstellen Sie auf beiden Hosts als Root eine systemd-Drop-in-Datei, die den Start von Corosync verzögert, um die richtige Reihenfolge der Ereignisse nach dem Neustart einer umzäunten VM zu gewährleisten:

   systemctl edit corosync.service

2. Fügen Sie der Datei die folgenden Zeilen hinzu:

   [Service]
   ExecStartPre=/bin/sleep 60

3. Speichern Sie die Datei und beenden Sie den Editor.

4. Laden Sie die Konfiguration des systemd-Managers neu.

   systemctl daemon-reload

5. Prüfen Sie, ob die Drop-in-Datei erstellt wurde:

   service corosync status

   Sie sollten eine Zeile für die Drop-in-Datei sehen, wie im folgenden Beispiel gezeigt:

   ● corosync.service - Corosync Cluster Engine
      Loaded: loaded (/usr/lib/systemd/system/corosync.service; disabled; vendor preset: disabled)
     Drop-In: /etc/systemd/system/corosync.service.d
              └─override.conf
      Active: active (running) since Tue 2021-07-20 23:45:52 UTC; 2 days ago

Lokale Cluster-IP-Ressource für die VIP-Adresse erstellen

Erstellen Sie zum Konfigurieren der VIP-Adresse im Betriebssystem eine lokale Cluster-IP-Ressource für die zuvor reservierte VIP-Adresse:

# crm configure primitive rsc_vip_int-primary IPaddr2 \
   params ip=vip-address cidr_netmask=32 nic="eth0" op monitor interval=3600s timeout=60s

Hilfsdienst zur Systemdiagnose einrichten

Der Load-Balancer verwendet einen Listener am Systemdiagnose-Port jedes Hosts, um zu ermitteln, wo die primäre Instanz des SAP HANA-Clusters ausgeführt wird.

Zur Verwaltung der Listener im Cluster erstellen Sie eine Ressource für den Listener.

In dieser Anleitung wird das socat-Dienstprogramm als Listener verwendet.

1. Installieren Sie als Root socat utility auf beiden Hosts:

   # zypper in -y socat

2. Erstellen Sie auf dem primären Host eine Ressource für den Hilfsdienst zur Systemdiagnose:

   # crm configure primitive rsc_healthcheck-primary anything \
     params binfile="/usr/bin/socat" \
     cmdline_options="-U TCP-LISTEN:healthcheck-port-num,backlog=10,fork,reuseaddr /dev/null" \
     op monitor timeout=20s interval=10s \
     op_params depth=0

Ressourcen für die VIP und den Hilfsdienst zur Systemdiagnose gruppieren

Gruppieren Sie die Ressourcen für die VIP und den Hilfsdienst zur Systemdiagnose:

# crm configure group g-primary rsc_vip_int-primary rsc_healthcheck-primary meta resource-stickiness=0

Einfache SAPHanaTopology-Ressource erstellen

Sie definieren die einfache SAPHanaTopology-Ressource in einer temporären Konfigurationsdatei, die Sie dann in Corosync hochladen.

Als Root auf dem primären Host:

1. Erstellen Sie eine temporäre Konfigurationsdatei für die SAPHanaTopology-Konfigurationsparameter:

   # vi /tmp/cluster.tmp

2. Kopieren Sie die SAPHanaTopology-Ressourcendefinitionen und fügen Sie sie in die Datei /tmp/cluster.tmp ein:

   SLES for SAP 15 SP5 oder niedriger

   primitive rsc_SAPHanaTopology_SID_HDBinst_num ocf:suse:SAPHanaTopology \
    operations \$id="rsc_sap2_SID_HDBinst_num-operations" \
    op monitor interval="10" timeout="600" \
    op start interval="0" timeout="600" \
    op stop interval="0" timeout="300" \
    params SID="SID" InstanceNumber="inst_num"
   
   clone cln_SAPHanaTopology_SID_HDBinst_num rsc_SAPHanaTopology_SID_HDBinst_num \
    meta clone-node-max="1" target-role="Started" interleave="true"

   SLES for SAP 15 SP6 oder höher

   primitive rsc_SAPHanaTopology_SID_HDBinst_num ocf:suse:SAPHanaTopology \
    operations \$id="rsc_sap2_SID_HDBinst_num-operations" \
    op monitor interval="10" timeout="600" \
    op start interval="0" timeout="600" \
    op stop interval="0" timeout="300" \
    params SID="SID" InstanceNumber="inst_num"
   
   clone cln_SAPHanaTopology_SID_HDBinst_num rsc_SAPHanaTopology_SID_HDBinst_num \
    meta clone-node-max="1" interleave="true"

3. Bearbeiten Sie die Datei /tmp/cluster.tmp, um den Variablentext durch die SID und die Instanznummer für Ihr SAP HANA-System zu ersetzen.

4. Laden Sie als Root auf dem primären Host den Inhalt der Datei /tmp/cluster.tmp in Corosync:

   crm configure load update /tmp/cluster.tmp

Einfache SAPHana- oder SAPHanaController-Ressource erstellen

Sie definieren die Ressource mit derselben Methode wie für die SAPHanaTopology-Ressource: in einer temporären Konfigurationsdatei, die Sie dann in Corosync hochladen.

1. Ersetzen Sie die temporäre Konfigurationsdatei:

   # rm /tmp/cluster.tmp
   # vi /tmp/cluster.tmp

2. Kopieren Sie die Ressourcendefinitionen und fügen Sie sie in die Datei /tmp/cluster.tmp ein:

   SLES for SAP 15 SP5 oder niedriger

   primitive rsc_SAPHana_SID_HDBinst_num ocf:suse:SAPHana \
    operations \$id="rsc_sap_SID_HDBinst_num-operations" \
    op start interval="0" timeout="3600" \
    op stop interval="0" timeout="3600" \
    op promote interval="0" timeout="3600" \
    op demote interval="0" timeout="3600" \
    op monitor interval="60" role="Master" timeout="700" \
    op monitor interval="61" role="Slave" timeout="700" \
    params SID="SID" InstanceNumber="inst_num" PREFER_SITE_TAKEOVER="true"
    DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="true"
   
   ms msl_SAPHana_SID_HDBinst_num rsc_SAPHana_SID_HDBinst_num \
    meta notify="true" clone-max="2" clone-node-max="1" \
    target-role="Started" interleave="true"
   
   colocation col_saphana_ip_SID_HDBinst_num 4000: g-primary:Started \
    msl_SAPHana_SID_HDBinst_num:Master
   order ord_SAPHana_SID_HDBinst_num Optional: cln_SAPHanaTopology_SID_HDBinst_num \
    msl_SAPHana_SID_HDBinst_num

   SLES for SAP 15 SP6 oder höher

   primitive rsc_SAPHana_SID_HDBinst_num ocf:suse:SAPHanaController \
    operations \$id="rsc_sap_SID_HDBinst_num-operations" \
    op start interval="0" timeout="3600" \
    op stop interval="0" timeout="3600" \
    op promote interval="0" timeout="3600" \
    op demote interval="0" timeout="3600" \
    op monitor interval="60" role="Promoted" timeout="700" \
    op monitor interval="61" role="Unpromoted" timeout="700" \
    params SID="SID" InstanceNumber="inst_num" PREFER_SITE_TAKEOVER="true" \
    DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="true"
   
   clone mst_SAPHana_SID_HDBinst_num rsc_SAPHana_SID_HDBinst_num \
    meta clone-node-max="1" interleave="true" promotable="true"
   
   colocation col_saphana_ip_SID_HDBinst_num 4000: g-primary:Started \
    mst_SAPHana_SID_HDBinst_num:Promoted
   order ord_SAPHana_SID_HDBinst_num Optional: cln_SAPHanaTopology_SID_HDBinst_num \
    mst_SAPHana_SID_HDBinst_num

   Wenn Sie für einen mehrstufigen SAP HANA-HA-Cluster eine ältere Version als SAP HANA 2.0 SP03 verwenden, legen Sie AUTOMATED_REGISTER auf false fest. Dadurch wird verhindert, dass eine wiederhergestellte Instanz versucht, sich selbst für eine Replikation auf ein HANA-System zu registrieren, auf dem bereits ein Replikationsziel konfiguriert ist. Bei SAP HANA 2.0 SP03 oder höher können Sie für SAP HANA-Konfigurationen, die eine mehrstufige Systemreplikation verwenden, AUTOMATED_REGISTER auf true setzen.

   Weitere Informationen finden Sie unter:

   • SAP HANA-Systemreplikation mit vertikaler Skalierung
   • HANA-HA mit vertikaler Skalierung, Systemreplikation und automatisiertem Failover

3. Laden Sie als Root auf dem primären Host den Inhalt der Datei /tmp/cluster.tmp in Corosync:

   crm configure load update /tmp/cluster.tmp

Einfache SAPHanaFilesystem-Ressource erstellen

Dieser Abschnitt gilt nur, wenn Sie den SAPHanaSR-angi-Hook verwenden. Wenn Sie den SAPHanaSR-Hook verwenden, können Sie diesen Abschnitt überspringen.

Sie erstellen die SAPHanaFilesystem-Ressource mit derselben Methode wie die SAPHanaTopology-Ressource: in einer temporären Konfigurationsdatei, die Sie dann in Corosync hochladen.

1. Ersetzen Sie die temporäre Konfigurationsdatei:

   rm /tmp/cluster.tmp
   vi /tmp/cluster.tmp

2. Kopieren Sie die Ressourcendefinitionen für SAPHana und fügen Sie sie in die Datei /tmp/cluster.tmp ein:

   primitive rsc_SAPHanaFileSystem_SID_HDBinst_num ocf:suse:SAPHanaFilesystem \
     operations \$id="rsc_sap3_SID_HDBinst_num-operations" \
     op monitor interval="10" timeout="600" \
     op start interval="0" timeout="600" \
     op stop interval="0" timeout="300" \
     params SID="SID" InstanceNumber="inst_num"
   
   clone cln_SAPHanaFileSystem_SID_HDBinst_num rsc_SAPHanaFileSystem_SID_HDBinst_num \
     meta clone-node-max="1  interleave="true"

Prüfen, ob die SAP HANA-Systemreplikation aktiv ist

1. Melden Sie sich auf dem primären Host als SID_LCadm im interaktiven Terminal der SAP HANA-Datenbank an:

   > hdbsql -u system -p "system-password" -i inst_num

2. Prüfen Sie im interaktiven Terminal den Replikationsstatus:

   => select distinct REPLICATION_STATUS from SYS.M_SERVICE_REPLICATION

   Der REPLICATION_STATUS sollte "ACTIVE" lauten.

Alternativ können Sie den Replikationsstatus prüfen, indem Sie das folgende Python-Script als SID_LCadm ausführen:

# python $DIR_INSTANCE/exe/python_support/systemReplicationStatus.py

Cluster aktivieren

1. Deaktivieren Sie als Root auf dem primären Host den Wartungsmodus für den Cluster:

   # crm configure property maintenance-mode="false"

   Wenn Sie dazu aufgefordert werden, „maintenance“ zu entfernen, geben Sie y ein.

2. Warten Sie 15 Sekunden und prüfen Sie dann als Root auf dem primären Host den Status des Clusters:

   # crm status

   Das folgende Beispiel zeigt den Status eines aktiven, ordnungsgemäß konfigurierten Clusters:

   SLES for SAP 15 SP5 oder niedriger

   Stack: corosync
   Current DC: hana-ha-vm-1 (version 2.0.1+20190417.13d370ca9-3.9.1-2.0.1+20190417.13d370ca9) - partition with quorum
   Last updated: Sun Jun  7 00:36:56 2020
   Last change: Sun Jun  7 00:36:53 2020 by root via crm_attribute on hana-ha-vm-1
   
   2 nodes configured
   8 resources configured
   
   Online: [ hana-ha-vm-1 hana-ha-vm-2 ]
   
   Full list of resources:
   
   STONITH-hana-ha-vm-1   (stonith:fence_gce):  Started hana-ha-vm-2
   STONITH-hana-ha-vm-2   (stonith:fence_gce):  Started hana-ha-vm-1
   Clone Set: cln_SAPHanaTopology_HA1_HDB22 [rsc_SAPHanaTopology_HA1_HDB22]
       Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
   Resource Group: g-primary
       rsc_vip_int-primary        (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-1
       rsc_healthcheck-primary        (ocf::heartbeat:anything):      Started hana-ha-vm-1
   Clone Set: msl_SAPHana_HA1_HDB22 [rsc_SAPHana_HA1_HDB22] (promotable)
       Masters: [ hana-ha-vm-1 ]
       Slaves: [ hana-ha-vm-2 ]

   SLES for SAP 15 SP6 oder höher

   Stack: corosync
   Current DC: hana-ha-vm-1 (version 2.1.7+20231219.0f7f88312-150600.6.3.1-2.1.7+20231219.0f7f88312) - partition with quorum
   Last updated: Tue Oct 15 03:26:11 2024
   Last change: Tue Oct 15 03:26:08 2024 by root via via crm_attribute on hana-ha-vm-1
   
   2 nodes configured
   10 resources configured
   
   Online: [ hana-ha-vm-1 hana-ha-vm-2 ]
   
   Full list of resources:
   
   STONITH-hana-ha-vm-1   (stonith:fence_gce):  Started hana-ha-vm-2
   STONITH-hana-ha-vm-2   (stonith:fence_gce):  Started hana-ha-vm-1
   Resource Group: g-primary
       rsc_vip_int-primary        (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-1
       rsc_healthcheck-primary        (ocf::heartbeat:anything):      Started hana-ha-vm-1
   Clone Set: cln_SAPHanaTopology_HA1_HDB22 [rsc_SAPHanaTopology_HA1_HDB22]
       Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
   Clone Set: cln_SAPHanaFileSystem_HA1_HDB22 [rsc_SAPHanaFilesystem_HA1_HDB22]
       Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
   Clone Set: mst_SAPHana_HA1_HDB22 [rsc_SAPHana_HA1_HDB22] (promotable)
       Masters: [ hana-ha-vm-1 ]
       Slaves: [ hana-ha-vm-2 ]

Failover testen

Testen Sie Ihren Cluster, indem Sie einen Ausfall auf dem primären Host simulieren. Verwenden Sie ein Testsystem oder führen Sie den Test auf Ihrem Produktionssystem durch, bevor Sie das System für die Verwendung freigeben.

Sichern Sie vor dem Test das System.

Sie können einen Ausfall auf unterschiedliche Weise simulieren, z. B. so:

• HDB stop
• HDB kill
• reboot (auf dem aktiven Knoten)
• ip link set eth0 down für Instanzen mit einer einzelnen Netzwerkschnittstelle
• iptables ... DROP für Instanzen mit mehreren Netzwerkschnittstellen
• echo c > /proc/sysrq-trigger

Diese Anleitung verwendet ip link set eth0 down oder iptables, um eine Netzwerkunterbrechung zwischen den beiden Hosts in Ihrem Cluster zu simulieren. Verwenden Sie den Befehl ip link für eine Instanz mit einer einzelnen Netzwerkschnittstelle und den Befehl iptables für Instanzen mit einer oder mehreren Netzwerkschnittstellen. Der Test validiert sowohl Failover als auch Fencing. Wenn für die Instanzen mehrere Netzwerkschnittstellen definiert sind, verwenden Sie den Befehl iptables auf dem sekundären Host, um eingehenden und ausgehenden Traffic anhand der IP-Adresse zu löschen, die vom primären Host für die Cluster-Kommunikation verwendet wird, wodurch ein Verlust der Netzwerkverbindung zum primären Knoten simuliert wird.

1. Schalten Sie als Root auf dem aktiven Host die Netzwerkschnittstelle offline:

   # ip link set eth0 down

   Wenn mehrere Netzwerkschnittstellen aktiv sind, verwenden Sie iptables auf dem sekundären Host:

   # iptables -A INPUT -s PRIMARY_CLUSTER_IP -j DROP; iptables -A OUTPUT -d PRIMARY_CLUSTER_IP -j DROP

2. Stellen Sie eine SSH-Verbindung zu einem der Hosts her und wechseln Sie zum Root-Nutzer.

3. Geben Sie crm status ein, um zu prüfen, ob der primäre Host jetzt auf der VM aktiv ist, auf der sich zuvor der sekundäre Host befand. Da im Cluster der automatische Neustart aktiviert ist, wird der angehaltene Host neu gestartet und übernimmt wie im folgenden Beispiel gezeigt die Rolle des sekundären Hosts.

   SLES for SAP 15 SP5 oder niedriger

   Stack: corosync
   Current DC: hana-ha-vm-2 (version 2.0.1+20190417.13d370ca9-3.9.1-2.0.1+20190417.13d370ca9) - partition with quorum
   Last updated: Fri Jun 12 16:46:07 2020
   Last change: Fri Jun 12 16:46:07 2020 by root via crm_attribute on hana-ha-vm-2
   
   2 nodes configured
   8 resources configured
   
   Online: [ hana-ha-vm-1 hana-ha-vm-2 ]
   
   Full list of resources:
   
    STONITH-hana-ha-vm-1   (stonith:fence_gce):  Started hana-ha-vm-2
    STONITH-hana-ha-vm-2   (stonith:fence_gce):  Started hana-ha-vm-1
    
    Clone Set: cln_SAPHanaTopology_HA1_HDB22 [rsc_SAPHanaTopology_HA1_HDB22]
        Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
    Resource Group: g-primary
        rsc_vip_int-primary        (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-2
        rsc_healthcheck-primary        (ocf::heartbeat:anything):      Started hana-ha-vm-2
    Clone Set: msl_SAPHana_HA1_HDB22 [rsc_SAPHana_HA1_HDB22] (promotable)
        Masters: [ hana-ha-vm-2 ]
        Slaves: [ hana-ha-vm-1 ]

   SLES for SAP 15 SP6 oder höher

   Stack: corosync
   Current DC: hana-ha-vm-2 (version 2.1.7+20231219.0f7f88312-150600.6.3.1-2.1.7+20231219.0f7f88312) - partition with quorum
   Last updated: Tue Oct 15 05:26:18 2024
   Last change: Tue Oct 15 05:26:18 2024 by root via via crm_attribute on hana-ha-vm-1
   
   2 nodes configured
   10 resources configured
   
   Online: [ hana-ha-vm-1 hana-ha-vm-2 ]
   
   Full list of resources:
   
    STONITH-hana-ha-vm-1   (stonith:fence_gce):  Started hana-ha-vm-2
    STONITH-hana-ha-vm-2   (stonith:fence_gce):  Started hana-ha-vm-1
    
    Resource Group: g-primary
        rsc_vip_int-primary        (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-2
        rsc_healthcheck-primary        (ocf::heartbeat:anything):      Started hana-ha-vm-2
    Clone Set: cln_SAPHanaTopology_HA1_HDB22 [rsc_SAPHanaTopology_HA1_HDB22]
        Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
    Clone Set: cln_SAPHanaFileSystem_HA1_HDB22 [rsc_SAPHanaFileSystem_HA1_HDB22]
        Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
    Clone Set: mst_SAPHana_HA1_HDB22 [rsc_SAPHana_HA1_HDB22] (promotable)
        Masters: [ hana-ha-vm-2 ]
        Slaves: [ hana-ha-vm-1 ]

HANA Aktiv/Aktiv konfigurieren (Lesezugriff aktiviert)

Ab SAP HANA 2.0 SPS1 können Sie HANA Aktiv/Aktiv (Lesezugriff aktiviert) in einem Pacemaker-Cluster konfigurieren. Dies ist optional.

Führen Sie die folgenden Schritte aus, um HANA Aktiv/Aktiv (Lesezugriff aktiviert) in einem Pacemaker-Cluster zu konfigurieren.

Failover-Unterstützung für den Cloud Load Balancing für den sekundären Host konfigurieren

Der interne Passthrough-Network-Load-Balancer-Dienst mit Failover-Unterstützung leitet den Traffic basierend auf einem Systemdiagnosedienst an den sekundären Host in einem SAP HANA-Cluster weiter.

So konfigurieren Sie die Failover-Unterstützung für den sekundären Host:

1. Öffnen Sie Cloud Shell:

   Zu Cloud Shell

2. Reservieren Sie eine IP-Adresse für die virtuelle IP-Adresse. Führen Sie dazu den folgenden Befehl aus.

   Die virtuelle IP-Adresse (VIP) folgt dem sekundären SAP HANA-System. Dies ist die IP-Adresse, mit der Anwendungen auf Ihr sekundäres SAP HANA-System zugreifen. Der Load-Balancer leitet den an die VIP gesendeten Traffic an die VM-Instanz weiter, die derzeit das sekundäre System hostet.

   Wenn Sie im folgenden Befehl das Flag --addresses weglassen, wird im angegebenen Subnetz automatisch eine IP-Adresse ausgewählt. Weitere Informationen zum Reservieren einer statischen IP-Adresse finden Sie unter Statische interne IP-Adresse reservieren.

   $ gcloud compute addresses create secondary-vip-name \
     --region cluster-region --subnet cluster-subnet \
     --addresses secondary-vip-address

3. Erstellen Sie eine Compute Engine-Systemdiagnose, indem Sie den folgenden Befehl ausführen.

   Wählen Sie für die Systemdiagnose einen Port aus dem privaten Bereich 49152-65535 aus, um Konflikte mit anderen Diensten zu vermeiden. Der Port sollte sich von dem Port unterscheiden, der für die Systemdiagnose konfiguriert ist, die für den primären HANA-Systemzugriff verwendet wird. Die Werte für Prüfintervall und Zeitlimit sind etwas länger als die Standardwerte, um die Failover-Toleranz während Compute Engine-Live-Migrationsereignissen zu erhöhen. Sie können die Werte bei Bedarf anpassen.

   $ gcloud compute health-checks create tcp secondary-health-check-name \
     --port=secondary-healthcheck-port-num \
     --proxy-header=NONE --check-interval=10 --timeout=10 --unhealthy-threshold=2 \
     --healthy-threshold=2

4. Konfigurieren Sie den Load-Balancer und die Failover-Gruppe, indem Sie die folgenden Befehle ausführen.

   Hier erstellen Sie einen zusätzlichen Backend-Dienst und verwenden dieselben Instanzgruppen, die Sie zuvor für den Backend-Dienst hinter dem internen TCP/UDP-Load-Balancer für das primäre SAP HANA-System erstellt haben.

   1. Erstellen Sie den Backend-Dienst des Load-Balancers:

      $ gcloud compute backend-services create secondary-backend-service-name \
        --load-balancing-scheme internal \
        --health-checks secondary-health-check-name \
        --no-connection-drain-on-failover \
        --drop-traffic-if-unhealthy \
        --failover-ratio 1.0 \
        --region cluster-region \
        --global-health-checks

   2. Fügen Sie die primäre Instanzgruppe dem Back-End-Dienst hinzu:

      $ gcloud compute backend-services add-backend secondary-backend-service-name \
        --instance-group primary-ig-name \
        --instance-group-zone primary-zone \
        --region cluster-region

   3. Fügen Sie die sekundäre Failover-Instanzgruppe dem Back-End-Dienst hinzu:

      $ gcloud compute backend-services add-backend secondary-backend-service-name \
        --instance-group secondary-ig-name \
        --instance-group-zone secondary-zone \
        --failover \
        --region cluster-region

   4. Erstellen Sie eine Weiterleitungsregel.

      Geben Sie darin die IP-Adresse an, die Sie für die VIP reserviert haben: Wenn Sie außerhalb der Region, die Sie im folgenden Befehl angeben, auf das sekundäre HANA-System zugreifen müssen, fügen Sie in die Definition der Weiterleitungsregel das Flag --allow-global-access ein.

      $ gcloud compute forwarding-rules create secondary-rule-name \
        --load-balancing-scheme internal \
        --address secondary-vip-name \
        --subnet cluster-subnet \
        --region cluster-region \
        --backend-service secondary-backend-service-name \
        --ports ALL

      Weitere Informationen zum regionenübergreifenden Zugriff auf Ihr SAP HANA-Hochverfügbarkeitssystem finden Sie unter Internes TCP/UDP-Load-Balancing.

HANA Aktiv/Aktiv (Lesezugriff aktiviert) aktivieren

Aktivieren Sie auf Ihrem sekundären Host die Aktiv/Aktiv-Funktion (Lesezugriff aktiviert) für die SAP HANA-Systemreplikation. Gehen Sie dazu so vor:

1. Versetzen Sie den Cluster als Root in den Wartungsmodus:

   # crm configure property maintenance-mode="true"

2. Beenden Sie SAP HANA als SID_LCadm:

   > HDB stop

3. Melden Sie sich als SID_LCadm noch einmal das sekundäre HANA-System bei der SAP HANA-Systemreplikation im Betriebsmodus logreplay_readaccess an:

   > hdbnsutil -sr_register --remoteHost=primary-host-name --remoteInstance=inst_num \
    --replicationMode=syncmem --operationMode=logreplay_readaccess --name=secondary-host-name

4. Starten Sie SAP HANA als SID_LCadm:

   > HDB start

5. Prüfen Sie als SID_LCadm, ob der HANA-Synchronisierungsstatus ACTIVE lautet:

   > cdpy; python systemReplicationStatus.py --sapcontrol=1 | grep overall_replication_status

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

   overall_replication_status=ACTIVE

Pacemaker konfigurieren

Konfigurieren Sie Ihren Pacemaker-HA-Cluster für Aktiv/Aktiv (Lesezugriff aktiviert), indem Sie die folgenden Befehle als Root ausführen:

1. Erstellen Sie eine lokale Cluster-IP-Ressource für die VIP-Adresse, die Sie für das sekundäre System reserviert haben:

   # crm configure primitive rsc_vip_int-secondary IPaddr2 \
     params ip=secondary-vip-address cidr_netmask=32 nic="eth0" \
     op monitor interval=3600s timeout=60s

2. Richten Sie den Hilfsdienst für die Systemdiagnose mit den folgenden Befehlen ein:

   Der Load-Balancer verwendet einen Listener am Systemdiagnose-Port jedes Hosts, um zu ermitteln, wo die sekundäre Instanz des SAP HANA-Clusters ausgeführt wird.

   1. Zur Verwaltung der Listener im Cluster erstellen Sie eine Ressource für den Listener. In dieser Anleitung wird das socat-Dienstprogramm als Listener verwendet. Erstellen Sie eine Ressource für den Hilfsdienst zur Systemdiagnose:

      # crm configure primitive rsc_healthcheck-secondary anything \
       params binfile="/usr/bin/socat" \
       cmdline_options="-U TCP-LISTEN:secondary-healthcheck-port-num,backlog=10,fork,reuseaddr /dev/null" \
       op monitor timeout=20s interval=10s \
       op_params depth=0

   2. Ressourcen für die VIP und den Hilfsdienst zur Systemdiagnose gruppieren:

      # crm configure group g-secondary rsc_vip_int-secondary rsc_healthcheck-secondary meta resource-stickiness=0

3. Erstellen Sie eine Colocation-Einschränkung:

   SLES for SAP 15 SP5 oder niedriger

   # crm configure colocation col_saphana_secondary 4000: g-secondary:Started \
    msl_SAPHana_SID_HDBinst_num:Slave

   SLES for SAP 15 SP6 oder höher

   # crm configure colocation col_saphana_secondary 4000: g-secondary:Started \
    mst_SAPHana_SID_HDBinst_num:Unpromoted

4. Beenden Sie den Clusterwartungsmodus:

   # crm configure property maintenance-mode="false"

5. Prüfen Sie den Clusterstatus:

   # crm status

   Die folgenden Beispiele zeigen den Status eines aktiven, ordnungsgemäß konfigurierten Clusters für die SAP HANA-Systemreplikation mit Aktiv/Aktiv (Lesezugriff aktiviert). Sie sollten eine zusätzliche Ressourcengruppe für die VIP-Ressourcen des sekundären Systems sehen. Im folgenden Beispiel lautet der Name dieser Ressourcengruppe g-secondary.

   SLES for SAP 15 SP5 oder niedriger

   Cluster Summary:
    Stack: corosync
    Current DC: hana-ha-vm-1 (version 2.0.4+20200616.2deceaa3a-3.15.1-2.0.4+20200616.2deceaa3a) - partition with quorum
    Last updated: Fri Oct  7 21:52:46 2022
    Last change:  Fri Oct  7 21:51:42 2022 by root via crm_attribute on hana-ha-vm-1
   
    2 nodes configured
    10 resource instances configured
   
   Node List:
    Online: [ hana-ha-vm-1 hana-ha-vm-2 ]
   
   Active Resources:
    STONITH-hana-ha-vm-1  (stonith:fence_gce):   Started hana-ha-vm-2
    STONITH-hana-ha-vm-2  (stonith:fence_gce):   Started hana-ha-vm-1
    Resource Group: g-primary:
      rsc_vip_int-primary       (ocf::heartbeat:IPaddr2):        Started hana-ha-vm-1
      rsc_vip_hc-primary        (ocf::heartbeat:anything):       Started hana-ha-vm-1
    Clone Set: cln_SAPHanaTopology_HA1_HDB00 [rsc_SAPHanaTopology_HA1_HDB00]:
      Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
    Clone Set: msl_SAPHana_HA1_HDB00 [rsc_SAPHana_HA1_HDB00] (promotable):
      Masters: [ hana-ha-vm-1 ]
      Slaves: [ hana-ha-vm-2 ]
    Resource Group: g-secondary:
      rsc_vip_int-secondary       (ocf::heartbeat:IPaddr2):        Started hana-ha-vm-2
      rsc_healthcheck-secondary   (ocf::heartbeat:anything):       Started hana-ha-vm-2

   SLES for SAP 15 SP6 oder höher

   Cluster Summary:
    Stack: corosync
    Current DC: hana-ha-vm-1 (version 2.1.7+20231219.0f7f88312-150600.6.3.1-2.1.7+20231219.0f7f88312) - partition with quorum
    Last updated: Tue Oct 15 05:46:18 2024
    Last change: Tue Oct 15 05:46:18 2024 by root via via crm_attribute on hana-ha-vm-1
   
    2 nodes configured
    10 resource instances configured
   
   Node List:
    Online: [ hana-ha-vm-1 hana-ha-vm-2 ]
   
   Active Resources:
    STONITH-hana-ha-vm-1  (stonith:fence_gce):   Started hana-ha-vm-2
    STONITH-hana-ha-vm-2  (stonith:fence_gce):   Started hana-ha-vm-1
    Resource Group: g-primary:
      rsc_vip_int-primary       (ocf::heartbeat:IPaddr2):        Started hana-ha-vm-1
      rsc_vip_hc-primary        (ocf::heartbeat:anything):       Started hana-ha-vm-1
    Clone Set: cln_SAPHanaTopology_HA1_HDB00 [rsc_SAPHanaTopology_HA1_HDB00]:
      Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
    Clone Set: cln_SAPHanaFileSystem_HA1_HDB00 [rsc_SAPHanaFileSystem_HA1_HDB00]:
      Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
    Clone Set: mst_SAPHana_HA1_HDB00 [rsc_SAPHana_HA1_HDB00] (promotable):
      Masters: [ hana-ha-vm-1 ]
      Slaves: [ hana-ha-vm-2 ]
    Resource Group: g-secondary:
      rsc_vip_int-secondary       (ocf::heartbeat:IPaddr2):        Started hana-ha-vm-2
      rsc_healthcheck-secondary   (ocf::heartbeat:anything):       Started hana-ha-vm-2

SAP HANA-Arbeitslast bewerten

Mit Workload Manager können Sie kontinuierliche Validierungsprüfungen für Ihre hochverfügbaren Arbeitslasten von SAP HANA automatisieren, die in Google Cloud ausgeführt werden.

Mit Workload Manager können Sie Ihre hochverfügbaren Arbeitslasten von SAP HANA automatisch anhand von Best Practices von SAP, Google Cloud und Betriebssystemanbietern scannen und bewerten. Dies verbessert die Qualität, Leistung und Zuverlässigkeit Ihrer Arbeitslasten.

Informationen zu den Best Practices, die Workload Manager für die Bewertung von hochverfügbaren Arbeitslasten von SAP HANA in der Google Cloud unterstützt, finden Sie unter Best Practices von Workload Manager für SAP. Informationen zum Erstellen und Ausführen einer Bewertung mit Workload Manager finden Sie unter Evaluierung erstellen und ausführen.

Fehlerbehebung

Informationen zur Fehlerbehebung bei Problemen mit Hochverfügbarkeitskonfigurationen für SAP HANA unter SLES finden Sie unter Fehlerbehebung bei Hochverfügbarkeitskonfigurationen für SAP.

Support für SAP HANA unter SLES

Wenn Sie Hilfe bei einem Problem mit Hochverfügbarkeitsclustern für SAP HANA unter SLES benötigen, stellen Sie die erforderlichen Diagnoseinformationen zusammen und wenden Sie sich an den Cloud Customer Care. Weitere Informationen finden Sie unter Diagnoseinformationen zu Hochverfügbarkeitsclustern auf SLES.

Support

Wenden Sie sich bei Problemen mit der Infrastruktur oder den Diensten von Google Cloud an Customer Care. Kontaktdaten finden Sie in der Google Cloud Console auf der Seite Supportübersicht. Wenn Customer Care feststellt, dass sich um ein Problem Ihres SAP-Systems handelt, werden Sie an den SAP-Support verwiesen.

Reichen Sie bei Problemen in Zusammenhang mit SAP-Produkten Ihre Supportanfrage beim SAP-Support ein. SAP wertet das Support-Ticket aus und leitet es, wenn es sich um ein Problem mit der Google Cloud-Infrastruktur handelt, gegebenenfalls an die entsprechende Google Cloud-Komponente in seinem System weiter: BC-OP-LNX-GOOGLE oder BC-OP-NT-GOOGLE.

Supportanforderungen

Bevor Sie Support für SAP-Systeme sowie für die Infrastruktur und Dienste von Google Cloud erhalten können, müssen Sie die Mindestanforderungen für den Supportplan erfüllen.

Weitere Informationen zu den Mindestsupportanforderungen für SAP in Google Cloud finden Sie hier:

• Support für SAP in Google Cloud
• SAP-Hinweis 2456406 – SAP auf der Google Cloud Platform: Support-Voraussetzungen (SAP-Nutzerkonto erforderlich)

Verbindung zu SAP HANA herstellen

Wenn die Host-VMs keine externe IP-Adresse für SAP HANA haben, können Sie die Verbindung zu den SAP HANA-Instanzen nur über die Bastion-Instanz mit SSH oder über den Windows-Server mit SAP HANA Studio herstellen.

• Wenn Sie die Verbindung zu SAP HANA über die Bastion-Instanz herstellen möchten, stellen Sie zuerst über einen SSH-Client Ihrer Wahl eine Verbindung zum Bastion Host und anschließend zu den SAP HANA-Instanzen her.

• Zum Herstellen einer Verbindung mit der SAP HANA-Datenbank über SAP HANA Studio verwenden Sie einen Remote-Desktop-Client, um eine Verbindung zur Windows Server-Instanz herzustellen. Nach dem Verbindungsaufbau installieren Sie SAP HANA Studio manuell und greifen auf Ihre SAP HANA-Datenbank zu.

Aufgaben nach der Bereitstellung

Führen Sie nach der Bereitstellung die folgenden Schritte aus:

1. Ändern Sie die temporären Passwörter für den SAP HANA-Systemadministrator und den Datenbank-Superuser. Beispiel:

   sudo passwd SID_LCadm

   Informationen von SAP zum Ändern des Passworts finden Sie unter System-Passwort der Systemdatenbank zurücksetzen.

2. Bevor Sie Ihre SAP HANA-Instanz verwenden, konfigurieren und sichern Sie die neue SAP HANA-Datenbank.

3. Wenn Ihr SAP HANA-System in einer VirtIO-Netzwerkschnittstelle bereitgestellt wird, empfehlen wir, den Wert des TCP-Parameters /proc/sys/net/ipv4/tcp_limit_output_bytes auf 1048576 zu setzen. Diese Änderung hilft, den Gesamtdurchsatz des Netzwerks der VirtIO-Netzwerkschnittstelle zu verbessern, ohne die Netzwerklatenz zu beeinträchtigen.

Weitere Informationen finden Sie unter:

• Betriebsanleitung für SAP HANA
• Installations- und Aktualisierungsanleitung für SAP HANA

Weitere Informationen

Mehr erfahren Sie unter den folgenden Links:

Automatisierte SAP HANA-Systemreplikation beim vertikalen Skalieren im Pacemaker-Cluster

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

Leitfaden zur Notfallwiederherstellung für SAP HANA

Weitere Informationen zu VM-Verwaltung und VM-Monitoring finden Sie in der Betriebsanleitung für SAP HANA.