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.

Analizza i log di Pacemaker in Cloud Logging

Il video seguente mostra come iniziare a risolvere i problemi relativi alle configurazioni ad alta disponibilità per SAP su Google Cloud utilizzando Cloud Logging.

Un nodo in errore 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 protetta non riesce a rientrare nel cluster dopo un failover, potrebbe essere necessario ritardare l'avvio del software Corosync al riavvio delle VM protette.

Problema

Durante un failover, l'agente fence_gce blocca la VM di Compute Engine non riuscita, che si riavvia e si riconnette al cluster prima che Pacemaker registri l'azione di fence come completata. Poiché l'azione di recinzione non è registrata come completata, la VM riavviata arresta i servizi Pacemaker e Corosync e lascia il cluster.

Diagnosi

Per verificare se è questo il 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 il log di sistema per verificare se 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 e assicurarti che l'azione di recinzione abbia il tempo di registrarsi come completata con Pacemaker sul nuovo nodo primario. Imposta inoltre il valore di timeout di riavvio del Pacemaker per tenere conto del ritardo.

Per configurare un avvio ritardato di Corosync:

Attiva la modalità di manutenzione per il cluster:

RHEL

pcs property set maintenance-mode=true

SLES

crm configure property maintenance-mode="true"

Su ciascun nodo del cluster come root, imposta un ritardo di avvio per Corosync:
1. Crea un file all'interno del campo 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 di sistema.
```
systemctl daemon-reload
```
Su entrambi i nodi del cluster come root, verifica che il valore di timeout di Pacemaker per i riavvii sia impostato per entrambi gli agenti di fence:
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 fence:
```
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 Corosync token
  - Il timeout del consenso Corosync, che per impostazione predefinita è il prodotto di token * 1,2
  - Il periodo di 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.

Disattiva la modalità di manutenzione del cluster:

RHEL

pcs property set maintenance-mode=false

SLES

crm configure property maintenance-mode="false"

Affinità nodo involontaria che favorisce un particolare nodo

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

Problema

Nel tuo cluster Linux Pacemaker ad alta disponibilità per SAP HANA o SAP NetWeaver, risorse come il sistema SAP HANA o i servizi centrali SAP NetWeaver vengono eseguite su un solo nodo del cluster 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 inviando un comando Pacemaker per move una risorsa in un nodo del cluster, la risorsa non viene avviata e mostra lo stato stopped.
Quando invii il comando standby a un nodo del cluster per forzare lo spostamento di tutte le risorse sull'altro nodo, le risorse non si avviano.

Diagnosi

Controlla nei log di Pacemaker 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 località di Pacemaker per identificare eventuali vincoli che potrebbero impedire l'esecuzione delle risorse su un determinato nodo del cluster.

Per verificare la configurazione del vincolo di località di Pacemaker, segui questi passaggi:
1. Visualizza i vincoli di località:
```
cibadmin --query --scope constraints | grep rsc_location
```
2. Verifica i vincoli di località:
  - Vincolo di località esplicita: trovi vincoli di località con 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 esserci vincoli di località con punteggio INFINITY o -INFINITY ad eccezione degli agenti di recinzione. In tutti i cluster ad alta disponibilità, gli agenti di recinzione sono definiti in un vincolo di località con punteggio -INFINITY, per impedirne l'esecuzione sul nodo che è la destinazione del recinto.
  - Vincolo di località implicita: quando invii il comando Pacemaker per spostare una risorsa in un nodo del cluster o escludere una risorsa per l'esecuzione su un nodo del cluster, all'ID del vincolo viene aggiunto un vincolo di località implicito con prefisso cli-ban o cli-prefer. Ad esempio:
```
<rsc_location id="cli-prefer-NW1-ASCS01" rsc="NW1-ASCS01" role="Started" node="nw-ha-2" score="INFINITY"/>
```

Soluzione

Assicurati che i vincoli di località siano specificati come spiegato nelle nostre guide al deployment:
Per correggere un vincolo di località esplicito, eliminalo:
RHEL
```
pcs constraint remove RESOURCE_LOCATION_ID
```
SLES
```
crm configure delete RESOURCE_LOCATION_ID
```
Sostituisci RESOURCE_LOCATION_ID con l'ID vincolo della località.
Per correggere un vincolo di posizione implicito, rimuovi tutti i vincoli definiti nella risorsa specificata.

Dopo ogni comando che utilizzi per spostare o escludere una risorsa, esegui questo comando per rimuovere tutti i vincoli:
RHEL
```
pcs resource clear RESOURCE_NAME
```
SLES
```
crm resource clear RESOURCE_NAME
```
Sostituisci RESOURCE_NAME con il nome della risorsa che stai spostando.

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 fence 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 tuo cluster ad alta disponibilità SAP HANA o SAP NetWeaver accede regolarmente al server dell'API Compute Engine per verificare lo stato dell'istanza di destinazione del fence. Se si verifica un ritardo temporaneo nella risposta alla chiamata API o se si verifica un'interruzione di rete, l'operazione di monitoraggio dell'agente fence potrebbe non riuscire o andare in timeout.

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

RHEL

pcs status

SLES

crm status

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

L'errore operativo dell'agente di recinzione potrebbe causare l'arresto dell'agente di recinzione, ma Pacemaker continua a chiamare gli agenti con una direttiva di interruzione in un evento di scherma.

Soluzione

Se lo stato dell'agente di recinto è stopped, procedi in uno dei seguenti modi:

Per reimpostare manualmente il numero di failcount e riavviare l'agente di recinzione, esegui questo comando:
RHEL
```
pcs resource cleanup FENCE_AGENT_NAME
```
SLES
```
crm resource cleanup FENCE_AGENT_NAME
```
Sostituisci FENCE_AGENT_NAME con il nome dell'agente di fence.
Per rimuovere automaticamente l'errore operativo dell'agente di recinto, configura il parametro failure-timeout.

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

Per configurare il parametro failure-timeout, esegui questo 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 successiva all'ultimo guasto operativo dopo la quale il conteggio degli errori viene reimpostato e l'agente di recinto viene riavviato.

L'agente risorsa è stato arrestato

Un agente risorsa non è riuscito ad avviarsi e rimane nello stato Stopped.

Problema

Nel tuo cluster Linux Pacemaker ad alta disponibilità per SAP HANA o SAP NetWeaver, un agente risorsa 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 risorsa in esecuzione non riesce, il Pacemaker tenta di arrestare l'agente e di avviarlo di nuovo. Se per qualsiasi motivo l'operazione di avvio non riesce, Pacemaker imposta il conteggio degli errori delle risorse su INFINITY e tenta di avviare l'agente su un altro nodo. Se l'agente risorsa non si avvia su qualsiasi nodo, lo stato dell'agente risorsa rimane Stopped.

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

RHEL

pcs status

SLES

crm status

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

Soluzione

Se un agente della risorsa è in stato Stopped:

Avvia manualmente l'agente risorsa 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.
Assicurati che lo stato dell'agente risorsa raggiunga lo stato Started:
```
crm_mon
```
Se l'agente della risorsa continua a non avviarsi, raccogli le informazioni diagnostiche pertinenti e contatta l'assistenza.