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 erfahren Sie, wie Sie mit Cloud Logging mit Hochverfügbarkeitskonfigurationen für SAP in Google Cloud Fehler beheben.

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

Versetzen Sie den Cluster in den Wartungsmodus:

RHEL

pcs property set maintenance-mode=true

SLES

crm configure property maintenance-mode="true"

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
```
Ü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 Fencing-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 Fencing-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 Fencing-Agents.

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 mithilfe der Clusterbefehle manuell in einen Hochverfügbarkeitscluster verschieben, stellen Sie fest, dass eine automatische Affinität oder Clienteinstellung auf einen bestimmten Knoten bevorzugt wird.

Problem

In Ihrem Linux Pacemaker-Hochverfügbarkeitscluster für SAP HANA oder SAP NetWeaver werden Ressourcen wie SAP HANA-System oder zentrale SAP NetWeaver-Dienste nur auf einem bestimmten Clusterknoten ausgeführt und führen während des Failovers kein Failover durch ein Knotenfehlerereignis.

Deshalb können folgende Probleme auftreten:

Wenn Sie den SAP NetWeaver ASCS-Dienst-Failover auslösen, indem Sie einen Pacemaker-Befehl an move für eine Ressource an einen Clusterknoten senden, wird die Ressource nicht gestartet und zeigt den Status stopped an.
Wenn Sie den Befehl standby für einen Clusterknoten ausführen, werden alle Ressourcen zum anderen Knoten verschoben, sodass die Ressourcen nicht gestartet werden.

Diagnose

Suchen Sie in den Pacemaker-Logs nach der Nachricht, in der eine bestimmte Ressource erwähnt wird, die 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 Pacemaker-Standorteinschränkung, um alle Einschränkungen zu ermitteln, die die Ausführung der Ressourcen auf einem bestimmten Clusterknoten verhindern können.

So prüfen Sie die Konfiguration der Pacemaker-Standorteinschränkung:
1. Rufen Sie die Standortbeschränkungen auf:
```
cibadmin --query --scope constraints | grep rsc_location
```
2. Prüfen Sie die Standortbeschränkungen:
  - Explizite Standortbeschränkung: Sie finden Standortbeschränkungen mit der Punktzahl INFINITY (bevorzugt den Knoten) oder -INFINITY (vermeiden Sie den Knoten). Beispiel:
```
<rsc_location id="loc-constraint" rsc="NW1-ASCS01" score="INFINITY" node="nw-ha-1"/>
```
    Es darf keine Standortbeschränkung mit dem Wert INFINITY oder -INFINITY außer den Fencing-Agents vorhanden sein. In allen HA-Clustern werden Fencing-Agents in einer Standortbeschränkung mit dem Wert -INFINITY definiert, um zu verhindern, dass sie auf dem Knoten ausgeführt werden, der das Fencing-Ziel ist.
  - Implizite Standortbeschränkung: Wenn Sie den Pacemaker-Befehl ausführen, um eine Ressource in einen Clusterknoten zu verschieben oder eine Ressource zu sperren, die auf einem Clusterknoten ausgeführt werden soll, eine implizite Standortbeschränkung mit dem Präfix cli-ban oder cli-prefer wird der Einschränkungs-ID hinzugefügt. Beispiel:
```
<rsc_location id="cli-prefer-NW1-ASCS01" rsc="NW1-ASCS01" role="Started" node="nw-ha-2" score="INFINITY"/>
```

Lösung

Achten Sie darauf, dass die Standortbeschränkungen wie in unseren Bereitstellungsanleitungen angegeben sind:
Löschen Sie die Standortbeschränkung, um eine explizite Standortbeschränkung zu korrigieren:
RHEL
```
pcs constraint remove RESOURCE_LOCATION_ID
```
SLES
```
crm configure delete RESOURCE_LOCATION_ID
```
Ersetzen Sie RESOURCE_LOCATION_ID durch die Standortbeschränkungs-ID.
Entfernen Sie alle für die angegebene Ressource definierten Einschränkungen, um eine implizite Standortbeschränkung zu beheben.

Führen Sie nach jedem Befehl, den Sie zum Verschieben oder Sperren einer Ressource verwenden, den folgenden Befehl aus, um alle Einschränkungen zu entfernen:
RHEL
```
pcs resource clear RESOURCE_NAME
```
SLES
```
crm resource clear RESOURCE_NAME
```
Ersetzen Sie RESOURCE_NAME durch den Namen der Ressource, die Sie verschieben möchten.

Beim Fencing-Agent ist ein Betriebsfehler aufgetreten

Der Fencing-Agent hat im Clusterstatus einen Fehler 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 greift regelmäßig auf den Compute Engine API-Server zu, um den Status der Fencing-Zielinstanz zu prüfen. Wenn es in der API-Aufrufantwort zu einer vorübergehenden Verzögerung kommt oder eine Netzwerkunterbrechung auftritt, kann der Fencing-Monitoring-Vorgang fehlschlagen oder zu einer Zeitüberschreitung führen.

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

RHEL

pcs status

SLES

crm status

Wenn der Fencing-Agent-Status stopped lautet, verwenden Sie eine der Lösungsoptionen, um den Fehler zu beheben.

Der Fencing-Agent-Betriebsfehler kann dazu führen, dass der Fencing-Agent gestoppt wird, aber Pacemaker ruft die Fencing-Agents weiterhin mit einer Stopp-Anweisung in einem Fencing-Ereignis auf.

Lösung

Wenn der Fencing-Agent-Status stopped ist, führen Sie einen der folgenden Schritte aus:

Führen Sie den folgenden Befehl aus, um die Failover-Anzahl manuell zurückzusetzen und den Fencing-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 Fencing-Agents.
Konfigurieren Sie den Parameter failure-timeout, um den Betriebsfehler des Fencing-Agents automatisch zu entfernen.

Der Parameter failure-timeout setzt die Fehlerzahl nach der angegebenen Dauer zurück und löscht alle Betriebsfehler. Bei der Anwendung dieses Parameters müssen Sie den Cluster nicht neu starten oder den Cluster 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 Fencing-Agents.
- DURATION: die Dauer nach dem letzten operativen Ausfall, nach dem die Fehlerzahl zurückgesetzt und der Fencing-Agent neu gestartet wird.

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:external/gcpstonith):   Started hana-b
  * STONITH-hana-b        (stonith:external/gcpstonith):   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:external/gcpstonith):   Started hana-b

Lösung

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

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