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

In dieser Anleitung wird beschrieben, wie Sie die Bereitstellung eines leistungsoptimierten SLES-Hochverfügbarkeitsclusters (SUSE Linux Enterprise Server) für SAP NetWeaver automatisieren.

In diesem Leitfaden wird Terraform verwendet, um zwei virtuelle Compute Engine-Maschinen (VMs), eine virtuelle IP-Adresse (VIP) mit interner Passthrough-Network-Load-Balancer-Implementierung und einen betriebssystembasierten Hochverfügbarkeits-Cluster bereitzustellen – alles gemäß den Best Practices von Google Cloud, SAP und dem Betriebssystemanbieter.

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.

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

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

  • Zwei Host-VMs, eine 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

Vorbereitung

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

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

Netzwerk erstellen

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

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

Während der Bereitstellung müssen VM-Instanzen normalerweise auf das Internet zugreifen können, um den 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.

Führen Sie die folgenden Schritte aus, um ein VPC-Netzwerk für Ihr Projekt zu erstellen:

  1. Erstellen Sie ein Netzwerk im benutzerdefinierten Modus. Weitere Informationen finden Sie unter Netzwerk im benutzerdefinierten Modus erstellen.

  2. Erstellen Sie ein Subnetzwerk und geben Sie die Region und den IP-Adressbereich an. Weitere Informationen finden Sie unter Subnetze hinzufügen.

NAT-Gateway einrichten

Wenn Sie eine oder mehrere VMs ohne öffentliche IP-Adressen erstellen müssen, müssen Sie die Network Address Translation (NAT) verwenden, damit die VMs auf das Internet zugreifen können. Verwenden Sie Cloud NAT, einen verteilten, softwarebasierten verwalteten Dienst von Google Cloud, der es VMs ermöglicht, ausgehende Pakete an das Internet zu senden und entsprechende eingehende Antwortpakete zu empfangen. Alternativ können Sie eine separate VM als NAT-Gateway einrichten.

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

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

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

Informationen zum Erstellen der Firewallregeln für Ihr Projekt finden Sie unter Firewallregeln erstellen.

Linux-Hochverfügbarkeitscluster für SAP NetWeaver erstellen

In der folgenden Anleitung wird mit der Terraform-Konfiguration ein SLES-Cluster mit zwei SAP NetWeaver-Systemen erstellt: ein primäres SAP NetWeaver-System mit einem Host auf einer VM-Instanz und ein SAP NetWeaver-Standby-System auf einer anderen VM-Instanz in derselben Compute Engine-Region.

Die Konfigurationsoptionen für den SAP NetWeaver-Hochverfügbarkeitscluster definieren Sie in einer Terraform-Konfigurationsdatei.

  1. Öffnen Sie Cloud Shell.

    Zu Cloud Shell

  2. Laden Sie die Konfigurationsdatei sap_nw_ha.tf für das SAP NetWeaver-Hochverfügbarkeitscluster in Ihr Arbeitsverzeichnis herunter:

    $ wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_nw_ha/terraform/sap_nw_ha.tf

  3. Öffnen Sie die Datei sap_nw_ha.tf im Cloud Shell-Code-Editor.

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

  4. Aktualisieren Sie in der Datei sap_nw_ha.tf die folgenden Argumentwerte. Ersetzen Sie dazu den Inhalt innerhalb der doppelten Anführungszeichen durch die Werte für Ihre Installation. Die Argumente werden in der folgenden Tabelle beschrieben.

    Argument Datentyp Beschreibung
    source String

    Gibt den Speicherort und die Version des Terraform-Moduls an, das während der Bereitstellung verwendet werden soll.

    Die Konfigurationsdatei sap_nw_ha.tf enthält zwei Instanzen des Arguments source: eine aktive und eine als Kommentar. Das standardmäßig aktive Argument source gibt latest als Modulversion an. Die zweite Instanz des Arguments source, die standardmäßig durch ein führendes #-Zeichen deaktiviert ist, gibt einen Zeitstempel an, der eine Modulversion identifiziert.

    Wenn alle Ihre Bereitstellungen dieselbe Modulversion verwenden müssen, entfernen Sie das führende #-Zeichen aus dem Argument source, das den Zeitstempel der Version angibt, und fügen Sie es dem Argument source hinzu, das latest angibt.

    project_id String Geben Sie die ID Ihres Google Cloud-Projekts an, in dem Sie dieses System bereitstellen. Beispiel: my-project-x.
    machine_type String Geben Sie den Typ der virtuellen Maschine (VM) von Compute Engine an, auf der Sie Ihr SAP-System ausführen müssen. Wenn Sie einen benutzerdefinierten VM-Typ benötigen, geben Sie einen vordefinierten VM-Typ mit einer Anzahl an vCPUs an, die der benötigten Anzahl am nächsten kommt, aber noch darüber liegt. Wenn die Bereitstellung abgeschlossen ist, ändern Sie die Anzahl der vCPUs und den Umfang des Arbeitsspeichers.

    Beispiel: n1-highmem-32.
    network String Geben Sie den Namen des Netzwerks an, in dem Sie den Load-Balancer, der die VIP verwaltet, erstellen möchten.

    Wenn Sie ein freigegebenes VPC-Netzwerk verwenden, müssen Sie die ID des Hostprojekts als übergeordnetes Verzeichnis des Netzwerknamens hinzufügen. Beispiel: HOST_PROJECT_ID/NETWORK_NAME.

    subnetwork String Geben Sie den Namen des Subnetzwerks an, das Sie in einem vorherigen Schritt erstellt haben. Wenn die Bereitstellung in einer freigegebenen VPC erfolgt, geben Sie diesen Wert als SHARED_VPC_PROJECT_ID/SUBNETWORK an. Beispiel: myproject/network1.
    linux_image String Geben Sie den Namen des Linux-Betriebssystem-Images an, auf dem Sie Ihr SAP-System bereitstellen möchten. Beispiel: sles-15-sp5-sap. Eine Liste der verfügbaren Betriebssystem-Images finden Sie auf der Seite Images in der Google Cloud Console.
    linux_image_project String Geben Sie das Google Cloud-Projekt an, in dem das Image enthalten ist, das Sie für das Argument linux_image angegeben haben. Dieses Projekt kann Ihr eigenes Projekt oder ein Google Cloud-Image-Projekt sein. Geben Sie für ein Compute Engine-Image suse-sap-cloud an. Weitere Informationen zum Image-Projekt für Ihr Betriebssystem finden Sie unter Details zu Betriebssystemen.
    sap_primary_instance String Geben Sie einen Namen für die VM-Instanz für das primäre SAP NetWeaver-System an. Dies ist der anfängliche ASCS-Speicherort. Der Name darf Kleinbuchstaben, Ziffern und Bindestriche enthalten und darf nicht länger als 13 Zeichen sein.
    sap_primary_zone String Geben Sie eine Zone an, in der das primäre SAP NetWeaver-System bereitgestellt wird. Die primäre und die sekundäre Zone müssen sich in derselben Region befinden. z. B. us-east1-b
    sap_secondary_instance String Geben Sie einen Namen für die VM-Instanz für das sekundäre SAP NetWeaver-System an. Dies ist Ihr anfänglicher ERS-Speicherort. Der Name darf Kleinbuchstaben, Ziffern und Bindestriche enthalten und darf nicht länger als 13 Zeichen sein.
    sap_secondary_zone String Geben Sie eine Zone an, in der das sekundäre SAP NetWeaver-System bereitgestellt wird. Die primäre und die sekundäre Zone müssen sich in derselben Region befinden. z. B. us-east1-c
    nfs_path String Geben Sie den NFS-Bereitstellungspunkt für das freigegebene Dateisystem an. Beispiel: 10.163.58.114:/ssd_nfs.
    sap_sid String Geben Sie eine SAP-System-ID an. Die ID muss aus drei alphanumerischen Zeichen bestehen und mit einem Buchstaben beginnen. Alle Buchstaben müssen Großbuchstaben sein. Beispiel: ED1.
    hc_firewall_rule_name String Optional. Geben Sie einen Namen für die Firewallregel für die Systemdiagnose ein. Der Standardwert ist SAP_SID-hc-allow.
    hc_network_tag String Optional. Geben Sie ein oder mehrere kommagetrennte Netzwerk-Tags an, die Sie mit Ihren VM-Instanzen für die Firewallregel zur Systemdiagnose verknüpfen möchten. Der Standardwert ist SAP_SID-hc-allow-tag.
    scs_inst_group_name String Optional. Geben Sie einen Namen für die ASCS-Instanzgruppe an. Der Standardwert ist SAP_SID-scs-ig.
    scs_hc_name String Optional. Geben Sie einen Namen für die ASCS-Systemdiagnose an. Der Standardwert ist SAP_SID-scs-hc.
    scs_hc_port String Optional. Geben Sie einen Port für die ASCS-Systemdiagnose an. Geben Sie die Portnummer für die ASCS-Systemdiagnose im privaten Bereich 49152–65535 an, um Konflikte mit anderen Diensten zu vermeiden. Der Standardwert ist 60000.
    scs_vip_address String Optional. Geben Sie eine nicht verwendete IP-Adresse in dem Subnetzwerk an, das zuvor für subnetwork angegeben wurde, um sie als virtuelle IP-Adresse für die ASCS-Instanz zu verwenden. Wenn nichts angegeben ist, wählen die Bereitstellungsskripts automatisch eine nicht verwendete IP-Adresse aus dem angegebenen Subnetzwerk aus.
    scs_vip_name String Optional. Geben Sie einen Namen für die virtuelle ASCS-IP-Adresse an. Der Standardwert ist SAP_SID-scs-vip.
    scs_backend_svc_name String Optional. Geben Sie einen Namen für den ASCS-Backend-Dienst an. Der Standardwert ist SAP_SID-scs-backend-svc.
    scs_forw_rule_name String Optional. Geben Sie einen Namen für die ASCS-Weiterleitungsregel an. Der Standardwert ist SAP_SID-scs-fwd-rule.
    ers_inst_group_name String Optional. Geben Sie einen Namen für die ERS-Instanzgruppe an. Der Standardwert ist SAP_SID-ers-ig.
    ers_hc_name String Optional. Geben Sie einen Namen für die ERS-Systemdiagnose an. Der Standardwert ist SAP_SID-ers-hc.
    ers_hc_port String Optional. Geben Sie einen Port für die ERS-Systemdiagnose an. Geben Sie die Portnummer für die ERS-Systemdiagnose im privaten Bereich 49152–65535 an, um Konflikte mit anderen Diensten zu vermeiden. Der Standardwert ist 60010.
    ers_vip_address String Optional. Geben Sie eine nicht verwendete IP-Adresse im Subnetzwerk an, das zuvor für subnetwork angegeben wurde, um sie als virtuelle IP-Adresse für die ERS-Instanz zu verwenden. Wenn nichts angegeben ist, wählen die Bereitstellungsskripts automatisch eine nicht verwendete IP-Adresse aus dem angegebenen Subnetzwerk aus.
    ers_vip_name String Optional. Geben Sie einen Namen für die virtuelle ERS-IP-Adresse an. Der Standardwert ist SAP_SID-ers-vip.
    ers_backend_svc_name String Optional. Geben Sie einen Namen für den ERS-Backend-Dienst an. Der Standardwert ist SAP_SID-ers-backend-svc.
    ers_forw_rule_name String Optional. Geben Sie einen Namen für die ERS-Weiterleitungsregel an. Der Standardwert ist SAP_SID-ers-fwd-rule.
    usr_sap_size Integer Optional. Geben Sie die Größe des Laufwerks /usr/sap in GB an. Die Mindestgröße beträgt 8 GB. Der Standardwert ist 8.
    sap_mnt_size Integer Optional. Geben Sie die Größe des Laufwerks /sapmnt in GB an. Die Mindestgröße beträgt 8 GB. Der Standardwert ist 8.
    swap_size Integer Optional. Geben Sie die Größe des Auslagerungs-Volumes in GB an. Die Mindestgröße beträgt 8 GB. Der Standardwert ist 8.
    sap_scs_instance_number String Optional. Geben Sie die ASCS-Instanznummer an. Die sap_scs_instance_number muss eine zweistellige Zahl sein. Wenn Sie eine einstellige Zahl angeben müssen, fügen Sie vor der Zahl eine 0 ein. Beispiel: 07 Der Standardwert ist 00.
    sap_ers_instance_number String Optional. Geben Sie die ERS-Instanznummer an. Die sap_ers_instance_number muss eine zweistellige Zahl sein. Wenn Sie eine einstellige Zahl angeben müssen, fügen Sie vor der Zahl eine 0 ein. Beispiel: 07 Der Standardwert ist 10.
    sap_nw_abap Boolesch Optional. Geben Sie an, ob Sie einen ABAP-Stack oder einen Java-Stack von SAP NetWeaver bereitstellen. Geben Sie für einen Java-Stack von SAP NetWeaver false an. Der Standardwert ist true.
    pacemaker_cluster_name String Optional. Geben Sie einen Namen für den Pacemaker-Cluster an. Der Standardwert ist SAP_SID-cluster.
    public_ip Boolesch Optional. Setzen Sie public_ip auf true, um eine sitzungsspezifische öffentliche IP-Adresse für die VM-Instanzen zu erstellen. Der Standardwert ist false.
    service_account String Optional. Geben Sie die E-Mail-Adresse eines nutzerverwalteten Dienstkontos an, das von den Host-VMs und den darauf ausgeführten Programmen verwendet werden soll. Beispiel: svc-acct-name@project-id.iam.gserviceaccount.com.

    Wenn Sie dieses Argument ohne Wert angeben oder weglassen, verwendet das Installationsskript das Compute Engine-Standarddienstkonto. Weitere Informationen finden Sie unter Identitäts- und Zugriffsverwaltung für SAP-Programme in Google Cloud.

    network_tags String Optional. Geben Sie ein oder mehrere kommagetrennte Netzwerk-Tags an, die Sie zu Firewall- oder Routingzwecken mit Ihren VM-Instanzen verknüpfen möchten.

    Ein Netzwerk-Tag für die ILB-Komponenten wird den Netzwerk-Tags der VM automatisch hinzugefügt.

    Wenn public_ip = false und Sie kein Netzwerk-Tag angeben, müssen Sie eine andere Möglichkeit für den Zugriff auf das Internet bereitstellen.

    sap_deployment_debug Boolesch Optional. Geben Sie true nur dann an, wenn Sie von Cloud Customer Care aufgefordert werden, das Debugging für Ihre Bereitstellung zu aktivieren, da hierdurch ausführliche Bereitstellungslogs generiert werden. Der Standardwert ist false.
    primary_reservation_name String Optional. Wenn Sie eine bestimmte Compute Engine-VM-Reservierung zur Bereitstellung der VM-Instanz verwenden möchten, auf der die primäre SAP HANA-Instanz Ihres HA-Clusters gehostet wird, geben Sie den Namen der Reservierung an. Standardmäßig wählt das Installationsskript basierend auf den folgenden Bedingungen jede verfügbare Compute Engine-Reservierung aus.

    Damit eine Reservierung unabhängig davon verwendet werden kann, ob Sie einen Namen angeben oder dieser vom Installationsskript automatisch ausgewählt wird, muss die Reservierung so festgelegt werden:

    • Die Option specificReservationRequired ist auf true oder in der Google Cloud Console auf Bestimmte Reservierung auswählen festgelegt.
    • Einige Compute Engine-Maschinentypen unterstützen CPU-Plattformen, die nicht von der SAP-Zertifizierung des Maschinentyps abgedeckt sind. Wenn die Zielreservierung für einen der folgenden Maschinentypen gilt, muss die Reservierung die Mindest-CPU-Plattformen angeben:
      • n1-highmem-32: Intel Broadwell
      • n1-highmem-64: Intel Broadwell
      • n1-highmem-96: Intel Skylake
      • m1-megamem-96: Intel Skylake
      • Die Mindest-CPU-Plattformen für alle anderen Maschinentypen, die von SAP für die Verwendung in Google Cloud zertifiziert sind, entsprechen der Mindest-CPU-Anforderung von SAP.
    secondary_reservation_name String Optional. Wenn Sie eine bestimmte Compute Engine-VM-Reservierung zur Bereitstellung der VM-Instanz verwenden möchten, auf der die sekundäre SAP HANA-Instanz Ihres HA-Clusters gehostet wird, geben Sie den Namen der Reservierung an. Standardmäßig wählt das Installationsskript basierend auf den folgenden Bedingungen jede verfügbare Compute Engine-Reservierung aus.

    Damit eine Reservierung unabhängig davon verwendet werden kann, ob Sie einen Namen angeben oder dieser vom Installationsskript automatisch ausgewählt wird, muss die Reservierung so festgelegt werden:

    • Die Option specificReservationRequired ist auf true oder in der Google Cloud Console auf Bestimmte Reservierung auswählen festgelegt.
    • Einige Compute Engine-Maschinentypen unterstützen CPU-Plattformen, die nicht von der SAP-Zertifizierung des Maschinentyps abgedeckt sind. Wenn die Zielreservierung für einen der folgenden Maschinentypen gilt, muss die Reservierung die Mindest-CPU-Plattformen angeben:
      • n1-highmem-32: Intel Broadwell
      • n1-highmem-64: Intel Broadwell
      • n1-highmem-96: Intel Skylake
      • m1-megamem-96: Intel Skylake
      • Die Mindest-CPU-Plattformen für alle anderen Maschinentypen, die von SAP für die Verwendung in Google Cloud zertifiziert sind, entsprechen der Mindest-CPU-Anforderung von SAP.

    Das folgende Beispiel zeigt eine fertige Konfigurationsdatei, die einen Hochverfügbarkeitscluster für SAP NetWeaver definiert. Der Cluster verwendet einen internen Passthrough-Netzwerk-Load-Balancer, um die VIP zu verwalten.

    Terraform stellt die Google Cloud-Ressourcen bereit, die in der Konfigurationsdatei definiert sind. Anschließend übernehmen Skripts die Konfiguration des Betriebssystems und Konfiguration des Linux-HA-Clusters.

    Zur Verdeutlichung werden Kommentare in der Konfigurationsdatei im Beispiel weggelassen.

       # ...
     module "sap_nw_ha" {
     source = "https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_nw_ha/sap_nw_ha_module.zip"
   #
   # By default, this source file uses the latest release of the terraform module
   # for SAP on Google Cloud.  To fix your deployments to a specific release
   # of the module, comment out the source argument above and uncomment the source argument below.
   #
   # source = "https://storage.googleapis.com/cloudsapdeploy/terraform/202201240926/terraform/sap_nw_ha/sap_nw_ha_module.zip"
   #
   # ...
   #
   project_id = "example-project-123456"
   machine_type = "n2-highmem-32"
   network = "example-network"
   subnetwork = "example-subnet-us-central1"
   linux_image = "sles-15-sp3-sap"
   linux_image_project = "suse-sap-cloud"

   sap_primary_instance = "example-nw1"
   sap_primary_zone = "us-central1-a"

   sap_secondary_instance = "example-nw2"
   sap_secondary_zone = "us-central1-c"

   nfs_path = "10.223.55.130:/pr1_nw"

   sap_sid = "PR1"
   # ...
}

  5. Initialisieren Sie Ihr aktuelles Arbeitsverzeichnis und laden Sie das Plug-in und die Moduldateien des Terraform-Anbieters für Google Cloud herunter:

    terraform init

    Mit dem Befehl terraform init wird Ihr Arbeitsverzeichnis für andere Terraform-Befehle vorbereitet.

    Wenn Sie eine Aktualisierung der Plug-in- und Konfigurationsdateien des Anbieters in Ihrem Arbeitsverzeichnis erzwingen möchten, geben Sie das Flag --upgrade an. Wenn das Flag --upgrade weggelassen wird und Sie keine Änderungen in Ihrem Arbeitsverzeichnis vornehmen, verwendet Terraform die lokal im Cache gespeicherten Kopien, auch wenn in der source-URL der Wert latest angegeben ist.

    terraform init --upgrade

  6. Optional können Sie den Terraform-Ausführungsplan erstellen:

    terraform plan

    Der Befehl terraform plan zeigt die Änderungen an, die für Ihre aktuelle Konfiguration erforderlich sind. Wenn Sie diesen Schritt überspringen, wird mit dem Befehl terraform apply automatisch ein neuer Plan erstellt und Sie werden aufgefordert, diesen zu genehmigen.

  7. Wenden Sie den Ausführungsplan an:

    terraform apply

    Wenn Sie aufgefordert werden, die Aktionen zu genehmigen, geben Sie yes ein.

    Mit dem Befehl terraform apply wird die Google Cloud-Infrastruktur eingerichtet und dann die Kontrolle an ein Script übergeben, das den Hochverfügbarkeits-Cluster gemäß den in der Terraform-Konfigurationsdatei definierten Argumenten konfiguriert.

    Solange Terraform die Kontrolle hat, werden Statusmeldungen in Cloud Shell geschrieben. Nach dem Aufrufen des Skripts werden Statusmeldungen in Logging geschrieben und können in der Google Cloud Console angezeigt werden, wie unter Logging-Logs überprüfen beschrieben.

    Die Abschlusszeit kann variieren, aber der gesamte Vorgang dauert in der Regel weniger als 30 Minuten.

Bereitstellung des SAP NetWeaver-Hochverfügbarkeits-Systems prüfen

Das Prüfen eines SAP NetWeaver-HA-Clusters umfasst mehrere Schritte:

  • Log prüfen
  • Konfiguration der VM prüfen

Log prüfen

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

    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. Cloud Shell öffnen

        Zu Cloud Shell

      3. Wechseln Sie zu Ihrem Arbeitsverzeichnis und löschen Sie das Deployment, um die VMs und nichtflüchtigen Speicher aus der fehlgeschlagenen Installation zu entfernen:

        terraform destroy

        Wenn Sie aufgefordert werden, die Aktion zu genehmigen, geben Sie yes ein.

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

Konfiguration der VM prüfen

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

  2. Wechseln Sie zum Root-Nutzer.

    sudo su -

  3. Geben Sie bei der Eingabeaufforderung df -h ein. Prüfen Sie, ob die Ausgabe /usr/sap-Verzeichnisse wie etwa /usr/sap/trans enthält.

    example-nw1:~ # df -h
  Filesystem                             Size  Used Avail Use% Mounted on
  ...
  /dev/mapper/vg_usrsap-vol              8.0G   41M  8.0G   1% /usr/sap
  /dev/mapper/vg_sapmnt-vol              8.0G   41M  8.0G   1% /sapmnt
  10.233.55.130:/pr1_nw/sapmntPR1       1007G     0  956G   0% /sapmnt/PR1
  10.223.55.130:/pr1_nw/usrsaptrans     1007G     0  956G   0% /usr/sap/trans
  10.223.55.130:/pr1_nw/usrsapPR1ASCS00 1007G     0  956G   0% /usr/sap/PR1/ASCS00
  ...
    autofs wird während der Bereitstellung automatisch so konfiguriert, 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 ebenfalls während der Bereitstellung eingerichtet wird.

  4. Prüfen Sie den Status des neuen Clusters durch Eingabe des Statusbefehls: crm status.

    Die Ausgabe sollte in etwa wie das folgende Beispiel aussehen. Darin werden beide VM-Instanzen gestartet und example-nw1 ist die aktive primäre Instanz: 

    example-nw1:~ # crm status
Cluster Summary:
  * Stack: corosync
  * Current DC: example-nw1 (version 2.0.4+20200616.2deceaa3a-3.6.1-2.0.4+20200616.2deceaa3a) - partition with quorum
  * Last updated: Fri Jun 18 05:47:48 2021
  * Last change:  Fri Jun 18 05:41:32 2021 by root via cibadmin on example-nw1
  * 2 nodes configured
  * 8 resource instances configured
Node List:
  * Online: [ example-nw1 example-nw2 ]
Full List of Resources:
  * fence-PR1-example-nw1     (stonith:fence_gce):           Started example-nw2
  * fence-PR1-example-nw2     (stonith:fence_gce):           Started example-nw1
  * file-system-PR1-ASCS00    (ocf::heartbeat:Filesystem):      Started example-nw1
  * file-system-PR1-ERS10     (ocf::heartbeat:Filesystem):      Started example-nw2
  * health-check-PR1-ASCS00   (ocf::heartbeat:anything):        Started example-nw1
  * health-check-PR1-ERS10    (ocf::heartbeat:anything):        Started example-nw2
  * vip-PR1-ASCS00      (ocf::heartbeat:IPaddr2):             Started example-nw1
  * vip-PR1-ERS10       (ocf::heartbeat:IPaddr2):             Started example-nw2

  5. Testen Sie die Einrichtung des ASCS- und des ERS-Load-Balancers mit dem Dienstprogramm socat:

    1. Starten Sie auf jeder VM-Instanz vorübergehend einen socat-Prozess, der seinen eigenen Hostnamen zurückgibt:

      socat TCP-LISTEN:80,bind=0.0.0.0,fork,reuseaddr,crlf SYSTEM:"echo HTTP/1.0 200; echo Content-Type\: text/plain; echo; echo $(hostname)" &

    2. Verwenden Sie auf jedem Knoten curl und versuchen Sie, die folgenden IP-Adressen und Hostnamen zu erreichen. Die IP-Adressen und Hostnamen finden Sie in /etc/hosts.

      • 127.0.0.1
      • localhost
      • ASCS_VIRTUAL_HOST_NAME
      • ASCS_IP_ADDRESS
      • ERS_VIRTUAL_HOST_NAME
      • ERS_IP_ADDRESS
      • SCS-VIP-Name, der für den Parameter scs_vip_name angegeben wird
      • SCS-VIP-Adresse, die für den Parameter scs_vip_address angegeben wird
      • ERS-VIP-Name, der für den Parameter ers_vip_name angegeben wird
      • ERS-VIP-Adresse, die für den Parameter ers_vip_address angegeben wird

    Hier sehen Sie eine Beispielausgabe eines solchen Tests:

    example-nw1:~ # cat /etc/hosts
...
10.128.1.182 example-nw1.c.myproject.internal example-nw1
10.128.1.169 example-nw2.c.myproject.internal example-nw2
10.128.1.46 pr1-scs-vip.c.myproject.internal pr1-scs-vip
10.128.0.75 pr1-ers-vip.c.myproject.internal pr1-ers-vip
example-nw1:~ # curl 127.0.0.1
example-nw1
example-nw1:~ # curl localhost
example-nw1
example-nw1:~ # curl example-nw1
example-nw1
example-nw1:~ # curl 10.128.1.182
example-nw1
example-nw1:~ # curl example-nw2
example-nw2
example-nw1:~ # curl 10.128.1.169
example-nw2
example-nw1:~ # curl pr1-scs-vip
example-nw1
example-nw1:~ # curl 10.128.1.46
example-nw1
example-nw1:~ # curl pr1-ers-vip
example-nw2
example-nw1:~ # curl 10.128.0.75
example-nw2

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

  1. Beheben Sie die Fehler.

  2. Cloud Shell öffnen

    Zu Cloud Shell

  3. Wechseln Sie zu dem Verzeichnis, das die Terraform-Konfigurationsdatei enthält.

  4. Löschen Sie das Deployment:

    terraform destroy

    Wenn Sie aufgefordert werden, die Aktion zu genehmigen, geben Sie yes ein.

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

Installation des Google Cloud-Agents für SAP prüfen

Nachdem Sie eine VM bereitgestellt und Ihr SAP-System installiert haben, prüfen Sie, ob der Google Cloud-Agent für SAP ordnungsgemäß funktioniert.

Ausführung des Google Cloud-Agents für SAP prüfen

So prüfen Sie, ob der Agent ausgeführt wird:

  1. Stellen Sie eine SSH-Verbindung zu Ihrer Host-VM-Instanz her.

  2. Führen Sie dazu diesen Befehl aus: 

    systemctl status google-cloud-sap-agent

    Wenn der Agent ordnungsgemäß funktioniert, enthält die Ausgabe active (running). Beispiel: 

    google-cloud-sap-agent.service - Google Cloud Agent for SAP
Loaded: loaded (/usr/lib/systemd/system/google-cloud-sap-agent.service; enabled; vendor preset: disabled)
Active:  active (running)  since Fri 2022-12-02 07:21:42 UTC; 4 days ago
Main PID: 1337673 (google-cloud-sa)
Tasks: 9 (limit: 100427)
Memory: 22.4 M (max: 1.0G limit: 1.0G)
CGroup: /system.slice/google-cloud-sap-agent.service
       └─1337673 /usr/bin/google-cloud-sap-agent

Wenn der Agent nicht ausgeführt wird, starten Sie den Agent neu.

Prüfen, ob der SAP-Host-Agent Messwerte empfängt

Führen Sie die folgenden Schritte aus, um zu prüfen, ob die Infrastrukturmesswerte vom Agent von Google Cloud für SAP erfasst und korrekt an den SAP-Host-Agent gesendet werden:

  1. Geben Sie in Ihrem SAP-System Transaktion ST06 ein.

  2. Kontrollieren Sie im Übersichtsbereich die Verfügbarkeit und den Inhalt der folgenden Felder, um die korrekte End-to-End-Einrichtung der SAP- und Google-Monitoring-Infrastruktur zu überprüfen:

    • Cloud-Anbieter: Google Cloud Platform
    • Zugriff für erweitertes Monitoring: TRUE
    • Details für erweitertes Monitoring: ACTIVE

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-Integration verwenden.

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

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

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

    # 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 Integration systemd 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-Integration für die ASCS- und die ERS-Instanzen:

      # 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-Integration deaktiviert ist:

      # systemctl list-unit-files | grep sap

      Eine Ausgabe wie das folgende Beispiel 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 Nutzer SID_LCadm 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

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

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

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

    ENSA2

    • Erstellen Sie die Clusterressource für die 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_RSC_NAME 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

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

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

Ressourcengruppen und Standorteinschränkungen konfigurieren

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

    # crm configure group ASCS_RSC_GROUP_NAME ASCS_FILE_SYSTEM_RSC_NAME \
  ASCS_HEALTH_CHECK_RSC_NAME ASCS_VIP_RSC_NAME \
  ASCS_INSTANCE_RSC_NAME \
  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_RSC_GROUP_NAME ERS_FILE_SYSTEM_RSC_NAME \
  ERS_HEALTH_CHECK_RSC_NAME ERS_VIP_RSC_NAME \
  ERS_INSTANCE_RSC_NAME

    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. 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_ASCS_ERS_COLOC -5000: ERS_RSC_GROUP_NAME ASCS_RSC_GROUP_NAME

    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_ASCS_SID_FAILOVER_TO_ERS ASCS_INSTANCE_RSC_NAME \
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_RSC_NAME:start \
 ERS_INSTANCE_RSC_NAME:stop symmetrical=false

    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_ASCS_ERS_COLOC -5000: ERS_RSC_GROUP_NAME ASCS_RSC_GROUP_NAME

    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_RSC_NAME:start \
 ERS_INSTANCE_RSC_NAME:stop symmetrical=false

  3. Deaktivieren Sie den Wartungsmodus.

    # crm configure property maintenance-mode="false"

  4. Prüfen Sie die Konfiguration der Gruppen, die Colocation-Einschränkungen und die Reihenfolge:

    # crm config show

    Die Ausgabe sollte Zeilen wie im folgenden Beispiel enthalten:

    ENSA1 

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

    ENSA2 

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

Cluster 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, an die Google Cloud-Komponente BC-OP-LNX-GOOGLE oder BC-OP-NT-GOOGLE weiter.

Supportanforderungen

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

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

Aufgaben nach dem Deployment ausführen

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

Weitere Informationen 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: