Partilhar via


O que é o Software Balanceador de Carga (SLB) para SDN?

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

Os Fornecedores de Serviços Cloud (CSPs) e as empresas que estão a implementar o Software Defined Networking (SDN) podem utilizar o Software Balanceador de Carga (SLB) para distribuir uniformemente o tráfego de rede de inquilinos e inquilinos entre recursos de rede virtual. O SLB permite que vários servidores alojem a mesma carga de trabalho, proporcionando elevada disponibilidade e escalabilidade.

Os Balanceador de Carga de software podem fornecer uma vantagem unificada e multi-inquilino ao integrar com tecnologias SDN, como o Gateway RAS, a Firewall do Datacenter e o Reflector de Rotas.

Nota

A multi-inquilino para VLANs não é suportada pelo Controlador de Rede. No entanto, pode utilizar VLANs com SLB para cargas de trabalho geridas pelo fornecedor de serviços, como a infraestrutura do datacenter e servidores Web de alta densidade.

Com o Software Balanceador de Carga, pode aumentar horizontalmente as suas capacidades de balanceamento de carga com máquinas virtuais (VMs) SLB nos mesmos servidores de computação Hyper-V que utiliza para as suas outras cargas de trabalho de VM. Por este motivo, o Software Balanceador de Carga suporta a criação e eliminação rápidas de pontos finais de balanceamento de carga, conforme necessário para as operações CSP. Além disso, o Software Balanceador de Carga suporta dezenas de gigabytes por cluster, fornece um modelo de aprovisionamento simples e é fácil de aumentar e reduzir horizontalmente.

Para saber como gerir políticas de Balanceador de Carga de Software com Windows Admin Center, veja Gerir Balanceador de Carga de Software para SDN.

O que inclui o Software Balanceador de Carga?

O Balanceador de Carga de software inclui as seguintes capacidades:

  • Serviços de balanceamento de carga de camada 4 (L4) para tráfego TCP/UDP norte/sul/leste/oeste.

  • Balanceamento de carga de tráfego de rede pública e de rede interna.

  • Os endereços IP dinâmicos (DIPs) suportam redes virtuais de Área Local (VLANs) e em redes virtuais que cria com a Virtualização de Rede Hyper-V.

  • Suporte da sonda de estado de funcionamento.

  • Pronto para dimensionamento da cloud, incluindo capacidade de escalamento horizontal e capacidade de aumento vertical para multiplexers e agentes anfitriões.

Para obter mais informações, veja Funcionalidades de Balanceador de Carga de software neste artigo.

Como funciona o Software Balanceador de Carga

O software Balanceador de Carga funciona ao mapear endereços IP virtuais (VIPs) para DIPs que fazem parte de um conjunto de recursos do serviço cloud no datacenter.

Os VIPs são endereços IP únicos que fornecem acesso público a um conjunto de VMs com balanceamento de carga. Por exemplo, os VIPs são endereços IP que são expostos na Internet para que os inquilinos e os clientes inquilinos possam ligar-se aos recursos do inquilino no datacenter da cloud.

Os DIPs são os endereços IP das VMs membros de um conjunto com balanceamento de carga atrás do VIP. Os DIPs são atribuídos na infraestrutura da cloud aos recursos do inquilino.

Os VIPs estão localizados no SLB Multiplexer (MUX). O MUX é composto por uma ou mais VMs. O Controlador de Rede fornece cada MUX com cada VIP e, por sua vez, cada MUX utiliza o Protocolo BGP (Border Gateway Protocol) para anunciar cada VIP aos routers na rede física como uma rota /32. O BGP permite que os routers de rede física:

  • Saiba que um VIP está disponível em cada MUX, mesmo que os MUXes estejam em sub-redes diferentes numa rede de Camada 3.

  • Espalhe a carga para cada VIP em todos os MUXes disponíveis através do encaminhamento ECMP (Equal Cost Multi-Path).

  • Detete automaticamente uma falha ou remoção do MUX e deixe de enviar tráfego para o MUX com falha.

  • Espalhe a carga do MUX falhado ou removido pelos MUXes em bom estado de funcionamento.

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 chegue a um DIP individual. Para o tráfego de rede de entrada, esta transação é efetuada num processo de dois passos que é dividido entre as VMs MUX e o anfitrião Hyper-V onde se encontra o DIP de destino:

  1. Balanceamento de carga – o MUX utiliza o VIP para selecionar um DIP, encapsula o pacote e encaminha o tráfego para o anfitrião Hyper-V onde o DIP está localizado.

  2. Tradução de Endereços de Rede (NAT) – o anfitrião Hyper-V remove o encapsulamento do pacote, traduz o VIP para um DIP, remapa as portas e reencaminha 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 define através do Controlador de Rede. Estas regras incluem Protocolo, Porta de Front-end, Porta de Back-end e algoritmo de distribuição (5, 3 ou 2 cadeias de identificação).

Quando as VMs de inquilino respondem e enviam o tráfego de rede de saída de volta para a Internet ou localizações remotas do inquilino, uma vez que o NAT é executado pelo anfitrião Hyper-V, o tráfego ignora o MUX e vai diretamente para o router edge do anfitrião Hyper-V. Este processo de bypass do MUX chama-se Devolução do Servidor Direto (DSR).

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

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

  1. O servidor DNS devolve o VIP 107.105.47.60 ao cliente.

  2. O cliente envia um pedido HTTP para o VIP.

  3. A rede física tem vários caminhos disponíveis para alcançar o VIP localizado em qualquer MUX. Cada router ao longo do caminho utiliza o ECMP para escolher o segmento seguinte do caminho até o pedido chegar a um MUX.

  4. O MUX que recebe o pedido verifica as políticas configuradas e vê que existem dois DIPs disponíveis, 10.10.10.5 e 10.10.20.5, numa rede virtual para processar o pedido para o VIP 107.105.47.60

  5. O MUX seleciona DIP 10.10.10.5 e encapsula os pacotes com VXLAN para que possa enviá-lo para o anfitrião que contém o DIP com o endereço de rede física do anfitrião.

  6. O anfitrião recebe o pacote encapsulado e inspeciona-o. Remove o encapsulamento e reescreve o pacote para que o destino seja agora DIP 10.10.10.5 em vez do VIP e, em seguida, envia o tráfego para a VM DIP.

  7. O pedido chega ao site do SharePoint da Contoso no Farm de Servidores 2. O servidor gera uma resposta e envia-a para o cliente, utilizando o seu próprio endereço IP como origem.

  8. O anfitrião interceta o pacote de envio no comutador virtual, que se lembra que o cliente, agora o destino, fez o pedido original ao VIP. O anfitrião reescreve a origem do pacote para ser o VIP para que o cliente não veja o endereço DIP.

  9. O anfitrião reencaminha o pacote diretamente para o gateway predefinido para a rede física que utiliza a respetiva tabela de encaminhamento padrão para reencaminhar o pacote para o cliente, que eventualmente recebe a resposta.

Processo de Balanceamento de Carga de Software.

Balanceamento de carga do tráfego do datacenter interno

Quando o balanceamento de carga do tráfego de rede interno para o datacenter, como entre recursos de inquilino que estão em execução em servidores diferentes e são membros da mesma rede virtual, o comutador virtual Hyper-V ao qual as VMs estão ligadas executa NAT.

Com o balanceamento de carga de tráfego interno, o primeiro pedido é enviado e processado pelo MUX, que seleciona o DIP adequado e, em seguida, encaminha o tráfego para o DIP. A partir daí, o fluxo de tráfego estabelecido ignora o MUX e passa diretamente da VM para a VM.

Sondas do estado de funcionamento

O software Balanceador de Carga inclui sondas de estado de funcionamento para validar o estado de funcionamento da infraestrutura de rede, incluindo o seguinte:

  • Sonda TCP para a porta

  • Pesquisa HTTP para porta e URL

Ao contrário de uma aplicação de balanceador de carga tradicional onde a sonda tem origem na aplicação e viaja através do fio até ao DIP, a sonda SLB tem origem no anfitrião onde o DIP está localizado e vai diretamente do agente anfitrião SLB para o DIP, distribuindo ainda mais o trabalho pelos anfitriões.

Infraestrutura de Balanceador de Carga de software

Antes de poder configurar o Software Balanceador de Carga, primeiro tem de implementar o Controlador de Rede e uma ou mais VMs SLB MUX.

Além disso, tem de configurar os anfitriões do Azure Stack HCI com o comutador virtual Hyper-V compatível com SDN e garantir que o Agente anfitrião SLB está em execução. Os routers que servem os anfitriões têm de suportar o encaminhamento ECMP e o Protocolo BGP (Border Gateway Protocol) e têm de ser configurados para aceitar pedidos de peering BGP dos MUXes do SLB.

A figura seguinte fornece uma descrição geral da infraestrutura de SLB.

Infraestrutura de Balanceador de Carga de software.

As secções seguintes fornecem mais informações sobre estes elementos da infraestrutura de software Balanceador de Carga.

Controlador de Rede

O Controlador de Rede aloja o Gestor de SLB e executa as seguintes ações para Software Balanceador de Carga:

  • Processa comandos SLB que são apresentados através da API northbound a partir de Windows Admin Center, System Center, Windows PowerShell ou outra aplicação de gestão de rede.

  • Calcula a política de distribuição para anfitriões do Azure Stack HCI e MUXes SLB.

  • Fornece o estado de funcionamento da infraestrutura de software Balanceador de Carga.

Pode utilizar Windows Admin Center ou 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 utiliza BGP para publicar rotas VIP em routers edge. O BGP Keep Alive notifica os MUXes quando um MUX falha, o que permite aos MUXes ativos redistribuir a carga em caso de falha do MUX. Isto fornece essencialmente balanceamento de carga para os balanceadores de carga.

Agente anfitrião SLB

Ao implementar o Software Balanceador de Carga, tem de utilizar Windows Admin Center, o System Center, o Windows PowerShell ou outra aplicação de gestão para implementar o Agente anfitrião SLB em todos os servidores anfitriões.

O Agente anfitrião SLB escuta as atualizações da política SLB do Controlador de Rede. Além disso, o agente anfitrião cria regras para o SLB nos comutadores virtuais Hyper-V compatíveis com SDN que estão configurados no computador local.

Comutador virtual Hyper-V compatível com SDN

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

Para obter informações sobre como ativar a VFP em comutadores virtuais, veja os comandos Windows PowerShell Get-VMSystemSwitchExtension e Enable-VMSwitchExtension.

O comutador virtual Hyper-V compatível com SDN executa as seguintes ações para o SLB:

  • Processa o caminho de dados do 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 router com dSR.

Router BGP

O router BGP executa as seguintes ações para Software Balanceador de Carga:

  • Encaminha o tráfego de entrada para o MUX com o ECMP.

  • Para tráfego de rede de saída, utiliza a rota fornecida pelo anfitrião.

  • Escuta atualizações de rotas para VIPs a partir do SLB MUX.

  • Remove os MUXes SLB da rotação SLB se o Keep Alive falhar.

Funcionalidades de Balanceador de Carga de software

As secções seguintes descrevem algumas das funcionalidades e capacidades do Software Balanceador de Carga.

Funcionalidade principal

  • O SLB fornece serviços de balanceamento de carga da Camada 4 para tráfego TCP/UDP norte/sul e leste/oeste.

  • Pode utilizar o SLB numa rede baseada em Virtualização de Rede Hyper-V.

  • Pode utilizar o SLB com uma rede baseada em VLAN para VMs DIP ligadas a um comutador virtual Hyper-V ativado por SDN.

  • Uma instância SLB pode processar vários inquilinos.

  • O SLB e o DIP suportam um caminho de retorno dimensionável e de baixa latência, conforme implementado pelo DSR.

  • O SLB funciona quando também está a utilizar o Agrupamento Incorporado do Comutador (SET) ou a Virtualização de Entrada/Saída de Raiz Única (SR-IOV).

  • O SLB inclui a versão 6 (IPv6) do Protocolo Internet e o suporte da versão 4 (IPv4).

  • Para cenários de gateway site a site, o SLB fornece funcionalidade NAT para permitir que todas as ligações site a site utilizem um único IP público.

Dimensionamento e desempenho

  • Pronto para dimensionamento na cloud, incluindo capacidade de aumento horizontal e vertical para MUXes e Agentes anfitriões.

  • Um módulo do Controlador de Rede do Gestor de SLB ativo pode suportar oito instâncias de MUX.

Elevada disponibilidade

  • Pode implementar o SLB em mais de dois nós numa configuração ativa/ativa.

  • Os MUXes podem ser adicionados e removidos do conjunto MUX sem afetar o serviço SLB. Isto mantém a disponibilidade do SLB quando os MUXes individuais estão a ser corrigidos.

  • As instâncias individuais do MUX têm um tempo de atividade de 99%.

  • Os dados de monitorização do estado de funcionamento estão disponíveis para entidades de gestão.

Passos seguintes

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