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á.
Editar os atributos do grupo de destino para o Network Load Balancer
Depois de criar um grupo-alvo para seu Network Load Balancer, você pode editar os atributos do grupo-alvo.
Atributos do grupo de destino
Preservação do IP do cliente
Os balanceadores de carga de rede podem preservar os endereços IP de origem dos clientes ao rotear solicitações para destinos de back-end. 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 é habilitada (e não pode ser desabilitada) para grupos de destino de tipo de instância e de IP com os protocolos UDP e TCP_UDP. 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): habilitados
-
Grupos de destino do tipo IP (TCP, TLS): desabilitados
Quando a preservação do IP do cliente está ativada
A tabela a seguir descreve os endereços IP que os alvos recebem quando a preservação de IP do cliente está ativada.
| Destinos | IPv4 solicitações de clientes | IPv6 solicitações de clientes |
|---|---|---|
| Tipo de instância (IPv4) | IPv4 Endereço do cliente | Endereço do balanceador IPv4 de carga |
| Tipo de IP (IPv4) | IPv4 Endereço do cliente | Endereço do balanceador IPv4 de carga |
| Tipo de IP (IPv6) | Endereço do balanceador IPv6 de carga | IPv6 Endereço do cliente |
Quando a preservação do IP do cliente está desativada
A tabela a seguir descreve os endereços IP que os alvos recebem quando a preservação do IP do cliente é desativada.
| Destinos | IPv4 solicitações de clientes | IPv6 solicitações de clientes |
|---|---|---|
| Tipo de instância (IPv4) | Endereço do balanceador IPv4 de carga | Endereço do balanceador IPv4 de carga |
| Tipo de IP (IPv4) | Endereço do balanceador IPv4 de carga | Endereço do balanceador IPv4 de carga |
| Tipo de IP (IPv6) | Endereço do balanceador IPv6 de carga | Endereço do balanceador IPv6 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.
-
A preservação do IP do cliente não é suportada quando os destinos são alcançados por meio de um gateway de trânsito.
-
A preservação do IP do cliente não é suportada ao usar um endpoint do Gateway Load Balancer 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 do 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,,, M1 HI1 HS1, 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 AWS PrivateLink tráfego é sempre o endereço IP privado do Network Load Balancer.
-
A preservação do IP do cliente não é suportada quando um grupo-alvo contém interfaces de AWS PrivateLink rede ou a interface de rede de outro Network Load Balancer. Isso causa perda de comunicação com esses alvos.
-
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 balanceadores de carga de rede internos, e o destino registrado atrás de um balanceador de carga de rede cria conexões com o mesmo balanceador de carga de rede. A conexão pode ser roteada para o destino que está tentando criar a conexão, levando a erros de conexão. Recomendamos não se conectar a um Network Load Balancer a partir de destinos atrás do mesmo Network Load Balancer. Como alternativa, você também pode evitar esse tipo de erro de conexão desativando a preservação do IP do cliente. Se você precisar do endereço IP do cliente, poderá recuperá-lo usando o Proxy Protocol v2. Para obter mais informações, consulte Protocolo de proxy.
-
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 portas para fluxos de back-end.
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.
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.
Protocolo de proxy
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 seus destinos fora do Network Load Balancer, o primeiro cabeçalho do protocolo proxy pode não ser o do 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.
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 retornar 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 personalizado Type-Length-Value (TLV) da seguinte forma.
| Campo | Comprimento (em octetos) | Descrição |
|---|---|---|
|
Tipo |
1 |
PP2_TYPE_AWS (0xEA) |
|
Length |
2 |
O comprimento do valor |
|
Valor |
1 |
PP2_SUBTIPO_ (0x01AWS_VPCE_ID ) |
| variável (comprimento do valor menos 1) | O ID do endpoint |
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
Sessões persistentes
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.
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 os balanceadores de carga de rede, o balanceamento de carga entre zonas é desativado por padrão no nível do balanceador de carga, mas você pode ativá-lo a qualquer momento. Para grupos-alvo, o padrão é usar a configuração do balanceador de carga, mas você pode substituí-lo ativando ou desativando explicitamente o balanceamento de carga entre zonas no nível do grupo-alvo.
Considerações
-
Ao ativar o balanceamento de carga entre zonas para um Network Load Balancer EC2 , cobranças de transferência de dados se aplicam. 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 desativado, verifique se você tem capacidade alvo suficiente em cada uma das zonas de disponibilidade do balanceador de carga, para que cada zona possa atender à carga de trabalho associada.
-
Quando o balanceamento de carga entre zonas estiver desativado, certifique-se de que todos os grupos-alvo participem das mesmas zonas de disponibilidade. Uma zona de disponibilidade vazia é considerada não íntegra.
-
Você pode ativar ou desativar o balanceamento de carga entre zonas no nível do grupo de destino se o tipo de grupo de destino for
instanceou.ipSe 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 nível do 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 término da conexão para destinos não íntegros é configurado no nível do grupo-alvo.
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 alvo permanece no unhealthy.draining estado antes que seu estado se torneunhealthy. Se o destino passar pelas verificações de integridade durante o intervalo de conexão não íntegra, seu estado healthy voltará a ser. 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.
