Global Traffic Manager
Conceitos do Global Traffic Manager
GTM vs. SLB
R: O Global Traffic Manager (GTM) utiliza o DNS para resolver um nome de domínio em vários endereços IP, distribuindo o tráfego da aplicação ao direcionar os usuários para diferentes endereços IP. Ele também usa verificações de integridade para atualizar dinamicamente a lista de endereços IP nas respostas DNS, o que permite o isolamento de falhas e o failover. O tráfego do usuário final conecta-se diretamente ao endereço IP do service e não passa pelo GTM. Em contraste, o Server Load Balancer (SLB) atua como um proxy para distribuir as solicitações dos usuários para diferentes servidores de backend em tempo real. Todo o tráfego do usuário deve passar pela instância do SLB.
Em geral, utiliza-se o SLB para balanceamento de carga dentro de uma única região. Quando há vários endpoints do SLB em regiões diferentes, é possível usar o GTM para realizar o balanceamento de carga entre eles.
A tabela a seguir compara o GTM e o SLB.
|
Recurso |
Camada de rede |
Endereço de backend |
Round-robin ponderado |
Complexidade entre regiões |
Tempo de failover |
Persistência de sessão |
|
Global Traffic Manager |
Camada 3 |
Nome de domínio, IP |
Suportado |
Simples |
Minutos |
Não suportado |
|
Server Load Balancer |
Camada 4, Camada 7 |
IP |
Suportado |
Complexa |
Segundos |
Suportado |
GTM vs. Alibaba Cloud DNS
R: O Alibaba Cloud DNS fornece services de resolução de nomes de domínio, convertendo nomes de domínio em endereços IP e suportando vários tipos de registros de resolução. O GTM estende a resolução DNS inteligente do Alibaba Cloud DNS com verificações de integridade e failover. Ele direciona os usuários para o endpoint mais próximo com base em sua localização geográfica e monitora o status do service em tempo real.
Domínio de acesso
Vários domínios por instância GTM
R: Depende.
Se vários domínios de service resolverem para o mesmo conjunto de endereços IP, utilize registros CNAME para apontá-los para o mesmo domínio de acesso do GTM. Caso contrário, cada domínio de service exige uma instância GTM separada.
1. Cenário de instância única do GTM
O domínio de service www.example.com resolve para 1.1.XX.XX e 2.2.XX.XX, e você precisa de recuperação de desastres entre eles.
O domínio de service test.example.com também resolve para 1.1.XX.XX e 2.2.XX.XX, sendo necessária a recuperação de desastres entre esses dois endereços IP.
Nesse cenário, ambos os domínios de service resolvem para o mesmo conjunto de endereços IP, portanto, apenas uma instância GTM é necessária. Em seguida, crie um registro CNAME tanto para www.example.com quanto para test.example.com, apontando-os para o domínio de acesso do GTM. Para obter mais informações, consulte {{XREF_0}}.
2. Cenário de múltiplas instâncias GTM
O domínio de service www.example.com resolve para 1.1.XX.XX e 2.2.XX.XX, e a recuperação de desastres é necessária entre esses dois endereços IP.
O domínio de service test.example.com resolve para 1.1.XX.XX e 3.3.XX.XX, e a recuperação de desastres é necessária entre esses dois endereços IP.
Neste caso, os domínios de service resolvem para conjuntos diferentes de endereços IP. É obrigatório adquirir uma instância GTM separada para cada domínio de service.
Acessando domínios CNAME do GTM
R: Sim. O domínio de acesso do GTM é uma URL diretamente acessível. Você também pode usá-lo como valor de um registro CNAME para outros domínios de service voltados ao cliente.
Detecção de falhas do GTM
R: O GTM monitora os services de aplicação a partir de vários nós em todo o mundo. Utilize uma combinação de nós de monitoramento para acionar alertas e determinar a integridade geral de um service. Escolha entre verificações de integridade Ping, TCP ou HTTP(S) para monitorar seus services de aplicação e detectar falhas.
{{XREF_1}}: Determina a falha do service com base na taxa de perda de pacotes e no tempo de resposta.
{{XREF_2}}: Identifica falhas no service analisando o tempo de resposta da porta.
{{XREF_3}}: Avalia a indisponibilidade do service considerando o tempo de resposta e o código de status retornado.
Tempo de failover do GTM
R: Com base em testes extensivos, o GTM Ultimate Edition consegue detectar com precisão uma falha e iniciar um failover em aproximadamente um minuto. O tempo total de recuperação é a soma dos tempos de detecção de falha e de propagação na rede.
A Standard Edition detecta falhas e inicia o failover em cerca de 3 minutos:
Tempo de detecção de falha: Com um intervalo de verificação de integridade de 60 segundos, TTL de 60 segundos e 2 falhas consecutivas, o GTM detecta a falha com precisão e inicia o failover em aproximadamente 3 minutos.
Tempo de propagação em toda a rede: O GTM não garante um tempo específico de propagação em toda a rede. Isso depende das configurações de cache TTL de vários Provedores de Serviços de Internet (ISPs) e das condições da rede.
A Ultimate Edition detecta falhas e inicia o failover em cerca de 1 minuto:
Tempo de detecção de falha: Com um intervalo de verificação de integridade de 15 segundos, TTL de 1 segundo e 3 falhas consecutivas, o GTM inicia o failover em cerca de 1 minuto.
Tempo de propagação em toda a rede: O GTM não garante um tempo específico de propagação em toda a rede. Esse tempo varia conforme as configurações de cache TTL dos diversos ISPs e as condições da rede.
Nomes de domínio em pools de endereços
R: Sim. Um pool de endereços do GTM pode conter endereços IP ou nomes de domínio, mas não é possível misturar ambos no mesmo pool. Se um pool de endereços contiver vários nomes de domínio, o GTM executará a resolução round-robin para eles por padrão.
GTM e DNS inteligente
R: Sim. O GTM integra a resolução DNS inteligente. Use o GTM para executar a resolução DNS inteligente para usuários de diferentes ISPs chineses, 7 regiões, 6 continentes no exterior e países específicos. Isso conecta os usuários ao endpoint de aplicação mais próximo, melhorando a velocidade de acesso.
GTM e persistência de sessão
R: Não. O GTM é um sistema de gerenciamento no nível de DNS. Ele usa respostas DNS para rotear clientes para os endereços de service de aplicação apropriados. Os clientes conectam-se diretamente ao endereço IP da aplicação, sem passar pelo GTM. Portanto, o GTM não visualiza o tráfego HTTP entre o cliente e o servidor, impossibilitando o suporte à persistência de sessão.
Usando o GTM e CDN
R: Sim. Posicione a CDN à frente do GTM. Para obter mais informações, consulte {{XREF_4}}.
CNAMEs de CDN em pools de endereços do GTM
R: É possível, mas não recomendado. As CDNs possuem um vasto número de nós, enquanto o GTM tem um número limitado de nós de verificação de integridade. Essa incompatibilidade pode levar a um monitoramento impreciso e afetar a confiabilidade das verificações de integridade e do failover.
Problemas de resolução DNS (IP antigo ou NXDOMAIN)
R: Os registros DNS do Global Traffic Manager levam algum tempo para entrar em vigor. Aguarde. Se os registros ainda não tiverem efeito após um longo período, execute as seguintes verificações:
Verifique se o TTL expirou: execute
dig www.example.compara visualizar a contagem regressiva do TTL.Confira a configuração do CNAME: execute
dig +trace www.example.com.Limpe o cache DNS local usando o comando apropriado para seu sistema operacional (por exemplo,
ipconfig /flushdnsno Windows).
Falhas na verificação de integridade
R: Se a verificação de integridade falhar consistentemente, mas você confirmou que o service está em execução, siga estas etapas de solução de problemas:
Garanta que seu firewall permita tráfego proveniente dos intervalos de endereços IP de sondagem do GTM.
Teste o caminho de verificação de integridade: execute
curl -H "Host: domain" http://ip:port/path.Analise a carga do servidor e o tempo de resposta.
Falha na consulta CNAME para domínio de acesso com registro A
De acordo com as restrições em {{XREF_5}}, um Access Domain do tipo A suporta pools de endereços dos tipos A e Domain Name. No entanto, ele responde apenas a consultas de registro A. Para responder a consultas CNAME, altere o tipo de acesso do Access Domain para CNAME.
Faturamento
Faturamento para endereços compartilhados
R: As instâncias são faturadas independentemente. Para instâncias por assinatura, o faturamento baseia-se no número de tarefas de sondagem geradas pelo domínio de acesso. Já nas instâncias de pagamento conforme o uso, o cálculo considera a quantidade de sondagens de verificação de integridade geradas pelo domínio de acesso.
Cobranças não intencionais do GTM
R: A causa e a solução para este problema são as seguintes:
Causa: Ao ativar o recurso Health Check para um registro DNS no Alibaba Cloud DNS, o sistema cria automaticamente uma instância GTM de pagamento conforme o uso para implementar o failover do registro, o que gera custos. Instâncias GTM de pagamento conforme o uso são cobradas pelo volume de consultas DNS, sondagens de verificação de integridade e pelo número de domínios de acesso. Qualquer utilização desses recursos sob o modelo de pagamento conforme o uso incorre em cobranças.
Solução:
Faça login no console do GTM e verifique se existem instâncias GTM indesejadas.
Após confirmar que nenhum service depende delas, exclua as instâncias GTM para interromper cobranças futuras.
Ciclo de faturamento: O GTM possui faturamento diário. Se você excluir uma instância hoje, a fatura final referente ao último dia de uso será gerada no dia seguinte. Nenhuma cobrança adicional será gerada a partir do dia posterior.
Observação:
Confirme se foram feitas modificações adicionais na configuração do GTM (como adicionar linhas de resolução ou pools de endereços) para outras finalidades comerciais, evitando a exclusão acidental de uma instância GTM essencial para o seu negócio.
Esta ação exclui a instância GTM, não os registros DNS. Após a exclusão de uma instância GTM, os registros DNS (como registros CNAME) que apontam para o domínio de acesso do GTM deixarão de ser válidos, o que pode tornar seu domínio de service inacessível. Antes de excluir uma instância, avalie o impacto em seus services. Se necessário, atualize primeiro seus registros DNS para apontar para o endereço IP do service de backend.
Edições do Alibaba Cloud DNS e limites de vinculação do GTM
R:
O GTM não possui edição gratuita. O Global Traffic Manager (GTM) é um recurso premium disponível mediante assinatura ou pagamento conforme o uso.
Uso do GTM com a Free Edition do Alibaba Cloud DNS: Se utilizar a Free Edition do Alibaba Cloud DNS, aponte registros CNAME de vários domínios de service para o mesmo domínio de acesso do GTM. Não há limite para a quantidade de domínios de service vinculados.
Limitações: A Free Edition possui um TTL mínimo de 600 segundos. Isso impede o failover no nível de minuto, tornando o tempo de failover maior do que em uma edição paga.
Alto volume de consultas com GTM e DNS pago
R: Sim. O Global Traffic Manager (GTM) e as edições pagas do Alibaba Cloud DNS são products separados. O GTM fornece verificações de integridade e failover, enquanto as edições pagas de DNS oferecem uma cota maior de consultas DNS. Se o número diário de consultas DNS exceder 100.000 (limite da Free Edition), recomendamos adquirir qualquer edição paga do Alibaba Cloud DNS para aumentar sua cota de consultas.
Reembolsos por cobranças acidentais do GTM
R: Geralmente, cobranças decorrentes da ativação não intencional do GTM não são reembolsáveis. Contudo, como cortesia, o suporte ao cliente pode aplicar um cupom como compensação, a seu critério. Caso seja indispensável solicitar um reembolso em dinheiro, envie um ticket para que o caso seja revisado por um gerente de plantão.
Liberação automática agendada
R: Não. As instâncias GTM não suportam liberação automática agendada. Exclua manualmente as instâncias GTM e seus modelos de sondagem associados para interromper o faturamento. Os extratos de faturamento podem sofrer atrasos (geralmente de um dia). A cobrança cessa assim que a instância é excluída.
Alertas
Não recebimento de notificações de alerta
R: Se você não receber as notificações de alerta esperadas, verifique os seguintes itens:
Verifique a regra de alerta: Confirme se a regra de alerta foi criada e está ativada.
Confira o status do contato: Na página de gerenciamento de contatos de alerta, confirme se o número de telefone ou endereço de e-mail do destinatário foi verificado.
Cheque spam ou mensagens bloqueadas: Consulte a pasta de spam do seu e-mail ou a lista de bloqueio de SMS do seu telefone para garantir que a notificação não foi filtrada equivocadamente.
Analise os logs de verificação de integridade: Confirme se uma alteração de status no objeto de alerta (um endereço ou pool de endereços) acionou a regra de alerta.
Acionadores de regras de alerta
R: As regras de alerta são acionadas principalmente por alterações no status da verificação de integridade. Os eventos comuns incluem:
Endereço indisponível: Ocorre quando um endereço falha em um número especificado de verificações de integridade consecutivas.
Endereço recuperado: Disparado quando um endereço anteriormente indisponível volta a ficar disponível.
Pool de endereços indisponível: Ativado quando todos os endereços em um pool tornam-se indisponíveis.
Pool de endereços recuperado: Acontece quando pelo menos um endereço em um pool indisponível retorna à disponibilidade.