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

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

Diese Anleitung umfasst die Schritte für Folgendes:

  • Internes TCP/UDP-Load-Balancing konfigurieren, um Traffic bei einem Ausfall umzuleiten
  • Pacemaker-Cluster unter SLES konfigurieren, um die SAP-Systeme und andere Ressourcen während eines Failovers zu verwalten

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

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

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

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

System, das in dieser Anleitung bereitgestellt wird

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

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

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

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

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

Vorbereitung

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

  • Sie oder Ihre Organisation haben ein Google Cloud-Konto. Außerdem haben Sie ein Projekt für die SAP HANA-Bereitstellung erstellt. Informationen zum Erstellen von Google Cloud-Konten und -Projekten finden Sie unter Google-Konto einrichten in der Bereitstellungsanleitung für SAP HANA.
  • Die SAP HANA-Installationsmedien sind in einem Cloud Storage-Bucket gespeichert, der in Ihrem Bereitstellungsprojekt und Ihrer Region verfügbar ist. Informationen zum Hochladen von SAP HANA-Installationsmedien in einen Cloud Storage-Bucket finden Sie in der Anleitung zur Bereitstellung von SAP HANA unter SAP HANA herunterladen.
  • Bei einem internen VPC-DNS muss der Wert der Variable VmDnsSetting in Ihren Projektmetadaten entweder GlobalOnly oder ZonalPreferred sein, damit die Knotennamen zonenübergreifend aufgelöst werden können. Die Standardeinstellung von VmDnsSetting ist ZonalOnly. Weitere Informationen finden Sie unter:

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.

So richten Sie das Netzwerk ein:

  1. Rufen Sie Cloud Shell auf.

    Zu Cloud Shell

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

    gcloud compute networks create [YOUR_NETWORK_NAME] --subnet-mode custom

    [YOUR_NETWORK_NAME] ist der Name des neuen Netzwerks. Der Netzwerkname darf nur Kleinbuchstaben, Ziffern und Bindestriche (-) enthalten.

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

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

    gcloud compute networks subnets create [YOUR_SUBNETWORK_NAME] \
            --network [YOUR_NETWORK_NAME] --region [YOUR_REGION] --range [YOUR_RANGE]

    Dabei gilt:

    • [YOUR_SUBNETWORK_NAME] ist das neue Subnetz.
    • [YOUR_NETWORK_NAME] ist der Name des Netzwerks, das Sie im vorherigen Schritt erstellt haben.
    • [REGION] ist die Region, in der sich das Subnetzwerk befinden soll.
    • [YOUR_RANGE] ist der im CIDR-Format angegebene IP-Adressbereich, z. B. 10.1.0.0/24. Wenn Sie mehrere Subnetzwerke erstellen möchten, weisen Sie den Subnetzwerken im Netzwerk nicht überlappende CIDR-IP-Adressbereiche zu. Beachten Sie, dass jedes Subnetzwerk und seine internen IP-Adressbereiche einer einzelnen Region zugeordnet sind.
  4. Wiederholen Sie den vorherigen Schritt, falls Sie weitere Subnetzwerke erstellen möchten.

NAT-Gateway einrichten

Wenn Sie eine oder mehrere VMs ohne öffentliche IP-Adressen erstellen möchten, müssen Sie ein NAT-Gateway erstellen, damit Ihre VMs auf das Internet zugreifen können, um den Monitoring-Agent von Google herunterzuladen.

Wenn Sie der VM eine externe öffentliche IP-Adresse zuweisen möchten, können Sie diesen Vorgang überspringen.

So erstellen Sie ein NAT-Gateway:

  1. Legen Sie eine VM an, die in dem soeben erstellten Subnetzwerk als NAT-Gateway fungieren soll:

    gcloud compute instances create [YOUR_VM_NAME] --can-ip-forward \
            --zone [YOUR_ZONE]  --image-family [YOUR_IMAGE_FAMILY] \
            --image-project [YOUR_IMAGE_PROJECT] \
            --machine-type=[YOUR_MACHINE_TYPE] --subnet [YOUR_SUBNETWORK_NAME] \
            --metadata startup-script="sysctl -w net.ipv4.ip_forward=1; iptables \
            -t nat -A POSTROUTING -o eth0 -j MASQUERADE" --tags [YOUR_VM_TAG]

    Dabei gilt:

    • [YOUR_VM_NAME] ist der Name der von Ihnen erstellten VM, die für das NAT-Gateway verwendet werden soll.
    • [YOUR_ZONE] ist die Zone, in der sich die VM befinden soll.
    • [YOUR_IMAGE_FAMILY] und [YOUR_IMAGE_PROJECT] geben das für das NAT-Gateway zu verwendende Image an.
    • [YOUR_MACHINE_TYPE] ist ein beliebiger unterstützter Maschinentyp. Wenn Sie einen hohen Netzwerktraffic erwarten, wählen Sie einen Maschinentyp mit mindestens acht virtuellen CPUs aus.
    • [YOUR_SUBNETWORK_NAME] ist der Name des Subnetzwerks, in dem sich die VM befinden soll.
    • [YOUR_VM_TAG] ist das Tag, das auf die von Ihnen erstellte VM angewendet wird. Wenn Sie diese VM auch als Bastion Host verwenden, wird dieses Tag verwendet, um die entsprechende Firewallregel nur auf diese VM anzuwenden.
  2. Erstellen Sie eine Route, die so getaggt ist, dass der Traffic nicht über das Standard-Internetgateway, sondern über die NAT-VM geleitet wird:

    gcloud compute routes create [YOUR_ROUTE_NAME] \
            --network [YOUR_NETWORK_NAME] --destination-range 0.0.0.0/0 \
            --next-hop-instance [YOUR_VM_NAME] --next-hop-instance-zone \
            [YOUR_ZONE] --tags [YOUR_TAG_NAME] --priority 800

    Dabei gilt:

    • [YOUR_ROUTE_NAME] ist der Name der Route, die Sie erstellen.
    • [YOUR_NETWORK_NAME] ist das von Ihnen erstellte Netzwerk.
    • [YOUR_VM_NAME] gibt die VM an, die Sie für Ihr NAT-Gateway verwenden.
    • [YOUR_ZONE] ist die Zone, in der sich die VM befindet.
    • [YOUR_TAG_NAME] stellt das Tag auf der Route dar, das den Verkehr durch die NAT-VM leitet.
  3. Wenn Sie die NAT-Gateway-VM auch als Bastion Host verwenden möchten, führen Sie den folgenden Befehl aus. Mit diesem Befehl wird eine Firewallregel erstellt, die eingehenden SSH-Zugriff auf diese Instanz aus dem Internet zulässt:

    gcloud compute firewall-rules create allow-ssh --network [YOUR_NETWORK_NAME] --allow tcp:22 --source-ranges 0.0.0.0/0 --target-tags "[YOUR_VM_TAG]"

    Dabei gilt:

    • [YOUR_NETWORK_NAME] ist das von Ihnen erstellte Netzwerk.
    • [YOUR_VM_TAG] stellt das Tag dar, das Sie beim Erstellen der NAT-Gateway-VM angegeben haben. Dieses Tag sorgt dafür, dass diese Firewallregel nur für die VM gilt, die das NAT-Gateway hostet, und nicht für alle VMs im Netzwerk.

Firewallregeln festlegen

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 eine Firewallregel erstellen, um externen Zugriff auf bestimmte Ports zuzulassen oder 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 anlegen, die Folgendes erlauben:

  • SAP-Standardports, die unter TCP/IP-Ports aller SAP-Produkte aufgeführt sind.
  • Verbindungen von Ihrem Computer oder dem Unternehmensnetzwerk aus zu Ihrer Compute Engine-VM-Instanz. Wenn Sie sich nicht sicher sind, welche IP-Adresse Sie verwenden sollen, wenden Sie sich an den Netzwerkadministrator Ihres Unternehmens.
  • Kommunikation zwischen VMs, wenn z. B. Ihr Datenbankserver und Ihr Anwendungsserver auf verschiedenen VMs ausgeführt werden. Damit eine Kommunikation zwischen VMs möglich ist, müssen Sie eine Firewallregel erstellen, die aus dem Subnetzwerk stammenden Traffic zulässt.

So erstellen Sie eine Firewallregel:

Console

  1. Rufen Sie in der Cloud Console die Seite Firewallregeln auf.

    ZUR SEITE "FIREWALLREGELN"

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

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

gcloud

Erstellen Sie mit dem folgenden Befehl eine Firewallregel:

$ gcloud compute firewall-rules create firewall-name
--direction=INGRESS --priority=1000 \
--network=network-name --action=ALLOW --rules=protocol:port \
--source-ranges ip-range --target-tags=network-tags

VMs und SAP HANA bereitstellen

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

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

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

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

In der folgenden Anleitung wird Cloud Shell verwendet. Sie ist aber allgemein auf das Cloud SDK anwendbar.

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

    Zur Seite "Kontingente"

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

    Zu Cloud Shell

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

    wget https://storage.googleapis.com/sapdeploy/dm-templates/sap_hana/template.yaml
  4. Sie können die Datei template.yaml so umbenennen, dass die von ihr definierte Konfiguration im Namen erkennbar ist.

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

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

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

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

    Attribut Datentyp Beschreibung
    instanceName String Der Name der VM-Instanz, die derzeit definiert ist. Geben Sie in der primären und sekundären VM-Definition unterschiedliche Namen an. Namen dürfen nur Kleinbuchstaben, Ziffern und Bindestriche enthalten.
    instanceType String Der Typ der virtuellen Maschine in Compute Engine, auf der Sie SAP HANA ausführen müssen. Wenn Sie einen benutzerdefinierten VM-Typ benötigen, geben Sie einen vordefinierten VM-Typ mit einer Anzahl an vCPUs an, die der benötigten Anzahl am nächsten kommt, aber noch darüber liegt. Wenn die Bereitstellung abgeschlossen ist, ändern Sie die Anzahl der vCPUs und den Umfang des Arbeitsspeichers.
    zone String Die Google Cloud-Zone, in der die von Ihnen definierte VM-Instanz bereitgestellt werden soll. Geben Sie für die primäre und sekundäre VM-Definition verschiedene Zonen in derselben Region an. Die Zonen müssen sich in derselben Region befinden, die Sie für Ihr Subnetz ausgewählt haben.
    subnetwork String Name des Subnetzes, das Sie in einem vorherigen Schritt erstellt haben. Wenn das Deployment in einer freigegebenen VPC erfolgt, geben Sie diesen Wert im Format [SHAREDVPC_PROJECT]/[SUBNETWORK] an. Beispiel: myproject/network1
    linuxImage String Der Name des Linux-Betriebssystem-Images bzw. der Linux-Image-Familie, die Sie mit SAP HANA verwenden. Wenn Sie eine Image-Familie angeben möchten, ergänzen Sie den Familiennamen durch das Präfix family/. Beispiel: family/sles-15-sp1-sap Wenn Sie ein bestimmtes Image verwenden möchten, geben Sie nur dessen Namen an. Eine Liste der verfügbaren Images und Familien finden Sie in der Cloud Console auf der Seite "Images".
    linuxImageProject String Das Google Cloud-Projekt, das das zu verwendende Image enthält. Dies kann Ihr eigenes Projekt oder ein Google Cloud-Image-Projekt wie suse-sap-cloud sein. Weitere Informationen zu GCP-Image-Projekten finden Sie in der Compute Engine-Dokumentation auf der Seite "Images".
    sap_hana_deployment_bucket String Name des GCP Storage-Buckets in Ihrem Projekt, der die von Ihnen in einem vorherigen Schritt hochgeladenen SAP HANA-Installations- und Aktualisierungsdateien enthält. Alle aktualisierten Dateiversionen im Bucket werden während des Bereitstellungsprozesses auf SAP HANA angewendet.
    sap_hana_sid String Die ID des SAP HANA-Systems (SID). Die ID muss aus drei alphanumerischen Zeichen bestehen und mit einem Buchstaben beginnen. Alle Buchstaben müssen Großbuchstaben sein.
    sap_hana_instance_number Ganzzahl Instanznummer (0 bis 99) des SAP HANA-Systems. Der Standardwert ist 0.
    sap_hana_sidadm_password String Das Passwort für den Betriebssystemadministrator. Passwörter müssen mindestens acht Zeichen lang sein und mindestens einen Großbuchstaben, einen Kleinbuchstaben und eine Ziffer enthalten.
    sap_hana_system_password String Passwort für den Datenbank-Superuser. Passwörter müssen mindestens acht Zeichen lang sein und mindestens einen Großbuchstaben, einen Kleinbuchstaben und eine Ziffer enthalten.
    sap_hana_sidadm_uid Ganzzahl Der Standardwert für die sidadm-Nutzer-ID lautet 900, um zu verhindern, dass von Nutzern erstellte Gruppen im Konflikt mit SAP HANA stehen. Sie können diesen Wert bei Bedarf ändern.
    sap_hana_sapsys_gid Ganzzahl Die Standard-Gruppen-ID für sapsys ist 79. Durch Angabe eines höheren Werts können Sie diesen Wert entsprechend Ihren Anforderungen überschreiben.
    sap_hana_scaleout_nodes Ganzzahl Geben Sie 0 an. Diese Anleitung gilt nur für vertikal skalierbare SAP HANA-Systeme.
    networkTag String Ein Netzwerk-Tag, das Ihre VM-Instanz für Firewall- oder Routing-Zwecke repräsentiert. Wenn Sie "publicIP: No", aber kein Netzwerk-Tag angeben, müssen Sie eine andere Möglichkeit für den Zugriff auf das Internet bereitstellen.
    publicIP Boolescher Wert Optional. Legt fest, ob Ihre VM-Instanz eine öffentliche IP-Adresse erhält. Der Standardwert ist Yes.
    serviceAccount String Optional. Gibt ein Dienstkonto an, das von den Host-VMs und den darauf ausgeführten Programmen verwendet werden soll. Geben Sie das E-Mail-Konto des Mitglieds des Dienstkontos an. Beispiel: svc-acct-name@project-id.iam.gserviceaccount.com. Standardmäßig wird das Compute Engine-Standarddienstkonto verwendet. Weitere Informationen finden Sie unter Identitäts- und Zugriffsverwaltung für SAP-Programme in Google Cloud.
  7. Erstellen Sie die Definition der zweiten VM und des zweiten SAP HANA-Systems, indem Sie die Definition der bzw. des ersten kopieren und sie nach der ersten Definition einfügen. Das nach diesen Schritten folgende Beispiel veranschaulicht dies.

  8. Geben Sie in der Definition des zweiten Systems für die folgenden Attribute andere Werte als in der ersten Definition an:

    • name
    • instanceName
    • zone
  9. Erstellen Sie die Instanzen:

    gcloud deployment-manager deployments create deployment-name --config template-name.yaml

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

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

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

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

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

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

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

imports:
‐ path: https://storage.googleapis.com/sapdeploy/dm-templates/sap_hana/sap_hana.py

resources:
‐ name: sap_hana_primary
  type: https://storage.googleapis.com/sapdeploy/dm-templates/sap_hana/sap_hana.py
  properties:
    instanceName: hana-ha-vm-1
    instanceType: n2-highmem-32
    zone: us-central1-a
    subnetwork: example-subnet-us-central1
    linuxImage: family/sles-15-sp1-sap
    linuxImageProject: suse-sap-cloud
    sap_hana_deployment_bucket: hana2-sp4-rev46
    sap_hana_sid: HA1
    sap_hana_instance_number: 22
    sap_hana_sidadm_password: Google123
    sap_hana_system_password: Google123
    sap_hana_scaleout_nodes: 0
    networkTag: cluster-ntwk-tag
    serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com
    # sap_hana_sidadm_uid: 900
    # sap_hana_sapsys_gid: 79

‐ name: sap_hana_secondary
  type: https://storage.googleapis.com/sapdeploy/dm-templates/sap_hana/sap_hana.py
  properties:
    instanceName: hana-ha-vm-2
    instanceType: n2-highmem-32
    zone: us-central1-c
    subnetwork: example-subnet-us-central1
    linuxImage: family/sles-15-sp1-sap
    linuxImageProject: suse-sap-cloud
    sap_hana_deployment_bucket: hana2-sp4-rev46
    sap_hana_sid: HA1
    sap_hana_instance_number: 22
    sap_hana_sidadm_password: Google123
    sap_hana_system_password: Google123
    sap_hana_scaleout_nodes: 0
    networkTag: cluster-ntwk-tag
    serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com
    # sap_hana_sidadm_uid: 900
    # sap_hana_sapsys_gid: 79

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

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

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

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

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

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

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

Bereitstellung der VMs und von SAP HANA prüfen

Prüfen Sie vor der Konfiguration des Hochverfügbarkeitsclusters, ob die VMs und SAP HANA korrekt bereitgestellt wurden. Prüfen Sie dazu die Logs, die Verzeichniszuordnung des Betriebssystems und die SAP HANA-Installation.

Logs prüfen

  1. Öffnen Sie Cloud Logging, um nach Fehlern zu suchen und den Fortschritt der Installation zu beobachten.

    Zu Cloud Logging

  2. Wählen Sie auf dem Tab Ressourcen die Option Global als Logging-Ressource aus.

    • Wird "INSTANCE DEPLOYMENT COMPLETE" angezeigt, ist die Verarbeitung in Deployment Manager beendet und Sie können mit dem nächsten Schritt fortfahren.
    • Wenn ein Kontingentfehler auftritt:

      1. Erhöhen Sie auf der Seite IAM & Verwaltung > Kontingente alle Kontingente, die nicht die im Planungsleitfaden für SAP HANA aufgeführten Anforderungen erfüllen.
      2. Löschen Sie in Deployment Manager auf der Seite Deployments die Bereitstellung, um VMs und nichtflüchtige Speicher von der fehlgeschlagenen Installation zu bereinigen.
      3. Führen Sie den Deployment Manager wieder aus.

      Logging-Anzeige

Konfiguration der VMs und von SAP HANA prüfen

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

    Schaltfläche

  2. Wechseln Sie zum Root-Nutzer.

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

    Filesystem                        Size  Used Avail Use% Mounted on
    /dev/sda2                          30G  4.0G   26G  14% /
    devtmpfs                          126G     0  126G   0% /dev
    tmpfs                             126G     0  126G   0% /dev/shm
    tmpfs                             126G   17M  126G   1% /run
    tmpfs                             126G     0  126G   0% /sys/fs/cgroup
    /dev/sda1                         200M  9.7M  191M   5% /boot/efi
    /dev/mapper/vg_hana-shared        251G   49G  203G  20% /hana/shared
    /dev/mapper/vg_hana-sap            32G  240M   32G   1% /usr/sap
    /dev/mapper/vg_hana-data          426G  7.0G  419G   2% /hana/data
    /dev/mapper/vg_hana-log           125G  4.2G  121G   4% /hana/log
    /dev/mapper/vg_hanabackup-backup  512G   33M  512G   1% /hanabackup
    tmpfs                              26G     0   26G   0% /run/user/900
    tmpfs                              26G     0   26G   0% /run/user/899
    tmpfs                              26G     0   26G   0% /run/user/1000
  4. Wechseln Sie zum SAP-Administrator. Ersetzen Sie dazu im folgenden Befehl sid durch die System-ID, die Sie in der Vorlage für die Konfigurationsdatei angegeben haben.

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

    > HDB info

Autostart von SAP HANA deaktivieren

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

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

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

    vi /usr/sap/SID/SYS/profile/SID_HDBinst_num_host_name
  3. Setzen Sie das Attribut Autostart auf 0:

    Autostart=0
  4. Speichern Sie das Profil.

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

    > HDB start

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

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

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

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

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

  1. Auf der primären Host-VM:

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

    2. Wechseln Sie zum Root:

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

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

      # gcloud compute instances add-metadata secondary-host-name \
      --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" --zone secondary-zone
    3. Autorisieren Sie die primäre VM für sich selbst.

      # cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
  2. Auf der sekundären Host-VM:

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

    2. Wechseln Sie zum Root:

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

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

      # gcloud compute instances add-metadata primary-host-name \
      --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" --zone primary-zone
    3. Autorisieren Sie die sekundäre VM für sich selbst.

      # cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
    4. Prüfen Sie, ob die SSH-Schlüssel ordnungsgemäß eingerichtet sind. Stellen Sie dazu eine SSH-Verbindung vom sekundären zum primären System her.

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

    # ssh secondary-host-name

SAP HANA-Datenbanknutzer zum Monitoring des Clusterstatus erstellen

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

    > hdbsql -u system -p "system-password" -i inst_num
  2. Erstellen Sie im interaktiven Terminal den Datenbanknutzer slehasync:

    => CREATE USER slehasync PASSWORD "hdb-user-password";
    => GRANT DATA ADMIN TO slehasync;
    => ALTER USER slehasync DISABLE PASSWORD LIFETIME;
  3. Definieren Sie als sidadm den Nutzerschlüssel SLEHALOC im sicheren SAP HANA-Nutzerspeicher (hdbuserstore):

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

Datenbanken sichern

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

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

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

So erstellen Sie Sicherungen von neuen SAP HANA-Datenbanken:

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

    sudo -i -u sidadm
  2. Erstellen Sie die Datenbanksicherungen:

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

      > hdbsql -t -u system -p system-password -i inst-num \
        "backup data using file ('full')"

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

      0 rows affected (overall time 18.416058 sec; server time 18.414209 sec)
    • Erstellen Sie für ein SAP HANA-System mit Container für mehrere Datenbanken (MDC) eine Sicherung der Systemdatenbank sowie aller Mandantendatenbanken:

      > hdbsql -t -d SYSTEMDB -u system -p system-password -i inst_num \
        "backup data using file ('full')"
      > hdbsql -t -d SID -u system -p system-password -i inst-num \
        "backup data using file ('full')"

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

    0 rows affected (overall time 16.590498 sec; server time 16.588806 sec)
  3. Prüfen Sie, ob der Logging-Modus auf "normal" eingestellt ist:

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

    Hier sollten Sie das sehen:

    VALUE
    "normal"

SAP HANA-Systemreplikation aktivieren

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

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

    > hdbnsutil -sr_enable --name=primary-host-name
  2. Auf dem sekundären Host:

    1. Beenden Sie SAP HANA als sidadm:

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

      # cd /usr/sap/SID/SYS/global/security/rsecssfs/
      # mv data/SSFS_SID.DAT data/SSFS_SID.DAT-ARC
      # mv key/SSFS_SID.KEY key/SSFS_SID.KEY-ARC
    3. Kopieren Sie die Datendatei vom primären Host:

      # scp -o StrictHostKeyChecking=no \
      primary-host-name:/usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT \
      /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT
    4. Kopieren Sie die Schlüsseldatei vom primären Host:

      # scp -o StrictHostKeyChecking=no \
      primary-host-name:/usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY \
      /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY
    5. Aktualisieren Sie die Eigentümerschaft für die Dateien:

      # chown sidadm:sapsys /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT
      # chown sidadm:sapsys /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY
    6. Aktualisieren Sie die Berechtigungen für die Dateien:

      # chmod 644 /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT
      # chmod 640 /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY
    7. Registrieren Sie als sidadm das sekundäre SAP HANA-System bei der SAP HANA-Systemreplikation:

      > hdbnsutil -sr_register --remoteHost=primary-host-name --remoteInstance=inst_num \
      --replicationMode=syncmem --operationMode=logreplay --name=secondary-host-name
    8. Starten Sie SAP HANA als sidadm:

      > HDB start

Systemreplikation validieren

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

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

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

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

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

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

Der interne TCP/UDP-Load-Balancing-Dienst mit Failover-Unterstützung leitet den Traffic basierend auf einem Systemdiagnosedienst an den aktiven Host in einem SAP HANA-Cluster weiter. Dies bietet Schutz in einer Aktiv/Passiv-Konfiguration und kann erweitert werden, um eine sekundäre Aktiv/Aktiv-Konfiguration mit Lesezugriff zu unterstützen.

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

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

  1. Öffnen Sie Cloud Shell:

    Zu Cloud Shell

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

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

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

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

    $ gcloud compute addresses describe vip-name \
      --region cluster-region

    Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

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

Instanzgruppen für Host-VMs erstellen

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

    $ gcloud compute instance-groups unmanaged create primary-ig-name \
      --zone=primary-zone
    $ gcloud compute instance-groups unmanaged add-instances primary-ig-name \
      --zone=primary-zone \
      --instances=primary-host-name
    $ gcloud compute instance-groups unmanaged create secondary-ig-name \
      --zone=secondary-zone
    $ gcloud compute instance-groups unmanaged add-instances secondary-ig-name \
      --zone=secondary-zone \
      --instances=secondary-host-name
    
  2. Bestätigen Sie die Erstellung der Instanzgruppen:

    $ gcloud compute instance-groups unmanaged list

    Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

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

Compute Engine-Systemdiagnose erstellen

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

    $ gcloud compute health-checks create tcp health-check-name --port=healthcheck-port-num \
      --proxy-header=NONE --check-interval=10 --timeout=10 --unhealthy-threshold=2 \
      --healthy-threshold=2
  2. Bestätigen Sie die Erstellung der Systemdiagnose:

    $ gcloud compute health-checks describe health-check-name

    Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

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

Firewallregel für die Systemdiagnosen erstellen

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

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

    $ gcloud compute firewall-rules create  rule-name \
      --network network-name \
      --action ALLOW \
      --direction INGRESS \
      --source-ranges 35.191.0.0/16,130.211.0.0/22 \
      --target-tags network-tags \
      --rules tcp:hlth-chk-port-num

    Beispiel:

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

Load-Balancer und Failover-Gruppe konfigurieren

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

    $ gcloud compute backend-services create backend-service-name \
      --load-balancing-scheme internal \
      --health-checks health-check-name \
      --no-connection-drain-on-failover \
      --drop-traffic-if-unhealthy \
      --failover-ratio 1.0 \
      --region cluster-region \
      --global-health-checks
  2. Fügen Sie die primäre Instanzgruppe dem Back-End-Dienst hinzu:

    $ gcloud compute backend-services add-backend backend-service-name \
      --instance-group primary-ig-name \
      --instance-group-zone primary-zone \
      --region cluster-region
  3. Fügen Sie die sekundäre Failover-Instanzgruppe dem Back-End-Dienst hinzu:

    $ gcloud compute backend-services add-backend backend-service-name \
      --instance-group secondary-ig-name \
      --instance-group-zone secondary-zone \
      --failover \
      --region cluster-region
  4. Erstellen Sie eine Weiterleitungsregel. Geben Sie darin die IP-Adresse an, die Sie für die VIP reserviert haben:

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

Konfiguration des Load-Balancers testen

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

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

Load-Balancer mit dem socat-Dienstprogramm testen

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

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

    # zypper install -y socat

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

    # timeout 60s socat - TCP-LISTEN:hlth-chk-port-num,fork

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

    $ gcloud compute backend-services get-health backend-service-name \
      --region cluster-region

    Die Ausgabe sollte in etwa so aussehen:

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

Load-Balancer über Port 22 testen

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

So verwenden Sie vorübergehend Port 22:

  1. Klicken Sie in der Konsole auf Ihre Systemdiagnose:

    Zur Seite "Systemdiagnosen"

  2. Klicken Sie auf Bearbeiten.

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

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

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

    $ gcloud compute backend-services get-health backend-service-name \
      --region cluster-region

    Die Ausgabe sollte in etwa so aussehen:

    ---
    backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/hana-ha-ig-1
    status:
     healthStatus:
     ‐ healthState: HEALTHY
       instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-ha-vm-1
       ipAddress: 10.0.0.35
       port: 80
     kind: compute#backendServiceGroupHealth
    ---
    backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/hana-ha-ig-2
    status:
     healthStatus:
     ‐ healthState: HEALTHY
       instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/hana-ha-vm-2
       ipAddress: 10.0.0.34
       port: 80
     kind: compute#backendServiceGroupHealth
  6. Wenn Sie fertig sind, ändern Sie die Portnummer der Systemdiagnose wieder in die ursprüngliche Portnummer.

Pacemaker einrichten

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

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

Ressourcen-Agent-Skripts herunterladen

Laden Sie als Root auf dem primären und dem sekundären Host die erforderlichen Ressourcen-Agent-Skripts herunter:

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

Corosync-Konfigurationsdateien erstellen

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

    1. Erstellen Sie die folgende Datei:

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

      totem {
       version: 2
       secauth: off
       crypto_hash: sha1
       crypto_cipher: aes256
       cluster_name: hacluster
       clear_node_high_bit: yes
       token: 20000
       token_retransmits_before_loss_const: 10
       join: 60
       consensus: 24000
       max_messages:  20
       transport: udpu
       interface {
         ringnumber: 0
         Bindnetaddr: static-ip-of-hdb-on-this-host
         mcastport: 5405
         ttl: 1
       }
      }
      logging {
       fileline:  off
       to_stderr: no
       to_logfile: no
       logfile: /var/log/cluster/corosync.log
       to_syslog: yes
       debug: off
       timestamp: on
       logger_subsys {
         subsys: QUORUM
         debug: off
       }
      }
      nodelist {
       node {
         ring0_addr: this-host-name
         nodeid: 1
       }
       node {
         ring0_addr: other-host-name
         nodeid: 2
       }
      }
      quorum {
       provider: corosync_votequorum
       expected_votes: 2
       two_node: 1
      }
  2. Erstellen Sie eine Corosync-Konfigurationsdatei auf dem sekundären Host. Wiederholen Sie dazu die Schritte, die Sie für den primären Host verwendet haben. Mit Ausnahme der statischen IP-Adresse der HDB für das Attribut Bindnetaddr und der Reihenfolge der Hostnamen in der nodelist sind die Attributwerte der Konfigurationsdatei für die Hosts identisch.

Cluster initialisieren

  1. Als Root auf dem primären Host:

    1. Initialisieren Sie den Cluster:

      # corosync-keygen
      # ha-cluster-init -y csync2
    2. Starten Sie Pacemaker auf dem primären Host:

      # systemctl enable pacemaker
      # systemctl start pacemaker
  2. Als Root auf dem sekundären Host:

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

      # ha-cluster-join -y -c primary-host-name csync2
    2. Starten Sie Pacemaker auf dem sekundären Host:

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

    # crm_mon -s

    Die Ausgabe sollte in etwa so aussehen:

    CLUSTER OK: 2 nodes online, 0 resources configured

Cluster konfigurieren

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

Wartungsmodus aktivieren

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

    # crm configure property maintenance-mode="true"

Allgemeine Clusterattribute konfigurieren

  1. Auf dem primären Host:

    1. Legen Sie die allgemeinen Clusterattribute fest:

      # crm configure property no-quorum-policy="stop"
      # crm configure property startup-fencing="true"
      # crm configure property stonith-timeout="300s"
      # crm configure property stonith-enabled="true"
      # crm configure rsc_defaults resource-stickiness="1000"
      # crm configure rsc_defaults migration-threshold="5000"
      # crm configure op_defaults timeout="600"

Einfache STONITH-Ressourcen erstellen

  1. Als Root auf dem primären Host:

    1. Fügen Sie STONITH-Ressourcen hinzu:

      # crm configure primitive STONITH-"primary-host-name" stonith:external/gcpstonith \
          op monitor interval="300s" timeout="60s" on-fail="restart" \
          op start interval="0" timeout="60s" onfail="restart" \
          params instance_name="primary-host-name" gcloud_path="/usr/bin/gcloud" logging="yes"
      # crm configure primitive STONITH-"secondary-host-name" stonith:external/gcpstonith \
          op monitor interval="300s" timeout="60s" on-fail="restart" \
          op start interval="0" timeout="60s" onfail="restart" \
          params instance_name="secondary-host-name" gcloud_path="/usr/bin/gcloud" logging="yes"
      # crm configure location LOC_STONITH_"primary-host-name" \
          STONITH-"primary-host-name" -inf: "primary-host-name"
      # crm configure location LOC_STONITH_"secondary-host-name" \
          STONITH-"secondary-host-name" -inf: "secondary-host-name"
    2. Erstellen Sie zum Konfigurieren der VIP-Adresse im Betriebssystem eine lokale Cluster-IP-Ressource für die zuvor reservierte VIP-Adresse:

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

Einfache Ressource für den Hilfsdienst zur Systemdiagnose erstellen

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

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

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

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

    # zypper in -y socat
  2. Auf dem primären Host:

    1. Erstellen Sie eine Ressource für den Hilfsdienst zur Systemdiagnose:

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

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

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

# crm configure group g-primary rsc_vip_int-primary rsc_healthcheck-primary

Einfache SAPHanaTopology-Ressource erstellen

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

Als Root auf dem primären Host:

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

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

    primitive rsc_SAPHanaTopology_SID_HDBinst_num ocf:suse:SAPHanaTopology \
     operations \$id="rsc_sap2_SID_HDBinst_num-operations" \
     op monitor interval="10" timeout="600" \
     op start interval="0" timeout="600" \
     op stop interval="0" timeout="300" \
     params SID="SID" InstanceNumber="inst_num"
    
    clone cln_SAPHanaTopology_SID_HDBinst_num rsc_SAPHanaTopology_SID_HDBinst_num \
     meta is-managed="true" clone-node-max="1" target-role="Started" interleave="true"
  3. Bearbeiten Sie die Datei /tmp/cluster.tmp, um den Variablentext durch die SID und die Instanznummer für Ihr SAP HANA-System zu ersetzen.

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

    crm configure load update /tmp/cluster.tmp

Einfache SAPHana-Ressource erstellen

Zum Definieren der einfachen SAPHana-Ressource verwenden Sie dieselbe Methode, die Sie für die SAPHanaTopology-Ressource verwendet haben: in einer temporären Konfigurationsdatei, die Sie dann in Corosync hochladen.

  1. Ersetzen Sie die temporäre Konfigurationsdatei:

    # rm /tmp/cluster.tmp
    # vi /tmp/cluster.tmp
  2. Kopieren Sie die SAPHana-Ressourcendefinitionen und fügen Sie sie in die Datei /tmp/cluster.tmp ein:

    primitive rsc_SAPHana_SID_HDBinst_num ocf:suse:SAPHana \
     operations \$id="rsc_sap_SID_HDBinst_num-operations" \
     op start interval="0" timeout="3600" \
     op stop interval="0" timeout="3600" \
     op promote interval="0" timeout="3600" \
     op monitor interval="10" role="Master" timeout="700" \
     op monitor interval="11" role="Slave" timeout="700" \
     params SID="SID" InstanceNumber="inst_num" PREFER_SITE_TAKEOVER="true" \
     DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="true"
    
    ms msl_SAPHana_SID_HDBinst_num rsc_SAPHana_SID_HDBinst_num \
     meta is-managed="true" notify="true" clone-max="2" clone-node-max="1" \
     target-role="Started" interleave="true"
    
    colocation col_saphana_ip_SID_HDBinst_num 4000: g-primary:Started \
     msl_SAPHana_SID_HDBinst_num:Master
    order ord_SAPHana_SID_HDBinst_num Optional: cln_SAPHanaTopology_SID_HDBinst_num \
     msl_SAPHana_SID_HDBinst_num
  3. Laden Sie als Root auf dem primären Host den Inhalt der Datei /tmp/cluster.tmp in Corosync:

    crm configure load update /tmp/cluster.tmp

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

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

    > hdbsql -u system -p "system-password" -i inst_num
  2. Prüfen Sie im interaktiven Terminal den Replikationsstatus:

    => select distinct REPLICATION_STATUS from SYS.M_SERVICE_REPLICATION

    Der REPLICATION_STATUS sollte "ACTIVE" lauten.

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

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

Cluster aktivieren

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

    # crm configure property maintenance-mode="false"

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

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

    # crm status

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

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

Failover testen

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

Sichern Sie vor dem Test das System.

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

  • HDB stop
  • HDB kill
  • shutdown -r (auf dem Master-Knoten)
  • ip link set eth0 down
  • echo c > /proc/sysrq-trigger

In dieser Anleitung wird ip link set eth0 down verwendet, um die Netzwerkschnittstelle offline zu schalten, weil damit sowohl der Failover als auch das Fencing validiert wird.

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

    # ip link set eth0 down
  2. Verfolgen Sie den Fortschritt des Failovers in Logging:

    Zu Logging

    Das folgende Beispiel zeigt die Logeinträge für ein erfolgreiches Failover:

    Logging-Logs für ein Failover

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

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

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

Fehlerbehebung

Sie finden die Logs in den folgenden Verzeichnissen:

  • /var/log/pacemaker.log
  • /var/log/cluster/corosync.log

NAT-Gateway-Installation beenden

Wenn Sie ein NAT-Gateway erstellt haben, führen Sie die folgenden Schritte aus.

  1. Fügen Sie allen Instanzen Tags hinzu:

    export NETWORK_NAME="[YOUR_NETWORK_NAME]"
    export TAG="[YOUR_TAG_TEXT]"
    gcloud compute instances add-tags "[PRIMARY_VM_NAME]" --tags="$TAG" --zone=[PRIMARY_VM_ZONE]
    gcloud compute instances add-tags "[SECONDARY_VM_NAME]" --tags="$TAG" --zone=[SECONDARY_VM_ZONE]
  2. Löschen Sie die externen IP-Adressen:

    gcloud compute instances delete-access-config "[PRIMARY_VM_NAME]" --access-config-name "external-nat" --zone=[PRIMARY_VM_ZONE]
    gcloud compute instances delete-access-config "[SECONDARY_VM_NAME]" --access-config-name "external-nat" --zone=[SECONDARY_VM_ZONE]

Verbindung zu SAP HANA herstellen

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

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

  • Zum Herstellen einer Verbindung mit der SAP HANA-Datenbank über SAP HANA Studio verwenden Sie einen Remotedesktop-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 dem Deployment ausführen

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

Weitere Informationen:

Weitere Informationen

Mehr erfahren Sie unter den folgenden Links:

  • Automatisierte SAP HANA-Systemreplikation beim vertikalen Skalieren im Pacemaker-Cluster
  • SAP on Google Cloud: High availability
  • Planungsleitfaden für SAP HANA – Hochverfügbarkeit und Notfallwiederherstellung
  • Weitere Informationen zu VM-Verwaltung und VM-Monitoring finden Sie in der Betriebsanleitung für SAP HANA.