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

In dieser Anleitung erfahren Sie, wie Sie einen leistungsoptimierten SLES-Hochverfügbarkeitscluster (SUSE Linux Enterprise Server) für das SAP NetWeaver-System bereitstellen und konfigurieren.

Die Anleitung umfasst folgende Schritte:

  • 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

Dieser Leitfaden enthält auch Schritte zum Konfigurieren des SAP NetWeaver-Systems für hohe Verfügbarkeit. Eine ausführliche Anleitung finden Sie in der SAP-Dokumentation.

Informationen zum Bereitstellen von Compute Engine-VMs für SAP NetWeaver, die nicht spezifisch für Hochverfügbarkeit sind, finden Sie im Bereitstellungsleitfaden für SAP NetWeaver, der für Ihr Betriebssystem spezifisch ist.

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

System, das in dieser Anleitung bereitgestellt wird

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

Übersicht über einen Linux-Hochverfügbarkeitscluster für ein SAP NetWeaver-System mit einem einzelnen Knoten

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

  • Zwei Host-VMs, eine mit einem aktiven SAP Central Services und eine mit einem aktiven Standalone Enqueue Server
  • 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 bereitgestellten Cloud Deployment Manager-Vorlagen, um die virtuellen Compute Engine-Maschinen (VMs) bereitzustellen. Dadurch wird sichergestellt, dass die VMs die Anforderungen der SAP-Unterstützung erfüllen und den aktuellen Best Practices entsprechen.

Vorbereitung

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

Sofern in der Google Cloud-Umgebung nicht erforderlich, entsprechen die Informationen in dieser Anleitung den folgenden verwandten Leitfäden von SUSE:

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 den folgenden Befehl aus, um ein neues Netzwerk im benutzerdefinierten Subnetzwerkmodus zu erstellen:

    gcloud compute networks create NETWORK_NAME --subnet-mode custom

    Ersetzen Sie NETWORK_NAME durch den Namen des neuen Clusters. 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 SUBNETWORK_NAME \
            --network NETWORK_NAME --region REGION --range RANGE

    Dabei gilt:

    • SUBNETWORK_NAME: der Name des neuen Subnetzwerks.
    • NETWORK_NAME: der Name des Netzwerks, das Sie im vorherigen Schritt erstellt haben.
    • REGION: die Region, in der sich das Subnetzwerk befinden soll.
    • RANGE: 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üssen, müssen Sie die Network Address Translation (NAT) verwenden, damit die VMs auf das Internet zugreifen können. Verwenden Sie Cloud NAT, einen verteilten, softwarebasierten verwalteten Dienst von Google Cloud, der es VMs ermöglicht, ausgehende Pakete an das Internet zu senden und entsprechende eingehende Antwortpakete zu empfangen. Alternativ können Sie eine separate VM als NAT-Gateway einrichten.

Informationen zum Erstellen einer Cloud NAT-Instanz für Ihr Projekt finden Sie unter Cloud NAT verwenden.

Nachdem Sie Cloud NAT für Ihr Projekt konfiguriert haben, können Ihre VM-Instanzen ohne öffentliche IP-Adressen sicher auf das Internet zugreifen.

Firewallregeln festlegen

Standardmäßig werden von außerhalb Ihres Google Cloud-Netzwerks eingehende Verbindungen blockiert. Wenn Sie eingehende Verbindungen zulassen möchten, richten Sie für Ihre VM eine entsprechende Firewallregel ein. Firewallregeln regulieren nur neue eingehende Verbindungen zu einer VM. Nachdem eine Verbindung zu einer VM hergestellt wurde, ist Traffic über diese Verbindung in beide Richtungen zulässig.

Sie können eine Firewallregel erstellen, um den Zugriff auf bestimmte Ports oder zwischen VMs im selben Subnetzwerk zuzulassen.

Erstellen Sie Firewallregeln, um den Zugriff für Folgendes zu ermöglichen:

  • Die von SAP NetWeaver verwendeten Standardports, wie unter TCP/IP-Ports aller SAP-Produkte dokumentiert.
  • 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 in einer dreistufigen Konfiguration, einer horizontal skalierbaren Konfiguration oder einer Hochverfügbarkeitskonfiguration. Wenn Sie beispielsweise ein dreistufiges System bereitstellen, befinden sich mindestens zwei VMs in Ihrem Subnetzwerk: die VM für SAP NetWeaver und eine andere VM für den Datenbankserver. Damit eine Kommunikation zwischen beiden VMs stattfinden kann, müssen Sie eine Firewallregel erstellen, die Traffic aus dem Subnetzwerk zulässt.
  • Systemdiagnosen für Cloud Load Balancing. Weitere Informationen finden Sie unter Firewallregel für die Systemdiagnosen erstellen.

So erstellen Sie eine Firewallregel:

  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.
    • Wählen Sie im Feld Ziele die Option Alle Instanzen im Netzwerk aus.
    • 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 Subnetzwerk 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]; an.
  3. Klicken Sie auf Erstellen, um die Firewallregel zu erstellen.

VMs für SAP NetWeaver bereitstellen

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

Zum Definieren und Bereitstellen der VMs verwenden Sie dieselbe Cloud Deployment Manager-Vorlage, die Sie zum Bereitstellen einer VM für ein SAP NetWeaver-System in der automatischen VM-Bereitstellung für SAP NetWeaver unter Linux verwenden.

Wenn Sie jedoch statt einer VM zwei VMs bereitstellen möchten, müssen Sie die Definition für die zweite VM der Konfigurationsdatei hinzufügen. Kopieren Sie hierfür die Definition der ersten VM 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 VMs bereitgestellt wurden, installieren Sie SAP NetWeaver und definieren und konfigurieren den Hochverfügbarkeitscluster.

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

  1. Cloud Shell öffnen

    Zu Cloud Shell

  2. Laden Sie die YAML-Konfigurationsdateivorlage template.yaml in Ihr Arbeitsverzeichnis herunter:

    wget https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/template.yaml

  3. Sie können die Datei template.yaml so umbenennen, dass die von ihr definierte Konfiguration im Namen erkennbar ist. Beispiel: nw-ha-sles15sp1.yaml.

  4. Öffnen Sie die YAML-Konfigurationsdatei im Cloud Shell-Code-Editor. Klicken Sie dazu im Cloud Shell-Terminalfenster auf das Stiftsymbol (), um den Editor zu starten.

  5. Definieren Sie in der YAML-Konfigurationsdateivorlage die erste VM-Instanz. Die zweite VM-Instanz wird im nächsten Schritt nach der folgenden Tabelle definiert.

    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. Ein Beispiel für eine vollständige Konfigurationsdatei finden Sie unter Beispiel für eine vollständige YAML-Konfigurationsdatei.

    Attribut Datentyp Beschreibung
    name String Beliebiger Name, der die Deployment-Ressource identifiziert, die durch die folgenden Attribute definiert wird.
    Typ String

    Gibt Speicherort, Typ und Version der Deployment Manager-Vorlage an, die während der Bereitstellung verwendet werden sollen.

    Die YAML-Datei enthält zwei type-Spezifikationen, von denen eine auskommentiert ist. Für die standardmäßig aktive type-Spezifikation ist die Vorlagenversion als latest angegeben. Die auskommentierte type-Spezifikation gibt eine bestimmte Vorlagenversion mit einem Zeitstempel an.

    Wenn Sie möchten, dass alle Ihre Bereitstellungen die gleiche Vorlagenversion nutzen, verwenden Sie die type-Spezifikation, die den Zeitstempel enthält.

    instanceName String Der Name der VM-Instanz, die Sie definieren. Geben Sie in der primären und sekundären VM-Definition unterschiedliche Namen an. Verwenden Sie Namen, mit denen die Instanzen als Teil desselben Hochverfügbarkeitsclusters identifiziert werden.

    Instanznamen dürfen aus höchstens 13 Zeichen bestehen und müssen mit Kleinbuchstaben, Zahlen oder Bindestrichen angegeben werden. Verwenden Sie einen Namen, der in Ihrem Projekt eindeutig ist.

    instanceType String Der der Compute Engine-VM-Typ, den Sie benötigen. Geben Sie für die primäre und die sekundäre VM denselben Instanztyp an.

    Wenn Sie einen benutzerdefinierten VM-Typ benötigen, geben Sie einen kleinen vordefinierten VM-Typ an und passen Sie die VM nach Bedarf an, nachdem die Bereitstellung abgeschlossen ist.

    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 Der Name des Subnetzwerks, 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 NetWeaver 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 Eine Liste der verfügbaren Image-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 das Google Cloud-Image-Projekt suse-sap-cloud sein. Eine Liste der Google Cloud-Image-Projekte finden Sie auf der Seite Images in der Dokumentation zu Compute Engine.
    usrsapSize Ganzzahl Die Größe des /usr/sap-Laufwerks. Die Mindestgröße beträgt 8 GB.
    sapmntSize Ganzzahl Die Größe des /sapmnt-Laufwerks. Die Mindestgröße beträgt 8 GB.
    swapSize Integer Die Größe des Auslagerungs-Volumes. Die Mindestgröße beträgt 1 GB.
    networkTag String

    Optional. Ein oder mehrere durch Kommas getrennte Netzwerk-Tags, die Ihre VM-Instanz für Firewall- oder Routingzwecke darstellen.

    Geben Sie für Hochverfügbarkeitskonfigurationen ein Netzwerktag an, das für eine Firewallregel verwendet werden soll, die Kommunikation zwischen den Clusterknoten zulässt, und ein Netzwerktag zur Verwendung in einer Firewallregel, die Cloud Load Balancing-Systemdiagnosen den Zugriff auf die Clusterknoten ermöglicht.

    Wenn Sie "publicIP: No", aber kein Netzwerk-Tag angeben, müssen Sie eine andere Möglichkeit für den Zugriff auf das Internet bereitstellen.

    serviceAccount String

    Optional. Gibt ein benutzerdefiniertes Dienstkonto an, das für die bereitgestellte VM verwendet werden soll. Das Dienstkonto muss die Berechtigungen enthalten, die während der Bereitstellung zum Konfigurieren der VM für SAP erforderlich sind.

    Wenn serviceAccount nicht angegeben ist, wird das Compute Engine-Standarddienstkonto verwendet.

    Geben Sie die vollständige Dienstkontoadresse an. Beispiel: sap-ha-example@example-project-123456.iam.gserviceaccount.com

    publicIP Boolesch Optional. Legt fest, ob Ihre VM-Instanz eine öffentliche IP-Adresse erhält. Der Standardwert ist Yes.
    sap_deployment_debug Boolesch Optional. Wenn dieser Wert auf Yes festgelegt ist, werden bei der Bereitstellung ausführliche Bereitstellungslogs generiert. Aktivieren Sie diese Einstellung nur, falls ein Google-Supporttechniker Sie bittet, das Debugging zu aktivieren.
  6. Erstellen Sie in der YAML-Konfigurationsdatei die Definition der zweiten VM. Kopieren Sie dazu die Definition der ersten VM und Fügen Sie die Kopie nach der ersten Definition ein. Ein Beispiel finden Sie unter Beispiel für eine vollständige YAML-Konfigurationsdatei.

  7. Geben Sie in der Definition der zweiten VM für die folgenden Attribute andere Werte als in der ersten Definition an:

    • name
    • instanceName
    • zone
  8. Erstellen Sie die VM-Instanzen:

    gcloud deployment-manager deployments create [DEPLOYMENT_NAME] --config [TEMPLATE_NAME].yaml

    Dabei gilt:

    • [DEPLOYMENT_NAME] steht für den Namen Ihres Deployments.
    • [TEMPLATE_NAME] steht für den Namen Ihrer YAML-Konfigurationsdatei.

    Der vorhergehende Befehl ruft den Deployment Manager auf, um die VMs entsprechend den Angaben in der YAML-Konfigurationsdatei bereitstellen zu lassen.

    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 YAML-Konfigurationsdatei

Das folgende Beispiel zeigt eine abgeschlossene YAML-Konfigurationsdatei, die zwei VM-Instanzen für eine HA-Konfiguration für SAP NetWeaver mithilfe der neuesten Version der Deployment Manager-Vorlagen bereitstellt. In diesem Beispiel werden die Kommentare ausgelassen, die beim ersten Download in der Vorlage enthalten sind.

Die Datei enthält die Definitionen der beiden Ressourcen, die bereitgestellt werden sollen: sap_nw_node_1 und sap_nw_node_2. Jede Ressourcendefinition enthält die Definitionen für eine VM.

Die Ressourcendefinition sap_nw_node_2 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 und serviceAccount stammen aus dem Abschnitt "Erweiterte Optionen" der Vorlage für die Konfigurationsdatei.

resources:
- name: sap_nw_node_1
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/sap_nw.py
  properties:
    instanceName: nw-ha-vm-1
    instanceType: n2-standard-4
    zone: us-central1-b
    subnetwork: example-sub-network-sap
    linuxImage: family/sles-15-sp2-sap
    linuxImageProject: suse-sap-cloud
    usrsapSize: 15
    sapmntSize: 15
    swapSize: 24
    networkTag: cluster-ntwk-tag,allow-health-check
    serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com
- name: sap_nw_node_2
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/sap_nw.py
  properties:
    instanceName: nw-ha-vm-2
    instanceType: n2-standard-4
    zone: us-central1-c
    subnetwork: example-sub-network-sap
    linuxImage: family/sles-15-sp2-sap
    linuxImageProject: suse-sap-cloud
    usrsapSize: 15
    sapmntSize: 15
    swapSize: 24
    networkTag: cluster-ntwk-tag,allow-health-check
    serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com

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
  • Die Systemdiagnosen, die von Cloud Load Balancing verwendet werden, wie unter Firewallregel für die Systemdiagnosen erstellen beschrieben.

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 prüfen

Prüfen Sie vor der Installation von SAP NetWeaver oder der Konfiguration des Hochverfügbarkeitsclusters, ob die VMs ordnungsgemäß bereitgestellt wurden. Prüfen Sie dazu die Logs und die Speicherzuordnung des Betriebssystems.

Logs prüfen

In den folgenden Schritten wird Cloud Logging verwendet. Hierfür können Gebühren anfallen. Weitere Informationen finden Sie unter Cloud Logging – Preise.

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

    Zu Logging

  2. Wählen Sie auf dem Tab Ressourcen die Option Global als Logging-Ressource aus. Wenn für eine VM INSTANCE DEPLOYMENT COMPLETE angezeigt wird, ist die Deployment Manager-Verarbeitung für die VM abgeschlossen.

    Logging-Anzeige

Konfiguration der VMs prüfen

  1. Stellen Sie nach der Bereitstellung der VM-Instanzen mithilfe von ssh eine Verbindung zu den VMs her.

    1. Erstellen Sie eine Firewallregel, um eine SSH-Verbindung über Port 22 zuzulassen, wenn nicht bereits geschehen.
    2. Wechseln Sie zur Seite VM-Instanzen.

      Zur Seite "VM-Instanzen"

    3. Stellen Sie eine Verbindung zu den einzelnen VM-Instanzen her, indem Sie für den jeweiligen Eintrag auf die Schaltfläche SSH klicken. Sie können auch Ihre bevorzugte SSH-Methode verwenden.

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

  2. Rufen Sie das Dateisystem auf:

    ~> df -h

    Prüfen Sie, ob eine Ausgabe ähnlich der folgenden angezeigt wird:

    Filesystem                 Size  Used Avail Use% Mounted on
    devtmpfs                    32G  8.0K   32G   1% /dev
    tmpfs                       48G     0   48G   0% /dev/shm
    tmpfs                       32G  402M   32G   2% /run
    tmpfs                       32G     0   32G   0% /sys/fs/cgroup
    /dev/sda3                   30G  3.4G   27G  12% /
    /dev/sda2                   20M  3.7M   17M  19% /boot/efi
    /dev/mapper/vg_usrsap-vol   15G   48M   15G   1% /usr/sap
    /dev/mapper/vg_sapmnt-vol   15G   48M   15G   1% /sapmnt
    tmpfs                      6.3G     0  6.3G   0% /run/user/1002
    tmpfs                      6.3G     0  6.3G   0% /run/user/0
  3. Prüfen Sie, ob das Auslagerungsverzeichnis erstellt wurde:

    ~> cat /proc/meminfo | grep Swap

    Die Ausgabe sollte diesem Beispiel ähneln:

    SwapCached:            0 kB
    SwapTotal:      25161724 kB
    SwapFree:       25161724 kB

Wenn einer der Überprüfungsschritte auf eine fehlgeschlagene Installation hindeutet:

  1. Korrigieren Sie den Fehler.
  2. Löschen Sie auf der Seite "Deployments" das Deployment, um die VMs und nichtflüchtigen Speicher aus der fehlgeschlagenen Installation zu entfernen.
  3. Führen Sie das Deployment noch einmal aus.

Aktualisieren Sie das Cloud SDK:

Die Deployment Manager-Vorlage hat das Cloud SDK während der Bereitstellung auf den VMs installiert. Aktualisieren Sie das Cloud SDK, damit es sämtliche neuesten Updates enthält.

  1. Stellen Sie eine SSH-Verbindung zur primären VM her.

  2. Aktualisieren Sie das Cloud SDK:

    ~>  sudo gcloud components update
  3. Führen Sie dazu die angezeigten Schritte aus.

  4. Wiederholen Sie die Schritte auf der sekundären VM.

Back-End-Kommunikation der Load-Balancer zwischen den VMs aktivieren

Nachdem Sie geprüft haben, ob die VMs erfolgreich bereitgestellt wurden, aktivieren Sie die Back-End-Kommunikation zwischen den VMs, die als Knoten in Ihrem HA-Cluster dienen.

  1. Aktivieren Sie auf jeder VM im HA-Cluster das lokale Routing.

    1. Stellen Sie eine SSH-Verbindung zu jeder VM in Ihrem geplanten Cluster her.
    2. Wechseln Sie zum Root-Nutzer.
    3. Aktivieren Sie auf jedem Computer das lokale Routing für die primäre Schnittstelle mit dem folgenden Befehl. Wenn Sie eine andere Schnittstelle als eth0 verwenden, geben Sie diese Schnittstelle im Befehl anstelle von eth0 an.

      echo net.ipv4.conf.eth0.accept_local=1 >> /etc/sysctl.conf
      sysctl -p

      Mit dem vorherigen Befehl wird die Einstellung in die Konfigurationsdatei geschrieben.

  2. Erstellen Sie auf jeder VM ein Startskript, um die Kommunikation zwischen Back-Ends zu aktivieren:

    Cloud Console

    1. Rufen Sie in der Cloud Console die Seite "VM-Instanzen" auf.

      Zur Seite "VM-Instanzen"

    2. Klicken Sie auf den Namen der primären VM.

    3. Klicken Sie auf der Seite VM-Instanzdetails auf die Schaltfläche BEARBEITEN.

    4. Klicken Sie im Abschnitt Benutzerdefinierte Metadaten auf Element hinzufügen.

    5. Geben Sie im Feld Schlüssel startup-script ein.

    6. Fügen Sie das folgende Bash-Skript in das Feld Wert ein:

      #! /bin/bash
      # VM startup script
      
      nic0_mac="$(curl -H "Metadata-Flavor:Google" \
      --connect-timeout 5 --retry 5 --retry-max-time 60 \
      http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/mac)"
      
      nic0_ip="$(curl -H "Metadata-Flavor:Google" \
      --connect-timeout 5 --retry 5 --retry-max-time 60 \
      http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/ip)"
      
      for nic in $(ls /sys/class/net); do
      nic_addr=$(cat /sys/class/net/"${nic}"/address)
      if [ "$nic_addr" == "$nic0_mac" ]; then
        nic0_name="$nic"
        break
      fi
      done
      
      [[ -n $nic0_name ]] && [[ -n $nic0_ip ]] \
      && logger -i "gce-startup-script: INFO adding IP configuration for ILB client" \
      || logger -i "gce-startup-script: ERROR could not determine IP or interface name"
      
      if [ -n "$nic0_name" ]; then
      ip rule del from all lookup local
      ip rule add pref 0 from all iif "${nic0_name}" lookup local
      ip route add local "${nic0_ip}" dev "${nic0_name}" proto kernel \
        scope host src "${nic0_ip}" table main
      ip route add local 127.0.0.0/8 dev lo proto kernel \
        scope host src 127.0.0.1 table main
      ip route add local 127.0.0.1 dev lo proto kernel \
        scope host src 127.0.0.1 table main
      ip route add broadcast 127.0.0.0 dev lo proto kernel \
        scope link src 127.0.0.1 table main
      ip route add broadcast 127.255.255.255 dev lo proto kernel \
        scope link src 127.0.0.1 table main
      fi
    7. Klicken Sie unten auf der Seite auf Speichern.

    8. Starten Sie den Server neu, damit das Startskript wirksam wird.

      Wenn Sie fertig sind, sollten Ihre benutzerdefinierten Metadaten in etwa so aussehen:

      Screenshot mit "startup-script" mit anderen Einträgen im Abschnitt "Benutzerdefinierte Metadaten" auf der Seite "VM-Details" in der Cloud Console

    9. Wiederholen Sie die vorherigen Schritte für den sekundären Server.

    gcloud

    1. Verwenden Sie in Cloud Shell oder an jedem Ort, an dem das Cloud SDK installiert ist, den folgenden gcloud-Befehl mit dem enthaltenen Startskript, um den Instanzmetadaten für jede VM ein Startskript hinzuzufügen. Ersetzen Sie die Variablen durch den Namen und die Zone der VM, bevor Sie den Befehl eingeben.

      gcloud compute instances add-metadata primary-vm-name \
      --zone=primary-vm-zone --metadata=startup-script='#! /bin/bash
      # VM startup script
      
      nic0_mac="$(curl -H "Metadata-Flavor:Google" \
      --connect-timeout 5 --retry 5 --retry-max-time 60 \
      http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/mac)"
      
      nic0_ip="$(curl -H "Metadata-Flavor:Google" \
      --connect-timeout 5 --retry 5 --retry-max-time 60 \
      http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/ip)"
      
      for nic in $(ls /sys/class/net); do
      nic_addr=$(cat /sys/class/net/"${nic}"/address)
      if [ "$nic_addr" == "$nic0_mac" ]; then
        nic0_name="$nic"
        break
      fi
      done
      
      [[ -n $nic0_name ]] && [[ -n $nic0_ip ]] \
      && logger -i "gce-startup-script: INFO adding IP configuration for ILB client" \
      || logger -i "gce-startup-script: ERROR could not determine IP or interface name"
      
      if [ -n "$nic0_name" ]; then
      ip rule add pref 0 from all iif "${nic0_name}" lookup local
      ip rule del from all lookup local
      ip route add local "${nic0_ip}" dev "${nic0_name}" proto kernel \
        scope host src "${nic0_ip}" table main
      ip route add local 127.0.0.0/8 dev lo proto kernel \
        scope host src 127.0.0.1 table main
      ip route add local 127.0.0.1 dev lo proto kernel \
        scope host src 127.0.0.1 table main
      ip route add broadcast 127.0.0.0 dev lo proto kernel \
        scope link src 127.0.0.1 table main
      ip route add broadcast 127.255.255.255 dev lo proto kernel \
        scope link src 127.0.0.1 table main
      fi'
    2. Starten Sie den Server neu, damit das Startskript wirksam wird.

    3. Mit dem folgenden Befehl können Sie prüfen, ob das Startskript in den Instanzmetadaten gespeichert ist:

      gcloud compute instances describe primary-vm-name \
      --zone=primary-vm-zone

      Das Startskript wird in der Ausgabe unter metadata angezeigt, wie im folgenden Beispielauszug gezeigt:

      metadata:
      fingerprint: Tbuij9k-knk=
      items:
      - key: post_deployment_script
      value: ''
      - key: sap_deployment_debug
      value: 'False'
      - key: status
      value: completed
      - key: startup-script
      value: |-
        #! /bin/bash
        # VM startup script
        ...
        [example truncated]
    4. Wiederholen Sie für die sekundäre VM die vorherigen Schritte, nachdem Sie die Variablenwerte durch die Werte für die sekundäre VM-Instanz ersetzt haben.

Weitere Informationen zum Erstellen von Startskripts für Compute Engine-VMs finden Sie unter Startskripts ausführen.

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

Damit Dateien zwischen den Hosts im Hochverfügbarkeitscluster kopiert werden können, erstellen die Schritte in diesem Abschnitt Root-SSH-Verbindungen zwischen den beiden Hosts.

Von Google Cloud bereitgestellte Deployment Manager-Vorlagen generieren automatisch einen Schlüssel. Sie können diesen Schlüssel jedoch durch einen von Ihnen generierten Schlüssel ersetzen.

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 Dateien mit anderen Methoden übertragen. Beispiele:

  • Übertragen Sie kleinere Dateien über Ihre lokale Workstation mithilfe der Cloud Shell-Menüoptionen Datei hochladen und Datei herunterladen. Siehe dazu Dateien mit Cloud Shell verwalten.
  • Tauschen Sie Dateien mithilfe eines Google Cloud Storage-Buckets aus. Siehe dazu Mit Objekten arbeiten in der Cloud Storage-Dokumentation.
  • Verwenden Sie eine Dateispeicherlösung wie Filestore oder den NetApp Cloud Volumes-Dienst, um einen freigegebenen Ordner zu erstellen. Siehe Lösungen zur Dateifreigabe.

So aktivieren Sie SSH-Verbindungen zwischen der primären und der sekundären Instanz: In den nächsten Schritten wird davon ausgegangen, dass Sie den SSH-Schlüssel verwenden, der von den Deployment Manager-Vorlagen für SAP generiert wird.

  1. Auf der primären Host-VM:

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

    2. Wechseln Sie zum Root:

      $ sudo su -
    3. Prüfen Sie, ob der SSH-Schlüssel vorhanden ist:

      # ls -l /root/.ssh/

      Die id_rsa-Schlüsseldateien werden wie im folgenden Beispiel angezeigt:

      -rw-r--r-- 1 root root  569 May  4 23:07 authorized_keys
      -rw------- 1 root root 2459 May  4 23:07 id_rsa
      -rw-r--r-- 1 root root  569 May  4 23:07 id_rsa.pub
    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-vm-name \
      --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" --zone secondary-vm-zone
    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 secondary-vm-name
  2. Auf der sekundären Host-VM:

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

    2. Wechseln Sie zum Root:

      $ sudo su -
    3. Prüfen Sie, ob der SSH-Schlüssel vorhanden ist:

      # ls -l /root/.ssh/

      Die id_rsa-Schlüsseldateien werden wie im folgenden Beispiel angezeigt:

      -rw-r--r-- 1 root root  569 May  4 23:07 authorized_keys
      -rw------- 1 root root 2459 May  4 23:07 id_rsa
      -rw-r--r-- 1 root root  569 May  4 23:07 id_rsa.pub
    4. 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-vm-name \
      --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" --zone primary-zone
      # 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-vm-name

Freigegebenen Dateispeicher einrichten und freigegebene Verzeichnisse konfigurieren

Sie müssen eine NFS-Dateifreigabelösung einrichten, die hochverfügbaren freigegebenen Dateispeicher bietet, auf den beide Knoten Ihres Hochverfügbarkeitsclusters zugreifen können. Anschließend erstellen Sie auf beiden Knoten Verzeichnisse, die dem freigegebenen Dateispeicher zugeordnet sind. Die Clustersoftware sorgt dafür, dass die entsprechenden Verzeichnisse nur auf den richtigen Instanzen bereitgestellt werden.

Das Einrichten einer Dateifreigabelösung wird in dieser Anleitung nicht behandelt. Eine Anleitung zum Einrichten des Dateifreigabesystems finden Sie in der Anleitung des Anbieters der von Ihnen ausgewählten Lösung.

Informationen zu den Lösungen für die Dateifreigabe in Google Cloud finden Sie unter Optionen für freigegebenen Speicher für SAP-SAP-Systeme in Google Cloud.

So konfigurieren Sie die freigegebenen Verzeichnisse:

  1. Wenn Sie noch keine hochverfügbare NFS-Dateifreigabelösung eingerichtet haben, tun Sie dies jetzt.

  2. Stellen Sie den freigegebenen NFS-Speicher auf beiden Servern für die Erstkonfiguration bereit.

    ~> sudo mkdir /mnt/nfs
    ~> sudo mount -t nfs nfs-path /mnt/nfs
  3. Erstellen Sie auf beiden Servern Verzeichnisse für sapmnt, das zentrale Transportverzeichnis, das Systemverzeichnis und das instanzspezifische Verzeichnis. Wenn Sie einen Java-Stack verwenden, ersetzen Sie "ASCS" durch "SCS", bevor Sie den folgenden und andere Beispielbefehle verwenden:

    ~> sudo mkdir /mnt/nfs/sapmntSID
    ~> sudo mkdir /mnt/nfs/usrsap{trans,SIDSYS,SIDASCSscs-instance-number,SIDERSers-instance-number}
  4. Erstellen Sie auf beiden Servern die erforderlichen Bereitstellungspunkte:

    ~> sudo mkdir -p /sapmnt/SID
    ~> sudo mkdir -p /usr/sap/trans
    ~> sudo mkdir -p /usr/sap/SID/SYS
    ~> sudo mkdir -p /usr/sap/SID/ASCSscs-instance-number
    ~> sudo mkdir -p /usr/sap/SID/ERSers-instance-number
  5. Konfigurieren Sie autofs so, dass die allgemeinen freigegebenen Dateiverzeichnisse beim ersten Zugriff auf die Dateiverzeichnisse bereitgestellt werden. Das Bereitstellen der Verzeichnisse ASCSscs-instance-number und ERSers-instance-number wird von der Clustersoftware verwaltet, die Sie in einem späteren Schritt konfigurieren.

    Passen Sie die NFS-Optionen in den Befehlen nach Bedarf für die Dateifreigabelösung an.

    Konfigurieren Sie auf beiden Servern autofs:

    ~> echo "/- /etc/auto.sap" | sudo tee -a /etc/auto.master
    ~> NFS_OPTS="-rw,relatime,vers=3,hard,proto=tcp,timeo=600,retrans=2,mountvers=3,mountport=2050,mountproto=tcp"
    ~> echo "/sapmnt/SID ${NFS_OPTS} nfs-path/sapmntSID" | sudo tee -a /etc/auto.sap
    ~> echo "/usr/sap/trans ${NFS_OPTS} nfs-path/usrsaptrans" | sudo tee -a /etc/auto.sap
    ~> echo "/usr/sap/SID/SYS ${NFS_OPTS} nfs-path/usrsapSIDSYS" | sudo tee -a /etc/auto.sap

    Weitere Informationen zu autofs finden Sie unter autofs – Funktionsweise.

  6. Starten Sie auf beiden Servern den Dienst autofs:

    ~> sudo systemctl enable autofs
    ~> sudo systemctl restart autofs
    ~> sudo automount -v
  7. Lösen Sie autofs aus, um freigegebene Verzeichnisse mit dem Befehl cd bereitzustellen. Beispiel:

    ~> cd /sapmnt/SID
    ~> cd /usr/sap/trans
    ~> cd /usr/sap/SID/SYS
    
  8. Nachdem Sie auf alle Verzeichnisse zugegriffen haben, führen Sie den Befehl df -Th aus, um zu prüfen, ob die Verzeichnisse bereitgestellt sind.

    ~> df -Th | grep file_share_name

    Sie sollten nun Bereitstellungspunkte und Verzeichnisse wie die folgenden sehen:

    10.49.153.26:/nfs_share_nw_ha              nfs      1007G   76M  956G   1% /mnt/nfs
    10.49.153.26:/nfs_share_nw_ha/usrsapAHASYS nfs      1007G   76M  956G   1% /usr/sap/AHA/SYS
    10.49.153.26:/nfs_share_nw_ha/usrsaptrans  nfs      1007G   76M  956G   1% /usr/sap/trans
    10.49.153.26:/nfs_share_nw_ha/sapmntAHA    nfs      1007G   76M  956G   1% /sapmnt/AHA

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

Der interne TCP/UDP-Load-Balancing-Dienst mit Failover-Unterstützung leitet den SCS- und ERS-Traffic an die aktiven Instanzen in einem SAP NetWeaver-Cluster weiter. Das interne TCP/UDP-Load-Balancing verwendet virtuelle IP-Adressen (VIP), Back-End-Dienste, Instanzgruppen und Systemdiagnosen, um den Traffic entsprechend weiterzuleiten.

IP-Adressen für die virtuellen IP-Adressen reservieren

Für einen SAP NetWeaver-Hochverfügbarkeitscluster erstellen Sie zwei VIPs, die manchmal als Floating-IP-Adressen bezeichnet werden. Eine VIP-Adresse folgt der aktiven SAP Central Services-Instanz (SCS-Instanz) und die andere der ERS-Instanz (Enqueue Replication Server). Der Load-Balancer leitet den an jede VIP gesendeten Traffic an die VM weiter, die derzeit die aktive Instanz der SCS- oder ERS-Komponente der VIP hostet.

  1. Öffnen Sie Cloud Shell:

    Zu Cloud Shell

  2. Reservieren Sie eine IP-Adresse für die virtuelle IP-Adresse der SCS und für die VIP des ERS. Für SCS ist die IP-Adresse die IP-Adresse, mit der Anwendungen auf SAP NetWeaver zugreifen. Beim ERS ist die IP-Adresse die IP-Adresse, die für die Enqueue Server-Replikation verwendet wird. Wenn Sie das Flag --addresses weglassen, wird im angegebenen Subnetz automatisch eine IP-Adresse ausgewählt:

    ~ gcloud compute addresses create scs-vip-name \
      --region cluster-region --subnet cluster-subnet \
      --addresses scs-vip-address
    
    ~ gcloud compute addresses create ers-vip-name \
      --region cluster-region --subnet cluster-subnet \
      --addresses ers-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 dem folgenden Beispiel entsprechen:

    address: 10.1.0.85
    addressType: INTERNAL
    creationTimestamp: '2021-05-12T13:30:29.991-07:00'
    description: ''
    id: '1740813556077659146'
    kind: compute#address
    name: scs-aha-vip-name
    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/scs-aha-vip-name
    status: RESERVED
    subnetwork: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/subnetworks/example-sub-network-sap

Hostnamen für die VIP-Adresse in /etc/hosts definieren

Definieren Sie für jede VIP-Adresse einen Hostnamen und fügen Sie dann die IP-Adressen und Hostnamen für die VMs und die VIPs zur Datei /etc/hosts auf jeder VM hinzu.

Die VIP-Hostnamen sind außerhalb der VMs nicht bekannt, es sei denn, Sie fügen sie auch Ihrem DNS-Dienst hinzu. Wenn Sie diese Einträge der lokalen Datei /etc/hosts hinzufügen, schützen Sie Ihren Cluster vor Unterbrechungen Ihres DNS-Dienstes.

Die Aktualisierungen der Datei /etc/hosts sollten in etwa so aussehen:

#
# IP-Address  Full-Qualified-Hostname  Short-Hostname
#
127.0.0.1       localhost
10.1.0.89       nw-ha-vm-1
10.1.0.88       nw-ha-vm-2
10.1.0.90       vh-scs-aha
10.1.0.91       vh-ers-aha

Cloud Load Balancing-Systemdiagnosen erstellen

Erstellen Sie Systemdiagnosen: eine für die aktive SCS-Instanz und eine für den aktiven ERS.

  1. Erstellen Sie die Systemdiagnosen in Cloud Shell. Geben Sie Portnummern für die SCS- und ERS-Instanzen im privaten Bereich (49152–65535) an, um Konflikte mit anderen Diensten zu vermeiden. Die Werte für Prüfintervall und Zeitlimit in den folgenden Befehlen 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:

    1. ~ gcloud compute health-checks create tcp scs-health-check-name \
      --port=scs-healthcheck-port-num --proxy-header=NONE --check-interval=10 --timeout=10 \
      --unhealthy-threshold=2 --healthy-threshold=2
    2. ~ gcloud compute health-checks create tcp ers-health-check-name \
      --port=ers-healthcheck-port-num --proxy-header=NONE --check-interval=10 --timeout=10 \
      --unhealthy-threshold=2 --healthy-threshold=2
  2. Prüfen Sie die Erstellung jeder Systemdiagnose:

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

    Die Ausgabe sollte in etwa dem folgenden Beispiel entsprechen:

    checkIntervalSec: 10
    creationTimestamp: '2021-05-12T15:12:21.892-07:00'
    healthyThreshold: 2
    id: '1981070199800065066'
    kind: compute#healthCheck
    name: scs-aha-health-check-name
    selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/scs-aha-health-check-name
    tcpHealthCheck:
      port: 60000
      portSpecification: USE_FIXED_PORT
      proxyHeader: NONE
    timeoutSec: 10
    type: TCP
    unhealthyThreshold: 2

Firewallregel für die Systemdiagnosen erstellen

Definieren Sie, sofern noch nicht geschehen, eine Firewallregel für einen Port im privaten Bereich, die den Zugriff auf Ihre Host-VMs aus den IP-Bereichen 35.191.0.0/16 und 130.211.0.0/22 ermöglicht, die von Cloud Load Balancing-Systemdiagnosen verwendet werden. Weitere Informationen zu Firewallregeln für Load-Balancer finden Sie unter Firewallregeln für Systemdiagnosen erstellen.

  1. Fügen Sie Ihren Host-VMs ein Netzwerk-Tag hinzu, falls noch keines vorhanden ist. Dieses Netzwerk-Tag wird von der Firewallregel für Systemdiagnosen verwendet.

  2. Erstellen Sie eine Firewallregel, die das Netzwerk-Tag verwendet, 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:scs-healthcheck-port-num,tcp:ers-healthcheck-port-num

    Beispiel:

    gcloud compute firewall-rules create  nw-ha-cluster-health-checks \
    --network=example-network \
    --action=ALLOW \
    --direction=INGRESS \
    --source-ranges=35.191.0.0/16,130.211.0.0/22 \
    --target-tags=allow-health-check \
    --rules=tcp:60000,tcp:60010

Compute Engine-Instanzgruppen erstellen

Sie müssen in jeder Zone eine Instanzgruppe erstellen, die eine VM mit Clusterknoten enthält, und die VM in dieser Zone der Instanzgruppe hinzufügen.

  1. Erstellen Sie in Cloud Shell die primäre Instanzgruppe und fügen Sie ihr die primäre VM hinzu:

    1. ~ gcloud compute instance-groups unmanaged create primary-ig-name \
      --zone=primary-vm-zone
    2. ~ gcloud compute instance-groups unmanaged add-instances primary-ig-name \
      --zone=primary-vm-zone \
      --instances=primary-vm-name
  2. Erstellen Sie in Cloud Shell die sekundäre Instanzgruppe und fügen Sie ihr die sekundäre VM hinzu:

    1. ~ gcloud compute instance-groups unmanaged create secondary-ig-name \
      --zone=secondary-vm-zone
    2. ~ gcloud compute instance-groups unmanaged add-instances secondary-ig-name \
      --zone=secondary-vm-zone \
      --instances=secondary-vm-name
  3. Bestätigen Sie die Erstellung der Instanzgruppen:

    ~ gcloud compute instance-groups unmanaged list

    Die Ausgabe sollte in etwa dem folgenden Beispiel entsprechen:

    NAME                              ZONE           NETWORK              NETWORK_PROJECT        MANAGED  INSTANCES
    sap-aha-primary-instance-group    us-central1-b  example-network-sap  example-project-123456  No       1
    sap-aha-secondary-instance-group  us-central1-c  example-network-sap  example-project-123456  No       1
    

Back-End-Dienste konfigurieren

Erstellen Sie zwei Back-End-Dienste, einen für SCS und einen für ERS. Fügen Sie jedem Back-End-Dienst beide Instanzgruppen hinzu und legen Sie die jeweils andere Instanzgruppe als Failover-Instanzgruppe fest. Zum Schluss erstellen Sie Weiterleitungsregeln von den VIPs zu den Back-End-Diensten.

  1. Erstellen Sie in Cloud Shell den Back-End-Dienst und die Failover-Gruppe für SCS:

    1. Erstellen Sie den Back-End-Dienst für SCS:

      ~ gcloud compute backend-services create scs-backend-service-name \
         --load-balancing-scheme internal \
         --health-checks scs-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 zum SCS-Back-End-Dienst hinzu:

      ~ gcloud compute backend-services add-backend scs-backend-service-name \
        --instance-group primary-ig-name \
        --instance-group-zone primary-vm-zone \
        --region cluster-region
    3. Fügen Sie die sekundäre Instanzgruppe als Failover-Instanzgruppe für den SCS-Back-End-Dienst hinzu:

      ~ gcloud compute backend-services add-backend scs-backend-service-name \
        --instance-group secondary-ig-name \
        --instance-group-zone secondary-vm-zone \
        --failover \
        --region cluster-region
  2. Erstellen Sie in Cloud Shell den Back-End-Dienst und die Failover-Gruppe für ERS:

    1. Erstellen Sie den Back-End-Dienst für ERS:

      ~ gcloud compute backend-services create ers-backend-service-name \
      --load-balancing-scheme internal \
      --health-checks ers-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 sekundäre Instanzgruppe zum ERS-Back-End-Dienst hinzu:

      ~ gcloud compute backend-services add-backend ers-backend-service-name \
        --instance-group secondary-ig-name \
        --instance-group-zone secondary-vm-zone \
        --region cluster-region
    3. Fügen Sie die primäre Instanzgruppe als Failover-Instanzgruppe zum ERS-Back-End-Dienst hinzu:

      ~ gcloud compute backend-services add-backend ers-backend-service-name \
        --instance-group primary-ig-name \
        --instance-group-zone primary-vm-zone \
        --failover \
        --region cluster-region
  3. Prüfen Sie optional, ob die Back-End-Dienste die Instanzgruppen wie erwartet enthalten:

    ~ gcloud compute backend-services describe backend-service-name \
     --region=cluster-region

    Die Ausgabe für den SCS-Back-End-Dienst sollte in etwa wie im folgenden Beispiel aussehen. Bei ERS wird failover: true in der primären Instanzgruppe angezeigt:

    backends:
    - balancingMode: CONNECTION
      group: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instanceGroups/sap-aha-primary-instance-group
    - balancingMode: CONNECTION
      failover: true
      group: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/sap-aha-secondary-instance-group
    connectionDraining:
      drainingTimeoutSec: 0
    creationTimestamp: '2021-05-25T08:30:58.424-07:00'
    description: ''
    failoverPolicy:
      disableConnectionDrainOnFailover: true
      dropTrafficIfUnhealthy: true
      failoverRatio: 1.0
    fingerprint: n44gVc1VVQE=
    healthChecks:
    - https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/scs-aha-health-check-name
    id: '4940777952116778717'
    kind: compute#backendService
    loadBalancingScheme: INTERNAL
    name: scs-aha-backend-service-name
    protocol: TCP
    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/backendServices/scs-aha-backend-service-name
    sessionAffinity: NONE
    timeoutSec: 30
  4. In Cloud Shell erstellen Sie Weiterleitungsregeln für die SCS- und ERS-Back-End-Dienste:

    1. Erstellen Sie die Weiterleitungsregel von der SCS-VIP zum SCS-Back-End-Dienst:

      ~ gcloud compute forwarding-rules create scs-forwarding-rule-name \
      --load-balancing-scheme internal \
      --address scs-vip-address \
      --subnet cluster-subnet \
      --region cluster-region \
      --backend-service scs-backend-service-name \
      --ports ALL
    2. Erstellen Sie die Weiterleitungsregel von der ERS-VIP zum ERS-Back-End-Dienst:

      ~ gcloud compute forwarding-rules create ers-forwarding-rule-name \
      --load-balancing-scheme internal \
      --address ers-vip-address \
      --subnet cluster-subnet \
      --region cluster-region \
      --backend-service ers-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 einen 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 auf der primären VM einen socat-Prozess, um 60 Sekunden lang den Port der SCS-Systemdiagnose zu überwachen:

    # timeout 60s socat - TCP-LISTEN:scs-healthcheck-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 SCS-Back-End-Instanzgruppen:

    ~ gcloud compute backend-services get-health scs-backend-service-name \
      --region cluster-region
  4. Wiederholen Sie die Schritte für ERS und ersetzen Sie die Werte der SCS-Variablen durch die ERS-Werte.

    Die Ausgabe sollte ähnlich wie das folgende Beispiel für SCS aussehen:

    backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instanceGroups/sap-aha-primary-instance-group
    status:
      healthStatus:
      - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
        forwardingRuleIp: 10.1.0.90
        healthState: HEALTHY
        instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instances/nw-ha-vm-1
        ipAddress: 10.1.0.89
        port: 80
      kind: compute#backendServiceGroupHealth
    ---
    backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/sap-aha-secondary-instance-group
    status:
      healthStatus:
      - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
        forwardingRuleIp: 10.1.0.90
        healthState: UNHEALTHY
        instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/nw-ha-vm-2
        ipAddress: 10.1.0.88
        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. 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-b/instanceGroups/sap-aha-primary-instance-group
    status:
      healthStatus:
      - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
        forwardingRuleIp: 10.1.0.85
        healthState: HEALTHY
        instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instances/nw-ha-vm-1
        ipAddress: 10.1.0.79
        port: 80
      kind: compute#backendServiceGroupHealth
    ---
    backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/sap-aha-secondary-instance-group
    status:
      healthStatus:
      - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
        forwardingRuleIp: 10.1.0.85
        healthState: HEALTHY
        instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/nw-ha-vm-2
        ipAddress: 10.1.0.78
        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 NetWeaver 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.

Erforderliche Clusterpakete installieren

  1. Laden Sie als Root auf dem primären und dem sekundären Host die folgenden erforderlichen Clusterpakete herunter:

    • Das ha_sles-Muster:

      # zypper install -t pattern ha_sles
    • Das Paket sap-suse-cluster-connector:

      # zypper install -y sap-suse-cluster-connector
    • Falls Sie es nicht bereits installiert haben, das Dienstprogramm socat:

      # zypper install -y socat

  2. Prüfen Sie, ob die neuesten Hochverfügbarkeits-Agents geladen wurden:

    # zypper se -t patch SUSE-SLE-HA

Cluster auf der primären VM initialisieren, konfigurieren und starten

Sie initialisieren den Cluster mit dem SUSE-Skript ha-cluster-init. Anschließend müssen Sie die Corosync-Konfigurationsdatei bearbeiten und mit dem sekundären Knoten synchronisieren. Nachdem Sie den Cluster gestartet haben, können Sie mit crm-Befehlen zusätzliche Clusterattribute und Standardeinstellungen festlegen.

Cluster initialisieren

So initialisieren Sie den Cluster:

  1. Initialisieren Sie den Cluster als Root auf dem primären Host mit dem SUSE-Skript ha-cluster-init. Die folgenden Befehle benennen den Cluster und erstellen die Konfigurationsdatei corosync.conf: Konfigurieren Sie ihn und richten Sie die Synchronisierung zwischen den Clusterknoten ein.

    # ha-cluster-init --name cluster-name --yes --interface eth0 csync2
    # ha-cluster-init --name cluster-name --yes --interface eth0 corosync

Corosync-Konfigurationsdateien aktualisieren

  1. Öffnen Sie die Datei corosync.conf zur Bearbeitung:

    # vi /etc/corosync/corosync.conf
  2. Legen Sie im Abschnitt totem der Datei corosync.conf die Parameter im folgenden Auszugsbeispiel auf die angezeigten Werte fest. Einige Parameter sind möglicherweise bereits auf die richtigen Werte festgelegt:

    totem {
            ...
            token: 20000
            token_retransmits_before_loss_const: 10
            join: 60
            consensus: 24000
            max_messages: 20
            ...
    }
  3. Starten Sie den Cluster.

    # ha-cluster-init --name cluster-name cluster

Zusätzliche Clusterattribute festlegen

  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="1"
    # crm configure rsc_defaults migration-threshold="3"
    # crm configure op_defaults timeout="600"

    Wenn Sie die einzelnen Clusterressourcen definieren, überschreiben die für resource-stickiness und migration-threshold festgelegten Werte die hier festgelegten Standardwerte.

    Sie können die Standardeinstellungen für Ressourcen sowie die Werte für alle definierten Ressourcen sehen, wenn Sie crm config show eingeben.

  2. Starten Sie Pacemaker auf dem primären Host:

    # systemctl enable pacemaker
    # systemctl start pacemaker

Sekundäre VM mit dem Cluster verbinden

Führen Sie über das offene Terminal auf der primären VM den Cluster auf der sekundären VM aus und starten Sie ihn über SSH.

  1. Führen Sie auf der primären VM die folgenden ha-cluster-join-Skriptoptionen auf der sekundären VM über SSH aus. Wenn Sie Ihren HA-Cluster wie in dieser Anleitung beschrieben konfiguriert haben, können Sie die Warnungen zum Watchdog-Gerät ignorieren.

    1. Führen Sie die Option --interface eth0 csync2 aus:

      # ssh secondary-vm-name 'ha-cluster-join --cluster-node primary-vm-name --yes --interface eth0 csync2'
    2. Führen Sie die Option ssh_merge aus:

      # ssh secondary-vm-name 'ha-cluster-join --cluster-node primary-vm-name --yes ssh_merge'
    3. Führen Sie die Option cluster aus:

      # ssh secondary-vm-name 'ha-cluster-join --cluster-node primary-vm-name --yes cluster'
  2. Starten Sie Pacemaker auf dem sekundären Host:

    1. Aktivieren Sie Pacemaker:

      # ssh secondary-vm-name systemctl enable pacemaker
    2. Starten Sie Pacemaker:

      # ssh secondary-vm-name 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 resource instances configured

Clusterressourcen für die Infrastruktur konfigurieren

Sie definieren die Ressourcen, die von Pacemaker in einem Hochverfügbarkeitscluster verwaltet werden. Sie müssen Ressourcen für die folgenden Clusterkomponenten definieren:

  • Das Fencing-Gerät, das Split-Brain-Szenarien verhindert
  • Die SCS- und ERS-Verzeichnisse im freigegebenen Dateisystem
  • Die Systemdiagnosen
  • Die VIPs
  • Die SCS- und ERS-Komponenten

Sie definieren die Ressourcen für SCS- und ERS-Komponenten später als die übrigen Ressourcen, da Sie zuerst SAP NetWeaver installieren müssen.

Wartungsmodus aktivieren

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

    # crm configure property maintenance-mode="true"
  2. Bestätigen Sie den Wartungsmodus:

    # crm status

    Die Ausgabe sollte anzeigen, dass die Ressourcenverwaltung deaktiviert ist, wie im folgenden Beispiel gezeigt:

    Cluster Summary:
    * Stack: corosync
    * Current DC: nw-ha-vm-1 (version 2.0.4+20200616.2deceaa3a-3.3.1-2.0.4+20200616.2deceaa3a) - partition with quorum
    * Last updated: Fri May 14 15:26:08 2021
    * Last change:  Thu May 13 19:02:33 2021 by root via cibadmin on nw-ha-vm-1
    * 2 nodes configured
    * 0 resource instances configured
    
                *** Resource management is DISABLED ***
    The cluster will not attempt to start, stop or recover services
    
    Node List:
    * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
    
    Full List of Resources:
    * No resources

Fencing einrichten

Definieren Sie für jede Host-VM eine Cluster-Ressource mit dem Agent fence_gce, um Fencing einzurichten.

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

Ressourcen für Fencing-Geräte erstellen

Für jede VM im Cluster erstellen Sie eine Clusterressource für das Fencing-Gerät, das diese VM neu starten kann. Das Fencing-Gerät für eine VM muss auf einer anderen VM ausgeführt werden. Daher konfigurieren Sie den Speicherort der Cluster-Ressource so, dass sie auf einer beliebigen VM ausgeführt wird, außer der VM, die sie neu starten kann.

  1. Erstellen Sie als Root auf dem primären Host eine Clusterressource für ein Fencing-Gerät für die primäre VM:

    # crm configure primitive fencing-rsc-name-primary-vm stonith:fence_gce \
      op monitor interval="300s" timeout="120s" on-fail="restart" \
      op start interval="0" timeout="60s" on-fail="restart" \
      params port="primary-vm-name" zone="primary-vm-zone" \
      project="cluster-project-id"
  2. Konfigurieren Sie den Standort des Fencing-Geräts für die primäre VM so, dass es nur auf der sekundären VM aktiv ist:

    # crm configure location fencing-location-name-primary-vm \
      fencing-rsc-name-primary-vm -inf: "primary-vm-name"
  3. Erstellen Sie als Root auf dem primären Host eine Clusterressource für ein Fencing-Gerät für die sekundäre VM:

    # crm configure primitive fencing-rsc-name-secondary-vm stonith:fence_gce \
      op monitor interval="300s" timeout="120s" on-fail="restart" \
      op start interval="0" timeout="60s" on-fail="restart" \
      params port="secondary-vm-name" zone="secondary-vm-zone" \
      project="cluster-project-id"
  4. Konfigurieren Sie den Standort des Fencing-Geräts für die sekundäre VM so, dass es nur auf der primären VM aktiv ist:

    # crm configure location fencing-location-name-secondary-vm \
      fencing-rsc-name-secondary-vm -inf: "secondary-vm-name"

Verzögerung für den Neustart von Corosync festlegen

  1. Erstellen Sie auf beiden Hosts als Root eine systemd-Drop-in-Datei, die den Start von Corosync verzögert, um die richtige Reihenfolge der Ereignisse nach dem Neustart einer umzäunten VM zu gewährleisten:

    systemctl edit corosync.service
  2. Fügen Sie der Datei die folgenden Zeilen hinzu:

    [Service]
    ExecStartPre=/bin/sleep 60
  3. Speichern Sie die Datei und beenden Sie den Editor.

  4. Laden Sie die Konfiguration des systemd-Managers neu.

    systemctl daemon-reload
  5. Prüfen Sie, ob die Drop-in-Datei erstellt wurde:

    service corosync status

    Sie sollten eine Zeile für die Drop-in-Datei sehen, wie im folgenden Beispiel gezeigt:

    ● corosync.service - Corosync Cluster Engine
       Loaded: loaded (/usr/lib/systemd/system/corosync.service; disabled; vendor preset: disabled)
      Drop-In: /etc/systemd/system/corosync.service.d
               └─override.conf
       Active: active (running) since Tue 2021-07-20 23:45:52 UTC; 2 days ago

Pacemaker-Zeitlimit für Neustarts erhöhen

  1. Erhöhen Sie auf jedem Host als Root den Pacemaker-Timeout-Wert für Neustarts, um die Startverzögerung zu berücksichtigen.

    crm_resource --resource STONITH-host-name --set-parameter=pcmk_reboot_timeout --parameter-value=300

    Der Wert pcmk_reboot_timeout muss größer sein als die Summe aus folgenden Komponenten:

    • Die Corosync-Zeitüberschreitung (token)
    • Das Corosync-Zeitlimit consensus
    • Die Zeit, die für einen Neustart benötigt wird, einschließlich Verzögerungsattribut.

    In Google Cloud sind 300 Sekunden für die meisten Cluster ausreichend.

  2. Bestätigen Sie den neuen Wert pcmk_reboot_timeout:

    crm_resource --resource STONITH-host-name --get-parameter=pcmk_reboot_timeout

Dateisystemressourcen erstellen

Nachdem Sie die freigegebenen Dateisystemverzeichnisse erstellt haben, können Sie die Clusterressourcen definieren.

  1. Konfigurieren Sie die Dateisystemressourcen für die instanzspezifischen Verzeichnisse.

    # crm configure primitive scs-file-system-rsc-name Filesystem \
    device="nfs-path/usrsapSIDASCSscs-instance-number" \
    directory="/usr/sap/SID/ASCSscs-instance-number" fstype="nfs" \
    op start timeout=60s interval=0 \
    op stop timeout=60s interval=0 \
    op monitor interval=20s timeout=40s
    # crm configure primitive ers-file-system-rsc-name Filesystem \
    device="nfs-path/usrsapSIDERSers-instance-number" \
    directory="/usr/sap/SID/ERSers-instance-number" fstype="nfs" \
    op start timeout=60s interval=0 \
    op stop timeout=60s interval=0 \
    op monitor interval=20s timeout=40s

Systemdiagnose-Ressourcen erstellen

  1. Konfigurieren Sie die Clusterressourcen für die SCS- und ERS-Systemdiagnosen:
# crm configure primitive scs-health-check-rsc-name anything \
  params binfile="/usr/bin/socat" \
  cmdline_options="-U TCP-LISTEN:scs-healthcheck-port-num,backlog=10,fork,reuseaddr /dev/null" \
  op monitor timeout=20s interval=10 \
  op_params depth=0
# crm configure primitive ers-health-check-rsc-name anything \
  params binfile="/usr/bin/socat" \
  cmdline_options="-U TCP-LISTEN:ers-healthcheck-port-num,backlog=10,fork,reuseaddr /dev/null" \
  op monitor timeout=20s interval=10 \
  op_params depth=0

VIP-Ressourcen erstellen

Definieren Sie die Clusterressourcen für die VIP-Adressen.

  1. Wenn Sie die numerische VIP-Adresse nachschlagen müssen, verwenden Sie diese Befehle:

    • gcloud compute addresses describe scs-vip-name
      --region=cluster-region --format="value(address)"
    • gcloud compute addresses describe ers-vip-name
      --region=cluster-region --format="value(address)"
  2. Erstellen Sie die Clusterressourcen für die SCS- und ERS-VIPs.

    # crm configure primitive scs-vip-rsc-name IPaddr2 \
     params ip=scs-vip-address cidr_netmask=32 nic="eth0" \
     op monitor interval=10s timeout=20s
    # crm configure primitive ers-vip-rsc-name IPaddr2 \
     params ip=ers-vip-address cidr_netmask=32 nic="eth0" \
     op monitor interval=10s timeout=20s

Definierte Ressourcen aufrufen

  1. Geben Sie den folgenden Befehl ein, um alle bisher definierten Ressourcen anzuzeigen:

    # crm status

    Die Ausgabe sollte in etwa dem folgenden Beispiel entsprechen:

    Stack: corosync
    Current DC: nw-ha-vm-1 (version 1.1.24+20201209.8f22be2ae-3.12.1-1.1.24+20201209.8f22be2ae) - partition with quorum
    Last updated: Wed May 26 19:10:10 2021
    Last change: Tue May 25 23:48:35 2021 by root via cibadmin on nw-ha-vm-1
    
    2 nodes configured
    8 resource instances configured
    
                  *** Resource management is DISABLED ***
      The cluster will not attempt to start, stop or recover services
    
    Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
    
    Full list of resources:
    
     fencing-rsc-nw-aha-vm-1        (stonith:fence_gce):    Stopped (unmanaged)
     fencing-rsc-nw-aha-vm-2        (stonith:fence_gce):    Stopped (unmanaged)
     filesystem-rsc-nw-aha-scs      (ocf::heartbeat:Filesystem):    Stopped (unmanaged)
     filesystem-rsc-nw-aha-ers      (ocf::heartbeat:Filesystem):    Stopped (unmanaged)
     health-check-rsc-nw-ha-scs     (ocf::heartbeat:anything):      Stopped (unmanaged)
     health-check-rsc-nw-ha-ers     (ocf::heartbeat:anything):      Stopped (unmanaged)
     vip-rsc-nw-aha-scs     (ocf::heartbeat:IPaddr2):       Stopped (unmanaged)
     vip-rsc-nw-aha-ers     (ocf::heartbeat:IPaddr2):       Stopped (unmanaged)

SCS und ERS installieren

Im folgenden Abschnitt werden nur die Anforderungen und Empfehlungen erläutert, die sich speziell auf die Installation von SAP NetWeaver in Google Cloud beziehen.

Eine vollständige Installationsanleitung finden Sie in der SAP NetWeaver-Dokumentation.

Vorbereitung der Installation

Bevor Sie die SCS- und ERS-Komponenten von SAP NetWeaver installieren, müssen Sie die Nutzer, Gruppen und Berechtigungen definieren und den sekundären Server in den Standby-Modus versetzen. So gewährleisten Sie die Konsistenz im Cluster und vereinfachen die Installation.

  1. Beenden Sie den Wartungsmodus des Clusters:

    # crm configure property maintenance-mode="false"
  2. Geben Sie auf beiden Servern als Root die folgenden Befehle ein. Geben Sie dabei die Nutzer- und Gruppen-IDs an, die für Ihre Umgebung geeignet sind:

    # groupadd -g gid-sapinst sapinst
    # groupadd -g gid-sapsys sapsys
    # useradd -u uid-sidadm sid-loweradm -g sapsys
    # usermod -a -G sapinst sid-loweradm
    # useradd -u uid-sapadm sapadm -g sapinst
    
    # chown sid-loweradm:sapsys /usr/sap/SID/SYS
    # chown sid-loweradm:sapsys /sapmnt/SID -R
    # chown sid-loweradm:sapsys /usr/sap/trans -R
    # chown sid-loweradm:sapsys /usr/sap/SID/SYS -R
    # chown sid-loweradm:sapsys /usr/sap/SID -R

SCS-Komponente installieren

  1. Geben Sie auf dem sekundären Server den folgenden Befehl ein, um den sekundären Server in den Standby-Modus zu versetzen:

    # crm_standby -v on -N ${HOSTNAME};

    Wird der sekundäre Server in den Standbymodus versetzt, werden alle Clusterressourcen auf dem primären Server konsolidiert. Dadurch wird die Installation vereinfacht.

  2. Prüfen Sie, ob sich der sekundäre Server im Standby-Modus befindet:

    # crm status

    Die Ausgabe sollte in etwa dem folgenden Beispiel entsprechen:

    Stack: corosync
    Current DC: nw-ha-vm-1 (version 1.1.24+20201209.8f22be2ae-3.12.1-1.1.24+20201209.8f22be2ae) - partition with quorum
    Last updated: Thu May 27 17:45:16 2021
    Last change: Thu May 27 17:45:09 2021 by root via crm_attribute on nw-ha-vm-2
    
    2 nodes configured
    8 resource instances configured
    
    Node nw-ha-vm-2: standby
    Online: [ nw-ha-vm-1 ]
    
    Full list of resources:
    
     fencing-rsc-nw-aha-vm-1        (stonith:fence_gce):    Stopped
     fencing-rsc-nw-aha-vm-2        (stonith:fence_gce):    Started nw-ha-vm-1
     filesystem-rsc-nw-aha-scs      (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
     filesystem-rsc-nw-aha-ers      (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
     health-check-rsc-nw-ha-scs     (ocf::heartbeat:anything):      Started nw-ha-vm-1
     health-check-rsc-nw-ha-ers     (ocf::heartbeat:anything):      Started nw-ha-vm-1
     vip-rsc-nw-aha-scs     (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
     vip-rsc-nw-aha-ers     (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
  3. Wechseln Sie auf dem primären Server als Root-Nutzer in ein temporäres Installationsverzeichnis, z. B. /tmp, um die SCS-Instanz zu installieren. Führen Sie dazu SAP Software Provisioning Manager (SWPM) aus.

    • Für den Zugriff auf die Weboberfläche von SWPM benötigen Sie das Passwort für den Nutzer root. Wenn Ihre IT-Richtlinie dem SAP-Administrator keinen Zugriff auf das Root-Passwort gewährt, können Sie SAPINST_REMOTE_ACCESS_USER verwenden.

    • Verwenden Sie beim Starten von SWPM den Parameter SAPINST_USE_HOSTNAME, um den virtuellen Hostnamen anzugeben, den Sie für die SCS-VIP-Adresse in der Datei /etc/hosts definiert haben.

      Beispiel:

      cd /tmp; /mnt/nfs/install/SWPM/sapinst SAPINST_USE_HOSTNAME=vh-aha-scs
    • Prüfen Sie auf der endgültigen SWPM-Bestätigungsseite, ob der Name des virtuellen Hosts korrekt ist.

  4. Nach Abschluss der Konfiguration beenden Sie den Standby-Modus für die sekundäre VM:

    # crm_standby -v off -N ${HOSTNAME}; # On SECONDARY

ERS-Komponente installieren

  1. Beenden Sie den SCS-Dienst auf dem primären Server als Root oder sidadm.

    # su - sid-loweradm -c "sapcontrol -nr scs-instance-number -function Stop"
    # su - sid-loweradm -c "sapcontrol -nr scs-instance-number -function StopService"
  2. Geben Sie auf dem primären Server den folgenden Befehl ein, um den primären Server in den Standby-Modus zu setzen.

    # crm_standby -v on -N ${HOSTNAME};

    Durch das Setzen des primären Servers in den Standby-Modus werden alle Clusterressourcen auf dem sekundären Server konsolidiert. Dadurch wird die Installation vereinfacht.

  3. Prüfen Sie, ob sich der primäre Server im Standby-Modus befindet:

    # crm status
  4. Wechseln Sie auf dem sekundären Server als Root-Nutzer in ein temporäres Installationsverzeichnis, z. B. /tmp, um die ERS-Instanz zu installieren. Führen Sie dazu SAP Software Provisioning Manager (SWPM) aus.

    • Verwenden Sie denselben Nutzer und dasselbe Passwort für den Zugriff auf SWPM, die Sie bei der Installation der SCS-Komponente verwendet haben.

    • Verwenden Sie beim Starten von SWPM den Parameter SAPINST_USE_HOSTNAME, um den Namen des virtuellen Hosts anzugeben, den Sie in der Datei /etc/hosts für die ERS-VIP-Adresse definiert haben.

      Beispiel:

      cd /tmp; /mnt/nfs/install/SWPM/sapinst SAPINST_USE_HOSTNAME=vh-aha-ers
    • Prüfen Sie auf der endgültigen SWPM-Bestätigungsseite, ob der Name des virtuellen Hosts korrekt ist.

  5. Beenden Sie den Standby-Modus der primären VM, damit beide aktiv sind:

    # crm_standby -v off -N ${HOSTNAME};

SAP-Dienste konfigurieren

Sie müssen prüfen, ob die Dienste ordnungsgemäß konfiguriert sind, die Einstellungen in den ASCS- und ERS-Profilen prüfen und der Nutzergruppe haclient den Nutzer sidadm hinzufügen.

SAP-Diensteinträge prüfen

  1. Achten Sie auf beiden Servern darauf, dass /usr/sap/sapservices Einträge für die SCS- und ERS-Dienste enthält. Mit sapstartsrv command mit den Optionen pf=profile-of-the-sap-instance und -reg können Sie fehlende Einträge hinzufügen. Beispiel:

    # LD_LIBRARY_PATH=/usr/sap/hostctrl/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH
    /usr/sap/hostctrl/exe/sapstartsrv \
     pf=/usr/sap/SID/SYS/profile/SID_ERSers-instance-number_ers-virtual-host-name \
     -reg
    /usr/sap/hostctrl/exe/sapstartsrv \
     pf=/usr/sap/SID/SYS/profile/SID_ASCSscs-instance-number_scs-virtual-host-name \
     -reg

SAP-Dienste beenden

  1. Beenden Sie auf dem sekundären Server den ERS-Dienst:

    # su - sid-loweradm -c "sapcontrol -nr ers-instance-number -function Stop"
    # su - sid-loweradm -c "sapcontrol -nr ers-instance-number -function StopService"
  2. Prüfen Sie auf jedem Server, ob alle Dienste beendet wurden:

    # su - sid-loweradm -c "sapcontrol -nr scs-instance-number -function GetSystemInstanceList"
    # su - sid-loweradm -c "sapcontrol -nr ers-instance-number -function GetSystemInstanceList"

    Die Ausgabe sollte in etwa dem folgenden Beispiel entsprechen:

    18.05.2021 17:39:18
    GetSystemInstanceList
    FAIL: NIECONN_REFUSED (Connection refused), NiRawConnect failed in plugin_fopen()

SCS- und ERS-Profile bearbeiten

  1. Wechseln Sie auf einem der Server mit dem folgenden Befehl zum Profilverzeichnis:

    # cd /usr/sap/SID/SYS/profile
    # cd /sapmnt/SID/profile
  2. Suchen Sie bei Bedarf die Dateinamen Ihrer ASCS- und ERS-Profile, indem Sie die Dateien im Profilverzeichnis auflisten oder die folgenden Formate verwenden:

    SID_ASCSscs-instance-number_scs-virtual-host-name
    SID_ERSers-instance-number_ers-virtual-host-name
  3. Aktivieren Sie das Paket sap-suse-cluster-connector. Fügen Sie dazu die folgenden Zeilen in die ASCS- und ERS-Instanzprofile ein:

    #-----------------------------------------------------------------------
    # SUSE HA library
    #-----------------------------------------------------------------------
    service/halib = $(DIR_CT_RUN)/saphascriptco.so
    service/halib_cluster_connector = /usr/bin/sap_suse_cluster_connector
  4. Wenn Sie ENSA1 verwenden, aktivieren Sie die Keepalive-Funktion. Legen Sie dazu Folgendes im ASCS-Profil fest:

    enque/encni/set_so_keepalive = true

    Weitere Informationen finden Sie unter SAP-Hinweis 1410736 – TCP/IP: Keepalive-Intervall festlegen.

  5. Bearbeiten Sie bei Bedarf die ASCS- und ERS-Profile, um das Startverhalten von Enqueue Server und Enqueue Replication Server zu ändern.

    ENSA1

    Wenn im Abschnitt SAP Enqueue Server starten des ASCS-Profils Restart_Program_nn angezeigt wird, ändern Sie Restart in Start, wie im folgenden Beispiel gezeigt:

    Start_Program_01 = local $(_EN) pf=$(_PF)

    Wenn im Abschnitt Enqueue Replication Server starten des ERS-Profils Restart_Program_nn angezeigt wird, ändern Sie Restart in Start, wie im folgenden Beispiel gezeigt.

    Start_Program_00 = local $(_ER) pf=$(_PFL) NR=$(SCSID)

    ENSA2

    Wenn im Abschnitt SAP Enqueue Server starten des ASCS-Profils Restart_Program_nn angezeigt wird, ändern Sie Restart in Start, wie im folgenden Beispiel gezeigt:

    Start_Program_01 = local $(_ENQ) pf=$(_PF)

    Wenn im Abschnitt Enqueue Replicator starten des ERS-Profils Restart_Program_nn angezeigt wird, ändern Sie Restart in Start, wie im folgenden Beispiel gezeigt:

    Start_Program_00 = local $(_ENQR) pf=$(_PF) ...

sidadm-Nutzer der haclient-Nutzergruppe hinzufügen

Beim Installieren des sap-suse-cluster-connector wurde durch die Installation eine haclient-Nutzergruppe erstellt. Damit der sidadm-Nutzer mit dem Cluster arbeiten kann, fügen Sie ihn der haclient-Nutzergruppe hinzu.

  1. Fügen Sie auf beiden Servern den Nutzer sidadm zur Nutzergruppe haclient hinzu:

    # usermod -aG haclient sid-loweradm

Clusterressourcen für SCS und ERS konfigurieren

  1. Versetzen Sie den Cluster als Root von einem der Server in den Wartungsmodus:

    # crm configure property maintenance-mode="true"
  2. Prüfen Sie, ob sich der Cluster im Wartungsmodus befindet:

    # crm status

    Wenn sich der Cluster im Wartungsmodus befindet, enthält der Status die folgenden Zeilen:

                  *** Resource management is DISABLED ***
    The cluster will not attempt to start, stop or recover services
  3. Erstellen Sie die Clusterressourcen für die SCS- und ERS-Dienste:

    ENSA1

    • Erstellen Sie die Clusterressource für die SCS-Instanz: Der Wert von InstanceName ist der Name des Instanzprofils, das SWPM bei der Installation von SCS generiert hat.

      # crm configure primitive scs-instance-rsc-name SAPInstance \
        operations \$id=scs-instance-rsc-operations-name \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ASCSscs-instance-number_scs-virtual-host-name \
           START_PROFILE="/path-to-profile/SID_ASCSscs-instance-number_scs-virtual-host-name" \
           AUTOMATIC_RECOVER=false \
        meta resource-stickiness=5000 failure-timeout=60 \
           migration-threshold=1 priority=10
    • Erstellen Sie die Clusterressource für die ERS-Instanz. Der Wert von InstanceName ist der Name des Instanzprofils, das SWPM bei der Installation von ERS generiert hat. Der Parameter IS_ERS=true weist Pacemaker an, das Flag runsersSID auf dem Knoten, auf dem ERS aktiv ist, auf 1 festzulegen.

      # crm configure primitive ers-instance-rsc-name SAPInstance \
        operations \$id=ers-instance-rsc-operations-name \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ERSers-instance-number_ers-virtual-host-name  \
           START_PROFILE="/path-to-profile/SID_ERSers-instance-number_ers-virtual-host-name" \
           AUTOMATIC_RECOVER=false IS_ERS=true \
        meta priority=1000

    ENSA2

    • Erstellen Sie die Clusterressource für die SCS-Instanz: Der Wert von InstanceName ist der Name des Instanzprofils, das SWPM bei der Installation von SCS generiert hat.

      # crm configure primitive scs-instance-rsc-name SAPInstance \
        operations \$id=scs-instance-rsc-operations-name \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ASCSscs-instance-number_scs-virtual-host-name \
           START_PROFILE="/path-to-profile/SID_ASCSscs-instance-number_scs-virtual-host-name" \
           AUTOMATIC_RECOVER=false \
        meta resource-stickiness=5000 failure-timeout=60
    • Erstellen Sie die Clusterressource für die ERS-Instanz. Der Wert von InstanceName ist der Name des Instanzprofils, das SWPM bei der Installation von ERS generiert hat.

      # crm configure primitive ers-instance-rsc-name SAPInstance \
        operations \$id=ers-instance-rsc-operations-name \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ERSers-instance-number_ers-virtual-host-name  \
           START_PROFILE="/path-to-profile/SID_ERSers-instance-number_ers-virtual-host-name" \
           AUTOMATIC_RECOVER=false IS_ERS=true

Ressourcengruppen und Standorteinschränkungen konfigurieren

  1. Gruppieren Sie die SCS- und ERS-Ressourcen. Mit dem Befehl crm resource status können Sie die Namen aller zuvor definierten Ressourcen aufrufen:

    # crm configure group scs-rsc-group-name scs-file-system-rsc-name \
      scs-health-check-rsc-name scs-vip-rsc-name \
      scs-instance-rsc-name \
      meta resource-stickiness=3000
    # crm configure group ers-rsc-group-name ers-file-system-rsc-name \
      ers-health-check-rsc-name ers-vip-rsc-name \
      ers-instance-rsc-name
  2. Erstellen Sie die Colocation-Einschränkungen:

    ENSA1

    1. Erstellen Sie eine Colocation-Einschränkung, die verhindert, dass die SCS-Ressourcen auf demselben Server wie die ERS-Ressourcen ausgeführt werden:

      # crm configure colocation prevent-scs-ers-coloc -5000: ers-rsc-group-name scs-rsc-group-name
    2. Konfigurieren Sie SCS so, dass ein Failover auf den Server erfolgt, auf dem ERS ausgeführt wird. Dies wird durch das Flag runsersSID gleich 1 bestimmt:

      # crm configure location loc-scs-SID-failover-to-ers scs-instance-rsc-name \
      rule 2000: runs_ers_SID eq 1
    3. Konfigurieren Sie SCS so, dass der Start erfolgt, bevor ERS nach einem Failover auf den anderen Server verschoben wird:

      # crm configure order ord-sap-SID-first-start-ascs \
       Optional: scs-instance-rsc-name:start \
       ers-instance-rsc-name:stop symmetrical=false

    ENSA2

    1. Erstellen Sie eine Colocation-Einschränkung, die verhindert, dass die SCS-Ressourcen auf demselben Server wie die ERS-Ressourcen ausgeführt werden:

      # crm configure colocation prevent-scs-ers-coloc -5000: ers-rsc-group-name scs-rsc-group-name
    2. Konfigurieren Sie SCS so, dass der Start erfolgt, bevor ERS nach einem Failover auf den anderen Server verschoben wird:

      # crm configure order ord-sap-SID-first-start-ascs \
       Optional: scs-instance-rsc-name:start \
       ers-instance-rsc-name:stop symmetrical=false
  3. Deaktivieren Sie den Wartungsmodus.

    # crm configure property maintenance-mode="false"
  4. Prüfen Sie die Konfiguration der Gruppen, die Colocation-Einschränkungen und die Reihenfolge:

    # crm config show

    Die Ausgabe sollte Zeilen wie im folgenden Beispiel enthalten:

    ENSA1

    group ers-aha-rsc-group-name filesystem-rsc-nw-aha-ers health-check-rsc-nw-ha-ers vip-rsc-nw-aha-ers ers-aha-instance-rsc-name
    group scs-aha-rsc-group-name filesystem-rsc-nw-aha-scs health-check-rsc-nw-ha-scs vip-rsc-nw-aha-scs scs-aha-instance-rsc-name \
            meta resource-stickiness=3000
    colocation prevent-aha-scs-ers-coloc -5000: ers-aha-rsc-group-name scs-aha-rsc-group-name
    location fencing-rsc-nw-aha-vm-1-loc fencing-rsc-nw-aha-vm-1 -inf: nw-ha-vm-1
    location fencing-rsc-nw-aha-vm-2-loc fencing-rsc-nw-aha-vm-2 -inf: nw-ha-vm-2
    location loc-sap-AHA-failover-to-ers scs-aha-instance-rsc-name \
            rule 2000: runs_ers_AHA eq 1

    ENSA2

    group ers-aha-rsc-group-name filesystem-rsc-nw-aha-ers health-check-rsc-nw-ha-ers vip-rsc-nw-aha-ers ers-aha-instance-rsc-name
    group scs-aha-rsc-group-name filesystem-rsc-nw-aha-scs health-check-rsc-nw-ha-scs vip-rsc-nw-aha-scs scs-aha-instance-rsc-name \
            meta resource-stickiness=3000
    location fencing-location-nw-aha-vm-1 fencing-rsc-nw-aha-vm-1 -inf: nw-ha-vm-1
    location fencing-location-nw-aha-vm-2 fencing-rsc-nw-aha-vm-2 -inf: nw-ha-vm-2
    order ord-sap-AHA-first-start-ascs Optional: scs-aha-instance-rsc-name:start ers-aha-instance-rsc-name:stop symmetrical=false
    colocation prevent-aha-scs-ers-coloc -5000: ers-aha-rsc-group-name scs-aha-rsc-group-name

Cluster testen

In diesem Abschnitt erfahren Sie, wie Sie die folgenden Tests ausführen:

  • Auf Konfigurationsfehler prüfen
  • Prüfen, ob die SCS- und ERS-Ressourcen den Server während eines Failovers richtig wechseln
  • Prüfen, ob die Sperren beibehalten werden
  • Compute Engine bestätigen, dass Wartungsereignisse keinen Failover auslösen

Clusterkonfiguration von SAP prüfen

  1. Prüfen Sie als Root auf einem der Server, welche Instanzen auf dem Server aktiv sind:

    # crm status
  2. Zum sidadm-Nutzer wechseln

    # su - sid-loweradm
  3. Prüfen Sie die Clusterkonfiguration. Geben Sie als Instanznummer die Instanznummer der SCS- oder ERS-Instanz an, die auf dem Server aktiv ist, auf dem Sie den Befehl eingeben:

    > sapcontrol -nr instance-number -function HAGetFailoverConfig

    HAActive sollte TRUE sein, wie im folgenden Beispiel gezeigt:

    20.05.2021 01:33:25
    HAGetFailoverConfig
    OK
    HAActive: TRUE
    HAProductVersion: SUSE Linux Enterprise Server for SAP Applications 15 SP2
    HASAPInterfaceVersion: SUSE Linux Enterprise Server for SAP Applications 15 SP2 (sap_suse_cluster_connector 3.1.2)
    HADocumentation: https://www.suse.com/products/sles-for-sap/resource-library/sap-best-practices/
    HAActiveNode: nw-ha-vm-1
    HANodes: nw-ha-vm-1, nw-ha-vm-2
  4. Suchen Sie als sidadm nach Fehlern in der Konfiguration:

    > sapcontrol -nr instance-number -function HACheckConfig

    Die Ausgabe sollte in etwa dem folgenden Beispiel entsprechen:

    20.05.2021 01:37:19
    HACheckConfig
    OK
    state, category, description, comment
    SUCCESS, SAP CONFIGURATION, Redundant ABAP instance configuration, 0 ABAP instances detected
    SUCCESS, SAP CONFIGURATION, Redundant Java instance configuration, 0 Java instances detected
    SUCCESS, SAP CONFIGURATION, Enqueue separation, All Enqueue server separated from application server
    SUCCESS, SAP CONFIGURATION, MessageServer separation, All MessageServer separated from application server
    SUCCESS, SAP STATE, SCS instance running, SCS instance status ok
    SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version (vh-scs-aha_AHA_00), SAPInstance includes is-ers patch
    SUCCESS, SAP CONFIGURATION, Enqueue replication (vh-scs-aha_AHA_00), Enqueue replication enabled
    SUCCESS, SAP STATE, Enqueue replication state (vh-scs-aha_AHA_00), Enqueue replication active
  5. Prüfen Sie als Root auf einem der Server, auf welchen Knoten Ihre Ressourcen ausgeführt werden:

    # crm status

    Im folgenden Beispiel werden die SCS-Ressourcen auf dem Server nw-ha-vm-1 und die ERS-Ressourcen auf dem Server nw-ha-vm-2 ausgeführt.

    # Cluster Summary:
      * Stack: corosync
      * Current DC: nw-ha-vm-2 (version 2.0.4+20200616.2deceaa3a-3.3.1-2.0.4+20200616.2deceaa3a) - partition with quorum
      * Last updated: Thu May 20 16:58:46 2021
      * Last change:  Thu May 20 16:57:31 2021 by ahaadm via crm_resource on nw-ha-vm-2
      * 2 nodes configured
      * 10 resource instances configured
    
    Node List:
      * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
    
    Active Resources:
      * fencing-rsc-nw-aha-vm-1     (stonith:fence_gce):     Started nw-ha-vm-2
      * fencing-rsc-nw-aha-vm-2     (stonith:fence_gce):     Started nw-ha-vm-1
      * Resource Group: scs-aha-rsc-group-name:
        * filesystem-rsc-nw-aha-scs (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
        * health-check-rsc-nw-ha-scs        (ocf::heartbeat:anything):       Started nw-ha-vm-1
        * vip-rsc-nw-aha-scs        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-1
        * scs-aha-instance-rsc-name (ocf::heartbeat:SAPInstance):    Started nw-ha-vm-1
      * Resource Group: ers-aha-rsc-group-name:
        * filesystem-rsc-nw-aha-ers (ocf::heartbeat:Filesystem):     Started nw-ha-vm-2
        * health-check-rsc-nw-ha-ers        (ocf::heartbeat:anything):       Started nw-ha-vm-2
        * vip-rsc-nw-aha-ers        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-2
        * ers-aha-instance-rsc-name (ocf::heartbeat:SAPInstance):    Started nw-ha-vm-2
  6. Simulieren Sie als sidadm auf dem Server, auf dem SCS aktiv ist, Folgendes:

    > sapcontrol -nr scs-instance-number -function HAFailoverToNode ""
  7. Wenn Sie als Root das Failover mit crm_mon ausführen, wird SCS auf den anderen Server verschoben und ERS auf diesem Server beendet. Daraufhin wird ERS auf den Server verschoben, auf dem SCS bisher ausgeführt wurde.

Beibehalten von Sperreinträgen bestätigen

Um zu prüfen, ob Sperreinträge während eines Failovers beibehalten werden, wählen Sie zuerst den Tab für Ihre Version von Enqueue Server aus und folgen Sie dann der Anleitung zum Erstellen von Sperreinträgen. Simulieren Sie ein Failover und prüfen Sie, ob die Sperreinträge beibehalten werden, nachdem SCS wieder aktiviert wurde.

ENSA1

  1. Generieren Sie als sidadm auf dem Server, auf dem ERS aktiv ist, Sperreneinträge mit dem Programm enqt:

    > enqt pf=/path-to-profile/SID_ERSers-instance-number_ers-virtual-host-name 11 number-of-locks
  2. Prüfen Sie als sidadm auf dem Server, auf dem SCS aktiv ist, ob die Sperreinträge registriert wurden:

    > sapcontrol -nr scs-instance-number -function EnqGetStatistic | grep locks_now

    Wenn Sie zehn Sperren erstellt haben, sollte die Ausgabe in etwa so aussehen:

    locks_now: 10
  3. Starten Sie als sidadm auf dem Server, auf dem ERS aktiv ist, die Monitoringfunktion OpCode=20 des Programms enqt:

    > enqt pf=/path-to-profile/SID_ERSers-instance-number_ers-virtual-host-name 20 1 1 9999

    Beispiel:

    > enqt pf=/sapmnt/AHA/profile/AHA_ERS10_vh-ers-aha 20 1 1 9999
  4. Wenn SCS aktiv ist, starten Sie den Server neu.

    Wenn der Pacemaker auf dem Monitoring-Server den ERS-Vorgang beendet, um ihn auf den anderen Server zu verschieben, sollte die Ausgabe in etwa so aussehen:

    Number of selected entries: 10
    Number of selected entries: 10
    Number of selected entries: 10
    Number of selected entries: 10
    Number of selected entries: 10
  5. Wenn der enqt-Monitor beendet wird, beenden Sie den Monitor, indem Sie Ctrl + c eingeben.

  6. Überwachen Sie das Cluster-Failover optional als Root auf einem der Server:

    # crm_mon
  7. Nachdem Sie als sidadm bestätigt haben, dass die Sperren beibehalten wurden, geben Sie die Sperren frei:

    > enqt pf=/path-to-profile/SID_ERSers-instance-number_ers-virtual-host-name 12 number-of-locks
  8. Prüfen Sie als sidadm auf dem Server, auf dem SCS aktiv ist, ob die Sperreinträge entfernt wurden:

    > sapcontrol -nr scs-instance-number -function EnqGetStatistic | grep locks_now

ENSA2

  1. Generieren Sie als sidadm auf dem Server, auf dem ERS aktiv ist, Sperreneinträge mit dem Programm enq_adm:

    > enq_admin --set_locks=number-of-locks:X:DIAG::TAB:%u pf=/path-to-profile/SID_ERSers-instance-number_ers-virtual-host-name
  2. Prüfen Sie als sidadm auf dem Server, auf dem SCS aktiv ist, ob die Sperreinträge registriert wurden:

    > sapcontrol -nr scs-instance-number -function EnqGetStatistic | grep locks_now

    Wenn Sie zehn Sperren erstellt haben, sollte die Ausgabe in etwa so aussehen:

    locks_now: 10
  3. Wenn SCS aktiv ist, starten Sie den Server neu.

  4. Überwachen Sie das Cluster-Failover optional als Root auf einem der Server:

    # crm_mon
  5. Prüfen Sie als sidadm auf dem Server, auf dem SCS neu gestartet wurde, ob die Sperreinträge beibehalten wurden:

    > sapcontrol -nr scs-instance-number -function EnqGetStatistic | grep locks_now
  6. Geben Sie als sidadm auf dem Server, auf dem ERS aktiv ist, die Sperren frei, nachdem Sie sich vergewissert haben, dass die Sperren beibehalten wurden:

    > enq_admin --release_locks=number-of-locks:X:DIAG::TAB:%u pf=/path-to-profile/SID_ERSers-instance-number_ers-virtual-host-name
  7. Prüfen Sie als sidadm auf dem Server, auf dem SCS aktiv ist, ob die Sperreinträge entfernt wurden:

    > sapcontrol -nr scs-instance-number -function EnqGetStatistic | grep locks_now

    Die Ausgabe sollte in etwa dem folgenden Beispiel entsprechen:

    locks_now: 0

Compute Engine-Wartungsereignis simulieren

Simulieren Sie ein Compute Engine-Wartungsereignis, um sicherzustellen, dass die Live-Migration keinen Failover auslöst.

Die Zeitlimit- und Intervallwerte, die in dieser Anleitung verwendet werden, berücksichtigen die Dauer der Live-Migrationen. Wenn Sie kürzere Werte verwenden, ist das Risiko, dass die Live-Migration einen Failover auslöst, höher.

So testen Sie die Toleranz Ihres Clusters für die Live-Migration:

  1. Lösen Sie auf dem primären Knoten ein simuliertes Wartungsereignis mit dem folgenden Cloud SDK-Befehl aus:

    # gcloud compute instances simulate-maintenance-event primary-instance-name
  2. Vergewissern Sie sich, dass sich der primäre Knoten nicht ändert:

    # crm status

Fehlerbehebung

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

Support für SAP NetWeaver auf SLES

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

Support

Wenden Sie sich bei Problemen mit der Infrastruktur oder den Diensten von Google Cloud an Customer Care. Kontaktdaten finden Sie in der Google Cloud Console auf der Seite Supportübersicht. Wenn Customer Care feststellt, dass sich um ein Problem Ihres SAP-Systems handelt, werden Sie an den SAP-Support verwiesen.

Reichen Sie bei Problemen in Zusammenhang mit SAP-Produkten Ihre Supportanfrage beim SAP-Support ein. SAP wertet das Support-Ticket aus und leitet es gegebenenfalls an die Google Cloud-Komponente BC-OP-LNX-GOOGLE oder BC-OP-NT-GOOGLE weiter, wenn es sich um ein Problem mit der Google Cloud-Infrastruktur handelt.

Supportanforderungen

Bevor Sie Support für SAP-Systeme sowie für die Infrastruktur und Dienste von Google Cloud erhalten können, müssen Sie die Mindestanforderungen für den Supportplan erfüllen.

Weitere Informationen zu den Mindestsupportanforderungen für SAP in Google Cloud finden Sie hier:

Aufgaben nach dem Deployment ausführen

Bevor Sie Ihr SAP NetWeaver-System verwenden, sollten Sie das neue SAP NetWeaver-HA-System sichern.

Weitere Informationen:

Nächste Schritte

Weitere Informationen finden Sie unter den folgenden Links:

+ Leitfaden zur Planung der Hochverfügbarkeit für SAP NetWeaver in Google Cloud + SAP in Google Cloud: Whitepaper zur Hochverfügbarkeit + Weitere Informationen zu VM-Verwaltung und -Monitoring finden Sie im Betriebsleitfaden für SAP NetWeaver