Konfigurationsleitfaden: Hochverfügbarkeitscluster für SAP HANA unter RHEL

In diesem Leitfaden wird beschrieben, wie Sie einen Hochverfügbarkeitscluster unter Red Hat Enterprise Linux (RHEL) für SAP HANA 1.0 ab SP 12 in Google Cloud bereitstellen und konfigurieren.

Die Anleitung umfasst folgende Schritte:

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

Dieser Leitfaden 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 den Bereitstellungsleitfaden für SAP HANA.

Informationen zum Konfigurieren eines HA-Clusters für SAP HANA auf SUSE Linux Enterprise Server (SLES) finden Sie im Konfigurationsleitfaden für HA-Cluster für die vertikale Skalierung von SAP HANA auf SLES.

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 RHEL 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/rhel-7-6-sap-ha 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 rhel-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/rhel-7-6-sap-ha
    linuxImageProject: rhel-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/rhel-7-6-sap-ha
    linuxImageProject: rhel-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 als sid-Administrator auf beiden Hosts SAP HANA:

    > HDB start

Optional: SSH-Schlüssel auf der primären und sekundären VM konfigurieren

Die SSFS-Schlüssel (SAP HANA Secure Store) müssen im Hochverfügbarkeitscluster zwischen den Hosts synchronisiert werden. Diese Anweisungen autorisieren direkte SSH-Verbindungen zwischen den beiden Hosts, um die Synchronisierung zu vereinfachen und das Kopieren von Dateien wie Sicherungen zwischen den Hosts im Hochverfügbarkeitscluster zu ermöglichen.

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. Generieren Sie einen SSH-Schlüssel für den Nutzer, der die SSH-Verbindung zwischen den Hosts benötigt. Dieser Nutzer sind in der Regel Sie.

      $ ssh-keygen
    3. Akzeptieren Sie die Standardeinstellungen, wenn Sie dazu aufgefordert werden, mit der Eingabetaste.

    4. 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
    5. 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. Generieren Sie einen SSH-Schlüssel für den Nutzer, der die SSH-Verbindung zwischen den Hosts benötigt.

      $ ssh-keygen
    3. 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
    4. Autorisieren Sie die sekundäre VM für sich selbst.

      $ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
    5. 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 auf der primären Host-VM die Verbindung, indem Sie eine SSH-Verbindung zur sekundären Host-VM herstellen:

    $ ssh secondary-host-name

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. Beenden Sie SAP HANA als sidadm auf dem sekundären Host:

    > HDB stop
  3. Kopieren Sie mit demselben Nutzerkonto, mit dem Sie SSH zwischen den Host-VMs eingerichtet haben, die Schlüsseldateien vom primären auf den sekundären Host. Der Einfachheit halber definieren die folgenden Befehle auch eine Umgebungsvariable für Ihre Nutzerkonto-ID:

    $ sudo cp /usr/sap/SID/SYS/global/security/rsecssfs ~/rsecssfs -r
    $ myid=$(whoami)
    $ sudo chown ${myid} -R /home/"${myid}"/rsecssfs
    $ scp -r rsecssfs $(whoami)@secondary-host-name:rsecssfs
    $ rm -r /home/"${myid}"/rsecssfs
    
  4. Auf dem sekundären Host mit demselben Nutzerkonto wie im vorherigen Schritt:

    1. Ersetzen Sie die vorhandenen Schlüsseldateien in den rsecssfs-Verzeichnissen durch die Dateien des primären Hosts und legen Sie die Dateiberechtigungen fest, um den Zugriff zu beschränken:

      $ SAPSID=SID
      $ sudo rm /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT
      $ sudo rm /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEY
      $ myid=$(whoami)
      $ sudo cp /home/"${myid}"/rsecssfs/data/SSFS_"${SAPSID}".DAT \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT
      $ sudo cp /home/"${myid}"/rsecssfs/key/SSFS_"${SAPSID}".KEY \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEY
      $ sudo chown "${SAPSID,,}"adm:sapsys \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT
      $ sudo chown "${SAPSID,,}"adm:sapsys \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEY
      $ sudo chmod 644 \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT
      $ sudo chmod 640 \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEY
    2. Bereinigen Sie die Dateien in Ihrem Basisverzeichnis.

      $ rm -r /home/"${myid}"/rsecssfs
    3. Registrieren Sie als sid-Administrator 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
    4. 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.

Nur für SAP HANA 1.0 SP 12: Linux-Nutzer für den Monitoring-Agent erstellen

Sie müssen Ressourcen-Agents als SAP HANA-Datenbanknutzer registrieren, damit sie den Replikationsstatus des Systems abfragen können. Die Ressourcen-Agents benötigen die Berechtigungen CATALOG READ und MONITOR ADMIN.

So registrieren Sie die Ressourcen-Agents als Datenbanknutzer:

  1. Auf dem primären Host:

    1. Erstellen Sie als sidadm den Nutzer rhelhasync:

      > hdbsql -i inst_num -u system -p system-password \
        "create user rhelhasync password \"monitoring-user-password\""
      > hdbsql -i inst_num -u system -p system-password \
        "grant CATALOG READ to rhelhasync"
      > hdbsql -i inst_num -u system -p system-password \
        "grant MONITOR ADMIN to rhelhasync"
      > hdbsql -i inst_num -u system -p system-password \
        "ALTER USER rhelhasync DISABLE PASSWORD LIFETIME"
    2. Speichern Sie die Anmeldedaten als Root, damit der Root-Nutzer darauf zugreifen kann:

      # /usr/sap/SID/HDBinst_num/exe/hdbuserstore \
        SET SAPHANASIDSR localhost:3inst_num15 rhelhasync \
        "monitoring-user-password"
    3. Prüfen Sie als Root, ob die Anmeldedaten erfolgreich gespeichert wurden:

      # /usr/sap/SID/HDBinst_num/exe/hdbuserstore list

      Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

      ha1adm@hana-ha-vm-1:/usr/sap/HA1/HDB22> /usr/sap/HA1/HDB22/exe/hdbuserstore list
      DATA FILE       : /usr/sap/HA1/home/.hdb/hana-ha-vm-1/SSFS_HDB.DAT
      KEY FILE        : /usr/sap/HA1/home/.hdb/hana-ha-vm-1/SSFS_HDB.KEY
      
      KEY SAPHANAHA1SR
       ENV : localhost:32215
       USER: rhelhasync
    4. Prüfen Sie als Root, ob Root mithilfe des gespeicherten Schlüssels eine Verbindung zur Datenbank herstellen kann:

      # /usr/sap/SID/HDBinst_num/exe/hdbsql -U SAPHANASIDSR -i inst_num \
        "select distinct REPLICATION_STATUS from SYS.M_SERVICE_REPLICATION"
  2. Auf dem sekundären Host:

    1. Speichern Sie die Anmeldedaten als Root, damit der Root-Nutzer darauf zugreifen kann:

      # /usr/sap/SID/HDBinst_num/exe/hdbuserstore \
        SET SAPHANASIDSR localhost:3inst_num15 rhelhasync \
          "monitoring-user-password"
    2. Prüfen Sie als Root, ob die Anmeldedaten erfolgreich gespeichert wurden:

      # /usr/sap/SID/HDBinst_num/exe/hdbuserstore list

      Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

      ha1adm@hana-ha-vm-2:/usr/sap/HA1/HDB22> /usr/sap/HA1/HDB22/exe/hdbuserstore list
      DATA FILE       : /usr/sap/HA1/home/.hdb/hana-ha-vm-2/SSFS_HDB.DAT
      KEY FILE        : /usr/sap/HA1/home/.hdb/hana-ha-vm-2/SSFS_HDB.KEY
      KEY SAPHANAHA1SR
       ENV : localhost:32215
       USER: rhelhasync

Wenn Sie Fehlermeldungen erhalten oder aufgefordert werden, das Passwort zu ändern, prüfen Sie entweder mit dem Befehl hdbsql oder mit SAP HANA Studio, ob das Passwort für den Ressourcen-Agent-Nutzer eventuell so konfiguriert ist, dass es bei der ersten Anmeldung geändert wird, oder ob es abgelaufen ist.

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

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

    $ sudo yum install -y socat

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

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

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

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

    Die Ausgabe sollte in etwa so aussehen:

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

Load-Balancer über Port 22 testen

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

So verwenden Sie vorübergehend Port 22:

  1. Klicken Sie in der Konsole auf Ihre Systemdiagnose:

    Zur Seite "Systemdiagnosen"

  2. Klicken Sie auf Bearbeiten.

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

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

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

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

    Die Ausgabe sollte in etwa so aussehen:

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

Pacemaker einrichten

Mit dem nachstehend beschriebenen Verfahren wird die Red Hat-Implementierung eines Pacemaker-Clusters auf Compute Engine-VMs für SAP HANA konfiguriert.

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

Cluster-Agents auf beiden Knoten installieren

Führen Sie die folgenden Schritte auf beiden Knoten aus.

  1. Installieren Sie als Root die Pacemaker-Komponenten:

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

    Wenn Sie ein von Google bereitgestelltes RHEL-for-SAP-Image verwenden, sind diese Pakete bereits installiert, möglicherweise sind jedoch einige Updates erforderlich.

  2. Legen Sie das Passwort für den Nutzer hacluster fest, der gemeinsam mit den Paketen installiert wird:

    # passwd hacluster
  3. Geben Sie in den Eingabeaufforderungen ein Passwort für hacluster an.

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

    # firewall-cmd --permanent --add-service=high-availability
    # firewall-cmd --reload
  5. Starten Sie den pcs-Dienst und konfigurieren Sie ihn so, dass er beim Booten startet:

    # systemctl start pcsd.service
    # systemctl enable pcsd.service
  6. Prüfen Sie den Status des pcs-Dienstes:

    # systemctl status pcsd.service

    Die Ausgabe sollte in etwa so aussehen:

    ● pcsd.service - PCS GUI and remote configuration interface
      Loaded: loaded (/usr/lib/systemd/system/pcsd.service; enabled; vendor preset: disabled)
      Active: active (running) since Sat 2020-06-13 21:17:05 UTC; 25s ago
        Docs: man:pcsd(8)
              man:pcs(8)
    Main PID: 31627 (pcsd)
      CGroup: /system.slice/pcsd.service
              └─31627 /usr/bin/ruby /usr/lib/pcsd/pcsd
    Jun 13 21:17:03 hana-ha-vm-1 systemd[1]: Starting PCS GUI and remote configuration interface...
    Jun 13 21:17:05 hana-ha-vm-1 systemd[1]: Started PCS GUI and remote configuration interface.
  7. Fügen Sie in der Datei /etc/hosts den vollständigen Hostnamen und die internen IP-Adressen beider Hosts im Cluster hinzu. Beispiel:

    127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
    ::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
    10.0.0.40 hana-ha-vm-1.us-central1-a.c.example-project-123456.internal hana-ha-vm-1  # Added by Google
    10.0.0.41 hana-ha-vm-2.us-central1-c.c.example-project-123456.internal hana-ha-vm-2
    169.254.169.254 metadata.google.internal  # Added by Google

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

Cluster erstellen

  1. Autorisieren Sie als Root den Nutzer hacluster auf einem der Knoten:

    # pcs cluster auth primary-host-name secondary-host-name
  2. Geben Sie bei Aufforderung den Nutzernamen hacluster und das Passwort ein, das Sie für den Nutzer hacluster festgelegt haben.

  3. Erstellen Sie den Cluster und legen Sie fest, dass er automatisch gestartet wird:

    # pcs cluster setup --name cluster-name primary-host-name secondary-host-name
    # pcs cluster enable --all
    # pcs cluster start --all

Standardeinstellungen für "corosync.conf" bearbeiten

Bearbeiten Sie die Datei /etc/corosync/corosync.conf auf dem primären Host, um einen geeigneteren Ausgangspunkt für das Testen der Fehlertoleranz Ihres Hochverfügbarkeitsclusters in Google Cloud festzulegen.

  1. Öffnen Sie in beiden Hosts die Datei /etc/corosync/corosync.conf zur Bearbeitung:

    # vi /etc/corosync/corosync.conf
  2. Fügen Sie im Abschnitt totem der Datei corosync.conf die folgenden Attribute mit den vorgeschlagenen Werten hinzu:

    • token: 20000
    • token_retransmits_before_loss_const: 10
    • join: 60
    • max_messages: 20

    Beispiel:

    totem {
     version: 2
     cluster_name: hacluster
     secauth: off
     transport: udpu
     token: 20000
     token_retransmits_before_loss_const: 10
     join: 60
     max_messages: 20
    }
    ...
  3. Synchronisieren Sie auf dem Host, der die bearbeitete Datei corosync.conf enthält, die corosync-Konfiguration für den gesamten Cluster:

    # pcs cluster sync corosync
  4. Laden Sie den Cluster neu:

    # pcs cluster reload corosync
  5. Prüfen Sie mit dem Dienstprogramm "corosync-cmapctl", ob die neuen Corosync-Einstellungen im Cluster aktiv sind:

    # corosync-cmapctl

Fencing einrichten

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

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

  1. Als Root auf dem primären Host:

    1. Erstellen Sie ein Fencing-Gerät für jede Host-VM:

      # pcs stonith create primary-fence-name fence_gce \
        port=primary-host-name \
        zone=primary-host-zone \
        project=project-id
      # pcs stonith create secondary-fence-name fence_gce \
        port=secondary-host-name \
        zone=secondary-host-zone \
        project=project-id
    2. Beschränken Sie jedes Fencing-Gerät jeweils auf die andere Host-VM:

      # pcs constraint location primary-fence-name \
        prefers secondary-host-name=INFINITY
      # pcs constraint location secondary-fence-name \
        prefers primary-host-name=INFINITY
  2. Testen Sie auf dem primären Host als Root das sekundäre Fencing-Gerät:

    1. Fahren Sie die sekundäre Host-VM herunter:

      # fence_gce -o off -n secondary-host-name --zone=secondary-host-zone

      Wenn der Befehl erfolgreich ausgeführt wurde, wird die Verbindung zur sekundären Host-VM getrennt und in der Cloud Console auf der Seite VM-Instanzen als gestoppt angezeigt. Möglicherweise müssen Sie die Seite aktualisieren.

    2. Starten Sie die sekundäre Host-VM neu:

      # fence_gce -o on -n secondary-host-name --zone=secondary-host-zone
  3. Testen Sie als Root auf dem sekundären Host das primäre Fencing-Gerät Wiederholen Sie dazu die vorherigen Schritte und verwenden Sie dabei in den Befehlen die Werte für den primären Host.

  4. Prüfen Sie als Root auf jedem Host den Status des Clusters:

    # pcs status

    Die Fencing-Ressourcen werden im Ressourcenbereich des Clusterstatus angezeigt, ähnlich wie im folgenden Beispiel:

    [root@hana-ha-vm-2 ~]# pcs status
    Cluster name: hana-ha-cluster
    Stack: corosync
    Current DC: hana-ha-vm-1 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
    Last updated: Mon Jun 15 17:19:07 2020
    Last change: Mon Jun 15 17:18:33 2020 by root via cibadmin on hana-ha-vm-1
    
    2 nodes configured
    2 resources configured
    
    Online: [ hana-ha-vm-1 hana-ha-vm-2 ]
    
    Full list of resources:
    
     STONITH-hana-ha-vm-1   (stonith:fence_gce):    Started hana-ha-vm-2
     STONITH-hana-ha-vm-2   (stonith:fence_gce):    Started hana-ha-vm-1
    
    Daemon Status:
      corosync: active/enabled
      pacemaker: active/enabled
      pcsd: active/enabled

Ab SAP HANA 2.0: Provider-Hook für SAP HANA HA/DR aktivieren

Der Provider-Hook für SAP HANA HA/DR ermöglicht es SAP HANA, Benachrichtigungen über bestimmte Ereignisse zu senden, und verbessert die Fehlererkennung. Red Hat empfiehlt die Verwendung.

So aktivieren Sie den Provider-Hook für SAP HANA HA/DR:

  1. Stoppen Sie als Root auf einem der Hosts den Cluster:

    # pcs cluster stop --all
  2. Auf beiden Hosts:

    1. Beenden Sie als sid-Administrator SAP HANA:

      > HDB stop
    2. Installieren Sie als Root das bereitgestellte SAP HANA-Skript:

      # mkdir -p /hana/shared/myHooks
      # cp /usr/share/SAPHanaSR/srHook/SAPHanaSR.py /hana/shared/myHooks
      # chown -R sidadm:sapsys /hana/shared/myHooks
    3. Öffnen Sie als Root die Datei global.ini zur Bearbeitung:

      # vi /hana/shared/SID/global/hdb/custom/config/global.ini
    4. Fügen Sie der Datei global.ini die folgenden Definitionen hinzu:

      [ha_dr_provider_SAPHanaSR]
      provider = SAPHanaSR
      path = /hana/shared/myHooks
      execution_order = 1
      
      [trace]
      ha_dr_saphanasr = info
    5. Erstellen Sie als Root eine sudo-Konfigurationsdatei, damit das Hook-Skript die Knotenattribute aktualisieren kann, wenn der Hook srConnectionChanged() aufgerufen wird:

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

      1 Cmnd_Alias SOK   = /usr/sbin/crm_attribute -n hana_SID_glob_srHook -v SOK -t crm_config -s SAPHanaSR
      2 Cmnd_Alias SFAIL = /usr/sbin/crm_attribute -n hana_SID_glob_srHook -v SFAIL -t crm_config -s SAPHanaSR
      3 sidadm ALL=(ALL) NOPASSWD: SOK, SFAIL
    7. Starten Sie SAP HANA als sid-Administrator:

      > HDB start
    8. Testen Sie als sid-Administrator den vom Hook-Skript gemeldeten Status:

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

Standardeinstellungen für den Cluster festlegen

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

  1. Starten Sie als Root den Cluster auf einem der Hosts:

    # pcs cluster start --all #start the cluster
  2. Legen Sie die Standardeinstellungen für Ressourcen fest:

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

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

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

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

  3. Wenn die Attribute startup-fencing und stonith-enabled noch nicht auf true festgelegt sind, legen Sie sie jetzt auf true fest:

    # pcs property set startup-fencing="true"
    # pcs property set stonith-enabled="true"

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

Ressource SAPHanaTopology erstellen

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

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

    # pcs resource create topology_resource_name SAPHanaTopology SID=SID \
       InstanceNumber=inst_num \
       op start timeout=600 \
       op stop timeout=300 \
       op monitor interval=10 timeout=600 \
       clone clone-max=2 clone-node-max=1 interleave=true
  2. Nachdem die Ressource erstellt wurde, prüfen Sie die Konfiguration. Hängen Sie -clone an den Ressourcennamen an, um die Informationen zum Klonsatz in die Antwort aufzunehmen:

    # pcs resource show topology_resource_name-clone

    Die Ausgabe sollte in etwa so aussehen:

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

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

SAPHana-Ressource erstellen

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

Die folgenden Parameter in der SAPHana-Ressourcendefinition sind optional:

  • AUTOMATED_REGISTER: Wenn dieser Wert auf true festgelegt ist, wird die frühere primäre Instanz automatisch als sekundäre registriert, wenn nach einem Takeover der DUPLICATE_PRIMARY_TIMEOUT eintritt. Der Standardwert ist false.
  • DUPLICATE_PRIMARY_TIMEOUT: Zeit in Sekunden, die zwischen zwei Primär-Zeitstempeln verstreichen muss, wenn zwei primäre Instanzen erfasst werden. Der Standardwert ist 7200.
  • PREFER_SITE_TAKEOVER: Legt fest, ob lokale Neustarts versucht werden sollen, bevor ein Failover ausgelöst wird. Der Standardwert ist false.

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

  1. Erstellen Sie als Root auf einem der Hosts die SAP HANA-Ressource:

    # pcs resource create sap_hana_resource_name SAPHana SID=SID \
        InstanceNumber=inst_num \
        PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true \
        op start timeout=3600 \
        op stop timeout=3600 \
        op monitor interval=61 role="Slave" timeout=700 \
        op monitor interval=59 role="Master" timeout=700 \
        op promote timeout=3600 \
        op demote timeout=3600 \
        master meta notify=true clone-max=2 clone-node-max=1 interleave=true
  2. Prüfen Sie die ausgegebenen Ressourcenattribute:

    # pcs resource show sap_hana_resource_name

    Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

     Resource: SAPHana_HA1_22 (class=ocf provider=heartbeat type=SAPHana)
      Attributes: AUTOMATED_REGISTER=true DUPLICATE_PRIMARY_TIMEOUT=7200 InstanceNumber=22 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_22-demote-interval-0s)
                  methods interval=0s timeout=5 (SAPHana_HA1_22-methods-interval-0s)
                  monitor interval=61 role=Slave timeout=700 (SAPHana_HA1_22-monitor-interval-61)
                  monitor interval=59 role=Master timeout=700 (SAPHana_HA1_22-monitor-interval-59)
                  promote interval=0s timeout=3600 (SAPHana_HA1_22-promote-interval-0s)
                  reload interval=0s timeout=5 (SAPHana_HA1_22-reload-interval-0s)
                  start interval=0s timeout=3600 (SAPHana_HA1_22-start-interval-0s)
                  stop interval=0s timeout=3600 (SAPHana_HA1_22-stop-interval-0s)
  3. Prüfen Sie nach dem Start der Ressource die Knotenattribute, um den aktuellen Status der SAP HANA-Datenbanken auf den Knoten anzeigen zu lassen:

    # crm_mon -A1

    Die Ausgabe sollte in etwa so aussehen:

    Stack: corosync
    Current DC: hana-ha-vm-2 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
    Last updated: Tue Jun 16 20:07:51 2020
    Last change: Tue Jun 16 20:07:26 2020 by root via crm_attribute on hana-ha-vm-1
    
    2 nodes configured
    6 resources configured
    
    Online: [ hana-ha-vm-1 hana-ha-vm-2 ]
    
    Active resources:
    
    STONITH-hana-ha-vm-1   (stonith:fence_gce):    Started hana-ha-vm-2
    STONITH-hana-ha-vm-2   (stonith:fence_gce):    Started hana-ha-vm-1
    Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
        Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
    Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
        Masters: [ hana-ha-vm-1 ]
        Slaves: [ hana-ha-vm-2 ]
    
    Node Attributes:
    * Node hana-ha-vm-1:
       + hana_ha1_clone_state              : PROMOTED
       + hana_ha1_op_mode                  : logreplay
       + hana_ha1_remoteHost               : hana-ha-vm-2
       + hana_ha1_roles                    : 4:P:master1:master:worker:master
       + hana_ha1_site                     : hana-ha-vm-1
       + hana_ha1_srmode                   : syncmem
       + hana_ha1_sync_state               : PRIM
       + hana_ha1_version                  : 1.00.122.27.1568902538
       + hana_ha1_vhost                    : hana-ha-vm-1
       + lpa_ha1_lpt                       : 1592338046
       + master-SAPHana_HA1_22             : 150
    * Node hana-ha-vm-2:
       + hana_ha1_clone_state              : DEMOTED
       + hana_ha1_op_mode                  : logreplay
       + hana_ha1_remoteHost               : hana-ha-vm-1
       + hana_ha1_roles                    : 4:S:master1:master:worker:master
       + hana_ha1_site                     : hana-ha-vm-2
       + hana_ha1_srmode                   : syncmem
       + hana_ha1_sync_state               : SOK
       + hana_ha1_version                  : 1.00.122.27.1568902538
       + hana_ha1_vhost                    : hana-ha-vm-2
       + lpa_ha1_lpt                       : 30
       + master-SAPHana_HA1_22             : 100

Virtuelle IP-Adressressource erstellen

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

Als Root auf einem Host:

# pcs resource create resource_name \
  IPaddr2 ip="vip-address" nic=eth0 cidr_netmask=32

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

Einschränkungen erstellen

Mit Einschränkungen legen Sie fest, welche Dienste zuerst gestartet werden müssen und welche Dienste zusammen auf demselben Host ausgeführt werden müssen. Die IP-Adresse muss sich beispielsweise auf demselben Host wie die primäre HANA-Instanz befinden.

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

    # pcs constraint order topology_resource_name-clone \
      then sap_hana_resource_name-master symmetrical=false

    Die Angabe von symmetrical=false bedeutet, dass die Einschränkung nur beim Start und nicht beim Herunterfahren gilt.

    Da Sie jedoch in einem vorherigen Schritt für diese Ressourcen interleave=true festgelegt haben, können die Prozesse parallel gestartet werden. Mit anderen Worten, Sie können SAPHana auf jedem Knoten starten, sobald SAPHanaTopology ausgeführt wird.

  2. Definieren Sie die Colocation-Einschränkung:

    # pcs constraint colocation add vip_resource_name \
      with master sap_hana_resource_name-master 4000

    Wenn Sie anstelle des Standardwertes INFINITY den Wert 4000 festlegen, kann der Cluster die IPaddr2-Ressource deaktivieren, wenn kein Master in der SAPHana-Ressource hochgestuft wird. Auf diese Weise können Tools wie SAP Management Console oder SAP LaMa die Adresse verwenden, um den Status der SAP-Instanz abzufragen.

  3. Prüfen Sie die Einschränkungen:

    # pcs constraint

    Die Ausgabe sollte in etwa so aussehen:

    Location Constraints:
     Resource: STONITH-hana-ha-vm-1
       Enabled on: hana-ha-vm-2 (score:INFINITY)
     Resource: STONITH-hana-ha-vm-2
       Enabled on: hana-ha-vm-1 (score:INFINITY)
    Ordering Constraints:
     start SAPHanaTopology_HA1_22-clone then start SAPHana_HA1_22-master (kind:Mandatory) (non-symmetrical)
    Colocation Constraints:
     rsc_vip_HA1_22 with SAPHana_HA1_22-master (score:4000) (rsc-role:Started) (with-rsc-role:Master)
    Ticket Constraints:

Listener installieren und Systemdiagnose-Ressource erstellen

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

Listener installieren

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

  1. Installieren Sie als Root auf jedem Host einen einfachen TCP-Listener. In dieser Anleitung wird HAProxy als Listener installiert und verwendet.

    # yum install haproxy
  2. Öffnen Sie die Konfigurationsdatei haproxy.cfg zur Bearbeitung:

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

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

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

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

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

      #---------------------------------------------------------------------
      # common defaults that all the 'listen' and 'backend' sections will
      # use if not designated in their block
      #---------------------------------------------------------------------
      defaults
        mode                    tcp
        log                     global
        option                  httplog
        option                  dontlognull
        option http-server-close
        option forwardfor       except 127.0.0.0/8
        option                  redispatch
        retries                 3
        timeout http-request    10s
        timeout queue           1m
        timeout connect         10s
        timeout client          1m
        timeout server          1m
        timeout http-keep-alive 10s
        timeout check           10s
        maxconn                 3000
      
      #---------------------------------------------------------------------
      # Set up health check listener for SAP HANA HA cluster
      #---------------------------------------------------------------------
      listen healthcheck
       bind *:60000
  3. Starten Sie als Root den Dienst auf jedem Host, um zu prüfen, ob er richtig konfiguriert ist:

    # systemctl start haproxy.service
  4. Klicken Sie in der Cloud Console auf der Seite "Load-Balancer" auf den Load-Balancer-Eintrag:

    Seite "Load-Balancing"

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

    Screenshot mit der Anzeige

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

    # systemctl stop haproxy.service

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

    Screenshot mit der Anzeige

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

Systemdiagnose-Ressource erstellen

  1. Erstellen Sie als Root auf jedem Host eine Systemdiagnose-Ressource für den HAProxy-Dienst:

    # pcs resource create healthcheck_resource_name service:haproxy
  2. Prüfen Sie, ob der Systemdiagnosedienst auf demselben Host wie Ihre Master-SAP HANA-Instanz und Ihre VIP-Ressource aktiv ist:

    # pcs status

    Wenn sich die Systemdiagnose-Ressource nicht auf dem primären Host befindet, verschieben Sie sie mit dem folgenden Befehl:

    # pcs resource move healthcheck_resource_name target_host_name
    # pcs resource clear healthcheck_resource_name

    Der Befehl pcs resource clear belässt die Ressource an ihrem neuen Speicherort, entfernt aber die unerwünschte Standortbeschränkung, die mit dem Befehl pcs resource move erstellt wurde.

    Der Status im Bereich "Ressourcen" sollte in etwa so aussehen:

    Full list of resources:
    
    STONITH-hana-ha-vm-1   (stonith:fence_gce):    Started hana-ha-vm-2
    STONITH-hana-ha-vm-2   (stonith:fence_gce):    Started hana-ha-vm-1
    Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
        Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
    Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
        Masters: [ hana-ha-vm-1 ]
        Slaves: [ hana-ha-vm-2 ]
    rsc_vip_HA1_22 (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-1
    rsc_healthcheck_HA1    (service:haproxy):      Started hana-ha-vm-2
  3. Gruppieren Sie die Ressourcen für VIP und Systemdiagnose:

    # pcs resource group add rsc-group-name healthcheck_resource_name vip_resource_name

    Im Clusterstatus sollte der Bereich "Ressourcen" in etwa so aussehen:

    Full list of resources:
    
    STONITH-hana-ha-vm-1   (stonith:fence_gce):    Started hana-ha-vm-2
    STONITH-hana-ha-vm-2   (stonith:fence_gce):    Started hana-ha-vm-1
    Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
        Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
    Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
        Masters: [ hana-ha-vm-1 ]
        Slaves: [ hana-ha-vm-2 ]
    Resource Group: g-primary
        rsc_healthcheck_HA1        (service:haproxy):      Started hana-ha-vm-1
        rsc_vip_HA1_22     (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-1
  4. Erstellen Sie eine Einschränkung, die die neue Gruppe demselben Knoten zuweist, auf dem sich auch die Master-SAP HANA-Instanz befindet.

    # pcs constraint colocation add rsc-group-name with master sap_hana_resource_name-master 4000

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

    # pcs constraint
    Location Constraints:
     Resource: STONITH-hana-ha-vm-1
       Enabled on: hana-ha-vm-2 (score:INFINITY)
     Resource: STONITH-hana-ha-vm-2
       Enabled on: hana-ha-vm-1 (score:INFINITY)
    Ordering Constraints:
     start SAPHanaTopology_HA1_22-clone then start SAPHana_HA1_22-master (kind:Mandatory) (non-symmetrical)
    Colocation Constraints:
     rsc_vip_HA1_22 with SAPHana_HA1_22-master (score:4000) (rsc-role:Started) (with-rsc-role:Master)
     g-primary with SAPHana_HA1_22-master (score:4000) (rsc-role:Started) (with-rsc-role:Master)
    Ticket Constraints:

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 pcs status ein, um zu prüfen, ob der primäre Host jetzt auf der VM aktiv ist, auf der sich zuvor der sekundäre Host befand. Da im Cluster der automatische Neustart aktiviert ist, wird der angehaltene Host neu gestartet und übernimmt wie im folgenden Beispiel gezeigt die Rolle des sekundären Hosts.

    Cluster name: hana-ha-cluster
    Stack: corosync
    Current DC: hana-ha-vm-2 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
    Last updated: Wed Jun 17 01:04:36 2020
    Last change: Wed Jun 17 01:03:58 2020 by root via crm_attribute on hana-ha-vm-2
    
    2 nodes configured
    8 resources configured
    
    Online: [ hana-ha-vm-1 hana-ha-vm-2 ]
    
    Full list of resources:
    
    STONITH-hana-ha-vm-1   (stonith:fence_gce):    Started hana-ha-vm-2
    STONITH-hana-ha-vm-2   (stonith:fence_gce):    Started hana-ha-vm-1
    Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
        Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
    Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
        Masters: [ hana-ha-vm-2 ]
        Slaves: [ hana-ha-vm-1 ]
    Resource Group: g-primary
        rsc_healthcheck_HA1        (service:haproxy):      Started hana-ha-vm-2
        rsc_vip_HA1_22     (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-2
    
    Daemon Status:
     corosync: active/enabled
     pacemaker: active/enabled
     pcsd: active/enabled

Fehlerbehebung

Sie finden die Logs in den folgenden Verzeichnissen:

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

Gültiger Clusterstatus:

# pcs status
Cluster name: hana-ha-cluster
Stack: corosync
Current DC: hana-ha-vm-1 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
Last updated: Wed Jun 17 00:34:16 2020
Last change: Wed Jun 17 00:34:09 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:fence_gce):    Started hana-ha-vm-2
 STONITH-hana-ha-vm-2   (stonith:fence_gce):    Started hana-ha-vm-1
 Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
     Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
 Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
     Masters: [ hana-ha-vm-1 ]
     Slaves: [ hana-ha-vm-2 ]
 Resource Group: g-primary
     rsc_healthcheck_HA1        (service:haproxy):      Started hana-ha-vm-1
     rsc_vip_HA1_22     (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-1

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

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

Ressourcen mit weiterführenden Informationen: