Terraform: Konfigurationsleitfaden für SAP HANA-Hochverfügbarkeitscluster

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

In diesem Leitfaden wird beschrieben, wie Sie die Bereitstellung von SAP HANA in einem RHEL-Cluster (Red Hat Enterprise Linux) oder einem SLES-Cluster (SUSE Linux Enterprise Server) für Hochverfügbarkeit (High Availability, HA) mit internem TCP/UDP-Load-Balancing automatisieren, um die virtuelle IP-Adresse zu verwalten.

In diesem Leitfaden wird Terraform verwendet, um zwei virtuelle Compute Engine-Maschinen (VMs), zwei SAP HANA-Systeme mit vertikaler Skalierung, eine virtuelle IP-Adresse (VIP) mit interner TCP/UDP-Load-Balancer-Implementierung und einen betriebssystembasierten HA-Cluster bereitzustellen – alles gemäß den Best Practices von Google Cloud, SAP und dem Betriebssystemanbieter.

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.

Überblick über einen Linux-Hochverfügbarkeitscluster für ein vertikal skalierbares SAP HANA-System mit einem Knoten

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
  • In RHEL-HA-Clustern:
    • Das Red Hat-Hochverfügbarkeitsmuster
    • Der Red Hat-Ressourcen-Agent und die Fencing-Pakete
  • In SLES-HA-Clustern:
    • 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 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 Monitoring-Agent von Google 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.

Für HA-Cluster für SAP HANA sind mindestens zwei Firewallregeln erforderlich. Mit einer Regel kann die Compute Engine-Systemdiagnose den Status der Clusterknoten prüfen und mit der anderen wird die Kommunikation zwischen den Clusterknoten ermöglicht.

Wenn Sie kein freigegebenes VPC-Netzwerk verwenden, müssen Sie die Firewallregel für die Kommunikation zwischen den Knoten erstellen, jedoch nicht für die Systemdiagnosen. Die Terraform-Konfigurationsdatei erstellt die Firewallregel für die Systemdiagnosen, die Sie bei Bedarf nach Abschluss der Bereitstellung ändern können.

Wenn Sie ein freigegebenes VPC-Netzwerk verwenden, muss ein Netzwerkadministrator beide Firewallregeln im Hostprojekt erstellen.

Sie können auch eine Firewallregel erstellen, um externen Zugriff auf bestimmte Ports zuzulassen oder den 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.
  • SSH-Verbindungen zu Ihrer VM-Instanz, einschließlich SSH-in-Browser.
  • Verbindung zu Ihrer VM über ein Drittanbieter-Tool unter Linux. Erstellen Sie eine Regel, die dem Tool den Zugriff über Ihre Firewall ermöglicht.

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 RHEL- oder SLES-Cluster mit zwei SAP HANA-Systemen erstellt: ein primäres SAP HANA-System mit einem Host auf einer VM-Instanz und ein SAP HANA-Standby-System auf einer anderen VM-Instanz 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.

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

    Zur Seite "Kontingente"

  2. Öffnen Sie Cloud Shell.

    Zu Cloud Shell

  3. Laden Sie die Konfigurationsdatei sap_hana_ha.tf für den SAP HANA-Hochverfügbarkeitscluster in Ihr Arbeitsverzeichnis herunter:

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

    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 DEPLOYMENT_TYPE.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.
    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.
    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-8-4-sap-ha oder sles-15-sp3-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.
    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.
    sap_hana_deployment_bucket String Wenn Sie SAP HANA automatisch auf den bereitgestellten VMs installieren möchten, geben Sie den Namen des Cloud Storage-Buckets in Ihrem Cloud-Projekt an, das die SAP HANA-Installationsdateien enthält.
    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.
    sap_hana_instance_number Ganzzahl 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.

    Geben Sie kein Passwort an, wenn Sie Secret Manager zum Speichern des Passworts SIDadm verwenden. Geben Sie stattdessen den Secret-Namen für das Argument sap_hana_sidadm_password_secret an.

    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.

    Geben Sie keinen Wert für sap_hana_sidadm_password_secret an, wenn Sie einen Wert für das Argument sap_hana_sidadm_password 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.

    Geben Sie kein Passwort an, wenn Sie das Passwort des Datenbank-Superusers mit Secret Manager speichern. Geben Sie stattdessen den Secret-Namen für das Argument sap_hana_system_password_secret an.

    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.

    Geben Sie keinen Wert für sap_hana_system_password_secret an, wenn Sie einen Wert für das Argument sap_hana_system_password 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 Ganzzahl 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 Ganzzahl 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 Ganzzahl 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 TCP/UDP-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.

    Ein Netzwerk-Tag für die ILB-Komponenten wird den Netzwerk-Tags der VM automatisch hinzugefügt.

    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.

    Folgende Beispiele zeigen eine vollständige Konfigurationsdatei, die einen Hochverfügbarkeitscluster für SAP HANA definiert. Der Cluster verwendet internes TCP/UDP-Load-Balancing zur Verwaltung der VIP.

    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.

    Klicken Sie auf RHEL oder SLES, um das Beispiel aufzurufen, das für Ihr Betriebssystem spezifisch ist. Zur Verdeutlichung werden Kommentare in der Konfigurationsdatei in den Beispielen weggelassen.

    RHEL

        # ...
        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 = "rhel-8-4-sap-ha"
        linux_image_project = "rhel-sap-cloud"
    
        primary_instance_name = "example-ha-vm1"
        primary_zone = "us-central1-a"
    
        secondary_instance_name = "example-ha-vm2"
        secondary_zone = "us-central1-c"
        # ...
        sap_hana_deployment_bucket = "my-hana-bucket"
        sap_hana_sid = "HA1"
        sap_hana_instance_number = 00
        sap_hana_sidadm_password = "TempPa55word"
        sap_hana_system_password = "TempPa55word"
        # ...
        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"
        # ...
        

    SLES

        # ...
        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-sp3-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-c"
        # ...
        sap_hana_deployment_bucket = "my-hana-bucket"
        sap_hana_sid = "HA1"
        sap_hana_instance_number = 00
        sap_hana_sidadm_password = "TempPa55word"
        sap_hana_system_password = "TempPa55word"
        # ...
        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"
        # ...
        
  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 df -h ein. Prüfen Sie, ob die Ausgabe /hana-Verzeichnisse wie etwa /hana/data enthält.

    RHEL

    [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

    SLES

    example-ha-vm1:~ # df -h
    Filesystem                        Size  Used Avail Use% Mounted on
    devtmpfs                          126G  8.0K  126G   1% /dev
    tmpfs                             189G   54M  189G   1% /dev/shm
    tmpfs                             126G   34M  126G   1% /run
    tmpfs                             126G     0  126G   0% /sys/fs/cgroup
    /dev/sda3                          30G  5.4G   25G  18% /
    /dev/sda2                          20M  2.9M   18M  15% /boot/efi
    /dev/mapper/vg_hana-shared        251G   50G  202G  20% /hana/shared
    /dev/mapper/vg_hana-sap            32G  281M   32G   1% /usr/sap
    /dev/mapper/vg_hana-data          426G  8.0G  418G   2% /hana/data
    /dev/mapper/vg_hana-log           125G  4.3G  121G   4% /hana/log
    /dev/mapper/vg_hanabackup-backup  512G  6.4G  506G   2% /hanabackup
    tmpfs                              26G     0   26G   0% /run/user/473
    tmpfs                              26G     0   26G   0% /run/user/900
    tmpfs                              26G     0   26G   0% /run/user/0
    tmpfs                              26G     0   26G   0% /run/user/1003
  4. Prüfen Sie den Status des neuen Clusters. Geben Sie dazu den für Ihr Betriebssystem spezifischen Statusbefehl ein:

    RHEL

    pcs status

    SLES

    crm status

    Die Ausgabe sollte in etwa wie das folgende Beispiel aussehen. Darin werden beide VM-Instanzen gestartet und example-ha-vm1 ist die aktive primäre Instanz:

    RHEL

    [root@example-ha-vm1 ~]# pcs status
    Cluster name: hacluster
    Cluster Summary:
      * Stack: corosync
      * Current DC: example-ha-vm1 (version 2.0.3-5.el8_2.4-4b1f869f0f) - partition with quorum
      * Last updated: Wed Jul  7 23:05:11 2021
      * Last change:  Wed Jul  7 23:04:43 2021 by root via crm_attribute on example-ha-vm2
      * 2 nodes configured
      * 8 resource instances configured
    
    Node List:
      * Online: [ example-ha-vm1 example-ha-vm2 ]
    
    Full List of Resources:
      * STONITH-example-ha-vm1      (stonith:fence_gce):    Started example-ha-vm2
      * STONITH-example-ha-vm2      (stonith:fence_gce):    Started example-ha-vm1
      * Resource Group: g-primary:
        * rsc_healthcheck_HA1       (service:haproxy):      Started example-ha-vm2
        * rsc_vip_HA1_00    (ocf::heartbeat:IPaddr2):       Started example-ha-vm2
      * Clone Set: SAPHanaTopology_HA1_00-clone [SAPHanaTopology_HA1_00]:
        * Started: [ example-ha-vm1 example-ha-vm2 ]
      * Clone Set: SAPHana_HA1_00-clone [SAPHana_HA1_00] (promotable):
        * Masters: [ example-ha-vm2 ]
        * Slaves: [ example-ha-vm1 ]
    
    Failed Resource Actions:
      * rsc_healthcheck_HA1_start_0 on example-ha-vm1 'error' (1): call=29, status='complete', exitreason='', last-rc-change='2021-07-07 21:07:35Z', queued=0ms, exec=2097ms
      * SAPHana_HA1_00_monitor_61000 on example-ha-vm1 'not running' (7): call=44, status='complete', exitreason='', last-rc-change='2021-07-07 21:09:49Z', queued=0ms, exec=0ms
    
    Daemon Status:
      corosync: active/enabled
      pacemaker: active/enabled
      pcsd: active/enabled

    SLES

    example-ha-vm1:~ # crm status
    Cluster Summary:
      * Stack: corosync
      * Current DC: example-ha-vm1 (version 2.0.4+20200616.2deceaa3a-3.9.1-2.0.4+20200616.2deceaa3a) - partition with quorum
      * Last updated: Wed Jul  7 22:57:59 2021
      * Last change:  Wed Jul  7 22:57:03 2021 by root via crm_attribute on example-ha-vm1
      * 2 nodes configured
      * 8 resource instances configured
    
    Node List:
      * Online: [ example-ha-vm1 example-ha-vm2 ]
    
    Full List of Resources:
      * STONITH-example-ha-vm1      (stonith:external/gcpstonith):   Started example-ha-vm2
      * STONITH-example-ha-vm2      (stonith:external/gcpstonith):   Started example-ha-vm1
      * 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-vm2 ]
      * Clone Set: msl_SAPHana_HA1_HDB00 [rsc_SAPHana_HA1_HDB00] (promotable):
        * Masters: [ example-ha-vm1 ]
        * Slaves: [ example-ha-vm2 ]
  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

Prüfen Sie die Parametereinstellungen des Clusters. 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 in den Beispielen unten, die von den in dieser Anleitung verwendeten Automatisierungsskripts erstellt wurden.

Klicken Sie auf den Tab für Ihr Betriebssystem.

RHEL

  1. Rufen Sie die Clusterressourcenkonfigurationen auf:

    pcs config show

    Das folgende Beispiel zeigt die Ressourcenkonfigurationen, die von den Automatisierungsskripts in RHEL 8.1 und höher erstellt werden.

    Wenn Sie RHEL 7.7 oder eine frühere Version ausführen, enthält die Ressourcendefinition Clone: SAPHana_HA1_00-clone nicht Meta Attrs: promotable=true.

     Cluster Name: hacluster
     Corosync Nodes:
      example-rha-vm1 example-rha-vm2
     Pacemaker Nodes:
      example-rha-vm1 example-rha-vm2
    
     Resources:
      Group: g-primary
       Resource: rsc_healthcheck_HA1 (class=service type=haproxy)
        Operations: monitor interval=10s timeout=20s (rsc_healthcheck_HA1-monitor-interval-10s)
                    start interval=0s timeout=100 (rsc_healthcheck_HA1-start-interval-0s)
                    stop interval=0s timeout=100 (rsc_healthcheck_HA1-stop-interval-0s)
       Resource: rsc_vip_HA1_00 (class=ocf provider=heartbeat type=IPaddr2)
        Attributes: cidr_netmask=32 ip=10.128.15.100 nic=eth0
        Operations: monitor interval=3600s timeout=60s (rsc_vip_HA1_00-monitor-interval-3600s)
                    start interval=0s timeout=20s (rsc_vip_HA1_00-start-interval-0s)
                    stop interval=0s timeout=20s (rsc_vip_HA1_00-stop-interval-0s)
      Clone: SAPHanaTopology_HA1_00-clone
       Meta Attrs: clone-max=2 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)
                    reload interval=0s timeout=5 (SAPHanaTopology_HA1_00-reload-interval-0s)
                    start interval=0s timeout=600 (SAPHanaTopology_HA1_00-start-interval-0s)
                    stop interval=0s timeout=300 (SAPHanaTopology_HA1_00-stop-interval-0s)
      Clone: SAPHana_HA1_00-clone
       Meta Attrs: promotable=true
       Resource: SAPHana_HA1_00 (class=ocf provider=heartbeat type=SAPHana)
        Attributes: AUTOMATED_REGISTER=true DUPLICATE_PRIMARY_TIMEOUT=7200 InstanceNumber=00 PREFER_SITE_TAKEOVER=true SID=HA1
        Meta Attrs: clone-max=2 clone-node-max=1 interleave=true notify=true
        Operations: demote interval=0s timeout=3600 (SAPHana_HA1_00-demote-interval-0s)
                    methods interval=0s timeout=5 (SAPHana_HA1_00-methods-interval-0s)
                    monitor interval=61 role=Slave timeout=700 (SAPHana_HA1_00-monitor-interval-61)
                    monitor interval=59 role=Master timeout=700 (SAPHana_HA1_00-monitor-interval-59)
                    promote interval=0s timeout=3600 (SAPHana_HA1_00-promote-interval-0s)
                    reload interval=0s timeout=5 (SAPHana_HA1_00-reload-interval-0s)
                    start interval=0s timeout=3600 (SAPHana_HA1_00-start-interval-0s)
                    stop interval=0s timeout=3600 (SAPHana_HA1_00-stop-interval-0s)
    
     Stonith Devices:
      Resource: STONITH-example-rha-vm1 (class=stonith type=fence_gce)
       Attributes: pcmk_delay_max=30 pcmk_monitor_retries=4 pcmk_reboot_timeout=300 port=example-rha-vm1 project=sap-certification-env zone=us-central1-a
       Operations: monitor interval=300s timeout=120s (STONITH-example-rha-vm1-monitor-interval-300s)
                   start interval=0 timeout=60s (STONITH-example-rha-vm1-start-interval-0)
      Resource: STONITH-example-rha-vm2 (class=stonith type=fence_gce)
       Attributes: pcmk_monitor_retries=4 pcmk_reboot_timeout=300 port=example-rha-vm2 project=sap-certification-env zone=us-central1-c
       Operations: monitor interval=300s timeout=120s (STONITH-example-rha-vm2-monitor-interval-300s)
                   start interval=0 timeout=60s (STONITH-example-rha-vm2-start-interval-0)
     Fencing Levels:
    
     Location Constraints:
       Resource: STONITH-example-rha-vm1
         Disabled on: example-rha-vm1 (score:-INFINITY) (id:location-STONITH-example-rha-vm1-example-rha-vm1--INFINITY)
       Resource: STONITH-example-rha-vm2
         Disabled on: example-rha-vm2 (score:-INFINITY) (id:location-STONITH-example-rha-vm2-example-rha-vm2--INFINITY)
     Ordering Constraints:
       start SAPHanaTopology_HA1_00-clone then start SAPHana_HA1_00-clone (kind:Mandatory) (non-symmetrical) (id:order-SAPHanaTopology_HA1_00-clone-SAPHana_HA1_00-clone-mandatory)
     Colocation Constraints:
       g-primary with SAPHana_HA1_00-clone (score:4000) (rsc-role:Started) (with-rsc-role:Master) (id:colocation-g-primary-SAPHana_HA1_00-clone-4000)
     Ticket Constraints:
    
     Alerts:
      No alerts defined
    
     Resources Defaults:
      migration-threshold=5000
      resource-stickiness=1000
     Operations Defaults:
      timeout=600s
    
     Cluster Properties:
      cluster-infrastructure: corosync
      cluster-name: hacluster
      dc-version: 2.0.2-3.el8_1.2-744a30d655
      have-watchdog: false
      stonith-enabled: true
      stonith-timeout: 300s
    
     Quorum:
       Options:
    
  2. Rufen Sie die Clusterkonfigurationsdatei corosync.conf auf:

    cat /etc/corosync/corosync.conf

    Das folgende Beispiel zeigt die Parameter, die die Automatisierungsskripts für RHEL 8.1 und höher festgelegt haben.

    Wenn Sie RHEL 7.7 oder früher verwenden, ist der Wert von transport: udpu, nicht knet:

     totem {
         version: 2
         cluster_name: hacluster
         transport: knet
         join: 60
         max_messages: 20
         token: 20000
         token_retransmits_before_loss_const: 10
         crypto_cipher: aes256
         crypto_hash: sha256
     }
    
     nodelist {
         node {
             ring0_addr: example-rha-vm1
             name: example-rha-vm1
             nodeid: 1
         }
    
         node {
             ring0_addr: example-rha-vm2
             name: example-rha-vm2
             nodeid: 2
         }
     }
    
     quorum {
         provider: corosync_votequorum
         two_node: 1
     }
    
     logging {
         to_logfile: yes
         logfile: /var/log/cluster/corosync.log
         to_syslog: yes
         timestamp: on
     }
    

SLES

  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_op_mode=logreplay lpa_ha1_lpt=1635380335 hana_ha1_srmode=syncmem hana_ha1_vhost=example-ha-vm1 hana_ha1_remoteHost=example-ha-vm2 hana_ha1_site=example-ha-vm1
     node 2: example-ha-vm2 \
             attributes lpa_ha1_lpt=30 hana_ha1_op_mode=logreplay hana_ha1_vhost=example-ha-vm2 hana_ha1_site=example-ha-vm2 hana_ha1_srmode=syncmem hana_ha1_remoteHost=example-ha-vm1
     primitive STONITH-example-ha-vm1 stonith:external/gcpstonith \
             op monitor interval=300s timeout=120s \
             op start interval=0 timeout=60s \
             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
     primitive STONITH-example-ha-vm2 stonith:external/gcpstonith \
             op monitor interval=300s timeout=120s \
             op start interval=0 timeout=60s \
             params instance_name=example-ha-vm2 gcloud_path="/usr/bin/gcloud" logging=yes pcmk_reboot_timeout=300 pcmk_monitor_retries=4
     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:SAPHana \
             operations $id=rsc_sap_HA1_HDB00-operations \
             op start interval=0 timeout=3600 \
             op stop interval=0 timeout=3600 \
             op promote interval=0 timeout=3600 \
             op demote interval=0 timeout=3600 \
             op monitor interval=60 role=Master timeout=700 \
             op monitor interval=61 role=Slave timeout=700 \
             params SID=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
     primitive rsc_vip_int-primary IPaddr2 \
             params ip=10.128.15.101 cidr_netmask=32 nic=eth0 \
             op monitor interval=3600s timeout=60s
     group g-primary rsc_vip_int-primary rsc_vip_hc-primary
     ms msl_SAPHana_HA1_HDB00 rsc_SAPHana_HA1_HDB00 \
             meta notify=true clone-max=2 clone-node-max=1 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-vm2 STONITH-example-ha-vm2 -inf: example-ha-vm2
     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 cib-bootstrap-options: \
             have-watchdog=false \
             dc-version="1.1.24+20210811.f5abda0ee-3.18.1-1.1.24+20210811.f5abda0ee" \
             cluster-infrastructure=corosync \
             cluster-name=hacluster \
             maintenance-mode=false \
             stonith-timeout=300s \
             stonith-enabled=true
     rsc_defaults rsc-options: \
             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.128.1.63
         mcastport: 5405
         ttl: 1
       }
     }
     logging {
       fileline: off
       to_stderr: no
       to_logfile: no
       logfile: /var/log/cluster/corosync.log
       to_syslog: yes
       debug: off
       timestamp: on
       logger_subsys {
         subsys: QUORUM
         debug: off
       }
     }
     nodelist {
       node {
         ring0_addr: example-ha-vm1
         nodeid: 1
       }
       node {
         ring0_addr: example-ha-vm2
         nodeid: 2
       }
     }
     quorum {
       provider: corosync_votequorum
       expected_votes: 2
       two_node: 1
     }
    

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 die Seite „Load-Balancing“ in der Google Cloud Console.

    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 in der Spalte Fehlerfrei unter Instanzgruppe im Abschnitt Back-End, ob eine der Instanzgruppen „1/1“ und die andere „0/1“ anzeigt. Nach einem Failover wechselt die fehlerfreie Anzeige „1/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 "Overview" unter "General Information" Folgendes:

    • Für den "Operational Status" (Betriebsstatus) wird "All services started" (Alle Dienste gestartet) 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 "General Information" (Allgemeine Informationen) auf den Link System Replication Status (Systemreplikationsstatus). Die synchrone Replikation wird von SYNCMEM in der Spalte REPLICATION_MODE auf dem Tab "System Replication" (Systemreplikation) angegeben.

    Tab "System Replication Status" in SAP HANA Studio

Wenn einer der Überprüfungsschritte auf eine fehlgeschlagene Installation hindeutet, gehen Sie so vor:

  1. Beheben Sie die Fehler.

  2. Cloud Shell öffnen

    Zu Cloud Shell

  3. Wechseln Sie zu dem Verzeichnis, das die Terraform-Konfigurationsdatei enthält, um SAP HANA bereitzustellen.

  4. Löschen Sie das Deployment:

    terraform destroy

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

  5. Erstellen Sie die Instanzen neu, wie im vorherigen Abschnitt beschrieben.

Failover-Test durchführen

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

  1. Stellen Sie eine SSH-Verbindung zur primären 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. Geben Sie bei der Eingabeaufforderung den folgenden Befehl ein:

    sudo ip link set eth0 down

    Der Befehl ip link set eth0 down löst ein Failover aus, da die Kommunikation mit dem primären Host unterbrochen wird.

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

  4. Bestätigen Sie, dass 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 beendete Host neu gestartet und übernimmt dann die Rolle des sekundären Hosts.

    RHEL

    pcs status

    SLES

    crm status

    Die folgenden Beispiele zeigen, dass die Rollen bei allen Hosts gewechselt wurden.

    RHEL

    [root@example-ha-vm1 ~]# pcs status
    Cluster name: hacluster
    Cluster Summary:
      * Stack: corosync
      * Current DC: example-ha-vm1 (version 2.0.3-5.el8_2.3-4b1f869f0f) - partition with quorum
      * Last updated: Fri Mar 19 21:22:07 2021
      * Last change:  Fri Mar 19 21:21:28 2021 by root via crm_attribute on example-ha-vm2
      * 2 nodes configured
      * 8 resource instances configured
    
    Node List:
      * Online: [ example-ha-vm1 example-ha-vm2 ]
    
    Full List of Resources:
      * STONITH-example-ha-vm1  (stonith:fence_gce):    Started example-ha-vm2
      * STONITH-example-ha-vm2  (stonith:fence_gce):    Started example-ha-vm1
      * Resource Group: g-primary:
        * rsc_healthcheck_HA1   (service:haproxy):  Started example-ha-vm2
        * rsc_vip_HA1_00    (ocf::heartbeat:IPaddr2):   Started example-ha-vm2
      * Clone Set: SAPHanaTopology_HA1_00-clone [SAPHanaTopology_HA1_00]:
        * Started: [ example-ha-vm1 example-ha-vm2 ]
      * Clone Set: SAPHana_HA1_00-clone [SAPHana_HA1_00] (promotable):
        * Masters: [ example-ha-vm2 ]
        * Slaves: [ example-ha-vm1 ]
    

    SLES

    example-ha-vm2:~ #
    Cluster Summary:
      * Stack: corosync
      * Current DC: example-ha-vm2 (version 2.0.4+20200616.2deceaa3a-3.9.1-2.0.4+20200616.2deceaa3a) - partition with quorum
      * Last updated: Thu Jul  8 17:33:44 2021
      * Last change:  Thu Jul  8 17:33:07 2021 by root via crm_attribute on example-ha-vm2
      * 2 nodes configured
      * 8 resource instances configured
    
    Node List:
      * Online: [ example-ha-vm1 example-ha-vm2 ]
    
    Full List of Resources:
      * STONITH-example-ha-vm1      (stonith:external/gcpstonith):   Started example-ha-vm2
      * STONITH-example-ha-vm2      (stonith:external/gcpstonith):   Started example-ha-vm1
      * 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-vm2 ]
      * Clone Set: msl_SAPHana_HA1_HDB00 [rsc_SAPHana_HA1_HDB00] (promotable):
        * Masters: [ example-ha-vm2 ]
        * Slaves: [ example-ha-vm1 ]
  5. Prüfen Sie auf der Seite Details zum Load-Balancer, ob in der Spalte Healthy für die neue aktive primäre Instanz der Wert „1/1“ angezeigt wird. Aktualisieren Sie gegebenenfalls die Seite.

    Zu Cloud Load Balancing

    Beispiel:

    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

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.

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:

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

Manuelle Schritte: SAP HANA Fast Restart aktivieren

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:

mount tmpfsSID_UC0 -t tmpfs -o mpol=prefer:0 /hana/tmpfs0/SID_UC
mount tmpfsSID_UC1 -t tmpfs -o mpol=prefer:1 /hana/tmpfs1/SID_UC
mount tmpfsSID_UC2 -t tmpfs -o mpol=prefer:2 /hana/tmpfs2/SID_UC
mount tmpfsSID_UC3 -t tmpfs -o mpol=prefer:3 /hana/tmpfs3/SID_UC
/etc/fstab aktualisieren

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

tmpfsSID_UC0 /hana/tmpfs0/SID_UC tmpfs rw,relatime,mpol=prefer:0
tmpfsSID_UC1 /hana/tmpfs1/SID_UC tmpfs rw,relatime,mpol=prefer:1
tmpfsSID_UC1 /hana/tmpfs2/SID_UC tmpfs rw,relatime,mpol=prefer:2
tmpfsSID_UC1 /hana/tmpfs3/SID_UC 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 tmpfsSID_UC0 -t tmpfs -o mpol=prefer:0,size=250G /hana/tmpfs0/SID_UC

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_UC;/hana/tmpfs1/SID_UC;/hana/tmpfs2/SID_UC;/hana/tmpfs3/SID_UC

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.

Automatisierungsskript: SAP HANA Fast Restart aktivieren

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

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 Skript 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 Skript 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 Skript mit dem Namen eines Secrets in Secret Manager aus.

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

    Dabei gilt:

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

    Alternativ können Sie das Skript 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'

    Dabei gilt:

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

Google Monitoring-Agent für SAP HANA einrichten

Optional können Sie den Google Monitoring-Agent für SAP HANA einrichten, der Messwerte aus SAP HANA erfasst und an Monitoring sendet. Mit Monitoring lassen sich Dashboards für Ihre Messwerte erstellen, benutzerdefinierte Benachrichtigungen anhand von Messwertschwellen einrichten und vieles mehr.

Zum Überwachen eines Hochverfügbarkeitsclusters installieren Sie den Monitoring-Agent auf einer VM-Instanz außerhalb des Clusters. Geben Sie die Floating-IP-Adresse des Clusters als die IP-Adresse der zu überwachenden Hostinstanz an.

Weitere Informationen zum Einrichten und Konfigurieren des Google Monitoring-Agents für SAP HANA finden Sie im Nutzerhandbuch für SAP HANA – Monitoring-Agent.

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.

Aufgaben nach der Bereitstellung 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. Installieren Sie ggf. zusätzliche Komponenten wie AFLs (Application Function Libraries) oder SDA (Smart Data Access).

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

Weitere Informationen