Editar os atributos do grupo de destino para o Network Load Balancer
Após criar um grupo de destino para o Network Load Balancer, você poderá editar os atributos do grupo de destino.
Atributos do grupo de destino
Preservação do IP do cliente
Os Network Load Balancers podem preservar os endereços IP de origem dos clientes ao rotear solicitações para destinos de backend. Quando você desabilita a preservação do IP do cliente, o endereço IP de origem é o endereço IP privado do Network Load Balancer.
Por padrão, a preservação do IP do cliente está habilitada (e não pode ser desabilitada) para grupos de destino de tipo de instância e de IP com os protocolos UDP, TCP_UDP, QUIC e TCP_QUIC. No entanto, você pode habilitar ou desabilitar a preservação do IP do cliente para grupos de destino TCP e TLS usando o atributo do grupo de destino preserve_client_ip.enabled.
Configurações padrão
-
Grupos de destino de tipo de instância: habilitados
-
Grupos de destino de tipo IP (UDP, TCP_UDP, QUIC, TCP_QUIC): habilitados
-
Grupos de destino do tipo IP (TCP, TLS): desabilitados
Quando a preservação do IP do cliente está habilitada
A tabela a seguir descreve os endereços IP que os destinos recebem quando a preservação do IP do cliente está habilitada.
| Targets | Solicitações de cliente de IPv4 | Solicitações de cliente de IPv6 |
|---|---|---|
| Tipo de instância (IPv4) | Endereço IPv4 do cliente | Endereço IPv4 do balanceador de carga |
| Tipo de IP (IPv4) | Endereço IPv4 do cliente | Endereço IPv4 do balanceador de carga |
| Tipo de IP (IPv6) | Endereço IPv6 do balanceador de carga | Endereço IPv6 do cliente |
Quando a preservação do IP do cliente está desabilitada
A tabela a seguir descreve os endereços IP que os destinos recebem quando a preservação do IP do cliente está desabilitada.
| Targets | Solicitações de cliente de IPv4 | Solicitações de cliente de IPv6 |
|---|---|---|
| Tipo de instância (IPv4) | Endereço IPv4 do balanceador de carga | Endereço IPv4 do balanceador de carga |
| Tipo de IP (IPv4) | Endereço IPv4 do balanceador de carga | Endereço IPv4 do balanceador de carga |
| Tipo de IP (IPv6) | Endereço IPv6 do balanceador de carga | Endereço IPv6 do balanceador de carga |
Requisitos e considerações
-
As alterações da preservação do IP do cliente só entram em vigor para novas conexões TCP.
-
Quando a preservação do IP do cliente está habilitada, o tráfego deve fluir diretamente do Network Load Balancer para o destino. O destino deve estar localizado na mesma VPC do balanceador de carga ou em uma VPC emparelhada na mesma região.
-
Não há suporte à preservação de IP do cliente quando os destinos são acessados por meio de um gateway de trânsito.
-
Não há suporte para a preservação de IP do cliente quando é usado um endpoint do balanceador de carga do gateway para inspecionar o tráfego entre o Network Load Balancer e o destino (instância ou endereço IP), mesmo que o destino esteja na mesma VPC que o Network Load Balancer.
-
Os seguintes tipos de instância não oferecem suporte à preservação do IP do cliente: C1, CC1, CC2, CG1, CG2, CR1, G1, G2, HI1, HS1, M1, M2, M3 e T1. Recomendamos que você registre esses tipos de instância como endereços IP, com a preservação do IP do cliente desabilitada.
-
A preservação do IP do cliente não afeta o tráfego de entrada de AWS PrivateLink. O endereço IP de origem do tráfego do AWS PrivateLink é sempre o endereço IP privado do Network Load Balancer.
-
A preservação do IP do cliente não é compatível quando um grupo de destino contém interfaces de rede do AWS PrivateLink ou a interface de rede de outro Network Load Balancer. Isso causa perda de comunicação com esses destinos.
-
A preservação do IP do cliente não afeta o tráfego convertido de IPv6 para IPv4. O endereço IP de origem desse tipo de tráfego é sempre o endereço IP privado do Network Load Balancer.
-
Quando você especifica destinos por tipo de Application Load Balancer, o IP do cliente de todo o tráfego de entrada é preservado pelo Network Load Balancer e enviado ao Application Load Balancer. Em seguida, o Application Load Balancer anexa o IP do cliente ao cabeçalho de solicitação
X-Forwarded-Forantes de enviá-lo ao destino. -
O loopback NAT, também conhecido como hairpinning, não é compatível quando a preservação do IP do cliente está habilitada. Isso ocorre ao usar Network Load Balancers internos e o destino registrado atrás de um Network Load Balancer cria conexões com o mesmo Network Load Balancer. A conexão pode ser roteada para o destino que está tentando criar a conexão, levando a erros de conexão. Recomendamos que não haja conexão a um Network Load Balancer a partir de destinos por trás do mesmo Network Load Balancer. Como alternativa, você também pode evitar esse tipo de erro de conexão desabilitando a preservação do IP do cliente. Se precisar do endereço IP do cliente, você poderá recuperá-lo usando o Proxy Protocol v2. Para obter mais informações, consulte Proxy Protocol.
-
Quando a preservação do IP do cliente está desabilitada, o Network Load Balancer pode oferecer suporte a 55 mil conexões simultâneas ou a cerca de 55 mil conexões por minuto para cada destino exclusivo (endereço IP e porta). Se você exceder essas conexões, existirá uma probabilidade maior de erros de alocação de porta, resultando em falhas para o estabelecimento de novas conexões. Para obter mais informações, consulte Erros de alocação de porta para fluxos de backend.
Atraso do cancelamento do registro
Quando você cancela o registro de um destino, o balanceador de carga interrompe a criação de novas conexões para o destino. O load balancer usa a diminuição de conexão para garantir que o tráfego em trânsito seja concluído nas conexões existentes. Se o destino com o registro cancelado permanecer íntegro e uma conexão existente não estiver ociosa, o balanceador de carga poderá continuar enviando tráfego para o destino. Para garantir que essas conexões existentes sejam fechadas, você pode executar uma das ações a seguir: habilitar o atributo do grupo de destino para encerramento de conexões, garantir que a instância não esteja íntegra antes de cancelar o registro dela ou fechar periodicamente conexões de clientes.
O estado inicial de um destino em cancelamento de registro é draining, período durante o qual o destino deixará de receber novas conexões. No entanto, o destino ainda poderá receber conexões devido ao atraso na propagação da configuração. Por padrão, o load balancer altera o estado de um destino que terá o registro cancelado para unused após 300 segundos. Para alterar a quantidade de tempo que o load balancer aguarda antes de alterar o estado de um destino que terá o registro cancelado para unused, atualize o valor de atraso do cancelamento do registro. Recomendamos que você especifique um valor de, pelo menos, 120 segundos para garantir que as solicitações sejam concluídas. Para tráfego QUIC, o valor é sempre 300 segundos e não pode ser ajustado.
Se você habilitar o atributo do grupo de destino para encerramento de conexões, as conexões com destinos com registros cancelados serão fechadas logo após o final do tempo limite de cancelamento do registro.
Proxy Protocol
Os Network Load Balancers usam o protocolo de proxy versão 2 para enviar informações de conexão adicionais, como a origem e o destino. O Proxy Protocol versão 2 oferece uma codificação binária do cabeçalho do Proxy Protocol.
Com receptores de TCP, o balanceador de carga acrescenta um cabeçalho do protocolo de proxy aos dados de TCP. Ele não descarta nem substitui os dados existentes, inclusive cabeçalhos do protocolo de proxy enviados pelo cliente ou quaisquer outros proxies, balanceadores de carga ou servidores no caminho da rede. Portanto, é possível receber mais de um cabeçalho do Proxy Protocol. Além disso, se houver outro caminho de rede para os destinos fora do Network Load Balancer, o primeiro cabeçalho do protocolo de proxy pode não ser do seu balanceador de carga.
Os receptores TLS não oferecem suporte a conexões de entrada com cabeçalhos de protocolo de proxy enviados pelo cliente ou por quaisquer outros proxies.
O tráfego QUIC não suporta a versão 2 do protocolo proxy.
Se você especificar destinos por endereço IP, os endereços IP de origem fornecidos às suas aplicações dependerão do protocolo do grupo de destino, da seguinte forma:
-
TCP e TLS: por padrão, a preservação do IP do cliente é desabilitada e os endereços IP de origem fornecidos para suas aplicações são os endereços IP privados dos nós do balanceador de carga. Para preservar o endereço IP do cliente, certifique-se de que o destino esteja localizado na mesma VPC ou em uma VPC pareada e habilite a preservação do IP do cliente. Se o endereço IP do cliente for necessário e essas condições ainda não foram atendias, habilite o protocolo de proxy e obtenha o endereço IP dos clientes no cabeçalho do protocolo de proxy.
-
UDP e TCP_UDP: os endereços IP de origem são os endereços IP dos clientes, pois a preservação do IP do cliente é habilitada por padrão para esses protocolos e não pode ser desabilitada. Se você especificar destinos por ID de instância, os endereços IP de origem fornecidos aos aplicativos serão os endereços IP dos clientes. No entanto, se preferir, você poderá ativar o Proxy Protocol e obter os endereços IP dos clientes que se encontram no cabeçalho do Proxy Protocol.
Conexões de verificação de integridade
Depois que habilitar o Proxy Protocol, o cabeçalho do Proxy Protocol também será incluído nas conexões de verificação de integridade do load balancer. No entanto, com conexões de verificação de integridade, as informações de conexão do cliente não serão enviadas no cabeçalho do Proxy Protocol.
Os destinos podem falhar nas verificações de integridade se não conseguirem analisar o cabeçalho do protocolo proxy. Por exemplo, eles podem apresentar o seguinte erro: HTTP 400: Solicitação inválida.
Serviços do VPC endpoint
Para o tráfego oriundo dos consumidores de serviço por meio de um serviço do VPC endpoint, os endereços IP de origem fornecidos aos seus aplicativos são os endereços IP privados dos nós do load balancer. Se os seus aplicativos precisam dos endereços IP dos consumidores de serviço, habilite o Proxy Protocol e obtenha os endereços IP no cabeçalho do Proxy Protocol.
O cabeçalho do Proxy Protocol também inclui o ID do endpoint. Essas informações são codificadas usando um vetor TLV (Type-Length-Value) personalizado, conforme mostrado a seguir.
| Campo | Comprimento (em octetos) | Descrição |
|---|---|---|
|
Tipo |
1 |
PP2_TYPE_AWS (0xEA) |
|
Length |
2 |
O comprimento do valor |
|
Valor |
1 |
PP2_SUBTYPE_AWS_VPCE_ID (0x01) |
| variável (comprimento do valor menos 1) | O ID do endpoint |
Para obter um exemplo que analisa um TLV tipo 0xEA, consulte https://github.com/aws/elastic-load-balancing-tools/tree/master/proprot
Habilitar o Proxy Protocol
Antes de habilitar o Proxy Protocol em um grupo de destino, certifique-se de que os aplicativos esperem e possam analisar o cabeçalho do Proxy Protocol v2. Caso contrário, poderá haver falha neles. Para obter mais informações, consulte o Proxy Protocol versões 1 e 2
Sticky sessions
As sticky sessions são um mecanismo para rotear tráfego de clientes para o mesmo destino em um grupo de destino. Isso é útil para servidores que mantêm as informações de estado em ordem para fornecer uma experiência contínua aos clientes.
Considerações
-
O uso de sticky sessions pode levar a uma distribuição desigual de conexões e de fluxos, o que pode afetar a disponibilidade dos destinos. Por exemplo, todos os clientes atrás do mesmo dispositivo NAT têm o mesmo endereço IP de origem. Portanto, todo o tráfego desses clientes é roteado para o mesmo destino.
-
O load balancer poderá redefinir as sticky sessions de um grupo de destino se o estado de integridade de qualquer um de seus destinos mudar ou se você registrar ou cancelar o registro de destinos com o grupo de destino.
-
Quando o atributo de persistência é ativado para um grupo de destino, as verificações de integridade passivas não são aceitas. Para obter mais informações, consulte Verificações de integridade para seus grupos de destino.
-
Sessões persistentes não são compatíveis com receptores TLS ou QUIC.
Balanceamento de carga entre zonas para grupos de destino
Os nós do load balancer distribuem solicitações de clientes para destinos registrados. Quando o balanceamento de carga entre zonas estiver ativado, cada nó do balanceador de carga distribuirá o tráfego aos destinos registrados em todas as zonas de disponibilidade registradas. Quando o balanceamento de carga entre zonas estiver desativado, cada nó do balanceador de carga distribuirá o tráfego somente para os destinos registrados na respectiva zona de disponibilidade. Isso poderá ser usado se os domínios de falha zonais forem preferidos com relação aos regionais, garantindo que uma zona íntegra não seja afetada por uma zona não íntegra ou para melhorias gerais na latência.
Com Network Load Balancers, o balanceamento de carga entre zonas fica desabilitado por padrão no nível do balanceador de carga, mas você pode habilitá-lo a qualquer momento. Para grupos de destino, o padrão é usar a configuração do balanceador de carga, mas você pode substituir o padrão habilitando ou desabilitando explicitamente o balanceamento de carga entre zonas em nível de grupo de destino.
Considerações
-
Ao habilitar o balanceamento de carga entre zonas para um Network Load Balancer, as tarifas de transferência de dados do EC2 são aplicáveis. Para obter mais informações, consulte Como entender as cobranças de transferência dados no Guia do usuário de exportações de dados da AWS.
-
A configuração do grupo de destino determina o comportamento de balanceamento de carga do grupo de destino. Por exemplo, se o balanceamento de carga entre zonas estiver habilitado em nível de balanceador de carga e desabilitado em nível de grupo de destino, o tráfego enviado ao grupo de destino não será roteado entre as zonas de disponibilidade.
-
Quando o balanceamento de carga entre zonas estiver desabilitado, verifique se você tem capacidade de destino suficiente em cada uma das zonas de disponibilidade do balanceador de carga para que cada zona possa fornecer a workload associada.
-
Quando o balanceamento de carga entre zonas estiver desabilitado, certifique-se de que todos os grupos de destino participem das mesmas zonas de disponibilidade. Uma zona de disponibilidade vazia é considerada não íntegra.
-
Você poderá habilitar ou desabilitar o balanceamento de carga entre zonas em nível de grupo de destino se o tipo do grupo de destino for
instanceouip. Se o tipo de grupo de destino foralb, o grupo de destino sempre herdará do balanceador de carga a configuração de balanceamento de carga entre zonas.
Para obter mais informações sobre como habilitar o balanceamento de carga entre zonas no balanceador de carga, consulte Balanceamento de carga entre zonas.
Encerramento da conexão para destinos não íntegros
O encerramento da conexão é habilitado por padrão. Quando o destino de um Network Load Balancer falha nas verificações de integridade configuradas e é considerado não íntegro, o balanceador de carga encerra as conexões estabelecidas e interrompe o roteamento de novas conexões para o destino. Com o encerramento da conexão desabilitado, o destino ainda é considerado não íntegro e não aceita novas conexões, mas as conexões estabelecidas são mantidas ativas, permitindo que elas sejam fechadas suavemente.
O encerramento da conexão para destinos não íntegros é configurado por grupo de destino.
Intervalo de drenagem de não íntegros
Os destinos no estado unhealthy.draining são considerados não íntegros, não recebem novas conexões, mas mantêm as conexões estabelecidas ao longo do intervalo configurado. O intervalo de conexão não íntegra determina a quantidade de tempo que o destino permanece no estado unhealthy.draining antes de passar a unhealthy. Se o destino passar nas verificações de integridade durante o intervalo de conexão não íntegra, seu estado voltará a ser healthy. Se um cancelamento de registro for acionado, o estado de destino se tornará draining e o tempo limite de atraso do cancelamento de registro começará.
Requisito
O encerramento da conexão deve ser desabilitado antes da habilitação do intervalo de drenagem de não íntegros.
