Resolução de Problemas do vSocket HA do Azure

Visão Geral

Este artigo fornece insights sobre problemas comuns de implantação do vSocket HA do Azure e oferece etapas de solução de problemas para resolvê-los. Este guia visa ajudar a identificar e resolver possíveis obstáculos durante e após a implantação da solução HA, seja via script HA ou Marketplace.

Sintomas

Ao implantar o vSocket HA do Azure, você pode encontrar os seguintes sintomas:

• Falha no Script HA
  • Falha na execução do script create_ha_settings na implantação manual.
  • Problemas com a implantação do vSocket secundário via Marketplace.
• Falha na Conmutação por erro do HA
  • Testes API HA falharam a partir da Interface Web do Socket.
  • Falha da conmutação por erro do HA resultando no trânsito que não está sendo roteado para o vSocket secundário.
• Status HA Não Pronto
  • CMA mostra que o status HA do Local não está pronto

Causas Possíveis

As causas mais comuns de falhas de implantação do HA incluem:

• Uso de DNS não públicos no Azure.
• Interface de Gerenciamento sem acesso à Internet.
• Permissões insuficientes da conta Azure.
• Configurações restritivas de Grupo de Segurança e Roteamento no Azure.
• Falha ao atribuir o endereço IP Flutuante à interface LAN.
• Problemas de conectividade LAN.

Resolução de Problemas da Questão

Solucionando Falha no Script HA

O script HA do Azure (create_ha_settings) e a implantação do vSocket secundário via Marketplace validam se a assinatura Azure possui dois vSockets válidos e então atribuem as Funções de Identidade que criam o mecanismo HA e de conmutação por erro. Se a execução do script falhar, siga estas etapas de solução de problemas:

Verificação de Logs de Atividade

• No Azure, os Logs de Atividade armazenam todos os eventos que acontecem dentro de cada recurso do Azure. Revise esses logs se a implantação não for bem-sucedida e uma das funções não for atribuída. Navegue para a VM ou a NIC e selecione o log de atividade
  

Verificação de Restrições de Nomeação do Azure 

• Ao inserir o Nome do vSocket no script, certifique-se de que o nome não inclua espaços ou caracteres restritos, conforme explicado em Regras e restrições de nomeação.
• Se ocorrer um problema de nomeação durante a implantação, o seguinte erro será mostrado no log de Erro

  O valor do parâmetro disk.name é inválido. (Código: InvalidParameter, Alvo: disk.name)

Verificação de Configuração DNS Azure

• Certifique-se de que o DNS Padrão Azure esteja configurado tanto para o VNET quanto para os NICs associados. Se o DNS padrão não estiver configurado no Azure, tanto no VNET quanto no NIC, a criação da Função falhará.
• Para verificar o que é a configuração do DNS Azure, veja Corrigindo problemas de configuração DNS 
  

Verificação de Permissões Azure

• Para executar com sucesso o script HA, certifique-se de que o usuário Azure tenha permissões de proprietário. Vá para Grupo de Recurso > Controle de Acesso IAM > Ver Meu Acesso, e verifique se a conta de usuário está definida como Proprietário ou função superior. Veja Funções integradas do Azure.
  
  
  

Verificando a Atribuição de Função do Azure 

• Execute as etapas fornecidas em Verificando a Atribuição de Função do Azure para confirmar que a função de identidade listada no grupo de recursos foi atribuída aos NICs LAN, sub-rede LAN e ambas as VMs vSocket.

Reexecutando o script HA

• Como último recurso, o script HA (create_ha_settings) pode ser reexecutado após a verificação das etapas anteriores.
• Certifique-se de renovar o token do Azure e remover a Identidade Gerenciada do Azure se foi criada durante a primeira execução do script.

Resolução de Problemas de Falha na Conmutação por erro do HA

Se o script HA for executado com sucesso, mas a conmutação por erro do vSocket HA não ocorrer conforme esperado (por exemplo, o tráfego não é roteado para o vSocket secundário), siga estas etapas:

Executar Teste API HA

• A partir da Interface Web do vSocket, execute a ferramenta de Teste API de ambos os vSockets, que valida que a chamada API para Azure pode ser feita com sucesso. Quaisquer erros com Permissões ou atribuições de IP Flutuante podem ser visualizados aqui.
  

Verificando o log de Atividade

• No Azure, os Logs de Atividade armazenam todos os eventos que ocorreram dentro de cada recurso do Azure. Revise esses logs para identificar se o IP Flutuante falhou ao ser enviado para a NIC LAN ou se o Teste de API não foi bem-sucedido. Procure pela NIC e selecione o log de atividade
  

Pingando o IP Flutuante

• A partir da Interface Web do vSocket, utilize a ferramenta de Ping, selecione a interface LAN e pingue o Endereço IP Flutuante. Se o teste não for bem-sucedido, continue com Verificando a atribuição de IP Flutuante
  

Verificando a atribuição de IP Flutuante

• Para rotear o tráfego para o mestre vSocket, o Azure atribui o IP Flutuante à NIC LAN do mestre vSocket atual. Vá para a VM Principal do vSocket LAN NIC > Configuração de IP e verifique se o IP Flutuante existe como "Secundário". Se não, continue com os próximos passos.

Verificando a Atribuição de Função no Azure 

• Durante a implantação do vSocket Azure, a Função de Identidade de HA é criada e armazenada em Identidades Gerenciadas do Azure.
• Apenas um usuário atribuído deve ser atribuído a cada recurso. Se uma Política adicionar identidades atribuídas ao sistema no Azure, as vSockets devem ser excluídas dela.

• Esta Função é atribuída aos diferentes recursos virtuais que estão associados ao vSocket. Os componentes na infraestrutura do Azure que usam essa Função são:

  • Interface de Rede (NIC) LAN para cada vSocket
  • A sub-rede LAN associada às NICs LAN
  • Ambas as VMs vSocket
• A atribuição de Função para as NICs pode ser verificada em Controle de Acesso > Atribuições de Função e deve ser atribuída para ambas as NICs LAN Principal e Secundária.
  
• A atribuição de Função para a sub-rede LAN pode ser verificada em VNET > Sub-rede, depois selecione a sub-rede LAN e clique em Gerenciar usuários > Atribuições de Função
  
• Para cada VM de vSocket, a função de identidade pode ser verificada em Segurança > Identidade > Usuário atribuído como você pode ver na captura de tela abaixo. Nenhuma função atribuída ao sistema deve ser atribuída à VM.
• Se a função de identidade de HA não estiver instalada em nenhum dos recursos acima, o processo de implantação pode ter falhado ao fazê-lo. Você pode executar o script de HA da Cato novamente se a função estiver ausente em qualquer um dos recursos envolvidos. Alternativamente, o vSocket secundário do Azure pode ser reimplantado , o que instalará as funções de identidade de HA ausentes.

Verificando se a interface de Gerenciamento possui Acesso à Nuvem e à Internet

• Verifique se a interface de gerenciamento possui Acesso à Nuvem e pode se conectar ao servidor DNS configurado.

• Verifique a resolução DNS para management.azure.com a partir do Portal Azure. A chamada de API de HA usa este Nome de domínio totalmente qualificado.

  • Vá para Máquina Virtual > vSocket > Executar comando > RunShellScript
  • Digite dig management.azure.com na caixa de texto
  • Clique em Executar
• A saída do dig será exibida no portal com uma resposta DNS.
  
  
• Se não houver resolução DNS, consulte Resolvendo problemas de configuração de DNS.
• Na mesma página, tente acessar qualquer recurso da internet para confirmar o Acesso à Nuvem. Por exemplo, ping -c 4 8.8.8.8 Se o ping não for bem-sucedido, continue com os próximos passos.
  

Verifique se o Grupo de Segurança da Rede está bloqueando o tráfego de Saída.

• Uma maneira rápida de verificar é ir para a interface de rede MGMT no Azure e clicar em "Regras de segurança eficazes" na parte inferior esquerda da tela.
• A captura de tela abaixo mostra que nenhum NSG está atribuído, portanto, o tráfego de saída não está bloqueado.

Verifique o Roteamento de Interface MGMT para o Tráfego de Internet.

• Caso o tráfego da interface MGMT seja roteado através de um firewall de terceiros no Azure, verifique se as conexões de saída UDP/53 e TCP/443 estão permitidas.
• A tabela de roteamento pode ser revisada na página da interface de gerenciamento no Azure clicando na opção "Roteamento eficaz".
• A captura de tela abaixo mostra a rota para o tráfego da Internet usando a Internet como o "Tipo de Próximo Salto", então um firewall não está bloqueando o tráfego.
  

Verificando o Próximo Salto da Tabela de Roteamento

• Confirme que a tabela de roteamento LAN está apontando para o IP Flutuante. Altere o Endereço IP do Próximo Salto conforme necessário.

Solucionando Problemas de Status HA Não Pronto

Se o CMA mostrar que o Status HA não está pronto e ambos os vSockets estão em execução, ambos os vSockets assumirão o papel de Mestre (cenário de split-brain). Pode haver dois problemas associados:

• Ambos os vSockets estão executando versões de firmware diferentes
• Mensagens de Keepalive HA não chegam ao vSocket secundário

Recomenda-se verificar as páginas WebUI de ambos os vSockets para confirmar o status HA de cada um deles. Um cenário de split-brain se manifestará se ambos vSockets primário e secundário estiverem em um papel de Mestre. O WebUI mostrará o papel atual no topo da página principal de Monitoramento.

Verificando versões de firmware

Para satisfazer os critérios de versão compatível, ambos os vSockets devem estar executando a mesma versão MAJOR, por exemplo, v17.xx.yy ou v18.xx.yy. Os vSockets realizam uma atualização inicial após serem implantados pela primeira vez. Se um dos vSockets falhar em atualizar, este problema deve ser solucionado. Envie um ticket de suporte para relatar este problema.

Verificação dos Keepalives HA

Pacotes Keepalive usam a porta UDP/20480 para vSocket Azure e serão enviados apenas do vSocket Mestre para o vSocket em Backup. A condição de split-brain ocorre quando ambos os vSockets têm o papel de Mestre, o que pode acontecer devido a problemas de conectividade LAN entre os vSockets que criam uma situação em que as mensagens Keepalive HA não chegam ao vSocket Secundário. 

Execute as seguintes verificações para confirmar a conectividade LAN:

• Verifique se o Grupo de Segurança de Rede está bloqueando a porta UDP/20480. Uma maneira rápida de verificar as regras NSG é ir a cada interface de rede LAN no Azure e clicar em "Regras de segurança eficazes" na parte inferior esquerda da tela.
• Confirme que ambas as interfaces LAN estão associadas à mesma sub-rede LAN.
• Execute uma captura de pacotes a partir do WebUI de ambos os vSockets e identifique se os keepalives enviados pelo primário estão sendo recebidos pelo vSocket secundário.

Resolvendo Problemas Descobertos

Renovando token do Azure

• Se o Azure Cloud Shell for usado para implantar o script HA, abra uma nova sessão e reautentique. Isso renovará o token usado para consultar a API.
  

Corrigindo problemas de configuração DNS

• Para corrigir a configuração do DNS do Azure e defini-la para o valor padrão, vá para Rede virtual > Servidores DNS e para Interface de Rede > Servidores DNS, e certifique-se de que está usando a opção Padrão ou um servidor DNS público. Desligue a VM para fazer quaisquer alterações relacionadas ao DNS e depois ligue-a novamente.
  
  

Cancelando registro e reimplantando um vSocket Azure

• Se, após seguir todas as etapas de solução de problemas acima, o script HA ou a falha HA continuar a falhar, é possível cancelar o registro e reimplantar um ou ambos os vSockets. Consulte Reimplantar Sites de Alta Disponibilidade vSocket
• É importante seguir as diretrizes e remover a Máquina Virtual, interfaces de rede, IPs públicos associados e Identidade Gerenciada antes de reimplantar um vSocket.
• Se apenas a instância primária do vSocket for reimplantada, você deve executar o script HA dedicado (create_ha_settings) para vincular ambas as instâncias de vSocket para HA.

Levantando casos para o Suporte Cato

Envie um ticket de suporte com os resultados das etapas de solução de problemas acima. Por favor, inclua as seguintes informações no ticket:

• Uma descrição clara do problema, incluindo quaisquer mensagens de erro.
• Resultados do teste DNS para management.azure.com
• Resultados do teste API.
• Capturas de tela do IP Flutuante atribuído e das funções de identidade configuradas.
• Capturas de tela do log de atividade do Azure, incluindo quaisquer erros encontrados.