O Classic Load Balancer (CLB) opera em clusters distribuídos por regiões e oferece balanceamento de carga nas camadas 4 (TCP/UDP) e 7 (HTTP/HTTPS). Sua arquitetura baseada em cluster sincroniza sessões entre os nodes, elimina pontos únicos de falha (SPOFs) e mantém os serviços disponíveis durante manutenções, upgrades e falhas de nodes.
Como funciona
O CLB utiliza tecnologias distintas em cada camada:
Camada | Protocolo | Tecnologia | Descrição |
Camada 4 | TCP, UDP | Linux Virtual Server (LVS) + Keepalived | Stack open-source, personalizado para atender aos requisitos de escala da nuvem |
Camada 7 | HTTP, HTTPS | Tengine | Servidor web baseado em NGINX desenvolvido pelo Taobao, otimizado para sites de alto tráfego |
Em cada região, o cluster da camada 4 reúne vários servidores físicos LVS. Essa arquitetura preserva a disponibilidade e a escalabilidade mesmo quando nodes individuais falham ou ficam offline para manutenção.
Sincronização de sessão
Cada node do cluster LVS utiliza pacotes multicast para sincronizar sessões com todos os demais nodes. No exemplo a seguir, depois que o cliente envia três pacotes, a Session A estabelecida no LVS1 é sincronizada em todo o cluster. As linhas contínuas representam as conexões ativas; as tracejadas indicam os caminhos de failover para nodes saudáveis (LVS2) quando o LVS1 falha ou entra em manutenção.
Esse design permite executar hot upgrades, diagnosticar servidores individualmente e tirar nodes do ar — tudo sem interromper as suas aplicações.
Se uma conexão não for estabelecida por falha no three-way handshake, ou se uma conexão já estabelecida não tiver suas sessões sincronizadas durante um hot upgrade, seus serviços poderão ser interrompidos. Nesse caso, inicie uma nova solicitação de conexão a partir do cliente.
Fluxo de tráfego de entrada
O CLB distribui o tráfego de entrada com base nas regras de encaminhamento configuradas no CLB console ou por meio de operações de API.
Figura 1. Fluxo de tráfego de entrada
Todo o tráfego de entrada — TCP, UDP, HTTP e HTTPS — passa primeiro pelo cluster da camada 4. O cluster distribui o tráfego de forma uniforme entre os nodes e sincroniza as sessões para garantir alta disponibilidade. A partir daí, o caminho depende do tipo de listener:
Listeners TCP/UDP: o cluster da camada 4 distribui as solicitações diretamente para as instâncias backend do Elastic Compute Service (ECS), conforme as suas regras de encaminhamento.
Listeners HTTP: o cluster da camada 4 encaminha as solicitações para o cluster da camada 7, que então as distribui para as instâncias backend do ECS, conforme as suas regras de encaminhamento.
Listeners HTTPS: o caminho é o mesmo do HTTP, mas o Key Server valida os certificados e descriptografa os pacotes de dados antes que as solicitações cheguem às instâncias backend do ECS.
Fluxo de tráfego de saída
O CLB e as instâncias backend do ECS se comunicam pela rede interna.
Figura 2. Fluxo de tráfego de saída
Um princípio geral para o tráfego de saída: o tráfego sai pelo mesmo caminho por onde entra.
Tráfego pelo CLB:
O throttling e o faturamento ocorrem no nível da instância CLB.
A comunicação interna entre o CLB e as instâncias backend do ECS é gratuita.
Tráfego pelos recursos públicos do ECS:
Se as suas instâncias ECS atendem apenas ao tráfego distribuído pelo CLB, não é necessário adquirir endereços IP públicos, elastic IP addresses (EIPs), Anycast EIPs ou NAT gateways. Nenhuma cobrança por tráfego de Internet será gerada, mesmo que apareçam estatísticas de tráfego na elastic network interface (ENI).
Se as suas instâncias ECS precisam atender diretamente a solicitações externas ou acessar a Internet, configure um endereço IP público, EIP, Anycast EIP ou NAT gateway nas instâncias.
O tráfego oriundo de EIPs ou NAT gateways é cobrado separadamente, e você pode aplicar throttling de velocidade nesses recursos. Se houver banda pública configurada nas instâncias ECS, o tráfego é cobrado e submetido a throttling no nível da instância.
As instâncias ECS criadas anteriormente recebem endereços IP públicos diretamente, o que pode ser verificado executando ipconfig. Se essas instâncias atendem ao tráfego externo apenas por meio do CLB, nenhuma cobrança por tráfego de Internet será gerada, mesmo que as estatísticas de tráfego da ENI estejam visíveis.
O CLB oferece suporte somente ao acesso responsivo à Internet. As instâncias backend do ECS só acessam a Internet quando precisam responder a solicitações vindas dela. Essas solicitações chegam às instâncias backend do ECS por meio das instâncias CLB. Para acesso ativo à Internet, associe um EIP ou utilize um NAT gateway.
Os recursos de banda pública configurados para instâncias ECS, EIPs, Anycast EIPs e NAT gateways permitem que as instâncias ECS acessem a Internet ou sejam acessadas a partir dela, mas esses recursos não distribuem nem balanceiam tráfego.
FAQ
A largura de banda máxima definida na compra do CLB se aplica ao tráfego de entrada e de saída somados?
Não. A largura de banda máxima se aplica de forma independente ao tráfego de entrada e ao tráfego de saída. Cada direção pode atingir o valor máximo configurado sem afetar a outra.
Para mais detalhes, consulte Bandwidth limits.