Konfigurationsanleitung für horizontal 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 horizontal 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.

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

Nach dieser Anleitung stellen Sie ein SAP HANA-HA-System mit mehreren Knoten bereit, das für vollständige Zonenredundanz konfiguriert ist, wobei eine zusätzliche Instanz als Mehrheitsersteller fungiert, die auch als Tie-Breaker-Knoten bezeichnet wird, der dafür sorgt, dass das Cluster-Quorum beim Verlust einer Zone erhalten bleibt.

Die endgültige Bereitstellung umfasst die folgenden Ressourcen:

• Eine primäre und sekundäre Ort, an denen jede Instanz ein zonales Gegenstück hat.
• Zwei Standorte, die für die synchrone Replikation konfiguriert sind.
• Eine einzelne Compute-Instanz, die als Mehrheitsersteller agiert.
• Hochverfügbarkeitsclusterressourcen-Manager von Pacemaker mit einem Fencing-Mechanismus
• Nichtflüchtige Speicher für SAP HANA-Daten- und -Log-Volumen, die an jede SAP HANA-Instanz angehängt sind.

In dieser Anleitung verwenden Sie die von Google Cloud zur Verfügung gestellten Terraform-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

• Sie haben eine NFS-Lösung, wie etwa die verwaltete Lösung Filestore, um die SAP HANA-Volumes /hana/shared und /hanabackup von den Hosts in großem Maßstab aus SAP HANA freizugeben. Informationen zum Bereitstellen von Filestore-NFS-Servern finden Sie unter Instanzen erstellen.

  • Beachten Sie, dass die primäre und sekundäre Website Zugriff auf ihre eigenen NFS-Pfade haben müssen, um das Überschreiben von Daten zu vermeiden. Wenn Sie eine einzelne Filestore-Instanz verwenden möchten, müssen Sie die Bereitstellung so konfigurieren, dass verschiedene Unterverzeichnisse als Bereitstellungspfad verwendet werden.

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

   Ersetzen Sie Folgendes:

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

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 Compute Engine-Seite Firewall 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

Wenn Sie ein SAP HANA-HA-System mit mehreren Knoten bereitstellen möchten, das für vollständige Zonenredundanz konfiguriert ist, verwenden Sie die Cloud Deployment Manager-Vorlage für SAP HANA als Basis für die Konfiguration sowie eine zusätzliche Vorlage zum Bereitstellen einer Mehrheitsersteller-Instanz.

Die Bereitstellung umfasst Folgendes:

• Zwei übereinstimmende SAP HANA-Systeme mit jeweils zwei oder mehr Worker-Knoten.
• Eine einzelne Mehrheitserstellerinstanz, auch als Tie-Breaker-Knoten bezeichnet. Durch sie wird sichergestellt, dass das Cluster-Quorum erhalten bleibt im Fall des Verlusts einer Zone.

Sie fügen einer YAML-Datei eine Definition für alle Systeme hinzu, sodass der Deployment Manager alle Ressourcen unter einem Deployment bereitstellt. Nachdem die SAP HANA-Systeme und die Mehrheitserstellerinstanz 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. Nach Abschluss der Bereitstellung ändern Sie die Anzahl der vCPUs und die Größe des Arbeitsspeichers. Der mindestens empfohlene instanceType für die Mehrheitsersteller-Instanz ist n1-standard-2 oder das Äquivalent von mindestens 2 CPU-Kernen und 2 GB Arbeitsspeicher.
   zone	String	Die Google Cloud-Zone, in der die von Ihnen definierte VM-Instanz bereitgestellt werden soll. Geben Sie verschiedene Zonen in der selben Region für die primäre HANA-, sekundäre HANA-, und Mehrheitsersteller-Instanz-Definition 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	Integer	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	Integer	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	Integer	Geben Sie 1 oder höher an.
   sap_hana_shared_nfs	String	NFS-Einhängepunkt für das Volume /hana/shared. Beispiel: 10.151.91.122:/hana_shared_nfs. Hinweis: Der NFS-Einhängepunkt für das Volume /hana/shared muss leer sein und wird nicht von anderen Bereitstellungen verwendet, bevor Sie Deployment Manager ausführen.
   sap_hana_backup_nfs	String	NFS-Einhängepunkt für das Volume /hanabackup. Beispiel: 10.216.41.122:/hana_backup_nfs.
   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. Laden Sie die Konfigurationsdatei der sap_majoritymaker.yaml-Mehrheitserstellerinstanz herunter:

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

10. Kopieren Sie die YAML-Spezifikation aus der Datei sap_majoritymaker.yaml, beginnend ab Zeile #6 und darunter, und fügen Sie sie am Ende der SAP HANA template.yaml Datei ein.

11. Erstellen Sie die Definition für die Mehrheitserstellerinstanz:

    • Geben Sie eine zone an, die sich von den beiden SAP HANA-Systemen unterscheidet.
    • Der empfohlene Mindestwert für instanceType ist n1-standard-2 oder das Äquivalent von mindestens 2 CPU-Kernen und 2 GB Arbeitsspeicher.

    Sie sollten jetzt drei Ressourcen in Ihrer YAML-Datei aufgelistet haben, zwei SAP HANA-Cluster und eine Mehrheitserstellerinstanz zusammen mit ihren konfigurierbaren Attributen.

12. 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 Cluster mit horizontaler Skalierung mit einem installierten SAP HANA-System sowie eine einzelne VM-Instanz, die als Mehrheitsersteller fungiert, 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: 2
    sap_hana_shared_nfs: 10.151.91.123:/hana_shared_nfs
    sap_hana_backup_nfs: 10.216.41.123:/hana_backup_nfs
    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: 2
    sap_hana_shared_nfs: 10.141.91.124:/hana_shared_nfs
    sap_hana_backup_nfs: 10.106.41.124:/hana_backup_nfs
    networkTag: cluster-ntwk-tag
    serviceAccount: [e-mail]
    # sap_hana_sidadm_uid: 900
    # sap_hana_sapsys_gid: 79
    
- name: sap_majoritymaker
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_majoritymaker/sap_majoritymaker.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/202208181245/dm-templates/sap_majoritymaker/sap_majoritymaker.py
  properties:
    instanceName: sap-majoritymaker
    instanceType: n1-standard-2
    zone: us-central1-b
    subnetwork: example-subnet-us-central1
    linuxImage: family/sles-15-sp1-sap
    linuxImageProject: suse-sap-cloud
    publicIP: No
    

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.

Bereitstellungsstatus des Mehrheitserstellers prüfen

Sie können den Bereitstellungsstatus der Mehrheitserstellerinstanz mit dem folgenden Befehl prüfen.

gcloud compute instances describe MAJORITY_MAKER_HOSTNAME --zone MAJORITY_MAKER_ZONE --format="table[box,title='Deployment Status'](name:label=Instance_Name,metadata.items.status:label=Status)"

Wenn der Status Complete angezeigt wird, ist die Verarbeitung der Bereitstellung der Mehrheitserstellerinstanz erfolgreich gewesen. Für eine laufende Bereitstellung wird der Status <blank> angezeigt.

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 Host-VM-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.

Optional: Liste der Instanzen für die Skriptautomatisierung erstellen

Um einige der sich wiederholenden Aufgaben während der Konfiguration des SAP HANA-System- und Pacemaker-Clusters teilweise zu automatisieren, können Sie Bash-Skripts verwenden. In dieser Anleitung werden solche Bash-Skripts verwendet, um die Konfiguration Ihres SAP HANA-System- und Pacemaker-Clusters zu beschleunigen. Diese Skripts erfordern eine Liste aller bereitgestellten VM-Instanzen und derer zugehörigen Zonen als Eingabe.

Erstellen Sie zur Aktivierung dieser Automatisierung eine Datei mit dem Namen nodes.txt und fügen Sie die Details aller bereitgestellten VM-Instanzen im folgenden Format hinzu: Zonenname, Leerzeichen, Name der VM-Instanz. In dieser Anleitung wird folgende Beispieldatei verwendet:

# cat nodes.txt
  us-west1-a hana-ha-vm-1
  us-west1-a hana-ha-vm-1w1
  us-west1-a hana-ha-vm-1w2
  us-west1-b hana-majoritymaker
  us-west1-c hana-ha-vm-2
  us-west1-c hana-ha-vm-2w1
  us-west1-c hana-ha-vm-2w2
 

Passwortlosen SSH-Zugriff einrichten

Um den Pacemaker-Cluster zu konfigurieren und die SAP HANA Secure Store (SSFS)-Schlüssel zu synchronisieren, ist ein passwortloser SSH-Zugriff zwischen allen Knoten erforderlich, einschließlich der Mehrheitsersteller-Instanz. Für den passwortlosen SSH-Zugriff müssen Sie die öffentlichen SSH-Schlüssel den Instanzmetadaten aller bereitgestellten Instanzen hinzufügen.

Das Format der Metadaten ist USERNAME: PUBLIC-KEY-VALUE.

Weitere Informationen zum Hinzufügen von SSH-Schlüsseln zu VMs finden Sie unter SSH-Schlüssel zu VMs hinzufügen, die metadatenbasierte SSH-Schlüssel verwenden.

Manuelle Schritte

1. Erfassen Sie für jede Instanz im primären und im sekundären System sowie für die Mehrheitserstellerinstanz den öffentlichen Schlüssel für den Nutzer root.

   gcloud compute ssh --quiet --zone ZONE_ID INSTANCE_NAME -- sudo cat /root/.ssh/id_rsa.pub

2. Stellen Sie dem Schlüssel den String root: voran und schreiben Sie den Schlüssel als neue Zeile in die Datei public-ssh-keys.txt. Beispiel:

   root:ssh-rsa AAAAB3NzaC1JfuYnOI1vutCs= root@INSTANCE_NAME

3. Nachdem Sie alle öffentlichen SSH-Schlüssel erfasst haben, laden Sie die Schlüssel als Metadaten in alle Instanzen hoch:

   gcloud compute instances add-metadata --metadata-from-file ssh-keys=public-ssh-keys.txt --zone ZONE_ID INSTANCE_NAME

Automatisierte Schritte

Alternativ können Sie die folgenden Schritte über die Google Cloud Console ausführen, um den Prozess der Einrichtung passwortloser SSH-Zugriffe für alle in nodes.txt aufgeführten Instanzen zu automatisieren:

1. Erstellen Sie eine Liste der öffentlichen Schlüssel aus allen bereitgestellten Instanzen:

   while read -u10 ZONE HOST ;  do echo "Collecting public-key from $HOST"; { echo 'root:'; gcloud compute ssh --quiet --zone $ZONE $HOST --tunnel-through-iap -- sudo cat /root/.ssh/id_rsa.pub; } | tr -ds '\n' " " >> public-ssh-keys.txt; done 10< nodes.txt

2. Weisen Sie allen Instanzen die öffentlichen SSH-Schlüssel als Metadateneinträge zu:

   while read -u10 ZONE HOST ;  do echo "Adding public keys to $HOST"; gcloud compute instances add-metadata --metadata-from-file ssh-keys=public-ssh-keys.txt --zone $ZONE $HOST; done 10< nodes.txt 

Autostart von SAP HANA deaktivieren

Manuelle Schritte

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

Automatisierte Schritte

Führen Sie alternativ das folgende Script über die Google Cloud Console aus, um SAP HANA Autostart für alle in nodes.txt aufgeführten Instanzen zu deaktivieren:

while read -u10 ZONE HOST ;
 do gcloud compute ssh --verbosity=none --zone $ZONE $HOST -- "echo Setting Autostart=0 on \$HOSTNAME;
 sudo sed -i 's/Autostart=1/Autostart=0/g' /usr/sap/SID/SYS/profile/SID_HDBINST_NUM_\$HOSTNAME";
 done 10< nodes.txt
 

Hinweis: Ignorieren Sie die Fehlermeldung "Keine solche Datei oder kein solches Verzeichnis vorhanden", die angezeigt wird, wenn das Automatisierungsskript auf die Mehrheitsersteller-Instanz zugreift. Dieser Fehler wird angezeigt, weil in der Mehrheitsersteller-Instanz SAP HANA nicht installiert ist.

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)

SUSE-Pakete herunterladen

Deinstallieren Sie die Ressourcen-Agents, die für Bereitstellungen mit vertikaler Skalierung verwendet werden, und ersetzen Sie sie durch die für die horizontale Skalierung verwendeten Ressourcen-Agents.

Manuelle Schritte

Führen Sie auf allen Hosts die folgenden Schritte aus, einschließlich der Mehrheitserstellerinstanz:

1. Deinstallieren Sie die HANA-Ressourcen-Agents mit vertikaler Skalierung:

   zypper remove SAPHanaSR SAPHanaSR-doc

2. Installieren Sie die HANA-Ressourcen-Agents mit horizontaler Skalierung:

   zypper in SAPHanaSR-ScaleOut SAPHanaSR-ScaleOut-doc

3. Installieren Sie socat:

   zypper install socat

4. Installieren Sie die neuesten Betriebssystem-Patches:

   zypper patch

Automatisierte Schritte

Alternativ können Sie diesen Prozess für alle in nodes.txt aufgeführten Instanzen automatisieren, indem Sie das folgende Script über die Google Cloud Console ausführen:

while read -u10 HOST ;  do gcloud compute ssh --zone $HOST -- "sudo zypper remove -y SAPHanaSR SAPHanaSR-doc; sudo zypper in -y SAPHanaSR-ScaleOut SAPHanaSR-ScaleOut-doc socat; sudo zypper patch -y"; done 10< nodes.txt

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:

      > sapcontrol -nr INST_NUM -function StopSystem

   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:

      > sapcontrol -nr INST_NUM -function StartSystem

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.

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 eine neuere Version.

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:

   > sapcontrol -nr 00 -function StopSystem

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:

   [ha_dr_provider_saphanasrmultitarget]
   provider = SAPHanaSrMultiTarget
   path = /usr/share/SAPHanaSR-ScaleOut/
   execution_order = 1
   
   [ha_dr_provider_sustkover]
   provider = susTkOver
   path = /usr/share/SAPHanaSR-ScaleOut/
   execution_order = 2
   sustkover_timeout = 30
   
   [ha_dr_provider_suschksrv]
   provider = susChkSrv
   path = /usr/share/SAPHanaSR-ScaleOut/
   execution_order = 3
   action_on_lost = stop
   
   [trace]
   ha_dr_saphanasrmultitarget = 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:

   Ersetzen Sie SID_LC durch die SID in Kleinbuchstaben.

   SID_LCadm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_*
   SID_LCadm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_SID_LC_gsh *
   SID_LCadm ALL=(ALL) NOPASSWD: /usr/sbin/SAPHanaSR-hookHelper --sid=SID_LC *

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:

   > sapcontrol -nr 00 -function StartSystem

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 den primären und sekundären Master-Host-VMs das Dienstprogramm socat:

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

Ressourcen-Agent-Skripts herunterladen

Manuelle Schritte

Laden Sie als Root auf allen primären und sekundären Hosts sowie als Mehrheitsersteller die erforderlichen Ressourcen-Agent-Skripts herunter:

# mkdir -p /usr/lib64/stonith/plugins/external
# curl https://storage.googleapis.com/sapdeploy/pacemaker-gcp/gcpstonith -o /usr/lib64/stonith/plugins/external/gcpstonith
# chmod +x /usr/lib64/stonith/plugins/external/gcpstonith

Automatisierte Schritte

Alternativ können Sie über die Google Cloud Console das folgende Script zum Herunterladen der erforderlichen Ressourcen-Agent-Script für alle in nodes.txt aufgeführten Instanzen herunterladen:

while read -u10 HOST ;  do gcloud compute ssh --tunnel-through-iap --quiet --zone $HOST -- "echo 'CLOUDSDK_PYTHON=/usr/bin/python' | sudo tee -a /etc/sysconfig/pacemaker; sudo curl --silent https://storage.googleapis.com/sapdeploy/pacemaker-gcp/gcpstonith -o /usr/lib64/stonith/plugins/external/gcpstonith; sudo chmod +x /usr/lib64/stonith/plugins/external/gcpstonith"; done 10< nodes.txt

Cluster initialisieren

Initialisieren Sie als Root auf dem primären Host den Cluster:

SLES 15

crm cluster init -y

SLES 12

ha-cluster-init -y

Ignorieren Sie die Warnungen in Bezug auf SBD und Standardpasswort. SBD und Standardpasswort werden in dieser Bereitstellung nicht verwendet.

Cluster konfigurieren

Führen Sie die folgenden Schritte auf dem primären Host als Root aus.

Wartungsmodus aktivieren

Versetzen Sie den Pacemaker-Cluster in den Wartungsmodus:

crm configure property maintenance-mode="true"

Allgemeine Clusterattribute konfigurieren

Konfigurieren Sie die folgenden allgemeinen Clusterattribute:

crm configure property stonith-timeout="300s"
crm configure property stonith-action="reboot"
crm configure property stonith-enabled="true"
crm configure property cluster-infrastructure="corosync"
crm configure property cluster-name="hacluster"
crm configure property placement-strategy="balanced"
crm configure property no-quorum-policy="freeze"
crm configure property concurrent-fencing="true"

crm configure rsc_defaults migration-threshold="50"
crm configure rsc_defaults resource-stickiness="1000"

crm configure op_defaults timeout="600"

Standardeinstellungen für "corosync.conf" bearbeiten

1. Öffnen Sie die Datei /etc/corosync/corosync.conf mit einem Editor Ihrer Wahl.

2. Entfernen Sie den Parameter consensus.

3. Ändern Sie die verbleibenden Parameter gemäß den Empfehlungen von Google Cloud.

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

   Parameter	Empfohlener Wert	Auswirkungen der Wertänderung
   secauth	off	Deaktiviert die Authentifizierung und Verschlüsselung aller totem-Nachrichten.
   join	60 (ms)	Erhöht, wie lange der Knoten im Mitgliedsprotokoll auf join-Nachrichten wartet.
   max_messages	20	Erhöht die maximale Anzahl von Nachrichten, die vom Knoten nach Erhalt des Tokens gesendet werden können.
   token	20000 (ms)	Erhöht, wie lange der Knoten auf ein totem-Protokolltoken wartet, bis er einen Tokenverlust deklariert, einen Knotenfehler annimmt und Maßnahmen ergreift. Wenn Sie den Wert des Parameters token erhöhen, wird der Cluster ausfallsicherer gegenüber kurzzeitigen Infrastrukturereignissen wie z. B. Live-Migrationen. Dies kann jedoch auch länger dauern, bis der Cluster einen Knotenfehler erkennt und behebt. Der Wert des Parameters token bestimmt auch den Standardwert des Parameters consensus. Dieser Parameter steuert, wie lange ein Knoten auf die Erzielung von Einigkeit wartet, bis er versucht, die Konfigurationsmitgliedschaft wiederherzustellen.
   consensus	–	Gibt in Millisekunden an, wie lange auf die Erzielung von Einigkeit gewartet werden soll, bevor eine neue Runde der Mitgliedschaftskonfiguration gestartet wird. Wir empfehlen, diesen Parameter wegzulassen. Wenn der Parameter consensus nicht angegeben ist, legt Corosync seinen Wert auf das 1,2-fache des Werts des Parameters token fest. Wenn Sie den empfohlenen Wert von 20000 für den Parameter token verwenden, wird der Parameter consesus auf den Wert 24000 gesetzt. Wenn Sie jedoch explizit einen Wert für consensus angeben, muss dieser Wert 24000 oder 1.2*token sein, je nachdem, welcher Wert höher ist.
   token_retransmits_before_loss_const	10	Erhöht die Anzahl der Token-Übertragungsversuche, die der Knoten unternimmt, bis er davon ausgeht, dass der Empfängerknoten fehlgeschlagen ist, und Maßnahmen ergreift.
   transport	Für SLES: udpu Für RHEL 8 oder höher: knet Für RHEL 7: udpu	Gibt den von Corosync verwendeten Transportmechanismus an.

Alle Hosts mit dem Pacemaker-Cluster verknüpfen

Fügen Sie alle anderen Hosts, einschließlich des Mehrheitserstellers, dem Pacemaker-Cluster auf dem primären Host hinzu:

Manuelle Schritte

SLES 15

crm cluster join -y -c PRIMARY_HOST_NAME

SLES 12

ha-cluster-join -y -c PRIMARY_HOST_NAME

Automatisierte Schritte

Alternativ können Sie diesen Prozess für alle in nodes.txt aufgeführten Instanzen automatisieren, indem Sie das folgende Script über die Google Cloud Console ausführen:

while read -u10 HOST ;  do echo "Joining $HOST to Pacemaker cluster";
gcloud compute ssh --tunnel-through-iap --quiet --zone $HOST -- sudo ha-cluster-join -y -c PRIMARY_HOST_NAME;
done 10< nodes.txt

Ignorieren Sie die Fehlermeldung ERROR: cluster.join: Abort: Cluster is currently active, die ausgelöst wird, wenn Sie den primären Knoten selbst verknüpfen.

Prüfen Sie als Root von einem beliebigen Host, ob für den Cluster alle Knoten angezeigt werden:

# crm_mon -s

Die Ausgabe sollte in etwa so aussehen:

CLUSTER OK: 5 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

Manuelle Schritte

Erstellen Sie als Root auf dem primären Host die Fencing-Ressourcen für alle Knoten im primären und sekundären Cluster:

1. Führen Sie den folgenden Befehl aus, nachdem Sie PRIMARY_HOST_NAME durch den Hostnamen eines Knotens im primären Cluster ersetzt haben:

   # crm configure primitive STONITH-"PRIMARY_HOST_NAME" stonith:external/gcpstonith \
       op monitor interval="300s" timeout="120s" \
       op start interval="0" timeout="60s" \
       params instance_name="PRIMARY_HOST_NAME" gcloud_path="/usr/bin/gcloud" logging="yes" \
       pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30

2. Wiederholen Sie den vorherigen Schritt für alle anderen Knoten im primären Cluster.

3. Führen Sie den folgenden Befehl aus, nachdem Sie SECONDARY_HOST_NAME durch den Hostnamen eines Knotens im sekundären Cluster ersetzt haben.

   # crm configure primitive STONITH-"SECONDARY_HOST_NAME" stonith:external/gcpstonith \
       op monitor interval="300s" timeout="120s" \
       op start interval="0" timeout="60s" \
       params instance_name="SECONDARY_HOST_NAME" gcloud_path="/usr/bin/gcloud" logging="yes" \
       pcmk_reboot_timeout=300 pcmk_monitor_retries=4

4. Wiederholen Sie den vorherigen Schritt für alle anderen Knoten im sekundären Cluster.

5. Führen Sie den folgenden Befehl aus, nachdem Sie MAJORITY_MAKER_HOSTNAME durch den Hostnamen der Mehrheitserstellerinstanz ersetzt haben:

   # crm configure primitive STONITH-"MAJORITY_MAKER_HOSTNAME" stonith:external/gcpstonith \
       op monitor interval="300s" timeout="120s" \
       op start interval="0" timeout="60s" \
       params instance_name="MAJORITY_MAKER_HOSTNAME" gcloud_path="/usr/bin/gcloud" logging="yes" \
       pcmk_reboot_timeout=300 pcmk_monitor_retries=4

6. Legen Sie den Standort des Fencing-Geräts fest:

   # crm configure location LOC_STONITH_"PRIMARY_HOST_NAME" \
       STONITH-"PRIMARY_HOST_NAME" -inf: "PRIMARY_HOST_NAME"

7. Wiederholen Sie den vorherigen Schritt für alle anderen Hosts auf dem primären und sekundären Cluster, einschließlich des Mehrheitsersteller-Hosts.

Automatisierte Schritte

Alternativ können Sie das Fencing für alle in nodes.txt aufgeführten Instanzen einrichten. Führen Sie dazu das folgende Script über die Google Cloud Console aus:

while read -u10 HOST;  do gcloud compute ssh --tunnel-through-iap --quiet --zone $HOST   -- "sudo crm configure primitive STONITH-\$HOSTNAME stonith:external/gcpstonith op monitor interval=\"300s\" timeout=\"60s\" on-fail=\"restart\" op start interval=\"0\" timeout=\"60s\" onfail=\"restart\" params instance_name=\$HOSTNAME gcloud_path=\"/usr/bin/gcloud\" logging=\"yes\" pcmk_reboot_timeout=300 pcmk_monitor_retries=4; sudo crm configure location LOC_STONITH_\$HOSTNAME STONITH-\$HOSTNAME -inf: \$HOSTNAME"; done 10< nodes.txt

Verzögerung für den Neustart von Corosync festlegen

Manuelle Schritte

1. Erstellen Sie auf allen 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

Automatisierte Schritte

Alternativ können Sie diesen Prozess für alle in nodes.txt aufgeführten Instanzen automatisieren, indem Sie das folgende Script über die Google Cloud Console ausführen:

while read -u10 HOST;  do gcloud compute ssh --tunnel-through-iap --quiet --zone $HOST   --  "sudo mkdir -p /etc/systemd/system/corosync.service.d/; sudo echo -e '[Service]\nExecStartPre=/bin/sleep 60' | sudo tee -a /etc/systemd/system/corosync.service.d/override.conf; sudo systemctl daemon-reload"; done 10< nodes.txt

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

3. 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:

   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"
   location SAPHanaTop_not_on_majority_maker cln_SAPHanaTopology_SID_HDBINST_NUM -inf: MAJORITY_MAKER_HOSTNAME

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-Ressource erstellen

Zum Definieren der einfachen SAPHana-Ressource verwenden Sie dieselbe Methode, die Sie für die SAPHanaTopology-Ressource verwendet haben: 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 SAPHana-Ressourcendefinitionen und fügen Sie sie in die Datei /tmp/cluster.tmp ein:

   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="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 master-node-max="1" master-max="1" 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
   location SAPHanaCon_not_on_majority_maker  msl_SAPHana_SID_HDBINST_NUM -inf: MAJORITY_MAKER_HOSTNAME

   Für einen mehrstufigen SAP HANA-HA-Cluster legen Sie AUTOMATED_REGISTER auf false fest, wenn Sie eine ältere Version als SAP HANA 2.0 SP03 verwenden. 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

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

Prüfen Sie als SID_LCadm auf dem primären Host den Replikationsstatus:

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

7 nodes configured
21 resources configured
Online: [   hana-ha-vm-1 hana-ha-vm-1w1 hana-ha-vm-1w2 hana-ha-vm-2 hana-ha-vm-2w1 hana-ha-vm-2w2 sap-majoritymaker ]


Full list of resources:


 STONITH-hana-ha-vm-1   (stonith:external/gcpstonith):  Started hana-ha-vm-1w2
 STONITH-hana-ha-vm-1w1 (stonith:external/gcpstonith):  Started hana-ha-vm-1
 STONITH-hana-ha-vm-1w2 (stonith:external/gcpstonith):  Started hana-ha-vm-2
 STONITH-sap-majoritymaker      (stonith:external/gcpstonith):  Started hana-ha-vm-1w2
 STONITH-hana-ha-vm-2   (stonith:external/gcpstonith):  Started hana-ha-vm-2w1
 STONITH-hana-ha-vm-2w1 (stonith:external/gcpstonith):  Started hana-ha-vm-2w2
 STONITH-hana-ha-vm-2w2 (stonith:external/gcpstonith):  Started sap-majoritymaker
 Clone Set: cln_SAPHanaTopology_HA1_HDB22 [rsc_SAPHanaTopology_HA1_HDB22]
     Started: [ hana-ha-vm-1 hana-ha-vm-1w1 hana-ha-vm-1w2 hana-ha-vm-2 hana-ha-vm-2w1 hana-ha-vm-2w2 ]
     Stopped: [ sap-majoritymaker ]
 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-1w1 hana-ha-vm-1w2 hana-ha-vm-2 hana-ha-vm-2w1 hana-ha-vm-2w2 ]
     Stopped: [ sap-majoritymaker ]

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.

   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 hana-ha-vm-1w1 hana-ha-vm-2w1]
   
   Full list of resources:
   
   STONITH-hana-ha-vm-1   (stonith:external/gcpstonith):  Started hana-ha-vm-2
   STONITH-hana-ha-vm-2   (stonith:external/gcpstonith):  Started hana-ha-vm-1
   STONITH-hana-ha-vm-1w1   (stonith:external/gcpstonith):    Started hana-ha-vm-2w1
   STONITH-hana-ha-vm-1w1   (stonith:external/gcpstonith):    Started hana-ha-vm-mm
   STONITH-hana-ha-vm-mm   (stonith:external/gcpstonith):    Started hana-ha-vm-1w1
   Clone Set: cln_SAPHanaTopology_HA1_HDB22 [rsc_SAPHanaTopology_HA1_HDB22]
       Started: [ hana-ha-vm-1 hana-ha-vm-2 hana-ha-vm-1w1 hana-ha-vm-2w1
       Stopped: [ hana-ha-vm-mm ]]
   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 hana-ha-vm-1w1 hana-ha-vm-2w1
       Stopped: [ hana-ha-vm-mm ]]

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.