Solução de problemas de configurações de alta disponibilidade para SAP

Em configurações de alta disponibilidade para SAP no Google Cloud, a causa raiz dos problemas pode estar no software de clustering, no software SAP, na infraestrutura do Google Cloud ou em alguma combinação deles.

Analisar registros do Pacemaker no Cloud Logging

O vídeo a seguir mostra como começar a solucionar problemas de configurações de alta disponibilidade para SAP no Google Cloud usando o Cloud Logging.

O nó com falha em um cluster do Linux não reinicia corretamente após um failover

Se o cluster de alta disponibilidade do Linux usar o agente de isolamento fence_gce e uma VM isolada não retornar ao cluster após um failover, talvez seja necessário atrasar o início do software Corosync quando as VMs isoladas forem reiniciadas.

Problema

Durante um failover, o agente fence_gce isola a VM do Compute Engine com falha, que reinicia e reingressa no cluster antes que o Pacemaker registre a ação de isolamento como concluída. Como a ação de isolamento não está registrada como concluída, a VM reinicializada encerra os serviços do Pacemaker e do Corosync e deixa o cluster.

Diagnóstico

Para confirmar se este é o problema:

Verifique se o cluster está usando o agente fence_gce:

RHEL

pcs config

SLES

crm config show

A definição do agente de isolamento inclui 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

Verifique as seguintes mensagens no registro do sistema:

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

Solução

Configure os sistemas operacionais nos dois nós de cluster para atrasar o início do Corosync para garantir que a ação de isolamento tenha tempo para se registrar como concluída com o Pacemaker no novo nó principal. Além disso, defina o valor de tempo limite de reinicialização do Pacemaker para considerar o atraso.

Para configurar um início atrasado do Corosync:

Coloque o cluster no modo de manutenção:

RHEL

pcs property set maintenance-mode=true

SLES

crm configure property maintenance-mode="true"

Em cada nó de cluster como raiz, defina um atraso inicial para o Corosync:
1. Crie um arquivo drop-in systemd:
```
systemctl edit corosync.service
```
2. Adicione as seguintes linhas ao arquivo:
```
[Service]
ExecStartPre=/bin/sleep 60
```
3. Salve o arquivo e saia do editor.
4. Atualize a configuração do gerenciador systemd.
```
systemctl daemon-reload
```
Em qualquer nó de cluster como raiz, verifique se o valor de tempo limite do Pacemaker para reinicializações é definido para os dois agentes de isolamento:
1. Verifique o valor pcmk_reboot_timeout:
```
crm_resource --resource FENCE_AGENT_NAME --get-parameter=pcmk_reboot_timeout
```
  Substitua FENCE_AGENT_NAME pelo nome do agente de isolamento.
2. Se o parâmetro pcmk_reboot_timeout não for encontrado ou estiver definido com um valor menor que 300, defina o valor em ambos os agentes de isolamento:
```
crm_resource --resource FENCE_AGENT_NAME --set-parameter=pcmk_reboot_timeout --parameter-value=300
```
  Substitua FENCE_AGENT_NAME pelo nome do agente de isolamento.
  
  O valor pcmk_reboot_timeout precisa ser maior que a soma do:
  - Tempo limite token do Corosync
  - O tempo limite de consenso do Corosync, que por padrão é o produto de token * 1.2
  - Tempo que uma operação de reinicialização leva para ser concluída, incluindo qualquer atributo de atraso.
  No Google Cloud, 300 segundos são suficientes para a maioria dos clusters.
3. Confirme o novo valor pcmk_reboot_timeout:
```
crm_resource --resource FENCE_AGENT_NAME --get-parameter=pcmk_reboot_timeout
```
  Substitua FENCE_AGENT_NAME pelo nome do agente de isolamento.

Remova o cluster do modo de manutenção:

RHEL

pcs property set maintenance-mode=false

SLES

crm configure property maintenance-mode="false"

Afinidade não intencional do nó que favorece um nó específico

Ao mover recursos manualmente em um cluster de alta disponibilidade usando os comandos do cluster, você descobre que uma afinidade automática ou uma preferência de cliente está definida para favorecer um nó específico.

Problema

No cluster de alta disponibilidade do Linux Pacemaker para SAP HANA ou SAP NetWeaver, recursos como o sistema SAP HANA ou os serviços centrais do SAP NetWeaver são executados apenas em um nó de cluster específico e não fazem o failover como esperado durante um evento de falha no nó.

Por isso, você pode enfrentar problemas como:

Quando você aciona o failover do serviço SAP NetWeaver ASCS emitindo um comando do Pacemaker para move, um recurso em um nó do cluster, o recurso não é iniciado e exibe o status stopped.
Quando você emite o comando standby para um nó do cluster a fim de forçar a migração de todos os recursos para o outro nó, os recursos não são iniciados.

Diagnóstico

Verifique nos registros do Pacemaker se a mensagem menciona que um recurso específico não pode ser executado em nenhum lugar. Exemplo:
```
2021-05-24 21:39:58 node_1 pacemaker-schedulerd (native_color) info:
 Resource NW1-ASCS01 cannot run anywhere
```
Verifique a configuração de restrição de local do Pacemaker para identificar quaisquer restrições que possam estar impedindo que os recursos sejam executados em um determinado nó do cluster.

Para verificar a configuração de restrição de local do Pacemaker, siga estas etapas:
1. Mostre as restrições de local:
```
cibadmin --query --scope constraints | grep rsc_location
```
2. Verifique as restrições de local:
  - Restrição de local explícita: você encontra restrições de local com pontuação INFINITY (prefere o nó) ou -INFINITY (evita o nó). Exemplo:
```
<rsc_location id="loc-constraint" rsc="NW1-ASCS01" score="INFINITY" node="nw-ha-1"/>
```
    Não pode haver nenhuma restrição de local com a pontuação INFINITY ou -INFINITY além dos agentes de isolamento. Em todos os clusters de alta disponibilidade, os agentes de isolamento são definidos em uma restrição de local com pontuação -INFINITY para evitar que sejam executados no nó que é o destino de isolamento.
  - Restrição de local implícita: quando você emite o comando do Pacemaker para mover um recurso para um nó do cluster ou proibir que um recurso seja executado em um nó do cluster, uma restrição de local implícita com o prefixo cli-ban ou cli-prefer é adicionado ao código de restrição. Exemplo:
```
<rsc_location id="cli-prefer-NW1-ASCS01" rsc="NW1-ASCS01" role="Started" node="nw-ha-2" score="INFINITY"/>
```

Solução

Verifique se as restrições de local estão especificadas conforme explicado nos nossos guias de implantação:
Para corrigir uma restrição de local explícita, exclua a restrição de local:
RHEL
```
pcs constraint remove RESOURCE_LOCATION_ID
```
SLES
```
crm configure delete RESOURCE_LOCATION_ID
```
Substitua RESOURCE_LOCATION_ID pelo ID de restrição de local.
Para corrigir uma restrição de local implícita, remova todas as restrições definidas no recurso especificado.

Depois de cada comando usado para mover ou proibir um recurso, execute o seguinte comando para remover todas as restrições:
RHEL
```
pcs resource clear RESOURCE_NAME
```
SLES
```
crm resource clear RESOURCE_NAME
```
Substitua RESOURCE_NAME pelo nome do recurso que você está movendo.

O agente da isolamento teve um erro operacional

O agente de isolamento relatou um erro no status do cluster.

Problema

No cluster de alta disponibilidade do Linux Pacemaker para SAP HANA ou SAP NetWeaver, o agente de isolamento relatou um erro no status do cluster. Exemplo:

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

Diagnóstico

O agente de isolamento implantado no cluster de alta disponibilidade do SAP HANA ou SAP NetWeaver acessa regularmente o servidor da API Compute Engine para verificar o status da instância de destino do isolamento. Se houver um atraso temporário na resposta da chamada de API ou uma interrupção de rede, a operação de monitoramento do agente de isolamento poderá falhar ou expirar.

Para verificar o status do agente de isolamento execute o seguinte comando:

RHEL

pcs status

SLES

crm status

Se o status do agente de isolamento for stopped, use uma das opções de solução para resolver o erro.

O erro operacional do agente de isolamento pode fazer com que ele pare, mas o Pacemaker ainda chama os agentes de isolamento com uma diretiva de parada em um evento de isolamento.

Solução

Se o status do agente de isolamento for stopped, siga um destes procedimentos:

Para redefinir manualmente a contagem de falhas e reiniciar o agente de isolamento, execute o seguinte comando:
RHEL
```
pcs resource cleanup FENCE_AGENT_NAME
```
SLES
```
crm resource cleanup FENCE_AGENT_NAME
```
Substitua FENCE_AGENT_NAME pelo nome do agente de isolamento.
Para remover automaticamente o erro operacional do agente de isolamento, configure o parâmetro failure-timeout.

O parâmetro failure-timeout redefine a falha de contagem após a duração especificada e limpa todos os erros operacionais. A aplicação desse parâmetro não exige que você reinicie o cluster ou o coloque no modo de manutenção.

Para configurar o parâmetro failure-timeout, execute o seguinte comando:
```
crm_resource --meta --resource FENCE_AGENT_NAME --set-parameter failure-timeout --parameter-value DURATION
```
Substitua:
- FENCE_AGENT_NAME: o nome do agente de isolamento.
- DURATION: a duração após a última falha operacional. Depois disso, a contagem de falhas é redefinida e o agente de isolamento é reiniciado.

O agente do recurso foi interrompido

Um agente de recursos não foi iniciado e permanece no status Stopped.

Problema

No cluster de alta disponibilidade do Linux Pacemaker para SAP HANA ou SAP NetWeaver, o agente de recursos relatou um erro no status do cluster. Exemplo:

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

Diagnóstico

Se um agente de recursos em execução falhar, o Pacemaker tentará interromper o agente e iniciá-lo novamente. Se a operação de inicialização falhar por qualquer motivo, o Pacemaker definirá a contagem de falhas do recurso como INFINITY e tentará iniciar o agente em outro nó. Se o agente de recursos não for iniciado em qualquer nó, ele vai permanecer no status Stopped.

Para verificar o status do agente de recursos execute o seguinte comando:

RHEL

pcs status

SLES

crm status

Para o SAP HANA, o exemplo a seguir mostra o agente de recursos no status Stopped no nó 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

Solução

Se um agente de recursos tiver o status Stopped, faça o seguinte:

Inicie manualmente o agente de recursos redefinindo a contagem de falhas:
RHEL
```
pcs resource cleanup RESOURCE_AGENT_NAME
```
SLES
```
crm resource cleanup RESOURCE_AGENT_NAME
```
Substitua RESOURCE_AGENT_NAME pelo nome do agente de recurso. Por exemplo, rsc_SAPHana_DV0_HDB00.
Verifique se o status do agente de recursos atinge o status Started:
```
crm_mon
```
Se o agente de recursos ainda não for iniciado, colete as informações de diagnóstico relevantes e entre em contato com o suporte.