Fehlerbehebung für Hochverfügbarkeitskonfigurationen für SAP

Bei Hochverfügbarkeitskonfigurationen für SAP in Google Cloud kann die Hauptursache von Problemen in der Clustersoftware, der SAP-Software, der Google Cloud-Infrastruktur oder in einer Kombination dieser Möglichkeiten liegen.

Pacemaker-Logs in Cloud Logging analysieren

Im folgenden Video wird gezeigt, wie Sie mithilfe von Cloud Logging Fehlerbehebungen für Hochverfügbarkeitskonfigurationen für SAP in Google Cloud starten.

Fehlgeschlagener Knoten in einem Linux-Cluster wird nach einem Failover nicht ordnungsgemäß neu gestartet

Wenn Ihr Linux-Hochverfügbarkeitscluster den Fencing-Agent fence_gce verwendet und eine abgegrenzte VM dem Cluster nach einem Failover nicht wieder beitreten kann, müssen Sie möglicherweise den Start der Corosync-Software verzögern, wenn die Fencing-VMs neu gestartet werden.

Problem

Während eines Failovers fängt der Agent fence_gce die fehlgeschlagene Compute Engine-VM ab, die neu gestartet und wieder dem Cluster hinzugefügt wird, bevor Pacemaker die Fencing-Aktion als abgeschlossen registriert. Da die Fencing-Aktion nicht als abgeschlossen registriert ist, fährt die neu gestartete VM die Pacemaker- und Corosync-Dienste herunter und verlässt den Cluster.

Diagnose

So bestätigen Sie, dass dies Ihr Problem ist:

  • Achten Sie darauf, dass der Cluster den Agent fence_gce verwendet:

    RHEL 

    pcs config

    SLES 

    crm config show

    Die Definition des Zaun-Agents enthält fence_gce.

    RHEL 

    Stonith Devices:
Resource: STONITH-example-ha-vm1 (class=stonith type=fence_gce)
Attributes: port=example-ha-vm1 project=example-project-123456 zone=us-central1-a
Operations: monitor interval=300s timeout=120s (STONITH-example-ha-vm1-monitor-interval-60s)
Resource: STONITH-example-ha-vm2 (class=stonith type=fence_gce)
Attributes: port=example-ha-vm2 project=example-project-123456 zone=us-central1-c
Operations: monitor interval=300s timeout=120s (STONITH-example-ha-vm2-monitor-interval-60s)

    SLES 

    primitive fence-example-ha-vm1 stonith:fence_gce \
 op monitor interval=300s timeout=120s \
 op start interval=0 timeout=60s \
 params port=example-ha-vm1 zone=us-central1-a project=example-project-123456
primitive fence-example-ha-vm2 stonith:fence_gce \
 op monitor interval=300s timeout=120s \
 op start interval=0 timeout=60s \
 params port=example-ha-vm2 zone=us-central1-c project=example-project-123456

  • Suchen Sie im Systemlog nach den folgenden Nachrichten:

    DATESTAMP> node2 stonith-ng[1106]:  notice: Operation reboot of node2 by node1 for stonith_admin.1366@node1.c3382af8: OK
DATESTAMP> node2 stonith-ng[1106]:   error: stonith_construct_reply: Triggered assert at commands.c:2343 : request != NULL
DATESTAMP> node2 stonith-ng[1106]: warning: Can't create a sane reply
DATESTAMP> node2 crmd[1110]:    crit: We were allegedly just fenced by node1 for node1!
DATESTAMP> node2 pacemakerd[1055]: warning: Shutting cluster down because crmd[1110] had fatal failure

Lösung

Konfigurieren Sie die Betriebssysteme in beiden Clusterknoten so, dass der Start von Corosync verzögert wird, damit die Fence-Aktion Zeit hat, sich bei Pacemaker auf dem neuen primären Knoten als abgeschlossen zu registrieren. Legen Sie außerdem das Zeitlimit für den Neustart von Pacemaker fest, um die Verzögerung zu berücksichtigen.

So konfigurieren Sie einen verzögerten Start von Corosync:

  1. Versetzen Sie den Cluster in den Wartungsmodus:

    RHEL 

    pcs property set maintenance-mode=true

    SLES 

    crm configure property maintenance-mode="true"

  2. Legen Sie als Root auf jedem Clusterknoten eine Startverzögerung für Corosync fest:

    1. Erstellen Sie eine systemd-Drop-in-Datei:

      systemctl edit corosync.service

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

      [Service]
ExecStartPre=/bin/sleep 60

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

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

      systemctl daemon-reload

  3. Überprüfen Sie als Root auf einem der Clusterknoten, ob das Pacemaker-Zeitlimit für Neustarts für beide Fencing-Agents festgelegt ist:

    1. Prüfen Sie den Wert pcmk_reboot_timeout:

      crm_resource --resource FENCE_AGENT_NAME --get-parameter=pcmk_reboot_timeout

      Ersetzen Sie FENCE_AGENT_NAME durch den Namen des Zaun-Agents.

    2. Wenn der Parameter pcmk_reboot_timeout nicht gefunden wird oder auf einen Wert kleiner als 300 festgelegt ist, legen Sie den Wert auf beiden Fencing-Agents fest:

      crm_resource --resource FENCE_AGENT_NAME --set-parameter=pcmk_reboot_timeout --parameter-value=300

      Ersetzen Sie FENCE_AGENT_NAME durch den Namen des Zaun-Agents.

      Der Wert pcmk_reboot_timeout sollte größer sein als die Summe von:

      • Das Corosync-Zeitlimit token
      • Das Corosync-Konsenszeitlimit, das standardmäßig das Produkt aus token * 1,2 ist
      • Die Zeit, die für einen Neustart benötigt wird, einschließlich Verzögerungsattribut.

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

    3. Bestätigen Sie den neuen Wert pcmk_reboot_timeout:

      crm_resource --resource FENCE_AGENT_NAME --get-parameter=pcmk_reboot_timeout

      Ersetzen Sie FENCE_AGENT_NAME durch den Namen des Zaun-Agents.

  4. Beenden Sie den Wartungsmodus des Clusters:

    RHEL 

    pcs property set maintenance-mode=false

    SLES 

    crm configure property maintenance-mode="false"

Unbeabsichtigte Knotenaffinität, die einen bestimmten Knoten bevorzugt

Wenn Sie Ressourcen in einem Hochverfügbarkeitscluster mithilfe der Clusterbefehle manuell verschieben, stellen Sie fest, dass eine automatische Affinität oder Clienteinstellung für einen bestimmten Knoten festgelegt ist.

Problem

In Ihrem Linux Pacemaker-Hochverfügbarkeitscluster für SAP HANA oder SAP NetWeaver werden Ressourcen wie das SAP HANA-System oder SAP NetWeaver Central Services nur auf einem bestimmten Clusterknoten ausgeführt und es kommt bei einem Knotenfehler nicht wie erwartet zu einem Failover.

Daher können Probleme wie die folgenden auftreten:

  • Wenn Sie den SAP NetWeaver ASCS-Dienst-Failover auslösen, indem Sie einen Pacemaker-Befehl zum move einer Ressource an einen Clusterknoten ausgeben, wird die Ressource nicht gestartet und zeigt den Status stopped an.

  • Wenn Sie den Befehl standby an einen Clusterknoten senden, um alle Ressourcen auf den anderen Knoten zu verschieben, werden die Ressourcen nicht gestartet.

Diagnose

  • Suchen Sie in den Pacemaker-Protokollen nach der Meldung, dass eine bestimmte Ressource nirgendwo ausgeführt werden kann. Beispiel:

    2021-05-24 21:39:58 node_1 pacemaker-schedulerd (native_color) info:
 Resource NW1-ASCS01 cannot run anywhere

  • Prüfen Sie die Konfiguration der Standorteinschränkung von Pacemaker, um Einschränkungen zu ermitteln, die möglicherweise verhindern, dass die Ressourcen auf einem bestimmten Clusterknoten ausgeführt werden.

    So prüfen Sie die Konfiguration der Standorteinschränkung von Pacemaker:

    1. Standorteinschränkungen anzeigen:

      cibadmin --query --scope constraints | grep rsc_location

    2. Prüfen Sie die Standortbeschränkungen:

      • Explizite Standorteinschränkung: Standorteinschränkungen mit dem Wert INFINITY (Knoten bevorzugen) oder -INFINITY (Knoten vermeiden). Beispiel:

        <rsc_location id="loc-constraint" rsc="NW1-ASCS01" score="INFINITY" node="nw-ha-1"/>

        Es darf keine anderen Ortseinschränkungen mit dem Wert INFINITY oder -INFINITY geben als die für die Begrenzungs-Agenten. In allen HA-Clustern sind Fence-Agents in einer Standorteinschränkung mit dem Wert -INFINITY definiert, um zu verhindern, dass sie auf dem Knoten ausgeführt werden, der das Ziel des Fence-Vorgangs ist.

      • Impliziter Standorteinschränkung: Wenn Sie den Pacemaker-Befehl ausführen, um eine Ressource an einen Clusterknoten zu verschieben oder die Ausführung einer Ressource auf einem Clusterknoten zu verbieten, wird der Einschränkungs-ID eine implizite Standorteinschränkung mit dem Präfix cli-ban oder cli-prefer hinzugefügt. Beispiel:

        <rsc_location id="cli-prefer-NW1-ASCS01" rsc="NW1-ASCS01" role="Started" node="nw-ha-2" score="INFINITY"/>

Lösung

Beim Zaun-Agent ist ein Betriebsfehler aufgetreten

Der Fencing-Agent hat einen Fehler im Clusterstatus gemeldet.

Problem

In Ihrem Linux Pacemaker-Hochverfügbarkeitscluster für SAP HANA oder SAP NetWeaver hat der Fencing-Agent einen Fehler im Clusterstatus gemeldet. Beispiel: 

Failed Resource Actions:
   STONITH-ha-node-01_monitor_300000 on ha-node-02 'unknown error' (1): call=153, status=Timed Out, exitreason='',  last-rc-change='Mon Dec 21 23:40:47 2023', queued=0ms, exec=60003ms

Diagnose

Der in Ihrem SAP HANA- oder SAP NetWeaver-Hochverfügbarkeitscluster bereitgestellte Fencing-Agent ruft regelmäßig den Compute Engine API-Server auf, um den Status der Fencing-Zielinstanz zu prüfen. Wenn es bei der API-Aufrufantwort zu einer vorübergehenden Verzögerung oder zu einer Netzwerkunterbrechung kommt, kann der Monitoring-Vorgang des Zaun-Agents fehlschlagen oder eine Zeitüberschreitung auftreten.

Führen Sie den folgenden Befehl aus, um den Status des Zaun-Agents zu prüfen:

RHEL 

pcs status

SLES 

crm status

Wenn der Status des Zaun-Agenten stopped lautet, verwenden Sie eine der Lösungsoptionen, um den Fehler zu beheben.

Der betriebliche Fehler des Zaun-Agents kann dazu führen, dass der Zaun-Agent angehalten wird. Pacemaker ruft die Zaun-Agents jedoch weiterhin mit einer Stopp-Anweisung in einem Zaun-Ereignis auf.

Lösung

Wenn der Status des Zaun-Agenten stopped ist, haben Sie folgende Möglichkeiten:

  • Führen Sie den folgenden Befehl aus, um die Anzahl der Fehlversuche manuell zurückzusetzen und den Zaun-Agent neu zu starten:

    RHEL 

    pcs resource cleanup FENCE_AGENT_NAME

    SLES 

    crm resource cleanup FENCE_AGENT_NAME

    Ersetzen Sie FENCE_AGENT_NAME durch den Namen des Zaun-Agents.

  • Wenn Sie den Betriebsfehler des Zaun-Agents automatisch entfernen möchten, konfigurieren Sie den Parameter failure-timeout.

    Mit dem Parameter failure-timeout wird die Fehlerzahl nach der angegebenen Dauer zurückgesetzt und alle Betriebsfehler werden gelöscht. Wenn Sie diesen Parameter anwenden, müssen Sie den Cluster nicht neu starten oder in den Wartungsmodus versetzen.

    Führen Sie den folgenden Befehl aus, um den Parameter failure-timeout zu konfigurieren:

    crm_resource --meta --resource FENCE_AGENT_NAME --set-parameter failure-timeout --parameter-value DURATION

    Ersetzen Sie Folgendes:

    • FENCE_AGENT_NAME: der Name des Zaun-Agents.
    • DURATION: die Dauer nach dem letzten operativen Ausfall, nach dem die Fehlerzahl zurückgesetzt und der Fencing-Agent neu gestartet wird.

Fencing-Agent gcpstonith wird eingestellt

Der Zaun-Agent gcpstonith ist in Ihrer Konfiguration aktiv. Dieser Agent wird nicht mehr unterstützt. Der Kundenservice hat mitgeteilt, dass du stattdessen zu fence_gce wechseln musst.

Problem

In Ihrem Linux Pacemaker-Hochverfügbarkeitscluster für SAP HANA unter SUSE Linux wird der Fencing-Agent gcpstonith verwendet. Beispiel:

 # crm status | grep gcpstonith
   * STONITH-hana-vm1   (stonith:external/gcpstonith):   Started hana-vm2
   * STONITH-hana-vm2   (stonith:external/gcpstonith):   Started hana-vm1

Diagnose

Der in Ihrem SAP HANA-Hochverfügbarkeitscluster bereitgestellte Fencing-Agent muss aktualisiert werden, damit stattdessen der im Betriebssystem enthaltene fence_gce-Fencing-Agent verwendet wird. Das gcpstonith-Agent-Script wurde auf Legacy-Systemen bereitgestellt und durch fence_gce ersetzt. fence_gce ist Teil des fence-agents-SUSE Linux-Pakets. gcpstonith wurde nur im Rahmen von SUSE Linux HANA-Bereitstellungen bereitgestellt.

Lösung

So migrieren Sie von gcpstonith unter SUSE Linux:

  1. Installieren Sie die folgenden zusätzlichen Pakete, die für Ihr Betriebssystem spezifisch sind:

    • Für SLES 15: python3-oauth2client und python3-google-api-python-client

    • Für SLES 12: python-google-api-python-client, python-oauth2client und python-oauth2client-gce

    Verwenden Sie den folgenden Befehl, um diese Pakete in Ihrem Betriebssystem zu installieren:

    SLES 15 

    zypper in -y python3-oauth2client python3-google-api-python-client

    SLES 12 

    zypper in -y python-google-api-python-client python-oauth2client python-oauth2client-gce

  2. Aktualisieren Sie das fence-agents-Paket, um sicherzustellen, dass Sie die neueste Version installiert haben:

    zypper update -y fence-agents

  3. Versetzen Sie den Cluster in den Wartungsmodus:

    crm configure property maintenance-mode=true

  4. Löschen Sie alle Begrenzungsgeräte aus Ihrem Cluster. Wenn Sie das letzte Fencing-Gerät löschen, werden Sie möglicherweise aufgefordert, zu bestätigen, dass in Ihrem Cluster keine STONITH-Ressourcen definiert sind.

    crm configure delete FENCING_RESOURCE_PRIMARY
     
    crm configure delete FENCING_RESOURCE_SECONDARY

  5. Erstellen Sie das Fencing-Gerät für die primäre Instanz neu:

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

  6. Erstellen Sie das Fencing-Gerät für die sekundäre Instanz neu:

    crm configure primitive FENCING_RESOURCE_SECONDARY stonith:fence_gce \
 op monitor interval="300s" timeout="120s" \
 op start interval="0" timeout="60s" \
 params port="SECONDARY_INSTANCE_NAME" zone="SECONDARY_ZONE" \
 project="PROJECT_ID" \
 pcmk_reboot_timeout=300 pcmk_monitor_retries=4

  7. Legen Sie die Standortbeschränkungen fest:

    crm configure location FENCING_LOCATION_NAME_PRIMARY \
 FENCING_RESOURCE_PRIMARY -inf: "PRIMARY_INSTANCE_NAME"

crm configure location FENCING_LOCATION_NAME_SECONDARY \
 FENCING_RESOURCE_SECONDARY -inf: "SECONDARY_INSTANCE_NAME"

  8. Beenden Sie den Wartungsmodus des Clusters: 

    crm configure property maintenance-mode=false

  9. Prüfen Sie die Konfiguration:

    crm config show related:FENCING_RESOURCE_PRIMARY

  10. Prüfen Sie den Clusterstatus:

    # crm status | grep fence_gce
  STONITH-hana-vm1   (stonith:fence_gce):   Started hana-vm2
  STONITH-hana-vm2   (stonith:fence_gce):   Started hana-vm1

Ressourcen-Agent wurde angehalten

Ein Ressourcen-Agent konnte nicht gestartet werden und verbleibt im Status Stopped.

Problem

In Ihrem Linux Pacemaker-Hochverfügbarkeitscluster für SAP HANA oder SAP NetWeaver hat der Ressourcen-Agent einen Fehler im Clusterstatus gemeldet. Beispiel:

Failed Resource Actions:
   rsc_SAPHana_DV0_HDB00_start_0 on ha-node-02 'error' (1): call=91, status='complete', last-rc-change='Wed Oct 18 18:00:31 2023', queued=0ms, exec=19010ms

Diagnose

Wenn ein laufender Ressourcen-Agent fehlschlägt, versucht Pacemaker, den Agent zu beenden und noch einmal zu starten. Wenn der Startvorgang aus irgendeinem Grund fehlschlägt, legt Pacemaker die Ressourcenfehleranzahl auf INFINITY fest und versucht, den Agent auf einem anderen Knoten zu starten. Wenn der Ressourcen-Agent auf einem Knoten nicht gestartet werden kann, bleibt der Ressourcen-Agent im Status Stopped.

Führen Sie den folgenden Befehl aus, um den Status des Ressourcen-Agents zu prüfen:

RHEL 

pcs status

SLES 

crm status

Für SAP HANA zeigt das folgende Beispiel den Ressourcen-Agent im Status Stopped auf dem Knoten hana-b:

Full List of Resources:
  * STONITH-hana-a        (stonith:fence_gce):   Started hana-b
  * STONITH-hana-b        (stonith:fence_gce):   Started hana-a
  * Resource Group: g-primary:
    * rsc_vip_int-primary       (ocf::heartbeat:IPaddr2):        Started hana-a
    * rsc_vip_hc-primary        (ocf::heartbeat:anything):       Started hana-a
  * Clone Set: cln_SAPHanaTopology_DV0_HDB00 [rsc_SAPHanaTopology_DV0_HDB00]:
    * Started: [ hana-a hana-b ]
  * Clone Set: msl_SAPHana_DV0_HDB00 [rsc_SAPHana_DV0_HDB00] (promotable):
    * Masters: [ hana-a ]
    * Stopped: [ hana-b ]
  * STONITH-scaleup-majority    (stonith:fence_gce):   Started hana-b

Lösung

Wenn ein Ressourcen-Agent den Status Stopped hat, gehen Sie so vor:

  1. Starten Sie den Ressourcen-Agent manuell, indem Sie die Anzahl der Fehler zurücksetzen:

    RHEL 

    pcs resource cleanup RESOURCE_AGENT_NAME

    SLES 

    crm resource cleanup RESOURCE_AGENT_NAME

    Ersetzen Sie RESOURCE_AGENT_NAME durch den Namen des Ressourcen-Agents. Beispiel: rsc_SAPHana_DV0_HDB00.

  2. Prüfen Sie, ob der Status des Ressourcen-Agents den Status Started erreicht: 

    crm_mon

    Wenn der Ressourcen-Agent immer noch nicht gestartet werden kann, holen Sie die relevanten Diagnoseinformationen ein und wenden Sie sich an den Support.