Anleitung für die manuelle Konfiguration von Hochverfügbarkeitsclustern für SAP NetWeaver unter RHEL

Diese Anleitung zeigt Ihnen, wie Sie einen leistungsoptimierten Red Hat Enterprise Linux (RHEL) Hochverfügbarkeitscluster (HA) für SAP NetWeaver-Systeme bereitstellen und konfigurieren.

Mit Ausnahme der Vorgehensweisen, die spezifisch für den Standalone Enqueue Server 2 (ENSA2) sind, der nur in ABAP verfügbar ist, gilt diese Anleitung sowohl für ABAP- als auch für Java-SAP NetWeaver-Stacks.

Sofern in der Anleitung nicht eine Ausnahme angegeben ist, sind Beispiele, die "ASCS" verwenden, sowohl für ABAP SAP Central Services (ASCS) als auch für Java SAP Central Services (SCS) gültig.

Wenn Sie einen Java-Stack verwenden, ersetzen Sie vor dem Verwenden der Befehle und Beispiele in dieser Anleitung alle Vorkommen von "ASCS" durch "SCS".

Diese Anleitung umfasst die Schritte für Folgendes:

• Internen Passthrough-Network-Load-Balancer konfigurieren, um Traffic bei einem Ausfall umzuleiten
• Pacemaker-Cluster unter RHEL konfigurieren, um die SAP-Systeme und andere Ressourcen während eines Failovers zu verwalten

Dieser Leitfaden enthält auch Schritte 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.

Informationen zum Konfigurieren eines Hochverfügbarkeitsclusters für SAP NetWeaver unter SUSE Linux Enterprise Server (SLES) finden Sie im Leitfaden für die manuelle Konfiguration von Hochverfügbarkeitsclustern für SAP NetWeaver unter SLES.

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

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

• Zwei Host-VMs, eine für die aktive ASCS-Instanz und eine für die aktive Instanz des ENSA2 Enqueue Replicator oder des ENSA1 Enqueue Replication Server (ENSA1). Sowohl ENSA2- als auch ENSA1-Instanzen werden als ERS bezeichnet.
• 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.

Informationen zum Automatisieren der Bereitstellung von SAP NetWeaver-HA-Systemen mit Terraform finden Sie unter Terraform: Konfigurationsanleitung für Hochverfügbarkeitscluster für SAP NetWeaver unter RHEL.

Vorbereitung

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

• Sie haben den Planungsleitfaden für SAP NetWeaver und den Planungsleitfaden für Hochverfügbarkeit für SAP NetWeaver in Google Cloud gelesen.
• Sie oder Ihre Organisation haben ein Google Cloud-Konto. Außerdem haben Sie ein Projekt für die SAP NetWeaver-Bereitstellung erstellt. Informationen zum Erstellen von Google Cloud-Konten und -Projekten finden Sie unter Projekt erstellen im SAP NetWeaver-Bereitstellungsleitfaden für Linux.
• Wenn Ihre SAP-Arbeitslast die Anforderungen an den Datenstandort, die Zugriffssteuerung oder die Supportmitarbeiter oder gesetzliche Anforderungen erfüllen muss, müssen Sie den erforderlichen Assured Workloads-Ordner erstellen. Weitere Informationen finden Sie unter Compliance und Steuerung der Datenhoheit für SAP in Google Cloud.

• Bei einem internen VPC-DNS muss der Wert der Variable vmDnsSetting in Ihren Projektmetadaten entweder GlobalOnly oder ZonalPreferred sein, damit die Knotennamen zonenübergreifend aufgelöst werden können. Die Standardeinstellung von vmDnsSetting ist ZonalOnly. Weitere Informationen finden Sie unter:

  • DNS-Namen für Projekte oder Instanzen konfigurieren
  • Benutzerdefinierte Metadaten abfragen
  • Benutzerdefinierte Metadaten für das gesamte Projekt einrichten

• Sie haben eine Dateifreigabe mit einer freigegebenen NFS-Dateispeicherlösung wie Filestore Enterprise eingerichtet.

• Wenn OS Login in den Projektmetadaten aktiviert ist, müssen Sie OS Login vorübergehend deaktivieren, bis die Bereitstellung abgeschlossen ist. Für die Bereitstellung konfiguriert dieses Verfahren SSH-Schlüssel in Instanzmetadaten. Bei aktiviertem OS Login sind metadatenbasierte SSH-Schlüsselkonfigurationen deaktiviert und diese Bereitstellung schlägt fehl. Nach Abschluss der Bereitstellung können Sie die OS Login-Funktion wieder aktivieren.

  Weitere Informationen finden Sie unter:

  • OS Login aktivieren oder deaktivieren
  • SSH-Schlüssel zu VMs hinzufügen, die metadatenbasierte SSH-Schlüssel verwenden

Folgen Sie diesen Empfehlungen, um zu vermeiden, dass Ihre VM-Instanz versehentlich im Internet veröffentlicht wird:

• Verwenden Sie ein NAT-Gateway.
• Erstellen Sie Firewallregeln, die den gesamten externen Zugriff blockieren, den Sie nicht benötigen.
• Gehen Sie beim Erstellen Ihrer VMs so vor:
  • Geben Sie für jede VM ein Netzwerk-Tag zur Verwendung in Routing- und Firewallregeln an. Wenn Sie die von Google Cloud bereitgestellte Deployment Manager-Vorlage nutzen, legen Sie Tags mit networkTag: [TAG] fest.
  • Erstellen Sie die VMs ohne externe IP-Adresse. Wenn Sie die von Google Cloud bereitgestellten Deployment Manager-Vorlagen verwenden, geben Sie publicIP: No an.

Weitere Informationen von RHEL

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

• Konfigurieren Sie SAP NetWeaver ASCS/ERS ENSA1 mit eigenständigen Ressourcen in RHEL 7.5+ und RHEL 8
• SAP S/4HANA ASCS/ERS mit eigenständigem Enqueue Server 2 (ENSA2) in Pacemaker konfigurieren
• SAP-Hinweis 2002167 – Red Hat Enterprise Linux 7.x: Installation und Upgrade
• SAP-Hinweis 2772999 – Red Hat Enterprise Linux 8.x: Installation und Konfiguration
• SAP-Hinweis 3108316 – Red Hat Enterprise Linux 9.x: Installation und Konfiguration
• SAP-Hinweis 2641322 – Installation von ENSA2 und Aktualisierung von ENSA1 auf ENSA2, wenn die Red Hat-Hochverfügbarkeitslösungen für SAP verwendet werden

Netzwerk erstellen

Erstellen Sie aus Sicherheitsgründen ein neues Netzwerk. Durch das Festlegen von Firewallregeln oder die Nutzung eines anderen Verfahrens der Zugriffskontrolle steuern Sie, wer Zugriff hat.

Wenn Ihr Projekt ein Standard-VPC-Netzwerk (Virtual Private Cloud) hat, verwenden Sie es nicht. Erstellen Sie stattdessen Ihr eigenes VPC-Netzwerk, sodass nur die von Ihnen explizit formulierten Firewallregeln gelten.

Während der Bereitstellung müssen VM-Instanzen normalerweise auf das Internet zugreifen können, um den Google Cloud-Agent für SAP herunterzuladen. Wenn Sie eines der von SAP zertifizierten Linux-Images verwenden, die in Google Cloud verfügbar sind, benötigen die VM-Instanzen außerdem einen Internetzugang, um die Lizenz zu registrieren und auf Repositories von Betriebssystemanbietern zuzugreifen. Eine Konfiguration mit einem NAT-Gateway und VM-Netzwerk-Tags unterstützt diesen Zugriff selbst dann, wenn die Ziel-VMs keine externen IP-Adressen haben.

So richten Sie das Netzwerk ein:

Console

1. Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.

   Zur Seite VPC-Netzwerke

2. Klicken Sie auf VPC-Netzwerk erstellen.
3. Geben Sie einen Namen für das Netzwerk ein.

   Der Name muss der Namenskonvention entsprechen. VPC-Netzwerke verwenden die Namenskonvention von Compute Engine.

4. Wählen Sie unter Modus für Subnetzerstellung die Option Benutzerdefiniert aus.
5. Legen Sie im Abschnitt Neues Subnetz folgende Konfigurationsparameter für das Subnetz fest:
   1. Geben Sie einen Namen für das Subnetz ein.
   2. Wählen Sie unter Region die Compute Engine-Region aus, in der Sie das Subnetz erstellen möchten.
   3. Wählen Sie für IP-Stack-Typ die Option IPv4 (einzelner Stack) aus und geben Sie dann einen IP-Adressbereich im CIDR-Format ein, z. B. 10.1.0.0/24.

      Dies ist der primäre IPv4-Bereich für das Subnetz. Wenn Sie mehrere Subnetze erstellen möchten, weisen Sie den Subnetzen im Netzwerk nicht überlappende CIDR-IP-Adressbereiche zu. Beachten Sie, dass jedes Subnetz und seine internen IP-Adressbereiche einer einzelnen Region zugeordnet sind.

   4. Klicken Sie auf Fertig.
6. Klicken Sie auf Subnetz hinzufügen und wiederholen Sie die vorherigen Schritte, um weitere Subnetze zu erstellen. Sie können dem Netzwerk weitere Subnetze hinzufügen, nachdem Sie das Netzwerk erstellt haben.
7. Klicken Sie auf Erstellen.

gcloud

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 Name muss der Namenskonvention entsprechen. VPC-Netzwerke verwenden die Namenskonvention von Compute Engine.

   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 hinzufügen 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 Subnetze 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.

Wichtiger Hinweis: Wenn Sie Cloud NAT konfigurieren, geben Sie mindestens 160 als Mindestanzahl von Ports pro VM an. Bestimmte Betriebssystem-Updates führen gleichzeitige Prozesse aus, die möglicherweise den Cloud NAT-Standardwert für die Anzahl der Ports überschreiten, was zu Aktivierungs- oder Downloadfehlern führen kann.

Wenn Sie eine Cloud NAT-Instanz erstellen, geben Sie die Anzahl der Ports im Feld Mindestanzahl an Ports pro VM unter Erweiterte Konfigurationen auf der Seite „NAT-Gateway erstellen“ in der Google Cloud Console ein.

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

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

Firewallregeln hinzufügen

Standardmäßig 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.

Hinweis: Das folgende Verfahren ist eine vereinfachte Version der Anleitung für das Erstellen von Firewallregeln. Eine ausführliche Anleitung finden Sie in der Dokumentation zu Virtual Private Cloud.

So erstellen Sie eine Firewallregel:

1. Rufen Sie in der Google Cloud Console die Seite Firewall des VPC-Netzwerks auf.

   Zur Firewall

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 Google Cloud-CLI 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-rhel-8-4.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.
   type	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/rhel-8-4-sap-ha Eine Liste der verfügbaren Image-Familien finden Sie in der Google Cloud Console auf der Seite 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 rhel-sap-cloud sein. Eine Liste der Google Cloud-Image-Projekte finden Sie auf der Seite Images in der Dokumentation zu Compute Engine.
   usrsapSize	Integer	Die Größe des Laufwerks /usr/sap. Die Mindestgröße beträgt 8 GB.
   sapmntSize	Integer	Die Größe des Laufwerks /sapmnt. 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 zwar 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: [e-mail]
   publicIP	Boolesch	Optional. Legt fest, ob Ihre VM-Instanz eine öffentliche IP-Adresse erhält. Der Standardwert ist Yes. Hinweis: Geben Sie No nur an, wenn Sie ein NAT-Gateway mit einem für die VM definierten Netzwerk-Tag konfiguriert oder für die VM eine andere Route zum Internet bereitgestellt haben. Wenn keine Route zum Internet angegeben ist, schlägt die Installation fehl.
   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

   wobei

   • 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/rhel-8-4-sap-ha
    linuxImageProject: rhel-sap-cloud
    usrsapSize: 15
    sapmntSize: 15
    swapSize: 24
    networkTag: cluster-ntwk-tag,allow-health-check
    serviceAccount: [e-mail]
- 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/rhel-8-4-sap-ha
    linuxImageProject: rhel-sap-cloud
    usrsapSize: 15
    sapmntSize: 15
    swapSize: 24
    networkTag: cluster-ntwk-tag,allow-health-check
    serviceAccount: [e-mail]

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.

Log prüfen

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

   Hinweis: Wenn Sie diesen Schritt in Cloud Logging ausführen, können Kosten anfallen. Weitere Informationen finden Sie unter Cloud Logging – Preise.

   Zu Cloud Logging

2. Filtern Sie die Logs:

   Log-Explorer

   1. Wechseln Sie auf der Seite Log-Explorer zum Bereich Abfrage.

   2. Wählen Sie im Drop-down-Menü Ressource die Option Global aus und klicken Sie dann auf Hinzufügen.

      Wenn die Option Global nicht angezeigt wird, geben Sie im Abfrageeditor die folgende Abfrage ein:

      resource.type="global"
      "Deployment"
      

   3. Klicken Sie auf Abfrage ausführen.

   Legacy-Loganzeige

   • Wählen Sie auf der Seite Legacy-Loganzeige im einfachen Auswahlmenü die Option Global als Logging-Ressource aus.

3. Analysieren Sie die gefilterten Logs:

   • Wenn "--- Finished" angezeigt wird, ist die Verarbeitung des Deployments abgeschlossen und Sie können mit dem nächsten Schritt fortfahren.

   • Wenn ein Kontingentfehler auftritt:

     1. Erhöhen Sie auf der Seite IAM & Verwaltung > Kontingente alle Kontingente, die nicht die im Planungsleitfaden für SAP HANA aufgeführten Anforderungen erfüllen.

     2. Löschen Sie in Deployment Manager auf der Seite Deployments die Bereitstellung, um VMs und nichtflüchtige Speicher von der fehlgeschlagenen Installation zu bereinigen.

     3. Führen Sie die Bereitstellung noch einmal aus.

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.

      

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.

Backend-Kommunikation der Load-Balancer zwischen den VMs aktivieren

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

Ändern Sie die Konfiguration von google-guest-agent, der in der Linux-Gastumgebung für alle von Google Cloud bereitgestellten Linux-Images enthalten ist, um die Backend-Kommunikation zwischen den VMs zu aktivieren.

Führen Sie die folgenden Schritte auf jeder VM aus, die Teil Ihres Clusters ist, um die Backend-Kommunikation für den Load-Balancer zu aktivieren:

1. Beenden Sie den Agent:

   sudo service google-guest-agent stop

2. Öffnen oder erstellen Sie die Datei /etc/default/instance_configs.cfg zur Bearbeitung. Beispiel:

   sudo vi /etc/default/instance_configs.cfg

3. Geben Sie in der Datei /etc/default/instance_configs.cfg die folgenden Konfigurationsattribute an: Wenn die Abschnitte nicht vorhanden sind, erstellen Sie sie. Achten Sie insbesondere darauf, dass die beiden Attribute target_instance_ips und ip_forwarding auf false gesetzt sind:

   [IpForwarding]
   ethernet_proto_id = 66
   ip_aliases = true
   target_instance_ips = false
   
   [NetworkInterfaces]
   dhclient_script = /sbin/google-dhclient-script
   dhcp_command =
   ip_forwarding = false
   setup = true
   

4. Starten Sie den Gast-Agent-Dienst:

   sudo service google-guest-agent start

Die Konfiguration der Load-Balancer-Systemdiagnose erfordert sowohl einen empfangsbereiten Zielport für die Systemdiagnose als auch eine Zuweisung der virtuellen IP zu einer Schnittstelle. Weitere Informationen finden Sie unter Konfiguration des Load-Balancers testen.

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 Cloud Storage-Buckets aus. Siehe Uploads und Downloads.
• 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 primären zum sekundä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_VM_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. Wenn Sie Filestore für Ihre Dateifreigabelösung verwenden möchten, empfehlen wir die Verwendung der Unternehmensstufe von Filestore. Informationen zum Erstellen einer Filestore-Instanz finden Sie unter Instanzen erstellen.

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

   Ersetzen Sie NFS_PATH durch den Pfad zu Ihrer NFS-Dateifreigabelösung. Beispiel: 10.49.153.26:/nfs_share_nw_ha.

3. Erstellen Sie auf beiden Servern Verzeichnisse für sapmnt, das zentrale Transportverzeichnis 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,SIDASCSASCS_INSTANCE_NUMBER,SIDERSERS_INSTANCE_NUMBER}

   Dabei gilt:

   • SID: die SAP-System-ID (SID). Verwenden Sie für alle Buchstaben Großbuchstaben. Beispiel: AHA.
   • ASCS_INSTANCE_NUMBER: Die Instanznummer des ASCS-Systems. Beispiel: 00.
   • ERS_INSTANCE_NUMBER: Die Instanznummer des ERS-Systems. Beispiel: 10.

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/ASCSASCS_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 ASCSASCS_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 Ihre Dateifreigabe-Lö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

   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
   

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

   Ersetzen Sie FILE_SHARE_NAME durch den Namen Ihrer NFS-Dateifreigabelösung. Beispiel: nfs_share_nw_ha.

   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/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 Passthrough-Network-Load-Balancer-Dienst mit Failover-Unterstützung leitet den ASCS- und ERS-Traffic an die aktiven Instanzen in einem SAP NetWeaver-Cluster weiter. Interne Passthrough-Network-Load-Balancer verwenden virtuelle IP-Adressen (VIP), Backend-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 ASCS- 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 ASCS und für die VIP des ERS. Für ASCS 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 ASCS_VIP_NAME \
     --region CLUSTER_REGION --subnet CLUSTER_SUBNET \
     --addresses ASCS_VIP_ADDRESS
   
   ~ gcloud compute addresses create ERS_VIP_NAME \
     --region CLUSTER_REGION --subnet CLUSTER_SUBNET \
     --addresses ERS_VIP_ADDRESS

   Dabei gilt:

   • ASCS_VIP_NAME: Geben Sie einen Namen für die virtuelle IP-Adresse der ASCS-Instanz an. Beispiel: ascs-aha-vip.
   • CLUSTER_REGION: Geben Sie die Google Cloud-Region an, in der sich Ihr Cluster befindet. z. B. us-central1.
   • CLUSTER_SUBNET: Geben Sie das Subnetzwerk an, das Sie mit Ihrem Cluster verwenden. Beispiel: example-sub-network-sap.
   • ASCS_VIP_ADDRESS: (Optional) Geben Sie eine IP-Adresse für die virtuelle ASCS-IP-Adresse in CIDR-Notation an. Beispiel: 10.1.0.2.
   • ERS_VIP_NAME: Geben Sie einen Namen für die virtuelle IP-Adresse der ERS-Instanz an. Beispiel: ers-aha-vip.
   • ERS_VIP_ADDRESS: Geben Sie optional eine IP-Adresse für die virtuelle ERS-IP-Adresse in CIDR-Notation an. Beispiel: 10.1.0.4.

   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.2
   addressType: INTERNAL
   creationTimestamp: '2022-04-04T15:04:25.872-07:00'
   description: ''
   id: '555067171183973766'
   kind: compute#address
   name: ascs-aha-vip
   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/ascs-aha-vip
   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:

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
10.1.0.113 nw-ha-vm-2.us-central1-c.c.example-project-123456.internal nw-ha-vm-2
10.1.0.2   ascs-aha-vip
10.1.0.4   ers-aha-vip
10.1.0.114 nw-ha-vm-1.us-central1-b.c.example-project-123456.internal nw-ha-vm-1  # Added by Google
169.254.169.254 metadata.google.internal  # Added by Google

Cloud Load Balancing-Systemdiagnosen erstellen

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

1. Erstellen Sie die Systemdiagnosen in Cloud Shell. Geben Sie Portnummern für die ASCS- 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 ASCS_HEALTH_CHECK_NAME \
      --port=ASCS_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: ascs-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.

   • ~ gcloud compute instances add-tags  PRIMARY_VM_NAME \
     --zone=PRIMARY_ZONE \
     --tags NETWORK_TAGS

   • ~ gcloud compute instances add-tags  SECONDARY_VM_NAME \
     --zone=SECONDARY_ZONE \
     --tags NETWORK_TAGS

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:ASCS_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_ZONE

   2. ~ gcloud compute instance-groups unmanaged add-instances PRIMARY_IG_NAME \
      --zone=PRIMARY_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_ZONE

   2. ~ gcloud compute instance-groups unmanaged add-instances SECONDARY_IG_NAME \
      --zone=SECONDARY_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
   

Backend-Dienste konfigurieren

Erstellen Sie zwei Backend-Dienste, einen für ASCS und einen für ERS. Fügen Sie jedem Backend-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 Backend-Diensten.

1. Erstellen Sie in Cloud Shell den Backend-Dienst und die Failover-Gruppe für ASCS:

   1. Erstellen Sie den Backend-Dienst für ASCS:

      ~ gcloud compute backend-services create ASCS_BACKEND_SERVICE_NAME \
         --load-balancing-scheme internal \
         --health-checks ASCS_HEALTH_CHECK_NAME \
         --no-connection-drain-on-failover \
         --drop-traffic-if-unhealthy \
         --failover-ratio 1.0 \
         --region CLUSTER_REGION \
         --global-health-checks

   2. Fügen Sie die primäre Instanzgruppe dem ASCS-Backend-Dienst hinzu:

      ~ gcloud compute backend-services add-backend ASCS_BACKEND_SERVICE_NAME \
        --instance-group PRIMARY_IG_NAME \
        --instance-group-zone PRIMARY_ZONE \
        --region CLUSTER_REGION

   3. Fügen Sie die sekundäre Instanzgruppe als Failover-Instanzgruppe für den ASCS-Backend-Dienst hinzu:

      ~ gcloud compute backend-services add-backend ASCS_BACKEND_SERVICE_NAME \
        --instance-group SECONDARY_IG_NAME \
        --instance-group-zone SECONDARY_ZONE \
        --failover \
        --region CLUSTER_REGION

2. Erstellen Sie in Cloud Shell den Backend-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_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_ZONE \
        --failover \
        --region CLUSTER_REGION

3. Prüfen Sie optional, ob die Backend-Dienste die Instanzgruppen wie erwartet enthalten:

   ~ gcloud compute backend-services describe BACKEND_SERVICE_NAME \
    --region=CLUSTER_REGION

   Die Ausgabe für den ASCS-Backend-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: '2022-04-06T10:58:37.744-07:00'
   description: ''
   failoverPolicy:
     disableConnectionDrainOnFailover: true
     dropTrafficIfUnhealthy: true
     failoverRatio: 1.0
   fingerprint: s4qMEAyhrV0=
   healthChecks:
   - https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/ascs-aha-health-check-name
   id: '6695034709671438882'
   kind: compute#backendService
   loadBalancingScheme: INTERNAL
   name: ascs-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/ascs-aha-backend-service-name
   sessionAffinity: NONE
   timeoutSec: 30

4. In Cloud Shell erstellen Sie Weiterleitungsregeln für die ASCS- und ERS-Backend-Dienste:

   1. Erstellen Sie die Weiterleitungsregel von der ASCS-VIP zum ASCS-Backend-Dienst:

      ~ gcloud compute forwarding-rules create ASCS_FORWARDING_RULE_NAME \
      --load-balancing-scheme internal \
      --address ASCS_VIP_ADDRESS \
      --subnet CLUSTER_SUBNET \
      --region CLUSTER_REGION \
      --backend-service ASCS_BACKEND_SERVICE_NAME \
      --ports ALL

   2. Erstellen Sie die Weiterleitungsregel von der ERS-VIP zum ERS-Backend-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

Note: Your backend instance groups won't register as healthy until you have completed the Pacemaker cluster configuration.

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.

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

   $ sudo yum install socat

2. Weisen Sie die VIP der Netzwerkkarte "eth0" vorübergehend auf der primären VM zu:

   ip addr add VIP_ADDRESS dev eth0

3. Starten Sie auf der primären VM einen socat-Prozess, um 60 Sekunden lang den Port der ASCS-Systemdiagnose zu überwachen:

   $ timeout 60s socat - TCP-LISTEN:ASCS_HEALTHCHECK_PORT_NUM,fork

4. Warten Sie in Cloud Shell einige Sekunden, bis die Systemdiagnose den Listener erkennt, und prüfen Sie dann den Status Ihrer ASCS-Backend-Instanzgruppe:

   ~ gcloud compute backend-services get-health ASCS_BACKEND_SERVICE_NAME \
     --region CLUSTER_REGION

   Die Ausgabe sollte ähnlich wie das folgende Beispiel für ASCS 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

5. Entfernen Sie die VIP der Schnittstelle "eth0":

   ip addr del VIP_ADDRESS dev eth0

6. Wiederholen Sie die Schritte für ERS und ersetzen Sie die Werte der ASCS-Variablen durch die ERS-Werte.

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. Rufen Sie in der Google Cloud Console die Compute Engine-Seite Systemdiagnosen auf:

   Zur Seite „Systemdiagnosen“

2. Klicken Sie auf den Namen Ihrer Systemdiagnose.

3. Klicken Sie auf Bearbeiten.

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

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

6. Warten Sie in Cloud Shell einige Sekunden, bis die Systemdiagnose den Listener erkennt, und prüfen Sie dann den Status Ihrer Backend-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

7. Wenn Sie fertig sind, ändern Sie die Portnummer der Systemdiagnose wieder in die ursprüngliche Portnummer.

Listener für Systemdiagnosen installieren

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

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

Installieren Sie auf jedem Host im Cluster einen Listener. Führen Sie dazu die folgenden Schritte aus:

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

   # yum install haproxy

2. Kopieren und benennen Sie die standardmäßige Konfigurationsdatei haproxy.cfg um, um sie als Vorlagendatei für die mehreren HAProxy-Instanzen zu erstellen:

   # cp /usr/lib/systemd/system/haproxy.service \
       /etc/systemd/system/haproxy@.service
   

3. Bearbeiten Sie die Abschnitte [Unit] und [Service] der Datei haproxy@.service, um den Instanzparameter %i aufzunehmen, wie im folgenden Beispiel gezeigt:

   [Unit]
   Description=HAProxy Load Balancer %i
   After=network-online.target
   Wants=network-online.target
   
   [Service]
   Environment="CONFIG=/etc/haproxy/haproxy-%i.cfg" "PIDFILE=/run/haproxy-%i.pid"
   ...
   

   Weitere Informationen von Red Hat zu systemd-Einheitenvorlagen finden Sie unter Mit instanziierten Einheiten arbeiten.

4. Erstellen Sie die Konfigurationsdatei haproxy.cfg für die ASCS-Instanz. Beispiel:

   # vi /etc/haproxy/haproxy-SIDscs.cfg

   Ersetzen Sie SID durch die SAP-System-ID (SID). Verwenden Sie für alle Buchstaben Großbuchstaben. Beispiel: AHA.

5. Fügen Sie in die ASCS-Konfigurationsdatei haproxy-SIDscs.cfg die folgende Konfiguration ein und ersetzen Sie ASCS_HEALTHCHECK_PORT_NUM durch die Portnummer, die Sie beim Erstellen der Compute Engine-Systemdiagnose für ASCS angegeben haben:

   global
       chroot      /var/lib/haproxy
       pidfile     /var/run/haproxy-%i.pid
       user        haproxy
       group       haproxy
       daemon
   defaults
       mode                    tcp
       log                     global
       option                  dontlognull
       option                  redispatch
       retries                 3
       timeout queue           1m
       timeout connect         10s
       timeout client          1m
       timeout server          1m
       timeout check           10s
       maxconn                 3000
   
   # Listener for SAP healthcheck
   listen healthcheck
      bind *:ASCS_HEALTHCHECK_PORT_NUM

6. Erstellen Sie die Konfigurationsdatei haproxy.cfg für die ERS-Instanz. Beispiel:

   # vi /etc/haproxy/haproxy-SIDers.cfg

7. Fügen Sie in die ERS-Konfigurationsdatei haproxy-SIDers.cfg die folgende Konfiguration ein und ersetzen Sie ERS_HEALTHCHECK_PORT_NUM durch die Portnummer, die Sie angegeben haben, als Sie die Compute Engine-Systemdiagnose für ERS erstellt haben:

   global
       chroot      /var/lib/haproxy
       pidfile     /var/run/haproxy-%i.pid
       user        haproxy
       group       haproxy
       daemon
   defaults
       mode                    tcp
       log                     global
       option                  dontlognull
       option                  redispatch
       retries                 3
       timeout queue           1m
       timeout connect         10s
       timeout client          1m
       timeout server          1m
       timeout check           10s
       maxconn                 3000
   
   # Listener for SAP healthcheck
   listen healthcheck
      bind *:ERS_HEALTHCHECK_PORT_NUM

8. Laden Sie die systemd-Dienste neu:

   # systemctl daemon-reload

9. Prüfen Sie, ob der HAProxy-Dienst ordnungsgemäß eingerichtet ist:

    # systemctl start haproxy
    # systemctl status haproxy
    # systemctl | grep haproxy

   Im zurückgegebenen Status sollte haproxy.service als active (running) angezeigt werden.

   ● haproxy.service - HAProxy Load Balancer
      Loaded: loaded (/usr/lib/systemd/system/haproxy.service; enabled; vendor preset: disabled)
      Active: active (running) since Sun 2022-04-10 16:48:10 UTC; 2 days ago
    Main PID: 1079 (haproxy)
       Tasks: 2 (limit: 100996)
      Memory: 5.1M
      CGroup: /system.slice/haproxy.service
              ├─1079 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid
              └─1083 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid
   
   Apr 10 16:48:10 dru-hanw-ascs systemd[1]: Starting HAProxy Load Balancer...
   Apr 10 16:48:10 dru-hanw-ascs systemd[1]: Started HAProxy Load Balancer.

10. Wiederholen Sie die vorherigen Schritte auf jedem Host im Cluster.

Pacemaker einrichten

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

Das Verfahren beruht auf der Red Hat-Dokumentation zum Konfigurieren von Hochverfügbarkeitsclustern, einschließlich der folgenden Veröffentlichungen (ein Red Hat-Abo ist erforderlich):

• SAP NetWeaver ASCS/ERS ENSA1 mit eigenständigen Ressourcen in RHEL 7.5+ und RHEL 8 konfigurieren
• SAP S/4HANA ASCS/ERS mit eigenständigem Enqueue Server 2 (ENSA2) in Pacemaker konfigurieren

Informationen von SAP zur Installation und Konfiguration von RHEL finden Sie unter:

• SAP-Hinweis 3108316 – Red Hat Enterprise Linux 9.x: Installation und Konfiguration
• SAP-Hinweis 2772999 – Red Hat Enterprise Linux 8.x: Installation und Konfiguration
• SAP-Hinweis 2002167 – Red Hat Enterprise Linux 7.x: Installation und Upgrade

Erforderliche Clusterpakete und Betriebssystem-Firewall auf beiden Hosts konfigurieren

Installieren und aktualisieren Sie als Root auf den primären und sekundären Hosts die erforderlichen Clusterpakete, konfigurieren Sie hacluster und konfigurieren Sie den Firewalldienst des Betriebssystems.

1. Installieren Sie die folgenden erforderlichen Clusterpakete:

   # yum install pcs pacemaker
   # yum install fence-agents-gce
   # yum install resource-agents-gcp
   # yum install resource-agents-sap
   # yum install sap-cluster-connector

2. Aktualisieren Sie die installierten Pakete:

   # yum update -y

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

   # passwd hacluster

4. Geben Sie in den Eingabeaufforderungen ein Passwort für hacluster an.

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

   # firewall-cmd --permanent --add-service=high-availability

   # firewall-cmd --reload

6. Starten Sie den pcs-Dienst und konfigurieren Sie ihn so, dass er beim Booten startet:

   # systemctl start pcsd.service
   # systemctl enable pcsd.service

7. Prüfen Sie den Status des pcs-Dienstes:

   # systemctl status pcsd.service

   Die Ausgabe sollte in etwa so aussehen:

   ● pcsd.service - PCS GUI and remote configuration interface
     Loaded: loaded (/usr/lib/systemd/system/pcsd.service; enabled; vendor preset: disabled)
     Active: active (running) since Sat 2020-06-13 21:17:05 UTC; 25s ago
       Docs: man:pcsd(8)
             man:pcs(8)
   Main PID: 31627 (pcsd)
     CGroup: /system.slice/pcsd.service
             └─31627 /usr/bin/ruby /usr/lib/pcsd/pcsd
   Jun 13 21:17:03 hana-ha-vm-1 systemd[1]: Starting PCS GUI and remote configuration interface...
   Jun 13 21:17:05 hana-ha-vm-1 systemd[1]: Started PCS GUI and remote configuration interface.

Cluster erstellen

1. Autorisieren Sie als Root den Nutzer hacluster auf einem der Knoten. Klicken Sie auf den Tab für Ihre RHEL-Version, um den Befehl anzuzeigen:

   RHEL 8 und höher:

   # pcs host auth PRIMARY_VM_NAME SECONDARY_VM_NAME

   RHEL 7

   # pcs cluster auth PRIMARY_VM_NAME SECONDARY_VM_NAME

2. Geben Sie bei Aufforderung den Nutzernamen hacluster und das Passwort ein, das Sie für den Nutzer hacluster festgelegt haben.

3. Erstellen Sie den Cluster:

   RHEL 8 und höher:

   # pcs cluster setup CLUSTER_NAME PRIMARY_VM_NAME SECONDARY_VM_NAME

   RHEL 7

   # pcs cluster setup --name CLUSTER_NAME PRIMARY_VM_NAME SECONDARY_VM_NAME

Corosync-Konfigurationsdateien aktualisieren

Mit den folgenden Schritten werden empfohlene Clusterwerte für Corosync festgelegt. Wenn die Corosync-Konfigurationsdatei /etc/corosync/corosync.conf noch nicht vorhanden oder leer ist, können Sie die Beispieldatei im Verzeichnis /etc/corosync/ als Basis für Ihre Konfiguration verwenden.

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:

   RHEL 8

   totem {
   ...
     transport: knet
     token: 20000
     token_retransmits_before_loss_const: 10
     join: 60
     max_messages: 20
   ...
   }

   RHEL 7

   totem {
   ...
     transport: udpu
     token: 20000
     token_retransmits_before_loss_const: 10
     join: 60
     max_messages: 20
   ...
   }

3. Synchronisieren Sie die Konfiguration mit Ihrem zweiten Server:

   RHEL 8 und höher:

   # pcs cluster sync corosync

   RHEL 7

   # pcs cluster sync

4. Cluster über die primäre VM aktivieren und starten

   # pcs cluster enable --all
   # pcs cluster start --all

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

   # corosync-cmapctl

6. Prüfen Sie den Clusterstatus:

   # pcs status

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

   Cluster name: nwha
   
   WARNINGS:
   No stonith devices and stonith-enabled is not false
   
   Cluster Summary:
   * Stack: corosync
   * Current DC: nw-ha-vm-2 (version 2.0.5-9.el8_4.3-ba59be7122) - partition with quorum
   * 2 nodes configured
   * 0 resource instances configured
   
   Node List:
   * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
   
   Full List of Resources:
   * No resources
   
   Daemon Status:
   corosync: active/enabled
   pacemaker: active/enabled
   pcsd: active/enabled

Clusterressourcen für die Infrastruktur konfigurieren

Sie müssen Pacemaker-Ressourcen für die folgende Clusterinfrastruktur definieren:

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

Sie definieren zuerst die Ressourcen für das Fencing-Gerät, das freigegebene Dateisystem, die Systemdiagnosen und die VIPs. Anschließend installieren Sie SAP NetWeaver. Nach der Installation von SAP NetWeaver definieren Sie schließlich die Clusterressourcen für die ASCS- und ERS-Komponenten.

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

Erstellen Sie für jede VM im Cluster eine Clusterressource für das Fencing-Gerät, damit der Cluster die 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:

   # pcs stonith create FENCING_RESOURCE_PRIMARY_VM fence_gce \
       port="PRIMARY_VM_NAME" \
       zone="PRIMARY_ZONE" \
       project="CLUSTER_PROJECT_ID" \
       pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
       op monitor interval="300s" timeout="120s" \
       op start interval="0" timeout="60s"

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:

   # pcs constraint location FENCING_RESOURCE_PRIMARY_VM avoids 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:

   # pcs stonith create FENCING_RESOURCE_SECONDARY_VM fence_gce \
       port="SECONDARY_VM_NAME" \
       zone="SECONDARY_ZONE" \
       project="CLUSTER_PROJECT_ID" \
       pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
       op monitor interval="300s" timeout="120s" \
       op start interval="0" timeout="60s"

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:

   # pcs constraint location FENCING_RESOURCE_SECONDARY_VM avoids 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

Dateisystemressourcen erstellen

Definieren Sie die Clusterressourcen für die ASCS- und ERS-Verzeichnisse im freigegebenen Dateisystem.

1. Konfigurieren Sie eine Dateisystemressource für das ASCS-Verzeichnis.

   # pcs resource create ASCS_FILE_SYSTEM_RESOURCE Filesystem \
       device="NFS_PATH/usrsapSIDASCSASCS_INSTANCE_NUMBER" \
       directory="/usr/sap/SID/ASCSASCS_INSTANCE_NUMBER" \
       fstype=nfs force_unmount=safe \
       --group ASCS_RESOURCE_GROUP \
       op start interval=0 timeout=60 \
       op stop interval=0 timeout=120 \
       op monitor interval=200 timeout=40

   Dabei gilt:

   • ASCS_FILE_SYSTEM_RESOURCE: Geben Sie einen Namen für die Clusterressource für das ASCS-Dateisystem an.
   • NFS_PATH: Geben Sie den Verzeichnispfad zum NFS-Dateisystem an.
   • SID: Geben Sie die System-ID (SID) an. Verwenden Sie für alle Buchstaben Großbuchstaben.
   • ASCS_INSTANCE_NUMBER: Geben Sie die ASCS-Instanznummer an.
   • ASCS_RESOURCE_GROUP: Geben Sie einen eindeutigen Gruppennamen für die ASCS-Clusterressourcen an. Mit einer Namenskonvention wie "SID_ASCSinstance_number_group" können Sie die Eindeutigkeit gewährleisten. Beispiel: nw8_ASCS00_group.

     Da eine Gruppe noch nicht vorhanden ist, erstellt Pacemaker diese Gruppe. Wenn Sie andere ASCS-Ressourcen erstellen, fügen Sie sie dieser Gruppe hinzu.

2. Konfigurieren Sie eine Dateisystemressource für das ERS-Verzeichnis.

   # pcs resource create ERS_FILE_SYSTEM_RESOURCE Filesystem \
       device="NFS_PATH/usrsapSIDERSERS_INSTANCE_NUMBER" \
       directory="/usr/sap/SID/ERSERS_INSTANCE_NUMBER" \
       fstype=nfs force_unmount=safe \
       --group ERS_RESOURCE_GROUP \
       op start interval=0 timeout=60 \
       op stop interval=0 timeout=120 \
       op monitor interval=200 timeout=40

   Dabei gilt:

   • ERS_FILE_SYSTEM_RESOURCE: Geben Sie einen Namen für die Dateisystemressource an.
   • NFS_PATH: Geben Sie den Verzeichnispfad zum NFS-Dateisystem an.
   • SID: Geben Sie die System-ID (SID) an. Verwenden Sie für alle Buchstaben Großbuchstaben.
   • ERS_INSTANCE_NUMBER: Geben Sie die ERS-Instanznummer an.
   • ERS_RESOURCE_GROUP: Geben Sie einen eindeutigen Gruppennamen für die ERS-Clusterressourcen an. Mit einer Namenskonvention wie "SID_ERSinstance_number_group" können Sie die Eindeutigkeit gewährleisten. Beispiel: nw8_ERS10_group.

     Da eine Gruppe noch nicht vorhanden ist, erstellt Pacemaker diese Gruppe. Wenn Sie andere ERS-Ressourcen erstellen, fügen Sie sie dieser Gruppe hinzu.

Virtuelle IP-Adressressource erstellen

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

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

   • gcloud compute addresses describe ASCS_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 ASCS- und ERS-VIPs.

   # pcs resource create ASCS_VIP_RESOURCE IPaddr2 \
       ip=ASCS_VIP_ADDRESS cidr_netmask=32 nic=eth0 \
       op monitor interval=3600 timeout=60 \
       --group ASCS_RESOURCE_GROUP

   # pcs resource create ERS_VIP_RESOURCE IPaddr2 \
       ip=ERS_VIP_ADDRESS cidr_netmask=32 nic=eth0 \
       op monitor interval=3600 timeout=60 \
       --group ERS_RESOURCE_GROUP

Systemdiagnose-Ressourcen erstellen

1. Konfigurieren Sie die Clusterressource für die ASCS-Systemdiagnose:

   # pcs resource create _HEALTHCHECK_SCS service:haproxy@SIDascs \
      op monitor interval=10s timeout=20s \
      --group ASCS_RESOURCE_GROUP

2. Konfigurieren Sie die Clusterressource für die ERS-Systemdiagnose:

   # pcs resource create _HEALTHCHECK_ERS service:haproxy@SIDers \
      op monitor interval=10s timeout=20s \
      --group ERS_RESOURCE_GROUP

Zusätzliche Standardeinstellungen für Cluster festlegen

1. Legen Sie zusätzliche Clusterattribute fest:

   # pcs resource defaults resource-stickiness=1
   # pcs resource defaults migration-threshold=3

Definierte Ressourcen aufrufen

Rufen Sie die Cluster auf, die Sie bisher definiert haben, um sicherzustellen, dass sie korrekt sind.

1. Rufen Sie den Clusterstatus auf:

   # pcs status

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

   Cluster name: nwha
   Cluster Summary:
     * Stack: corosync
     * Current DC: nw-ha-vm-1 (version 2.0.5-9.el8_4.3-ba59be7122) - partition with quorum
     * 2 nodes configured
     * 8 resource instances configured
   
   Node List:
     * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
   
   Full List of Resources:
     * fence-nw-ha-vm-2    (stonith:fence_gce):     Started nw-ha-vm-1
     * fence-nw-ha-vm-1    (stonith:fence_gce):     Started nw-ha-vm-2
     * Resource Group: nw8_ascs00_group:
       * nw8_vip_ascs00    (ocf::heartbeat:IPaddr2):    Started nw-ha-vm-1
       * nw8_healthcheck_scs   (service:haproxy@nw8scs):    Started nw-ha-vm-1
       * nw8_fs_ascs00 (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
     * Resource Group: nw8_ers10_group:
       * nw8_vip_ers10 (ocf::heartbeat:IPaddr2):    Started nw-ha-vm-2
       * nw8_healthcheck_ers   (service:haproxy@nw8ers):    Started nw-ha-vm-2
       * nw8_fs_ers10  (ocf::heartbeat:Filesystem):     Started nw-ha-vm-2
   
   Daemon Status:
     corosync: active/enabled
     pacemaker: active/enabled
     pcsd: active/enabled
   

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

   # sudo pcs property set 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_LCadm -g sapsys
   # usermod -a -G sapinst SID_LCadm
   # useradd -u UID_SAPADM sapadm -g sapinst
   
   # chown SID_LCadm:sapsys /usr/sap/SID/SYS
   # chown SID_LCadm:sapsys /sapmnt/SID -R
   # chown SID_LCadm:sapsys /usr/sap/trans -R
   # chown SID_LCadm:sapsys /usr/sap/SID/SYS -R
   # chown SID_LCadm:sapsys /usr/sap/SID -R

   Dabei gilt:

   • GID_SAPINST: Geben Sie die Linux-Gruppen-ID für das SAP-Bereitstellungstool an.
   • GID_SAPSYS: Geben Sie die Linux-Gruppen-ID für den SAPSYS-Nutzer an.
   • UID_SIDADM: Geben Sie die Linux-Nutzer-ID für den Administrator des SAP-Systems (SID) an.
   • SID_LC: Geben Sie die System-ID (SID) an. Verwenden Sie Kleinbuchstaben für Buchstaben.
   • UID_SAPADM: Geben Sie die Nutzer-ID für den SAP-Host-Agent an.
   • SID: Geben Sie die System-ID (SID) an. Verwenden Sie für alle Buchstaben Großbuchstaben.

   Nachstehend sehen Sie ein praktisches Schema für GID- und UID-Nummerierung:

   Group sapinst      1001
   Group sapsys       1002
   Group dbhshm       1003
   
   User  en2adm       2001
   User  sapadm       2002
   User  dbhadm       2003

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

   # pcs node standby

   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:

   # pcs status

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

   Cluster name: nwha
      Cluster Summary:
        * Stack: corosync
        * Current DC: nw-ha-vm-1 (version 2.0.5-9.el8_4.3-ba59be7122) - partition with quorum
        * 2 nodes configured
        * 8 resource instances configured
   
      Node List:
        * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
   
      Full List of Resources:
        * fence-nw-ha-vm-2  (stonith:fence_gce):     Started nw-ha-vm-1
        * fence-nw-ha-vm-1  (stonith:fence_gce):     Stopped
        * Resource Group: nw8_ascs00_group:
          * nw8_vip_ascs00  (ocf::heartbeat:IPaddr2):    Started nw-ha-vm-1
          * nw8_healthcheck_scs (service:haproxy@nw8scs):    Started nw-ha-vm-1
          * nw8_fs_ascs00   (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
        * Resource Group: nw8_ers10_group:
          * nw8_vip_ers10   (ocf::heartbeat:IPaddr2):    Started nw-ha-vm-1
          * nw8_healthcheck_ers (service:haproxy@nw8ers):    Started nw-ha-vm-1
          * nw8_fs_ers10    (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
   
      Daemon Status:
        corosync: active/enabled
   

3. Wechseln Sie auf dem primären Server als Root-Nutzer in ein temporäres Installationsverzeichnis, z. B. /tmp, um die ASCS-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 ASCS-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:

   # pcs node unstandby

ERS-Komponente installieren

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

   # su - SID_LCadm -c "sapcontrol -nr ASCS_INSTANCE_NUMBER -function Stop"
   # su - SID_LCadm -c "sapcontrol -nr ASCS_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.

   # pcs node standby

   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:

   # pcs 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 ASCS-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:

   # pcs node unstandby

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 SID_LCadm hinzufügen.

SAP-Diensteinträge prüfen

1. Achten Sie auf beiden Servern darauf, dass die Datei /usr/sap/sapservices Einträge für die ASCS- und ERS-Dienste enthält. Dazu können Sie die systemV- oder systemd-Einbindung verwenden.

   Mit dem Befehl sapstartsrv können Sie über die Optionen pf=PROFILE_OF_THE_SAP_INSTANCE und -reg fehlende Einträge hinzufügen.

   Weitere Informationen zu diesen Einbindungen finden Sie in den folgenden SAP-Hinweisen:

   • 3139184 – Linux: systemd-Einbindung für sapstartsrv und SAP-Host-Agent

   • 3115048 – sapstartsrv mit nativer Linux-systemd-Unterstützung

   systemV

   Das folgende Beispiel zeigt die Einträge für die ASCS- und ERS-Dienste in der Datei /usr/sap/sapservices bei Verwendung der systemV-Einbindung:

   # 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 \
   -D -u SID_LCadm
   /usr/sap/hostctrl/exe/sapstartsrv \
   pf=/usr/sap/SID/SYS/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
   -D -u SID_LCadm

   systemd

   1. Prüfen Sie, ob die Datei /usr/sap/sapservices Einträge für die ASCS- und ERS-Dienste enthält. Das folgende Beispiel zeigt, wie diese Einträge in der Datei /usr/sap/sapservices angezeigt werden, wenn Sie die systemd-Einbindung verwenden:

      systemctl --no-ask-password start SAPSID_ASCS_INSTANCE_NUMBER # sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ASCSASCS_INSTANCE_NUMBER_SID_LCascs
      systemctl --no-ask-password start SAPSID_ERS_INSTANCE_NUMBER # sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ERSERS_INSTANCE_NUMBER_SID_LCers

   2. Deaktivieren Sie die systemd-Einbindung für die ASCS- und die ERS-Instanzen:

      Achtung: Durch die Deaktivierung der systemd-Einbindung werden auch die SAP-Instanzen beendet.

      # systemctl disable SAPSID_ASCS_INSTANCE_NUMBER.service
      # systemctl stop SAPSID_ASCS_INSTANCE_NUMBER.service
      # systemctl disable SAPSID_ERS_INSTANCE_NUMBER.service
      # systemctl stop SAPSID_ERS_INSTANCE_NUMBER.service

   3. Prüfen Sie, ob die systemd-Einbindung deaktiviert ist:

      # systemctl list-unit-files | grep sap

      Eine Ausgabe, die dem folgenden Beispiel ähnelt, bedeutet, dass die systemd-Einbindung deaktiviert ist. Beachten Sie, dass einige Dienste (z. B. saphostagent und saptune) aktiviert und andere deaktiviert sind.

      SAPSID_ASCS_INSTANCE_NUMBER.service disabled
      SAPSID_ERS_INSTANCE_NUMBER.service disabled
      saphostagent.service enabled
      sapinit.service generated
      saprouter.service disabled
      saptune.service enabled

SAP-Dienste beenden

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

   # su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function Stop"
   # su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function StopService"

2. Prüfen Sie auf jedem Server, ob alle Dienste beendet wurden:

   # su - SID_LCadm -c "sapcontrol -nr ASCS_INSTANCE_NUMBER -function GetSystemInstanceList"
   # su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function GetSystemInstanceList"

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

   GetSystemInstanceList
   FAIL: NIECONN_REFUSED (Connection refused), NiRawConnect failed in plugin_fopen()

Automatischen Dienstneustart in SAP deaktivieren

Wichtiger Hinweis: Dieser Abschnitt ist NUR für systemV erforderlich.

Da die Clustersoftware den Neustart der SAP-Dienste während eines Failover verwaltet, sollten Sie zur Vermeidung von Konflikten die Fähigkeit der SAP-Software zum automatischen Neustart der Dienste deaktivieren.

1. Bearbeiten Sie auf beiden Knoten die Datei /usr/sap/sapservices, um den automatischen Neustart der SAP-Software zu deaktivieren. Fügen Sie dazu ein Kommentarzeichen # am Anfang des Befehls sapstartsrv für die ASCS- und ERS-Komponenten hinzu.

   Beispiel:

   #!/bin/sh
   
    #LD_LIBRARY_PATH=/usr/sap/SID/ASCSASCS_INSTANCE_NUMBER/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/SID/ASCSASCS_INSTANCE_NUMBER/exe/sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME -D -u SID_LCadm
    #LD_LIBRARY_PATH=/usr/sap/SID/ERSERS_INSTANCE_NUMBER/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/SID/ERSERS_INSTANCE_NUMBER/exe/sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME -D -u SID_LCadm
    

ASCS- 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_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME

   SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME

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

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

Clusterressourcen für ASCS und ERS konfigurieren

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

   # pcs property set maintenance-mode="true"

2. Prüfen Sie, ob sich der Cluster im Wartungsmodus befindet:

   # pcs status

3. Erstellen Sie die Clusterressourcen für die ASCS- und ERS-Dienste:

   ENSA1

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

     # pcs resource create ASCS_INSTANCE_RESOURCE SAPInstance \
         InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
         START_PROFILE=/sapmnt/SID/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
         AUTOMATIC_RECOVER=false meta resource-stickiness=5000 migration-threshold=1 \
         failure-timeout=60  --group ASCS_RESOURCE_GROUP \
         op monitor interval=20 on-fail=restart timeout=60 \
         op start interval=0 timeout=600 \
         op stop interval=0 timeout=600
     

     # pcs resource meta ASCS_RESOURCE_GROUP resource-stickiness=3000
     

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

     # pcs resource create ERS_INSTANCE_RESOURCE SAPInstance \
         InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
         START_PROFILE=/sapmnt/SID/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
         AUTOMATIC_RECOVER=false IS_ERS=true --group ERS_RESOURCE_GROUP \
         op monitor interval=20 on-fail=restart timeout=60 \
         op start interval=0 timeout=600 \
         op stop interval=0 timeout=600
     

   ENSA2

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

     # pcs resource create ASCS_INSTANCE_RESOURCE SAPInstance \
         InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
         START_PROFILE=/sapmnt/SID/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
         AUTOMATIC_RECOVER=false meta resource-stickiness=5000 \
         --group ASCS_RESOURCE_GROUP \
         op monitor interval=20 on-fail=restart timeout=60 \
         op start interval=0 timeout=600 \
         op stop interval=0 timeout=600
     

     # pcs resource meta ASCS_RESOURCE_GROUP resource-stickiness=3000
     

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

     # pcs resource create ERS_INSTANCE_RESOURCE SAPInstance \
         InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
         START_PROFILE=/sapmnt/SID/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
         AUTOMATIC_RECOVER=false IS_ERS=true --group ERS_RESOURCE_GROUP \
         op monitor interval=20 on-fail=restart timeout=60 \
         op start interval=0 timeout=600 \
         op stop interval=0 timeout=600
     

Standort- und Reihenfolgeeinschränkungen konfigurieren

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

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

ENSA1

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

   # pcs constraint colocation add ERS_RESOURCE_GROUP with \
       ASCS_RESOURCE_GROUP -5000
   

2. Konfigurieren Sie ASCS so, dass ein Failover auf den Server erfolgt, auf dem ERS ausgeführt wird. Dies wird durch das Flag runsersSID gleich 1 bestimmt:

   # pcs constraint location ASCS_INSTANCE \
       rule score=2000 runs_ers_SID eq 1

3. Konfigurieren Sie ASCS so, dass der Start erfolgt, bevor ERS nach einem Failover auf den anderen Server verschoben wird:

   # pcs constraint order start ASCS_RESOURCE_GROUP then \
       stop ERS_RESOURCE_GROUP symmetrical=false kind=Optional
   

ENSA2

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

   # pcs constraint colocation add ERS_RESOURCE_GROUP  with \
       ASCS_RESOURCE_GROUP -5000
   

2. Konfigurieren Sie ASCS so, dass der Start erfolgt, bevor ERS nach einem Failover auf den anderen Server verschoben wird:

   # pcs constraint order start ASCS_RESOURCE_GROUP then \
       stop ERS_RESOURCE_GROUP symmetrical=false kind=Optional
   

1. Prüfen Sie die Einschränkungen:

   # pcs constraint

   Die Ausgabe sollte in etwa so aussehen:

   Location Constraints:
     Resource: ascs-aha-instance
       Constraint: location-ascs-instance
         Rule: score=2000
           Expression: runs_ers_HKN eq 1
     Resource: fence-nw-ha-vm-1
       Disabled on: nw-ha-vm-1 (score:-INFINITY)
     Resource: fence-nw-ha-vm-2
       Disabled on: nw-ha-vm-2 (score:-INFINITY)
   Ordering Constraints:
     start ascs-group then stop ers-group (kind:Optional) (non-symmetrical)
   Colocation Constraints:
     ascs-group with ers-group (score:-5000)
   Ticket Constraints:

2. Deaktivieren Sie als Root von einem der Server den Clusterwartungsmodus:

   # pcs property set maintenance-mode="false"

Red Hat-Cluster-Connector für SAP konfigurieren

Konfigurieren Sie auf jedem Host im Cluster den SAP-Startdienst sapstartsrv so, dass er über die HA-Schnittstelle mit der Pacemaker-Clustersoftware kommuniziert.

1. Fügen Sie den SAP-Administrator zur Gruppe haclient hinzu:

   usermod -a -G haclient SID_LCadm

2. Bearbeiten Sie die SAP-Instanzprofile. Fügen Sie dazu die folgenden Zeilen am Ende jedes Profils hinzu. Die Profile finden Sie im Verzeichnis /sapmnt/SID/profiles.

   service/halib = $(DIR_CT_RUN)/saphascriptco.so
   service/halib_cluster_connector = /usr/bin/sap_cluster_connector

3. Wenn die ASCS- und ERS-Instanzressourcen derzeit im Cluster ausgeführt werden, deaktivieren Sie sie:

   pcs resource disable ERS_INSTANCE_RESOURCE
   pcs resource disable ASCS_INSTANCE_RESOURCE

4. Beenden Sie die Dienste auf dem ASCS-Host:

   sapcontrol -nr ASCS_INSTANCE_NUMBER -function StopService

5. Beenden Sie die Dienste auf dem ERS-Host:

   sapcontrol -nr ERS_INSTANCE_NUMBER -function StopService

6. Aktivieren Sie die Ressourcen:

   pcs resource enable ERS_INSTANCE_RESOURCE
   pcs resource enable ASCS_INSTANCE_RESOURCE

7. Wiederholen Sie die vorherigen Schritte auf jedem Host im Cluster.

Weitere Informationen von Red Hat finden Sie unter SAP halib für SAPInstance-Ressourcen in RHEL 7 und 8 konfigurieren.

Datenbank- und Anwendungsserver auf Hosts außerhalb des Clusters installieren

In Hochverfügbarkeitskonfigurationen wird empfohlen, die Datenbank- und Anwendungsserver auf anderen Hosts zu installieren als die ASCS- und ERS-Hosts im Cluster.

Durch die Verwendung separater Hosts für jeden Server reduzieren Sie die Komplexität und verringern Sie das Risiko, dass ein Ausfall mehrere Server betrifft. Außerdem können Sie die Größe jeder Compute Engine an den jeweiligen Servertyp anpassen.

So können Sie die am besten geeignete Maschinengröße auswählen, Fehler vermeiden und die Komplexität reduzieren.

Die Installation der Datenbank- und Anwendungsserver wird in dieser Anleitung nicht behandelt.

Informationen zum Installieren der Datenbankserver finden Sie unter:

• SAP HANA in Google Cloud
• SAP ASE in Google Cloud
• SAP MaxDB in Google Cloud
• IBM Db2 für SAP in Google Cloud

Cluster validieren und testen

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

• Auf Konfigurationsfehler prüfen
• Prüfen, ob die ASCS- und ERS-Ressourcen den Server während eines Failovers richtig wechseln
• Prüfen, ob die Sperren beibehalten werden
• Ein Compute Engine-Wartungsereignis simulieren, damit die Live-Migration kein Failover auslöst

Clusterkonfiguration prüfen

1. Prüfen Sie als Root auf einem der Server, auf welchen Knoten Ihre Ressourcen ausgeführt werden:

   # pcs status

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

   Stack: corosync
     Current DC: nw-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
     Last updated: Wed Apr 13 05:21:21 2022
     Last change: Wed Apr 13 05:21:18 2022 by hacluster via crmd on nw-ha-vm-2
   
     2 nodes configured
     10 resource instances configured
   
     Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
   
     Full list of resources:
   
     fence-nw-ha-vm-1     (stonith:fence_gce):    Started nw-ha-vm-2
     fence-nw-ha-vm-2     (stonith:fence_gce):    Started nw-ha-vm-1
      Resource Group: ascs-group
          ascs-file-system   (ocf::heartbeat:Filesystem):    Started nw-ha-vm-2
          ascs-vip   (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-2
          ascs-healthcheck   (service:haproxy@AHAascs):      Started nw-ha-vm-2
          ascs-aha-instance      (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-2
      Resource Group: ers-group
          ers-file-system    (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
          ers-vip    (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
          ers-healthcheck    (service:haproxy@AHAers):       Started nw-ha-vm-1
          ers-aha-instance       (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-1
   
     Migration Summary:
     * Node nw-ha-vm-1:
     * Node nw-ha-vm-2:

2. Wechseln Sie zum Nutzer SID_LCadm:

   # su - SID_LCadm

3. Prüfen Sie die Clusterkonfiguration. Geben Sie für INSTANCE_NUMBER die Instanznummer der ASCS- 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:

   HAGetFailoverConfig
   
   14.04.2022 17:25:45
   HAGetFailoverConfig
   OK
   HAActive: TRUE
   HAProductVersion: Pacemaker
   HASAPInterfaceVersion: sap_cluster_connector
   HADocumentation: https://github.com/ClusterLabs/sap_cluster_connector
   HAActiveNode:
   HANodes:

4. Suchen Sie als SID_LCadm nach Fehlern in der Konfiguration:

   > sapcontrol -nr INSTANCE_NUMBER -function HACheckConfig

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

   14.04.2022 21:43:39
   HACheckConfig
   OK
   state, category, description, comment
   SUCCESS, SAP CONFIGURATION, Redundant ABAP instance configuration, 0 ABAP 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 (vip-ascs_NWT_00), SAPInstance includes is-ers patch
   SUCCESS, SAP CONFIGURATION, Enqueue replication (vip-ascs_NWT_00), Enqueue replication enabled
   SUCCESS, SAP STATE, Enqueue replication state (vip-ascs_NWT_00), Enqueue replication active
   SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version (vip-ers_NWT_10), SAPInstance includes is-ers patch

5. Simulieren Sie auf dem Server, auf dem ASCS aktiv ist, als SID_LCadm ein Failover:

   > sapcontrol -nr ASCS_INSTANCE_NUMBER -function HAFailoverToNode ""

6. Wenn Sie als Root das Failover mit crm_mon ausführen, wird ASCS auf den anderen Server verschoben und ERS auf diesem Server beendet. Daraufhin wird ERS auf den Server verschoben, auf dem ASCS bisher ausgeführt wurde.

Failover simulieren

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

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

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

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

1. Sicherung Ihres Systems erstellen

2. Schalten Sie als Root auf dem Host mit der aktiven SCS-Instanz die Netzwerkschnittstelle offline:

   $ ip link set eth0 down

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

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

    Stack: corosync
     Current DC: nw-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
     Last updated: Wed Apr 13 05:21:21 2022
     Last change: Wed Apr 13 05:21:18 2022 by hacluster via crmd on nw-ha-vm-2
   
     2 nodes configured
     10 resource instances configured
   
     Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
   
     Full list of resources:
   
     fence-nw-ha-vm-1     (stonith:fence_gce):    Started nw-ha-vm-2
     fence-nw-ha-vm-2     (stonith:fence_gce):    Started nw-ha-vm-1
      Resource Group: ascs-group
          ascs-file-system   (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
          ascs-vip   (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
          ascs-healthcheck   (service:haproxy@AHAascs):      Started nw-ha-vm-1
          ascs-aha-instance      (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-1
      Resource Group: ers-group
          ers-file-system    (ocf::heartbeat:Filesystem):    Started nw-ha-vm-2
          ers-vip    (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-2
          ers-healthcheck    (service:haproxy@AHAers):       Started nw-ha-vm-2
          ers-aha-instance       (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-2
   
     Migration Summary:
     * Node nw-ha-vm-1:
     * Node nw-ha-vm-2:

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 ASCS wieder aktiviert wurde.

ENSA1

1. Generieren Sie als SID_LCadm 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 SID_LCadm auf dem Server, auf dem ASCS aktiv ist, ob die Sperreinträge registriert wurden:

   > sapcontrol -nr ASCS_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 SID_LCadm 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 ASCS 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 SID_LCadm 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 SID_LCadm auf dem Server, auf dem ASCS aktiv ist, ob die Sperreinträge entfernt wurden:

   > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

ENSA2

1. Generieren Sie als SID_LCadm auf dem Server, auf dem ASCS 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_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME

2. Prüfen Sie als SID_LCadm auf dem Server, auf dem ASCS aktiv ist, ob die Sperreinträge registriert wurden:

   > sapcontrol -nr ASCS_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 ERS aktiv ist, prüfen Sie, ob die Sperreinträge repliziert wurden:

   > sapcontrol -nr ERS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

   Die Anzahl der zurückgegebenen Sperren sollte mit der Anzahl der ASCS-Instanz übereinstimmen.

4. Wenn ASCS aktiv ist, starten Sie den Server neu.

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

   # crm_mon

6. Prüfen Sie als SID_LCadm auf dem Server, auf dem ASCS neu gestartet wurde, ob die Sperreinträge beibehalten wurden:

   > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

7. Geben Sie als SID_LCadm 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

8. Prüfen Sie als SID_LCadm auf dem Server, auf dem ASCS aktiv ist, ob die Sperreinträge entfernt wurden:

   > sapcontrol -nr ASCS_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 in Ihrer Clusterkonfiguration kürzere Werte verwenden, ist das Risiko, dass eine Live-Migration ein 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 Befehl der gcloud CLI aus:

   $ gcloud compute instances simulate-maintenance-event PRIMARY_VM_NAME

2. Vergewissern Sie sich, dass sich der primäre Knoten nicht ändert:

   $ pcs status

SAP NetWeaver-Arbeitslast bewerten

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

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

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

Fehlerbehebung

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

Diagnoseinformationen für SAP NetWeaver-Hochverfügbarkeitscluster erfassen

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

Informationen zum Erfassen von Diagnoseinformationen finden Sie unter Hochverfügbarkeitscluster unter RHEL-Diagnoseinformationen.

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, wenn es sich um ein Problem mit der Google Cloud-Infrastruktur handelt, gegebenenfalls an die entsprechende Google Cloud-Komponente in seinem System weiter: BC-OP-LNX-GOOGLE oder BC-OP-NT-GOOGLE.

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:

• Support für SAP in Google Cloud
• SAP-Hinweis 2456406 – SAP auf der Google Cloud Platform: Support-Voraussetzungen (SAP-Nutzerkonto erforderlich)

Aufgaben nach dem Deployment ausführen

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

Weitere Informationen finden Sie in der Betriebsanleitung für SAP NetWeaver.

Nächste Schritte

Weitere Informationen zur Hochverfügbarkeit, zu SAP NetWeaver und zu Google Cloud finden Sie in den folgenden Ressourcen:

• Hochverfügbarkeitscluster für Red Hat Enterprise Linux 7.6 (und höher) in Google Cloud installieren und konfigurieren

• Supportrichtlinien für RHEL-Hochverfügbarkeitscluster – Allgemeine Anforderungen für Fencing/STONith

• Leitfaden zur Planung der Hochverfügbarkeit für SAP NetWeaver in Google Cloud

• Weitere Informationen zu VM-Verwaltung und VM-Monitoring finden Sie in der Betriebsanleitung für SAP NetWeaver.