O Gateway Load Balancer (GWLB) opera na Camada 3 (camada de rede) e distribui tráfego de forma transparente para servidores backend, aumentando a segurança e a disponibilidade das aplicações.
Estado da instância
As instâncias GWLB podem estar nos seguintes estados:
|
Estado da instância |
Descrição |
Tipo de bloqueio |
Exclusão permitida |
Atualização de configuração permitida |
|
Running |
Operação normal. |
Não aplicável |
Sim |
Sim |
|
Creating |
Criação em andamento. |
Não aplicável |
Não |
Não |
|
Updating configuration |
Atualização de configuração em andamento. |
Não aplicável |
Não |
|
|
Stopped |
Instância parada. |
Bloqueio por pagamento em atraso: bloqueada devido a pagamento pendente. Conclua o pagamento para desbloquear. |
Não |
Versão de IP
As instâncias GWLB aceitam tráfego IPv4.
A instância GWLB utiliza endereços IPv4 privados de sua sub-rede para se comunicar com os servidores backend.
Encaminhamento entre zonas
O encaminhamento entre zonas é ativado por padrão e, no momento, não pode ser desativado. A instância GWLB distribui o tráfego para servidores backend em todas as zonas de disponibilidade habilitadas na região.
Unidade máxima de transmissão
A unidade máxima de transmissão (MTU) é o maior tamanho de pacote que pode ser transmitido em uma rede. Ela inclui o cabeçalho IP e o payload, mas não o cabeçalho Ethernet.
-
Limite de MTU do GWLB:
Tamanho máximo de pacote: 1.500 bytes. Pacotes maiores são descartados.
-
Configurações de MTU para appliances virtuais de rede:
O GWLB encapsula o tráfego IP com um cabeçalho Geneve (+68 bytes) antes de encaminhá-lo aos NVAs. Para lidar com pacotes encapsulados de 1.500 bytes, garanta que:
Jumbo frames estejam ativados na instância ECS onde o NVA está implantado.
-
A MTU da interface do NVA esteja definida como pelo menos 1.568 bytes.
Configure essa MTU na imagem do NVA conforme a documentação do fabricante do appliance.
-
Fragmentação de IP:
O GWLB não oferece suporte à fragmentação de IP.
-
Descoberta de MTU de caminho (PMTUD):
O GWLB não gera as mensagens ICMP necessárias para indicar que a fragmentação é necessária e, portanto, não oferece suporte à PMTUD.
Timeout de inatividade de conexão
O timeout de inatividade de conexão define por quanto tempo uma conexão pode permanecer ociosa antes que o GWLB a encerre. O comportamento do timeout depende do flow scheduling algorithm e do tipo de tráfego.
Tratamento de tráfego TCP
-
Quando o algoritmo de agendamento de fluxo é hash de cinco tuplas:
O GWLB rastreia o estado da conexão TCP. Se nenhum dado for transferido dentro do período de timeout, a conexão é encerrada e o tráfego existente é descartado. A instância GWLB encaminha o tráfego subsequente para um novo servidor backend. Uma nova conexão é estabelecida com a próxima requisição.
O timeout padrão é de 350 segundos. Você pode customize the TCP connection idle timeout nas configurações do listener. Intervalo válido: 60 a 6.000 segundos.
Ajuste o timeout de inatividade da conexão TCP para otimizar o uso de recursos:
Aumente o timeout para conexões de longa duração (transações financeiras, interações com bancos de dados, sistemas ERP). Iguale ou supere os timeouts dos NVAs backend para evitar encerramento prematuro. Por exemplo, se o timeout do seu firewall for 3.600 segundos, defina o GWLB para 3.700 segundos.
Reduza o timeout para tráfego de curta duração ou em rajadas, liberando conexões ociosas e diminuindo o consumo de recursos.
NotaSe uma conexão TCP for encerrada ativamente antes do timeout, o GWLB exclui seu estado imediatamente.
-
Quando o algoritmo de agendamento de fluxo é hash de duas ou três tuplas:
O GWLB aplica hash nos fluxos por duas tuplas (IP de source, IP de destino) ou três tuplas (IP de source, IP de destino, protocolo) para manter a afinidade com o servidor. Se um fluxo ficar ocioso além do timeout, o estado é limpo e os pacotes subsequentes podem ser encaminhados para um servidor backend diferente.
O timeout de inatividade de conexão é fixo em 350 segundos e não pode ser alterado.
Tratamento de tráfego não-TCP
Embora o UDP não seja orientado a conexão, o GWLB mantém o estado do fluxo com base no algoritmo de agendamento para garantir a afinidade com o servidor. Se um fluxo ficar ocioso além do timeout, o estado é limpo e os pacotes subsequentes podem ser encaminhados para um servidor backend diferente.
O timeout de inatividade de conexão para tráfego não-TCP é fixo em 120 segundos e não pode ser alterado.
Modo de tráfego
Por padrão, o GWLB opera no modo de balanceamento de carga, encaminhando o tráfego dos endpoints GWLB para os servidores backend.
Para resposta a emergências, solução de problemas ou manutenção de NVAs, alterne para o modo bypass. Nesse modo, o GWLB retorna o tráfego diretamente ao endpoint sem encaminhá-lo aos servidores backend, garantindo a continuidade do service.
Não ativado por padrão. Entre em contato com seu gerente de conta para utilizar este recurso.
|
Modo de tráfego |
Modo de balanceamento de carga |
Modo bypass |
|
Comportamento do GWLB |
O GWLB encaminha o tráfego do endpoint para os servidores backend para processamento. |
O GWLB retorna o tráfego diretamente ao endpoint sem encaminhá-lo aos servidores backend. |
|
Diagrama de arquitetura |
 |
 |
|
Casos de uso |
Modo padrão. Firewalls de terceiros processam o tráfego de negócio conforme esperado. |
Utilizado para manutenção de rede e firewall:
|
|
Observações |
- |
|
Console
No console do GWLB, acesse a página Instance Details. À direita de Traffic Processing Mode, clique em Modify para alternar o modo de processamento de tráfego.
API
Alterne o modo de tráfego chamando UpdateLoadBalancerAttribute e definindo o parâmetro TrafficMode.
Os seguintes valores são suportados para o parâmetro TrafficMode:
LoadBalance (padrão): modo de balanceamento de carga
ByPass: modo bypass
Consulte o modo de tráfego de uma instância GWLB com:
Alternar para o modo bypass ignora o processamento de segurança do NVA. Avalie os riscos de segurança envolvidos.
-
Ao retornar para o modo de balanceamento de carga com protocolos stateful, configure os NVAs (como firewalls) para lidar com tráfego no meio de sessão. Caso contrário, conexões existentes podem ser interrompidas.
Por exemplo, para tráfego TCP, o firewall precisa ser configurado para permitir o estabelecimento de uma sessão TCP sem o segmento SYN inicial.
-
Como funciona:
O TCP utiliza um handshake de três vias para estabelecer uma conexão. Esse processo envolve o envio de um segmento SYN pelo cliente, a resposta do servidor com um segmento SYN-ACK e o envio de um segmento ACK pelo cliente para concluir a conexão.
Após alternar do modo bypass para o modo de balanceamento de carga, o tráfego volta a passar pelos NVAs. NVAs que exigem o pacote SYN inicial não reconhecem pacotes intermediários de conexões existentes, causando a interrupção dessas conexões. Novas conexões não são afetadas. Configure seu NVA para aceitar sessões TCP sem o pacote SYN e evitar interrupções.
Exemplo de configuração: em um firewall FortiGate, ative
tcp-session-without-synna política de firewall. Para mais informações, consulte a documentação oficial do fabricante do seu firewall.
-