Grupos de destino para Network Load Balancers
Cada grupo de destino é usado para rotear solicitações para um ou mais destinos registrados. Ao criar um listener, especifique um grupo de destino para a ação padrão dele. O tráfego é encaminhado para o grupo de destino especificado na regra do listener. Você pode criar grupos de destino diferentes para tipos de solicitações diferentes. Por exemplo, você pode criar um grupo de destino para solicitações gerais e outros grupos de destino para solicitações para os microsserviços do aplicativo. Para obter mais informações, consulte Componentes do Network Load Balancer.
Você define as configurações de verificação de integridade para seu load balancer por grupo de destino. Cada grupo de destino usa as configurações de verificação de integridade padrão, a menos que você as substitua ao criar o grupo de destino ou as modifique posteriormente. Após especificar um grupo de destino em uma regra para um listener, o load balancer monitora continuamente a integridade de todos os destinos registrados com o grupo de destino que estiverem em uma Zona de disponibilidade habilitada para o load balancer. O load balancer roteia solicitações para os destinos registrados que são íntegros. Para obter mais informações, consulte Verificações de integridade para grupos de destino do Network Load Balancer.
Conteúdo
Configuração de roteamento
Por padrão, um load balancer roteia solicitações para seus destinos usando o protocolo e o número da porta que você especificou ao criar o grupo de destino. Como alternativa, você pode substituir a porta usada para rotear o tráfego para um destino quando registrá-lo no grupo de destino.
Os grupos de destino para Network Load Balancers são compatíveis com os seguintes protocolos e portas:
-
Protocolos: TCP, TLS, UDP, TCP_UDP, QUIC, TCP_QUIC
-
Ports (Portas: 1-65535
Se um grupo de destino estiver configurado com o protocolo TLS, o load balancer estabelecerá conexões TLS com os destinos usando certificados instalados nos destinos. O load balancer não valida esses certificados. Portanto, é possível usar certificados autoassinados ou certificados que tenham expirado. Como o load balancer está em uma nuvem privada virtual (VPC), o tráfego entre o load balancer e os destinos é autenticado no nível do pacote e, portanto, não corre o risco de ataques man-in-the-middle ou de falsificações mesmo que os certificados nos destinos não sejam válidos.
A tabela a seguir resume as combinações compatíveis das configurações do protocolo do listener e do grupo de destino.
| Protocolo do listener | Protocolo do grupo de destino | Tipo de grupo de destino | Protocolo da verificação de integridade |
|---|---|---|---|
|
TCP |
TCP | TCP_UDP | TCP_QUIC |
instância | ip |
HTTP | HTTPS | TCP |
|
TCP |
TCP |
alb |
HTTP | HTTPS |
|
TLS |
TCP | TLS |
instância | ip |
HTTP | HTTPS | TCP |
|
UDP |
UDP | TCP_UDP |
instância | ip |
HTTP | HTTPS | TCP |
|
TCP_UDP |
TCP_UDP |
instância | ip |
HTTP | HTTPS | TCP |
|
QUIC |
QUIC | TCP_QUIC |
instância | ip |
HTTP | HTTPS | TCP |
|
TCP_QUIC |
TCP_QUIC |
instância | ip |
HTTP | HTTPS | TCP |
Target type
Quando você cria um grupo de destino, você especifica o tipo de destino, que determina como você especifica seus destinos. Depois de criar um grupo de destino, você não pode mudar o tipo de destino dele.
Os possíveis tipos de destino são os seguintes:
instance-
Os destinos são especificados por ID de instância.
ip-
Os destinos são especificados por endereço IP.
alb-
O destino é um Application Load Balancer.
Quando o tipo de destino é ip, você pode especificar os endereços IP de um dos seguintes blocos CIDR:
Importante
Você não pode especificar publicamente endereços IP roteáveis.
Todos os blocos CIDR compatíveis permitem que você registre os seguintes destinos em um grupo de destino:
-
Recursos da AWS que são endereçáveis por endereço IP e porta (por exemplo, bancos de dados).
-
Recursos on-premises vinculados à AWS por meio do Direct Connect ou de uma conexão do Site-to-Site VPN.
Quando a preservação do IP do cliente está desabilitada para seus grupos de destino, o balanceador de carga pode suportar aproximadamente 55 mil conexões por minuto para cada combinação de endereço IP do Network Load Balancer e destino exclusivo (endereço IP e porta). Se você exceder essas conexões, há uma chance maior de erros de alocação de porta. Se você receber erros de alocação de porta, adicione mais destinos ao grupo de destino.
Ao iniciar um Network Load Balancer em uma VPC compartilhada (como participante), você só pode registrar destinos em sub-redes que foram compartilhadas com você.
Quando o tipo de destino é alb, você pode registrar um único Application Load Balancer como destino. Para obter mais informações, consulte Usar um Application Load Balancer como destino de um Network Load Balancer.
Os Network Load Balancers não são compatíveis com o tipo de destino lambda. Os Application Load Balancers são os únicos balanceadores de carga compatíveis com o tipo de destino lambda. Para obter mais informações, consulte Lambda functions as targets no Guia do usuário de Application Load Balancers.
Se você tiver microsserviços em instâncias registradas em um Network Load Balancer, não poderá usar o balanceador de carga para possibilitar a comunicação entre eles, a menos que o balanceador de carga esteja voltado para a Internet ou as instâncias estejam registradas por endereço IP. Para obter mais informações, consulte As conexões expiram para solicitações de um destino para o load balancer.
Roteamento de solicitações e endereços IP
Se você especificar destinos usando um ID de instância, o tráfego será roteado para instâncias usando o endereço IP primário privado especificado na interface de rede primária para a instância. O load balancer grava novamente o endereço IP de destino do pacote de dados antes de encaminhá-lo para a instância de destino.
Se você especificar destinos usando endereços IP, você pode rotear o tráfego para uma instância com qualquer endereço IP privado de uma ou mais interfaces de rede. Isso permite que vários aplicativos em uma instância usem a mesma porta. Observe que cada interface de rede pode ter seu próprio security group. O load balancer grava novamente o endereço IP de destino antes de encaminhá-lo para o destino.
Para obter mais informações sobre permissão de tráfego para suas instâncias, consulte Grupos de segurança de destino.
Recursos on-premises como destinos
Recursos on-premises vinculados por meio do Direct Connect ou de uma conexão do Site-to-Site VPN podem servir como destino quando o tipo de destino é ip.
Ao usar recursos on-premises, os endereços IP desses destinos ainda devem vir de um dos seguintes blocos CIDR:
Para obter mais informações sobre o Direct Connect, consulte O que é Direct Connect?
Para obter mais informações sobre o AWS Site-to-Site VPN, consulte O que é AWS Site-to-Site VPN?
Tipo de endereço IP
Ao criar um novo grupo de destino, você pode selecionar o tipo de endereço IP dele. Isso controla a versão do IP usada para comunicação com os destinos e para a verificação do status de integridade deles.
Os grupos de destino de seus Network Load Balancers são compatíveis com os seguintes tipos de endereço IP:
ipv4-
O balanceador de carga se comunica com os destinos usando IPv4.
ipv6-
O balanceador de carga se comunica com os destinos usando IPv6.
Considerações
-
O balanceador de carga se comunica com os destinos com base no tipo de endereço IP do grupo de destino. Os destinos de um grupo de destino IPv4 devem aceitar o tráfego IPv4 do balanceador de carga e os destinos de um grupo de destino IPv6 devem aceitar o tráfego IPv6 do balanceador de carga.
-
Você não pode usar um grupo de destino IPv6 com um balanceador de carga
ipv4. -
Você não pode usar um grupo de destino IPv4 com um receptor UDP para um balanceador de carga
dualstack. -
Você não pode registrar um Application Load Balancer com um grupo de destino IPv6.
-
Você não pode usar um grupo de destino IPv6 com protocolos QUIC ou TCP_QUIC.
Destinos registrados
O seu load balancer serve como um ponto único de contato para clientes e distribui o tráfego de entrada nos destinos íntegros registrados. Cada grupo de destino deve ter pelo menos um destino registrado em cada zona de disponibilidade que é habilitada para o load balancer. Você pode registrar cada destino com um ou mais grupos de destino.
Se a demanda da seu aplicativo aumentar, você pode registrar destinos adicionais com um ou mais grupos de destino, a fim de dar conta da demanda. O balanceador de carga inicia o roteamento do tráfego para um destino recém-registrado assim que o processo de registro é concluído e o destino passa pelas verificações de integridade iniciais, independentemente do limite configurado.
Se a demanda na aplicação diminuir ou se você precisar fazer manutenção nos destinos, poderá cancelar o registro dos destinos nos grupos de destino. Cancelar o registro de um destino o remove do seu grupo de destino, mas não afeta o destino de outra forma. O load balancer interrompe o roteamento do tráfego para um destino assim que o registro dele é cancelado. O destino entra no estado draining até que as solicitações em andamento tenham sido concluídas. Você pode registrar o destino com o grupo de destino novamente quando estiver pronto para retomar o recebimento do tráfego.
Se você estiver registrando destinos por ID de instância, poderá usar o balanceador de carga com um grupo do Auto Scaling. Depois que você anexar um grupo de destino a um grupo do Auto Scaling, o Auto Scaling registrará os destinos no grupo de destino para você quando ele os iniciar. Para obter mais informações, consulte Anexar um balanceador de carga ao seu grupo do Auto Scaling no Guia do usuário do Amazon EC2 Auto Scaling.
Requisitos e considerações
-
Você não pode registrar instâncias por ID de instância se for usado um dos seguintes tipos de instância: C1, CC1, CC2, CG1, CG2, CR1, G1, G2, HI1, HS1, M1, M2, M3 ou T1.
-
Ao registrar destinos por ID de instância para um grupo de destino IPv6, os destinos devem ter um endereço IPv6 primário atribuído. Para saber mais, consulte Endereços IPv6 no Guia do usuário do Amazon EC2
-
Ao registrar destinos por ID da instância, as instâncias devem estar na mesma VPC que o Network Load Balancer. Não será possível registrar instâncias por ID de instância se elas estiverem em uma VPC emparelhada com a VPC do balanceador de carga (mesma região ou região diferente). Você poderá registrar essas instâncias pelo endereço IP.
-
Se você registrar um destino por endereço IP e o endereço IP estiver na mesma VPC que o load balancer, o load balancer verificará se ele é de uma sub-rede que ele possa acessar.
-
O balanceador de carga direciona o tráfego para destinos localizados somente em zonas de disponibilidade habilitadas. Destinos em zonas não habilitadas não são usados.
-
Para grupos de destino UDP e TCP_UDP, QUIC e TCP_QUIC, não registre instâncias por endereço IP se elas residirem fora da VPC do balanceador de carga ou se usarem um dos seguintes tipos de instância: C1, CC1, CC2, CG1, CG2, CR1, G1, G2, HI1, HS1, M1, M2, M3 ou T1. Destinos que residem fora da VPC do balanceador de carga ou que usam um tipo de instância incompatível podem receber tráfego do balanceador de carga, mas não conseguem responder.
Atributos do grupo de destino
Você pode configurar um grupo de destino editando os atributos. Para obter mais informações, consulte Editar atributos do grupo de destino.
Os seguintes atributos de grupo de destino são compatíveis. Você só pode modificar esses atributos quando o tipo de grupo de destino é instance ou ip. Se o tipo de grupo de destino for alb, esses atributos sempre usarão os valores padrão.
deregistration_delay.timeout_seconds-
A quantidade de tempo que o Elastic Load Balancing deve aguardar antes de alterar o estado de um destino que terá o registro cancelado de
drainingparaunused. O intervalo é 0-3600 segundos. O valor de padrão é de 300 segundos. Para tráfego QUIC, o valor é sempre 300 segundos. deregistration_delay.connection_termination.enabled-
Indica se o balanceador de carga encerra as conexões no final do tempo limite de cancelamento do registro. O valor é
trueoufalse. Para novos grupos de destino UDP/TCP_UDP, o padrão étrue. Caso contrário, o padrão éfalse. Esse atributo não se aplica ao tráfego QUIC. load_balancing.cross_zone.enabled-
Indica se o balanceamento de carga entre zonas está habilitado. O valor é
true,falseouuse_load_balancer_configuration. O padrão é “”.use_load_balancer_configuration. preserve_client_ip.enabled-
Indica se a preservação do IP do cliente está habilitada. O valor é
trueoufalse. O padrão é desativado se o tipo de grupo de destino for endereço IP e o protocolo do grupo de destino for TCP ou TLS. Caso contrário, o padrão é habilitado. A preservação do cliente não pode ser desabilitada para grupos de destino UDP e TCP_UDP, QUIC e TCP_QUIC. proxy_protocol_v2.enabled-
Indica se o Proxy Protocol versão 2 está habilitado. Por padrão, o Proxy Protocol está desabilitado.
stickiness.enabled-
Indica se sticky sessions estão habilitadas. O valor é
trueoufalse. O padrão é “”.false. Esse atributo não se aplica ao tráfego QUIC. stickiness.type-
O tipo de perdurabilidade. O valor possível é
source_ip. target_group_health.dns_failover.minimum_healthy_targets.count-
O número mínimo de destinos que devem ser íntegros. Se o número de destinos íntegros for menor do que esse valor, marque a zona como não íntegra no DNS, para que o tráfego seja roteado somente para zonas íntegras. Os valores possíveis são
offou um número inteiro de 1 até o número máximo de destinos. Quando estiveroff, a falha de DNS é desabilitada, ou seja, mesmo que todos os destinos no grupo de destino não estejam íntegros, a zona não será removida do DNS. O padrão é 1. target_group_health.dns_failover.minimum_healthy_targets.percentage-
A porcentagem mínima de destinos que devem ser íntegros. Se a porcentagem de destinos íntegros for menor do que esse valor, marque a zona como não íntegra no DNS, para que o tráfego seja roteado somente para zonas íntegras. Os valores possíveis são
offou um número inteiro de 1 a 100. Quando estiveroff, a falha de DNS é desabilitada, ou seja, mesmo que todos os destinos no grupo de destino não estejam íntegros, a zona não será removida do DNS. O padrão é “”.off. target_group_health.unhealthy_state_routing.minimum_healthy_targets.count-
O número mínimo de destinos que devem estar íntegros. Se o número de destinos íntegros for menor do que desse valor, envie tráfego para todos os alvos, incluindo alvos não íntegros. Os valores possíveis são de 1 ao número máximo de destinos. O padrão é 1.
target_group_health.unhealthy_state_routing.minimum_healthy_targets.percentage-
O percentual mínimo de destinos que devem estar íntegros. Se a porcentagem de destinos íntegros for menor do que valor, envie tráfego para todos os destinos, incluindo destinos não íntegros. Os valores possíveis são
offou um número inteiro de 1 a 100. O padrão é “”.off. target_health_state.unhealthy.connection_termination.enabled-
Indica se o balanceador de carga encerra as conexões com destinos não íntegros. O valor é
trueoufalse. O padrão é “”.true. target_health_state.unhealthy.draining_interval_seconds-
A quantidade de tempo que o Elastic Load Balancing deve aguardar antes de alterar o estado de um destino não íntegro de
unhealthy.drainingparaunhealthy. O intervalo é 0 – 360.000 segundos. O valor de padrão é 0 segundos.Observação: esse atributo só pode ser configurado quando
target_health_state.unhealthy.connection_termination.enabledéfalse.
Integridade do grupo de destino
Por padrão, um grupo de destino é considerado íntegro desde que tenha pelo menos um destino íntegro. Se você tiver uma frota grande, não é suficiente ter apenas um destino íntegro distribuindo o tráfego. Em vez disso, você pode especificar uma contagem ou percentual mínimo de destinos que devem estar íntegros e quais ações o balanceador de carga executa quando os destinos íntegros ficarem abaixo do limite especificado. Isso melhora a disponibilidade do seu aplicativo.
Conteúdo
Ações para estado não íntegro
Você pode configurar os limites íntegros para as seguintes ações:
-
Failover de DNS: quando os destinos íntegros em uma zona ficam abaixo do limite, marcamos os endereços IP do nó do balanceador de carga da zona como não íntegros em DNS. Portanto, quando os clientes resolvem o nome DNS do balanceador de carga, o tráfego é roteado somente para zonas íntegras.
-
Failover de roteamento: quando os destinos íntegros em uma zona ficam abaixo do limite, o balanceador de carga envia tráfego para todos os destinos que estão disponíveis para o nó do balanceador de carga, incluindo destinos não íntegros. Isso aumenta a probabilidade de sucesso da conexão de um cliente, especialmente quando os destinos temporariamente são reprovados nas verificações de integridade, e reduz o risco de sobrecarga dos destinos íntegros.
Requisitos e considerações
-
Se você especificar os dois tipos de limites para uma ação (contagem e porcentagem), o balanceador de carga executará a ação quando um dos limites for violado.
-
Se você especificar limites para ambas as ações, o limite para failover de DNS deverá ser maior ou igual ao limite para failover de roteamento, de modo que o failover de DNS ocorra com o failover de roteamento ou antes dele.
-
Se você especificar o limite como um percentual, calcularemos o valor dinamicamente com base no número total de destinos registrados nos grupos de destino.
-
O número total de destinos depende do balanceamento de carga entre zonas estar ativado ou desativado. Se o balanceamento de carga entre zonas estiver desativado, cada nó enviará tráfego somente para os destinos na sua própria zona, o que significa que os limites se aplicarão ao número de destinos em cada zona habilitada separadamente. Se o balanceamento de carga entre zonas estiver ativado, cada nó enviará tráfego a todos os destinos em todas as zonas habilitadas, o que significa que os limites especificados se aplicarão ao número total de destinos em todas as zonas habilitadas. Para obter mais informações, consulte Balanceamento de carga entre zonas.
-
Quando houver um failover de DNS, todos os grupos de destino associados ao balanceador de carga serão afetados. Verifique se você tem capacidade suficiente nas zonas restantes para processar esse tráfego adicional, especialmente se o balanceamento de carga entre zonas estiver desativado.
-
Com o failover de DNS, removemos os endereços IP das zonas não íntegras do nome de host DNS do balanceador de carga. No entanto, o cache DNS do cliente local pode conter esses endereços IP até que a vida útil (TTL) no registro DNS expire (60 segundos).
-
Com o failover de DNS, se houver vários grupos de destino vinculados a um Network Load Balancer e um grupo de destino não estiver íntegro em uma zona, o failover de DNS ocorre, mesmo que outro grupo de destino esteja íntegro nessa zona.
-
Com o failover de DNS, se todas as zonas do balanceador de carga forem consideradas não íntegras, o balanceador de carga enviará tráfego para todas as zonas, incluindo as zonas não íntegras.
-
Além da existência de destinos íntegros em número suficiente, há outros fatores que podem levar ao failover de DNS, como a integridade da zona.
Exemplo
O exemplo a seguir demonstra como as configurações de integridade do grupo de destino são aplicadas.
Cenário
-
Um balanceador de carga compatível com duas zonas de disponibilidade, A e B
-
Cada zona de disponibilidade contém 10 destinos registrados
-
O grupo de destino tem as seguintes configurações de integridade:
Failover de DNS: 50%
Failover de roteamento: 50%
-
Seis destinos apresentam falha na zona de disponibilidade B
Se o balanceamento de carga entre zonas estiver desativado
-
O nó do balanceador de carga em cada zona de disponibilidade só pode enviar tráfego para os 10 destinos em sua zona de disponibilidade.
-
Há 10 destinos íntegros na zona de disponibilidade A, o que atende ao percentual necessário de destinos íntegros. O balanceador de carga continua distribuindo o tráfego entre os 10 destinos íntegros.
-
Há apenas 4 destinos íntegros na zona de disponibilidade B, o que representa 40% dos destinos do nó do balanceador de carga na zona de disponibilidade B. Como isso é inferior ao percentual necessário de destinos íntegros, o balanceador de carga executará as seguintes ações:
-
Failover de DNS: a zona de disponibilidade B será marcada como não íntegra no DNS. Como os clientes não conseguem resolver o nome do balanceador de carga para o nó do balanceador de carga na zona de disponibilidade B e a zona de disponibilidade A está íntegra, os clientes enviam novas conexões para a zona de disponibilidade A.
-
Failover de roteamento: quando novas conexões são enviadas explicitamente para a zona de disponibilidade B, o balanceador de carga distribui o tráfego para todos os destinos na zona de disponibilidade B, incluindo os destinos não íntegros. Isso evita interrupções entre os destinos íntegros restantes.
-
Se o balanceamento de carga entre zonas estiver ativado
-
Cada nó do balanceador de carga pode enviar tráfego para todos os 20 destinos registrados em ambas as zonas de disponibilidade.
-
Há 10 destinos íntegros na zona de disponibilidade A e 4 destinos íntegros na zona de disponibilidade B, totalizando 14 destinos íntegros. Isso representa 70% dos destinos para os nós do balanceador de carga em ambas as zonas de disponibilidade, o que atende ao percentual necessário de destinos íntegros.
-
O balanceador de carga distribui tráfego entre os 14 destinos íntegros nas duas zonas de disponibilidade.
Como usar o failover de DNS do Route 53 para o seu balanceador de carga
Se você usa o Route 53 para rotear consultas de DNS para seu balanceador de carga, também poderá configurar o failover de DNS para o seu balanceador de carga usando o Route 53. Em uma configuração de failover, o Route 53 verifica a integridade dos destinos dos grupos de destino do balanceador de carga para determinar se eles estão disponíveis. Se não houver destinos íntegros registrados no balanceador de carga ou se o próprio balanceador de carga não estiver íntegro, o Route 53 roteará o tráfego para outro recurso disponível, como um balanceador de carga íntegro ou um site estático no Amazon S3.
Por exemplo, vamos supor que você tenha uma aplicação Web para www.example.com e deseja instâncias redundantes em execução por trás de dois balanceadores de carga que residam em diferentes regiões. Você deseja que o tráfego seja roteado primariamente para o balanceador de carga em uma região e quer usar o balanceador de carga na outra região como backup durante falhas. Se você configurar o failover de DNS, poderá especificar os balanceadores de carga primário e secundário (backup). O Route 53 direcionará o tráfego para o balanceador de carga primário, se estiver disponível, ou para o balanceador de carga secundário, em caso contrário.
Como funciona a avaliação da integridade do destino
-
Quando a opção de avaliar a integridade do destino está definida como
Yesem um registro de alias para um Network Load Balancer, o Route 53 avalia a integridade do recurso especificado pelo valor doalias target. O Route 53 usa as verificações de integridade do grupo de destino. -
Se todos os grupos de destino vinculados a um Network Load Balancer estiverem íntegros, o Route 53 marcará o registro do alias como íntegro. Se você configurou um limite para um grupo de destino e ele atinge esse limite, ele passa nas verificações de integridade. Do contrário, se um grupo de destino contiver pelo menos um destino íntegro, sua verificação de integridade será aprovada. Se a verificação de integridade tiver êxito, o Route 53 retornará os registros de acordo com a sua política de roteamento. Se uma política de roteamento por failover for usada, o Route 53 retornará o registro primário.
-
Se todos os grupos de destino em um Network Load Balancer não estiverem íntegros, o registro do alias apresentará falha na verificação de integridade do Route 53 (falha na abertura). Se a avaliação da integridade do destino for usada, a política de roteamento por failover redirecionará o tráfego para o recurso secundário.
-
Se todos os grupos de destino em um Network Load Balancer estiverem vazios (sem destinos), o Route 53 considerará o registro não íntegro (falha na abertura). Se a avaliação da integridade do destino for usada, a política de roteamento por failover redirecionará o tráfego para o recurso secundário.
Para mais informações, consulte Uso dos limites de integridade do grupo de destino do balanceador de carga para melhorar a disponibilidade
