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

In dieser Anleitung wird beschrieben, wie Sie die Bereitstellung eines SAP HANA-Systems mit horizontaler Skalierung in einem SLES-Hochverfügbarkeitscluster (SUSE Linux Enterprise Server) in Google Cloud automatisieren.

In dieser Anleitung wird Terraform verwendet, um ein SAP HANA-System mit horizontaler Skalierung für mehrere Hosts, eine virtuelle IP-Adresse (VIP) mit einer internen Passthrough-Netzwerk-Load-Balancer-Implementierung und einem betriebssystembasierten HA-Cluster, alles gemäß den Best Practices von Google Cloud, SAP und SUSE.

Eines der SAP HANA-Systeme dient als primäres, aktives System und das andere als sekundäres Standby-System. Sie stellen beide SAP HANA-Systeme in derselben Region bereit, idealerweise in verschiedenen Zonen.

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

  • Ressourcen-Manager für Hochverfügbarkeitscluster von Pacemaker
  • Google Cloud-Fencing-Mechanismus
  • Eine virtuelle IP-Adresse (VIP), die die Implementierung eines internen TCP-Load-Balancers der Ebene 4 verwendet, einschließlich:
    • Eine Reservierung der IP-Adresse, die Sie für die VIP auswählen.
    • Zwei Compute Engine-Instanzgruppen.
    • Ein interner TCP-Load-Balancer.
    • Eine Compute Engine-Systemdiagnose.
  • SUSE-Hochverfügbarkeitsmuster
  • SUSE SAPHanaSR-Ressourcen-Agent-Paket
  • Synchrone Systemreplikation
  • Vorab in den Arbeitsspeicher laden
  • Automatischer Neustart der fehlgeschlagenen Instanz als neue sekundäre Instanz

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.

Wenn Sie ein SAP HANA-System ohne Linux-Hochverfügbarkeitscluster oder Standby-Hosts bereitstellen möchten, verwenden Sie den Terraform: Bereitstellungsleitfaden für SAP HANA.

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

Vorbereitung

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

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.

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.

Linux-Hochverfügbarkeitscluster mit SAP HANA-Installation erstellen

In der folgenden Anleitung wird mit der Terraform-Konfiguration ein SLES-Cluster mit zwei SAP HANA-Systemen erstellt: ein primäres SAP HANA-System und ein sekundäres oder Standby-SAP HANA-System in derselben Compute Engine-Region. Die SAP HANA-Systeme verwenden die synchrone Systemreplikation. Die replizierten Daten werden vorab vom Standby-System geladen.

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 sap_hana_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/sap_hana_ha.tf

  4. Öffnen Sie die Datei sap_hana_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 sap_hana_ha.tf die folgenden 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 sap_hana_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: 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 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
    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.

    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 sowohl in der primären als auch in der sekundären Zone 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.

    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.

    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.

    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.

    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/sap_hana_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.

    enable_fast_restart Boolesch Optional. Dieses Argument bestimmt, ob die Option "SAP HANA Fast Restart" für Ihre Bereitstellung aktiviert ist. Der Standardwert ist true. Google Cloud empfiehlt dringend, die Option "SAP HANA Fast Restart" zu aktivieren.

    Dieses Argument ist ab der sap_hana_ha-Modulversion 202309280828 verfügbar.

    public_ip Boolesch Optional. Legt fest, ob Ihre VM-Instanz eine öffentliche IP-Adresse erhält. Der Standardwert ist true.
    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: svc-acct-name@project-id.iam.gserviceaccount.com.

    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.

    Das folgende Beispiel zeigt eine fertige Konfigurationsdatei, die einen Hochverfügbarkeitscluster für ein SAP HANA-System mit horizontaler Skalierung auf SLES definiert. 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, die Installation von SAP HANA, die Konfiguration der Replikation und die Konfiguration des Linux-HA-Clusters.

    Zur Verdeutlichung werden Kommentare in der folgenden Beispielkonfiguration weggelassen.

    # ...
module "sap_hana_ha" {
source = "https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_hana_ha/sap_hana_ha_module.zip"
#
# By default, this source file uses the latest release of the terraform module
# for SAP on Google Cloud.  To fix your deployments to a specific release
# of the module, comment out the source argument above and uncomment the source argument below.
#
# source = "https://storage.googleapis.com/cloudsapdeploy/terraform/YYYYMMDDHHMM/terraform/sap_hana_ha/sap_hana_ha_module.zip"
# ...
project_id = "example-project-123456"
machine_type = "n2-highmem-32"
network = "example-network"
subnetwork = "example-subnet-us-central1"
linux_image = "sles-15-sp4-sap"
linux_image_project = "suse-sap-cloud"

primary_instance_name = "example-ha-vm1"
primary_zone = "us-central1-a"

secondary_instance_name = "example-ha-vm2"
secondary_zone = "us-central1-b"

majority_maker_instance_name = "example-ha-mj"
majority_maker_instance_type = "n2-highmem-32"
majority_maker_zone = "us-central1-c"

sap_hana_scaleout_nodes = 2
# ...
sap_hana_deployment_bucket = "my-hana-bucket"
sap_hana_sid = "HA1"
sap_hana_instance_number = 00
sap_hana_sidadm_password_secret = "hana_sid_adm_pwd"
sap_hana_system_password_secret = "hana_sys_pwd"
# ...
sap_vip = "10.0.0.100"
primary_instance_group_name = "ig-example-ha-vm1"
secondary_instance_group_name = "ig-example-ha-vm2"
loadbalancer_name = "lb-ha1"
# ...
network_tags = ["hana-ha-ntwk-tag"]
service_account = "sap-deploy-example@example-project-123456.iam.gserviceaccount.com"
primary_static_ip = "10.0.0.1"
secondary_static_ip = "10.0.0.2"
primary_worker_static_ips = ["10.0.0.3", "10.0.0.4"]
secondary_worker_static_ips = ["10.0.0.5", "10.0.0.6"]
enable_fast_restart = true
# ...
}

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

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

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

Das Prüfen eines SAP HANA-HA-Clusters umfasst mehrere Schritte:

  • Logging prüfen
  • Konfiguration der VM und der SAP HANA-Installation prüfen
  • Clusterkonfiguration prüfen
  • Load-Balancer und Zustand der Instanzgruppen prüfen
  • SAP HANA-System mit SAP HANA Studio prüfen
  • Failover-Test durchführen

Log prüfen

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

    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

  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.

    Schaltfläche "SSH" auf der Seite "VM-Instanzen" von Compute Engine

  2. Wechseln Sie zum Root-Nutzer.

    sudo su -

  3. Geben Sie bei der Eingabeaufforderung Folgendes ein.

    df -h

    Die Ausgabe sieht etwa so aus wie im folgenden Beispiel. Achten Sie darauf, dass Ihre Ausgabe die /hana-Verzeichnisse enthält, z. B. /hana/data.

    example-ha-vm1:~ # df -h
Filesystem                         Size  Used Avail Use% Mounted on
devtmpfs                           4.0M  8.0K  4.0M   1% /dev
tmpfs                              189G   48M  189G   1% /dev/shm
tmpfs                               51G   26M   51G   1% /run
tmpfs                              4.0M     0  4.0M   0% /sys/fs/cgroup
/dev/sda3                           30G  6.2G   24G  21% /
/dev/sda2                           20M  3.0M   17M  15% /boot/efi
/dev/mapper/vg_hana_shared-shared  256G   41G  215G  16% /hana/shared
/dev/mapper/vg_hana_data-data      308G   12G  297G   4% /hana/data
/dev/mapper/vg_hana_log-log        128G  8.8G  120G   7% /hana/log
/dev/mapper/vg_hana_usrsap-usrsap   32G  265M   32G   1% /usr/sap
/dev/mapper/vg_hanabackup-backup   512G  8.5G  504G   2% /hanabackup
tmpfs                               26G     0   26G   0% /run/user/174
tmpfs                               26G     0   26G   0% /run/user/900
tmpfs                               26G     0   26G   0% /run/user/0
tmpfs                               26G     0   26G   0% /run/user/1000

  4. Prüfen Sie den Status des neuen Clusters. Geben Sie dazu den für Ihr Betriebssystem spezifischen Statusbefehl ein:

    crm status

    Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen. Darin werden die VM-Instanzen der primären und sekundären SAP HANA-Systeme sowie die Mehrheit der Maker-Instanz gestartet. example-ha-vm1 ist die aktive primäre Instanz.

    example-ha-vm1:~ # crm status
Cluster Summary:
  * Stack: corosync
  * Current DC: example-ha-vm1 (version 2.1.2+20211124.ada5c3b36-150400.4.9.2-2.1.2+20211124.ada5c3b36) - partition with quorum
  * Last updated: Sat Jul 15 19:42:56 2023
  * Last change:  Sat Jul 15 19:42:21 2023 by root via crm_attribute on example-ha-vm1
  * 7 nodes configured
  * 23 resource instances configured

Node List:
  * Online: [ example-ha-mj example-ha-vm1 example-ha-vm1w1 example-ha-vm1w2 example-ha-vm2 example-ha-vm2w1 example-ha-vm2w2 ]

Full List of Resources:
  * STONITH-example-ha-vm1  (stonith:external/gcpstonith):   Started example-ha-mj
  * STONITH-example-ha-vm2        (stonith:external/gcpstonith):   Started example-ha-vm1
  * STONITH-example-ha-mjw2     (stonith:external/gcpstonith):   Started example-ha-vm1w1
  * STONITH-example-ha-vm1w1        (stonith:external/gcpstonith):   Started example-ha-vm1w2
  * STONITH-example-ha-vm2w1      (stonith:external/gcpstonith):   Started example-ha-vm2
  * STONITH-example-ha-vm1w2        (stonith:external/gcpstonith):   Started example-ha-vm2w1
  * STONITH-example-ha-vm2w2      (stonith:external/gcpstonith):   Started example-ha-mj
  * Resource Group: g-primary:
    * rsc_vip_int-primary       (ocf::heartbeat:IPaddr2):        Started example-ha-vm1
    * rsc_vip_hc-primary        (ocf::heartbeat:anything):       Started example-ha-vm1
  * Clone Set: cln_SAPHanaTopology_HA1_HDB00 [rsc_SAPHanaTopology_HA1_HDB00]:
    * Started: [ example-ha-vm1 example-ha-vm1w1 example-ha-vm1w2 example-ha-vm2 example-ha-vm2w1 example-ha-vm2w2 ]
    * Stopped: [ example-ha-mj ]
  * Clone Set: msl_SAPHana_HA1_HDB00 [rsc_SAPHana_HA1_HDB00] (promotable):
    * Masters: [ example-ha-vm1 ]
    * Slaves: [ example-ha-vm1w1 example-ha-vm1w2 example-ha-vm2 example-ha-vm2w1 example-ha-vm2w2 ]
    * Stopped: [ example-ha-mj ]

  5. Wechseln Sie zum SAP-Administrator. Ersetzen Sie hierfür im folgenden Befehl SID_LC durch den Wert sap_hana_sid, den Sie in der Datei sap_hana_ha.tf angegeben haben: Der Wert SID_LC muss in Kleinbuchstaben geschrieben werden.

    su - SID_LCadm

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

    HDB info

Clusterkonfiguration prüfen

Nachdem der Cluster bereitgestellt wurde, müssen Sie die Parametereinstellungen des Clusters prüfen. Prüfen Sie sowohl die Einstellungen, die von Ihrer Clustersoftware angezeigt werden, als auch die Parametereinstellungen in der Clusterkonfigurationsdatei. Vergleichen Sie Ihre Einstellungen mit den Einstellungen im folgenden Beispiel, das von den in dieser Anleitung verwendeten Automatisierungsskripts erstellt wurde.

  1. Rufen Sie die Clusterressourcenkonfigurationen auf:

    crm config show

    Die in dieser Anleitung verwendeten Automatisierungsskripts erstellen die Ressourcenkonfigurationen, die im folgenden Beispiel gezeigt werden:

      node 1: example-ha-vm1 \
    attributes hana_ha1_site=example-ha-vm1 hana_ha1_gra=2.0
  node 2: example-ha-vm2 \
    attributes hana_ha1_site=example-ha-vm2 hana_ha1_gra=2.0
  node 3: example-ha-mj
  node 4: example-ha-vm1w1 \
    attributes hana_ha1_site=example-ha-vm1 hana_ha1_gra=2.0
  node 5: example-ha-vm2w1 \
    attributes hana_ha1_site=example-ha-vm2 hana_ha1_gra=2.0
  node 6: example-ha-vm1w2 \
    attributes hana_ha1_site=example-ha-vm1 hana_ha1_gra=2.0
  node 7: example-ha-vm2w2 \
    attributes hana_ha1_site=example-ha-vm2 hana_ha1_gra=2.0
  primitive STONITH-example-ha-mjw2 stonith:external/gcpstonith \
    params instance_name=example-ha-mjw2 gcloud_path="/usr/bin/gcloud" logging=yes pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
    op monitor interval=300s timeout=120s \
    op start interval=0 timeout=60s \
    op stop timeout=15 interval=0s
  primitive STONITH-example-ha-vm1 stonith:external/gcpstonith \
    params instance_name=example-ha-vm1 gcloud_path="/usr/bin/gcloud" logging=yes pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
    op monitor interval=300s timeout=120s \
    op start interval=0 timeout=60s \
    op stop timeout=15 interval=0s
  primitive STONITH-example-ha-vm1w1 stonith:external/gcpstonith \
    params instance_name=example-ha-vm1w1 gcloud_path="/usr/bin/gcloud" logging=yes pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
    op monitor interval=300s timeout=120s \
    op start interval=0 timeout=60s \
    op stop timeout=15 interval=0s
  primitive STONITH-example-ha-vm1w2 stonith:external/gcpstonith \
    params instance_name=example-ha-vm1w2 gcloud_path="/usr/bin/gcloud" logging=yes pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
    op monitor interval=300s timeout=120s \
    op start interval=0 timeout=60s \
    op stop timeout=15 interval=0s
  primitive STONITH-example-ha-vm2 stonith:external/gcpstonith \
    params instance_name=example-ha-vm2 gcloud_path="/usr/bin/gcloud" logging=yes pcmk_reboot_timeout=300 pcmk_monitor_retries=4 \
    op monitor interval=300s timeout=120s \
    op start interval=0 timeout=60s \
    op stop timeout=15 interval=0s
  primitive STONITH-example-ha-vm2w1 stonith:external/gcpstonith \
    params instance_name=example-ha-vm2w1 gcloud_path="/usr/bin/gcloud" logging=yes pcmk_reboot_timeout=300 pcmk_monitor_retries=4 \
    op monitor interval=300s timeout=120s \
    op start interval=0 timeout=60s \
    op stop timeout=15 interval=0s
  primitive STONITH-example-ha-vm2w2 stonith:external/gcpstonith \
    params instance_name=example-ha-vm2w2 gcloud_path="/usr/bin/gcloud" logging=yes pcmk_reboot_timeout=300 pcmk_monitor_retries=4 \
    op monitor interval=300s timeout=120s \
    op start interval=0 timeout=60s \
    op stop timeout=15 interval=0s
  primitive rsc_SAPHanaTopology_HA1_HDB00 ocf:suse:SAPHanaTopology \
    operations $id=rsc_sap2_HA1_HDB00-operations \
    op monitor interval=10 timeout=600 \
    op start interval=0 timeout=600 \
    op stop interval=0 timeout=300 \
    params SID=HA1 InstanceNumber=00
  primitive rsc_SAPHana_HA1_HDB00 ocf:suse:SAPHanaController \
    op start interval=0 timeout=3600 \
    op stop interval=0 timeout=3600 \
    op promote interval=0 timeout=3600 \
    op demote interval=0 timeout=3600 \
    op monitor interval=60 role=Master timeout=700 \
    op monitor interval=61 role=Slave timeout=700 \
    params SID=HA1 InstanceNumber=00 PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true
  primitive rsc_vip_hc-primary anything \
    params binfile="/usr/bin/socat" cmdline_options="-U TCP-LISTEN:60000,backlog=10,fork,reuseaddr /dev/null" \
    op monitor timeout=20s interval=10s \
    op_params depth=0 \
    op start timeout=20s interval=0s \
    op stop timeout=20s interval=0s
  primitive rsc_vip_int-primary IPaddr2 \
    params ip=10.1.0.23 cidr_netmask=32 nic=eth0 \
    op monitor interval=3600s timeout=60s \
    op start timeout=20s interval=0s \
    op stop timeout=20s interval=0s
  group g-primary rsc_vip_int-primary rsc_vip_hc-primary \
    meta resource-stickiness=0
  ms msl_SAPHana_HA1_HDB00 rsc_SAPHana_HA1_HDB00 \
    meta clone-node-max=1 master-max=1 interleave=true target-role=Started interleave=true
  clone cln_SAPHanaTopology_HA1_HDB00 rsc_SAPHanaTopology_HA1_HDB00 \
    meta clone-node-max=1 target-role=Started interleave=true
  location LOC_STONITH_example-ha-vm1 STONITH-example-ha-vm1 -inf: example-ha-vm1
  location LOC_STONITH_example-ha-vm1w1 STONITH-example-ha-vm1w1 -inf: example-ha-vm1w1
  location LOC_STONITH_example-ha-vm1w2 STONITH-example-ha-vm1w2 -inf: example-ha-vm1w2
  location LOC_STONITH_example-ha-vm2 STONITH-example-ha-vm2 -inf: example-ha-vm2
  location LOC_STONITH_example-ha-vm2w1 STONITH-example-ha-vm2w1 -inf: example-ha-vm2w1
  location LOC_STONITH_example-ha-vm2w2 STONITH-example-ha-vm2w2 -inf: example-ha-vm2w2
  location SAPHanaCon_not_on_mm msl_SAPHana_HA1_HDB00 -inf: example-ha-mj
  location SAPHanaTop_not_on_mm cln_SAPHanaTopology_HA1_HDB00 -inf: example-ha-mj
  colocation col_saphana_ip_HA1_HDB00 4000: g-primary:Started msl_SAPHana_HA1_HDB00:Master
  order ord_SAPHana_HA1_HDB00 Optional: cln_SAPHanaTopology_HA1_HDB00 msl_SAPHana_HA1_HDB00
  property SAPHanaSR: \
    hana_ha1_glob_mts=true \
    hana_ha1_site_srHook_example-ha-vm2=SOK \
    hana_ha1_site_lss_example-ha-vm1=4 \
    hana_ha1_site_srr_example-ha-vm1=P \
    hana_ha1_site_lss_example-ha-vm2=4 \
    hana_ha1_site_srr_example-ha-vm2=S \
    hana_ha1_glob_srmode=syncmem \
    hana_ha1_glob_upd=ok \
    hana_ha1_site_mns_example-ha-vm1=example-ha-vm1 \
    hana_ha1_site_mns_example-ha-vm2=example-ha-vm2 \
    hana_ha1_site_lpt_example-ha-vm2=30 \
    hana_ha1_site_srHook_example-ha-vm1=PRIM \
    hana_ha1_site_lpt_example-ha-vm1=1689450463 \
    hana_ha1_glob_sync_state=SOK \
    hana_ha1_glob_prim=example-ha-vm1
  property cib-bootstrap-options: \
    have-watchdog=false \
    dc-version="2.1.2+20211124.ada5c3b36-150400.4.9.2-2.1.2+20211124.ada5c3b36" \
    cluster-infrastructure=corosync \
    cluster-name=hacluster \
    maintenance-mode=false \
    stonith-timeout=300s \
    stonith-enabled=true \
    concurrent-fencing=true
  rsc_defaults build-resource-defaults: \
    resource-stickiness=1000 \
    migration-threshold=5000
  op_defaults op-options: \
    timeout=600

  2. Rufen Sie die Clusterkonfigurationsdatei corosync.conf auf:

    cat /etc/corosync/corosync.conf

    Die in dieser Anleitung verwendeten Automatisierungsskripts geben Parametereinstellungen in der Datei corosync.conf an, wie im folgenden Beispiel gezeigt:

      totem {
    version: 2
    secauth: off
    crypto_hash: sha1
    crypto_cipher: aes256
    cluster_name: hacluster
    clear_node_high_bit: yes
    token: 20000
    token_retransmits_before_loss_const: 10
    join: 60
    max_messages: 20
    transport: udpu
    interface {
      ringnumber: 0
      bindnetaddr: "10.1.0.7"
      mcastport: 5405
      ttl: 1
    }
  }
  logging {
    fileline: off
    to_stderr: no
    to_logfile: no
    logfile: /var/log/cluster/corosync.log
    to_syslog: yes
    debug: off
    timestamp: on
    logger_subsys {
      subsys: QUORUM
      debug: off
    }
  }
  quorum {
    provider: corosync_votequorum

  }
  nodelist {
    node {
      ring0_addr: example-ha-vm1
      nodeid: 1
    }
    node {
      ring0_addr: example-ha-vm2
      nodeid: 2
    }
    node {
      ring0_addr: example-ha-mj
      nodeid: 3
     }
    node {
      ring0_addr: example-ha-vm1w1
      nodeid: 4
     }
    node {
      ring0_addr: example-ha-vm2w1
      nodeid: 5
     }
    node {
      ring0_addr: example-ha-vm1w2
      nodeid: 6
     }
    node {
      ring0_addr: example-ha-vm2w2
      nodeid: 7
     }
  }

Load-Balancer und Zustand der Instanzgruppen prüfen

Prüfen Sie den Load-Balancer und die Instanzgruppen in der Google Cloud Console, um festzustellen, ob der Load-Balancer und die Systemdiagnose ordnungsgemäß eingerichtet wurden:

  1. Öffnen Sie in der Google Cloud Console die Seite Load-Balancing.

    Zu Cloud Load Balancing

  2. Prüfen Sie in der Liste der Load-Balancer, ob ein Load-Balancer für Ihren HA-Cluster erstellt wurde.

  3. Prüfen Sie auf der Seite Details zum Load-Balancer im Abschnitt Backend, in der Spalte Fehlerfrei, dass eine der Instanzgruppen 1 von 1 und die andere 0 von 1. Nach einem Failover wechselt der Indikator „fehlerfreie“ 1 von 1 zur neuen aktiven Instanzgruppe.

    Zeigt die Detailseite des Load-Balancers mit der aktiven primären Instanzgruppe (1/1) und der inaktiven sekundären Instanzgruppe (0/1)

SAP HANA-System mit SAP HANA Studio prüfen

Sie können SAP HANA Cockpit oder SAP HANA Studio verwenden, um SAP HANA-Systeme in Hochverfügbarkeitsclustern zu überwachen und zu verwalten.

  1. Stellen Sie mit SAP HANA Studio eine Verbindung zum HANA-System her. Geben Sie beim Definieren der Verbindung die folgenden Werte an:

    • Geben Sie im Bereich "Specify System" (System angeben) als Hostnamen die Floating-IP-Adresse an.
    • Geben Sie im Bereich "Connection Properties" für die Authentifizierung des Datenbanknutzers den Namen des Datenbank-Supernutzers und das Passwort an, den bzw. das Sie in der Datei sap_hana_ha.tf für das Argument sap_hana_system_password angegeben haben.

    Informationen von SAP zur Installation von SAP HANA Studio finden Sie in der Installations- und Aktualisierungsanleitung von SAP HANA Studio.

  2. Nachdem SAP HANA Studio mit dem HANA-HA-System verbunden ist, rufen Sie die Systemübersicht auf. Doppelklicken Sie hierfür im linken Navigationsbereich auf den Systemnamen.

    Navigationsbereich in SAP HANA Studio

  3. Prüfen Sie auf dem Tab Übersicht unter Allgemeine Informationen Folgendes:

    • Für den Betriebsstatus wird All services started angezeigt.
    • Unter System Replication Status wird All services are active and in sync angezeigt.

    Tab "Overview" (Übersicht) in SAP HANA Studio

  4. Klicken Sie zur Überprüfung des Replikationsmodus unter Allgemeine Informationen auf den Link Systemreplikationsstatus. Die synchrone Replikation wird von SYNCMEM in der Spalte REPLICATION_MODE auf dem Tab Systemreplikation angegeben.

    Tab "System Replication Status" in SAP HANA Studio

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.

Failover-Test durchführen

Nachdem Sie überprüft haben, ob das SAP HANA-System erfolgreich bereitgestellt wurde, müssen Sie die Failover-Funktion testen.

In der folgenden Anleitung wird mit dem Befehl ip link set eth0 down die Netzwerkschnittstelle offline geschaltet. Dieser Befehl validiert sowohl das Failover als auch das Fencing.

Führen Sie die folgenden Schritte aus, um einen Failover-Test durchzuführen:

  1. Stellen Sie in Ihrer primären SAP HANA-Instanz über SSH eine Verbindung zum Masterknoten her. Sie können eine Verbindung auf der Seite VM-Instanzen von Compute Engine herstellen, indem Sie für jede VM-Instanz auf die Schaltfläche "SSH" klicken oder Ihre bevorzugte SSH-Methode verwenden.

  2. Geben Sie bei der Eingabeaufforderung den folgenden Befehl ein:

    ip link set eth0 down

    Der Befehl ip link set eth0 down löst ein Failover aus, da die Kommunikation mit der primären SAP HANA-Instanz unterbrochen wird.

  3. Stellen Sie eine SSH-Verbindung zu einem anderen Knoten im Cluster her und wechseln Sie zum Root-Nutzer.

  4. Bestätigen Sie, dass Ihre primäre SAP HANA-Instanz nun auf der VM aktiv ist, auf der sich zuvor die sekundäre Instanz befand. Führen Sie dazu den folgenden Befehl aus:

    crm status

    Da im Cluster der automatische Neustart aktiviert ist, wird die angehaltene Instanz neu gestartet und übernimmt dann die Rolle der sekundären Instanz. Das folgende Beispiel zeigt, dass die Rollen der einzelnen SAP HANA-Instanzen gewechselt wurden:

    example-ha-vm2:~ # crm status
Cluster Summary:
  * Stack: corosync
  * Current DC: example-ha-vm2 (version 2.1.2+20211124.ada5c3b36-150400.4.9.2-2.1.2+20211124.ada5c3b36) - partition with quorum
  * Last updated: Mon Jul 17 19:47:11 2023
  * Last change:  Mon Jul 17 19:46:56 2023 by root via crm_attribute on example-ha-vm2
  * 7 nodes configured
  * 23 resource instances configured

Node List:
  * Online: [ example-ha-mj example-ha-vm1 example-ha-vm1w1 example-ha-vm1w2 example-ha-vm2 example-ha-vm2w1 example-ha-vm2w2 ]

Full List of Resources:
  * STONITH-example-ha-vm1      (stonith:external/gcpstonith):   Started example-ha-mj
  * STONITH-example-ha-vm2      (stonith:external/gcpstonith):   Started example-ha-vm1w1
  * STONITH-example-ha-mjw2     (stonith:external/gcpstonith):   Started example-ha-vm1w1
  * STONITH-example-ha-vm1w1    (stonith:external/gcpstonith):   Started example-ha-vm1w2
  * STONITH-example-ha-vm2w1    (stonith:external/gcpstonith):   Started example-ha-vm2
  * STONITH-example-ha-vm1w2    (stonith:external/gcpstonith):   Started example-ha-vm2w1
  * STONITH-example-ha-vm2w2    (stonith:external/gcpstonith):   Started example-ha-mj
  * Resource Group: g-primary:
    * rsc_vip_int-primary       (ocf::heartbeat:IPaddr2):        Started example-ha-vm2
    * rsc_vip_hc-primary        (ocf::heartbeat:anything):       Started example-ha-vm2
  * Clone Set: cln_SAPHanaTopology_HA1_HDB00 [rsc_SAPHanaTopology_HA1_HDB00]:
    * Started: [ example-ha-vm1 example-ha-vm1w1 example-ha-vm1w2 example-ha-vm2 example-ha-vm2w1 example-ha-vm2w2 ]
    * Stopped: [ example-ha-mj ]
  * Clone Set: msl_SAPHana_HA1_HDB00 [rsc_SAPHana_HA1_HDB00] (promotable):
    * Masters: [ example-ha-vm2 ]
    * Slaves: [ example-ha-vm1 example-ha-vm1w1 example-ha-vm1w2 example-ha-vm2w1 example-ha-vm2w2 ]
    * Stopped: [ example-ha-mj ]

  5. Prüfen Sie in der Google Cloud Console auf der Seite Details zum Load-Balancer, ob in der neuen aktiven primären Instanz unter Fehlerfrei der Wert 1 von 1 angezeigt wird. Aktualisieren Sie gegebenenfalls die Seite.

    Zu Cloud Load Balancing

    Sehen Sie sich zur Veranschaulichung das folgende Bild an:

    Zeigt die Detailseite des Load-Balancers mit der Instanz „ig-example-ha-vm2“, für die in der Spalte „Fehlerfrei“ der Wert „1/1“ angezeigt wird

  6. Überprüfen Sie in SAP HANA Studio, ob die Systemverbindung noch immer besteht. Klicken Sie hierfür im Navigationsbereich doppelt auf den Systemeintrag, um die Systeminformationen zu aktualisieren.

  7. Klicken Sie auf den Link System Replication Status (Systemreplikationsstatus), um zu prüfen, ob der primäre und der sekundäre Host die VMs gewechselt haben und aktiv sind.

    Tab "System Replication Status" in SAP HANA Studio

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

Nachdem Ihre Infrastruktur bereitgestellt wurde und das SAP HANA-System installiert ist, 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.

Mit SAP HANA verbinden

Da in dieser Anleitung keine externe IP-Adresse für SAP HANA verwendet wird, können Sie nur über die Bastion-Instanz mit SSH oder über den Windows-Server mit SAP HANA Studio eine Verbindung zu den SAP HANA-Instanzen 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.

HANA Aktiv/Aktiv konfigurieren (Lesezugriff aktiviert)

Ab SAP HANA 2.0 SPS1 können Sie HANA Aktiv/Aktiv (Lesezugriff aktiviert) in einem Pacemaker-Cluster konfigurieren. Eine Anleitung finden Sie unter HANA Aktiv/Aktiv (Lesezugriff aktiviert) in einem SUSE Pacemaker-Cluster konfigurieren.

Aufgaben nach dem Deployment ausführen

Bevor Sie Ihre SAP HANA-Instanz verwenden, sollten Sie nach der Bereitstellung diese Schritte ausführen: Weitere Informationen finden Sie in der Installations- und Aktualisierungsanleitung für SAP HANA.

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

  2. Aktualisieren Sie die SAP HANA-Software mit den neuesten Patches.

  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.

  4. Installieren Sie ggf. zusätzliche Komponenten wie AFLs (Application Function Libraries) oder SDA (Smart Data Access).

  5. Konfigurieren und sichern Sie Ihre neue SAP HANA-Datenbank. Weitere Informationen finden Sie in der Betriebsanleitung für SAP HANA.

SAP HANA-Arbeitslast bewerten

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

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

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

Fehlerbehebung

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

Support kontaktieren

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

Nächste Schritte