O que é o SLB (Balanceador de Carga de Software) para SDN?
Aplica-se a: Azure Local, versões 23H2 e 22H2; Windows Server 2022, Windows Server 2019, Windows Server 2016
Os CSPs (Provedores de Serviços de Nuvem) e as empresas que estão implantando SDN (Rede Definida pelo Software) podem usar o SLB (Balanceador de Carga de Software) para distribuir uniformemente o tráfego de rede do locatário e do cliente entre os recursos de rede virtual. O SLB permite que vários servidores hospedem a mesma carga de trabalho, fornecendo alta disponibilidade e escalabilidade.
O Software Load Balancer pode fornecer uma borda unificada e multilocatário integrando-se a tecnologias SDN, como RAS Gateway, Datacenter Firewall e Route Reflector.
Observação
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 Software Load Balancer, você pode escalar horizontalmente seus recursos de balanceamento de carga usando VMs (máquinas virtuais) 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 dá suporte à criação e exclusão rápidas de pontos de extremidade de balanceamento de carga, conforme necessário para operações de CSP. Além disso, o Software Load Balancer dá suporte a dezenas de gigabytes por sistema, fornece um modelo de provisionamento simples e é fácil de escalar horizontalmente e horizontalmente.
Para saber como gerenciar políticas do Balanceador de Carga de Software usando Windows Admin Center, consulte Gerenciar o Balanceador de Carga de Software para SDN.
O que o Software Load Balancer inclui?
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 rede pública e tráfego de rede interna.
Suporte a endereços IP dinâmicos (DIPs) em VLANs (redes locais) virtuais e em redes virtuais que você cria usando a Virtualização de Rede Hyper-V.
Suporte à investigação de integridade.
Pronto para escala de 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 Software Load Balancer neste artigo.
Como funciona o Balanceador de Carga de Software
O Software Load Balancer funciona mapeando VIPs (endereços IP virtuais) 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 expostos na Internet para que locatários e clientes de locatário possam se conectar a recursos de locatário no datacenter de nuvem.
DIPs são os endereços IP das VMs membros de um pool com balanceamento de carga por trá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 a cada MUX cada VIP, e cada MUX, por sua vez, usa o BGP (Border Gateway Protocol) para anunciar cada VIP aos 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.
Distribua a carga de cada VIP em todos os MUXes disponíveis usando o roteamento ECMP (Equal Cost Multi-Path).
Detecte automaticamente uma falha ou remoção de MUX e pare de enviar tráfego para o MUX com falha.
Distribua a carga do MUX com falha ou removido entre os 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 dividido entre as VMs MUX e o host Hyper-V em que 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 em que o DIP está localizado.
NAT (Conversão de Endereços de Rede) – o host Hyper-V remove o encapsulamento do pacote, converte o VIP em 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 de Front-end, Porta de Back-end e algoritmo de distribuição (5, 3 ou 2 tuplas).
Quando as VMs de locatário respondem e enviam o tráfego de rede de saída de volta para a Internet ou locais de locatário remoto, como 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 (Retorno Direto do Servidor).
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 – nesse caso, uma empresa fictícia chamada Contoso. O seguinte processo ocorre:
O servidor DNS retorna o VIP 107.105.47.60 para o cliente.
O cliente envia uma solicitação HTTP para o VIP.
A rede física tem vários caminhos disponíveis para acessar o 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 possa enviá-los ao 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 a VM DIP.
A solicitação chega ao site da Contoso SharePoint no Server Farm 2. O servidor gera uma resposta e a envia ao cliente, usando seu próprio endereço IP como origem.
O host intercepta o pacote de saída no switch virtual, que lembra que o cliente, agora o destino, fez a solicitação original ao VIP. O host reescreve a origem 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 em execução em servidores diferentes e são membros da mesma rede virtual, o comutador virtual do Hyper-V ao qual as VMs estão conectadas executa o 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. Desse ponto em diante, o fluxo de tráfego estabelecido ignora o MUX e vai diretamente de VM para VM.
Investigações de integridade
O Software Load Balancer inclui investigações 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 de balanceador de carga tradicional em que a sonda se origina no dispositivo e viaja pela conexão até o DIP, a sonda SLB se origina no host em que o DIP está localizado e vai diretamente do agente de host SLB para o DIP, distribuindo ainda mais o trabalho entre os hosts.
Infraestrutura do Software Load Balancer
Antes de configurar o Software Load Balancer, você deve primeiro implantar o Controlador de Rede e uma ou mais VMs SLB MUX.
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 peering BGP dos SLB MUXes.
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 Gerenciador SLB e executa as seguintes ações para o Balanceador de Carga de Software:
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 para distribuição para hosts locais do Azure e SLB MUXes.
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 outras infraestruturas 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 o BGP para publicar rotas VIP em roteadores de borda. O BGP Keep Alive notifica os MUXes quando um MUX falha, o que permite que os MUXes ativos redistribuam a carga em caso de falha do MUX. Isso essencialmente fornece balanceamento de carga para os balanceadores de carga.
Agente de 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 SLB do Controlador de Rede. Além disso, o agente de host 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 o SLB, a extensão VFP (Virtual Filtering Platform) deve ser habilitada no comutador virtual. Isso é feito automaticamente pelos scripts do PowerShell de implantação do SDN, pelo assistente de implantação do Windows Admin Center e pela implantação do SCVMM (System Center Virtual Machine Manager).
Para obter informações sobre como habilitar o VFP em comutadores virtuais, consulte os comandos do Windows PowerShell Get-VMSystemSwitchExtension e Enable-VMSwitchExtension.
O comutador virtual Hyper-V habilitado para SDN executa as seguintes ações para SLB:
Processa o caminho de dados para SLB.
Recebe o 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.
multilocatário
O roteador BGP executa as seguintes ações para o Software Load Balancer:
Roteia 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 atualizações de rota para VIPs do SLB MUX.
Remove MUXes SLB da rotação SLB se o Keep Alive falhar.
Recursos do Balanceador de Carga de Software
As seções a seguir descrevem alguns dos recursos e funcionalidades 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 em 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 do SLB pode lidar com vários locatários.
O SLB e o DIP dão suporte a um caminho de retorno escalonável e de baixa latência, conforme implementado pelo DSR.
O SLB funciona quando você também está usando o SET (Switch Embedded Teaming) ou o SR-IOV (Single Root Input/Output Virtualization).
O SLB inclui suporte ao Protocolo de 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.
Escala e desempenho
Pronto para escala na nuvem, incluindo capacidade de expansão e expansão para MUXes e Agentes de Host.
Um módulo ativo do controlador de rede do SLB Manager pode suportar oito instâncias MUX.
Alta disponibilidade
Você pode implantar o SLB em mais de dois nós em uma configuração ativa/ativa.
Os 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 de saúde estão disponíveis para as entidades gestoras.
Próximas etapas
Para informações relacionadas, confira também: