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

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

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 SLES konfigurieren, um die SAP-Systeme und andere Ressourcen während eines Failovers zu verwalten

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

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

Informationen zum Konfigurieren eines Hochverfügbarkeitsclusters für SAP HANA unter Red Hat Enterprise Linux (RHEL) finden Sie in der Anleitung für die manuelle Konfiguration von Hochverfügbarkeitsclustern für SAP NetWeaver unter RHEL.

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

System, das in dieser Anleitung bereitgestellt wird

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

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

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.

Verwandte Informationen von SUSE

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

• SAP NetWeaver Enqueue Replication 1 High Availability Cluster – Einrichtungsleitfaden für SAP NetWeaver 7.40 und 7.50 | SUSE Linux Enterprise Server for SAP Applications 12
• SAP NetWeaver Enqueue Replication 1 High Availability Cluster – Einrichtungsleitfaden für SAP NetWeaver 7.40 und 7.50 | SUSE Linux Enterprise Server for SAP Applications 15
• SAP S/4 HANA – Enqueue Replication 2 High Availability Cluster – Einrichtungsleitfaden | SUSE Linux Enterprise Server for SAP Applications 12
• SAP S/4 HANA – Enqueue Replication 2 High Availability Cluster – Einrichtungsleitfaden | SUSE Linux Enterprise Server for SAP Applications 15

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-sles15sp3.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/sles-15-sp3-sap 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 suse-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/sles-15-sp3-sap
    linuxImageProject: suse-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/sles-15-sp3-sap
    linuxImageProject: suse-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 die Bereitstellung noch einmal aus.

Google Cloud-CLI aktualisieren

Die Deployment Manager-Vorlage hat Google Cloud-CLI während der Bereitstellung auf den VMs installiert. Aktualisieren Sie die gcloud CLI, damit sie alle aktuellen Updates enthält.

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

2. gcloud CLI aktualisieren

   ~>  sudo gcloud components update

3. Führen Sie dazu die angezeigten Schritte aus.

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

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. Sie müssen das socat-Dienstprogramm ohnehin installieren, da Sie es später beim Konfigurieren von Clusterressourcen benötigen.

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

   # zypper install 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.

Pacemaker einrichten

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

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

Erforderliche Clusterpakete installieren

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

   • Das ha_sles-Muster:

     # zypper install -t pattern ha_sles

   • Das Paket sap-suse-cluster-connector:

     # zypper install -y sap-suse-cluster-connector

   • Falls Sie es nicht bereits installiert haben, das Dienstprogramm socat:

     # zypper install -y socat

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

   # zypper se -t patch SUSE-SLE-HA

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

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

Beim Initialisieren oder Zusammenführen des Clusters werden möglicherweise die folgenden Warnungen angezeigt:

• Keine Firewall erkannt: Diese Warnung weist darauf hin, dass die Clusterinitialisierung die Firewall des Betriebssystems nicht finden oder aktualisieren konnte. Wenn Sie die Firewall eines Betriebssystems verwenden, müssen Sie den Zugriff auf diese Ports zulassen. Außerdem müssen Sie eine VPC-Firewallregel erstellen, die den Zugriff auf diese Ports sowie auf die von der SAP-Anwendung verwendeten Ports zulässt.
• Kein Watchdog-Gerät gefunden: Sie können dies ignorieren. In dieser Anleitung wird SBD nicht verwendet.
• Sie sollten das Passwort "hacluster" ändern: Ändern Sie das Passwort, nachdem Sie diese Anleitung abgeschlossen haben.

Corosync-Konfigurationsdateien erstellen

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

   1. Erstellen Sie mit Ihrem bevorzugten Texteditor die folgende Datei:

      /etc/corosync/corosync.conf

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

      totem {
       version: 2
       secauth: off
       crypto_hash: sha1
       crypto_cipher: aes256
       cluster_name: hacluster
       clear_node_high_bit: yes
       token: 20000
       token_retransmits_before_loss_const: 10
       join: 60
       max_messages:  20
       transport: udpu
       interface {
         ringnumber: 0
         Bindnetaddr: STATIC_IP_OF_THIS_HOST
         mcastport: 5405
         ttl: 1
       }
      }
      logging {
       fileline:  off
       to_stderr: no
       to_logfile: no
       logfile: /var/log/cluster/corosync.log
       to_syslog: yes
       debug: off
       timestamp: on
       logger_subsys {
         subsys: QUORUM
         debug: off
       }
      }
      nodelist {
       node {
         ring0_addr: THIS_HOST_NAME
         nodeid: 1
       }
       node {
         ring0_addr: OTHER_HOST_NAME
         nodeid: 2
       }
      }
      quorum {
       provider: corosync_votequorum
       expected_votes: 2
       two_node: 1
      }

   Dabei gilt:

   • STATIC_IP_OF_THIS_HOST: Geben Sie die statische primäre interne IP-Adresse dieser VM an, wie unter Netzwerkschnittstellen in der Google Cloud Console oder wie von gcloud compute instances describe VM_NAME angezeigt beschrieben.
   • THIS_HOST_NAME: Geben Sie den Hostnamen dieser VM an.
   • OTHER_HOST_NAME: Geben Sie den Hostnamen der anderen VM im Cluster an.

2. Erstellen Sie eine Corosync-Konfigurationsdatei auf dem sekundären Host. Wiederholen Sie dazu die Schritte, die Sie für den primären Host verwendet haben. Mit Ausnahme der statischen IP-Adresse der HDB für das Attribut Bindnetaddr und der Reihenfolge der Hostnamen in der nodelist sind die Attributwerte der Konfigurationsdatei für die Hosts identisch.

Cluster initialisieren

So initialisieren Sie den Cluster:

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

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

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

   # systemctl enable pacemaker
   # systemctl start pacemaker

Zusätzliche Clusterattribute festlegen

1. Legen Sie die allgemeinen Clusterattribute fest:

   # crm configure property stonith-timeout="300s"
   # crm configure property stonith-enabled="true"
   # crm configure rsc_defaults resource-stickiness="1"
   # crm configure rsc_defaults migration-threshold="3"
   # crm configure op_defaults timeout="600"

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

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

Sekundäre VM mit dem Cluster verbinden

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

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

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

      # ssh SECONDARY_VM_NAME 'ha-cluster-join --cluster-node PRIMARY_VM_NAME --yes --interface eth0 csync2'

   2. Führen Sie die Option ssh_merge aus:

      # ssh SECONDARY_VM_NAME 'ha-cluster-join --cluster-node PRIMARY_VM_NAME --yes ssh_merge'

   3. Führen Sie die Option cluster aus:

      # ssh SECONDARY_VM_NAME 'ha-cluster-join --cluster-node PRIMARY_VM_NAME --yes cluster'

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

   1. Aktivieren Sie Pacemaker:

      # ssh SECONDARY_VM_NAME systemctl enable pacemaker

   2. Starten Sie Pacemaker:

      # ssh SECONDARY_VM_NAME systemctl start pacemaker

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

   # crm_mon -s

   Die Ausgabe sollte in etwa so aussehen:

   CLUSTER OK: 2 nodes online, 0 resource instances configured

Clusterressourcen für die Infrastruktur konfigurieren

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

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

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

Wartungsmodus aktivieren

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

   # crm configure property maintenance-mode="true"

2. Bestätigen Sie den Wartungsmodus:

   # crm status

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

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

Fencing einrichten

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

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

Ressourcen für Fencing-Geräte erstellen

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

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

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

2. Konfigurieren Sie den Standort des Fencing-Geräts für die primäre VM so, dass es nur auf der sekundären VM aktiv ist:

   # crm configure location FENCING_LOCATION_NAME_PRIMARY_VM \
     FENCING_RESOURCE_PRIMARY_VM -inf: "PRIMARY_VM_NAME"

3. Bestätigen Sie die neu erstellte Konfiguration:

   # crm config show related:FENCING_RESOURCE_PRIMARY_VM

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

   primitive FENCING_RESOURCE_PRIMARY_VM stonith:fence_gce \
           op monitor interval=300s timeout=120s \
           op start interval=0 timeout=60s \
           params PRIMARY_VM_NAME zone=PRIMARY_ZONE project=CLUSTER_PROJECT_ID pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30
   location FENCING_RESOURCE_PRIMARY_VM FENCING_RESOURCE_PRIMARY_VM -inf: PRIMARY_VM_NAME

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

   # crm configure primitive FENCING_RESOURCE_SECONDARY_VM stonith:fence_gce \
     op monitor interval="300s" timeout="120s" \
     op start interval="0" timeout="60s" \
     params port="SECONDARY_VM_NAME" zone="SECONDARY_VM_ZONE" \
     project="CLUSTER_PROJECT_ID" \
     pcmk_reboot_timeout=300 pcmk_monitor_retries=4

5. Konfigurieren Sie den Standort des Fencing-Geräts für die sekundäre VM so, dass es nur auf der primären VM aktiv ist:

   # crm configure location FENCING_LOCATION_NAME_SECONDARY_VM \
     FENCING_RESOURCE_SECONDARY_VM -inf: "SECONDARY_VM_NAME"

6. Bestätigen Sie die neu erstellte Konfiguration:

   # crm config show related:FENCING_RESOURCE_SECONDARY_VM

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

   primitive FENCING_RESOURCE_SECONDARY_VM stonith:fence_gce \
           op monitor interval=300s timeout=120s \
           op start interval=0 timeout=60s \
           params SECONDARY_VM_NAME zone=SECONDARY_ZONE project=CLUSTER_PROJECT_ID pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30
   location FENCING_RESOURCE_SECONDARY_VM FENCING_RESOURCE_SECONDARY_VM -inf: SECONDARY_VM_NAME

Verzögerung für den Neustart von Corosync festlegen

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

   systemctl edit corosync.service

2. Fügen Sie der Datei die folgenden Zeilen hinzu:

   [Service]
   ExecStartPre=/bin/sleep 60

3. Speichern Sie die Datei und beenden Sie den Editor.

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

   systemctl daemon-reload

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

   service corosync status

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

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

Dateisystemressourcen erstellen

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

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

   # crm configure primitive ASCS_FILE_SYSTEM_RESOURCE Filesystem \
   device="NFS_PATH/usrsapSIDASCSASCS_INSTANCE_NUMBER" \
   directory="/usr/sap/SID/ASCSASCS_INSTANCE_NUMBER" fstype="nfs" \
   op start timeout=60s interval=0 \
   op stop timeout=60s interval=0 \
   op monitor interval=20s timeout=40s

   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 Pfad zum NFS-Dateisystem für ASCS 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.

   # crm configure primitive ERS_FILE_SYSTEM_RESOURCE Filesystem \
   device="NFS_PATH/usrsapSIDERSERS_INSTANCE_NUMBER" \
   directory="/usr/sap/SID/ERSERS_INSTANCE_NUMBER" fstype="nfs" \
   op start timeout=60s interval=0 \
   op stop timeout=60s interval=0 \
   op monitor interval=20s timeout=40s

   Dabei gilt:

   • ERS_FILE_SYSTEM_RESOURCE: Geben Sie einen Namen für die Clusterressource für das ERS-Dateisystem an.
   • NFS_PATH: Geben Sie den Pfad zum NFS-Dateisystem für ERS an.
   • SID: Geben Sie die System-ID (SID) an. Verwenden Sie für alle Buchstaben Großbuchstaben.
   • ERS_INSTANCE_NUMBER: Geben Sie die ASCS-Instanznummer an.

2. Bestätigen Sie die neu erstellte Konfiguration:

   # crm configure show ASCS_FILE_SYSTEM_RESOURCE ERS_FILE_SYSTEM_RESOURCE

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

   primitive ASCS_FILE_SYSTEM_RESOURCE Filesystem \
       params device="NFS_PATH/usrsapSIDASCSASCS_INSTANCE_NUMBER" directory="/usr/sap/SID/ASCSASCS_INSTANCE_NUMBER" fstype=nfs \
       op start timeout=60s interval=0 \
       op stop timeout=60s interval=0 \
       op monitor interval=20s timeout=40s
   primitive ERS_FILE_SYSTEM_RESOURCE Filesystem \
       params device="NFS_PATH/usrsapSIDERSERS_INSTANCE_NUMBER" directory="/usr/sap/SID/ERSERS_INSTANCE_NUMBER" fstype=nfs \
       op start timeout=60s interval=0 \
       op stop timeout=60s interval=0 \
       op monitor interval=20s timeout=40s

Systemdiagnose-Ressourcen erstellen

1. Konfigurieren Sie die Clusterressourcen für die ASCS- und ERS-Systemdiagnosen:

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

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

2. Bestätigen Sie die neu erstellte Konfiguration:

   # crm configure show ERS_HEALTH_CHECK_RESOURCE ASCS_HEALTH_CHECK_RESOURCE

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

   primitive ERS_HEALTH_CHECK_RESOURCE anything \
           params binfile="/usr/bin/socat" cmdline_options="-U TCP-LISTEN:ASCS_HEALTHCHECK_PORT_NUM,backlog=10,fork,reuseaddr /dev/null" \
           op monitor timeout=20s interval=10s \
           op_params depth=0
       primitive ASCS_HEALTH_CHECK_RESOURCE anything \
           params binfile="/usr/bin/socat" cmdline_options="-U TCP-LISTEN:ERS_HEALTHCHECK_PORT_NUM,backlog=10,fork,reuseaddr /dev/null" \
           op monitor timeout=20s interval=10s \
           op_params depth=0

VIP-Ressourcen erstellen

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

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

   • gcloud compute addresses describe 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.

   # crm configure primitive ASCS_VIP_RESOURCE IPaddr2 \
    params ip=ASCS_VIP_ADDRESS cidr_netmask=32 nic="eth0" \
    op monitor interval=3600s timeout=60s

   # crm configure primitive ERS_VIP_RESOURCE IPaddr2 \
    params ip=ERS_VIP_ADDRESS cidr_netmask=32 nic="eth0" \
    op monitor interval=3600s timeout=60s

3. Bestätigen Sie die neu erstellte Konfiguration:

   # crm configure show ASCS_VIP_RESOURCE ERS_VIP_RESOURCE

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

       primitive ASCS_VIP_RESOURCE IPaddr2 \
           params ip=ASCS_VIP_ADDRESS cidr_netmask=32 nic=eth0 \
           op monitor interval=3600s timeout=60s
       primitive ERS_VIP_RESOURCE IPaddr2 \
           params ip=ERS_VIP_RESOURCE cidr_netmask=32 nic=eth0 \
           op monitor interval=3600s timeout=60s

Definierte Ressourcen aufrufen

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

   # crm status

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

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

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:

   # crm configure property maintenance-mode="false"

2. Geben Sie auf beiden Servern als Root die folgenden Befehle ein. Geben Sie dabei die Nutzer- und Gruppen-IDs an, die für Ihre Umgebung geeignet sind:

   # groupadd -g GID_SAPINST sapinst
   # groupadd -g GID_SAPSYS sapsys
   # useradd -u UID_SIDADM SID_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:

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

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

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

   # crm status

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

   Stack: corosync
    Current DC: nw-ha-vm-1 (version 1.1.24+20201209.8f22be2ae-3.12.1-1.1.24+20201209.8f22be2ae) - partition with quorum
    Last updated: Thu May 27 17:45:16 2021
    Last change: Thu May 27 17:45:09 2021 by root via crm_attribute on nw-ha-vm-2
   
    2 nodes configured
    8 resource instances configured
   
    Node nw-ha-vm-2: standby
    Online: [ nw-ha-vm-1 ]
   
    Full list of resources:
   
     fencing-rsc-nw-aha-vm-1        (stonith:fence_gce):    Stopped
     fencing-rsc-nw-aha-vm-2        (stonith:fence_gce):    Started nw-ha-vm-1
     filesystem-rsc-nw-aha-scs      (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
     filesystem-rsc-nw-aha-ers      (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
     health-check-rsc-nw-ha-scs     (ocf::heartbeat:anything):      Started nw-ha-vm-1
     health-check-rsc-nw-ha-ers     (ocf::heartbeat:anything):      Started nw-ha-vm-1
     vip-rsc-nw-aha-scs     (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
     vip-rsc-nw-aha-ers     (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
   

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

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

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.

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

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

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

   # crm status

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

   • Verwenden Sie denselben Nutzer und dasselbe Passwort für den Zugriff auf SWPM, die Sie bei der Installation der 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:

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

SAP-Dienste konfigurieren

Sie müssen prüfen, ob die Dienste ordnungsgemäß konfiguriert sind, die Einstellungen in den ASCS- und ERS-Profilen prüfen und der Nutzergruppe haclient den Nutzer 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 wie saphostagent und saptune aktiviert und andere Dienste 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

      Weitere Informationen finden Sie im SUSE-Dokument systemd-Dienste der ASCS- und ERS-SAP-Instanzen deaktivieren.

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

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. Aktivieren Sie das Paket sap-suse-cluster-connector. Fügen Sie dazu die folgenden Zeilen in die ASCS- und ERS-Instanzprofile ein:

   #-----------------------------------------------------------------------
   # SUSE HA library
   #-----------------------------------------------------------------------
   service/halib = $(DIR_CT_RUN)/saphascriptco.so
   service/halib_cluster_connector = /usr/bin/sap_suse_cluster_connector
   

4. Wenn Sie ENSA1 verwenden, aktivieren Sie die Keepalive-Funktion. Legen Sie dazu Folgendes im ASCS-Profil fest:

   enque/encni/set_so_keepalive = true

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

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

   ENSA1

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

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

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

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

   ENSA2

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

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

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

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

Fügen Sie den Nutzer sidadm der Nutzergruppe haclient hinzu.

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

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

   # usermod -aG haclient SID_LCadm

Clusterressourcen für ASCS und ERS konfigurieren

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

   # crm configure property maintenance-mode="true"

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

   # crm status

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

                 *** Resource management is DISABLED ***
   The cluster will not attempt to start, stop or recover services

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

   ENSA1

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

      # crm configure primitive ASCS_INSTANCE_RESOURCE SAPInstance \
        operations \$id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
           START_PROFILE="/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME" \
           AUTOMATIC_RECOVER=false \
        meta resource-stickiness=5000 failure-timeout=60 \
           migration-threshold=1 priority=10

   2. Erstellen Sie die Clusterressource für die ERS-Instanz. Der Wert von InstanceName ist der Name des Instanzprofils, das SWPM bei der Installation von ERS generiert hat. Der Parameter IS_ERS=true weist Pacemaker an, das Flag runsersSID auf dem Knoten, auf dem ERS aktiv ist, auf 1 festzulegen.

      # crm configure primitive ERS_INSTANCE_RESOURCE SAPInstance \
        operations \$id=ERS_INSTANCE_RSC_OPERATIONS_NAME \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME  \
           START_PROFILE="/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME" \
           AUTOMATIC_RECOVER=false IS_ERS=true \
        meta priority=1000

   3. Bestätigen Sie die neu erstellte Konfiguration:

      # crm configure show ASCS_INSTANCE_RESOURCE ERS_INSTANCE_RESOURCE

      Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

      primitive ASCS_INSTANCE_RESOURCE SAPInstance \
      operations $id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \
      op monitor interval=11 timeout=60 on-fail=restart \
      params InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME START_PROFILE="/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME" AUTOMATIC_RECOVER=false \
      meta resource-stickiness=5000 failure-timeout=60 migration-threshold=1 priority=10
      
      
      primitive ERS_INSTANCE_RESOURCE SAPInstance \
      operations $id=ERS_INSTANCE_RSC_OPERATIONS_NAME \
      op monitor interval=11 timeout=60 on-fail=restart \
      params InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME START_PROFILE="/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME" AUTOMATIC_RECOVER=false IS_ERS=true \
      meta priority=1000
      

   ENSA2

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

      # crm configure primitive ASCS_INSTANCE_RESOURCE SAPInstance \
        operations \$id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
           START_PROFILE="/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME" \
           AUTOMATIC_RECOVER=false \
        meta resource-stickiness=5000 failure-timeout=60

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

      # crm configure primitive ERS_INSTANCE_RESOURCE SAPInstance \
        operations \$id=ERS_INSTANCE_RSC_OPERATIONS_NAME \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME  \
           START_PROFILE="/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME" \
           AUTOMATIC_RECOVER=false IS_ERS=true

   3. Bestätigen Sie die neu erstellte Konfiguration:

      # crm configure show ASCS_INSTANCE_RESOURCE ERS_INSTANCE_RESOURCE

      Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

      primitive ASCS_INSTANCE_RESOURCE SAPInstance \
      operations $id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \
      op monitor interval=11 timeout=60 on-fail=restart \
      params InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME START_PROFILE="/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME" AUTOMATIC_RECOVER=false \
      meta resource-stickiness=5000 failure-timeout=60
      
      
      primitive ERS_INSTANCE_RESOURCE SAPInstance \
      operations $id=ERS_INSTANCE_RSC_OPERATIONS_NAME \
      op monitor interval=11 timeout=60 on-fail=restart \
      params InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME START_PROFILE="/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME" AUTOMATIC_RECOVER=false IS_ERS=true \
      

Ressourcengruppen und Standorteinschränkungen konfigurieren

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

   # crm configure group ASCS_RESOURCE_GROUP ASCS_FILE_SYSTEM_RESOURCE \
     ASCS_HEALTH_CHECK_RESOURCE ASCS_VIP_RESOURCE \
     ASCS_INSTANCE_RESOURCE \
     meta resource-stickiness=3000

   Dabei gilt:

   • ASCS_RESOURCE_GROUP: Geben Sie einen eindeutigen Gruppennamen für die ASCS-Clusterressourcen an. Mit der Namenskonvention "SID_ASCSinstance number_group" können Sie die Eindeutigkeit gewährleisten. Beispiel: nw1_ASCS00_group.
   • ASCS_FILE_SYSTEM_RESOURCE: Geben Sie den Namen der Clusterressource an, die Sie zuvor für das ASCS-Dateisystem definiert haben.
   • ASCS_HEALTH_CHECK_RESOURCE: Geben Sie den Namen der Clusterressource an, den Sie zuvor für die ASCS-Systemdiagnose definiert haben.
   • ASCS_VIP_RESOURCE: Geben Sie den Namen der Clusterressource an, die Sie zuvor für die ASCS-VIP definiert haben.
   • ASCS_INSTANCE_RESOURCE: Geben Sie den Namen der Clusterressource an, die Sie zuvor für die ASCS-Instanz definiert haben.

   # crm configure group ERS_RESOURCE_GROUP ERS_FILE_SYSTEM_RESOURCE \
     ERS_HEALTH_CHECK_RESOURCE ERS_VIP_RESOURCE \
     ERS_INSTANCE_RESOURCE

   Dabei gilt:

   • ERS_RESOURCE_GROUP: Geben Sie einen eindeutigen Gruppennamen für die ERS-Clusterressourcen an. Mit einer Konvention wie "SID_ERSinstance number_group" können Sie die Eindeutigkeit gewährleisten. Beispiel: nw1_ERS10_group.
   • ERS_FILE_SYSTEM_RESOURCE: Geben Sie den Namen der Clusterressource an, die Sie zuvor für das ERS-Dateisystem definiert haben.
   • ERS_HEALTH_CHECK_RESOURCE: Geben Sie den Namen der Clusterressource an, die Sie zuvor für die ERS-Systemdiagnose definiert haben.
   • ERS_VIP_RESOURCE: Geben Sie den Namen der Clusterressource an, die Sie zuvor für die ERS-VIP definiert haben.
   • ERS_INSTANCE_RESOURCE: Geben Sie den Namen der Clusterressource an, die Sie zuvor für die ERS-Instanz definiert haben.

2. Bestätigen Sie die neu erstellte Konfiguration:

   # crm configure show type:group

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

   group ERS_RESOURCE_GROUP ERS_FILE_SYSTEM_RESOURCE ERS_HEALTH_CHECK_RESOURCE ERS_VIP_RESOURCE ERS_INSTANCE_RESOURCE
   group ASCS_RESOURCE_GROUP ASCS_FILE_SYSTEM_RESOURCE ASCS_HEALTH_CHECK_RESOURCE ASCS_VIP_RESOURCE ASCS_INSTANCE_RESOURCE \
           meta resource-stickiness=3000

3. Erstellen Sie die Colocation-Einschränkungen:

   ENSA1

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

      # crm configure colocation PREVENT_SCS_ERS_COLOC -5000: ERS_RESOURCE_GROUP ASCS_RESOURCE_GROUP

   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:

      # crm configure location LOC_SCS_SID_FAILOVER_TO_ERS ASCS_INSTANCE_RESOURCE \
      rule 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:

      # crm configure order ORD_SAP_SID_FIRST_START_ASCS \
       Optional: ASCS_INSTANCE_RESOURCE:start \
       ERS_INSTANCE_RESOURCE:stop symmetrical=false

   4. Bestätigen Sie die neu erstellte Konfiguration:

      # crm configure show type:colocation type:location type:order

      Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

      order ORD_SAP_SID_FIRST_START_ASCS Optional: ASCS_INSTANCE_RESOURCE:start ERS_INSTANCE_RESOURCE:stop symmetrical=false
      colocation PREVENT_SCS_ERS_COLOC -5000: ERS_RESOURCE_GROUP ASCS_RESOURCE_GROUP
      location LOC_SCS_SID_FAILOVER_TO_ERS ASCS_INSTANCE_RESOURCE \
      rule 2000: runs_ers_SID eq 1

   ENSA2

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

      # crm configure colocation PREVENT_SCS_ERS_COLOC -5000: ERS_RESOURCE_GROUP ASCS_RESOURCE_GROUP

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

      # crm configure order ORD_SAP_SID_FIRST_START_ASCS \
       Optional: ASCS_INSTANCE_RESOURCE:start \
       ERS_INSTANCE_RESOURCE:stop symmetrical=false

   3. Bestätigen Sie die neu erstellte Konfiguration:

      # crm configure show type:colocation type:order

      Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

      colocation PREVENT_SCS_ERS_COLOC -5000: ERS_RESOURCE_GROUP ASCS_RESOURCE_GROUP
      order ORD_SAP_SID_FIRST_START_ASCS  Optional: ASCS_INSTANCE_RESOURCE:start ERS_INSTANCE_RESOURCE:stop symmetrical=false

4. Deaktivieren Sie den Wartungsmodus.

   # crm configure property maintenance-mode="false"

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:

   # crm status

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

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

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:

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

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

   > sapcontrol -nr INSTANCE_NUMBER -function HACheckConfig

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

   20.05.2021 01:37:19
   HACheckConfig
   OK
   state, category, description, comment
   SUCCESS, SAP CONFIGURATION, Redundant ABAP instance configuration, 0 ABAP instances detected
   SUCCESS, SAP CONFIGURATION, Redundant Java instance configuration, 0 Java instances detected
   SUCCESS, SAP CONFIGURATION, Enqueue separation, All Enqueue server separated from application server
   SUCCESS, SAP CONFIGURATION, MessageServer separation, All MessageServer separated from application server
   SUCCESS, SAP STATE, SCS instance running, SCS instance status ok
   SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version (vh-ascs-aha_AHA_00), SAPInstance includes is-ers patch
   SUCCESS, SAP CONFIGURATION, Enqueue replication (vh-ascs-aha_AHA_00), Enqueue replication enabled
   SUCCESS, SAP STATE, Enqueue replication state (vh-ascs-aha_AHA_00), Enqueue replication active

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

   Cluster Summary:
   * Stack: corosync
   * Current DC: nw-ha-vm-2 (version 2.0.4+20200616.2deceaa3a-3.3.1-2.0.4+20200616.2deceaa3a) - partition with quorum
   * Last updated: Fri May 21 22:31:32 2021
   * Last change:  Thu May 20 20:36:36 2021 by ahaadm via crm_resource on nw-ha-vm-1
   * 2 nodes configured
   * 10 resource instances configured
   
   Node List:
   * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
   
   Full List of Resources:
   * fencing-rsc-nw-aha-vm-1     (stonith:fence_gce):     Started nw-ha-vm-2
   * fencing-rsc-nw-aha-vm-2     (stonith:fence_gce):     Started nw-ha-vm-1
   * Resource Group: scs-aha-rsc-group-name:
     * filesystem-rsc-nw-aha-scs (ocf::heartbeat:Filesystem):     Started nw-ha-vm-2
     * health-check-rsc-nw-ha-scs        (ocf::heartbeat:anything):       Started nw-ha-vm-2
     * vip-rsc-nw-aha-scs        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-2
     * scs-aha-instance-rsc-name (ocf::heartbeat:SAPInstance):    Started nw-ha-vm-2
   * Resource Group: ers-aha-rsc-group-name:
     * filesystem-rsc-nw-aha-ers (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
     * health-check-rsc-nw-ha-ers        (ocf::heartbeat:anything):       Started nw-ha-vm-1
     * vip-rsc-nw-aha-ers        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-1
     * ers-aha-instance-rsc-name (ocf::heartbeat:SAPInstance):    Started nw-ha-vm-1

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:

   # crm 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 SLES-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:

• SUSE-Best Practices

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