Esta página foi traduzida pela API Cloud Translation.

Solução de problemas de configurações de alta disponibilidade para SAP
Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

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 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. Por 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ó). Por 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. Por 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. Por 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 de isolamento `gcpstonith` foi descontinuado

O agente de isolamento gcpstonith está ativo na sua configuração. Esse agente foi descontinuado, e o Atendimento ao cliente informou que você precisa mudar para fence_gce.

Problema

No cluster de alta disponibilidade do Linux Pacemaker para SAP HANA no SUSE Linux, o agente de isolamento gcpstonith é usado. Por exemplo:

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

Diagnóstico

O agente de isolamento implantado no cluster de alta disponibilidade do SAP HANA precisa ser atualizado para usar o agente de isolamento fence_gce incluído no SO. O script do agente gcpstonith foi entregue em sistemas legados e foi substituído por fence_gce. fence_gce é fornecido como parte do pacote fence-agents SUSE Linux. gcpstonith só foi entregue como parte das implantações do SUSE Linux HANA.

Solução

Para migrar do gcpstonith no SUSE Linux, siga estas etapas:

Instale os seguintes pacotes específicos para seu sistema operacional:
- Para o SLES 15: python3-oauth2client e python3-google-api-python-client
- Para o SLES 12: python-google-api-python-client, python-oauth2client e python-oauth2client-gce
Para instalar esses pacotes no sistema operacional, use o comando a seguir:
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
```
Atualize o pacote fence-agents para garantir que você tenha a versão mais recente instalada:
```
zypper update -y fence-agents
```

Coloque o cluster no modo de manutenção:

crm configure property maintenance-mode=true

Exclua todos os dispositivos de isolamento do cluster. Ao excluir o último dispositivo de isolamento, talvez seja necessário confirmar que nenhum recurso STONITH foi definido no cluster.
```
crm configure delete FENCING_RESOURCE_PRIMARY
```
```
crm configure delete FENCING_RESOURCE_SECONDARY
```

Recrie o dispositivo de isolamento para a instância principal:

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

Recrie o dispositivo de isolamento para a instância secundária:

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

Defina as restrições de local:

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"

Remova o cluster do modo de manutenção:

crm configure property maintenance-mode=false

Verifique a configuração:

crm config show related:FENCING_RESOURCE_PRIMARY

Verifique o status do cluster:

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

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. Por 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: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

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.

Falha de comunicação entre VMs devido a rotas de rede local para IPs virtuais

O tráfego de rede de uma VM de back-end para outra VM falha devido a rotas de rede local para IPs virtuais.

Problema

Quando as VMs fazem parte de um balanceador de carga de rede de passagem interno, a comunicação de rede de back-end para as rotas de IP virtual (VIP) do ILB é tratada como local e pelo dispositivo de loopback.

Esse comportamento de loopback impede que uma VM de back-end use o VIP do ILB para acessar serviços potencialmente hospedados em outras VMs de back-end que usam o ILB, resultando em uma falha de comunicação.

Por exemplo: falha de comunicação entre ASCS e ERS em um cluster de HA do SAP Netweaver configurado como um back-end de balanceador de carga.

O teste telnet resulta em um erro Connection Refused porque esse roteamento local não permite que o tráfego alcance a VM pretendida:

   [root@test-server-ha ~]# telnet IP_ADDRESS_OF_ILB PORT_NUMBER
   Trying IP_ADDRESS_OF_ILB...
   telnet: connect to address IP_ADDRESS_OF_ILB: Connection refused

Diagnóstico

Pré-requisitos:

As VMs afetadas são listadas como membros de um grupo de instâncias não gerenciadas que são configuradas como um back-end do balanceador de carga.

Quando uma VM de back-end em um balanceador de carga interno (ILB, na sigla em inglês) inicia a comunicação com o IP virtual (VIP) do ILB, ocorre um comportamento de roteamento específico.

Embora o VIP esteja configurado em uma interface de rede padrão, como eth0, e listado na tabela de roteamento local, o kernel roteia pacotes destinados a esse VIP local usando a interface de loopback lo. Esse loopback interno significa que o pacote nunca sai da VM de origem para ser processado pelo ILB.

Embora a comunicação direta entre VMs de back-end usando os IPs individuais funcione, esse comportamento de loopback impede que uma VM de back-end use o VIP do ILB para acessar serviços potencialmente hospedados em outras VMs de back-end usando o balanceador de carga de rede de passagem interna.

   [root@test-server-ha ~]# ip route show table local
   local IP_ADDRESS_OF_ILB dev eth0 proto 66 kernel scope host src IP_ADDRESS_OF_ILB
   local IP_ADDRESS_OF_THE_CURRENT_NODE dev eth0 proto kernel scope host src IP_ADDRESS_OF_THE_CURRENT_NODE
   local IP_ADDRESS_OF_THE_OTHER_NODE dev eth0 proto kernel scope host src IP_ADDRESS_OF_THE_OTHER_NODE
   broadcast IP_ADDRESS dev lo proto kernel scope link src IP_ADDRESS
   local IP_ADDRESS dev lo proto kernel scope host src IP_ADDRESS
   broadcast IP_ADDRESS dev lo proto kernel scope link src IP_ADDRESS

   ip route get IP_ADDRESS_OF_ILB

A saída desse comando mostra uma interface de loopback lo:

   [root@test-server-ha ~]# ip route get IP_ADDRESS_OF_ILB
   local IP_ADDRESS_OF_ILB dev lo src IP_ADDRESS_OF_ILB uid 0
   cache <local>

Solução

Ative a comunicação de back-end entre as VMs modificando a configuração do google-guest-agent, que está incluída no ambiente convidado do Linux para todas as imagens públicas do Linux fornecidas por Google Cloud.

Para ativar as comunicações de back-end do balanceador de carga, siga estas etapas em cada VM que faz parte do cluster:

Interrompa o agente:
```
sudo service google-guest-agent stop
```
Abra ou crie o arquivo /etc/default/instance_configs.cfg para edição:
```
sudo vi /etc/default/instance_configs.cfg
```
No arquivo /etc/default/instance_configs.cfg, especifique as seguintes propriedades de configuração, conforme mostrado. Se as seções não existirem, crie-as. Em particular, verifique se as propriedades target_instance_ips e ip_forwarding estão definidas como falso:
```
[IpForwarding]
ethernet_proto_id = 66
ip_aliases = true
target_instance_ips = false

[NetworkInterfaces]
dhclient_script = /sbin/google-dhclient-script
dhcp_command =
ip_forwarding = false
setup = true
```
Inicie o serviço de agente convidado:
```
sudo service google-guest-agent start
```

Para aplicar as mudanças, reinicie a VM ou siga as etapas abaixo para excluir a rota local.

Exclua a rota local que está enviando tráfego de volta:
```
sudo ip route del table local $(ip route show table local | grep "proto 66" | awk '{print $2}') dev eth0
```
O comando anterior é uma sequência de comandos do Linux conectados para excluir o VIP da tabela de roteamento local. Vamos detalhar cada um deles:

Identificamos o endereço IP usando:
```
ip route show table local | grep "proto 66" | awk '{print $2}'
```
Em seguida, encaminhe para o comando de exclusão real:
```
ip route del table local
```
Reinicie o agente convidado do Google:
```
systemctl google-guest-agent restart
```

Essa mudança não é disruptiva. A reinicialização do google-guest-agent recria uma nova rota de rede que instrui o tráfego de rede a usar eth0 em vez do dispositivo de loopback para enviar tráfego ao VIP.

Para verificar as mudanças,

   ip route get IP_ADDRESS_OF_ILB

A saída desse comando precisa mostrar a interface de rede como eth0 e não a interface de loopback lo:

   [root@test-server-ha ~]# ip route get IP_ADDRESS_OF_ILB
   IP_ADDRESS_OF_ILB via IP_ADDRESS_OF_ILB dev eth0 src IP_ADDRESS_OF_ILB uid 0
   cache

Tente fazer o teste telnet:

   [root@test-server-ha ~]# telnet IP_ADDRESS_OF_ILB PORT_NUMBER
   Trying IP_ADDRESS_OF_ILB...
   Connected to IP_ADDRESS_OF_ILB.
   Escape character is '^]'.

Solução de problemas de configurações de alta disponibilidade para SAP Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Analisar registros do Pacemaker no Cloud Logging

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

Problema

Diagnóstico

RHEL

SLES

RHEL

SLES

Solução

RHEL

SLES

RHEL

SLES

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

Problema

Diagnóstico

Solução

RHEL

SLES

RHEL

SLES

O agente da isolamento teve um erro operacional

Problema

Diagnóstico

RHEL

SLES

Solução

RHEL

SLES

O agente de isolamento gcpstonith foi descontinuado

Problema

Diagnóstico

Solução

SLES 15

SLES 12

O agente do recurso foi interrompido

Problema

Diagnóstico

RHEL

SLES

Solução

RHEL

SLES

Falha de comunicação entre VMs devido a rotas de rede local para IPs virtuais

Problema

Diagnóstico

Solução

Para aplicar as mudanças, reinicie a VM ou siga as etapas abaixo para excluir a rota local.

Para verificar as mudanças,

Solução de problemas de configurações de alta disponibilidade para SAP
Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

O agente de isolamento `gcpstonith` foi descontinuado