As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

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.

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:

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. Para obter mais informações, consulte Cross-zone load balancing no Guia do usuário de Network Load Balancers.

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 a API ou a CLI, 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 de zona é um recurso do Amazon Application Recovery Controller (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. O ARC cria a mudança de zona 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 How a zonal shift works: health checks and zonal IP addresses no Guia do desenvolvedor do Amazon Application Recovery Controller (ARC).

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

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

Roteamento de solicitações

Antes de um cliente enviar uma solicitação para seu load balancer, ele resolverá o nome de domínio do load balancer usando um servidor Domain Name System (DNS, Sistema de Nomes de Domínios) do servidor. A entrada do DNS é controlada pela Amazon, pois seus load balancers estão no domínio amazonaws.com. Os servidores DNS da Amazon retornam um ou mais endereços IP ao 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 ocorram mudanças no tráfego para sua aplicação ao longo do tempo, o Elastic Load Balancing dimensionará o balanceador de carga e atualizará a entrada do DNS. A entrada DNS 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 Rotear tráfego para um balanceador de carga ELB 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:

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

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

Conexões HTTP

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 backend. 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, desabilite os cabeçalhos keep-alive HTTP definindo o cabeçalho Connection: close em suas respostas HTTP.

Os Application Load Balancers e os Classic Load Balancers são compatíveis com HTTP canalizado em conexões de front-end. Eles não são compatíveis com HTTP com pipeline em conexões backend.

Os Application Load Balancers são compatíveis com os seguintes métodos de solicitação HTTP: GET, HEAD, POST, PUT, DELETE, OPTIONS e PATCH.

Os Application Load Balancers são compatíveis com os seguintes protocolos em conexões de front-end: HTTP/0.9, HTTP/1.0, HTTP/1.1 e HTTP/2. É possível usar HTTP/2 somente com listeners HTTPS e 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 o. 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 backend (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 gRPC. Para obter mais informações, consulte Versões de protocolo. Por padrão, o cabeçalho keep-alive é compatível com conexões de backend. Para solicitações HTTP/1.0 de clientes que não tenham um cabeçalho de host, o load balancer gerará um cabeçalho de host para as solicitações HTTP/1.1 enviadas nas conexões backend. O cabeçalho do host contém o nome DNS do balanceador de carga.

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

Cabeçalhos HTTP

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 host nos cabeçalhos de host HTTP em letras minúsculas antes de enviá-los aos destinos.

Para conexões front-end que usam HTTP/2, os nomes de cabeçalho estão em minúsculas. Antes de enviar a solicitação ao destino usando HTTP/1.1, os seguintes nomes de cabeçalhos são convertidos para letras maiúsculas e minúsculas: X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Port, Host, X-Amzn-Trace-Id, Upgrade e Conexão. 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 comprimento do cabeçalho 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 são compatíveis com o 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.

Limites de cabeçalho HTTP

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

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 nome DNS de um load balancer voltado para a Internet é resolvível publicamente para os 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 nome DNS de um load balancer interno é resolvido publicamente para os endereços IP privados dos nós. Portanto, load balancers internos só podem rotear solicitações de clientes com acesso à VPC para o load balancer.

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.

Tipos de endereço IP

O tipo de endereço IP que você especifica para o balanceador de carga determina como os clientes podem se comunicar com o balanceador de carga.

A tabela a seguir descreve os endereços IP compatíveis com cada tipo de balanceador de carga.

O tipo de endereço IP especificado para o grupo de destino determina como o balanceador de carga pode se comunicar com os destinos.

A tabela a seguir descreve os tipos de endereço IP compatíveis com cada protocolo de grupo de destino.

MTU de rede 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 a MTU de uma conexão, mais dados podem ser passados em um único pacote. Os quadros de Ethernet consistem no pacote, ou nos dados em si que você envia, e nas informações de overhead de rede que o cercam. O tráfego enviado por um gateway da Internet tem um MTU 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.

Não é possível configurar o tamanho da MTU nos nós do balanceador de carga. Os frames jumbo (9.001 MTU) são padrão em todos os nós do balanceador de carga para Application Load Balancers, Network Load Balancers e Classic Load Balancers. Os balanceadores de carga de gateway são compatíveis com 8.500 MTU. Para obter mais informações, consulte Unidade máxima de transmissão (MTU) no Guia do usuário para Gateway Load Balancers.

A MTU do caminho é o tamanho máximo de pacote compatível no caminho entre o host de origem e o host receptor. A Path MTU Discovery (PMTUD – Descoberta de MTU do caminho) é usada para determinar a MTU do caminho entre dois dispositivos. A descoberta de MTU do caminho é especialmente importante se o cliente ou o destino não for compatível com frames jumbo.

Se um host enviar um pacote maior que a MTU do host receptor ou maior que a MTU de um dispositivo no caminho, o host ou dispositivo receptor descartará o pacote e retornará a seguinte mensagem ICMP: 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 continuar havendo descarte de pacotes maiores que o tamanho da MTU do cliente ou da interface de destino, é provável que a descoberta de MTU do caminho (PMTUD) não esteja funcionando. Para evitar isso, certifique-se de que a descoberta de MTU do caminho esteja funcionando de ponta a ponta e que você tenha habilitado frames jumbo 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 do usuário da Amazon EC2 .