Verificação de acesso usando uma conexão somente leitura explícita

Verifique a conexão com a instância secundária usando uma conexão somente leitura explícita.

Em um nó do cluster, execute o seguinte comando.

sudo -i -u ${sid}adm -- \
    hdbsql -n $VIP_SECONDARY -i $INSTNO -d SYSTEMDB -u SYSTEM \
      "select * from m_host_information \
      where key = 'net_hostnames' or key = 'net_ip_addresses'"

O exemplo de saída mostra que a instrução foi executada no secundário SAP HANA.

HOST,KEY,VALUE
"cl-h4s-2","net_hostnames","cl-h4s-2"
"cl-h4s-2","net_ip_addresses","10.40.10.132,10.40.10.211"
2 rows selected (overall time 7518 usec; server time 291 usec)

Verificação de acesso usando o roteamento de instruções baseado em dicas

Verifique a conexão com a instância secundária usando o roteamento de instruções baseado em dicas.

1. Execute um teste de conexão usando uma conexão explícita com o SAP HANA primary sem uma dica de SQL.

   Em um nó do cluster, execute o seguinte comando.

   sudo -i -u ${sid}adm -- \
       hdbsql -n $VIP_PRIMARY -i $INSTNO -d SYSTEMDB -u SYSTEM \
         "select * from m_host_information \
         where key = 'net_hostnames' or key = 'net_ip_addresses'"
   

   O exemplo de saída mostra que a declaração foi executada no SAP HANA primary.

     HOST,KEY,VALUE
   "cl-h4s-1","net_hostnames","cl-h4s-1"
   "cl-h4s-1","net_ip_addresses","10.40.10.162,10.40.10.201"
   2 rows selected (overall time 5239 usec; server time 361 usec)
   

2. Execute um teste de conexão usando uma conexão explícita com o SAP HANA primary e a dica de SQL result_lag.

   sudo -i -u ${sid}adm -- \
       hdbsql -n $VIP_PRIMARY -i $INSTNO -d SYSTEMDB -u SYSTEM \
         "select * from m_host_information \
         where key = 'net_hostnames' or key = 'net_ip_addresses' \
         with hint(result_lag('hana_sr'))"
   

   O exemplo de saída mostra que a instrução foi executada no secundário SAP HANA.

   HOST,KEY,VALUE
   "cl-h4s-2","net_hostnames","cl-h4s-2"
   "cl-h4s-2","net_ip_addresses","10.40.10.132,10.40.10.211"
   2 rows selected (overall time 40.722 msec; server time 16.428 msec)
   

Test1- Descrição

Simule uma falha da instância primária do banco de dados SAP HANA que está sendo executada em NODE1.

Test1- Pré-requisitos

• Um cluster RHEL HA Add-On funcional de dois nós para replicação do sistema SAP HANA.
• Ambos os nós do cluster estão ativos.
• Cluster que é iniciado em NODE1 e NODE2.
• Cluster Resource SAPHana_${SID}_${INSTNO} que está configurado com AUTOMATED_REGISTER=false.
• Verifique o status do SAP HANA System Replication:
  • O banco de dados primário SAP HANA está sendo executado em NODE1
  • O banco de dados secundário SAP HANA está sendo executado em NODE2
  • SAP HANA A replicação do sistema está ativada e em sincronia

Test1- Procedimento de teste

Crash SAP HANA primary enviando um sinal SIGKILL enquanto o usuário ${sid}adm.

Em NODE1, execute o seguinte comando.

sudo -i -u ${sid}adm -- HDB kill-9

Test1- Comportamento esperado

• SAP HANA a instância primária em NODE1 falha.
• O cluster detecta o banco de dados SAP HANA primário interrompido e marca o recurso como failed.
• O cluster promove o banco de dados secundário SAP HANA em NODE2 para assumir o controle como o novo primário.
• O cluster libera o endereço IP virtual em NODE1 e o adquire no novo primário em NODE2.
• Após o controle, a instância secundária SAP HANA fica indisponível e o endereço IP virtual secundário permanece em NODE2.
• Se um aplicativo, como o SAP NetWeaver, estiver conectado a um banco de dados de locatário do SAP HANA, o aplicativo se reconectará automaticamente ao novo primário.

Test1- Procedimento de recuperação

Como o recurso de cluster SAPHana_${SID}_${INSTNO} está configurado com AUTOMATED_REGISTER=false, o cluster não reinicia o banco de dados SAP HANA com falha e não o registra no novo primário. Isso significa que o status do novo primário ( NODE2 ) também mostra o secundário no status "CONNECTION TIMEOUT".

Para registrar novamente o primário anterior como um novo secundário, use os seguintes comandos.

Em NODE1, execute o seguinte comando.

sudo -i -u ${sid}adm -- \
    hdbnsutil -sr_register \
      --name=${DC1} \
      --remoteHost=${NODE2} \
      --remoteInstance=00 \
      --replicationMode=sync \
      --operationMode=logreplay_readaccess \
      --online

Verifique o status da replicação do sistema:

sudo -i -u ${sid}adm -- \
    hdbnsutil -sr_state

Em um nó do cluster, execute o seguinte comando para atualizar o recurso do cluster. Esse comando inicia a instância secundária.

pcs resource refresh SAPHana_${SID}_${INSTNO}

Quando o secundário atinge o estado sincronizado (SOK), o endereço IP virtual secundário é movido para NODE1.

Em um nó do cluster, execute o seguinte comando para verificar o status do cluster.

pcs status --full

Test2- Descrição

Simule uma falha do nó que está executando o banco de dados primário SAP HANA.

Test2- Preparação

Certifique-se de que o recurso de cluster SAPHana_${SID}_${INSTNO} esteja configurado com AUTOMATED_REGISTER=true.

Em NODE1, execute o seguinte comando.

pcs resource update SAPHana_${SID}_${INSTNO} AUTOMATED_REGISTER=true

Verifique a configuração AUTOMATED_REGISTER na configuração do recurso.

pcs resource config SAPHana_${SID}_${INSTNO} | grep Attributes

Test2- Pré-requisitos

• Um cluster RHEL HA Add-On funcional de dois nós para replicação do sistema SAP HANA.
• Ambos os nós estão ativos.
• O cluster é iniciado em NODE1 e NODE2.
• Verifique o status do SAP HANA System Replication.
  • O banco de dados primário SAP HANA está sendo executado em NODE2
  • O banco de dados secundário SAP HANA está sendo executado em NODE1
  • SAP HANA A replicação do sistema está ativada e em sincronia
  • O endereço IP virtual secundário está ativo em NODE1

Test2- Procedimento de teste

Crash primário em NODE2 enviando uma solicitação de crash do sistema.

Em NODE2, execute o seguinte comando.

sync; echo c > /proc/sysrq-trigger

Test2- Comportamento esperado

• NODE2 é desligado.
• O cluster detecta o nó com falha e define seu estado como OFFLINE.
• O cluster promove o banco de dados secundário SAP HANA em NODE1 para assumir o controle como o novo primário.
• O cluster adquire o endereço IP virtual em NODE1 no novo primário.
• Após o controle, a instância secundária SAP HANA fica indisponível e o endereço IP virtual secundário permanece em NODE1.
• Se um aplicativo, como o SAP NetWeaver, estiver conectado a um banco de dados de locatário do SAP HANA, o aplicativo se reconectará automaticamente ao novo primário.

Test2- Procedimento de recuperação

Faça login no console IBM Cloud® e inicie a instância NODE2. Aguarde até que o site NODE2 esteja disponível novamente e, em seguida, reinicie a estrutura do cluster.

Em NODE2, execute o seguinte comando.

pcs cluster start

pcs status --full

Como um recurso de cluster SAPHana_${SID}_${INSTNO} está configurado com AUTOMATED_REGISTER=true, SAP HANA é reiniciado quando NODE2 entra novamente no cluster e o antigo primário é registrado novamente como secundário. Quando o secundário atinge o estado sincronizado (SOK), o endereço IP virtual secundário é movido para NODE2.

Test3- Descrição

Simule uma falha do banco de dados secundário SAP HANA.

Test3- Pré-requisitos

• Um cluster RHEL HA Add-On funcional de dois nós para replicação do sistema SAP HANA.
• Ambos os nós estão ativos.
• O cluster é iniciado em NODE1 e NODE2.
• O Cluster Resource SAPHana_${SID}_${INSTNO} está configurado com AUTOMATED_REGISTER=true.
• Verifique o status do SAP HANA System Replication:
  • O banco de dados primário SAP HANA está sendo executado em NODE1
  • O banco de dados secundário SAP HANA está sendo executado em NODE2
  • SAP HANA A replicação do sistema está ativada e em sincronia
  • O endereço IP virtual secundário está ativo em NODE2

Test3- Procedimento de teste

Crash SAP HANA secundário enviando um sinal SIGKILL enquanto o usuário ${sid}adm.

Em NODE2, execute o seguinte comando.

sudo -i -u ${sid}adm -- HDB kill-9

Test3- Comportamento esperado

• SAP HANA secundário em NODE2 crashes.
• O cluster detecta o banco de dados secundário interrompido SAP HANA e marca o recurso como failed.
• O cluster move o endereço IP virtual secundário para NODE1.
• O cluster reinicia o banco de dados secundário SAP HANA.
• O cluster detecta que a replicação do sistema está sincronizada novamente.
• O cluster move o endereço IP virtual secundário de volta para NODE2.

Test3- Procedimento de recuperação

Aguarde até que a instância secundária SAP HANA seja iniciada e sincronizada novamente (SOK) e, em seguida, limpe as ações de recursos com falha, conforme mostrado em pcs status.

Em um nó do cluster, execute os seguintes comandos.

pcs resource refresh SAPHana_${SID}_${INSTNO}

pcs status --full

Test4- Descrição

Use os comandos do cluster para mover a instância primária para o outro nó para fins de manutenção.

Test4- Pré-requisitos

• Um cluster RHEL HA Add-On funcional de dois nós para replicação do sistema SAP HANA.
• Ambos os nós estão ativos.
• O cluster é iniciado em NODE1 e NODE2.
• O Cluster Resource SAPHana_${SID}_${INSTNO} está configurado com AUTOMATED_REGISTER=true.
• Verifique o status do SAP HANA System Replication:
  • O banco de dados primário SAP HANA está sendo executado em NODE1
  • O banco de dados secundário SAP HANA está sendo executado em NODE2
  • SAP HANA A replicação do sistema está ativada e em sincronia
  • O endereço IP virtual secundário está ativo em NODE2

Test4- Procedimento de teste

Mova o SAP HANA primário para outro nó usando o comando pcs resource move.

Em um nó do cluster, execute o seguinte comando.

pcs resource move SAPHana_${SID}_${INSTNO}-clone

Saída de amostra:

# pcs resource move SAPHana_H4S_00-clone
Warning: Creating location constraint 'cli-ban-SAPHana_H4S_00-clone-on-cl-hdb-1' with a score of -INFINITY for resource SAPHana_H4S_00-clone on cl-hdb-1.
        This will prevent SAPHana_H4S_00-clone from running on cl-hdb-1 until the constraint is removed
        This will be the case even if cl-hdb-1 is the last node in the cluster

Test4- Comportamento esperado

• O cluster cria restrições de localização para mover o recurso.
• O cluster aciona um takeover para o banco de dados secundário SAP HANA.
• O endereço IP virtual secundário permanece em NODE2.
• Se um aplicativo, como o SAP NetWeaver, estiver conectado a um banco de dados de locatário do SAP HANA, o aplicativo se reconectará automaticamente ao novo primário.

Test4- Procedimento de recuperação

As restrições de local criadas automaticamente devem ser removidas para permitir o failover automático no futuro.

Aguarde até que a instância primária do SAP HANA esteja ativa e remova as restrições.

Em um nó do cluster, execute o seguinte comando.

pcs constraint

pcs resource clear SAPHana_${SID}_${INSTNO}-clone

pcs constraint

O cluster registra e inicia o banco de dados SAP HANA como uma nova instância secundária. Depois que o status de replicação do sistema estiver sincronizado novamente (SOK), o cluster moverá o endereço IP virtual secundário para NODE1.

pcs status --full