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, nel software SAP, nell'infrastruttura Google Cloud o in una combinazione di questi elementi.

Analizzare i log di Pacemaker in Cloud Logging

Il seguente video mostra come iniziare a risolvere i problemi relativi alle configurazioni di 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 ad alta disponibilità Linux utilizza l'agente di recinzione fence_gce e una VM recintata non riesce a rientrare nel cluster dopo un failover, potresti dover ritardare l'avvio del software Corosync al riavvio delle VM recintate.

Problema

Durante un failover, l'agente fence_gce esegue il fencing della VM Compute Engine con errore, che si riavvia e si ricollega al cluster prima che Pacemaker registri l'azione di fencing come completata. Poiché l'azione di recinzione non è 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 recinzione 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 il log di sistema per verificare la presenza dei 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 in modo da assicurarti che l'azione di recinzione abbia il tempo di registrarsi come completata con Pacemaker sul nuovo nodo principale. Imposta inoltre il valore del timeout del riavvio di Pacemaker in modo da tenere conto del ritardo.

Per configurare un avvio ritardato di Corosync:

  1. Metti 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 dell'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:

      • Il 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 dell'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 cluster Linux Pacemaker ad alta disponibilità per SAP HANA o SAP NetWeaver, le risorse come il sistema SAP HANA o i servizi centrali SAP NetWeaver vengono eseguite solo su un determinato nodo del cluster e non eseguono il failover come previsto durante un evento di guasto del nodo.

Di conseguenza, potresti riscontrare problemi come:

  • 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 indica che una determinata 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 di Pacemaker per identificare eventuali vincoli che potrebbero impedire l'esecuzione delle risorse su un determinato nodo del cluster.

    Per controllare la configurazione del vincolo di posizione del pacemaker:

    1. Visualizza i vincoli relativi alla località:

      cibadmin --query --scope constraints | grep rsc_location

    2. Verifica i vincoli di località:

      • Vincolo di località esplicito: puoi trovare i vincoli di località con il 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 devono essere presenti vincoli di località con punteggio INFINITY o -INFINITY diversi dagli agenti di recinzione. 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 recinzione 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 di recinzione di cui è stato eseguito il deployment nel cluster ad alta disponibilità SAP HANA o SAP NetWeaver accede regolarmente al server API Compute Engine per controllare lo stato dell'istanza di destinazione del recinto. Se si verifica un ritardo temporaneo nella risposta alla chiamata dell'API o se si verifica un'interruzione della rete, l'operazione di monitoraggio dell'agente di recinzione potrebbe 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 recinzione è stopped, utilizza una delle opzioni di soluzione per risolvere l'errore.

L'errore operativo dell'agente di recinzione potrebbe causare l'interruzione dell'agente, ma Pacemaker chiama comunque gli agenti di recinzione con una direttiva di arresto 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 è deprecato

L'agente di recinzione 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 di recinzione di cui è stato eseguito il deployment nel cluster SAP HANA ad alta disponibilità deve essere aggiornato in modo da utilizzare l'agente di recinzione fence_gce incluso nel sistema operativo. Lo script dell'agente gcpstonith è stato pubblicato sui sistemi precedenti 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 recinzione 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. Rimuovi il cluster dalla modalità di manutenzione: 

    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 della risorsa è stato interrotto

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

Se un agente di risorse in esecuzione non va a buon fine, Pacemaker tenta di interrompere l'agente e di avviarlo di nuovo. 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 della risorsa non riesce ad avviarsi su nessun nodo, rimane nello stato Stopped.

Per controllare lo stato dell'agente delle risorse, esegui il seguente comando:

RHEL 

pcs status

SLES 

crm status

Per SAP HANA, l'esempio seguente mostra l'agente delle risorse nello stato 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 un agente della risorsa è nello stato Stopped:

  1. Avvia manualmente l'agente delle risorse reimpostando il valore failcount:

    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 della risorsa raggiunga lo stato Started: 

    crm_mon

    Se l'agente delle risorse continua a non avviarsi, raccogli le informazioni di diagnostica pertinenti e contatta l'assistenza.