Server Load Balancer:CLB listener FAQ

Suporte a redirecionamento de porta no CLB

Sim.

O CLB oferece suporte a redirecionamento de porta. Para visualizar um exemplo, consulte Use CLB to redirect HTTP requests to HTTPS.

Suporte a intervalo de portas para listeners da Camada 4

Não. Para escutar em um intervalo de portas com um listener tcp ou udp, crie uma instância de Network Load Balancer (NLB) e ative o recurso All Ports para o listener. Para obter mais informações, consulte Use the NLB All Ports listener feature to forward traffic on multiple ports.

Considerações sobre a configuração da porta do listener

Algumas operadoras classificam portas como 25, 135, 139, 444, 445, 5800 e 5900 como de alto risco e as bloqueiam por padrão. Mesmo que você permita essas portas nas regras do grupo de segurança, usuários em regiões restritas podem não conseguir acessar seus services. Recomendamos o uso de outras portas que não sejam de alto risco.

• Para obter informações sobre as portas usadas por aplicativos em sistemas Windows Server, consulte a Documentação da Microsoft Visão geral do service e requisitos de porta de rede para Windows Server.

• Para obter mais informações sobre portas comuns, consulte Common ports.

Configuração de listener para WebSocket

• Se seus servidores back-end hospedarem services WebSocket, configure um listener tcp ou http.

• Caso seus servidores back-end hospedem services WebSocket Secure, configure um listener tcp ou HTTPS.

Efeito das alterações na configuração do listener

As alterações entram em vigor imediatamente e se aplicam apenas a novas requisições. As conexões existentes não são afetadas.

Caracteres especiais em regras de encaminhamento de url

Codifique caracteres especiais em uma url para garantir o acesso adequado. Por exemplo, o caractere cerquilha (#) é codificado como %23, resultando na url http://www.example.com/%23/. Para conhecer as regras completas de codificação, consulte a RFC 3986.

Gerenciar servidores back-end para regras de encaminhamento

Na página Forwarding Rule, clique em no nome do grupo de servidores virtuais alvo na coluna Virtual Server Group. Na página Edit Virtual Server Group, adicione ou exclua servidores back-end e modifique suas portas ou pesos.

O CLB permite definir limites de tamanho para o corpo da requisição?

O CLB não oferece suporte ao parâmetro client_max_body_size. O limite de 50 GB para o corpo da requisição pertence ao Application Load Balancer (ALB), e não ao CLB.

Para controlar o tamanho do corpo da requisição, utilize um listener tcp da Camada 4 e configure client_max_body_size no servidor web da instância ECS back-end (como o Nginx):

http {
    client_max_body_size 100m;
}

Com um listener tcp, o CLB encaminha o tráfego da Camada 4 de forma transparente, e a instância ECS back-end impõe o limite de tamanho do corpo da requisição.

Como a largura de banda é calculada para instâncias CLB com largura de banda fixa?

A largura de banda de saída e de entrada de uma instância CLB com largura de banda fixa são calculadas independentemente. Após defina o valor da largura de banda fixa, tanto a largura de banda de saída quanto a de entrada são limitadas individualmente ao valor configurado. Não é necessário somá-las. Por exemplo, se a largura de banda fixa for definida como 80 Mbps, a largura de banda máxima de saída será 80 Mbps e a largura de banda máxima de entrada também será 80 Mbps. Os dois valores são calculados separadamente e não se afetam mutuamente.

Visualize dados de monitoramento em tempo real da largura de banda de saída e de entrada na página de monitoramento do console CLB. Nas métricas de monitoramento, inBitsPS representa a largura de banda de entrada e outBitsPS representa a largura de banda de saída. Recomendamos usar os dados de monitoramento por minuto no console como referência ao ajustar a largura de banda.

Queda de tráfego sem exceder o limite de largura de banda

Esse problema geralmente ocorre pelos seguintes motivos:

• O monitoramento de largura de banda da Alibaba Cloud utiliza médias de um minuto. Se um pico instantâneo de tráfego dentro de um segundo exceder o limite de largura de banda da instância, o sistema descartará o tráfego. Isso pode acontecer mesmo que a largura de banda média durante todo o minuto permaneça abaixo do limite configurado. Como resultado, o gráfico de monitoramento pode mostrar que o uso geral da largura de banda está inferior ao limite especificado.

• As instâncias CLB executam em um cluster de servidores que distribui uniformemente as requisições recebidas entre seus servidores. A largura de banda de pico configurada também é distribuída entre os servidores do cluster. Se os dados baixados por uma única conexão de cliente excederem o limiar de um servidor individual, o sistema descartará o tráfego. Para obter mais informações sobre como o tráfego máximo de download para uma única conexão é calculado, consulte Why can't a connection reach the peak bandwidth in certain scenarios?.

Tráfego monitorado excede o limite configurado

As instâncias CLB utilizam um cluster de servidores para limitação de taxa distribuída. O limite de taxa de pico para um único nó é calculado como: Limite de taxa de pico para um único nó = Largura de banda total configurada / (N - 1), onde N é o número de nós no cluster. Consequentemente, o limite de taxa efetivo total pode ser ligeiramente superior ao valor configurado.

Conexão não atinge a largura de banda de pico

• Cenário: Uma única conexão com uma instância CLB voltada para a internet que utiliza o método de faturamento por especificação (largura de banda fixa) pode não atingir a largura de banda de pico configurada. Esse problema frequentemente ocorre durante testes de estresse com um único cliente ou ao transferir um pacote de dados muito grande.

• Causa:

  As instâncias CLB executam em um cluster de servidores. O cluster distribui uniformemente todas as requisições recebidas entre seus servidores.

  O tráfego máximo de download para uma única conexão é calculado da seguinte forma: Peak download traffic per connection = Total configured bandwidth / (N - 1), onde N é o número de servidores no cluster. N é 4 para um listener da Camada 4 e 8 para um listener da Camada 7. Por exemplo, se você defina o limite de largura de banda como 10 Mbps no console, a largura de banda total poderá atingir 10 Mbps quando vários clientes forem usados simultaneamente. No entanto, o tráfego máximo que um único cliente pode baixar é 10 / (4 - 1) = 3,33 Mbps.

• Solução:

  • Utilize o método de faturamento por tráfego para a instância CLB voltada para a internet.

  • Use uma instância NLB ou ALB com um EIP e largura de banda compartilhada. Essa configuração é mais elástica e evita essa limitação.

Instância CLB não atinge o QPS de pico

• Cenário: Ao utilizar um pequeno número de conexões persistentes, as conexões podem não ser distribuídas para todos os servidores no cluster de encaminhamento. Como resultado, a instância CLB pode não atingir seu QPS de pico.

• Causa:

  As instâncias CLB são implantadas em um cluster. O sistema distribui as requisições recebidas uniformemente entre os servidores do cluster. Portanto, o QPS de pico de uma instância CLB também é distribuído entre esses servidores.

  O QPS máximo para um único servidor é calculado da seguinte forma: Peak QPS per server = Total instance QPS / (N - 1), onde N é o número de servidores no cluster de encaminhamento. Por exemplo, se você adquirir uma instância CLB da especificação slb.s1.small, que suporta 1.000 QPS, o QPS total poderá atingir 1.000 quando vários clientes forem usados. Contudo, se o cluster tiver 8 servidores, o QPS máximo para um único servidor será 1000 / (8 - 1) = 142 QPS.

  Nota

  Novas aquisições de instâncias CLB com faturamento por especificação serão descontinuadas às 00:00:00 de 1º de junho de 2025 (UTC+8). Para obter mais informações, consulte End of sale for pay-by-specification CLB instances.

• Solução:

  • Utilize conexões de curta duração a partir de um único cliente para testes de estresse.

  • Reduza a reutilização de conexões com base nos requisitos reais do seu negócio.

  • Atualize a especificação da instância CLB. Para obter mais informações, consulte Upgrade or downgrade a pay-as-you-go (pay-by-specification) instance.

  • Utilize uma instância ALB. Esse tipo de instância oferece maior elasticidade.

Taxa de novas conexões não atinge o pico

• Cenário: Ao usar uma instância Classic Load Balancer (CLB) com faturamento por especificação, sua taxa de novas conexões (CPS) pode não atingir o nível especificado, especialmente durante testes de estresse com um único cliente ou quando o tráfego vem de uma única source.

  Nota

  Novas aquisições de instâncias CLB com faturamento por especificação serão descontinuadas às 00:00:00 de 1º de junho de 2025 (UTC+8). Para obter mais informações, consulte End of sale for pay-by-specification CLB instances.

• Causa:

  O sistema de balanceamento de carga usa uma arquitetura de cluster para alta disponibilidade e escalabilidade. Ele distribui as requisições de conexão recebidas uniformemente entre os servidores do cluster. Portanto, o CPS de pico de uma instância CLB também é distribuído entre esses servidores.

  O CPS de pico para um único servidor é calculado da seguinte forma: CPS de pico por servidor = CPS total da instância / (N - 1), onde N é o número de servidores no cluster de encaminhamento.

  Por exemplo, se você adquirir uma instância CLB da especificação slb.s1.small classificada para 3.000 CPS, a instância poderá atingir os 3.000 CPS completos com requisições de vários clientes. No entanto, se o cluster tiver 4 servidores, o CPS máximo para um único servidor será 3000 / (4 - 1) = 1.000 CPS.

• Solução:

  • Altere o método de faturamento da instância de pagamento por especificação para pagamento conforme o uso. Instâncias com pagamento conforme o uso não estão vinculadas a uma especificação de desempenho específica e oferecem limites mais altos, o que ajuda a evitar gargalos.

  • Migre para um Network Load Balancer (NLB) em cenários com alta concorrência e alta taxa de novas conexões. O NLB oferece desempenho e elasticidade superiores em comparação ao CLB. Uma única instância NLB suporta 100 milhões de conexões simultâneas, sendo ideal para aplicações de grande escala e evitando as limitações de CPS da arquitetura de cluster do CLB.

Intervalos suportados para tempo limite de conexão

• Tempo limite de conexão do listener tcp: 10 a 900 segundos.

• Listener http:

  • Tempo limite de ociosidade: 1 a 60 segundos.

  • Tempo limite de requisição: 1 a 180 segundos.

• Listener HTTPS:

  • Tempo limite de ociosidade: 1 a 60 segundos.

  • Tempo limite de requisição: 1 a 180 segundos.

Causas de tempos limite de conexão no CLB

Os seguintes problemas no lado do servidor podem causar tempos limite de conexão com o endereço de service do CLB:

• O endereço de service está bloqueado por medidas de segurança

  Isso inclui limpeza de tráfego, filtragem blackhole ou proteção WAF. O WAF, por exemplo, envia pacotes RST tanto para o cliente quanto para o cluster de servidores após estabelecer uma conexão.

• Portas de cliente insuficientes

  Esse problema é comum durante testes de estresse. A escassez de portas de cliente pode causar falhas de conexão. Por padrão, o CLB remove a opção de timestamp das conexões tcp, o que impede que o recurso tw_reuse do kernel Linux (reutilização de conexões no estado TIME_WAIT) tenha efeito. Isso leva a um acúmulo de conexões no estado TIME_WAIT e à falta de portas de cliente disponíveis.

  Solução: Utilize conexões persistentes em vez de conexões de curta duração. Desconecte enviando um pacote RST definindo a opção de socket SO_LINGER, em vez de enviar um pacote FIN.

• A fila de aceitação do servidor back-end está cheia

  Se a fila de aceitação de um servidor back-end estiver cheia, ele não enviará uma resposta SYN-ACK, causando um tempo limite no cliente.

  Solução: O valor padrão de net.core.somaxconn é 128. Avalie seu volume de tráfego e ajuste esse valor para atender às suas necessidades. Em seguida, execute sysctl -w net.core.somaxconn=<new_value> para alterar o parâmetro e reinicie o aplicativo no servidor back-end.

• Um servidor back-end da Camada 4 acessa o endereço de service do seu próprio balanceador de carga

  Listeners da Camada 4 do CLB (tcp/udp) não permitem que um servidor back-end atue como cliente e servidor simultaneamente. Se um servidor back-end tentar acessar o endereço de service da instância CLB à qual está anexado, a conexão falhará. Isso frequentemente acontece quando um aplicativo back-end redireciona para o endereço de service do CLB construindo uma url.

  Solução:

  • Utilize um cliente diferente para acessar o endereço de service em vez do servidor back-end da Camada 4.

  • Migre para uma instância Network Load Balancer (NLB) e desative a preservação de ip do cliente no grupo de servidores. Após desativar esse recurso, uma instância ECS no grupo de servidores pode atuar tanto como servidor back-end quanto como cliente da instância NLB. Para obter o endereço ip de source do cliente, ative o Proxy Protocol. Para obter mais informações, consulte How can an ECS instance act as both a backend server and a client of an NLB instance?.

• Tratamento inadequado de pacotes RST no tempo limite de conexão

  Após o estabelecimento de uma conexão tcp, se não houver atividade por 900 segundos, o CLB envia pacotes RST tanto para o cliente quanto para o servidor para fechar a conexão. Alguns aplicativos podem não lidar corretamente com o pacote RST e tentar enviar dados pela conexão fechada, causando um tempo limite no aplicativo.

  Nota

  O tempo limite padrão é de 900 segundos, mas pode ser ajustado conforme necessário.

Tempos limite de conexão http e HTTPS

• Uma conexão persistente http suporta no máximo 100 requisições consecutivas. Após atingir esse limite, o CLB fecha a conexão.

• O tempo limite de ociosidade entre duas requisições http ou HTTPS em uma conexão persistente é configurável de 1 a 60 segundos (com uma margem de erro de 1 a 2 segundos). Se esse tempo limite for excedido, a conexão tcp será fechada. Se seu aplicativo usar conexões persistentes, recomendamos enviar uma requisição de heartbeat pelo menos a cada 13 segundos.

• O handshake triplo tcp entre uma instância CLB e uma instância ECS back-end expira após 5 segundos. Se o handshake expirar, o CLB tentará a próxima instância ECS. Identifique esse problema verificando o tempo de resposta upstream no log de acesso.

• O tempo limite de requisição (tempo que uma instância CLB aguarda por uma resposta de uma instância ECS) é configurável de 1 a 180 segundos. Se esse tempo limite for excedido, o CLB normalmente retorna um código de status 504 ou 408 ao cliente. Identifique esse problema verificando o tempo de resposta upstream no log de acesso.

• O tempo limite de reutilização de sessão HTTPS é de 300 segundos. Após esse período, o mesmo cliente deve realizar um handshake SSL completo novamente.

O CLB tenta repetir requisições automaticamente após um tempo limite?

Não. Se uma requisição exceder o tempo limite de requisição configurado do listener (por exemplo, o padrão de 60 segundos), o CLB encerra a conexão e retorna um código de erro 504 ao cliente. O CLB não repete a requisição automaticamente. Para implementar repetições de requisição, implemente a lógica de nova tentativa no lado do cliente.

Mecanismo de nova tentativa implícita para listeners HTTPS da Camada 7 do CLB

Quando um servidor back-end não responde ou retorna um erro em um listener HTTPS da Camada 7 do CLB, o CLB aciona automaticamente um mecanismo de nova tentativa implícita. O CLB tenta sequencialmente outros servidores back-end íntegros. A nova tentativa é iniciada pelo próprio CLB e não depende do cliente. Quando ocorre um tempo limite, o CLB registra um erro 504 e tenta outro nó back-end. Apenas o resultado da última tentativa é retornado ao cliente.

Visualizar registros de nova tentativa: O console CLB não fornece uma interface dedicada para consultar logs de nova tentativa. Visualize os registros de nova tentativa nos logs de acesso do CLB. Vários valores no campo upstream_addr (separados por vírgulas) servem como evidência de uma nova tentativa. Os múltiplos valores em upstream_response_time correspondem aos tempos de resposta de cada tentativa. Por exemplo, upstream_addr: 10.0.0.1:80, 10.0.0.2:80 indica que o CLB tentou dois servidores back-end sequencialmente.

Comportamento do CLB na desconexão antecipada do cliente

Não. O CLB não fecha a conexão com o servidor back-end durante operações de leitura e gravação.

Ativar conexões persistentes de back-end para o CLB

As instâncias CLB não suportam conexões persistentes de back-end. Para usar esse recurso, crie uma instância ALB, configure um listener http ou HTTPS e ative conexões persistentes de back-end para o grupo de servidores ALB correspondente. Para obter mais informações, consulte Create and manage a server group.

Solucionar alta latência no CLB

Acessar um service back-end através de uma instância CLB introduz uma pequena quantidade de latência extra em comparação ao acesso direto ao servidor back-end. Isso é normal. Listeners da Camada 7 do CLB usam uma arquitetura de proxy reverso (Tengine), que adiciona um salto de rede extra e tempo de processamento de protocolo. A latência extra para listeners da Camada 4, que usam LVS para encaminhamento, é tipicamente menor.

Se você experimentar uma latência significativamente alta, siga estas etapas para solucionar o problema:

1. Ative logs de acesso e analise campos de latência: Ative CLB access logs e concentre-se nos seguintes campos:

   • request_time: O intervalo, em segundos, desde quando o CLB recebe o primeiro pacote de requisição até quando retorna a resposta.

   • upstream_response_time: O intervalo, em segundos, desde quando uma conexão com um servidor back-end é estabelecida até quando os dados são totalmente recebidos e a conexão é fechada.

2. Identifique a source da latência:

   • Se upstream_response_time estiver alto: A latência provavelmente é causada por processamento lento no servidor back-end. Verifique o desempenho do aplicativo back-end, a eficiência das consultas ao banco de dados e o uso de recursos (cpu/memória), ou adicione mais servidores back-end para distribuir a carga.

   • Se request_time for muito maior que upstream_response_time, a latência pode estar no link de rede do cliente para o CLB. Execute um teste contínuo de ping ou realize rastreamento de rota MTR do cliente para o endereço de service do CLB para solucionar problemas de link de rede.

3. Acesso entre regiões: Se o cliente e a instância CLB 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.

Solucionar erros 502, 503 ou 504

Ao acessar um service back-end através de uma instância CLB, códigos de erro 502, 503 ou 504 geralmente indicam que a requisição não foi processada corretamente pelo servidor back-end. Os códigos de erro significam o seguinte:

• 502 Bad Gateway: O CLB não conseguiu encaminhar a requisição para um servidor back-end ou receber uma resposta dele. Causas comuns incluem services back-end inacessíveis ou falha em todas as verificações de integridade.

• 503 Service Temporarily Unavailable: Geralmente causado por tráfego excedendo limites ou um servidor back-end indisponível. Esse erro é retornado quando o tráfego instantâneo excede os limites da especificação da instância CLB.

• 504 Gateway Timeout: O servidor back-end atingiu o tempo limite. Causas comuns incluem tempos longos de processamento no back-end ou tempo limite ao estabelecer uma conexão com o servidor back-end.

Primeiro passo: Verificar logs de acesso

Primeiro, ative CLB access logs e verifique os campos status (código de status retornado pelo CLB ao cliente) e upstream_status (código de status retornado pelo servidor back-end ao CLB) nos logs:

• Se status e upstream_status forem iguais, o CLB provavelmente passou o código de erro diretamente do servidor back-end. Investigue por que o servidor back-end está retornando esse erro.

• Se upstream_status for "-" ou diferente de status, o erro foi retornado pelo CLB. Consulte os pontos a seguir para solucionar o problema.

Solucionar erros 502

• Falha nas verificações de integridade de todos os servidores back-end: Quando todos os servidores back-end associados a um listener falham nas verificações de integridade, o CLB não consegue encaminhar requisições e retorna um erro 502. Verifique o status da verificação de integridade no console e solucione a causa da falha, como iptables ou software de segurança de terceiros bloqueando o bloco CIDR do sistema CLB 100.64.0.0/10, um código de status de verificação de integridade incompatível ou um caminho de verificação de integridade inexistente. Para obter mais informações, consulte CLB Health Check FAQ.

• Back-end retorna um código de erro que o CLB converte para 502: Se um servidor back-end retornar certos códigos de erro (como 504 ou 444), o CLB pode retornar um erro 502 ao cliente. Verifique o campo upstream_status no log de acesso para confirme o código de status real retornado pelo back-end e investigue a causa do erro no back-end.

• Erros no service back-end: Alta carga, respostas malformadas ou fechamentos inesperados de conexão no servidor back-end também podem causar erros 502. Verifique os logs e o uso de recursos do servidor back-end, como cpu e memória.

Solucionar erros 503

• Tráfego excede os limites da especificação da instância: O CLB retorna um erro 503 se o QPS, a largura de banda ou a taxa de novas conexões do tráfego recebido excederem os limites da especificação atual da instância CLB. Recupere essas métricas em CloudMonitor.

• Tráfego instantâneo excede limites, mas não aparece no monitoramento: O CloudMonitor exibe dados com granularidade de minuto e pode não mostrar picos no nível de segundos. Verifique a contagem de requisições por segundo no log de acesso. Se o upstream_status for "-", indica que a requisição não foi enviada ao servidor back-end.

Solucionar erros 504

• Tempo limite de resposta do back-end: Se o servidor back-end não responder dentro do período de tempo limite de requisição configurado para o listener, o CLB retorna um erro 504. Verifique o campo upstream_response_time no log de acesso para confirme o tempo de resposta real do back-end e ajuste o tempo limite de requisição do listener adequadamente.

• Tempo limite de conexão com o back-end: O tempo limite para uma instância CLB completar um handshake triplo tcp com uma instância ECS back-end é de 5 segundos. Se o upstream_response_time no log de acesso for muito longo, pode indicar um problema de conexão com o servidor back-end. Recomendamos capturar pacotes para investigar a causa.

• Alta carga no back-end: Alto uso de recursos (cpu, memória, etc.) no servidor back-end pode fazer com que os tempos de resposta excedam o período de tempo limite. Investigue e otimize o desempenho do service back-end, ou adicione mais servidores back-end para distribuir a carga.

Solucionar problemas de acesso ao CLB

Se você não conseguir acessar seu service após configure uma instância CLB, siga estas etapas para solucionar o problema camada por camada:

1. Verifique a resolução de nome de domínio: Se acessar o service usando um nome de domínio, certifique-se de que o nome de domínio resolve corretamente para o endereço de service da instância CLB. Utilize os comandos nslookup ou dig para verifique a resolução. Resolução incorreta de nome de domínio é um motivo comum para falhas de acesso.

2. Verifique a configuração do listener: No console CLB, verifique se um listener foi criado e confirme se a porta e o protocolo do listener estão configurados corretamente. Se um listener estiver ausente ou mal configurado, o CLB não poderá encaminhar requisições.

3. Verifique o status da verificação de integridade: No console CLB, verifique o status da verificação de integridade dos servidores back-end. Se todos os servidores back-end falharem nas verificações de integridade, o CLB não poderá encaminhar requisições.

4. Verifique as configurações de firewall: Verifique se o iptables ou software de segurança de terceiros no servidor back-end permite a porta do service back-end e o bloco CIDR do sistema CLB 100.64.0.0/10.

5. Verifique se o service back-end está funcionando corretamente: Faça login diretamente no servidor back-end e confirme se o service back-end está responsivo executando telnet <private IP address of the backend server> <port> (Camada 4) ou curl -I http://<private IP address of the backend server> (Camada 7).

6. Solucione problemas no link de rede: Teste o acesso ao endereço de service do CLB a partir de diferentes ambientes de rede. Se apenas sua rede local for afetada, execute um teste contínuo de ping ou use rastreamento de rota MTR para investigação adicional.

Acesso por ip, mas não por nome de domínio

O motivo mais comum é que o nome de domínio não concluiu seu registro ICP.

De acordo com os regulamentos, quando um nome de domínio é usado para acesso público na China continental, ele deve ter um registro ICP válido. O acesso a domínios sem registro ICP é bloqueado, resultando em um código de status 403 ou redefinição de conexão.

Recomendamos seguir estas etapas para solucionar e resolver o problema:

1. Verifique o status do registro ICP: Faça login no Alibaba Cloud ICP Filing System para verifique se seu nome de domínio concluiu o registro ICP. Caso contrário, conclua o processo primeiro. Para obter mais informações, consulte ICP filing process.

2. Verifique se precisa transferir seu registro ICP: Se seu nome de domínio possui um registro ICP com outro provedor de services cloud, mas você está usando-o com a Alibaba Cloud pela primeira vez, também deve concluir um transfer ICP filing para associar as informações de registro à Alibaba Cloud. A falha em concluir essa transferência também pode resultar em acesso bloqueado.

3. Elimine outras causas: Se o nome de domínio tiver um registro ICP e o registro ICP de transferência também estiver concluído, verifique se a resolução do nome de domínio aponta corretamente para o endereço de service do CLB (use o comando nslookup ou dig para verifique) e se a porta do listener CLB e a configuração de protocolo correspondem ao método de acesso ao domínio.

Impacto do controle de acesso no tráfego interno

Sim. O controle de acesso é aplicado no nível do listener e afeta tanto o tráfego interno quanto o público. Se você configure uma lista de permissões que permita apenas endereços ip públicos específicos, requisições de endereços ip internos que não estejam na lista de permissões serão bloqueadas. Para evitar interromper services internos, recomendamos adicionar os blocos CIDR internos relevantes à lista de permissões ou usar o Cloud Firewall para restringir o acesso público ao EIP.

Solucionar tempos limite de requisição durante testes de estresse

Ao testar a carga de um CLB da Camada 7, se você receber códigos de status 504 ou tempos limite de requisição, e o upstream_response_time nos logs estiver concentrado em torno de 5 segundos, o problema geralmente é um tempo limite de conexão causado por falha no handshake triplo tcp entre o CLB e o servidor back-end. Um motivo comum para isso é a tabela de rastreamento de conexões (nf_conntrack) no servidor back-end estar cheia, o que faz com que o servidor descarte pacotes para novas conexões.

Faça login no servidor back-end e verifique o log /var/log/messages. Confirme o problema se a seguinte mensagem de erro aparecer:

nf_conntrack: table full, dropping packet

Solução: Ajuste os valores dos seguintes parâmetros nf_conntrack com base nos requisitos reais do seu service:

sysctl -w net.netfilter.nf_conntrack_max=1048576
sysctl -w net.netfilter.nf_conntrack_buckets=262144
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=3600

Nota: O comando anterior tem efeito apenas temporariamente. As alterações são perdidas após a reinicialização da instância. Para tornar as alterações permanentes, grave os parâmetros em /etc/sysctl.conf.

Impacto de falhas de back-end em listeners compartilhados

Cenário: Você tem vários sites, como um site estático www.example.com e um site dinâmico app.example.com, anexados ao mesmo listener CLB. Quando o banco de dados back-end do site dinâmico falha, o site estático também se torna inacessível e retorna um erro HTTP 502.

Causa: Ambos os sites compartilham o mesmo listener, e o Health Check Domain Name do listener está configurado com o nome de domínio do site dinâmico. Quando o back-end do site dinâmico falha, todos os servidores back-end falham nas verificações de integridade. Como resultado, o CLB para de encaminhar tráfego para o back-end, afetando todos os sites configurados sob aquele listener.

Solução: Utilize instâncias CLB separadas para fornecer balanceamento de carga para os sites dinâmicos e estáticos, alcançando isolamento de negócios. Dessa forma, uma falha no site dinâmico não afetará o site estático.

Motivos para falha na persistência de sessão

• Persistência de sessão não está ativada: Verifique se a persistência de sessão está ativada na configuração do listener.

• Problemas com listener http/HTTPS: Para um listener http ou HTTPS, o CLB não consegue inserir o cookie necessário para persistência de sessão em uma resposta 4xx.

  Solução: Mude para um listener tcp, que usa o endereço ip de source do cliente para manter a persistência de sessão. Para maior confiabilidade, insira um cookie na instância ECS back-end e adicione uma verificação de validação de cookie.

• Problemas com redirecionamento 302: Um redirecionamento 302 pode alterar a string SERVERID usada para persistência de sessão.

  Se uma instância ECS back-end emitir um redirecionamento 302, isso pode alterar a string SERVERID no cookie injetado pelo CLB, quebrando a persistência de sessão.

  Como solucionar: Use as ferramentas de desenvolvedor do seu navegador ou um sniffer de pacotes para capturar requisições e respostas. Analise os pacotes para verifique respostas de redirecionamento 302 e compare as strings SERVERID nos cookies antes e depois do redirecionamento.

  Solução: Mude para um listener tcp, que usa o endereço ip de source do cliente para manter a persistência de sessão. Para maior confiabilidade, insira um cookie na instância ECS back-end e adicione uma verificação de validação de cookie.

• O tempo limite de persistência de sessão é muito curto: Se o valor do tempo limite for definido muito baixo, a persistência de sessão pode falhar.

Visualizar a string de persistência de sessão

Utilize as ferramentas de desenvolvedor do seu navegador (F12) para verifique se os cabeçalhos de resposta contêm a string SERVERID ou uma palavra-chave personalizada. Alternativamente, execute o comando curl www.example.com -c /tmp/cookie123 para salve o cookie e, em seguida, execute curl www.example.com -b /tmp/cookie123 para enviar o cookie na próxima requisição.

Testar persistência de sessão com curl

1. Crie uma página de teste.

   Em cada instância ECS back-end, crie uma página de teste que exiba o endereço ip privado da instância. Esse endereço identifica qual servidor está lidando com uma requisição. Se o endereço ip for consistente em várias requisições, a persistência de sessão está funcionando.

   

2. Execute o comando curl em um sistema Linux.

   Suponha que o endereço ip de service do CLB seja 10.170.XX.XX e a url da página de teste seja http://10.170.XX.XX/check.jsp.

   1. Faça login no servidor Linux que você usará para testes.

   2. Execute o seguinte comando para recuperar o cookie do balanceador de carga.

      curl -c test.cookie http://10.170.XX.XX/check.jsp

      Nota

      Por padrão, o CLB usa injeção de cookie para persistência de sessão. No entanto, o curl não salve nem envia cookies por padrão. Salve o cookie antes de testar. Caso contrário, as requisições subsequentes do curl serão enviadas sem cookie, levando a roteamento aleatório, o que pode fazer você concluir incorretamente que a persistência de sessão não está funcionando.

   3. Execute o seguinte comando para realizar testes contínuos.

      for ((a=1;a<=30;a++));
          do curl  -b test.cookie http://10.170.XX.XX/check.jsp  | grep '10.170.XX.XX';
          sleep 1;
      done

      Nota

      Em a≤30, 30 é o número de testes repetidos e pode ser modificado conforme necessário. O comando grep '10.170.XX.XX' filtra as informações de ip exibidas. Altere 10.170.XX.XX para o endereço ip privado da instância ECS back-end.

   4. Observe os endereços ip retornados pelo teste. Se todas as respostas vierem do mesmo endereço ip privado do servidor back-end, a persistência de sessão está funcionando corretamente. Caso contrário, a persistência de sessão não está funcionando corretamente.

Configurar cookies de back-end para o modo **Rewrite Cookie**

Se selecione o modo Rewrite Cookie para persistência de sessão da Camada 7, configure um cookie com o mesmo nome em seus servidores back-end. O nome do cookie deve ser idêntico ao configurado no console CLB. Os exemplos a seguir mostram como configure isso em servidores web comuns:

server {
    listen 8080;
    server_name wqwq.example.com;
    location / {
        add_header Set-Cookie name=xxxx;
        root   html;
        index  index.html index.htm;
    }
}

Solucionar carga desigual entre servidores

Se você tiver vários servidores back-end anexados a uma instância CLB e um servidor tiver uma carga significativamente maior que os outros, siga estas etapas para solucionar o problema:

1. Verifique se a persistência de sessão está ativada: Listeners http/HTTPS do CLB suportam persistência de sessão por meio de injeção de cookie. Quando a persistência de sessão está ativada, todas as requisições do mesmo cliente são roteadas para o mesmo servidor back-end. Se alguns clientes gerarem um grande número de requisições, isso concentra o tráfego em servidores back-end específicos, levando a uma carga desigual.

2. Desative a persistência de sessão para distribuição uniforme: Se seu aplicativo não depender do estado da sessão (como cookies ou estado de login), desative a persistência de sessão para o listener. Uma vez desativada, o CLB distribui requisições uniformemente para todos os servidores back-end com base no algoritmo de agendamento configurado, como round-robin ponderado. Realize essa ação fora dos horários de pico e verifique imediatamente se seu aplicativo permanece disponível. Desativar a persistência de sessão afetará services com estado, como carrinhos de compras ou logins persistentes. Avalie a dependência do seu aplicativo em relação à persistência de sessão antes de prosseguir.

3. Verifique a carga do aplicativo nos servidores back-end: Mesmo que o CLB distribua o tráfego uniformemente, diferenças no uso de cpu, memória ou outros recursos nos próprios servidores back-end podem fazer com que alguns servidores experimentem uma carga maior. Faça login em cada servidor back-end, compare o uso de recursos de seus aplicativos e verifique se há gargalos de desempenho.

Estilos falham ao carregar via HTTPS

Sintoma:

Você tem um listener http e um HTTPS, ambos usando os mesmos servidores back-end. Ao acessar o site pelo listener http, ele é exibido corretamente. No entanto, ao acessar o site pelo listener HTTPS, o layout aparece quebrado.

Causa:

Um balanceador de carga não bloqueia arquivos JavaScript (JS) por padrão. Esse problema pode ser causado pelo seguinte:

• O certificado não é compatível com o nível de segurança do navegador.

• O certificado é de um provedor terceirizado não confiável. Entre em contato com o emissor para resolver isso.

Solução:

1. Ao abrir o site, siga os avisos do navegador para carregar os scripts.

2. Adicione o certificado correspondente ao armazenamento de confiança do cliente.

Certificados de servidor back-end para redirecionamento de http para HTTPS

Não. Você só precisa configure um certificado no listener HTTPS da instância CLB. Para obter mais informações, consulte Configure an SSL certificate.

Navegador mostra expiração antiga do certificado após atualização

Isso geralmente ocorre se a instância CLB estiver integrada transparentemente com o WAF 2.0 e o certificado do WAF não tiver sido atualizado. O WAF sincroniza certificados do CLB periodicamente. Para acionar uma sincronização imediata, desative e reative o redirecionamento de tráfego no console WAF para forçar uma atualização do certificado. Essa ação pode causar uma breve interrupção do service, durando de 1 a 2 segundos.

Versão do protocolo http para acesso ao servidor back-end

• Se uma requisição de cliente usar http/1,1 ou http/2,0, o listener da Camada 7 se comunicará com o servidor back-end usando http/1,1.

• Se uma requisição de cliente usar uma versão de protocolo diferente de http/1,1 ou http/2,0, o listener da Camada 7 se comunicará com o servidor back-end usando http/1,0.

Recuperar a versão do protocolo do cliente

Sim.

Limitação baseada em url

O CLB não suporta limitação baseada em url, apenas limitação de largura de banda no nível do listener.

O ALB suporta limitação baseada em url. Você pode configure a listener forwarding rule para aplicar limitação de QPS a um caminho específico. Esse recurso deve ser usado em conjunto com a ação "Forward to". Veja a figura a seguir:

O CLB suporta SSE (Server-Sent Events)?

SSE (Server-Sent Events) é uma tecnologia baseada em http que permite aos servidores enviar dados aos clientes unilateralmente. É comumente usada em cenários de streaming de dados em tempo real.

• CLB da Camada 7 suporta o protocolo SSE.

• CLB da Camada 4 não suporta o protocolo SSE.

Restrições de uso: Listeners da Camada 7 do CLB suportam SSE, mas não suportam o uso de SSE sobre conexões persistentes http (keep-alive). Utilize conexões de curta duração.

O campo Transfer-Encoding: chunked

Transfer-Encoding: chunked é um campo padrão do protocolo http indicando que o corpo da mensagem é enviado usando transferência fragmentada. O CLB da Camada 7 é um proxy reverso construído no Tengine. Ao encaminhar requisições para um servidor back-end, ele usa transferência fragmentada. Portanto, o servidor back-end recebe esse campo no cabeçalho da requisição. Este é um comportamento normal para um proxy reverso e não afeta seus services. Um CLB da Camada 4 apenas encaminha tráfego e não adiciona esse campo.

Campos de cabeçalho de resposta removidos

Para implementar persistência de sessão, o CLB remove campos como Date, Server, X-Pad, e X-Accel-Redirect do cabeçalho de resposta. Para reter esses campos, adicione um prefixo aos seus cabeçalhos de resposta personalizados, como xl-server, ou mude para um listener tcp da Camada 4.

proxy_buffering e proxy_cache

Os recursos proxy_buffering e proxy_cache não estão ativados para o CLB. O CLB não armazena em buffer ou cache dados de requisição ou resposta. Em vez disso, ele encaminha requisições de clientes diretamente para servidores back-end em um modo de encaminhamento transparente. Este é o comportamento padrão do CLB e não requer configuração adicional.

Ativar proteção WAF para CLB

Impacto de desativar a ENI pública

Se uma instância ECS tiver um ip público, desativar sua interface de rede elástica pública afeta o service de balanceador de carga.

Isso ocorre porque, se existir uma interface de rede elástica pública, a rota padrão direciona o tráfego pela rede pública. Desativar a interface impede que pacotes de resposta sejam enviados de volta, o que interrompe o service de balanceador de carga. Recomendamos não desativar a interface de rede elástica pública. Se precisar desativá-la, altere a rota padrão para a rede privada para evitar interrupção do service. No entanto, considere se seus services dependem de acesso à rede pública, por exemplo, para acessar o rds.

Suporte a requisições de cliente com campo TOA

Não. Um campo tcp Option Address (TOA) fornecido pelo cliente entra em conflito com o campo TOA que o balanceador de carga usa para comunicação interna. Esse conflito impede que o servidor back-end obtenha o endereço ip real do cliente.