Konfigurationsanleitung für horizontal skalierbares Hochverfügbarkeitscluster für SAP HANA unter RHEL

In dieser Anleitung erfahren Sie, wie Sie einen Hochverfügbarkeitscluster unter Red Hat Enterprise Linux (RHEL) für SAP HANA mit einem horizontal skalierbaren System in Google Cloud bereitstellen und konfigurieren, der einen internen Passthrough-Netzwerk-Load-Balancer verwendet, um die virtuelle IP-Adresse (VIP) zu verwalten.

Die Anleitung umfasst folgende Schritte:

• Internen Passthrough-Network-Load-Balancer konfigurieren, um Traffic bei einem Ausfall umzuleiten
• Pacemaker-Cluster unter RHEL 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 besteht aus den folgenden Ressourcen:

• Eine primäre und sekundäre Ort, an denen jede Instanz ein zonales Gegenstück hat.
• Zwei Standorte für die synchrone Replikation konfiguriert.
• Eine einzelne Compute-Instanz, die als Mehrheitsersteller agiert.
• Pacemaker-Hochverfügbarkeitscluster-Ressourcenmanager mit 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 Terraform-Konfigurationsdatei verwenden, geben Sie ein Tag mit network_tags = "TAG" an.
  • Erstellen Sie die VMs ohne externe IP-Adresse. Wenn Sie die von Google Cloud bereitgestellte Terraform-Konfigurationsdatei verwenden, geben Sie public_ip = false 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.

Führen Sie die folgenden Schritte aus, um ein VPC-Netzwerk für Ihr Projekt zu erstellen:

1. Erstellen Sie ein Netzwerk im benutzerdefinierten Modus. Weitere Informationen finden Sie unter Netzwerk im benutzerdefinierten Modus erstellen.

2. Erstellen Sie ein Subnetzwerk und geben Sie die Region und den IP-Adressbereich an. Weitere Informationen finden Sie unter Subnetze hinzufügen.

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.

Informationen zum Erstellen der Firewallregeln für Ihr Projekt finden Sie unter Firewallregeln erstellen.

VMs und SAP HANA bereitstellen

In dieser Anleitung verwenden Sie eine von Google Cloud bereitgestellte Terraform-Konfigurationsdatei, um Folgendes bereitzustellen:

• Zwei übereinstimmende SAP HANA-Systeme mit jeweils zwei oder mehr VM-Instanzen
• 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.

Die SAP HANA-Systeme verwenden die asynchrone Systemreplikation, sodass eines der SAP HANA-Systeme als primäres, aktives System und das andere als sekundäres Standby-System fungiert. Sie stellen beide SAP HANA-Systeme in derselben Region bereit, idealerweise in verschiedenen Zonen.

Wenn Sie für das automatische Host-Failover von SAP HANA ein horizontal skalierbares System mit Standby-Hosts benötigen, lesen Sie stattdessen Terraform: Bereitstellungsanleitung für SAP HANA-Systeme zur horizontalen Skalierung mit automatischem Host-Failover.

Die Konfigurationsoptionen für den SAP HANA-Hochverfügbarkeitscluster definieren Sie in einer Terraform-Konfigurationsdatei.

In der folgenden Anleitung wird Cloud Shell verwendet. Sie ist aber allgemein auf ein lokales Terminal anwendbar, auf dem Terraform mit dem Google-Anbieter installiert und konfiguriert ist.

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.

   Kontingente aufrufen

2. Öffnen Sie Cloud Shell oder Ihr lokales Terminal.

   Cloud Shell öffnen

3. Laden Sie die Konfigurationsdatei manual_sap_hana_scaleout_ha.tf in Ihr Arbeitsverzeichnis herunter. Führen Sie dazu den folgenden Befehl in Cloud Shell oder in Ihrem Terminal aus:

   $ wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_hana_ha/terraform/manual_sap_hana_scaleout_ha.tf

   Hinweis: Achten Sie darauf, dass Ihr Arbeitsverzeichnis nur eine einzige Terraform-Konfigurationsdatei hat.

4. Öffnen Sie die Datei manual_sap_hana_scaleout_ha.tf im Cloud Shell-Code-Editor bzw. bei Verwendung Ihres Terminals in einem Texteditor Ihrer Wahl.

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

5. Aktualisieren Sie in der Datei manual_sap_hana_scaleout_ha.tf sowohl für sap_hana_primary als auch für sap_hana_secondary die Argumentwerte. Ersetzen Sie dazu den Inhalt innerhalb der doppelten Anführungszeichen durch die Werte für Ihre Installation. Die Argumente werden in der folgenden Tabelle beschrieben.

   Argument	Datentyp	Beschreibung
   source	String	Gibt den Speicherort und die Version des Terraform-Moduls an, das während der Bereitstellung verwendet werden soll. Die Konfigurationsdatei manual_sap_hana_scaleout_ha.tf enthält zwei Instanzen des Arguments source: eine aktive und eine als Kommentar. Das standardmäßig aktive Argument source gibt latest als Modulversion an. Die zweite Instanz des Arguments source, die standardmäßig durch ein führendes #-Zeichen deaktiviert ist, gibt einen Zeitstempel an, der eine Modulversion identifiziert. Wenn alle Ihre Bereitstellungen dieselbe Modulversion verwenden müssen, entfernen Sie das führende #-Zeichen aus dem Argument source, das den Zeitstempel der Version angibt, und fügen Sie es dem Argument source hinzu, das latest angibt.
   project_id	String	Geben Sie die ID Ihres Google Cloud-Projekts an, in dem Sie dieses System bereitstellen. Beispiel: my-project-x.
   machine_type	String	Geben Sie den Typ der virtuellen Maschine (VM) von Compute Engine an, auf der Sie Ihr SAP-System ausführen müssen. Wenn Sie einen benutzerdefinierten VM-Typ benötigen, geben Sie einen vordefinierten VM-Typ mit einer Anzahl an vCPUs an, die der benötigten Anzahl am nächsten kommt, aber noch darüber liegt. Wenn die Bereitstellung abgeschlossen ist, ändern Sie die Anzahl der vCPUs und den Umfang des Arbeitsspeichers. Beispiel: n1-highmem-32.
   network	String	Geben Sie den Namen des Netzwerks an, in dem Sie den Load-Balancer, der die VIP verwaltet, erstellen möchten. Wenn Sie ein freigegebenes VPC-Netzwerk verwenden, müssen Sie die ID des Hostprojekts als übergeordnetes Verzeichnis des Netzwerknamens hinzufügen. Beispiel: HOST_PROJECT_ID/NETWORK_NAME.
   subnetwork	String	Geben Sie den Namen des Subnetzwerks an, das Sie in einem vorherigen Schritt erstellt haben. Wenn die Bereitstellung in einer freigegebenen VPC erfolgt, geben Sie diesen Wert als SHARED_VPC_PROJECT_ID/SUBNETWORK an. Beispiel: myproject/network1.
   linux_image	String	Geben Sie den Namen des Linux-Betriebssystem-Images an, auf dem Sie Ihr SAP-System bereitstellen möchten. Beispiel: rhel-9-2-sap-ha oder sles-15-sp5-sap. Eine Liste der verfügbaren Betriebssystem-Images finden Sie auf der Seite Images in der Google Cloud Console.
   linux_image_project	String	Geben Sie das Google Cloud-Projekt an, in dem das Image enthalten ist, das Sie für das Argument linux_image angegeben haben. Dieses Projekt kann Ihr eigenes Projekt oder ein Google Cloud-Image-Projekt sein. Geben Sie für ein Compute Engine-Image entweder rhel-sap-cloud oder suse-sap-cloud an. Weitere Informationen zum Image-Projekt für Ihr Betriebssystem finden Sie unter Details zu Betriebssystemen.
   primary_instance_name	String	Geben Sie einen Namen für die VM-Instanz des primären SAP HANA-Systems an. Der Name darf Kleinbuchstaben, Zahlen oder Bindestriche enthalten.
   primary_zone	String	Geben Sie eine Zone an, in der das primäre SAP HANA-System bereitgestellt wird. Die primäre und die sekundäre Zone müssen sich in derselben Region befinden. z. B. us-east1-c
   secondary_instance_name	String	Geben Sie einen Namen der VM-Instanz für das sekundäre SAP HANA-System an. Der Name darf Kleinbuchstaben, Zahlen oder Bindestriche enthalten.
   secondary_zone	String	Geben Sie eine Zone an, in der das sekundäre SAP HANA-System bereitgestellt wird. Die primäre und die sekundäre Zone müssen sich in derselben Region befinden. z. B. us-east1-b
   sap_hana_deployment_bucket	String	Wenn Sie SAP HANA automatisch auf den bereitgestellten VMs installieren möchten, geben Sie den Pfad des Cloud Storage-Buckets an, der die SAP HANA-Installationsdateien enthält. Fügen Sie gs:// nicht in den Pfad ein. Geben Sie nur den Bucket-Namen und die Namen der Ordner an. Beispiel: my-bucket-name/my-folder. Der Cloud Storage-Bucket muss in dem Google Cloud-Projekt vorhanden sein, das Sie für das Argument project_id angeben.
   sap_hana_scaleout_nodes	Integer	Geben Sie die Anzahl der Worker-Hosts an, die Sie in Ihrem System mit horizontaler Skalierung benötigen. Für die Bereitstellung eines Systems mit horizontaler Skalierung benötigen Sie mindestens einen Worker-Host. Terraform erstellt die Worker-Hosts zusätzlich zur primären SAP HANA-Instanz. Wenn Sie beispielsweise 3 angeben, werden vier SAP HANA-Instanzen in Ihrem System mit horizontaler Skalierung bereitgestellt.
   sap_hana_sid	String	Geben Sie die SAP HANA-System-ID an, damit SAP HANA automatisch auf den bereitgestellten VMs installiert wird. Die ID muss aus drei alphanumerischen Zeichen bestehen und mit einem Buchstaben beginnen. Alle Buchstaben müssen Großbuchstaben sein. Beispiel: ED1.
   sap_hana_instance_number	Integer	Optional. Geben Sie die Instanznummer (0 bis 99) des SAP HANA-Systems an. Der Standardwert ist 0.
   sap_hana_sidadm_password	String	Wenn Sie SAP HANA automatisch auf den bereitgestellten VMs installieren möchten, geben Sie ein temporäres SIDadm-Passwort an, das während der Bereitstellung für die Installationsskripts verwendet werden soll. Das Passwort muss mindestens 8 Zeichen lang sein und mindestens einen Großbuchstaben, einen Kleinbuchstaben und eine Zahl enthalten. Wichtig: Ändern Sie nach Abschluss der Installation das Passwort. Anstatt das Passwort als Nur-Text anzugeben, empfehlen wir die Verwendung eines Secrets. Weitere Informationen finden Sie unter Passwortverwaltung.
   sap_hana_sidadm_password_secret	String	Optional. Wenn Sie Secret Manager zum Speichern des Passworts SIDadm verwenden, geben Sie den Namen des Secrets an, das zu diesem Passwort gehört. Achten Sie im Secret Manager darauf, dass der Secret-Wert, also das Passwort, mindestens 8 Zeichen enthält und mindestens einen Großbuchstaben, einen Kleinbuchstaben und eine Zahl umfasst. Wichtig: Das Secret muss in dem Google Cloud-Projekt vorhanden sein, das Sie für das Argument project_id angeben. Weitere Informationen finden Sie unter Passwortverwaltung.
   sap_hana_system_password	String	Wenn Sie SAP HANA automatisch auf den bereitgestellten VMs installieren möchten, geben Sie ein temporäres Passwort für den Datenbank-Superuser an, das während der Bereitstellung für die Installationsskripts verwendet werden soll. Das Passwort muss mindestens 8 Zeichen lang sein und mindestens einen Großbuchstaben, einen Kleinbuchstaben und eine Zahl enthalten. Wichtig: Ändern Sie nach Abschluss der Installation das Passwort. Anstatt das Passwort als Nur-Text anzugeben, empfehlen wir die Verwendung eines Secrets. Weitere Informationen finden Sie unter Passwortverwaltung.
   sap_hana_system_password_secret	String	Optional. Wenn Sie das Passwort des Datenbank-Superusers mit Secret Manager speichern, geben Sie den Namen des Secrets an, das diesem Passwort entspricht. Achten Sie im Secret Manager darauf, dass der Secret-Wert, also das Passwort, mindestens 8 Zeichen enthält und mindestens einen Großbuchstaben, einen Kleinbuchstaben und eine Zahl umfasst. Wichtig: Das Secret muss in dem Google Cloud-Projekt vorhanden sein, das Sie für das Argument project_id angeben. Weitere Informationen finden Sie unter Passwortverwaltung.
   sap_hana_double_volume_size	Boolesch	Optional. Geben Sie true an, um die HANA-Volume-Größe zu verdoppeln. Dieses Argument ist nützlich, wenn Sie mehrere SAP HANA-Instanzen oder eine SAP HANA-Instanz zur Notfallwiederherstellung auf derselben VM bereitstellen möchten. Standardmäßig wird die Volume-Größe automatisch so berechnet, dass sie der erforderlichen Mindestgröße für die VM entspricht und gleichzeitig die SAP-Zertifizierungs- und Supportanforderungen erfüllt werden. Der Standardwert ist false.
   sap_hana_backup_size	Integer	Optional. Geben Sie die Größe des Volumes /hanabackup in GB an. Wenn Sie dieses Argument nicht angeben oder auf 0 setzen, stellt das Installationsskript die Compute Engine-Instanz mit einem HANA-Sicherungsvolumen bereit, das doppelt so groß wie der Gesamtspeichers ist.
   sap_hana_sidadm_uid	Integer	Optional. Geben Sie einen Wert an, um den Standardwert der SID_LCadm-Nutzer-ID zu überschreiben. Der Standardwert ist 900. Sie können diesen Wert zwecks Vereinheitlichung innerhalb Ihrer SAP-Landschaft ändern.
   sap_hana_sapsys_gid	Integer	Optional. Überschreibt die Standardgruppen-ID für sapsys. Der Standardwert ist 79.
   sap_vip	String	Geben Sie die IP-Adresse an, die Sie für Ihre VIP verwenden möchten. Die IP-Adresse muss im Bereich der Ihrem Subnetz zugewiesenen IP-Adressen liegen. Diese IP-Adresse wird von der Terraform-Konfigurationsdatei reserviert.
   primary_instance_group_name	String	Optional. Gibt den Namen der nicht verwalteten Instanzgruppe für den primären Knoten an. Der Standardname ist ig-PRIMARY_INSTANCE_NAME.
   secondary_instance_group_name	String	Optional. Gibt den Namen der nicht verwalteten Instanzgruppe für den sekundären Knoten an. Der Standardname ist ig-SECONDARY_INSTANCE_NAME.
   loadbalancer_name	String	Optional. Geben Sie den Namen des internen Passthrough-Netzwerk-Load-Balancers an. Der Standardname ist lb-SAP_HANA_SID-ilb.
   network_tags	String	Optional. Geben Sie ein oder mehrere kommagetrennte Netzwerk-Tags an, die Sie zu Firewall- oder Routingzwecken mit Ihren VM-Instanzen verknüpfen möchten. Wenn Sie public_ip = false, aber kein Netzwerk-Tag angeben, müssen Sie eine andere Möglichkeit für den Zugriff auf das Internet bereitstellen.
   nic_type	String	Optional. 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 Argument linux_image unterstützt. Eine Liste der Betriebssystem-Images finden Sie unter Details zu Betriebssystemen. Wenn Sie für dieses Argument keinen Wert angeben, wird die Netzwerkschnittstelle automatisch basierend auf dem Maschinentyp ausgewählt, den Sie für das Argument machine_type angeben. Dieses Argument ist in der sap_hana-Modulversion 202302060649 oder höher verfügbar.
   disk_type	String	Optional. Geben Sie den Standardtyp des nichtflüchtigen Laufwerks oder Hyperdisk an, den Sie für alle SAP-Volumes in Ihrem Einsatz einsetzen möchten. Der Standardwert ist pd-ssd. Folgende Werte sind für dieses Argument gültig: pd-ssd, pd-balanced, hyperdisk-extreme, hyperdisk-balanced, und pd-extreme. Wenn Sie den Wert hyperdisk-extreme oder hyperdisk-balanced angeben, wird das Verzeichnis /usr/sap auf einem separaten abgestimmten nichtflüchtigen Speicher (pd-balanced) bereitgestellt. Das liegt daran, dass das Verzeichnis /usr/sap keine höhere Leistung erfordert als das Verzeichnis /hana/data oder /hana/log. Bei SAP HANA-Bereitstellungen mit vertikaler Skalierung wird auch ein separater abgestimmter nichtflüchtiger Speicher für das Verzeichnis /hana/shared bereitgestellt. Sie können diesen Standardlaufwerkstyp und die zugehörige Standardlaufwerksgröße und die Standard-IOPS mit einigen erweiterten Argumenten überschreiben. Weitere Informationen finden Sie in Ihrem Arbeitsverzeichnis. Führen Sie dann den Befehl terraform init aus und sehen Sie sich die Datei /.terraform/modules/manual_sap_hana_scaleout_ha/variables.tf an. Bevor Sie diese Argumente in der Produktion verwenden, sollten Sie sie in einer Testumgebung testen.
   use_single_shared_data_log_disk	Boolesch	Optional. Der Standardwert ist false, womit Terraform angewiesen wird, für jedes der folgenden SAP-Volumes einen separaten nichtflüchtigen Speicher oder Hyperdisk bereitzustellen: /hana/data, /hana/log, /hana/shared und /usr/sap. Geben Sie true an, um diese SAP-Volumes auf demselben nichtflüchtigen Speicher oder Hyperdisk bereitzustellen.
   include_backup_disk	Boolesch	Optional. Dieses Argument gilt für SAP HANA-Bereitstellungen mit vertikaler Skalierung. Der Standardwert ist true, der Terraform anweist, einen nichtflüchtigen HDD-Standardspeicher zum Hosten des Verzeichnisses /hanabackup bereitzustellen. Die Größe des Laufwerks wird durch das Argument sap_hana_backup_size bestimmt. Wenn Sie den Wert für include_backup_disk als false festlegen, wird für das Verzeichnis /hanabackup kein Laufwerk bereitgestellt.
   public_ip	Boolesch	Optional. Legt fest, ob Ihre VM-Instanz eine öffentliche IP-Adresse erhält. Der Standardwert ist true. Achtung: Geben Sie false nur dann an, wenn Sie ein NAT-Gateway mit einem für die VM definierten Netzwerk-Tag konfiguriert haben oder Sie der VM eine andere Route zum Internet bereitgestellt haben. Wenn keine Route zum Internet angegeben ist, schlägt die Installation fehl.
   service_account	String	Optional. Geben Sie die E-Mail-Adresse eines nutzerverwalteten Dienstkontos an, das von den Host-VMs und den darauf ausgeführten Programmen verwendet werden soll. Beispiel: [e-mail]. Wenn Sie dieses Argument ohne Wert angeben oder weglassen, verwendet das Installationsskript das Compute Engine-Standarddienstkonto. Weitere Informationen finden Sie unter Identitäts- und Zugriffsverwaltung für SAP-Programme in Google Cloud.
   sap_deployment_debug	Boolesch	Optional. Geben Sie true nur dann an, wenn Sie von Cloud Customer Care aufgefordert werden, das Debugging für Ihre Bereitstellung zu aktivieren, da hierdurch ausführliche Bereitstellungslogs generiert werden. Der Standardwert ist false.
   primary_reservation_name	String	Optional. Wenn Sie eine bestimmte Compute Engine-VM-Reservierung zur Bereitstellung der VM-Instanz verwenden möchten, auf der die primäre SAP HANA-Instanz Ihres HA-Clusters gehostet wird, geben Sie den Namen der Reservierung an. Standardmäßig wählt das Installationsskript basierend auf den folgenden Bedingungen jede verfügbare Compute Engine-Reservierung aus. Damit eine Reservierung unabhängig davon verwendet werden kann, ob Sie einen Namen angeben oder dieser vom Installationsskript automatisch ausgewählt wird, muss die Reservierung so festgelegt werden: Die Option specificReservationRequired ist auf true oder in der Google Cloud Console auf Bestimmte Reservierung auswählen festgelegt. Einige Compute Engine-Maschinentypen unterstützen CPU-Plattformen, die nicht von der SAP-Zertifizierung des Maschinentyps abgedeckt sind. Wenn die Zielreservierung für einen der folgenden Maschinentypen gilt, muss die Reservierung die Mindest-CPU-Plattformen angeben: n1-highmem-32: Intel Broadwell n1-highmem-64: Intel Broadwell n1-highmem-96: Intel Skylake m1-megamem-96: Intel Skylake Die Mindest-CPU-Plattformen für alle anderen Maschinentypen, die von SAP für die Verwendung in Google Cloud zertifiziert sind, entsprechen der Mindest-CPU-Anforderung von SAP.
   secondary_reservation_name	String	Optional. Wenn Sie eine bestimmte Compute Engine-VM-Reservierung zur Bereitstellung der VM-Instanz verwenden möchten, auf der die sekundäre SAP HANA-Instanz Ihres HA-Clusters gehostet wird, geben Sie den Namen der Reservierung an. Standardmäßig wählt das Installationsskript basierend auf den folgenden Bedingungen jede verfügbare Compute Engine-Reservierung aus. Damit eine Reservierung unabhängig davon verwendet werden kann, ob Sie einen Namen angeben oder dieser vom Installationsskript automatisch ausgewählt wird, muss die Reservierung so festgelegt werden: Die Option specificReservationRequired ist auf true oder in der Google Cloud Console auf Bestimmte Reservierung auswählen festgelegt. Einige Compute Engine-Maschinentypen unterstützen CPU-Plattformen, die nicht von der SAP-Zertifizierung des Maschinentyps abgedeckt sind. Wenn die Zielreservierung für einen der folgenden Maschinentypen gilt, muss die Reservierung die Mindest-CPU-Plattformen angeben: n1-highmem-32: Intel Broadwell n1-highmem-64: Intel Broadwell n1-highmem-96: Intel Skylake m1-megamem-96: Intel Skylake Die Mindest-CPU-Plattformen für alle anderen Maschinentypen, die von SAP für die Verwendung in Google Cloud zertifiziert sind, entsprechen der Mindest-CPU-Anforderung von SAP.
   primary_static_ip	String	Optional. Geben Sie eine gültige statische IP-Adresse für die primäre VM-Instanz in Ihrem Hochverfügbarkeitscluster an. Wenn Sie keine angeben, wird automatisch eine IP-Adresse für die VM-Instanz generiert. Beispiel: 128.10.10.10. Dieses Argument ist in der sap_hana_ha-Modulversion 202306120959 oder höher verfügbar.
   secondary_static_ip	String	Optional. Geben Sie eine gültige statische IP-Adresse für die sekundäre VM-Instanz in Ihrem Hochverfügbarkeitscluster an. Wenn Sie keine angeben, wird automatisch eine IP-Adresse für die VM-Instanz generiert. Beispiel: 128.11.11.11. Dieses Argument ist in der sap_hana_ha-Modulversion 202306120959 oder höher verfügbar.
   primary_worker_static_ips	List(String)	Optional. Geben Sie ein Array gültiger statischer IP-Adressen für die Worker-Instanzen in der primären Instanz Ihres SAP HANA-HA-Systems mit horizontaler Skalierung an. Wenn Sie für dieses Argument keinen Wert angeben, wird für jede Worker-VM-Instanz automatisch eine IP-Adresse generiert. Beispiel: [ "1.0.0.1", "2.3.3.4" ]. Die statischen IP-Adressen werden in der Reihenfolge der Instanzerstellung zugewiesen. Wenn Sie sich beispielsweise für die Bereitstellung von 3 Worker-Instanzen entscheiden, aber nur 2 IP-Adressen für das Argument primary_worker_static_ips angeben, dann werden diese IP-Adressen den ersten beiden VM-Instanzen zugewiesen, die die Terraform-Konfiguration bereitstellt. Für die dritte Worker-VM-Instanz wird die IP-Adresse automatisch generiert. Dieses Argument ist in der sap_hana_ha-Modulversion 202307270727 oder höher verfügbar.
   secondary_worker_static_ips	List(String)	Optional. Geben Sie ein Array gültiger statischer IP-Adressen für die Worker-Instanzen in der sekundären Instanz Ihres SAP HANA-HA-Systems mit horizontaler Skalierung an. Wenn Sie für dieses Argument keinen Wert angeben, wird für jede Worker-VM-Instanz automatisch eine IP-Adresse generiert. Beispiel: [ "1.0.0.2", "2.3.3.5" ]. Die statischen IP-Adressen werden in der Reihenfolge der Instanzerstellung zugewiesen. Wenn Sie sich beispielsweise für die Bereitstellung von 3 Worker-Instanzen entscheiden, aber nur 2 IP-Adressen für das Argument secondary_worker_static_ips angeben, dann werden diese IP-Adressen den ersten beiden VM-Instanzen zugewiesen, die die Terraform-Konfiguration bereitstellt. Für die dritte Worker-VM-Instanz wird die IP-Adresse automatisch generiert. Dieses Argument ist in der sap_hana_ha-Modulversion 202307270727 oder höher verfügbar.

   Die folgenden Beispiele zeigen abgeschlossene Konfigurationsdateien, die einen Hochverfügbarkeitscluster für ein SAP HANA-System mit horizontaler Skalierung definieren. Der Cluster verwendet einen internen Passthrough-Netzwerk-Load-Balancer, um die VIP zu verwalten.

   Terraform stellt die Google Cloud-Ressourcen bereit, die in der Konfigurationsdatei definiert sind. Anschließend übernehmen Skripts die Konfiguration des Betriebssystems und die Installation von SAP HANA.

   Hinweis: Die Bereitstellungsskripts installieren SAP HANA nur, wenn die entsprechenden Argumente in der Terraform-Konfigurationsdatei angegeben sind. Wenn Sie SAP HANA automatisch auf den bereitgestellten VMs installieren möchten, müssen Sie die folgenden Argumente angeben:

   • sap_hana_deployment_bucket
   • sap_hana_sid
   • sap_hana_sidadm_password oder sap_hana_sidadm_password_secret
   • sap_hana_system_password oder sap_hana_system_password_secret

6. Aktualisieren Sie in derselben Datei manual_sap_hana_scaleout_ha.tf die Argumentwerte für majority_maker. Die Argumente werden in der folgenden Tabelle beschrieben.

   Argument	Datentyp	Beschreibung
   project	String	Geben Sie die ID Ihres Google Cloud-Projekts an, in dem Sie dieses System bereitstellen.
   majority_maker_instance_name	String	Geben Sie einen Namen für die Compute Engine-VM-Instanz an, die als Mehrheitsersteller dient. Dieses Argument ist in der sap_hana_ha-Modulversion 202307270727 oder höher verfügbar.
   majority_maker_instance_type	String	Geben Sie den Typ der virtuellen Maschine (VM) von Compute Engine an, die Sie für die Mehrheitserstellerinstanz verwenden möchten. Beispiel: n1-highmem-32. Wenn Sie einen benutzerdefinierten VM-Typ nutzen möchten, geben Sie einen vordefinierten VM-Typ mit einer Anzahl an vCPUs an, die der benötigten Anzahl am nächsten kommt, aber noch darüber liegt. Wenn die Bereitstellung abgeschlossen ist, ändern Sie die Anzahl der vCPUs und den Umfang des Arbeitsspeichers. Dieses Argument ist in der sap_hana_ha-Modulversion 202307270727 oder höher verfügbar.
   majority_maker_zone	String	Geben Sie eine Zone an, in der die Mehrheit der Maker-VM-Instanz bereitgestellt wird. Diese Zone muss sich in derselben Region wie die primäre und sekundäre Zone befinden. Beispiel: us-east1-d. Google Cloud empfiehlt, dass die VM-Instanz des Mehrheitserstellers in einer anderen Zone als das primäre und sekundäre SAP HANA-System bereitgestellt wird. Dieses Argument ist in der sap_hana_ha-Modulversion 202307270727 oder höher verfügbar.
   majority_maker_linux_image	String	Geben Sie dabei dieselben Werte wie im vorherigen Schritt an und geben Sie den vollständigen Image-Pfad wie "linux_image_project/linux_image" an. Beispiel: "rhel-sap-cloud/rhel-9-0-sap-v20230708".
   subnetwork	String	Geben Sie den Namen des Subnetzwerks an, das Sie in einem vorherigen Schritt erstellt haben. Wenn die Bereitstellung in einer freigegebenen VPC erfolgt, geben Sie diesen Wert als SHARED_VPC_PROJECT_ID/SUBNETWORK an. Beispiel: myproject/network1.
   service_account	String	Optional. Geben Sie die E-Mail-Adresse eines nutzerverwalteten Dienstkontos an, das von den Host-VMs und den darauf ausgeführten Programmen verwendet werden soll. Beispiel: [e-mail]. Wenn Sie dieses Argument ohne Wert angeben oder weglassen, verwendet das Installationsskript das Compute Engine-Standarddienstkonto. Weitere Informationen finden Sie unter Identitäts- und Zugriffsverwaltung für SAP-Programme in Google Cloud.
   metadata_startup_script	String	Bearbeiten Sie dieses Argument nicht. Standardmäßig lädt der Großteil der Entwickler das neueste Startskript herunter, um die Instanz für das Pacemaker-Clustering vorzubereiten.

   Zur Verdeutlichung werden Kommentare in der folgenden Beispielkonfiguration weggelassen.

  module "sap_hana_primary" {
    source = "https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_hana/sap_hana_module.zip"

    project_id                     = "example-project-123456"
    zone                           = "us-west1-a"
    machine_type                   = "n1-highmem-32"
    subnetwork                     = "default"
    linux_image                    = "rhel-9-0-sap-v20230711"
    linux_image_project            = "rhel-sap-cloud"
    instance_name                  = "hana-ha-1"
    sap_hana_sid                   = "HA1"

    sap_hana_deployment_bucket      = "my-hana-bucket"
    sap_hana_sidadm_password_secret = "hana_sid_adm_pwd"
    sap_hana_system_password_secret = "hana_sys_pwd"
    sap_hana_scaleout_nodes         = 1
    sap_hana_shared_nfs             = "10.10.10.1:/hana_scaleout/hana_a/shared"
    sap_hana_backup_nfs             = "10.10.10.1:/hana_scaleout/hana_a/backup"

  }
  module "sap_hana_secondary" {
    source = "https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_hana/sap_hana_module.zip"

    project_id                     = "example-project-123456"
    zone                           = "us-west1-b"
    machine_type                   = "n1-highmem-32"
    subnetwork                     = "default"
    linux_image                    = "rhel-9-0-sap-v20230711"
    linux_image_project            = "rhel-sap-cloud"
    instance_name                  = "hana-ha-2"
    sap_hana_sid                   = "HA1"

    sap_hana_deployment_bucket      = "my-hana-bucket"
    sap_hana_sidadm_password_secret = "hana_sid_adm_pwd"
    sap_hana_system_password_secret = "hana_sys_pwd"
    sap_hana_scaleout_nodes         = 1
    sap_hana_shared_nfs             = "10.10.10.2:/hana_scaleout/hana_b/shared"
    sap_hana_backup_nfs             = "10.10.10.2:/hana_scaleout/hana_b/backup"
  }

  resource "google_compute_instance" "majority_maker" {

    project =  "example-project-123456"

    # majority_maker_instance_name
    name         = "majority-maker"

    # majority_maker_instance_type
    machine_type = "n1-standard-8"

    # majority_maker_zone
    zone         = "us-west1-c"

    boot_disk {
      initialize_params {
        # majority_maker_linux_image
        image = "rhel-sap-cloud/rhel-9-0-sap-v20230711"
      }
    }

    network_interface {
      # network or subnetwork
      network = "default"
    }

      service_account {
      # service_account (Optional)
      # email  = [e-mail].
      scopes = ["cloud-platform"]
    }

    # Do not edit
    metadata_startup_script = "curl -s https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_majoritymaker/startup.sh | bash -s https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_majoritymaker/startup.sh"

  }

1. Initialisieren Sie Ihr aktuelles Arbeitsverzeichnis und laden Sie das Plug-in und die Moduldateien des Terraform-Anbieters für Google Cloud herunter:

   terraform init

   Mit dem Befehl terraform init wird Ihr Arbeitsverzeichnis für andere Terraform-Befehle vorbereitet.

   Wenn Sie eine Aktualisierung der Plug-in- und Konfigurationsdateien des Anbieters in Ihrem Arbeitsverzeichnis erzwingen möchten, geben Sie das Flag --upgrade an. Wenn das Flag --upgrade weggelassen wird und Sie keine Änderungen in Ihrem Arbeitsverzeichnis vornehmen, verwendet Terraform die lokal im Cache gespeicherten Kopien, auch wenn in der source-URL der Wert latest angegeben ist.

   terraform init --upgrade 

2. Optional können Sie den Terraform-Ausführungsplan erstellen:

   terraform plan

   Der Befehl terraform plan zeigt die Änderungen an, die für Ihre aktuelle Konfiguration erforderlich sind. Wenn Sie diesen Schritt überspringen, wird mit dem Befehl terraform apply automatisch ein neuer Plan erstellt und Sie werden aufgefordert, diesen zu genehmigen.

3. Wenden Sie den Ausführungsplan an:

   terraform apply

   Wenn Sie aufgefordert werden, die Aktionen zu genehmigen, geben Sie yes ein.

   Mit dem Befehl terraform apply wird die Google Cloud-Infrastruktur eingerichtet und dann die Kontrolle an ein Skript übergeben, das den HA-Cluster konfiguriert und SAP HANA gemäß den in der Terraform-Konfigurationsdatei definierten Argumenten installiert.

   Solange Terraform die Kontrolle hat, werden Statusmeldungen in Cloud Shell geschrieben. Nach dem Aufrufen des Skripts werden Statusmeldungen in Logging geschrieben und können in der Google Cloud Console angezeigt werden, wie unter Logging-Logs überprüfen beschrieben.

Bereitstellung des HANA-HA-Systems prüfen

Log prüfen

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. Cloud Shell öffnen

        Zu Cloud Shell

     3. Wechseln Sie zu Ihrem Arbeitsverzeichnis und löschen Sie das Deployment, um die VMs und nichtflüchtigen Speicher aus der fehlgeschlagenen Installation zu entfernen:

        terraform destroy

        Wenn Sie aufgefordert werden, die Aktion zu genehmigen, geben Sie yes ein.

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

Prüfen Sie die Konfiguration der VM und der SAP HANA-Installation

Hinweis: Die Bereitstellungsskripts installieren SAP HANA nur, wenn die entsprechenden Argumente in der Terraform-Konfigurationsdatei angegeben wurden. Wenn keine angegeben wurden, können Sie diesen Schritt überspringen.

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. Prüfen Sie, ob die Ausgabe /hana-Verzeichnisse wie etwa /hana/data enthält.

   [root@example-ha-vm1 ~]# df -h
     Filesystem                        Size  Used Avail Use% Mounted on
     devtmpfs                          126G     0  126G   0% /dev
     tmpfs                             126G   54M  126G   1% /dev/shm
     tmpfs                             126G   25M  126G   1% /run
     tmpfs                             126G     0  126G   0% /sys/fs/cgroup
     /dev/sda2                          30G  5.4G   25G  18% /
     /dev/sda1                         200M  6.9M  193M   4% /boot/efi
     /dev/mapper/vg_hana-shared        251G   52G  200G  21% /hana/shared
     /dev/mapper/vg_hana-sap            32G  477M   32G   2% /usr/sap
     /dev/mapper/vg_hana-data          426G  9.8G  417G   3% /hana/data
     /dev/mapper/vg_hana-log           125G  7.0G  118G   6% /hana/log
     /dev/mapper/vg_hanabackup-backup  512G  9.3G  503G   2% /hanabackup
     tmpfs                              26G     0   26G   0% /run/user/900
     tmpfs                              26G     0   26G   0% /run/user/899
     tmpfs                              26G     0   26G   0% /run/user/1003

Führen Sie eine Bereinigung durch und wiederholen Sie die Bereitstellung.

Wenn einer der Schritte zur Bereitstellungsprüfung in den vorherigen Abschnitten zeigt, dass die Installation nicht erfolgreich war, müssen Sie die Bereitstellung rückgängig machen und es noch einmal ausführen. Gehen Sie dazu so vor:

1. Beheben Sie alle Fehler, um sicherzustellen, dass Ihre Bereitstellung nicht aus demselben Grund fehlschlägt. Informationen zum Prüfen der Logs oder zum Beheben von kontingentbezogenen Fehlern finden Sie unter Logs prüfen.

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

   Cloud Shell öffnen

3. Wechseln Sie zu dem Verzeichnis, das die Terraform-Konfigurationsdatei enthält, die Sie für diese Bereitstellung verwendet haben.

4. Löschen Sie alle Ressourcen, die Teil Ihrer Bereitstellung sind, indem Sie den folgenden Befehl ausführen:

   terraform destroy

   Wenn Sie aufgefordert werden, die Aktion zu genehmigen, geben Sie yes ein.

5. Wiederholen Sie Ihre Bereitstellung wie zuvor in dieser Anleitung beschrieben.

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

Nachdem Sie alle Instanzen 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
 

SSH-Zugriff ohne Passwort 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 einen passwortlosen SSH-Zugriff müssen Sie die öffentlichen SSH-Schlüssel den Instanzmetadaten aller bereitgestellten Instanzen hinzufügen.

Die Metadaten haben das Format 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 in den primären und sekundären Systemen 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 das Einrichten eines passwortlosen SSH-Zugriffs für alle in nodes.txt aufgeführten Instanzen automatisieren. Führen Sie dazu die folgenden Schritte über die Google Cloud Console aus:

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)

Automatisierte Schritte

Verwenden Sie nodes.txt und die folgenden Skripts aus der Google Cloud Console, um diesen Prozess zu automatisieren:

1. Generieren Sie eine Datei hosts.txt mit einer Liste von IP-Adressen und Hostnamen:

   while read -u10 ZONE HOST ; do gcloud compute instances list --filter="name=( 'NAME' $HOST )" --format="csv[separator=' ',no-heading](networkInterfaces[0].networkIP,name)" >> hosts.txt; done 10< nodes.txt

2. Überprüfen Sie, ob die Datei hosts.txt in etwa so aussieht:

   10.138.0.1 rhel-hana-primary
   10.138.0.2 rhel-hana-primaryw1
   10.138.0.3 rhel-hana-secondary
   10.138.0.4 rhel-hana-secondaryw1
   10.138.0.5 rhel-sap-mm
   

3. Aktualisieren Sie auf allen Hosts im Cluster, einschließlich des Großteils des Erstellers, die Datei /etc/hosts, um die Hostnamen und die internen IP-Adressen aller Instanzen im Pacemaker-Cluster aufzunehmen.

   while read -u10 ZONE HOST ;  do gcloud compute ssh --tunnel-through-iap --quiet $HOST --zone $ZONE -- "sudo tee -a /etc/hosts" < hosts.txt; 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

Red Hat 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_SAPHanaSR]
   provider = SAPHanaSR
   path = /usr/share/SAPHanaSR-ScaleOut/
   execution_order = 1
   
   [trace]
   ha_dr_saphanasr = 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/20-saphana

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

   Ersetzen Sie SID_LC durch die SID in Kleinbuchstaben.

   Cmnd_Alias SOK = /usr/sbin/crm_attribute -n hana_SID_LC_glob_srHook -v SOK -t crm_config -s SAPHanaSR
   Cmnd_Alias SFAIL = /usr/sbin/crm_attribute -n hana_SID_LC_glob_srHook -v SFAIL -t crm_config -s SAPHanaSR
   SID_LCadm ALL=(ALL) NOPASSWD: SOK, SFAIL
   Defaults!SOK, SFAIL !requiretty

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

   #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 von Red Hat empfohlen, Sie können jedoch 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. Testen Sie auf dem primären Host als SID_LCadm den vom Hook-Skript gemeldeten Status:

   > cdtrace
   > awk '/ha_dr_SAPHanaSR.*crm_attribute/ { printf "%s %s %s %s\n",$2,$3,$5,$16 }' nameserver_*

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 Dienstprogramm socat können Sie den Port der Systemdiagnose vorübergehend überwachen.

1. Installieren Sie auf der primären und der sekundären Master-Host-VM das Dienstprogramm socat:

   $ sudo yum install -y socat

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

   $ sudo 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 nachstehend beschriebenen Verfahren wird die Red Hat-Implementierung eines Pacemaker-Clusters auf Compute Engine-VMs für SAP HANA konfiguriert.

Das Verfahren beruht auf der Red Hat-Dokumentation zum Konfigurieren von Hochverfügbarkeitsclustern (dafür wird ein Red Hat-Abo benötigt) und umfasst Folgendes:

• Hochverfügbarkeitscluster für Red Hat Enterprise Linux 2012 (und höher) in Google Cloud installieren und konfigurieren
• Automatisierte SAP HANA-Systemreplikation beim horizontalen Skalieren im Pacemaker-Cluster

Manuelle Schritte

Führen Sie die folgenden Schritte auf allen Hosts aus. Auf dem von Google bereitgestellten RHEL-for-SAP-Image sind einige Pakete bereits installiert, es sind jedoch einige zusätzliche Änderungen erforderlich.

1. Entfernen Sie als Root den SAP HANA-Ressourcen-Agent zur vertikalen Skalierung, der auf dem Image vorinstalliert ist:

   # yum -y remove resource-agents-sap-hana

2. Installieren Sie Pacemaker und die fehlenden Ressourcen-Agents:

   # yum -y install pcs pacemaker fence-agents-gce resource-agents-gcp resource-agents-sap-hana-scaleout
   

3. Aktualisieren Sie die Pakete auf die neueste Version:

   # yum-Aktualisierung -y

4. Legen Sie das Passwort für den Nutzer hacluster fest, der gemeinsam mit den Paketen erstellt wurde:

   # passwd hacluster

5. Geben Sie in den Eingabeaufforderungen ein Passwort für hacluster an.

6. In den von Google Cloud bereitgestellten RHEL-for-SAP-Images ist der Firewalldienst des Betriebssystems standardmäßig aktiv. Konfigurieren Sie den Firewalldienst so, dass Traffic mit hoher Verfügbarkeit zugelassen wird:

   # firewall-cmd --permanent --add-service=high-availability

   # firewall-cmd --reload

7. Starten Sie den pcs-Dienst und konfigurieren Sie ihn so, dass er beim Booten startet:

   # systemctl start pcsd.service
   # systemctl enable pcsd.service

8. Prüfen Sie den Status des pcs-Dienstes:

   # systemctl status pcsd.service

   Die Ausgabe sollte in etwa so aussehen:

   ● pcsd.service - PCS GUI and remote configuration interface
     Loaded: loaded (/usr/lib/systemd/system/pcsd.service; enabled; vendor preset: disabled)
     Active: active (running) since Sat 2020-06-13 21:17:05 UTC; 25s ago
       Docs: man:pcsd(8)
             man:pcs(8)
   Main PID: 31627 (pcsd)
     CGroup: /system.slice/pcsd.service
             └─31627 /usr/bin/ruby /usr/lib/pcsd/pcsd
   Jun 13 21:17:03 hana-ha-1 systemd[1]: Starting PCS GUI and remote configuration interface...
   Jun 13 21:17:05 hana-ha-1 systemd[1]: Started PCS GUI and remote configuration interface.

Automatisierte Schritte

Zur Automatisierung dieses Prozesses können Sie nodes.txt und das folgende Skript über die Google Cloud Console verwenden.

Geben Sie an der Eingabeaufforderung das Passwort ein, das vom hacluster-Nutzer verwendet werden soll, der während der Installation der Pacemaker-Ressourcen-Agents erstellt wurde.

echo "Set password for hacluster user:"; read -r HA_PASSWD; while read -u10 HOST ;  do gcloud compute ssh --tunnel-through-iap --quiet --zone $HOST -- "sudo yum -y remove resource-agents-sap-hana; sudo yum -y install pcs pacemaker fence-agents-gce resource-agents-sap-hana-scaleout resource-agents-gcp; sudo yum update -y; sudo firewall-cmd --permanent --add-service=high-availability; sudo firewall-cmd --reload; sudo systemctl start pcsd.service; sudo systemctl enable pcsd.service; yes $HA_PASSWD | sudo passwd hacluster"; done 10< nodes.txt

/etc/hosts-Datei aktualisieren

Aktualisieren Sie auf allen Hosts im Cluster, einschließlich des Großteils des Erstellers, die Datei /etc/hosts, um die Hostnamen und die internen IP-Adressen aller Instanzen im Pacemaker-Cluster aufzunehmen.

Die Ausgabe der Datei /etc/hosts sollte in etwa so aussehen:

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1                localhost localhost.localdomain localhost6 localhost6.localdomain6
10.138.0.1 rhel-hana-primary.us-west1-a.c.project-name.internal rhel-hana-primary # Added by Google
169.254.169.254 metadata.google.internal # Added by Google
10.138.0.1 rhel-hana-primary
10.138.0.2 rhel-hana-primaryw1
10.138.0.3 rhel-hana-secondary
10.138.0.4 rhel-hana-secondaryw1
10.138.0.5 rhel-sap-mm

Weitere Informationen von Red Hat zum Einrichten der Datei /etc/hosts auf RHEL-Clusterknoten finden Sie unter https://access.redhat.com/solutions/81123.

Cluster erstellen

1. Autorisieren Sie als Root den Nutzer hacluster auf dem primären Master-Host. Es ist wichtig, jeden Host des Clusters in diesen Befehl aufzunehmen. Dieser sollte Teil des Clusters sein.

   RHEL 8.0 und höher:

   pcs host auth primary-master-name primary-worker-name(s) secondary-master-name secondary-worker-name(s) majority-maker-name
   

   RHEL 7.6 und höher:

   pcs cluster auth primary-master-name primary-worker-name(s) secondary-master-name secondary-worker-name(s) majority-maker-name
   

2. Geben Sie bei Aufforderung den Nutzernamen hacluster und das Passwort ein, das Sie im vorherigen Abschnitt für den Nutzer hacluster festgelegt haben.

3. Versetzen Sie den Cluster in den Wartungsmodus.

   pcs property set maintenance-mode=true

4. Generieren und synchronisieren Sie die Corosync-Konfiguration.

   RHEL 8.0 und höher:

   pcs cluster setup scale_out_hsr primary-master-name primary-worker-name(s) secondary-master-name secondary-worker-name(s) majority-maker-name

   RHEL 7.6 und höher:

   pcs cluster setup --start --name hanascaleoutsr primary-master-name primary-worker-name(s) secondary-master-name secondary-worker-name(s) majority-maker-name

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 einer Änderung des Werts
   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 Live-Migrationen. Allerdings kann es 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 auszulassen. 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 20000 des Parameters 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.

4. Synchronisieren Sie auf dem Host, der die bearbeitete Datei corosync.conf enthält, die corosync-Konfiguration für den gesamten Cluster:

   RHEL 8 und höher:

   # pcs cluster sync corosync

   RHEL 7

   # pcs cluster sync

5. Legen Sie fest, dass der Cluster automatisch gestartet wird:

   # pcs cluster enable --all
   # pcs cluster start --all

6. Prüfen Sie mit dem Dienstprogramm "corosync-cmapctl", ob die neuen Corosync-Einstellungen im Cluster aktiv sind:

   # corosync-cmapctl

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

Fencing einrichten

RHEL-Images, die von Google Cloud bereitgestellt werden, enthalten den für Google Cloud spezifischen Fencing-Agent fence_gce. Sie verwenden fence_gce, um für jede Host-VM Fencing-Geräte zu erstellen.

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

Wenn Sie alle Optionen sehen möchten, die für den Fencing-Agent fence_gce verfügbar sind, führen Sie fence_gce -h aus.

Hinweis: Wenn Sie die Hostnamen geändert haben, sodass sie nicht mehr mit den VM-Instanznamen übereinstimmen, lesen Sie den Abschnitt Hochverfügbarkeitscluster für Red Hat Enterprise Linux 2012 (und höher) in Google Compute Cloud installieren und konfigurieren. Für die folgenden Schritte müssen die Hostnamen mit den VM-Instanznamen übereinstimmen.

Manuelle Schritte

1. Erstellen Sie als Root-Nutzer auf dem primären Host die Fencing-Geräte für alle Hosts, einschließlich des Großteils der Ersteller:

   pcs stonith create STONITH-host-name fence_gce \
   port=host-name \
   zone=host-zone \
   project=project-id \
   pcmk_host_list=host-name pcmk_reboot_timeout=300 pcmk_monitor_retries=4 \
   op monitor interval="300s" timeout="120s" \
   op start interval="0" timeout="60s"

2. Legen Sie die Standortbeschränkung für die Fencing-Geräte fest:

   pcs constraint location STONITH-host-name avoids host-name

3. Wiederholen Sie die vorherigen beiden Schritte für alle anderen Hosts auf dem primären und sekundären Cluster sowie auf dem Mehrheitsersteller-Hosts, indem Sie die entsprechenden Werte für die Variablen host-name und host-zone eingeben.

Automatisierte Schritte

Um diesen Prozess zu automatisieren, müssen Sie die Datei nodes.txt und das folgende Skript über die Google Cloud Console verwenden:

while read -u10 ZONE HOST; do gcloud compute ssh $HOST --tunnel-through-iap --quiet --zone $ZONE -- "sudo pcs stonith create STONITH-$HOST fence_gce project=project-id port=$HOST zone=$ZONE pcmk_host_list=$HOST pcmk_reboot_timeout=300 pcmk_monitor_retries=4 op monitor interval=300s timeout=120s op start interval=0 timeout=60s && sudo pcs constraint location STONITH-$HOST avoids $HOST"; done 10< nodes.txt

Standardeinstellungen für den Cluster festlegen

Richten Sie Migrationsschwellenwerte und Wiederkehrrate ein, um festzulegen, wie viele Failover-Versuche ausgeführt werden sollen, bevor der Vorgang fehlschlägt, und um das System so zu konfigurieren, dass es zuerst auf dem aktuellen Host neu gestartet wird. Für die Anwendung auf den Cluster muss dies nur auf einem Knoten festgelegt werden.

1. Legen Sie als Root von einem beliebigen Host aus die Standardeinstellungen für Ressourcen fest:

   RHEL 8.0 und höher:

   # pcs resource defaults update resource-stickiness=1000
   # pcs resource defaults update migration-threshold=5000

   RHEL 7.6 und höher:

   # pcs resource defaults resource-stickiness=1000
   # pcs resource defaults migration-threshold=5000

   Das Attribut resource-stickiness steuert, wie wahrscheinlich ein Dienst dort ausgeführt wird, wo er sich befindet. Bei höheren Werten ist der Dienst fixierter. Mit dem Wert 1000 ist der Dienst stark fixiert.

   Das Attribut migration-threshold gibt die Anzahl der Fehler an, die auftreten müssen, bevor der Dienst per Failover auf einen anderen Host verlagert wird Ein Wert von 5.000 ist hoch genug, um bei nur kurzzeitig auftretenden Fehlern ein Failover zu vermeiden.

   Sie können die Standardeinstellungen für Ressourcen prüfen, indem Sie pcs resource defaults eingeben.

2. Standardeinstellungen für Zeitlimits bei Ressourcenvorgängen festlegen:

   RHEL 8.0 und höher:

   # pcs resource op defaults update timeout=600s

   RHEL 7.6 und höher:

   # pcs resource op defaults timeout=600s

   Sie können die Standardeinstellungen für Ressourcenvorgänge prüfen, indem Sie pcs resource op defaults eingeben.

3. Folgende Clusterattribute festlegen:

   # pcs property set stonith-enabled="true"
   # pcs property set stonith-timeout="300s"
   

   Sie können die Einstellungen der Attribute mit pcs property list prüfen.

Ressource SAPHanaTopology erstellen

Die Ressource SAPHanaTopology ruft den Status und die Konfiguration der HANA-Systemreplikation auf den Knoten ab. Außerdem wird der SAP-Host-Agent geprüft.

1. Erstellen Sie als Root auf einem Host die Ressource SAPHanaTopology:

   RHEL 8.0 und höher:

   # pcs resource create rsc_SAPHanaTopology_SID_HDBinstNr SAPHanaTopology SID=SID \
   InstanceNumber=inst_num \
   op methods interval=0s timeout=5 \
   op monitor interval=10 timeout=600 \
   clone meta clone-node-max=1 interleave=true

   RHEL 7.6 und höher:

   # pcs resource create rsc_SAPHanaTopology_SID_HDBinstNr SAPHanaTopologyScaleOut SID=SID \
   InstanceNumber=inst_num \
   op start timeout=600 \
   op stop timeout=300 \
   op monitor interval=10 timeout=600

   # pcs resource clone  rsc_SAPHanaTopology_SID_HDBinstNr meta clone-node-max=1 interleave=true

2. Nachdem die Ressource erstellt wurde, prüfen Sie die Konfiguration. Hängen Sie -clone an den Ressourcennamen an, um die Informationen zum Klonsatz in die Antwort aufzunehmen.

   RHEL 8.0 und höher:

   # pcs resource config rsc_SAPHanaTopology_SID_HDBinstNr-clone

   Die Ausgabe sollte in etwa so aussehen:

   Clone: SAPHanaTopology_HA1_00-clone
   Meta Attrs: clone-node-max=1 interleave=true
   Resource: SAPHanaTopology_HA1_00 (class=ocf provider=heartbeat type=SAPHanaTopology)
   Attributes: InstanceNumber=00 SID=HA1
   Operations: methods interval=0s timeout=5 (SAPHanaTopology_HA1_00-methods-interval-0s)
          monitor interval=10 timeout=600 (SAPHanaTopology_HA1_00-monitor-interval-10)
          start interval=0s timeout=600 (SAPHanaTopology_HA1_00-start-interval-0s)
          stop interval=0s timeout=300 (SAPHanaTopology_HA1_00-stop-interval-0s)

   RHEL 7.6 und höher:

   # pcs resource show rsc_SAPHanaTopology_SID_HDBinstNr-clone

   Die Ausgabe sollte in etwa so aussehen:

   Clone: rsc_SAPHanaTopology_HA1_HDB00-clone
   Meta Attrs: clone-node-max=1 interleave=true
   Resource: rsc_SAPHanaTopology_HA1_HDB00 (class=ocf provider=heartbeat type=SAPHanaTopologyScaleOut)
   Attributes: InstanceNumber=00 SID=HA1
   Meta Attrs: clone-node-max=1 interleave=true
   Operations: methods interval=0s timeout=5 (rsc_SAPHanaTopology_HA1_HDB00-methods-interval-0s)
          monitor interval=10 timeout=600 (rsc_SAPHanaTopology_HA1_HDB00-monitor-interval-10)
          start interval=0s timeout=600 (rsc_SAPHanaTopology_HA1_HDB00-start-interval-0s)
          stop interval=0s timeout=300 (rsc_SAPHanaTopology_HA1_HDB00-stop-interval-0s)

Sie können die Clusterattribute auch mit dem Befehl crm_mon -A1 prüfen.

Ressource SAPHanaController erstellen

Der SAPHanaController-Ressourcen-Agent verwaltet die Datenbanken, die für die SAP HANA-Systemreplikation konfiguriert sind.

Die folgenden Parameter in der SAPHana-Ressourcendefinition sind optional:

• AUTOMATED_REGISTER: Wenn dieser Wert auf true festgelegt ist, wird die frühere primäre Instanz automatisch als sekundäre registriert, wenn nach einem Takeover der DUPLICATE_PRIMARY_TIMEOUT eintritt. Der Standardwert ist false

  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.

• DUPLICATE_PRIMARY_TIMEOUT: Zeit in Sekunden, die zwischen zwei Primär-Zeitstempeln verstreichen muss, wenn zwei primäre Instanzen erfasst werden. Der Standardwert ist 7200.

• PREFER_SITE_TAKEOVER: Legt fest, ob lokale Neustarts versucht werden sollen, bevor ein Failover ausgelöst wird. Der Standardwert ist false.

Weitere Informationen zu diesen Parametern finden Sie unter Hochverfügbarkeitscluster für Red Hat Enterprise Linux 7.6 (und höher) in Google Cloud installieren und konfigurieren. Hierfür ist ein Red Hat-Abo erforderlich.

1. Erstellen Sie als Root auf einem Host die SAPHanaController-Ressource:

   RHEL 8.0 und höher:

   # pcs resource create rsc_SAPHana_SID_HDBinstNr SAPHanaController SID=SID \
   InstanceNumber=inst_num \
   PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true \
   op demote interval=0s timeout=320 \
   op methods interval=0s timeout=5 \
   op monitor interval=59 \
   role="Master" timeout=700 \
   op monitor interval=61 \
   role="Slave" timeout=700 \
   op promote interval=0 timeout=3600 \
   op start interval=0 timeout=3600 \
   op stop interval=0 timeout=3600e

   # pcs resource promotable rsc_SAPHana_SID_HDBinstNr meta master-max="1" clone-node-max=1 interleave=true

   RHEL 7.6 und höher:

   # pcs resource create rsc_SAPHana_SID_HDBinstNr SAPHanaController SID=SID \
   InstanceNumber=inst_num \
   PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true \
   op start interval=0 timeout=3600 \
   op stop interval=0 timeout=3600 \
   op promote interval=0 timeout=3600 \
   op monitor interval=60 \
   role="Master" timeout=700 \
   op monitor interval=61 \
   role="Slave" timeout=700

   # pcs resource master msl_rsc_SAPHana_SID_HDBinstNr rsc_SAPHana_SID_HDBinstNr master-max="1" clone-node-max=1 interleave=true

2. Überprüfen Sie die ausgegebenen Ressourcenattribute:

   RHEL 8.0 und höher:

   # pcs resource config rsc_SAPHana_SID_HDBinstNr-clone

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

   Resource: SAPHana_HA1_00 (class=ocf provider=heartbeat type=SAPHanaController)
   Attributes: AUTOMATED_REGISTER=true DUPLICATE_PRIMARY_TIMEOUT=7200 InstanceNumber=00 PREFER_SITE_TAKEOVER=true SID=HA1
   Operations: demote interval=0s timeout=320 (SAPHana_HA1_00-demote-interval-0s)
         methods interval=0s timeout=5 (SAPHana_HA1_00-methods-interval-0s)
         monitor interval=59 role=Master timeout=700 (SAPHana_HA1_00-monitor-interval-59)
         promote interval=0 timeout=3600 (SAPHana_HA1_00-promote-interval-0)
         reload interval=0s timeout=5 (SAPHana_HA1_00-reload-interval-0s)
         start interval=0 timeout=3600 (SAPHana_HA1_00-start-interval-0)
         stop interval=0 timeout=3600 (SAPHana_HA1_00-stop-interval-0)
         monitor interval=61 role=Slave timeout=700 (SAPHana_HA1_00-monitor-interval-61)

   RHEL 7.6 und höher:

   # pcs resource show msl_rsc_SAPHana_SID_HDBinstNr

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

   Master: msl_rsc_SAPHana_HA1_HDB00
   Meta Attrs: clone-node-max=1 interleave=true master-max=1
   Resource: rsc_SAPHana_HA1_HDB00 (class=ocf provider=heartbeat type=SAPHanaController)
   Attributes: AUTOMATED_REGISTER=true DUPLICATE_PRIMARY_TIMEOUT=7200 InstanceNumber=00 PREFER_SITE_TAKEOVER=true SID=HA1
   Operations: demote interval=0s timeout=320 (rsc_SAPHana_HA1_HDB00-demote-interval-0s)
          methods interval=0s timeout=5 (rsc_SAPHana_HA1_HDB00-methods-interval-0s)
          monitor interval=60 role=Master timeout=700 (rsc_SAPHana_HA1_HDB00-monitor-interval-60)
          monitor interval=61 role=Slave timeout=700 (rsc_SAPHana_HA1_HDB00-monitor-interval-61)
          promote interval=0 timeout=3600 (rsc_SAPHana_HA1_HDB00-promote-interval-0)
          start interval=0 timeout=3600 (rsc_SAPHana_HA1_HDB00-start-interval-0)
          stop interval=0 timeout=3600 (rsc_SAPHana_HA1_HDB00-stop-interval-0)

Virtuelle IP-Adressressource erstellen

Sie müssen für die VIP eine Clusterressource erstellen. Die VIP-Ressource ist für das primäre Betriebssystem lokalisiert und kann nicht von anderen Hosts weitergeleitet werden. Der Load-Balancer leitet den an die VIP gesendeten Traffic basierend auf der Systemdiagnose an den Back-End-Host weiter.

Als Root auf einem Host:

# pcs resource create rsc_ip_SAPHANA_SID_HDBinstNr \
  IPaddr2 ip="vip-address" nic=eth0 cidr_netmask=32 \
  op monitor interval=3600s timeout=60s

Der Wert vip-address ist dieselbe IP-Adresse, die Sie zuvor reserviert und in der Weiterleitungsregel für das Frontend Ihres Load-Balancers angegeben haben. Ändern Sie die Netzwerkschnittstelle entsprechend Ihrer Konfiguration.

Einschränkungen erstellen

Mit Einschränkungen legen Sie fest, welche Dienste zuerst gestartet werden müssen und welche Dienste zusammen auf demselben Host ausgeführt werden müssen.

1. Definieren Sie die Einschränkung für die Startreihenfolge:

   RHEL 8.0 und höher:

   # pcs constraint order start rsc_SAPHanaTopology_SID_HDBinstNr-clone then start rsc_SAPHana_SID_HDBinstNr-clone
   

   RHEL 7.6

   # pcs constraint order rsc_SAPHanaTopology_SID_HDBinstNr-clone then rsc_SAPHana_SID_HDBinstNr-master
   

2. Konfigurieren Sie die Mehrheitsersteller, um die Aktivierung einer aktiven Rolle in der Clusterumgebung zu vermeiden:

   RHEL 8.0 und höher:

   # pcs constraint location rsc_SAPHana_SID_HDBinstNr-clone avoids majority-maker-name
   
   # pcs constraint location rsc_SAPHanaTopology_SID_HDBinstNr-clone avoids majoritymaker

   RHEL 7.6

   # pcs constraint location msl_rsc_SAPHana_SID_HDBinstNr avoids majoritymaker
   
   # pcs constraint location rsc_SAPHanaTopology_SID_HDBinstNr-clone avoids majoritymaker

3. Prüfen Sie die Einschränkungen:

   # pcs constraint

   Die Ausgabe sollte in etwa so aussehen:

   Location Constraints:
   Resource: STONITH-hana-ha-1
     Disabled on: hana-ha-1 (score:-INFINITY)
   Resource: STONITH-hana-ha-1w1
     Disabled on: hana-ha-1w1 (score:-INFINITY)
   Resource: STONITH-hana-ha-2
     Disabled on: hana-ha-2 (score:-INFINITY)
   Resource: STONITH-hana-ha-2w1
     Disabled on: hana-ha-2w1 (score:-INFINITY)
   Resource: STONITH-majority-maker
     Disabled on: majority-maker (score:-INFINITY)
   Resource: rsc_SAPHanaTopology_HA1_HDB00-clone
     Disabled on: majority-maker (score:-INFINITY)
   Resource: rsc_SAPHana_HA1_HDB00-master
     Disabled on: majority-maker (score:-INFINITY)
   Ordering Constraints:
     start rsc_SAPHanaTopology_HA1_HDB00-clone then start rsc_SAPHana_HA1_HDB00-master (kind:Mandatory)

Listener installieren und Systemdiagnose-Ressource erstellen

Zum Konfigurieren einer Systemdiagnose-Ressource müssen Sie zuerst die Listener installieren.

Listener installieren

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. 1. Installieren Sie als Root auf der Masterinstanz auf dem primären und dem sekundären System einen TCP-Listener. In dieser Anleitung wird HAProxy als Listener installiert und verwendet.

# yum install haproxy

1. Öffnen Sie die Konfigurationsdatei haproxy.cfg zur Bearbeitung:

   # vi /etc/haproxy/haproxy.cfg

   1. Ändern Sie im Abschnitt Defaults der Datei haproxy.cfg den Parameter mode in tcp.

   2. Erstellen Sie nach dem Abschnitt Defaults einen neuen Abschnitt, indem Sie Folgendes hinzufügen:

      #---------------------------------------------------------------------
      # Health check listener port for SAP HANA HA cluster
      #---------------------------------------------------------------------
      listen healthcheck
        bind *:healthcheck-port-num

      Der Bind-Port ist derselbe, den Sie beim Erstellen der Systemdiagnose verwendet haben.

      Wenn Sie fertig sind, sollten die Aktualisierungen in etwa so aussehen:

      #---------------------------------------------------------------------
      # common defaults that all the 'listen' and 'backend' sections will
      # use if not designated in their block
      #---------------------------------------------------------------------
      defaults
        mode                    tcp
        log                     global
        option                  tcplog
        option                  dontlognull
        option http-server-close
        # option forwardfor       except 127.0.0.0/8
        option                  redispatch
        retries                 3
        timeout http-request    10s
        timeout queue           1m
        timeout connect         10s
        timeout client          1m
        timeout server          1m
        timeout http-keep-alive 10s
        timeout check           10s
        maxconn                 3000
      
      #---------------------------------------------------------------------
      # Set up health check listener for SAP HANA HA cluster
      #---------------------------------------------------------------------
      listen healthcheck
       bind *:60000

2. Starten Sie als Root den Dienst auf jedem Host, um zu prüfen, ob er richtig konfiguriert ist:

   # systemctl start haproxy.service

3. Klicken Sie in der Google Cloud Console auf der Seite „Load-Balancer“ auf den Load-Balancer-Eintrag:

   Seite "Load-Balancing"

   Wenn auf der Seite Details zum Load-Balancer im Bereich Back-End der HAProxy-Dienst an beiden Hosts aktiv ist, wird in der Spalte Fehlerfrei jedes Instanzgruppeneintrags 1/1 angezeigt.

   

4. Beenden Sie auf beiden Hosts den HAProxy-Dienst:

   # systemctl stop haproxy.service

   Nachdem Sie den HAProxy-Dienst auf beiden Hosts beendet haben, wird in der Spalte Fehlerfrei jeder Instanzgruppe 0/1 angezeigt.

   

   Später, wenn die Systemdiagnose konfiguriert ist, startet der Cluster den Listener auf dem Masterknoten neu.

Systemdiagnose-Ressource erstellen

1. Erstellen Sie als Root von einem beliebigen Host aus eine Systemdiagnose-Ressource für den HAProxy-Dienst:

   # pcs resource create hc_SID_HDBinstNr service:haproxy op monitor interval=10s timeout=20s

2. Gruppieren Sie die Ressourcen für VIP und Systemdiagnose:

   # pcs resource group add rsc-group-name hc_SID_HDBinstNr rsc_ip_SAPHANA_SID_HDBinstNr

3. Erstellen Sie eine Einschränkung, die die Gruppe auf demselben Knoten wie die Master-SAP HANA-Instanz platziert.

   RHEL 8.0 und höher:

   # pcs constraint colocation add rsc-group-name with master rsc_SAPHana_SID_HDBinstNr-clone

   RHEL 7.6 und höher:

   # pcs constraint colocation add rsc-group-name with master msl_rsc_SAPHana_SID_HDBinstNr

4. Erstellen Sie eine Auftragseinschränkung, um die Gruppe erst zu starten, nachdem HANA hochgestuft wurde:

   # pcs constraint order promote rsc_SAPHana_SID_HDBinstNr-clone then start rsc-group-name

   Die endgültigen Einschränkungen sollten in etwa so aussehen:

   # pcs constraint
   
   Location Constraints:
   Resource: STONITH-hana-ha-1
    Disabled on: hana-ha-1 (score:-INFINITY)
   Resource: STONITH-hana-ha-1w1
    Disabled on: hana-ha-1w1 (score:-INFINITY)
   Resource: STONITH-hana-ha-2
    Disabled on: hana-ha-2 (score:-INFINITY)
   Resource: STONITH-hana-ha-2w1
    Disabled on: hana-ha-2w1 (score:-INFINITY)
   Resource: STONITH-majority-maker
    Disabled on: majority-maker (score:-INFINITY)
   Resource: rsc_SAPHanaTopology_HA1_HDB00-clone
    Disabled on: majority-maker (score:-INFINITY)
   Resource: rsc_SAPHana_HA1_HDB00-master
    Disabled on: majority-maker (score:-INFINITY)
   Ordering Constraints:
    start rsc_SAPHanaTopology_HA1_HDB00-clone then start rsc_SAPHana_HA1_HDB00-master (kind:Mandatory)
    promote rsc_SAPHana_HA1_HDB00-clone then start g-primary (kind:Mandatory) (id:order-rsc_SAPHana_HA1_HDB00-clone-g-primary-mandatory)
   Colocation Constraints:
    g-primary with rsc_SAPHana_HA1_HDB00-master (score:INFINITY) (rsc-role:Started) (with-rsc-role:Master)
   Ticket Constraints:

Einrichtung abschließen

1. Beenden Sie den Wartungsmodus des Clusters:

   pcs property set maintenance-mode=false

2. Prüfen Sie nach dem Start der Ressource die Knotenattribute, um den aktuellen Status der SAP HANA-Datenbanken auf den Knoten anzeigen zu lassen:

   # crm_mon -A1

   Die Ausgabe sollte in etwa so aussehen:

   RHEL 8.0 und höher:

   Cluster Summary:
   Stack: corosync
   Current DC: hana-ha-2w1 (version 2.0.5-9.el8_4.7-ba59be7122) - partition with quorum
   Last updated: Wed Oct 11 17:59:51 2023
   Last change:  Wed Oct 11 17:59:48 2023 by hacluster via crmd on hana-ha-2
   5 nodes configured
   17 resource instances configured
   
   Node List:
   Online: [ hana-ha-1 hana-ha-1w1 hana-ha-2 hana-ha-2w1 dru-somm ]
   
   Active Resources:
   STONITH-hana-ha-1     (stonith:fence_gce):     Started hana-ha-2
   STONITH-hana-ha-1w1   (stonith:fence_gce):     Started hana-ha-1
   STONITH-hana-ha-2     (stonith:fence_gce):     Started hana-ha-2w1
   STONITH-hana-ha-2w1   (stonith:fence_gce):     Started dru-somm
   STONITH-dru-somm    (stonith:fence_gce):     Started hana-ha-1
   Clone Set: SAPHanaTopology_HA1_00-clone [SAPHanaTopology_HA1_00]:
    Started: [ hana-ha-1 hana-ha-1w1 hana-ha-2 hana-ha-2w1 ]
   Clone Set: SAPHana_HA1_00-clone [SAPHana_HA1_00]-(promotable):
    Slaves: [ hana-ha-1w1 hana-ha-2w1 ]
   Resource Group: g-primary:
    healthcheck_HA1   (service:haproxy):       Started hana-ha-1
    ip_SAPHANA_HA1_00 (ocf::heartbeat:IPaddr2):        Started hana-ha-1
   
   Node Attributes:
   Node: hana-ha-1:
    hana_ha1_clone_state              : PROMOTED
    hana_ha1_gra                      : 2.0
    hana_ha1_remoteHost               : hana-ha-2w1
    hana_ha1_roles                    : master1:master:worker:master
    hana_ha1_site                     : hana-ha-1
    hana_ha1_sra                      : -
    hana_ha1_srmode                   : syncmem
    hana_ha1_vhost                    : hana-ha-1
    master-SAPHana_HA1_00             : 5
   Node: hana-ha-1w1:
    hana_ha1_clone_state              : DEMOTED
    hana_ha1_gra                      : 2.0
    hana_ha1_remoteHost               : hana-ha-2w1
    hana_ha1_roles                    : slave:slave:worker:slave
    hana_ha1_site                     : hana-ha-1
    hana_ha1_srmode                   : syncmem
    hana_ha1_vhost                    : hana-ha-1w1
    master-SAPHana_HA1_00             : -INFINITY
   Node: hana-ha-2:
    hana_ha1_clone_state              : DEMOTED
    hana_ha1_gra                      : 2.0
    hana_ha1_remoteHost               : hana-ha-1w1
    hana_ha1_roles                    : master1:master:worker:master
    hana_ha1_site                     : hana-ha-2
    hana_ha1_sra                      : -
    hana_ha1_srmode                   : syncmem
    hana_ha1_vhost                    : hana-ha-2
    master-SAPHana_HA1_00             : 100
   Node: hana-ha-2w1:
    hana_ha1_clone_state              : DEMOTED
    hana_ha1_gra                      : 2.0
    hana_ha1_remoteHost               : hana-ha-1w1
    hana_ha1_roles                    : slave:slave:worker:slave
    hana_ha1_site                     : hana-ha-2
    hana_ha1_srmode                   : syncmem
    hana_ha1_vhost                    : hana-ha-2w1
    master-SAPHana_HA1_00             : -12200
   Node: dru-somm:
    hana_ha1_remoteHost               : hana-ha-2w1
    hana_ha1_srmode                   : syncmem

   RHEL 7.6 und höher:

   Stack: corosync
   Current DC: majority-maker (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
   Last updated: Wed Oct 11 17:58:07 2023
   Last change: Wed Oct 11 17:57:57 2023 by hacluster via crmd on hana-ha-2w1
   
   5 nodes configured
   17 resource instances configured
   
   Online: [ hana-ha-1 hana-ha-1w1 hana-ha-2 hana-ha-2w1 majority-maker ]
   
   Active resources:
   
   STONITH-hana-ha-1 (stonith:fence_gce):    Started hana-ha-1w1
   STONITH-hana-ha-1w1       (stonith:fence_gce):    Started hana-ha-2
   STONITH-hana-ha-2 (stonith:fence_gce):    Started hana-ha-1
   STONITH-hana-ha-2w1       (stonith:fence_gce):    Started majority-maker
   STONITH-majority-maker (stonith:fence_gce):    Started hana-ha-1w1
   Master/Slave Set: msl_rsc_SAPHana_HA1_HDB00 [rsc_SAPHana_HA1_HDB00]
    rsc_SAPHana_HA1_HDB00      (ocf::heartbeat:SAPHanaController):     Master hana-ha-1 (Monitoring)
    Slaves: [ hana-ha-1w1 hana-ha-2 hana-ha-2w1 ]
   Clone Set: rsc_SAPHanaTopology_HA1_HDB00-clone [rsc_SAPHanaTopology_HA1_HDB00]
    Started: [ hana-ha-1 hana-ha-1w1 hana-ha-2 hana-ha-2w1 ]
   Resource Group: g-primary
    hc_HA1_HDB00       (service:haproxy):      Started hana-ha-1
    rsc_ip_SAPHANA_HA1_HDB00   (ocf::heartbeat:IPaddr2):       Started hana-ha-1
   
   Node Attributes:
   Node hana-ha-1:
     hana_ha1_clone_state              : PROMOTED
     hana_ha1_remoteHost               : hana-ha-2
     hana_ha1_roles                    : master1:master:worker:master
     hana_ha1_site                     : hana-ha-1
     hana_ha1_srmode                   : syncmem
     hana_ha1_vhost                    : hana-ha-1
     master-rsc_SAPHana_HA1_HDB00      : 150
   Node hana-ha-1w1:
     hana_ha1_clone_state              : DEMOTED
     hana_ha1_remoteHost               : hana-ha-2w1
     hana_ha1_roles                    : slave:slave:worker:slave
     hana_ha1_site                     : hana-ha-1
     hana_ha1_srmode                   : syncmem
     hana_ha1_version                  : 2.00.052.00.1599235305
     hana_ha1_vhost                    : hana-ha-1w1
     master-rsc_SAPHana_HA1_HDB00      : -10000
   Node hana-ha-2:
     hana_ha1_clone_state              : DEMOTED
     hana_ha1_remoteHost               : hana-ha-2w1
     hana_ha1_roles                    : master1:master:worker:master
     hana_ha1_site                     : hana-ha-2
     hana_ha1_srmode                   : syncmem
     hana_ha1_vhost                    : hana-ha-2
     master-rsc_SAPHana_HA1_HDB00      : 100
   Node hana-ha-2w1:
     hana_ha1_clone_state              : DEMOTED
     hana_ha1_remoteHost               : hana-ha-1
     hana_ha1_roles                    : slave:slave:worker:slave
     hana_ha1_site                     : hana-ha-2
     hana_ha1_srmode                   : syncmem
     hana_ha1_vhost                    : hana-ha-2w1
     master-rsc_SAPHana_HA1_HDB00      : -12200
   Node majority-maker:
     hana_ha1_srmode                   : syncmem

3. Wenn fehlgeschlagene Clusterressourcen vorhanden sind, müssen Sie möglicherweise den nächsten Befehl ausführen:

   pcs resource cleanup

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 Ihre Instanzen mehrere Netzwerkschnittstellen definiert sind, verwenden Sie den Befehl iptables auf dem sekundären Host, um eingehenden und ausgehenden Traffic anhand der IP-Adresse auszulassen, die vom primären Host zur Cluster-Kommunikation verwendet wird. Dadurch wird ein Verlust der Netzwerkverbindung zum primären Knoten simuliert.

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

   Cluster name: hana-ha-cluster
   Stack: corosync
   Current DC: hana-ha-vm-2 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
   Last updated: Wed Jun 17 01:04:36 2020
   Last change: Wed Jun 17 01:03:58 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:fence_gce):    Started hana-ha-vm-2
   STONITH-hana-ha-vm-2   (stonith:fence_gce):    Started hana-ha-vm-1
   STONITH-hana-ha-vm-1w1   (stonith:fence_gce):    Started hana-ha-vm-2w1
   STONITH-hana-ha-vm-1w1   (stonith:fence_gce):    Started hana-ha-vm-mm
   STONITH-hana-ha-vm-mm   (stonith:fence_gce):    Started hana-ha-vm-1w1
   Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
       Started: [ hana-ha-vm-1 hana-ha-vm-2 hana-ha-vm-1w1 hana-ha-vm-2w1
       Stopped: [ hana-ha-vm-mm ] ]
   Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
       Masters: [ hana-ha-vm-2 ]
       Slaves: [ hana-ha-vm-1 hana-ha-vm-1w1 hana-ha-vm-2w1
       Stopped: [ hana-ha-vm-mm ] ]
   Resource Group: g-primary
       rsc_healthcheck_HA1        (service:haproxy):      Started hana-ha-vm-2
       rsc_vip_HA1_22     (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-2
   
   Daemon Status:
    corosync: active/enabled
    pacemaker: active/enabled
    pcsd: active/enabled

Fehlerbehebung

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

Support für SAP HANA unter RHEL

Wenn Sie Hilfe bei einem Problem mit Hochverfügbarkeitsclustern für SAP HANA unter RHEL 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 RHEL.

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, an die Google Cloud-Komponente BC-OP-LNX-GOOGLE oder BC-OP-NT-GOOGLE weiter.

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

Ressourcen mit weiterführenden Informationen:

• Hochverfügbarkeitscluster für Red Hat Enterprise Linux 7.6 (und höher) in Google Cloud installieren und konfigurieren
• Automatisierte SAP HANA-Systemreplikation beim vertikalen Skalieren im Pacemaker-Cluster
• Supportrichtlinien für RHEL-Hochverfügbarkeitscluster – Allgemeine Anforderungen für Fencing/STONith
• 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.