Visão geral #

Este guia fornece uma abordagem estruturada para validar e solucionar problemas de configurações GSLB (Balanceamento de Carga Global do Servidor / GTM) em RELIANOID ambientes, particularmente quando se espera que os serviços sejam transferidos automaticamente de ambientes locais para sites de recuperação de desastres (DR).

Inclui também as melhores práticas para IPs públicos baseados em aplicações e serviços GSLB internos.

Escopo de validação #

Este guia aplica-se a:

• Implantações GSLB com vários sites (local + DR)
• Serviços expostos através de IPs públicos
• Failover baseado em DNS usando RELIANOID GSLB
• Cenários de failover automático baseados em verificações de integridade

Componentes-chave a serem validados #

Antes de solucionar problemas relacionados ao comportamento em caso de falha, verifique o seguinte:

Configuração GSLB #

• O serviço GSLB está configurado corretamente com:
  • Vários sites de backend (local + recuperação de desastres)
  • Políticas de resolução corretas (prioridade, latência, etc.)
• A zona DNS e os registros estão definidos corretamente.

Verificações de saúde #

• Os exames de saúde são:
  • Habilitado para todos os serviços de back-end.
  • Direcionar corretamente os endpoints da aplicação (e não apenas IP/porta)
• Os códigos de resposta esperados ou a validação de conteúdo estão configurados.

Configuração DNS #

• Os valores de TTL estão configurados adequadamente (recomenda-se um TTL baixo para failover).
• O DNS autoritativo está apontando para RELIANOID GSLB

Validação de failover do ambiente local para o ambiente de recuperação de desastres #

Etapa 1: Confirme o funcionamento normal (primário ativo) #

• Consultar resolução de DNS:

  escavação

• Verifique se:
  • O endereço IP resolvido corresponde ao site local.
  • O aplicativo é acessível e saudável.

Etapa 2: Simular falha #

Provocar uma condição de falha no site principal:

• Interrompa os serviços de backend
• endpoint de verificação de integridade do bloco
• Desative a fazenda ou o backend

Etapa 3: Validar a detecção da verificação de integridade #

• Confirmar RELIANOID marca o site principal como DESATIVADO
• Verifique os registros e o monitoramento para garantir:
  • As verificações de saúde estão falhando, como esperado.
  • Sem falsos positivos/negativos

Etapa 4: Validar o failover de DNS #

• Executar novamente a consulta DNS:

  escavação

• Resultado esperado:
  • O endereço IP agora deve ser resolvido para o site de recuperação de desastres.

Nota: O armazenamento em cache do DNS pode atrasar a propagação dependendo do TTL.

Etapa 5: Validar a disponibilidade do aplicativo #

• Acesse o aplicativo usando o IP de recuperação de desastres resolvido.
• Confirme:
  • O aplicativo está totalmente funcional.
  • Sem problemas de dependência (banco de dados, APIs, etc.)

Problemas comuns e solução de problemas #

Failover não acionado #

• Verificações de saúde muito permissivas (por exemplo, validação TCP em vez de HTTP)
• Ponto final de verificação de integridade incorreto
• O servidor ainda responde parcialmente.

FixarUtilize verificações em nível de aplicação (status HTTP, corpo da resposta)

O DNS ainda resolve para o diretório primário. #

• TTL muito alto
• Cache de DNS do lado do cliente
• Servidores DNS recursivos não atualizados

Fixar:

• TTL mais baixo (por exemplo, 30 a 60 segundos)
• Limpar o cache DNS local
• Teste com resolvedores externos (dig @8.8.8.8)

O site DR não está exibindo tráfego. #

• O backend de recuperação de desastres não está configurado corretamente.
• Dependências ausentes (banco de dados, armazenamento, autenticação)
• Problemas de firewall ou roteamento

FixarValide a prontidão de toda a pilha de recuperação de desastres, não apenas do balanceador de carga.

Falha intermitente (oscilação) #

• Exames de saúde instáveis
• Latência de rede ou perda de pacotes
• Respostas inconsistentes do servidor

Fixar:

• Ajuste os intervalos e limites das verificações de integridade.
• Aumentar a tolerância a falhas

Considerações sobre IP público baseado em aplicações #

Ao usar IPs públicos por site:

• Garanta que cada site anuncie seu próprio IP público.
• O GSLB deve retornar o IP correto para cada site.
• Validar:
  • Regras de NAT e firewall
  • Certificados SSL por endpoint
  • Comportamento consistente do aplicativo em todos os sites

Diretrizes para Serviços Internos do GSLB #

Para serviços exclusivamente internos (DNS privado / aplicativos internos):

Configuração DNS #

• Utilize servidores DNS internos integrados com RELIANOID GSLB
• Garantir que os clientes resolvam seus problemas através dos mecanismos internos corretos.

Considerações de rede #

• Verificar roteamento entre sites (VPN/MPLS)
• Garanta que o site de recuperação de desastres seja acessível a partir de todas as redes do cliente.

Verificações de saúde #

• Utilize endpoints internos (IPs privados)
• Validar respostas da camada de aplicação

Evitar a Síndrome do Cérebro Dividido #

• Garantir a sincronização adequada entre os nós do GSLB
• Evite cenários em que ambos os sites sejam considerados ativos incorretamente.

Melhores Práticas #

• Use valores TTL baixos para uma recuperação de falhas mais rápida.
• Utilize sempre verificações de integridade no nível da aplicação.
• Realize regularmente simulações de contingência.
• Monitore a resolução de DNS globalmente
• Garantir a paridade de configuração entre o servidor primário e o de recuperação de desastres (DR).

Lista de verificação de validação #

[ ] Serviço GSLB configurado com todos os sites
[ ] Exames de saúde validados e confiáveis
[ ] TTL configurado adequadamente
[ ] Ambiente de recuperação de desastres totalmente operacional
[ ] Failover de DNS testado e confirmado
[ ] Aplicação testada após falha
[ ] Serviços internos validados (se aplicável)

Resumo #

Validação adequada de RELIANOID O GSLB garante uma transição automática e perfeita de ambientes locais para ambientes de recuperação de desastres (DR), minimizando o tempo de inatividade e mantendo a continuidade do serviço.

Uma implementação bem-sucedida requer coordenação entre:

• Configuração de DNS
• Verificações de saúde
• Preparação da candidatura
• Design de rede