O que é o Software Load Balancer (SLB) para SDN?

Artigo
11/23/2024

Aplica-se a: Azure Local, versões 23H2 e 22H2; Windows Server 2022, Windows Server 2019, Windows Server 2016

Os Provedores de Serviços de Nuvem (CSPs) e as empresas que estão implantando o Software Defined Networking (SDN) podem usar o Software Load Balancer (SLB) para distribuir uniformemente o tráfego de rede de locatário e cliente locatário entre os recursos de rede virtual. O SLB permite que vários servidores hospedem a mesma carga de trabalho, proporcionando alta disponibilidade e escalabilidade.

O Software Load Balancer pode fornecer uma borda unificada e multilocatária integrando-se com tecnologias SDN, como RAS Gateway, Datacenter Firewall e Route Refletor.

Nota

A multilocação para VLANs não é suportada pelo controlador de rede. No entanto, você pode usar VLANs com SLB para cargas de trabalho gerenciadas pelo provedor de serviços, como a infraestrutura do datacenter e servidores Web de alta densidade.

Usando o Balanceador de Carga de Software, você pode expandir seus recursos de balanceamento de carga usando máquinas virtuais (VMs) SLB nos mesmos servidores de computação Hyper-V que você usa para suas outras cargas de trabalho de VM. Por isso, o Software Load Balancer oferece suporte à criação e exclusão rápidas de pontos de extremidade de balanceamento de carga, conforme necessário para operações CSP. Além disso, o Software Load Balancer suporta dezenas de gigabytes por sistema, fornece um modelo de provisionamento simples e é fácil de dimensionar.

Para saber como gerenciar políticas do Software Load Balancer usando o Windows Admin Center, consulte Manage Software Load Balancer for SDN.

O que inclui o Software Load Balancer?

O Software Load Balancer inclui os seguintes recursos:

Serviços de balanceamento de carga de camada 4 (L4) para tráfego TCP/UDP norte/sul e leste/oeste.
Balanceamento de carga de tráfego de rede pública e rede interna.
Suporte a endereços IP dinâmicos (DIPs) em VLANs (Redes de Área Local) virtuais e em redes virtuais que você cria usando a Virtualização de Rede Hyper-V.
Suporte de sonda de saúde.
Pronto para a escala da nuvem, incluindo capacidade de expansão e capacidade de expansão para multiplexadores e agentes de host.

Para obter mais informações, consulte Recursos do balanceador de carga de software neste artigo.

Como funciona o Software Load Balancer

O Software Load Balancer funciona mapeando endereços IP virtuais (VIPs) para DIPs que fazem parte de um conjunto de recursos de serviço de nuvem no datacenter.

VIPs são endereços IP únicos que fornecem acesso público a um pool de VMs com balanceamento de carga. Por exemplo, VIPs são endereços IP que são expostos na Internet para que locatários e clientes locatários possam se conectar a recursos de locatário no datacenter em nuvem.

DIPs são os endereços IP das VMs membros de um pool com balanceamento de carga atrás do VIP. Os DIPs são atribuídos dentro da infraestrutura de nuvem aos recursos do locatário.

Os VIPs estão localizados no SLB Multiplexer (MUX). O MUX consiste em uma ou mais VMs. O controlador de rede fornece cada MUX com cada VIP, e cada MUX, por sua vez, usa o Border Gateway Protocol (BGP) para anunciar cada VIP para roteadores na rede física como uma rota /32. O BGP permite que os roteadores de rede física:

Saiba que um VIP está disponível em cada MUX, mesmo que os MUXes estejam em sub-redes diferentes em uma rede de Camada 3.
Divida a carga de cada VIP por todos os MUXes disponíveis usando o roteamento ECMP (Equal Cost Multi-Path).
Detete automaticamente uma falha ou remoção de MUX e pare de enviar tráfego para o MUX com falha.
Espalhe a carga do MUX com falha ou removido pelos MUXes íntegros.

Quando o tráfego público chega da internet, o SLB MUX examina o tráfego, que contém o VIP como destino, e mapeia e reescreve o tráfego para que ele chegue a um DIP individual. Para o tráfego de rede de entrada, essa transação é executada em um processo de duas etapas que é dividido entre as VMs MUX e o host Hyper-V onde o DIP de destino está localizado:

Balanceamento de carga - o MUX usa o VIP para selecionar um DIP, encapsula o pacote e encaminha o tráfego para o host Hyper-V onde o DIP está localizado.
Network Address Translation (NAT) - o host Hyper-V remove o encapsulamento do pacote, traduz o VIP para um DIP, remapeia as portas e encaminha o pacote para a VM DIP.

O MUX sabe como mapear VIPs para os DIPs corretos devido às políticas de balanceamento de carga que você define usando o Controlador de Rede. Essas regras incluem Protocolo, Porta Front-end, Porta Back-end e algoritmo de distribuição (5, 3 ou 2 tuplas).

Quando as VMs locatárias respondem e enviam tráfego de rede de saída de volta para a Internet ou locais de locatários remotos, porque o NAT é executado pelo host Hyper-V, o tráfego ignora o MUX e vai diretamente para o roteador de borda do host Hyper-V. Esse processo de desvio de MUX é chamado de DSR (Direct Server Return).

E depois que o fluxo de tráfego de rede inicial é estabelecido, o tráfego de rede de entrada ignora completamente o SLB MUX.

Na ilustração a seguir, um computador cliente executa uma consulta DNS para o endereço IP de um site do SharePoint da empresa - neste caso, uma empresa fictícia chamada Contoso. Ocorre o seguinte processo:

O servidor DNS devolve o VIP 107.105.47.60 ao cliente.
O cliente envia uma solicitação HTTP para o VIP.
A rede física tem vários caminhos disponíveis para chegar ao VIP localizado em qualquer MUX. Cada roteador ao longo do caminho usa ECMP para escolher o próximo segmento do caminho até que a solicitação chegue a um MUX.
O MUX que recebe a solicitação verifica as políticas configuradas e vê que há dois DIPs disponíveis, 10.10.10.5 e 10.10.20.5, em uma rede virtual para lidar com a solicitação para o VIP 107.105.47.60
O MUX seleciona DIP 10.10.10.5 e encapsula os pacotes usando VXLAN para que ele possa enviá-lo para o host que contém o DIP usando o endereço de rede física do host.
O host recebe o pacote encapsulado e o inspeciona. Ele remove o encapsulamento e reescreve o pacote para que o destino agora seja DIP 10.10.10.5 em vez do VIP e, em seguida, envia o tráfego para DIP VM.
A solicitação chega ao site do SharePoint da Contoso no Farm de Servidores 2. O servidor gera uma resposta e envia-a para o cliente, usando o seu próprio endereço IP como fonte.
O host interceta o pacote de saída no comutador virtual, que lembra que o cliente, agora o destino, fez a solicitação original para o VIP. O host reescreve a fonte do pacote para ser o VIP para que o cliente não veja o endereço DIP.
O host encaminha o pacote diretamente para o gateway padrão da rede física que usa sua tabela de roteamento padrão para encaminhar o pacote para o cliente, que eventualmente recebe a resposta.

Balanceamento de carga do tráfego interno do datacenter

Ao balancear a carga do tráfego de rede interno ao datacenter, como entre recursos de locatário que estão sendo executados em servidores diferentes e são membros da mesma rede virtual, o comutador virtual Hyper-V ao qual as VMs estão conectadas executa NAT.

Com o balanceamento de carga de tráfego interno, a primeira solicitação é enviada e processada pelo MUX, que seleciona o DIP apropriado e, em seguida, roteia o tráfego para o DIP. A partir desse ponto, o fluxo de tráfego estabelecido ignora o MUX e vai diretamente de VM para VM.

Sondas do estado de funcionamento

O Balanceador de Carga de Software inclui testes de integridade para validar a integridade da infraestrutura de rede, incluindo o seguinte:

Sonda TCP para porta
Sonda HTTP para porta e URL

Ao contrário de um dispositivo balanceador de carga tradicional, onde a sonda se origina no dispositivo e viaja através do fio até o DIP, a sonda SLB se origina no host onde o DIP está localizado e vai diretamente do agente do host SLB para o DIP, distribuindo ainda mais o trabalho entre os hosts.

Infraestrutura do Software Load Balancer

Antes de configurar o Balanceador de Carga de Software, você deve primeiro implantar o Controlador de Rede e uma ou mais VMs MUX SLB.

Além disso, você deve configurar os hosts locais do Azure com o comutador virtual Hyper-V habilitado para SDN e garantir que o Agente de Host SLB esteja em execução. Os roteadores que atendem aos hosts devem oferecer suporte ao roteamento ECMP e ao BGP (Border Gateway Protocol) e devem ser configurados para aceitar solicitações de emparelhamento BGP dos MUXes do SLB.

A figura a seguir fornece uma visão geral da infraestrutura do SLB.

As seções a seguir fornecem mais informações sobre esses elementos da infraestrutura do Software Load Balancer.

Controlador de Rede

O controlador de rede hospeda o SLB Manager e executa as seguintes ações para o Software Load Balancer:

Processa comandos SLB que chegam por meio da API Northbound do Windows Admin Center, System Center, Windows PowerShell ou outro aplicativo de gerenciamento de rede.
Calcula a política de distribuição para hosts locais do Azure e MUXes SLB.
Fornece o status de integridade da infraestrutura do Software Load Balancer.

Você pode usar o Windows Admin Center ou o Windows PowerShell para instalar e configurar o Controlador de Rede e outra infraestrutura SLB.

SLB MUX

O SLB MUX processa o tráfego de rede de entrada e mapeia VIPs para DIPs e, em seguida, encaminha o tráfego para o DIP correto. Cada MUX também usa BGP para publicar rotas VIP para roteadores de borda. O BGP Keep Alive notifica MUXes quando um MUX falha, o que permite que MUXes ativos redistribuam a carga em caso de falha de MUX. Isso essencialmente fornece balanceamento de carga para os balanceadores de carga.

Agente Host SLB

Ao implantar o Balanceador de Carga de Software, você deve usar o Windows Admin Center, o System Center, o Windows PowerShell ou outro aplicativo de gerenciamento para implantar o Agente de Host SLB em cada servidor host.

O Agente de Host SLB escuta as atualizações de política do SLB do Controlador de Rede. Além disso, o Host Agent programa regras para SLB nos comutadores virtuais Hyper-V habilitados para SDN configurados no computador local.

Comutador virtual Hyper-V habilitado para SDN

Para que um comutador virtual seja compatível com SLB, a extensão VFP (Virtual Filtering Platform) deve estar habilitada no comutador virtual. Isso é feito automaticamente pelos scripts do PowerShell de implantação SDN, pelo assistente de implantação do Windows Admin Center e pela implantação do System Center Virtual Machine Manager (SCVMM).

Para obter informações sobre como habilitar o VFP em comutadores virtuais, consulte os comandos Get-VMSystemSwitchExtension e Enable-VMSwitchExtension do Windows PowerShell.

O comutador virtual Hyper-V habilitado para SDN executa as seguintes ações para o SLB:

Processa o caminho de dados para SLB.
Recebe tráfego de rede de entrada do MUX.
Ignora o MUX para tráfego de rede de saída, enviando-o para o roteador usando DSR.

Roteador BGP

O roteador BGP executa as seguintes ações para o Software Load Balancer:

Encaminha o tráfego de entrada para o MUX usando ECMP.
Para tráfego de rede de saída, usa a rota fornecida pelo host.
Escuta as atualizações de rota para VIPs do SLB MUX.
Remove MUXes SLB da rotação SLB se o Keep Alive falhar.

Recursos do Software Load Balancer

As seções a seguir descrevem alguns dos recursos e capacidades do Software Load Balancer.

Funcionalidade principal

O SLB fornece serviços de balanceamento de carga de Camada 4 para tráfego TCP/UDP norte/sul e leste/oeste.
Você pode usar o SLB em uma rede baseada na Virtualização de Rede Hyper-V.
Você pode usar o SLB com uma rede baseada em VLAN para VMs DIP conectadas a um comutador virtual Hyper-V habilitado para SDN.
Uma instância SLB pode lidar com vários locatários.
SLB e DIP suportam um caminho de retorno escalável e de baixa latência, conforme implementado pelo DSR.
O SLB funciona quando você também está usando o Switch Embedded Teaming (SET) ou o SR-IOV (Single Root Input/Output Virtualization).
O SLB inclui suporte para Protocolo Internet versão 6 (IPv6) e versão 4 (IPv4).
Para cenários de gateway site a site, o SLB fornece funcionalidade NAT para permitir que todas as conexões site a site utilizem um único IP público.

Dimensionamento e desempenho

Pronto para escalabilidade na nuvem, incluindo capacidade de expansão e expansão para MUXes e Host Agents.
Um módulo de controlador de rede SLB Manager ativo pode suportar oito instâncias MUX.

Elevada disponibilidade

Você pode implantar o SLB em mais de dois nós em uma configuração ativa/ativa.
MUXes podem ser adicionados e removidos do pool MUX sem afetar o serviço SLB. Isso mantém a disponibilidade do SLB quando MUXes individuais estão sendo corrigidos.
As instâncias MUX individuais têm um tempo de atividade de 99%.
Os dados de monitorização do estado de funcionamento estão disponíveis para as entidades gestoras.

Próximos passos

Para obter informações relacionadas, consulte também:

Partilhar via