Como o Elastic Load Balancing funciona

Um balanceador de carga aceita tráfego de entrada de clientes e encaminha solicitações para seus destinos registrados (como EC2 instâncias) em uma ou mais zonas de disponibilidade. O load balancer também monitora a integridade de seus destinos registrados e roteia o tráfego apenas para destinos íntegros. Quando o load balancer detecta um destino não íntegro, ele interrompe o roteamento do tráfego para esse destino. Depois, ele retoma o roteamento do tráfego para esse destino quando detecta que o destino está íntegro novamente.

Você configura seu load balancer para aceitar o tráfego de entrada especificando um ou mais listeners. Um listener é um processo que verifica se há solicitações de conexão. Ele é configurado com um protocolo e um número de porta para as conexões de clientes com o load balancer. Da mesma forma, ele é configurado com um protocolo e um número de porta para conexões do load balancer com os destinos.

O Elastic Load Balancing é compatível com os seguintes tipos de balanceadores de carga:

• Application Load Balancers

• Network Load Balancers

• Balanceadores de carga de gateway

• Classic Load Balancers

Há uma diferença fundamental em como os tipos de balanceadores de carga são configurados. Com Application Load Balancers, Network Load Balancers e Gateway Load Balancers, você registra destinos em grupos de destino e roteia o tráfego para os grupos de destino. Com Classic Load Balancers, você registra as instâncias diretamente no balanceador de carga.

Zonas de disponibilidade e nós de balanceador de carga

Quando você habilita uma zona de disponibilidade para seu balanceador de carga, o Elastic Load Balancing cria um nó de balanceador de carga na zona de disponibilidade. Se você registrar destinos em uma Zona de disponibilidade mas não ativá-la, esses destinos registrados não receberão tráfego. O load balancer é mais eficaz se você garantir que cada zona de disponibilidade habilitada tenha pelo menos um destino registrado.

Recomendamos habilitar várias zonas de disponibilidade para todos os balanceadores de carga. No entanto, com um Application Load Balancer, é necessário que você habilite pelo menos duas ou mais zonas de disponibilidade. Essa configuração ajuda a garantir que o load balancer possa continuar a rotear o tráfego. Se uma zona de disponibilidade ficar indisponível ou não tiver destinos íntegros, o load balancer poderá continuar a rotear o tráfego para destinos íntegros de outra zona de disponibilidade.

Depois de desabilitar uma zona de disponibilidade, os destinos nessa zona de disponibilidade permanecem registrados com o load balancer. No entanto, mesmo que permaneçam registrados, o load balancer não roteará o tráfego para eles.

Balanceamento de carga entre zonas

Os nós do load balancer distribuem solicitações de clientes para destinos registrados. Quando o balanceamento de carga entre zonas estiver habilitado, cada nó do load balancer distribuirá o tráfego aos destinos registrados em todas as zonas de disponibilidade habilitadas. Quando o balanceamento de carga entre zonas estiver desabilitado, cada nó do load balancer distribuirá o tráfego somente para os destinos registrados na respectiva zona de disponibilidade.

Os diagramas a seguir demonstram o efeito do balanceamento de carga entre zonas com ida e volta como o algoritmo padrão de roteamento. Há duas zonas de disponibilidade habilitadas, com dois destinos na zona de disponibilidade A e oito destinos na zona de disponibilidade B. Os clientes enviam solicitações e o Amazon Route 53 responde a cada solicitação com o endereço IP de um dos nós do balanceador de carga. Com base no algoritmo de roteamento de ida e volta, o tráfego é distribuído de modo que cada nó do balanceador de carga receba 50% do tráfego dos clientes. Cada nó de load balancer distribui a respectiva parcela de tráfego entre os destinos registrados no escopo.

Caso o balanceamento de carga entre zonas esteja habilitado, cada um dos dez destinos recebe 10% do tráfego. Isso ocorre porque cada nó do load balancer pode rotear 50% do tráfego do cliente para todos os dez destinos.

Quando o balanceamento de carga entre zonas está desabilitado:

• Cada um dos dois destinos na zona de disponibilidade A recebe 25% do tráfego.

• Cada um dos oito destinos na zona de disponibilidade B recebe 6,25% do tráfego.

Isso ocorre porque cada nó do load balancer pode rotear 50% do tráfego do cliente apenas para destinos na respectiva zona de disponibilidade.

Com os Application Load Balancers, o balanceamento de carga entre zonas sempre está habilitado por balanceador de carga. É possível desabilitar o balanceamento de carga entre zonas por grupo de destino. Para obter mais informações, consulte Desativar o balanceamento de carga entre zonas no Guia do usuário de Application Load Balancers.

Com Network Load Balancers e Gateway Load Balancers, o balanceamento de carga entre zonas é desabilitado por padrão. Depois de criar o balanceador de carga, você pode habilitar ou desabilitar o balanceamento de carga entre zonas a qualquer momento.

Quando você cria um Classic Load Balancer, o padrão para balanceamento de carga entre zonas depende de como você cria o balanceador de carga. Com o API ouCLI, o balanceamento de carga entre zonas é desativado por padrão. Com o AWS Management Console, a opção de ativar o balanceamento de carga entre zonas é selecionada por padrão. Depois de criar um Classic Load Balancer, você pode habilitar ou desabilitar o balanceamento de carga entre zonas a qualquer momento. Para obter mais informações, consulte Habilitar o balanceamento de carga entre zonas no Guia do usuário de Classic Load Balancers.

Mudança de zona

A mudança zonal é um recurso no Amazon Application Recovery Controller (ARC) (ARC). Com a mudança de zona, você pode retirar um recurso do balanceador de carga de uma zona de disponibilidade prejudicada com uma única ação. Dessa forma, é possível continuar a operar em outras zonas de disponibilidade íntegras em uma Região da AWS.

Quando você inicia uma mudança de zona, o balanceador de carga para de enviar o tráfego do recurso para a zona de disponibilidade afetada. ARCcria a mudança zonal imediatamente. No entanto, a efetivação das conexões existentes e em andamento na zona de disponibilidade afetada pode levar algum tempo, normalmente alguns minutos. Para obter mais informações, consulte Como funciona uma mudança de zona: verificações de saúde e endereços IP zonais no Guia do desenvolvedor do Amazon Application Recovery Controller (ARC).

As mudanças de zona só são compatíveis com Application Load Balancers e Network Load Balancers com o balanceamento de carga entre zonas desativado. Caso ative o balanceamento de carga entre zonas, você não poderá iniciar uma mudança de zona. Para obter mais informações, consulte Recursos suportados para mudanças zonais no Guia do desenvolvedor do Amazon Application Recovery Controller (ARC).

Antes de usar uma mudança de zona, analise o seguinte:

• O balanceamento de carga entre zonas não é compatível com mudanças de zona. Você deve desativar o balanceamento de carga entre zonas para usar esse recurso.

• A mudança de zona não é compatível quando você usa um Application Load Balancer como um endpoint do acelerador no AWS Global Accelerator.

• Você pode iniciar uma mudança de zona para um balanceador de carga específico somente para uma única zona de disponibilidade. Você não pode iniciar uma mudança de zona para várias zonas de disponibilidade.

• AWS remove proativamente os endereços IP do balanceador de carga zonal DNS quando vários problemas de infraestrutura afetam os serviços. Antes de iniciar uma mudança de zona, sempre verifique a capacidade atual da zona de disponibilidade. Se os balanceadores de carga estiverem com o balanceamento de carga entre zonas desativado e você usar uma mudança de zona para remover o endereço IP de um balanceador de carga de zona, a zona de disponibilidade afetada pela mudança de zona também perderá a capacidade de destino.

• Quando um Application Load Balancer for o destino de um Network Load Balancer, sempre inicie a mudança de zona pelo Network Load Balancer. Se você iniciar uma mudança de zona pelo Application Load Balancer, o Network Load Balancer não reconhecerá a mudança e continuará a enviar tráfego para o Application Load Balancer.

Para obter mais orientações e informações, consulte as melhores práticas com mudanças ARC zonais do Route 53 no Guia do desenvolvedor do Amazon Application Recovery Controller (ARC).

Roteamento de solicitações

Antes de um cliente enviar uma solicitação ao seu balanceador de carga, ele resolve o nome de domínio do balanceador de carga usando um servidor Domain Name System ()DNS. A DNS entrada é controlada pela Amazon, porque seus balanceadores de carga estão no amazonaws.com domínio. Os DNS servidores da Amazon retornam um ou mais endereços IP para o cliente. Esses são os endereços IP dos nós do load balancer para o seu load balancer. Com os Network Load Balancers, o Elastic Load Balancing cria uma interface de rede para cada zona de disponibilidade que você habilita e a usa para obter um endereço IP estático. Opcionalmente, você pode associar um endereço IP elástico a cada interface de rede ao criar o Network Load Balancer.

Conforme o tráfego para seu aplicativo muda com o tempo, o Elastic Load Balancing escala seu balanceador de carga e atualiza a entrada. DNS A DNS entrada também especifica o time-to-live (TTL) de 60 segundos. Isso ajuda a garantir que os endereços IP possam ser remapeados rapidamente em resposta às alterações de tráfego.

O cliente determina qual endereço IP usar para enviar solicitações para o load balancer. O nó do load balancer que recebe a solicitação seleciona um destino íntegro registrado e envia a solicitação para o destino usando seu endereço IP privado.

Para obter mais informações, consulte Roteamento de tráfego para um balanceador de ELB carga no Guia do desenvolvedor do Amazon Route 53.

Algoritmo de roteamento

Com Application Load Balancers, o nó do balanceador de carga que recebe a solicitação aplica o seguinte processo:

1. Avalia as regras de listener em ordem de prioridade para determinar qual regra aplicar.

2. Seleciona um destino do grupo de destino para a ação da regra, usando o algoritmo de roteamento configurado para o grupo de destino. O algoritmo de roteamento padrão é o round robin. O roteamento é realizado de forma independente para cada grupo de destino, até mesmo quando um destino é registrado com vários grupos de destino.

Com Network Load Balancers, o nó do balanceador de carga que recebe a conexão aplica o seguinte processo:

1. Seleciona um destino do grupo de destino para a regra padrão usando um algoritmo de hash de fluxo. Ele baseia o algoritmo:

   • No protocolo.

   • No endereço IP de origem e na porta de origem

   • No endereço IP de destino e na porta de destino

   • O número TCP de sequência

2. Encaminha cada TCP conexão individual para um único destino durante toda a vida útil da conexão. As TCP conexões de um cliente têm portas de origem e números de sequência diferentes e podem ser roteadas para destinos diferentes.

Com Classic Load Balancers, o nó do balanceador de carga que recebe a solicitação seleciona uma instância registrada da seguinte maneira:

• Usa o algoritmo de roteamento round robin para ouvintes TCP

• Usa o algoritmo de roteamento de solicitações menos pendentes para HTTP e HTTPS ouvintes

HTTPconexões

Os Classic Load Balancers usam conexões pré-abertas, mas os Application Load Balancers não. Tanto os Classic Load Balancers quanto os Application Load Balancers usam multiplexação de conexão. Isso significa que solicitações de vários clientes em várias conexões front-end podem ser roteadas para um determinado destino por meio de uma única conexão back-end. A multiplexação de conexão melhora a latência e reduz a carga em seus aplicativos. Para evitar a multiplexação de conexão, desative HTTP keep-alive os cabeçalhos definindo o Connection: close cabeçalho em suas respostas. HTTP

Os balanceadores de carga de aplicativos e os balanceadores de carga clássicos oferecem suporte a conexões de pipeline HTTP em front-end. Eles não oferecem suporte a conexões de back-end HTTP em pipelines.

Os Application Load Balancers oferecem suporte aos seguintes métodos de HTTP solicitação: GET HEADPOST,PUT,DELETE,,OPTIONS, e. PATCH

Os Application Load Balancers oferecem suporte aos seguintes protocolos em conexões front-end: HTTP /0.9, HTTP /1.0, /1.1 e /2. HTTP HTTP Você pode usar HTTP /2 somente com HTTPS ouvintes e pode enviar até 128 solicitações em paralelo usando uma conexão HTTP /2. Os Application Load Balancers também oferecem suporte a atualizações de conexão de HTTP para. WebSockets No entanto, se houver um upgrade de conexão, as regras e AWS WAF integrações de roteamento de ouvintes do Application Load Balancer não se aplicarão mais.

Os Application Load Balancers usam HTTP /1.1 em conexões de back-end (balanceador de carga para o destino registrado) por padrão. No entanto, você pode usar a versão do protocolo para enviar a solicitação aos destinos usando HTTP /2 ou g. RPC Para obter mais informações, consulte Versões de protocolo. Por padrão, o cabeçalho keep-alive é compatível com conexões de back-end. Para solicitações HTTP /1.0 de clientes que não têm um cabeçalho de host, o balanceador de carga gera um cabeçalho de host para as solicitações HTTP /1.1 enviadas nas conexões de back-end. O cabeçalho do host contém o DNS nome do balanceador de carga.

Os Classic Load Balancers oferecem suporte aos seguintes protocolos em conexões front-end (cliente para balanceador de carga): HTTP /0.9, /1.0 e /1.1. HTTP HTTP Eles usam HTTP /1.1 em conexões de back-end (balanceador de carga para o destino registrado). Por padrão, o cabeçalho keep-alive é compatível com conexões de back-end. Para solicitações HTTP /1.0 de clientes que não têm um cabeçalho de host, o balanceador de carga gera um cabeçalho de host para as solicitações HTTP /1.1 enviadas nas conexões de back-end. O cabeçalho do host contém o endereço IP do nó do balanceador de carga.

HTTPcabeçalhos

Os Application Load Balancers e Classic Load Balancers adicionam automaticamente os cabeçalhos X-Forwarded-For, X-Forwarded-Proto e X-Forwarded-Port à solicitação.

Os Application Load Balancers convertem os nomes de HTTP host nos cabeçalhos do host em letras minúsculas antes de enviá-los aos destinos.

Para conexões front-end que usam HTTP /2, os nomes dos cabeçalhos estão em minúsculas. Antes de a solicitação ser enviada ao destino usando HTTP /1.1, os seguintes nomes de cabeçalho são convertidos em letras maiúsculas e minúsculas: X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Port, Host, X-Amzn-Trace-Id, Upgrade e Connection. Todos os outros nomes de cabeçalho estão em minúsculas.

Os Application Load Balancers e Classic Load Balancers diferenciam o cabeçalho de conexão da solicitação de entrada do cliente após enviar um proxy da resposta de volta para o cliente.

Quando os Application Load Balancers e Classic Load Balancers que usam HTTP /1.1 recebem um cabeçalho Expect: 100-Continue, eles respondem imediatamente com HTTP/1.1 100 Continue sem testar o cabeçalho do tamanho do conteúdo. O cabeçalho da solicitação Expect: 100-Continue não é encaminhado para seus destinos.

Ao usar HTTP /2, os Application Load Balancers não oferecem suporte ao cabeçalho Expect: 100-Continue das solicitações do cliente. O Application Load Balancer não responderá com HTTP/2 100 Continue nem encaminhará esse cabeçalho para seus destinos.

HTTPlimites de cabeçalho

Os seguintes limites de tamanho para Application Load Balancers são limites inflexíveis e que não podem ser alterados:

• Linha de solicitação: 16 K

• Cabeçalho único: 16 K

• Cabeçalho de resposta inteiro: 32 K

• Cabeçalho da solicitação inteira: 64 K

Esquema do balanceador de carga

Ao criar um load balancer, você deverá optar se deve fazer dele um load balancer interno ou um load balancer voltado para a Internet.

Os nós de um load balancer voltado para a Internet têm endereços IP públicos. O DNS nome de um balanceador de carga voltado para a Internet pode ser resolvido publicamente nos endereços IP públicos dos nós. Portanto, os load balancers voltados para a Internet podem rotear solicitações de clientes pela Internet.

Os nós de um load balancer interno têm somente endereços IP privados. O DNS nome de um balanceador de carga interno pode ser resolvido publicamente nos endereços IP privados dos nós. Portanto, os balanceadores de carga internos só podem rotear solicitações de clientes com acesso ao VPC para o balanceador de carga.

Tanto os load balancers voltados para a Internet quanto os internos roteiam as solicitações para seus destinos usando endereços IP privados. Portanto, seus destinos não precisam de endereços IP públicos para receber solicitações de um load balancer interno ou voltado para a Internet.

Se o seu aplicativo tiver vários níveis, você poderá projetar uma arquitetura que use load balancers internos e load balancers voltados para a Internet. Por exemplo, isso é válido se o aplicativo usa servidores da web que devem estar conectados à Internet e servidores de aplicativos que estão conectados somente aos servidores da web. Crie um load balancer voltado para a Internet e registre os servidores da web nele. Crie um load balancer interno e registre os servidores de aplicativos nele. Os servidores da web recebem solicitações do load balancer voltado para a Internet e enviam solicitações dos servidores de aplicativos para o load balancer interno. Os servidores de aplicativos recebem solicitações do load balancer interno.

Rede MTU para seu balanceador de carga

A unidade máxima de transmissão (MTU) determina o tamanho, em bytes, do maior pacote que pode ser enviado pela rede. Quanto maior MTU a conexão, mais dados podem ser passados em um único pacote. Os frames de Ethernet consistem no pacote, ou nos próprios dados que você envia, e nas informações de overhead de rede que o cercam. O tráfego enviado por um gateway de internet tem um MTU valor de 1500. Isso significa que, se um pacote tiver mais de 1500 bytes, ele será fragmentado para ser enviado usando vários frames ou será descartado se Don't Fragment estiver definido no cabeçalho IP.

O MTU tamanho dos nós do balanceador de carga não é configurável. Os quadros jumbo (9001MTU) são padrão em todos os nós do balanceador de carga para balanceadores de carga de aplicativos, balanceadores de carga de rede e balanceadores de carga clássicos. Os balanceadores de carga de gateway suportam MTU 8500. Para obter mais informações, consulte Unidade máxima de transmissão (MTU) no Guia do usuário para balanceadores de carga de gateway.

O caminho MTU é o tamanho máximo do pacote suportado no caminho entre o host de origem e o host receptor. O Path MTU Discovery (PMTUD) é usado para determinar o caminho MTU entre dois dispositivos. O Path MTU Discovery é especialmente importante se o cliente ou o destino não suportar quadros jumbo.

Quando um host envia um pacote maior que o MTU do host receptor ou maior que o MTU de um dispositivo ao longo do caminho, o host ou dispositivo receptor descarta o pacote, e então retorna a seguinte ICMP mensagem:. Destination Unreachable: Fragmentation Needed and Don't Fragment was Set (Type 3, Code 4) Isso instrui o host de transmissão a dividir a carga útil em vários pacotes menores e retransmiti-los.

Se pacotes maiores que o MTU tamanho da interface cliente ou de destino continuarem sendo descartados, é provável que o Path MTU Discovery (PMTUD) não esteja funcionando. Para evitar isso, certifique-se de que o Path MTU Discovery esteja funcionando de ponta a ponta e que você tenha habilitado jumbo frames em seus clientes e destinos. Para obter mais informações sobre o Path MTU Discovery e a habilitação de jumbo frames, consulte Path MTU Discovery no Guia EC2 do usuário da Amazon.