Server Load Balancer:Perguntas frequentes sobre o ALB

O ALB oferece especificações de instância específicas?

Não é necessário selecionar especificações para uma instância do ALB. Uma instância de ALB atualizada usa o VIP auto-scaling para processar até 1 milhão de consultas por segundo (QPS) por instância. Para obter mais informações sobre o desempenho das instâncias do ALB, consulte Métricas de desempenho da instância.

Posso converter uma instância de ALB IPv4 em uma instância de pilha dupla ou vice-versa?

Não.

Em vez disso, crie uma nova instância IPv4 ou de pilha dupla.

Posso desativar o ping para VIPs do ALB?

• Gerencie o tráfego de acesso para instâncias de ALB atualizadas usando grupos de segurança. Adicione uma regra ao grupo de segurança da instância para negar solicitações ICMP de entrada.

• Para instâncias de ALB não atualizadas, associe o EIP da instância a uma instância do Internet Boundary Firewall e adicione uma política para negar solicitações ICMP de entrada.

Como aumento a largura de banda pública de uma instância do ALB?

Por padrão, uma instância do ALB implantada em duas zonas de disponibilidade tem uma largura de banda pública máxima de 400 Mbit/s. Esse limite não se aplica se a instância fizer parte de uma instância do Internet Shared Bandwidth.

Posso usar um plano de transferência de dados para pagar o tráfego público de uma instância do ALB?

• Se a sua instância do ALB usar um Elastic IP Address (EIP) para fornecer serviços públicos, você pode usar um plano de transferência de dados para pagar o tráfego gerado pelo EIP.

• Se a sua instância do ALB usar um Anycast Elastic IP Address (Anycast EIP) para fornecer serviços públicos, não é possível usar um plano de transferência de dados para pagar o tráfego gerado pelo Anycast EIP.

Quais tipos de EIPs posso associar a uma instância do ALB?

Posso associar um EIP a uma instância de ALB voltada para a rede interna?

Sim.

Se precisar vincular um Elastic IP Address a um ALB privado, converta o ALB privado em um ALB público alterando o tipo de rede da instância. Para obter mais informações, consulte Alterar o tipo de rede de uma instância do ALB.

Ao alterar o tipo de rede de uma instância de voltada para a rede interna para voltada para a Internet, um EIP é associado à instância e você é cobrado pelo tráfego de Internet. Para obter mais informações, consulte Faturamento de EIP.

Como altero o EIP da minha instância do ALB para um EIP BGP (Multi-ISP) Pro?

Para isso, altere o tipo de rede da instância do ALB:

1. Altere o tipo de rede da instância do ALB de voltada para a Internet para voltada para a rede interna. Essa ação desassocia o EIP da instância.

2. Altere o tipo de rede da instância do ALB novamente para voltada para a Internet. Ao realizar essa operação, selecione dois EIPs existentes do tipo de linha BGP (Multi-ISP) Pro.

Por que o tráfego está desbalanceado entre os EIPs associados à minha instância do ALB?

Esse problema pode ocorrer pelos seguintes motivos:

• O nome de domínio do seu serviço está resolvido para um único EIP associado à instância do ALB, em vez do nome DNS da instância do ALB, conforme exigido.

• Um proxy de camada 7, como WAF ou Anti-DDoS, está implantado na frente da instância do ALB, e seu algoritmo de hash de origem (como IP Hash) impede que o tráfego seja distribuído uniformemente entre vários EIPs.

• Alguns clientes armazenam em cache os registros A da resolução DNS, o que faz com que um grande número de solicitações seja enviado continuamente para o mesmo EIP.

Remoção de registros DNS para o ALB

Instâncias de ALB atualizadas oferecem suporte à remoção e restauração de registros DNS por padrão.

Após a remoção de um registro DNS, as sondas de disponibilidade para o VIP nessa zona de disponibilidade são interrompidas. O VIP ou EIP nessa zona de disponibilidade, incluindo endereços IPv4 e IPv6, é removido da resolução DNS do nome de domínio do ALB. Não há suporte para a remoção apenas do endereço VIP IPv4 ou IPv6.

Por que o tráfego público da minha instância de ECS de backend ainda está alto após usar o ALB?

O tráfego que o ALB encaminha para uma instância de ECS de backend passa pela VPC e não consome a largura de banda pública da instância de ECS. Se o tráfego público na sua instância de ECS ainda estiver alto, isso geralmente se deve a um dos seguintes motivos:

• O tráfego de entrada está contornando a instância do ALB: o nome de domínio ainda está resolvido para o endereço IP público da instância de ECS, ou os clientes estão acessando a instância de ECS diretamente pelo endereço IP público.

• Solicitações de saída são iniciadas pela instância de ECS: um programa em execução na instância de ECS faz solicitações externas ativamente, como atualizações de software, uploads de log ou chamadas de API, o que gera tráfego público de saída.

Para solucionar esse problema, execute as seguintes etapas:

1. Verifique se o nome de domínio está resolvido para o endereço da instância do ALB, e não para o endereço IP público da instância de ECS.

2. Verifique as regras de entrada do grupo de segurança da instância de ECS para confirmar que a porta de serviço não está aberta ao público.

3. Na instância de ECS, use o iftop ou o nethogs para identificar os processos e endereços de destino que estão consumindo largura de banda pública.

O ALB oferece suporte a espelhamento de tráfego?

Sim. Para obter mais informações, consulte Usar espelhamento de tráfego para realizar testes de estresse.

Falha ao atingir o limite de QPS

• Como funciona: O sistema de balanceamento de carga usa um cluster de servidores para fornecer serviços. Todas as solicitações externas são distribuídas uniformemente entre esses servidores para encaminhamento. Portanto, o limite de QPS definido em uma regra de encaminhamento é distribuído entre vários servidores do sistema.

  O QPS máximo para um único servidor do sistema é calculado pela seguinte fórmula: Maximum QPS per system server = Total QPS configured/(N - 1), em que N é o número de servidores do sistema no grupo de encaminhamento. Por exemplo, se você definir o limite de QPS como 1.000 QPS no console e houver 8 servidores do sistema, o QPS máximo para um único servidor do sistema será 1000/(8 - 1) = 142 QPS.

• Causa: Se você usar um número pequeno de conexões persistentes, as conexões podem não ser distribuídas para todos os servidores do sistema no grupo de encaminhamento. Isso faz com que a instância do ALB não consiga atingir o limite de QPS.

• Recomendação: Com base no funcionamento do balanceamento de carga, recomendamos que você defina um limite de QPS razoável na regra de encaminhamento de acordo com os requisitos do seu negócio. Isso ajuda a garantir que seus serviços não sejam impactados. Para obter mais informações sobre como definir um limite de QPS em uma regra de encaminhamento, consulte Adicionar uma regra de encaminhamento.

Limites de tamanho de solicitação

Componentes do tempo de processamento do ALB

Sim, o tempo de processamento do ALB inclui o tempo para receber dados do cliente e enviar dados de resposta.

Máximo de solicitações por conexão persistente

Uma única conexão persistente suporta no máximo 100 solicitações consecutivas. Após esse limite ser excedido, a conexão é fechada automaticamente.

Se você usar um listener HTTPS e ativar o HTTP/2, o número máximo de solicitações suportadas por uma única conexão persistente pode ser aumentado para 1.000.

Limite de comprimento do pacote Client Hello para listeners QUIC

Ao usar um listener QUIC, o ALB exige um comprimento mínimo para pacotes Client Hello dos clientes. O comprimento deve ser de pelo menos 1.024 bytes. Caso contrário, o ALB retorna "client hello too small" e fecha a conexão. Você pode preencher o pacote Client Hello com caracteres nulos para atender a esse requisito de 1.024 bytes.

Observações de uso do ALB Ingress

Na maioria dos casos, não modifique manualmente uma instância do ALB criada por um ALB Ingress no console. A configuração da instância do ALB é sincronizada principalmente a partir do recurso AlbConfig. Para obter mais informações sobre ALB Ingresses, consulte Gerenciar ALB Ingresses e Recursos do ALB Ingress.

Se você modificar manualmente a configuração no console, as alterações podem ser substituídas porque o AlbConfig não é atualizado. Isso pode causar problemas como logs de acesso desativados ou regras de encaminhamento excluídas.

Cross-Origin Resource Sharing (CORS)

Referência a valores de cabeçalhos originais

Key especifica o nome do cabeçalho a ser inserido, e Value é usado para selecionar um tipo de referência e especificar o nome do cabeçalho original cujo valor você deseja referenciar. Por exemplo, você pode inserir um cabeçalho chamado abc-abc que referencia o valor do cabeçalho original abc. A regra de encaminhamento extrai o valor do cabeçalho original abc e o atribui ao cabeçalho recém-inserido abc-abc.

Cliente

Servidor

O ALB oferece suporte à autenticação mútua?

Instâncias Basic do ALB não oferecem suporte à autenticação mútua. Você pode configurar a autenticação mútua ao adicionar um listener HTTPS para uma instância Standard ou com WAF ativado do ALB. Se precisar usar a autenticação mútua em uma instância Basic do ALB, altere a edição da instância.

Regras para certificados curinga

Posso fazer upload de certificados no console do ALB?

Não.

O ALB obtém os certificados diretamente do Alibaba Cloud SSL Certificates Service. Faça upload dos seus certificados no console do SSL Certificates Service, e não no console do ALB. Para obter mais informações, consulte Fazer upload de um certificado SSL.

Data de expiração do certificado desatualizada no navegador

Isso normalmente ocorre quando a instância do ALB está conectada ao WAF 2.0 no modo de proxy transparente, e o certificado no lado do WAF ainda não foi atualizado. O WAF sincroniza os certificados do ALB periodicamente. Para forçar uma sincronização imediata, desative e reative o redirecionamento de tráfego no console do WAF. Observe que essa ação causa uma breve interrupção do serviço de um a dois segundos.

Modificar a configuração de verificação de integridade

1. Faça login no console do Application Load Balancer (ALB).

2. No painel de navegação à esquerda, escolha ALB > Server Groups.

3. Na página Server Groups, localize o grupo de servidores que deseja gerenciar e clique no ID dele.

4. Na aba Details, clique em Modify Health Check na seção Health Check.

5. Na caixa de diálogo Modify Health Check, clique em Edit à direita de Health Check Settings e modifique as configurações. Em seguida, clique em Save.

   Para obter mais informações, consulte Verificações de integridade do ALB.

Erro 502 com verificações de integridade normais

Esse problema geralmente ocorre porque os servidores de backend da instância do ALB estão sobrecarregados. Se os servidores de backend da sua instância do ALB estiverem sobrecarregados, os resultados da verificação de integridade e os resultados da solicitação de acesso podem ser inconsistentes. Para obter informações sobre como verificar a carga nos servidores de backend, consulte Solucionar problemas de alto uso de CPU em uma instância Linux.

Encaminhamento de solicitações quando todos os servidores de backend estão indisponíveis

O ALB ainda tenta encaminhar solicitações com base no algoritmo de agendamento para minimizar a interrupção do serviço. Se as solicitações não forem tratadas conforme esperado, verifique os logs em busca de erros nos servidores de backend ou inspecione a configuração da verificação de integridade. Para obter mais informações, consulte Solucionar falhas na verificação de integridade do ALB.

Solucionar problemas de acesso ao serviço

Consulte as seguintes soluções:

1. Confirme a resolução CNAME: não é possível acessar diretamente uma nova instância do ALB pelo nome DNS. Mapeie um nome de domínio personalizado para o nome DNS da instância do ALB criando um registro CNAME. Use o comando nslookup ou dig para verificar o resultado da resolução. Para obter mais informações, consulte Nomes DNS de instâncias do ALB.

2. Verifique o tipo de rede da instância: uma instância de ALB voltada para a rede interna pode ser acessada apenas de dentro da VPC. Para ativar o acesso público, altere o tipo de rede da instância para voltada para a Internet e associe um EIP à instância. Para obter mais informações, consulte Alterar o tipo de rede de uma instância do ALB.

3. Verifique os listeners e as regras de encaminhamento: no console do ALB, verifique se um listener foi criado, confirme se a porta e o protocolo do listener estão configurados corretamente e confirme se a regra de encaminhamento pode corresponder ao nome de domínio e ao caminho da solicitação.

4. Verifique o status da verificação de integridade: no console do ALB, verifique o status de integridade dos servidores de backend. Se um servidor de backend falhar na verificação de integridade, a instância do ALB pode não conseguir encaminhar as solicitações corretamente.

5. Verifique se o serviço de backend está funcionando corretamente: faça login diretamente no servidor de backend e execute o comando curl -I http://<backend_server_private_IP>:<port> para confirmar que o serviço de backend está respondendo corretamente.

6. Verifique o controle de acesso e as configurações de firewall: confirme se a lista de controle de acesso (ACL) ou o grupo de segurança da instância do ALB não está bloqueando o intervalo de endereços IP de origem do cliente. Confirme se o iptables ou software de segurança de terceiros na instância de ECS de backend não está bloqueando o intervalo de endereços IP local do ALB.

Solucionar alta latência

Como o ALB é um serviço de camada de aplicação que encaminha solicitações para servidores de backend, um leve aumento na latência em comparação com o acesso direto é normal.

Se a latência for significativamente alta, siga estas etapas para solucionar o problema:

1. Ative os logs de acesso e analise os campos de latência: ative os logs de acesso do ALB e observe os seguintes campos:

   • request_time: o intervalo de tempo desde quando o balanceador de carga recebe o primeiro pacote de uma solicitação até enviar a resposta, em segundos.

   • upstream_response_time: o tempo, em segundos, desde quando o balanceador de carga começa a estabelecer uma conexão com um servidor de backend até terminar de receber os dados e fechar a conexão.

2. Identifique a origem da latência:

   • Se upstream_response_time estiver alto, a latência geralmente é causada por processamento lento nos servidores de backend. Investigue o desempenho do aplicativo de backend, a eficiência das consultas ao banco de dados e o uso de recursos como CPU e memória, ou adicione mais servidores de backend para distribuir a carga.

   • Se request_time for muito maior que upstream_response_time, a latência provavelmente está no link de rede do cliente ao ALB. Recomendamos executar testes contínuos de ping ou rotas de rastreamento MTR do cliente para o endereço do serviço ALB para solucionar problemas de link de rede.

3. Acesso entre regiões: se o cliente e a instância do ALB estiverem em regiões diferentes, a latência de rede devido à distância física é inevitável. Recomendamos usar o Global Accelerator (GA) para otimizar a experiência de acesso entre regiões.

Não é possível acessar o serviço pelo nome de domínio

Uma nova instância do ALB não pode ser acessada diretamente pelo nome DNS. Resolva um nome de domínio personalizado para o nome DNS da instância do ALB usando um registro CNAME. Se o registro CNAME foi configurado corretamente, mas o serviço ainda não pode ser acessado (por exemplo, um erro 403 é retornado ou a conexão é redefinida), a causa mais provável é um registro ICP incompleto.

Siga estas etapas para solucionar o problema:

1. Verifique a configuração do registro CNAME: execute o comando nslookup ou dig para verificar se o nome de domínio está corretamente resolvido para o nome DNS da instância do ALB. Para obter mais informações, consulte Configurar um registro CNAME.

2. Verifique o status do registro ICP do nome de domínio: de acordo com as regulamentações vigentes, um nome de domínio deve ter um registro ICP para fornecer acesso público na China continental. Caso contrário, o acesso é bloqueado. Faça login no sistema de registro ICP da Alibaba Cloud para verificar o status do registro do seu nome de domínio. Se não houver registro, conclua o registro ICP primeiro. Para obter mais informações, consulte Processo de registro ICP.

3. Verifique se é necessário transferir o registro ICP: se o seu nome de domínio já possui um registro ICP com outro provedor de serviços em nuvem, mas está sendo usado com a Alibaba Cloud pela primeira vez, transfira as informações do registro para a Alibaba Cloud. Se a transferência não estiver concluída, o acesso também pode ser bloqueado.

500 (Internal Server Error)

O servidor de backend encontrou um erro interno e não conseguiu processar a solicitação.

• O backend retorna 500 diretamente: verifique o log de acesso. Se upstream_status for 500, o ALB provavelmente encaminhou o código de status do backend. Investigue o serviço de backend.

• O servidor de backend fechou a conexão inesperadamente: o servidor de backend fechou a conexão antes de enviar uma resposta completa. Capture pacotes no servidor de backend para identificar a causa do encerramento inesperado da conexão.

502 (Bad Gateway)

Esse erro ocorre quando um listener HTTP ou HTTPS recebe uma solicitação do cliente, mas o ALB não consegue encaminhar a solicitação para um servidor de backend ou receber uma resposta dele.

Abordagem de solução de problemas: primeiro, verifique o valor do campo upstream_status no log de acesso para determinar as próximas etapas.

• Se upstream_status = 502: o ALB encaminhou o código de status 502 do servidor de backend. O problema está no próprio serviço de backend. Investigue o serviço de backend. Por exemplo, verifique se um Nginx ou camada de gateway de backend está tentando fazer proxy reverso para um upstream inacessível.

• Se upstream_status for outro valor (como 504, 444 ou 500): o status que o ALB retorna ao cliente difere do upstream_status, o que significa que o ALB alterou o código de status. Investigue por que o serviço de backend está retornando esse código de status específico verificando os logs do Nginx, gateway ou aplicação de backend.

• Se upstream_status for - ou vazio: o ALB não recebeu nenhuma resposta do backend. Isso significa que a solicitação não chegou ao backend ou a conexão do backend foi encerrada de forma anormal antes do envio de uma resposta. Verifique as seguintes causas em ordem:

  • A comunicação TCP entre o ALB e o servidor de backend está falhando. Verifique se o serviço de backend está em execução, se a porta de serviço está escutando corretamente e se nenhuma regra iptables ou software de segurança de terceiros na ECS de backend está bloqueando o bloco CIDR do vSwitch onde a instância do ALB está localizada. O ALB se comunica com os servidores de backend usando um Local IP atribuído pelo vSwitch. Capture pacotes para verificar se o handshake TCP foi bem-sucedido.

  • O backlog do servidor de backend está cheio. Isso faz com que o servidor descarte novas solicitações de conexão. Execute netstat -s | grep -i listen no servidor de backend e verifique se há um contador de drop.

  • O servidor de backend não conseguiu processar a solicitação a tempo. Verifique os logs do servidor de backend e analise o uso de CPU e memória para identificar gargalos de desempenho.

  • O tamanho do pacote da solicitação do cliente excede o MTU do servidor de backend. Isso pode fazer com que pacotes curtos (como verificações de integridade) sejam bem-sucedidos enquanto pacotes longos falham. Capture pacotes no servidor de backend para analisar se o comprimento do pacote está dentro dos limites exigidos.

  • A resposta do servidor de backend tem formato inválido ou contém cabeçalhos HTTP inválidos. Capture pacotes no servidor de backend para analisar se o formato da resposta está em conformidade com os padrões.

503 (Service Temporarily Unavailable)

O servidor está temporariamente indisponível, geralmente devido ao tráfego que excede os limites ou a um serviço de backend indisponível.

• O backend retorna 503 diretamente: verifique o log de acesso. Se upstream_status for 503, o ALB provavelmente encaminhou o código de status do backend. Investigue o serviço de backend.

• A solicitação do cliente acionou o throttling do ALB:

  • No Cloud Monitor, verifique a métrica Requests per second.

  • O Cloud Monitor exibe dados em nível de minuto e pode não refletir picos em nível de segundo. Verifique o log de acesso. Se o campo upstream_status for -, a solicitação não chegou ao servidor de backend.

  • Verifique o cabeçalho do pacote de resposta. Se ele contiver o campo ALB-QPS-Limited:Limited, a solicitação acionou o throttling do ALB.

• Acesso direto por IP ou resolução DNS anormal: isso pode concentrar o tráfego em apenas alguns endereços IP e acionar o throttling. Acesse o ALB pelo nome de domínio (consulte Configurar um CNAME para uma instância do ALB) e verifique se a resolução DNS funciona conforme esperado.

• O listener não possui servidores de backend configurados, ou os servidores de backend configurados têm peso 0.

504 (Gateway Time-out)

O ALB expirou o tempo limite ao aguardar uma resposta do servidor de backend.

• O backend retorna 504 diretamente: verifique o log de acesso. Se upstream_status for 504, o ALB provavelmente encaminhou o código de status do backend. Investigue o serviço de backend.

• Tempo limite de tentativa de conexão do ALB ao servidor de backend: esse tempo limite é de 5 segundos por padrão e não pode ser alterado. Capture pacotes para identificar por que o servidor de backend não está respondendo a tempo.

• Tempo limite de resposta do backend: o tempo limite da solicitação de conexão é de 60 segundos por padrão. Verifique a métrica UpstreamResponseTime no Cloud Monitor e o campo upstream_response_time no log de acesso para determinar se a resposta do servidor de backend expirou.

WAF 2.0 vs. WAF 3.0 — integração

Para obter mais informações, consulte Comparação entre WAF 3.0 e WAF 2.0.

Integração do WAF com o ALB

• Recomendamos ativar a proteção WAF 3.0 para a sua instância do ALB usando o modo de integração de serviço, ou seja, uma instância de ALB com WAF ativado.

  • Regiões compatíveis:

    Área	Região
    China	China (Chengdu), China (Qingdao), China (Beijing), China (Guangzhou), China (Hangzhou), China (Ulanqab), China (Shanghai), China (Shenzhen), China (Zhangjiakou), China (Hong Kong), China (Heyuan)
    Ásia-Pacífico	Indonésia (Jacarta), Japão (Tóquio), Malásia (Kuala Lumpur), Filipinas (Manila), Singapura, Coreia do Sul (Seul), Tailândia (Bangcoc)
    Europa e Américas	Alemanha (Frankfurt), EUA (Vale do Silício), EUA (Virgínia), México
    Oriente Médio	Arábia Saudita (Riad) (Operado por Parceiro), Emirados Árabes Unidos (Dubai)

  • As instâncias de ALB com WAF ativado usam o modelo de integração via SDK do WAF 3.0. Se a sua conta possuir uma instância do WAF 2.0, primeiro libere a instância do WAF 2.0 ou migre para o WAF 3.0.

    Por padrão, o ALB não adiciona o cabeçalho X-Forwarded-Proto às solicitações. Após liberar uma instância do WAF 2.0, acessar a instância do ALB diretamente pode causar problemas de serviço, como redirecionamentos infinitos, pois os servidores de backend não conseguem identificar o protocolo original (HTTP ou HTTPS). Para evitar esse problema, ative manualmente o cabeçalho de solicitação X-Forwarded-Proto na configuração do listener do ALB.

  • Instâncias de ALB com WAF ativado não oferecem suporte ao recurso de prevenção contra vazamento de dados do WAF.

• Se precisar usar uma instância existente do WAF 2.0, instâncias de ALB voltadas para a Internet das edições Basic e Standard oferecem suporte à proteção WAF 2.0 no modo de proxy transparente. Isso é compatível nas seguintes regiões: China (Hangzhou), China (Shanghai), China (Shenzhen), China (Chengdu), China (Beijing) e China (Zhangjiakou). Instâncias de ALB voltadas para a rede interna não oferecem suporte à proteção WAF 2.0.

Suporte do CLB e do ALB à integração com WAF

Problemas de configuração com o modo de proxy transparente do WAF 2.0

Ao usar o WAF 2.0 no modo de proxy transparente, as solicitações dos clientes são inspecionadas pelo WAF antes de serem encaminhadas para uma instância do ALB ou CLB. As solicitações passam por dois gateways, o que exige a sincronização das configurações entre o WAF e o balanceador de carga. Atrasos na sincronização das configurações, especialmente para alterações de tempo limite e certificados, podem ocorrer com facilidade.