Visão Geral
Este guia fornece uma estrutura detalhada de solução de problemas para resolver problemas comuns encontrados durante a implantação do AWS vSocket Alta Disponibilidade (HA). Seja implantando manualmente ou via AWS Marketplace, essas etapas têm como objetivo ajudar a identificar e resolver efetivamente problemas potenciais.
Sintomas
Problemas comuns nas implantações de HA do vSocket AWS podem incluir:
-
Falha no Failover HA
- Testes de API de HA falhos a partir da Interface Web do vSocket.
- Falha no failover HA, resultando em tráfego não sendo encaminhado para o vSocket secundário.
-
Status de HA Não Pronto
- CMA exibe o Status de HA do site como "Não Pronto"
Causas possíveis
Falhas na implantação de HA são frequentemente devido às seguintes causas:
- Uso de DNS não público na AWS.
- Interface de gerenciamento sem acesso à Internet.
- Configuração incorreta do IAM role.
- Configurações restritivas de Grupo de Segurança e Roteamento na AWS.
- Falha ao atribuir a Interface de Rede apropriada à Tabela de Roteamento LAN.
- Problemas de conectividade LAN.
Solução de Problemas do Problema
Importante
IMPORTANTE: Antes de começar a solucionar problemas, certifique-se de que todos os pré-requisitos para implantação do vSocket AWS HA estão verificados. Veja Implantando um Site vSocket AWS Manualmente, Implantando um Site vSocket do AWS Marketplace e Configurando HA para AWS vSockets
Solução de Problemas de Falha no Failover HA
Se o tráfego não está sendo direcionado para o vSocket secundário durante o failover, considere as seguintes etapas de solução de problemas:
Executando o Teste de API de HA
- A partir da Interface Web do vSocket, execute a ferramenta de Teste de API para ambos os vSockets.
- Esta ferramenta valida que a chamada API para AWS pode ser feita com sucesso.
- Qualquer erro relacionado a permissões ou atualizações de tabela de roteamento pode ser visto aqui.
Verificação da Configuração DNS AWS
- Verifique se o servidor DNS AWS padrão está configurado para a VPC associada.
- Para verificar a Configuração DNS da AWS, consulte Corrigindo problemas de configuração de DNS
- Se um servidor DNS personalizado (por exemplo, um servidor DNS privado) estiver configurado, certifique-se de que ele pode resolver domínios públicos. Verifique se ele pode resolver o Nome de domínio totalmente qualificado (FQDN) ec2.<region>.amazonaws.com (por exemplo, ec2.us-east-1.amazonaws.com), que é usado pela API.
- O Grupo de Segurança associado à interface MGMT deve permitir solicitações DNS para 8.8.8.8 e 8.8.4.4, mesmo que o servidor DNS padrão AWS esteja configurado.
Verificação da Tabela de Roteamento LAN
- Para redirecionar o tráfego para o vSocket mestre, a AWS atribui a Interface de Rede LAN do vSocket mestre atual à Tabela de Roteamento LAN.
- Vá para VPC > Tabelas de Roteamento e selecione a Tabela de Roteamento LAN. Na aba Rotas, verifique se a Interface de Rede LAN do vSocket mestre é o gateway (alvo) da rota padrão. Se não for o caso, continue com os próximos passos.
- Observe que modificar manualmente a Tabela de Roteamento LAN pode ser uma solução rápida se a NIC de destino não foi alterada durante o failover.
Verificação do Role IAM
- Durante a implantação do vSocket AWS, a Função IAM HA é criada e associada a ambos os vSockets, principal e secundário.
- Na página de detalhes de cada instância, confirme que a função IAM correta é atribuída.
- Clique no link da Função IAM e, na guia de permissões, verifique se a Política de Implantação da IAM contém a declaração correta, conforme mostrado abaixo.
Nota: Em caso de Função IAM ausente, uma vez que a função seja adicionada, os sockets devem ser reiniciados para que as funções adicionadas entrem em vigor.
Verificação das Configurações IMDS
- Garanta que ambos os vSockets utilizem configurações IMDS correspondentes (opcionais ou obrigatórias). Para mais informações, consulte documentação AWS.
- A partir da build 20.0.18221, vSocket suporta IMDSv2.
- Para modificar as configurações do IMDS, selecione a instância e, em ações, clique em Configurações de Instância > Modificar opções de metadados da instância.
Verificação do Grupo de Segurança de Rede.
- Certifique-se de que o grupo de segurança de rede não está bloqueando o tráfego de saída para a Interface de Gerenciamento.
-
Em EC2 > Interfaces de Rede, encontre o Grupo de Segurança associado à Interface de Gerenciamento.
-
Verifique se as regras de saída do Grupo de Segurança permitem as portas 80, 443 e 53. Neste caso, todo o tráfego de saída é permitido.
Verificando o Roteamento da Interface MGMT para Tráfego de Internet.
- Se o tráfego da interface MGMT estiver roteado através de um firewall de terceiros na AWS, verifique se as conexões de saída UDP/53, TCP/80 e TCP/443 estão permitidas.
-
Na página da interface de rede, clique no ID da Sub-rede da interface MGMT.
-
Na página de Sub-rede, selecione a aba Tabela de Roteamento. A captura de tela abaixo mostra a rota padrão apontando para o Gateway da Internet, então um firewall não está bloqueando o tráfego.
- Abra a Tabela de Roteamento relacionada e verifique se todas as sub-redes MGMT estão listadas como sub-redes associadas. No caso de Zona de Disponibilidade dupla, existirão duas sub-redes MGMT, uma para cada vSocket, conforme explicado em Criando uma Sub-rede para as Interfaces LAN do vSocket Secundário.
- Na aba Mapa de Recursos do VPC, todas as sub-redes associadas e suas configurações de roteamento são visualmente representadas para fácil referência.
- Confirme que um IP elástico está associado à interface MGMT. Isso pode ser visto na aba de rede da instância. A interface MGMT pode ser identificada por seu índice de dispositivo de 0. As interfaces WAN e LAN devem ser associadas aos índices de dispositivo 1 e 2, respectivamente.
Verificando logs do CloudTrail
- Habilite AWS CloudTrail para registrar chamadas de API para AWS para depurar modificações falhadas da tabela de roteamento LAN durante a falha do HA.
- Você pode seguir o processo para criar um trail, definir o bucket S3 para armazenar logs, e selecionar eventos de gerenciamento que incluem atividade de API. Veja Criando um Trail.
Resolução de Problemas de Status de HA Não Pronto
Se a CMA mostrar que o Status de HA está Não Pronto e ambos os vSockets estão ativos e operacionais, ambos os vSockets assumirão o papel de Mestre (cenário split-brain). Isso pode ocorrer devido a:
- Ambos os vSockets estão executando diferentes versões de firmware
- Mensagens de Keepalive de HA não chegam ao vSocket secundário
Recomenda-se verificar as páginas WebUI de ambos os vSockets para confirmar o status de HA de cada um deles. Um cenário de split-brain se manifestará se ambos os vSockets primário e secundário estão 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 atender aos Critérios de versão compatível, ambos os vSockets devem executar 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 não conseguir atualizar, este problema deve ser solucionado. Envie um ticket de Suporte para relatar este problema.
Verificando HA Keepalives
Pacotes de Keepalive usam a porta UDP/20480 para AWS vSocket e serão enviados apenas do vSocket Mestre para o vSocket de Backup. A condição de split-brain ocorre quando ambos os vSockets possuem 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 de Keepalive de 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 da Rede está bloqueando a porta UDP/20480. Um modo rápido de verificar regras NSG é acessar cada interface de rede LAN na AWS e verificar as regras de entrada e saída conforme explicado em Verifique se o Grupo de Segurança de Rede está bloqueando o tráfego de saída.
- Confirme que ambas as interfaces LAN estão associadas a diferentes sub-redes LAN.
- Execute uma captura de pacotes do WebUI de ambos os vSockets e identifique se o vSocket secundário está recebendo os keepalives enviados pelo principal.
Resolução de Problemas Descobertos
Corrigindo problemas de Configuração DNS
- Para corrigir problemas de Configuração DNS, verifique se o servidor DNS padrão da AWS está configurado para o VPC.
- Nos Detalhes do VPC, encontre o conjunto de opções DHCP configurado para ele.
- Abra o conjunto de opções DHCP e verifique se o Nome do Domínio definido é AmazonProvidedDNS.
- Não é possível alterar os servidores de Nome de Domínio existentes. Para isso, crie um novo conjunto de opções DHCP, que usará o AmazonProvidedDNS por padrão.
Cancelando Registro e Reimplantando um AWS vSocket
- Se após seguir todas as etapas de solução de problemas acima, a falha do HA ainda continuar, é possível cancelar o registro e reimplantar um ou ambos os vSockets. Veja Reimplantar Sites de Alta Disponibilidade vSocket
- É importante remover a Máquina Virtual, mas reter as interfaces de rede, IPs Públicos associados e a função IAM antes de reimplantar um vSocket.
- Além disso, lembre-se de reanexar a função IAM correta ao vSocket selecionando a instância do vSocket > Segurança > Anexar Função IAM e atribuindo a função AWS-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 todas as mensagens de erro.
- Configuração DNS na VPC.
- Resultados dos Testes API.
- Capturas de tela da Tabela de Roteamento LAN e das Funções IAM configuradas.
- Se possível, arquivos de log do CloudTrail no momento da falha da transferência por erro.
0 comentário
Por favor, entre para comentar.