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

In dieser Anleitung wird beschrieben, wie Sie die Bereitstellung eines leistungsoptimierten Red Hat Enterprise Linux (RHEL)-Hochverfügbarkeitsclusters (HA) 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 NetWeaver unter SUSE Linux Enterprise Server (SLES) finden Sie im Leitfaden für die manuelle Konfiguration von Hochverfügbarkeitsclustern für SAP NetWeaver unter SLES.

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

System, das in dieser Anleitung bereitgestellt wird

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

Ü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 Red Hat und SAP:

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 eine Terraform-Konfigurationsdatei verwendet, um einen RHEL-Hochverfügbarkeitscluster für SAP NetWeaver mit zwei Compute Engine-VMs zu erstellen. Die Compute Engine-VMs werden in zwei Zielzonen in einer Konfiguration (mit automatischem Failover) für zentrale SAP-Dienste und die Replikation von Warteschlangen erstellt.

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 DEPLOYMENT_TYPE.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: rhel-9-2-sap-ha. 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 rhel-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 Ganzzahl 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 Ganzzahl 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 Ganzzahl 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 die Startskripts die Konfiguration des Betriebssystems und 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 = "rhel-8-4-sap-ha"
   linux_image_project = "rhel-sap-cloud"

   sap_primary_instance = "nw-ha-vm-1"
   sap_primary_zone = "us-central1-a"

   sap_secondary_instance = "nw-ha-vm-2"
   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. 

    nw-ha-vm-1:~ # df -h
Filesystem                             Size  Used Avail Use% Mounted on
...
/dev/mapper/vg_usrsap-vol              8.0G  242M  7.8G   3% /usr/sap
/dev/mapper/vg_sapmnt-vol              8.0G   90M  7.9G   2% /sapmnt
10.95.255.130:/pr1_nw/sapmntPR1       1007G     0  956G   0% /sapmnt/PR1
10.95.255.130:/pr1_nw/usrsaptrans     1007G     0  956G   0% /usr/sap/trans
10.95.255.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: pcs status.

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

    nw-ha-vm-1:~ # pcs status
Cluster name: pr1-cluster
Cluster Summary:
* Stack: corosync
* Current DC: nw-ha-vm-1 (version 2.0.5-9.el8_4.5-ba59be7122) - partition with quorum
* Last updated: Mon Aug 29 18:03:22 2022
* Last change:  Mon Aug 29 17:58:21 2022 by root via cibadmin on nw-ha-vm-1
* 2 nodes configured
* 8 resource instances configured
Node List:
* Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
Full List of Resources:
* fence-PR1-nw-ha-vm-1    (stonith:fence_gce):     Started nw-ha-vm-2
* fence-PR1-nw-ha-vm-2    (stonith:fence_gce):     Started nw-ha-vm-1
* file-system-PR1-ASCS00    (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
* file-system-PR1-ERS10    (ocf::heartbeat:Filesystem):     Started nw-ha-vm-2
* health-check-PR1-ASCS00    (service:haproxy@PR1ASCS):     Started nw-ha-vm-1
* health-check-PR1-ERS10    (service:haproxy@PR1ERS):     Started nw-ha-vm-2
* vip-PR1-ASCS00    (ocf::heartbeat:IPaddr2):     Started nw-ha-vm-1
* vip-PR1-ERS10    (ocf::heartbeat:IPaddr2):     Started nw-ha-vm-2
Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled

  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

  6. Wenn Sie RHEL für SAP 9.0 oder höher verwenden, achten Sie darauf, dass die Pakete chkconfig und compat-openssl11 auf Ihrer VM-Instanz installiert sind.

    Weitere Informationen von SAP finden Sie im SAP-Hinweis 3108316 – Red Hat Enterprise Linux 9.x: Installation und Konfiguration.

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:

    # sudo pcs property set maintenance-mode="false"

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

    # groupadd -g GID_SAPINST sapinst
# groupadd -g GID_SAPSYS sapsys
# useradd -u UID_SIDADM SID_LCadm -g sapsys
# usermod -a -G sapinst SID_LCadm
# useradd -u UID_SAPADM sapadm -g sapinst

# chown SID_LCadm:sapsys /usr/sap/SID/SYS
# chown SID_LCadm:sapsys /sapmnt/SID -R
# chown SID_LCadm:sapsys /usr/sap/trans -R
# chown SID_LCadm:sapsys /usr/sap/SID/SYS -R
# chown SID_LCadm:sapsys /usr/sap/SID -R

    Dabei gilt:

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

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

    Group sapinst      1001
Group sapsys       1002
Group dbhshm       1003

User  en2adm       2001
User  sapadm       2002
User  dbhadm       2003

ASCS-Komponente installieren

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

    # pcs node standby

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

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

    # pcs status

    Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen: 

    Cluster name: nwha
   Cluster Summary:
     * Stack: corosync
     * Current DC: nw-ha-vm-1 (version 2.0.5-9.el8_4.3-ba59be7122) - partition with quorum
     * 2 nodes configured
     * 8 resource instances configured

   Node List:
     * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]

   Full List of Resources:
     * fence-nw-ha-vm-2  (stonith:fence_gce):     Started nw-ha-vm-1
     * fence-nw-ha-vm-1  (stonith:fence_gce):     Stopped
     * Resource Group: nw8_ascs00_group:
       * nw8_vip_ascs00  (ocf::heartbeat:IPaddr2):    Started nw-ha-vm-1
       * nw8_healthcheck_scs (service:haproxy@nw8scs):    Started nw-ha-vm-1
       * nw8_fs_ascs00   (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
     * Resource Group: nw8_ers10_group:
       * nw8_vip_ers10   (ocf::heartbeat:IPaddr2):    Started nw-ha-vm-1
       * nw8_healthcheck_ers (service:haproxy@nw8ers):    Started nw-ha-vm-1
       * nw8_fs_ers10    (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1

   Daemon Status:
     corosync: active/enabled

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

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

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

      Beispiel:

      cd /tmp; /mnt/nfs/install/SWPM/sapinst SAPINST_USE_HOSTNAME=vh-aha-scs

    • Prüfen Sie auf der endgültigen SWPM-Bestätigungsseite, ob der Name des virtuellen Hosts korrekt ist.

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

    # pcs node unstandby

ERS-Komponente installieren

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

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

  2. Geben Sie auf dem primären Server den folgenden Befehl ein, um den primären Server in den Standby-Modus zu setzen.

    # pcs node standby

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

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

    # pcs status

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

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

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

      Beispiel:

      cd /tmp; /mnt/nfs/install/SWPM/sapinst SAPINST_USE_HOSTNAME=vh-aha-ers

    • Prüfen Sie auf der endgültigen SWPM-Bestätigungsseite, ob der Name des virtuellen Hosts korrekt ist.

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

    # pcs node unstandby

SAP-Dienste konfigurieren

Sie müssen bestätigen, dass die Dienste ordnungsgemäß konfiguriert sind, und die Einstellungen in den ASCS- und ERS-Profilen prüfen.

SAP-Dienste beenden

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

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

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

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

    Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

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

Automatischen Dienstneustart in SAP deaktivieren

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

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

    Beispiel:

    #!/bin/sh

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

ASCS- und ERS-Profile bearbeiten

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

    # cd /usr/sap/SID/SYS/profile
    # cd /sapmnt/SID/profile

  2. Suchen Sie bei Bedarf die Dateinamen Ihrer ASCS- und ERS-Profile, indem Sie die Dateien im Profilverzeichnis auflisten oder die folgenden Formate verwenden:

    SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME
    SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME

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

    enque/encni/set_so_keepalive = true

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

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

    ENSA1

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

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

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

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

    ENSA2

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

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

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

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

Clusterressourcen für ASCS und ERS konfigurieren

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

    # pcs property set maintenance-mode="true"

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

    # pcs status

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

    ENSA1

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

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

      # pcs resource meta ASCS_RESOURCE_GROUP resource-stickiness=3000

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

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

    ENSA2

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

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

      # pcs resource meta ASCS_RESOURCE_GROUP resource-stickiness=3000

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

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

Standort- und Reihenfolgeeinschränkungen konfigurieren

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

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

ENSA1

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

    # pcs constraint colocation add ERS_RESOURCE_GROUP with \
    ASCS_RESOURCE_GROUP -5000

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

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

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

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

ENSA2

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

    # pcs constraint colocation add ERS_RESOURCE_GROUP  with \
    ASCS_RESOURCE_GROUP -5000

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

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

  1. Prüfen Sie die Einschränkungen:

    # pcs constraint

    Die Ausgabe sollte in etwa so aussehen:

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

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

    # pcs property set maintenance-mode="false"

Red Hat-Cluster-Connector für SAP konfigurieren

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

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

    usermod -a -G haclient SID_LCadm

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

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

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

    pcs resource disable ERS_INSTANCE_RESOURCE
pcs resource disable ASCS_INSTANCE_RESOURCE

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

    sapcontrol -nr ASCS_INSTANCE_NUMBER -function StopService

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

    sapcontrol -nr ERS_INSTANCE_NUMBER -function StopService

  6. Aktivieren Sie die Ressourcen:

    pcs resource enable ERS_INSTANCE_RESOURCE
pcs resource enable ASCS_INSTANCE_RESOURCE

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

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

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

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

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

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

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

Informationen zum Installieren der Datenbankserver finden Sie unter:

Cluster validieren und testen

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

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

Clusterkonfiguration prüfen

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

    # pcs status

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

    Stack: corosync
  Current DC: nw-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
  Last updated: Wed Apr 13 05:21:21 2022
  Last change: Wed Apr 13 05:21:18 2022 by hacluster via crmd on nw-ha-vm-2

  2 nodes configured
  10 resource instances configured

  Online: [ nw-ha-vm-1 nw-ha-vm-2 ]

  Full list of resources:

  fence-nw-ha-vm-1     (stonith:fence_gce):    Started nw-ha-vm-2
  fence-nw-ha-vm-2     (stonith:fence_gce):    Started nw-ha-vm-1
   Resource Group: ascs-group
       ascs-file-system   (ocf::heartbeat:Filesystem):    Started nw-ha-vm-2
       ascs-vip   (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-2
       ascs-healthcheck   (service:haproxy@AHAascs):      Started nw-ha-vm-2
       ascs-aha-instance      (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-2
   Resource Group: ers-group
       ers-file-system    (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
       ers-vip    (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
       ers-healthcheck    (service:haproxy@AHAers):       Started nw-ha-vm-1
       ers-aha-instance       (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-1

  Migration Summary:
  * Node nw-ha-vm-1:
  * Node nw-ha-vm-2:

  2. Wechseln Sie zum Nutzer SID_LCadm:

    # su - SID_LCadm

  3. Prüfen Sie die Clusterkonfiguration. Geben Sie für INSTANCE_NUMBER die Instanznummer der ASCS- oder ERS-Instanz an, die auf dem Server aktiv ist, auf dem Sie den Befehl eingeben:

    > sapcontrol -nr INSTANCE_NUMBER -function HAGetFailoverConfig

    HAActive sollte TRUE sein, wie im folgenden Beispiel gezeigt:

    HAGetFailoverConfig

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

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

    > sapcontrol -nr INSTANCE_NUMBER -function HACheckConfig

    Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

    14.04.2022 21:43:39
HACheckConfig
OK
state, category, description, comment
SUCCESS, SAP CONFIGURATION, Redundant ABAP instance configuration, 0 ABAP instances detected
SUCCESS, SAP CONFIGURATION, Enqueue separation, All Enqueue server separated from application server
SUCCESS, SAP CONFIGURATION, MessageServer separation, All MessageServer separated from application server
SUCCESS, SAP STATE, SCS instance running, SCS instance status ok
SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version (vip-ascs_NWT_00), SAPInstance includes is-ers patch
SUCCESS, SAP CONFIGURATION, Enqueue replication (vip-ascs_NWT_00), Enqueue replication enabled
SUCCESS, SAP STATE, Enqueue replication state (vip-ascs_NWT_00), Enqueue replication active
SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version (vip-ers_NWT_10), SAPInstance includes is-ers patch

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

    > sapcontrol -nr ASCS_INSTANCE_NUMBER -function HAFailoverToNode ""

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

Failover simulieren

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

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

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

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

  1. Sicherung Ihres Systems erstellen

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

    $ ip link set eth0 down

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

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

     Stack: corosync
  Current DC: nw-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
  Last updated: Wed Apr 13 05:21:21 2022
  Last change: Wed Apr 13 05:21:18 2022 by hacluster via crmd on nw-ha-vm-2

  2 nodes configured
  10 resource instances configured

  Online: [ nw-ha-vm-1 nw-ha-vm-2 ]

  Full list of resources:

  fence-nw-ha-vm-1     (stonith:fence_gce):    Started nw-ha-vm-2
  fence-nw-ha-vm-2     (stonith:fence_gce):    Started nw-ha-vm-1
   Resource Group: ascs-group
       ascs-file-system   (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
       ascs-vip   (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
       ascs-healthcheck   (service:haproxy@AHAascs):      Started nw-ha-vm-1
       ascs-aha-instance      (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-1
   Resource Group: ers-group
       ers-file-system    (ocf::heartbeat:Filesystem):    Started nw-ha-vm-2
       ers-vip    (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-2
       ers-healthcheck    (service:haproxy@AHAers):       Started nw-ha-vm-2
       ers-aha-instance       (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-2

  Migration Summary:
  * Node nw-ha-vm-1:
  * Node nw-ha-vm-2:

Beibehalten von Sperreinträgen bestätigen

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

ENSA1

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

    > enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 11 NUMBER_OF_LOCKS

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

    > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

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

    locks_now: 10

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

    > enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 20 1 1 9999

    Beispiel:

    > enqt pf=/sapmnt/AHA/profile/AHA_ERS10_vh-ers-aha 20 1 1 9999

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

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

    Number of selected entries: 10
Number of selected entries: 10
Number of selected entries: 10
Number of selected entries: 10
Number of selected entries: 10

  5. Wenn der enqt-Monitor beendet wird, beenden Sie den Monitor, indem Sie Ctrl + c eingeben.

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

    # crm_mon

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

    > enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 12 NUMBER_OF_LOCKS

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

    > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

ENSA2

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

    > enq_admin --set_locks=NUMBER_OF_LOCKS:X:DIAG::TAB:%u pf=/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME

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

    > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

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

    locks_now: 10

  3. Wenn ERS aktiv ist, prüfen Sie, ob die Sperreinträge repliziert wurden:

    > sapcontrol -nr ERS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

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

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

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

    # crm_mon

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

    > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

  7. Geben Sie als SID_LCadm auf dem Server, auf dem ERS aktiv ist, die Sperren frei, nachdem Sie sich vergewissert haben, dass die Sperren beibehalten wurden:

    > enq_admin --release_locks=NUMBER_OF_LOCKS:X:DIAG::TAB:%u pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME

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

    > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

    Die Ausgabe sollte in etwa dem folgenden Beispiel entsprechen:

    locks_now: 0

Compute Engine-Wartungsereignis simulieren

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

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

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

  1. Lösen Sie auf dem primären Knoten ein simuliertes Wartungsereignis mit dem folgenden Befehl der gcloud CLI aus:

    $ gcloud compute instances simulate-maintenance-event PRIMARY_VM_NAME

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

    $ pcs status

SAP NetWeaver-Arbeitslast bewerten

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

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

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

Fehlerbehebung

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

Diagnoseinformationen für SAP NetWeaver-Hochverfügbarkeitscluster erfassen

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

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

Support

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

Reichen Sie bei Problemen in Zusammenhang mit SAP-Produkten Ihre Supportanfrage beim SAP-Support ein. SAP wertet das Support-Ticket aus und leitet es, wenn es sich um ein Problem mit der Google Cloud-Infrastruktur handelt, 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: