Testar o endereço IP virtual de um cluster mirror SafeKit na sua rede

Este guia descreve como verificar se o endereço IP virtual (VIP) de um cluster mirror SafeKit (módulo mirror) funciona corretamente na sua rede: o IP virtual (VIP) é detido pelo servidor primário e é redirecionado para o novo servidor primário após uma falha.

1. Princípios-chave

Pré-requisito: ambos os nós do cluster mirror devem estar na mesma sub-rede IP de camada 2: uma LAN ou uma VLAN estendida entre locais remotos.

• O IP Virtual (VIP) está ativo apenas no servidor principal (estados PRIM ou ALONE): é definido como um alias do endereço IP físico, na placa de rede desse endereço, quando o módulo é iniciado como principal no nó (configuração where="one_side_alias").
• O endereço MAC do servidor principal é, portanto, o associado ao IP Virtual (VIP) nas tabelas ARP (router, gateway, clientes na mesma sub-rede). Todo o tráfego para o IP Virtual (VIP) é enviado para o servidor principal.
• Durante uma mudança de servidor (paragem ou falha do servidor principal), o IP Virtual (VIP) é removido do antigo servidor principal e definido como um alias no novo servidor principal. Dois mecanismos permitem então que a rede associe o IP Virtual (VIP) ao endereço MAC do novo servidor principal:
  • as mensagens de rede enviadas pelo sistema operativo quando o IP Virtual (VIP) é adicionado como um alias na placa de rede;
  • os GARPs (gratuitous ARP) enviados pelo SafeKit, quando o atributo arpreroute="on" está configurado na secção <vip>.

O que precisa, portanto, de testar:

1. o IP virtual (VIP) é detido pelo servidor principal e é acessível a partir dos clientes;
2. o endereço MAC associado ao IP Virtual (VIP) é redirecionado para o novo servidor principal na rede (router, gateway, virtualização) quando o servidor principal muda.

2. Pré-requisito: Configuração de IP virtual (VIP)

1. No userconfig.xml do módulo mirror, configure o IP Virtual (VIP) na secção <vip>. O atributo arpreroute="on" faz com que o novo primário envie GARPs após uma falha:

   <vip>
     <interface_list>
       <interface arpreroute="on">
         <real_interface>
           <virtual_addr addr="<VIP>" where="one_side_alias"/>
         </real_interface>
       </interface>
     </interface_list>
   </vip>
   

2. Aplique a configuração em ambos os nós.

3. Inicie o módulo: um nó deve estar em PRIM (Ready) e o outro SECOND (Ready).

3. Teste 1 – Endereço IP virtual (VIP) detido pelo servidor principal

Passos

1. No servidor principal, execute o ipconfig (Windows) ou ip addr show (Linux). → Resultado esperado: o IP Virtual (VIP) aparece como um alias na placa de rede do endereço IP físico.
2. No servidor secundário, execute o mesmo comando. → Resultado esperado: o IP virtual (VIP) não aparece.
3. A partir de uma estação de trabalho cliente fora do cluster, ping ambos os endereços IP físicos e para o IP Virtual (VIP). → Resultado esperado: todos os três comandos ping respondem (a menos que sejam filtrados por firewalls).
4. Verifique o acesso através do IP Virtual (VIP) com o mosaico do SafeKit: a partir de um navegador no cliente externo, ligue-se a http://<VIP>:9010/safekit/mosaic.html (ou use a porta 9453 se o servidor web e a consola do SafeKit tiverem sido configurados para HTTPS), depois introduza o nome do módulo mirror e execute o teste. → Resultado esperado: todas as células do mosaico exibem o nome do servidor principal, numa única cor: todas as ligações TCP ao IP Virtual (VIP) são servidas pelo servidor principal.

4. Teste 2 – Comutação manual de contingência (paragem do primário)

Este teste verifica se o IP Virtual (VIP) segue o servidor principal durante uma falha, acionada pela paragem do módulo no servidor principal.

Passos

1. Pare o módulo no primário (nó 1) a partir da consola SafeKit (ou a partir da linha de comandos com safekit stop -m <module>). → Resultado esperado: o nó 1 passa para STOP (NotReady) e o nó 2 passa para ALONE (Ready). No registo do novo primário, aparece a mensagem “Endereço Virtual IP <VIP> set.
2. Na nova interface principal, execute o ipconfig ou ip addr show. → Resultado esperado: o IP Virtual (VIP) aparece agora como um alias neste nó, e não mais no anterior primário.
3. A partir da estação de trabalho do cliente, repita os três comandos ping e execute o mosaico novamente no IP Virtual (VIP). → Resultado esperado: tudo responde e todas as células do mosaico exibem agora o nome do novo primário, numa única cor.
4. Reinicie o módulo no nó 1: ele resincroniza e vai para SECOND (Ready), enquanto o nó 2 vai para PRIM (Ready).

5. Teste 3 – Verificação do redirecionamento MAC com arp -a

Anote o endereço MAC associado ao IP Virtual (VIP) antes da comutação por falha e, em seguida, verifique se este foi alterado.

Este teste só é possível se a estação de trabalho do cliente estiver na mesma sub-rede IP que o cluster.

Se houver um router entre o cliente e o cluster, a tabela ARP do cliente não contém o IP Virtual (VIP), mas sim o endereço do gateway utilizado para aceder à rede do cluster. Nesse caso, verifique a tabela ARP do router ou gateway com a equipa de rede.

Passos

1. O módulo está PRIM (Ready) no nó 1 e SECOND (Ready) no nó 2.
2. Na estação de trabalho do cliente, ping para os dois endereços IP físicos e para o IP Virtual (VIP), e depois execute arp -a. → Resultado esperado: o IP virtual (VIP) está associado ao mesmo endereço MAC que o endereço IP físico do primário.
3. stop o módulo no primário (nó 1).
4. ping ao IP Virtual (VIP) novamente e, em seguida, execute arp -a novamente. → Resultado esperado: o IP virtual (VIP) está agora associado ao mesmo endereço MAC que o endereço IP físico do novo servidor principal.

ping ao IP Virtual (VIP) novamente antes de ler a tabela ARP: a entrada pode estar marcada como desatualizada e só é atualizada após um ping.

Exemplo da tabela ARP esperada, antes e depois de o servidor principal ser parado:

6. Teste 4 – Verificação completa com Wireshark (Windows) ou tcpdump (Linux)

É possível seguir uma ligação TCP para o IP Virtual (VIP) capturando pacotes no cliente e em ambos os nós: com o Wireshark em máquinas Windows e com o tcpdump em máquinas Linux.

É preciso analisar os cabeçalhos MAC (Ethernet) dos pacotes : o endereço IP de destino permanece o IP Virtual (VIP), e é o endereço MAC de destino que indica qual nó recebe o tráfego.

O que deve observar:

Se a estação de trabalho do cliente estiver numa sub-rede diferente da do cluster, o “MAC do cliente” visível nos nós é o endereço MAC do gateway (router) que liga as duas sub-redes, e não o da estação de trabalho do cliente.

7. De quais estações de trabalho testar

O comportamento depende do caminho da rede entre o cliente e o cluster. Execute os testes 1 e 2 de cada tipo de cliente relevante para a sua arquitetura:

8. Resumo dos resultados esperados

9. Resolução de problemas

• O IP Virtual (VIP) deixa de responder após a comutação por falha: as mensagens de redirecionamento MAC não são tidas em conta por um dispositivo no caminho (router, gateway, switch virtual), que continua a enviar tráfego para o endereço MAC do antigo primário. Verifique o tratamento das mensagens de redirecionamento MAC com a sua equipa de rede.
• Envio de GARPs: o atributo arpreroute="on" da secção <vip> (com arpinterval e arpelapse) envia GARPs regularmente no IP Virtual (VIP) após a falha. Consulte o Guia do Utilizador, secção 13.6.4 " Sintaxe <vip> “.
• Diagnóstico da resolução de IP virtual (VIP) ↔ MAC: consulte o Guia do Utilizador, secção 7.24 " Resolução de problemas de IP virtual (VIP) ↔ MAC " e secção 7.16 " Problema com o IP virtual após a mudança de servidor “.

Para mais informações:

• Como funciona um endereço IP virtual em clusters de alta disponibilidade?
• Para balanceamento de carga com um endereço IP virtual, consulte Testar o endereço IP virtual de balanceamento de carga numa cluster farm SafeKit.