Global Accelerator:Global Accelerator FAQ

Quais são os principais casos de uso do GA?

O GA pode ser usado para acelerar o acesso a sistemas de Automação de Escritório (OA), aplicações de internet e servidores de jogos. Para mais informações, consulte Scenarios.

O GA pode acelerar o acesso a service de backend implantados em outra conta da Alibaba cloud?

Não diretamente.

Os clientes podem usar diretamente o CNAME de uma instância do GA para acesse service de backend?

Não.

O CNAME do GA é usado apenas para identificar o servidor de source do service de backend e não possui registro ICP. Os clientes não podem usar o CNAME do GA para acelerar diretamente o acesso ao service de backend.

Se quiser usar o CNAME do GA para acelerar o acesso a um service de backend, adicione um registro CNAME na sua plataforma de dns para mapear o nome de domínio do service de backend para o CNAME do GA. Para mais informações, consulte Accelerate access to backend services that are associated with a specific domain name.

O CNAME de uma instância do GA oferece suporte à resolução dns específica por região?

Sim.

Você pode configure um registro CNAME na sua plataforma de dns para mapear o nome de domínio para o CNAME do GA. Quando um cliente acessa o service de backend usando o nome de domínio, o GA resolve automaticamente o nome de domínio para o endereço IP acelerado correspondente à região do cliente.

Como os endereços IP acelerados do GA são alocados e como os clientes devem se conectar?

Se você selecione Elastic IP Address (EIP) como o tipo de endereço IP acelerado, o GA aloca endereços IP acelerados separadamente para cada região de aceleração. Regiões diferentes usam endereços IP diferentes. Recomendamos adicionar um registro CNAME para o nome de domínio do seu negócio e apontá-lo para o CNAME fornecido pelo GA. Isso permite que o GA execute o roteamento de tráfego baseado em dns e reduz o esforço necessário para manter endereços IP para regiões individuais. Você também pode usar registros A para se conectar ao GA, mas precisará manter esses registros e gerencie o failover por conta própria. O uso de um CNAME não garante que as alterações de configuração não tenham impacto no acesso. Caches de dns, valores de time-to-live (TTL) e conexões existentes podem afetar a forma como as alterações entram em vigor.

Se a sua aplicação exigir um conjunto comum de endereços IP em todo o mundo e acesso automático por meio de pontos de acesso próximos, selecione Anycast Elastic IP Address (Anycast EIP) como o tipo de endereço IP acelerado. O GA fornece dois Anycast EIPs e você não precisa configure áreas de aceleração. Atualmente, não há suporte para pontos de acesso na parte continental da china. Os clientes na parte continental da china se conectam por meio de Hong Kong, china. Se os clientes precisarem codificar endereços IP diretamente ou configure listas de permissões de IP, verifique se os endereços IP relevantes serão mantidos e avalie o impacto antes de alterar a configuração da instância ou da região de aceleração.

Quanto tempo leva para as alterações de registro dns entrarem em vigor no GA?

Quando um endpoint usa um nome de domínio personalizado, o tempo para que as alterações de registro dns entrem em vigor depende dos dois fatores a seguir:

• Duração do cache do servidor dns: o TTL configurado para o registro dns.

• Duração do cache do GA: o GA recupera registros dns a cada 15 segundos por padrão.

O GA oferece suporte ao processamento de pacotes TCP e UDP fragmentados?

Não.

Posso usar ICMP ping ou TCPing para testar o desempenho de aceleração de um listener UDP ou TCP?

Não.

Quantas instâncias do GA posso crie com uma única conta da Alibaba cloud?

Por padrão, você pode crie até 10 instâncias padrão do GA. Na página Quota Management, request a quota increase.

Não há cota imposta para instâncias básicas do GA.

Posso usar o GA se o meu cliente não tiver acesso à internet?

Não.

Para se conectar ao GA, os clientes devem ter acesso à internet.

Qual é a largura de banda mínima que posso alocar para uma única região de aceleração do GA?

• Se o tipo de endereço IP acelerado for Elastic IP Address: 2 Mbps.

• Se o tipo de endereço IP acelerado for Anycast Elastic IP Address: 200 Mbps.

O GA possui um mecanismo de cache?

Não.

Por que os clientes não conseguem acesse os service de backend após eu configure uma instância básica do GA?

• A ACL de rede ou o grupo de segurança da virtual private cloud (vpc) que hospeda o recurso de backend do endpoint contém regras de bloqueio. Para mais informações sobre como configure regras de ACL de rede e de grupo de segurança, consulte Create and manage a network ACL ou Modify security group rules.

• Na vpc que hospeda o recurso de backend do endpoint, um gateway IPv4 está ou esteve ativo. Você deve adicionar uma rota que aponte para o gateway IPv4 à tabela de rotas da vpc. Para mais informações, consulte Create and manage an IPv4 gateway.

• O service de backend do endpoint usa um endereço IP privado secundário de uma instância ECS ou interface de rede elástica (ENI), mas o sistema operacional não foi configurado para usar esse endereço.

  • Para saber como visualize as configurações de ENI, consulte Configure an operating system to recognize the IP addresses of a secondary ENI.

  • Para saber como configure um endereço IP privado secundário para uma ENI, consulte Assign secondary private IP addresses.

Como verifique se o recurso de tradução de IPv6 do GA funciona?

Por que o recurso de tradução de IPv6 do GA não entra em vigor?

Por que os clientes não conseguem acesse os service de backend após eu configure uma instância padrão do GA?

Como soluciono problemas de erros 502 após configure o GA?

Se as solicitações retornarem HTTP 502 após a configuração do GA, primeiro identifique o caminho da solicitação e a source do erro e, em seguida, verifique as configurações de conexão de backend e os service:

1. Identifique o caminho da solicitação e a source do erro: verifique os resultados da resolução dns do nome de domínio do seu negócio para confirmar que as solicitações passam pela instância do GA pretendida. O acesso baseado em CNAME é recomendado, mas registros A apontando para endereços IP acelerados do GA também são suportados. Compare os logs do GA, do servidor de source e da aplicação para identificar qual componente gerou a resposta 502. Um listener TCP encaminha o tráfego e não gera respostas HTTP 502.

2. verifique o status de saúde e os logs de backend: Se os health checks estiverem ativados, verifique o status de saúde dos endpoints e confirme as configurações do health check. Um health check bem-sucedido não garante que todas as solicitações da aplicação sejam bem-sucedidas. verifique se o backend está em execução e procure por fechamentos de conexão inesperados ou respostas inválidas.

3. Diferencie falhas de TLS no frontend de falhas de conexão no backend: Falhas de validação de certificado ou de handshake TLS entre o cliente e o GA geralmente aparecem como erros de conexão. Se o cliente recebeu um HTTP 502 via HTTPS, verifique primeiro a conexão do GA com o service de backend. Se o GA usar HTTPS para se conectar ao backend, verifique a compatibilidade do protocolo TLS, a configuração do certificado e os resultados do handshake TLS no backend.

4. verifique o protocolo de backend, as portas e as políticas de segurança: Confirme o endereço do endpoint, o protocolo de backend, a porta do service e o mapeamento de portas. Para um listener HTTPS, o protocolo usado entre o cliente e o GA pode ser diferente do protocolo usado entre o GA e o backend. Configure o protocolo de backend com base nos protocolos que o service de backend realmente suporta. verifique os grupos de segurança, firewalls e controles de acesso para o tipo de conexão pública ou privada aplicável.

5. Use ferramentas de diagnóstico: Revise os resultados de diagnóstico da instância. Se a instância atender aos requisitos para sondagem de source, incluindo as especificações de instância suportadas e os protocolos de listener, você poderá crie uma tarefa de sondagem de source para ajudar a localizar o problema.

O GA pode ajustar automaticamente a largura de banda de acesso do cliente e a largura de banda da rede interna da Alibaba cloud durante picos de tráfego?

O ajuste automático da largura de banda de acesso do cliente e de transmissão depende do método de faturamento da instância do GA:

• Pagamento conforme o uso: A largura de banda é dimensionada automaticamente com base no tráfego, até o pico de largura de banda da área de aceleração.

• Assinatura: Não há suporte para dimensionamento automático. A largura de banda é limitada pela largura de banda do plano de largura de banda básico e pela capacidade máxima de largura de banda da especificação da instância do GA.

Como soluciono problemas de perda de pacotes em redes transfronteiriças?

Se os clientes enfrentarem perda de pacotes ou falhas de acesso ao se conectarem a uma instância ECS da Alibaba cloud através de fronteiras, use o MTR ou o PathPing para coletar evidências de rede e correlacioná-las com as solicitações da aplicação e capturas de pacotes:

1. Colete os resultados da sondagem a partir do cliente

   Execute os seguintes comandos no cliente. Substitua o placeholder pelo endereço IP público real da instância ECS, sem os colchetes angulares:

   • Linux: mtr -rwc 100 <ECS-public-IP>

   • Windows: pathping -n -q 100 <ECS-public-IP>

   Para o MTR, -r ativa o modo de relatório, -w ativa relatórios amplos para evitar o truncamento de nomes de host e -c 100 execute 100 ciclos de sondagem. Para o PathPing, -n desativa a resolução de nomes de host e -q 100 envia 100 consultas para cada roteador ao longo do caminho. Repita os testes durante o incidente e mantenha os resultados de períodos saudáveis para comparação.

   O MTR usa ICMP por padrão, e a perda de sondagem ICMP não indica necessariamente perda de pacotes da aplicação. Para sondar a porta real da aplicação com TCP, use um comando como mtr -rwc 100 -T -P 443 <ECS-public-IP>. Os saltos intermediários no modo TCP ainda dependem tipicamente de respostas ICMP Time Exceeded. O MTR TCP não valida handshakes TLS ou solicitações HTTP, portanto, teste também as solicitações reais da aplicação.

2. Interprete a saída do MTR para identificar áreas a serem investigadas

   • Loss%: Porcentagem de perda de sondagem para o salto

   • Snt: Número de sondagens enviadas para o salto

   • Last: Tempo de ida e volta mais recente (ms)

   • Avg: Tempo médio de ida e volta (ms)

   • Best: Tempo mínimo de ida e volta (ms)

   • Wrst: Tempo máximo de ida e volta (ms)

   Concentre-se em saber se a perda persiste através dos saltos subsequentes até o destino. Uma perda alta ou perda de 100% em um salto intermediário, seguida por saltos downstream saudáveis e um destino saudável, geralmente indica respostas de sondagem ausentes, filtradas ou com taxa limitada. Isso não estabelece perda de pacotes da aplicação nesse salto. A perda que começa em um salto e persiste até o destino identifica uma área a ser investigada, mas o MTR sozinho não consegue identificar o dispositivo exato ou a direção da perda de pacotes.

3. Colete os resultados da direção reversa a partir da instância ECS

   Rastreie a rota da instância ECS para o endereço IP público do cliente: mtr -r -c 100 <client-public-IP>.

   Testes de ambas as extremidades ajudam a investigar diferenças de caminho, mas números de saltos com perda diferentes não provam que o tráfego atravessa links internacionais diferentes. As estatísticas de sondagem são afetadas tanto pelas sondagens de saída quanto pelos seus caminhos de resposta. Correlacione as rotas em ambas as direções com capturas de pacotes e o comportamento da aplicação.

   O nat ou firewalls podem restringir sondagens reversas, portanto, um salto final sem resposta não indica necessariamente perda de pacotes da aplicação. As sondagens TCP ainda exigem um service acessível no lado do cliente e qualquer mapeamento nat necessário. Repetir um teste direto pode fornecer evidências adicionais, mas não substitui um teste reverso.

4. Correlacione outras evidências para localizar o problema

   Analise as taxas de falha de solicitações da aplicação, retransmissões TCP, capturas de pacotes de ambas as extremidades, dados de número de sistema autônomo (ASN) e informações do ISP em conjunto para identificar a parte afetada da rede. O whois e a geolocalização de IP fornecem pistas de apoio; eles não podem estabelecer independentemente a localização dos roteadores ou o congestionamento em um gateway internacional.

5. Avalie a aceleração transfronteiriça

   Se as evidências apontarem para a qualidade da rede pública transfronteiriça, avalie o Global Accelerator (GA) e compare as taxas de sucesso da aplicação, a latência e a perda de pacotes antes e depois da adoção. Antes de usar uma linha dedicada transfronteiriça da china Unicom, verifique a elegibilidade da instância e da região e conclua os procedimentos necessários de qualificação e conformidade.

Como soluciono problemas de tempos limite ou redefinições de conexão que afetam ISPs específicos na parte continental da china?

Se os clientes que usam ISPs específicos ou estão localizados em regiões específicas da parte continental da china enfrentarem tempos limite ou redefinições de conexão ao acesse service acelerados pelo GA, registre o horário, a região e o ISP do cliente, o domínio do negócio, o endereço IP acelerado de destino, a porta e a mensagem de erro. Diferencie falhas de dns, tempos limite de conexão, falhas de handshake TLS e redefinições TCP. Falhas que afetam um ISP, região ou endereço IP acelerado específico não estabelecem, por si só, que uma política do ISP é a responsável.

Use ferramentas de sondagem de rede para comparar os resultados de acesso entre regiões, ISPs e endereços IP acelerados, mantendo o domínio do negócio, o protocolo, a porta e o caminho da solicitação consistentes. Para HTTPS, use o nome de domínio do negócio no cabeçalho Host e na Server Name Indication (SNI); usar um endereço IP como nome de host da URL pode introduzir diferenças de certificado ou roteamento. verifique o dns, os listeners, os controles de acesso, a saúde do backend, as políticas de segurança tanto no cliente quanto no servidor de source, e as capturas de pacotes ou logs para identificar o estágio da falha. Se as falhas persistirem para um ISP ou endereço IP acelerado específico, forneça ao suporte técnico da Alibaba cloud os resultados de testes bem-sucedidos e com falha, carimbos de data/hora e capturas de pacotes. Coordene com o ISP, se necessário. Para obter instruções de sondagem, consulte Test the acceleration performance of GA.