Freigeben über

Problembehandlung bei unerwarteten Knotenneustarts in Azure Linux SUSE Pacemaker Cluster-Knoten

Gilt für: ✔️ Linux-VMs

Dieser Artikel enthält Anleitungen zur Problembehandlung, Analyse und Auflösung der am häufigsten verwendeten Szenarien für unerwartete Knotenneustarts in SUSE Pacemaker Clustern.

Voraussetzungen

Szenario 1: Netzwerkausfall

  • Bei den Clusterknoten treten corosync Kommunikationsfehler auf. Dies führt zu kontinuierlichen Übertragungen aufgrund einer Unfähigkeit, die Kommunikation zwischen Knoten herzustellen. Dieses Problem löst Anwendungstimeouts aus, was letztendlich zu Knoten-Fencing und nachfolgenden Neustarts führt.
  • Darüber hinaus generieren Dienste, die von der Netzwerkkonnektivität abhängig sind, z waagent. B. kommunikationsbezogene Fehlermeldungen in den Protokollen. Dies zeigt weitere Netzwerkunterbrechungen an.

Die folgenden Nachrichten werden im /var/log/messages Protokoll protokolliert:

Von node 01:

Aug 21 01:48:00 node  01 corosync[19389]:  [TOTEM ] Token has not been received in 30000 ms
Aug 21 01:48:00 node  01 corosync[19389]:  [TOTEM ] A processor failed, forming new configuration: token timed out (40000ms), waiting 48000ms for consensus.

Von node 02:

Aug 21 01:47:27 node  02 corosync[15241]:  [KNET  ] link: host: 2 link: 0 is down
Aug 21 01:47:27 node  02 corosync[15241]:  [KNET  ] host: host: 2 (passive) best link: 0 (pri: 1)
Aug 21 01:47:27 node  02 corosync[15241]:  [KNET  ] host: host: 2 has no active links
Aug 21 01:47:31 node  02 corosync[15241]:  [TOTEM ] Token has not been received in 30000 ms

Ursache für Szenario 1

Ein unerwarteter Knotenneustart tritt aufgrund einer Netzwerkwartungsaktivität oder eines Ausfalls auf. Zur Bestätigung können Sie den Zeitstempel abgleichen, indem Sie die Azure-Wartungsbenachrichtigung im Azure-Portal überprüfen. Weitere Informationen zu geplanten Azure-Ereignissen finden Sie unter Azure Metadata Service: Geplante Ereignisse für Linux-VMs.

Lösung für Szenario 1

Wenn der unerwartete Neustartzeitstempel mit einer Wartungsaktivität übereinstimmt, bestätigt die Analyse, dass sich die Plattform oder die Netzwerkwartung auf den Cluster auswirkt.

Für weitere Unterstützung oder andere Abfragen können Sie eine Supportanfrage öffnen, indem Sie diese Anweisungen befolgen.

Szenario 2: Fehlkonfiguration von Clustern

Die Clusterknoten haben unerwartete Failovers oder Knotenneustarts. Diese werden häufig durch Clusterfehler verursacht, die sich auf die Stabilität von Pacemaker-Clustern auswirken.

Führen Sie den folgenden Befehl aus, um die Konfiguration des Rhe-Clusters zu überprüfen:

sudo crm configure show

Ursache für Szenario 2

Unerwartete Neustarts in einem Azure SUSE Pacemaker-Cluster treten häufig aufgrund von Fehlkonfigurationen auf:

  • Falsche STONITH-Konfiguration:

    • Kein STONITH oder Fencing falsch konfiguriert: Das ordnungsgemäße Konfigurieren von STONITH kann dazu führen, dass Knoten als fehlerhaft gekennzeichnet werden und unnötige Neustarts auslösen.
    • Falsche STONITH-Ressourceneinstellungen: Falsche Parameter für Azure-Fencing-Agents, z fence_azure_arm. B. , können dazu führen, dass Knoten unerwartet während failovers neu gestartet werden.
    • Unzureichende Berechtigungen: Die Azure-Ressourcengruppe oder Anmeldeinformationen, die für das Fencing verwendet werden, weisen möglicherweise erforderliche Berechtigungen auf und verursachen STONITH-Fehler.

  • Fehlende oder falsche Ressourceneinschränkungen: Unzureichend festgelegte Einschränkungen können dazu führen, dass Ressourcen unnötig verteilt werden. Dies kann zu Knotenüberladungen und Neustarts führen. Falsch ausgerichtete Ressourcenabhängigkeitskonfigurationen können dazu führen, dass Knoten fehlschlagen oder in eine Neustartschleife wechseln.

  • Clusterschwellenwert und Timeout-Fehlkonfigurationen:

    • failure-time-out, migration-thresholdoder monitor-time-out Werte können dazu führen, dass Knoten vorzeitig neu gestartet werden.
    • Takttimeouteinstellungen: Falsche corosync Timeouteinstellungen für Taktintervalle können dazu führen, dass Knoten offline sind und unnötige Neustarts auslösen.

  • Fehlende ordnungsgemäße Integritätsprüfungen: Das Festlegen korrekter Integritätsprüfungsintervalle für kritische Dienste wie SAP HANA (High-Performance ANalytic Application) kann zu Ressourcen- oder Knotenfehlern führen.

  • Falschkonfiguration des Ressourcen-Agents:

    • Benutzerdefinierte Ressourcen-Agents, die mit Cluster falsch ausgerichtet sind: Ressourcen-Agents, die nicht den Pacemaker-Standards entsprechen, können zu unvorhersehbaren Verhaltensweisen führen, einschließlich Knotenneustarts.
    • Falsche Start-/Stoppparameter der Ressource: Falsch abgestimmte Start-/Stoppparameter in der Clusterkonfiguration können Knoten während der Ressourcenwiederherstellung neu starten.

  • Corosync-Konfigurationsprobleme:

    • Nicht optimierte Netzwerkeinstellungen: Falsche Multicast-/Unicastkonfigurationen können zu Taktkommunikationsfehlern führen. Nicht übereinstimmende ring0 Konfigurationen und ring1 Netzwerkkonfigurationen können zu Split-Brain-Szenarien und Knoten-Fencing führen.
    • Tokentimeout-Konflikte: Tokentimeoutwerte, die nicht an der Latenz der Umgebung ausgerichtet sind, können die Knotenisolation und Neustarts auslösen.
    • Führen Sie den folgenden Befehl aus, um eine Corosync-Konfiguration zu überprüfen: 
      sudo cat /etc/corosync/corosync.conf

Lösung für Szenario 2

  • Befolgen Sie die richtigen Richtlinien, um einen SUSE Pacemaker Cluster einzurichten. Stellen Sie außerdem sicher, dass entsprechende Ressourcen für Anwendungen wie SAP HANA oder SAP NetWeaver zugeordnet werden, wie in der Microsoft-Dokumentation angegeben.
  • Schritte zum Vornehmen der erforderlichen Änderungen an der Clusterkonfiguration:
    1. Beenden Sie die Anwendung auf beiden Knoten.
    2. Setzen Sie den Cluster in den Wartungsmodus. 
      crm configure property maintenance-mode=true
    3. Bearbeiten der Clusterkonfiguration: 
      crm configure edit
    4. Speichern Sie die Änderungen.
    5. Entfernen Sie den Cluster aus dem Wartungsmodus. 
      crm configure property maintenance-mode=false

Szenario 3: Migration von lokal zu Azure

Wenn Sie einen SUSE Pacemaker-Cluster von der lokalen Bereitstellung zu Azure migrieren, können unerwartete Neustarts von bestimmten Fehlkonfigurationen oder übersehenen Abhängigkeiten auftreten.

Ursache für Szenario 3

Im Folgenden finden Sie häufige Fehler in dieser Kategorie:

  • Unvollständige oder falsche STONITH-Konfiguration:

    • Kein STONITH oder Fencing falsch konfiguriert: Das Ordnungsgemäße Konfigurieren von STONITH (Shoot-The-Other-Node-In-The-Head) kann dazu führen, dass Knoten als fehlerhaft markiert werden und unnötige Neustarts auslösen.
    • Falsche STONITH-Ressourceneinstellungen: Falsche Parameter für Azure-Fencing-Agents, z fence_azure_arm . B. können dazu führen, dass Knoten während des Failovers unerwartet neu gestartet werden.
    • Unzureichende Berechtigungen: Die Azure-Ressourcengruppe oder Anmeldeinformationen, die für das Fencing verwendet werden, weisen möglicherweise erforderliche Berechtigungen auf und verursachen STONITH-Fehler. Wichtige azurespezifische Parameter, z. B. Abonnement-ID, Ressourcengruppe oder VM-Namen, müssen im Fencing-Agent ordnungsgemäß konfiguriert werden. Auslassungen können hier zu Fencing-Fehlern und unerwarteten Neustarts führen.

    Weitere Informationen finden Sie unter "Behandeln von Problemen beim Start von Azure Fence Agent" in SUSE und Problembehandlung bei SBD-Dienstfehlern in SUSE Pacemaker-Clustern

  • Netzwerkfehler: Falsch konfigurierte VNets, Subnetze oder Sicherheitsgruppenregeln können die grundlegende Clusterkommunikation blockieren und wahrgenommene Knotenfehler und Neustarts verursachen.

    Weitere Informationen finden Sie unter Virtuelle Netzwerke und virtuelle Computer in Azure

  • Metadatendienstprobleme: Die Cloudmetadatendienste von Azure müssen ordnungsgemäß behandelt werden. Andernfalls können Ressourcenerkennungs- oder Startprozesse fehlschlagen.

    Weitere Informationen finden Sie unter Azure Instance Metadata Service und Azure Metadata Service: Geplante Ereignisse für Linux-VMs

  • Leistungs- und Latenzkonflikt:

    • Unzureichende VM-Größe: Migrierte Workloads stimmen möglicherweise nicht mit der ausgewählten Größe von Azure VM(Virtual Machine) überein. Dies führt zu übermäßiger Ressourcennutzung und löst Neustarts aus.
    • Disk-E/A-Übereinstimmungen: Lokale Workloads mit hohen IOPS-Anforderungen (Eingabe-/Ausgabevorgänge pro Sekunde) müssen mit der entsprechenden Azure-Datenträger- oder Speicherleistungsebene gekoppelt werden.

    Weitere Informationen finden Sie unter Sammeln von Leistungsmetriken für eine Linux-VM

  • Sicherheitsregeln und Firewallregeln:

    • Portblock: Lokale Cluster haben häufig offene, interne Kommunikation. Darüber hinaus blockieren Azure NSGs (Netzwerksicherheitsgruppen) oder Firewalls möglicherweise Ports, die für die Pacemaker- oder Corosync-Kommunikation erforderlich sind.

    Weitere Informationen finden Sie unter Netzwerksicherheitsgruppentest

Lösung für Szenario 3

Befolgen Sie die richtigen Richtlinien, um einen SUSE Pacemaker Cluster einzurichten. Stellen Sie außerdem sicher, dass entsprechende Ressourcen für Anwendungen wie SAP HANA oder SAP NetWeaver zugeordnet werden, wie in der Microsoft-Dokumentation angegeben.

Szenario 4: HANA_CALL Timeout nach 60 Sekunden

Der Azure SUSE Pacemaker Cluster führt SAP HANA als Anwendung aus und erlebt unerwartete Neustarts auf einem der Knoten oder beide Knoten im Pacemaker Cluster. Gemäß den /var/log/messages Einträgen oder /var/log/pacemaker.log Protokolleinträgen wird der Knotenneustart durch ein HANA_CALL Timeout wie folgt verursacht:

2024-06-04T09:25:37.772406+00:00 node01 SAPHanaTopology(rsc_SAPHanaTopology_H00_HDB02)[99440]: WARNING: RA: HANA_CALL timed out after 60 seconds running command 'hdbnsutil -sr_stateConfiguration --sapcontrol=1'
2024-06-04T09:25:38.711650+00:00 node01 SAPHana(rsc_SAPHana_H00_HDB02)[99475]: WARNING: RA: HANA_CALL timed out after 60 seconds running command 'hdbnsutil -sr_stateConfiguration'
2024-06-04T09:25:38.724146+00:00 node01 SAPHana(rsc_SAPHana_H00_HDB02)[99475]: ERROR: ACT: check_for_primary:  we didn't expect node_status to be: <>
2024-06-04T09:25:38.736748+00:00 node01 SAPHana(rsc_SAPHana_H00_HDB02)[99475]: ERROR: ACT: check_for_primary:  we didn't expect node_status to be: DUMP <00000000  0a                                                |.|#01200000001>

Ursache für Szenario 4

Die SAP HANA-Timeoutmeldungen gelten häufig als interne Anwendungstimeouts. Daher sollte der SAP-Anbieter eingebunden werden.

Lösung für Szenario 4

  • Überprüfen Sie die Betriebssystemleistung, um die Ursache des Problems zu identifizieren.
  • Sie sollten besonders auf Speicherdruck und Speichergeräte und deren Konfiguration achten. Dies gilt insbesondere, wenn HANA auf Network File System (NFS), Azure NetApp Files (ANF) oder Azure Files gehostet wird.
  • Nachdem Sie externe Faktoren, z. B. Plattform- oder Netzwerkausfälle, ausgeschlossen haben, empfehlen wir, dass Sie sich an den Anwendungsanbieter wenden, um die Ablaufverfolgung von Anrufanalysen und die Protokollüberprüfung durchzuführen.

Szenario 5: ASCS/ERS Timeout in SAP Netweaver Clustern

Der Azure SUSE Pacemaker Cluster führt SAP Netweaver ASCS/ERS als Anwendung aus und erlebt unerwartete Neustarts auf einem der Knoten oder beide Knoten im Pacemaker Cluster. Die folgenden Nachrichten werden im /var/log/messages Protokoll protokolliert:

2024-11-09T07:36:42.037589-05:00 node  01 SAPInstance(RSC_SAP_ERS10)[8689]: ERROR: SAP instance service enrepserver is not running with status GRAY !
2024-11-09T07:36:42.044583-05:00 node  01 pacemaker-controld[2596]: notice: Result of monitor operation for RSC_SAP_ERS10 on node01: not running 

2024-11-09T07:39:42.789404-05:00 node01 SAPInstance(RSC_SAP_ASCS00)[16393]: ERROR: SAP Instance CP2-ASCS00 start failed: #01109.11.2024 07:39:42#012WaitforStarted#012FAIL: process msg_server MessageServer not running
2024-11-09T07:39:420.796280-05:00 node01 pacemaker-execd[2404]: notice: RSC_SAP_ASCS00 start (call 78, PID 16393) exited with status 7 (execution time 23.488s)
2024-11-09T07:39:42.828845-05:00 node  01 pacemaker-schedulerd[2406]: warning: Unexpected result (not running) was recorded for start of RSC_SAP_ASCS00 on node01 at Nov  9 07:39:42 2024 
2024-11-09T07:39:42.828955-05:00 node  01 pacemaker-schedulerd[2406]: warning: Unexpected result (not running) was recorded for start of RSC_SAP_ASCS00 on node01 at Nov  9 07:39:42 2024

Ursache für Szenario 5

Die ASCS/ERS Ressource gilt als Anwendung für SAP Netweaver Cluster. Wenn die entsprechende Clusterüberwachungsressource zu einem Ausfall führt, löst sie einen Failoverprozess aus.

Lösungsszenario 5

  • Um die Ursache des Problems zu identifizieren, empfehlen wir, die Betriebssystemleistung zu überprüfen.
  • Sie sollten besonders auf Speicherdruck und Speichergeräte und deren Konfiguration achten. Dies gilt insbesondere, wenn SAP Netweaver auf Network File System (NFS), Azure NetApp Files (ANF) oder Azure Files gehostet wird.
  • Nachdem Sie externe Faktoren, z. B. Plattform- oder Netzwerkausfälle, ausgeschlossen haben, empfehlen wir, den Anwendungsanbieter für die Ablaufverfolgungs-Anrufanalyse und die Protokollüberprüfung zu engagieren.

Nächste Schritte

Um weitere Hilfe zu finden, öffnen Sie eine Supportanfrage, und übermitteln Sie Ihre Anfrage, indem Sie supportconfig und hb_report Protokolle zur Problembehandlung anfügen.

Informationen zum Haftungsausschluss von Drittanbietern

Die in diesem Artikel genannten Drittanbieterprodukte stammen von Herstellern, die von Microsoft unabhängig sind. Microsoft gewährt keine implizite oder sonstige Garantie in Bezug auf die Leistung oder Zuverlässigkeit dieser Produkte.

Haftungsausschluss für Kontaktinformationen von Drittanbietern

Die Kontaktinformationen zu den in diesem Artikel erwähnten Drittanbietern sollen Ihnen helfen, zusätzliche Informationen zu diesem Thema zu finden. Diese Kontaktinformationen können ohne vorherige Ankündigung geändert werden. Sie werden von Microsoft ohne jede Gewähr weitergegeben.

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.