Como funciona o Azure Load Balancer

  • 5 minutos

O Azure Load Balancer opera na camada de transporte do modelo OSI. Esta funcionalidade de Camada 4 permite a gestão de tráfego com base em propriedades específicas do tráfego. Propriedades, incluindo endereço de origem e destino, tipo de protocolo TCP ou UDP e número da porta.

O Load Balancer tem vários elementos que trabalham juntos para garantir a alta disponibilidade e o desempenho de um aplicativo:

  • Front-end IP
  • Regras do balanceador de carga
  • Conjunto back-end
  • Sondas do estado de funcionamento
  • Regras NAT de entrada
  • Portas de alta disponibilidade
  • Regras de saída

Front-end IP

O endereço IP front-end é o endereço que os clientes usam para se conectar ao seu aplicativo Web. Um endereço IP front-end pode ser um endereço IP público ou privado. Os balanceadores de carga do Azure podem ter vários IPs front-end. A seleção de um endereço IP público ou privado determina que tipo de balanceador de carga criar:

  • Endereço IP público: um balanceador de carga público: um balanceador de carga público mapeia o IP público e a porta do tráfego de entrada para o IP privado e a porta da VM. Você pode distribuir tipos específicos de tráfego entre várias VMs ou serviços aplicando regras de balanceamento de carga. Por exemplo, pode distribuir a carga do tráfego de pedidos da Web entre múltiplos servidores Web. O balanceador de carga mapeia o tráfego de resposta do IP privado e da porta da VM para o IP público e a porta do balanceador de carga. Em seguida, ele transmite a resposta de volta para o cliente solicitante.

  • Endereço IP privado: um balanceador de carga interno: um balanceador de carga interno distribui o tráfego para recursos que estão dentro de uma rede virtual. O Azure restringe o acesso aos endereços IP front-end de uma rede virtual com balanceamento de carga. Os endereços IP front-end e as redes virtuais nunca são expostos diretamente a um ponto de extremidade da Internet. Os aplicativos internos de linha de negócios são executados no Azure e são acessados de dentro do Azure ou de recursos locais por meio de uma conexão VPN ou ExpressRoute.

    Diagram that depicts how public and internal load balancers work in Azure Load Balancer.

Regras do Balanceador de Carga

Uma regra de balanceador de carga define como o tráfego é distribuído para o pool de back-end. A regra mapeia um determinado IP front-end e uma combinação de portas para um conjunto de endereços IP back-end e uma combinação de portas.

Diagram that depicts how load balancer rules work in Azure Load Balancer.

O tráfego é gerenciado usando um hash de cinco tuplas feito dos seguintes elementos:

  • IP de origem: O endereço IP do cliente solicitante.
  • Porta de origem: A porta do cliente solicitante.
  • IP de destino: o endereço IP de destino da solicitação.
  • Porta de destino: a porta de destino da solicitação.
  • Tipo de protocolo: O tipo de protocolo especificado, TCP ou UDP.
  • Afinidade de sessão: garante que o mesmo nó do pool sempre lide com o tráfego de um cliente.

O Load Balancer permite que você balanceie a carga de serviços em várias portas, vários endereços IP ou ambos. Você pode configurar diferentes regras de balanceamento de carga para cada IP front-end. Várias configurações front-end só são suportadas com VMs IaaS.

O Balanceador de Carga não pode aplicar regras diferentes com base no conteúdo de tráfego interno porque opera na Camada 4 (camada de transporte) do modelo OSI. Se você precisar gerenciar o tráfego com base em suas propriedades de Camada 7 (camada de aplicativo), precisará implantar uma solução como o Gateway de Aplicativo do Azure.

Conjunto back-end

O pool de back-end é um grupo de VMs ou instâncias em um Conjunto de Dimensionamento de Máquina Virtual que responde à solicitação de entrada. Para dimensionar de forma econômica para atender a grandes volumes de tráfego de entrada, as diretrizes de computação geralmente recomendam a adição de mais instâncias ao pool de back-end.

O Load Balancer implementa a reconfiguração automática para redistribuir a carga pelo número alterado de instâncias quando você aumenta ou diminui a escala das instâncias. Por exemplo, se você adicionou mais duas instâncias de VMs ao pool de back-end, o Load Balancer se reconfiguraria para iniciar o balanceamento de tráfego para essas instâncias com base nas regras de balanceamento de carga já configuradas.

Sondas do estado de funcionamento

Uma investigação de integridade é usada para determinar o status de integridade das instâncias no pool de back-end. Essa investigação de integridade determina se uma instância está íntegra e pode receber tráfego. Você pode definir o limite insalubre para suas sondas de saúde. Quando um teste não responde, o balanceador de carga para de enviar novas conexões para as instâncias não íntegras. Uma falha de sonda não afeta as conexões existentes. A conexão continua até:

  • O aplicativo encerra o fluxo.
  • Ocorre tempo limite ocioso.
  • A VM é desligada.

O Balanceador de Carga permite configurar diferentes tipos de teste de integridade para pontos de extremidade: TCP, HTTP e HTTPS.

  • Sonda personalizada TCP: esta sonda depende do estabelecimento de uma sessão TCP bem-sucedida para uma porta de teste definida. Se o ouvinte especificado na VM existir, o teste será bem-sucedido. Se a conexão for recusada, a sonda falhará. Você pode especificar o limite Porta, Intervalo e Não Íntegro.
  • Sonda personalizada HTTP ou HTTPS: o balanceador de carga investiga regularmente seu ponto de extremidade (a cada 15 segundos, por padrão). A instância estará íntegra se responder com um HTTP 200 dentro do período de tempo limite (padrão de 31 segundos). Qualquer status diferente de HTTP 200 faz com que a sonda falhe. Você pode especificar a porta (Porta), o URI para solicitar o status de integridade do back-end (URI), a quantidade de tempo entre as tentativas de teste (Interval) e o número de falhas que devem ocorrer para que a instância seja considerada não íntegra (Limite não íntegro).

Persistência da sessão

Por padrão, o Load Balancer distribui o tráfego de rede igualmente entre várias instâncias de VM. Ele fornece aderência apenas dentro de uma sessão de transporte. A persistência da sessão especifica como o tráfego de um cliente deve ser tratado. O comportamento padrão (Nenhum) é que qualquer VM íntegra pode lidar com solicitações sucessivas de um cliente.

A persistência da sessão também é conhecida como afinidade de sessão, afinidade IP de origem ou afinidade IP de cliente. Esse modo de distribuição usa um hash de duas tuplas (IP de origem e IP de destino) ou de três tuplas (IP de origem, IP de destino e tipo de protocolo) para rotear para instâncias de back-end. Quando você usa a persistência de sessão, as conexões do mesmo cliente vão para a mesma instância de back-end dentro do pool de back-end. Você pode configurar uma das seguintes opções de persistência de sessão:

  • Nenhum (padrão): especifica que qualquer VM íntegra pode lidar com a solicitação.
  • IP do cliente (2-tupla): Especifica que a mesma instância de back-end pode lidar com solicitações sucessivas do mesmo endereço IP do cliente.
  • IP do cliente e protocolo (3 tuplas): especifica que a mesma instância de back-end pode lidar com solicitações sucessivas do mesmo endereço IP do cliente e combinação de protocolo.

Você pode alterar esse comportamento configurando uma das opções descritas nas seções a seguir.

Portas de alta disponibilidade

Uma regra de balanceador de carga configurada com protocol - all and port - 0 é chamada de regra de porta de alta disponibilidade (HA). Esta regra permite que uma única regra balanceie a carga de todos os fluxos TCP e UDP que chegam em todas as portas de um balanceador de carga padrão interno.

A decisão de balanceamento de carga é tomada por fluxo. Esta ação baseia-se na seguinte conexão de cinco tuplas:

  • Endereço IP de origem
  • Porta de origem
  • Endereço IP de destino
  • Porta de destino
  • Protocolo

As regras de balanceamento de carga de portas HA ajudam você em cenários críticos, como alta disponibilidade e dimensionamento para dispositivos virtuais de rede (NVAs) dentro de redes virtuais. O recurso pode ajudar quando um grande número de portas deve ser balanceado de carga.

Diagram that shows how high availability ports work in Azure Load Balancer.

Regras NAT de entrada

Você pode usar regras de balanceamento de carga em combinação com regras NAT (Network Address Translation). Por exemplo, você pode usar NAT do endereço público do balanceador de carga para TCP 3389 em uma VM específica. Esta combinação de regras permite o acesso remoto ao ambiente de trabalho a partir de fora do Azure.

Diagram that shows how inbound NAT rules work in Azure Load Balancer.

Regras de saída

Uma regra de saída configura a SNAT (Conversão de Endereço de Rede de Origem) para todas as VMs ou instâncias identificadas pelo pool de back-end. Essa regra permite que instâncias no back-end se comuniquem (saída) com a Internet ou outros pontos de extremidade públicos.

Diagram that shows how outbound rules work in Azure Load Balancer.