Risoluzione dei problemi relativi alle configurazioni ad alta disponibilità per SAP

Nelle configurazioni ad alta disponibilità per SAP su Google Cloud, la causa principale dei problemi potrebbe risiedere nel software di clustering, software, l'infrastruttura Google Cloud o una combinazione di questi.

Analizzare i log di Pacemaker in Cloud Logging

Il seguente video mostra come avviare la risoluzione dei problemi configurazioni ad alta disponibilità per SAP su Google Cloud utilizzando Cloud Logging.

Il nodo non riuscito in un cluster Linux non si riavvia correttamente dopo un failover

Se il tuo cluster Linux ad alta disponibilità utilizza l'agente di fence fence_gce e una VM recintata non riesce a rientrare nel cluster dopo un failover, potresti aver bisogno per ritardare l'avvio del software Corosync al riavvio delle VM protette.

Problema

Durante un failover, l'agente fence_gce respinge l'errore VM di Compute Engine, che si riavvia e si riconnette al cluster prima che il pacemaker registri l'azione del recinto come completata. Poiché l'azione di blocco non è stata registrata come completata, la VM riavviata arresta i servizi Pacemaker e Corosync e esce dal cluster.

Diagnosi

Per confermare che si tratta del tuo problema:

  • Assicurati che il cluster utilizzi l'agente fence_gce:

    RHEL 

    pcs config

    SLES 

    crm config show

    La definizione dell'agente di recinto include 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

  • Controlla se nel log di sistema sono presenti i seguenti messaggi:

    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

Soluzione

Configura i sistemi operativi in entrambi i nodi del cluster per ritardare l'avvio di Corosync per garantire che l'azione del recinto abbia il tempo di essere registrata come completata con Pacemaker sul nuovo nodo primario. Imposta anche la funzionalità Pacemaker il valore di timeout del riavvio per tenere conto del ritardo.

Per configurare un avvio ritardato di Corosync:

  1. Imposta il cluster in modalità di manutenzione:

    RHEL 

    pcs property set maintenance-mode=true

    SLES 

    crm configure property maintenance-mode="true"

  2. Su ogni nodo del cluster come utente root, imposta un ritardo di avvio per Corosync:

    1. Crea un file di plug-in systemd:

      systemctl edit corosync.service

    2. Aggiungi le seguenti righe al file:

      [Service]
ExecStartPre=/bin/sleep 60

    3. Salva il file ed esci dall'editor.

    4. Ricarica la configurazione del gestore systemd.

      systemctl daemon-reload

  3. Su entrambi i nodi del cluster come utente root, verifica che il valore di timeout di Pacemaker per i riavvii sia impostato per entrambi gli agenti di recinzione:

    1. Controlla il valore pcmk_reboot_timeout:

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

      Sostituisci FENCE_AGENT_NAME con il nome di l'agente di recinzione.

    2. Se il parametro pcmk_reboot_timeout non viene trovato o è impostato su un valore inferiore a 300, imposta il valore su entrambi gli agenti di recinzione:

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

      Sostituisci FENCE_AGENT_NAME con il nome dell'agente di recinzione.

      Il valore pcmk_reboot_timeout deve essere maggiore della somma di:

      • Timeout di Corosync token
      • Il timeout del consenso di Corosync, che per impostazione predefinita è il prodotto di token * 1,2
      • Il tempo necessario per completare un'operazione di riavvio, incluso qualsiasi attributo di ritardo.

      Su Google Cloud, 300 secondi sono sufficienti per la maggior parte dei cluster.

    3. Conferma il nuovo valore pcmk_reboot_timeout:

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

      Sostituisci FENCE_AGENT_NAME con il nome di l'agente di recinzione.

  4. Rimuovi il cluster dalla modalità di manutenzione:

    RHEL 

    pcs property set maintenance-mode=false

    SLES 

    crm configure property maintenance-mode="false"

Affinità dei nodi involontaria che favorisce un determinato nodo

Quando sposti manualmente le risorse in un cluster ad alta disponibilità utilizzando i comandi di cluster, scopri che è impostata un'affinità automatica o una preferenza del client per favorire un determinato nodo.

Problema

Nel tuo cluster ad alta disponibilità Pacemaker Linux per SAP HANA o SAP NetWeaver, risorse come il sistema SAP HANA o I servizi SAP NetWeaver Central vengono eseguiti solo su un nodo cluster specifico e non eseguono il failover come previsto durante un evento di errore del nodo.

Di conseguenza, potresti riscontrare problemi quali:

  • Quando attivi il failover del servizio SAP NetWeaver ASCS emettendo un comando Pacemaker per move una risorsa a un nodo del cluster, la risorsa non si avvia e mostra lo stato stopped.

  • Quando emetti il comando standby a un nodo del cluster per forzare il trasferimento di tutte le risorse all'altro nodo, le risorse non si avviano.

Diagnosi

  • Controlla i log di Pacemaker per verificare se è presente il messaggio che menziona un particolare la risorsa non può essere eseguita da nessuna parte. Ad esempio:

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

  • Controlla la configurazione del vincolo di posizione del pacemaker per identificarlo a eventuali vincoli che potrebbero impedire l'esecuzione delle risorse su un di un nodo del cluster specifico.

    Per controllare la configurazione del vincolo di posizione del pacemaker:

    1. Visualizza i vincoli di località:

      cibadmin --query --scope constraints | grep rsc_location

    2. Verifica i vincoli di località:

      • Vincolo di località esplicito: individua i vincoli di località con un punteggio INFINITY (preferisci il nodo) o -INFINITY (evita il nodo). Ad esempio:

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

        Non deve essere presente alcun vincolo di località con punteggio INFINITY o -INFINITY diverso dagli agenti del recinto. In tutti i cluster ad alta disponibilità, gli agenti di recinzione sono definiti in un vincolo di posizione con punteggio -INFINITY per impedire che vengano eseguiti sul nodo che è il target della recinzione.

      • Vincolo di posizione implicito: quando emetti il comando Pacemaker per spostare una risorsa in un nodo del cluster o vietare l'esecuzione di una risorsa su un nodo del cluster, viene aggiunto un vincolo di posizione implicito con prefisso cli-ban o cli-prefer all'ID vincolo. Ad esempio:

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

Soluzione

L'agente di recinto ha riscontrato un errore operativo

L'agente di recinzione ha segnalato un errore nello stato del cluster.

Problema

Nel cluster ad alta disponibilità Linux Pacemaker per SAP HANA o SAP NetWeaver, l'agente di recinzione ha segnalato un errore nello stato del cluster. Ad esempio: 

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

Diagnosi

L'agente fence di cui è stato eseguito il deployment nel tuo cluster ad alta disponibilità SAP HANA o SAP NetWeaver accede regolarmente al server API Compute Engine per controllare lo stato del recinto dell'istanza di destinazione del recinto. Se si verifica un ritardo temporaneo nella risposta alla chiamata API o in caso di interruzione della rete, l'operazione di monitoraggio dell'agente di recinzione potrebbero non riuscire o scadere.

Per controllare lo stato dell'agente di recinzione, esegui il seguente comando:

RHEL 

pcs status

SLES 

crm status

Se lo stato dell'agente di recinto è stopped, utilizza una delle soluzioni opzioni per risolvere l'errore.

L'errore operativo dell'agente di recinto potrebbe causare l'arresto dell'agente, ma Il pacemaker chiama comunque gli agenti della recinzione con una direttiva di interruzione in un evento di recinzione.

Soluzione

Se lo stato dell'agente di recinzione è stopped, esegui una delle seguenti operazioni:

  • Per reimpostare manualmente il valore failcount e riavviare l'agente fencing, esegui il seguente comando:

    RHEL 

    pcs resource cleanup FENCE_AGENT_NAME

    SLES 

    crm resource cleanup FENCE_AGENT_NAME

    Sostituisci FENCE_AGENT_NAME con il nome dell'agente del recinto.

  • Per rimuovere automaticamente l'errore operativo dell'agente di recinzione, configura il parametro failure-timeout.

    Il parametro failure-timeout reimposta il conteggio errori dopo la durata specificata e cancella eventuali errori operativi. L'applicazione di questo parametro non richiede il riavvio del cluster o la sua messa in modalità di manutenzione.

    Per configurare il parametro failure-timeout, esegui il seguente comando:

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

    Sostituisci quanto segue:

    • FENCE_AGENT_NAME: il nome dell'agente di recinzione.
    • DURATION: la durata che segue l'ultimo errore operativo dopo il quale il conteggio errori viene reimpostato e l'agente di recinzione viene riavviato.

L'agente recinto gcpstonith è stato ritirato

L'agente di recinto gcpstonith è attivo nella tua configurazione. Questo agente è stato ritirato e l'Assistenza clienti ti ha comunicato che devi passare a fence_gce.

Problema

Nel cluster ad alta disponibilità Linux Pacemaker per SAP HANA su SUSE Linux viene utilizzato l'agente di recinzione gcpstonith. Ad esempio:

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

Diagnosi

L'agente fence di cui è stato eseguito il deployment nel cluster ad alta disponibilità SAP HANA deve essere è stata aggiornata per utilizzare invece l'agente di fence fence_gce in bundle con il sistema operativo. gcpstonith lo script dell'agente è stato pubblicato su sistemi legacy ed è stato sostituito da fence_gce. fence_gce è fornito nel pacchetto fence-agents SUSE Linux. gcpstonith è stato fornito solo nell'ambito dei deployment di SUSE Linux HANA.

Soluzione

Per eseguire la migrazione da gcpstonith su SUSE Linux, completa i seguenti passaggi:

  1. Installa i seguenti pacchetti aggiuntivi specifici per il tuo sistema operativo:

    • Per SLES 15: python3-oauth2client e python3-google-api-python-client

    • Per SLES 12: python-google-api-python-client, python-oauth2client e python-oauth2client-gce

    Per installare questi pacchetti sul sistema operativo, utilizza il seguente comando:

    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. Aggiorna il pacchetto fence-agents per assicurarti di avere installato la versione più recente:

    zypper update -y fence-agents

  3. Metti il cluster in modalità di manutenzione:

    crm configure property maintenance-mode=true

  4. Elimina tutti i dispositivi di recinzione dal cluster. Durante l'eliminazione dell'ultimo dispositivo di recinzione, potrebbe esserti chiesto di confermare che nel cluster non sono definite risorse STONITH.

    crm configure delete FENCING_RESOURCE_PRIMARY
     
    crm configure delete FENCING_RESOURCE_SECONDARY

  5. Ricrea il dispositivo di recinzione per l'istanza principale:

    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. Ricrea il dispositivo di scherma per l'istanza secondaria:

    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. Imposta i vincoli di località:

    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. Disattiva la modalità di manutenzione del cluster: 

    crm configure property maintenance-mode=false

  9. Controlla la configurazione:

    crm config show related:FENCING_RESOURCE_PRIMARY

  10. Controlla lo stato del cluster:

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

L'agente di risorsa è stato arrestato

L'avvio di un agente delle risorse non è riuscito e rimane nello stato Stopped.

Problema

Nel cluster ad alta disponibilità Linux Pacemaker per SAP HANA o SAP NetWeaver, un agente delle risorse ha segnalato un errore nello stato del cluster. Ad esempio:

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

Diagnosi

In caso di errore di un agente di risorse in esecuzione, Pacemaker tenta di arrestare l'agente e ricominciare da capo. Se l'operazione di avvio non va a buon fine per qualsiasi motivo, Pacemaker imposta il valore failcount della risorsa su INFINITY e tenta di avviare l'agente su un altro nodo. Se l'agente delle risorse non riesce ad avviarsi su nessun nodo, rimane nello stato Stopped.

Per controllare lo stato dell'agente di risorsa, esegui questo comando:

RHEL 

pcs status

SLES 

crm status

Per SAP HANA, l'esempio seguente mostra l'agente di risorsa nel Stato di Stopped sul nodo 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

Soluzione

Se lo stato di un agente di risorsa è Stopped, segui questi passaggi:

  1. Avvia manualmente l'agente di risorse reimpostando il numero di errori:

    RHEL 

    pcs resource cleanup RESOURCE_AGENT_NAME

    SLES 

    crm resource cleanup RESOURCE_AGENT_NAME

    Sostituisci RESOURCE_AGENT_NAME con il nome dell'agente risorsa. Ad esempio rsc_SAPHana_DV0_HDB00.

  2. Assicurati che lo stato dell'agente di risorsa raggiunga lo stato Started: 

    crm_mon

    Se l'agente di risorsa continua a non avviarsi, raccogli le informazioni informazioni diagnostiche pertinenti e contattare l'assistenza.