Como funciona o Azure Load Balancer

Concluído

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
• Pool de back-end
• Sondas de saúde
• Regras de NAT de entrada
• Portas de alta disponibilidade
• Regras de saída

Endereço IP da Interface

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, você pode distribuir a carga de tráfego de solicitação da Web por vários servidores da 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 diretamente expostos a um endpoint 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.

  

Regras do Load Balancer

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

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 manipule o tráfego de determinado 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.

Pool de 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 Balanceador de Carga realiza a reconfiguração automática para redistribuir a carga através do número alterado de instâncias quando escala as instâncias para cima ou para baixo. 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 de saúde

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

• O aplicativo encerra o fluxo.
• Ocorre tempo limite de inatividade.
• 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 sonda pré-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 a Porta, o Intervalo e o limite de integridade.
• teste personalizado HTTP ou HTTPS: O balanceador de carga analisa regularmente o seu endereço de destino (a cada 15 segundos, por padrão). A instância é saudável 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 estado de saúde do back-end (URI), o tempo entre as tentativas de teste (Intervalo) e o número de falhas que devem ocorrer para que a instância seja considerada não saudável (Limite não saudável).

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 se utiliza a persistência de sessão, as conexões do mesmo cliente dirigem-se para a mesma instância de backend dentro do pool de backend. 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-tuple): Especifica que a mesma instância de back-end pode lidar com pedidos sucessivos 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
• Porto 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 é necessário fazer o balanceamento de carga de um grande número de portas.

Regras de 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.

Regras de saída

Uma regra de saída configura a conversão de endereço de rede de origem (SNAT) para todas as VMs ou instâncias identificadas pelo pool de back-end. Esta regra permite que instâncias no back-end comuniquem-se para fora, com a Internet ou outros terminais públicos.