Поделиться через


Что такое Software Load Balancer (SLB) для SDN?

Применимо к: Azure Local 2311.2 и более поздних версий; Windows Server 2022, Windows Server 2019, Windows Server 2016

Поставщики облачных служб (CSP) и предприятия, развертывающие программно-определяемые сети (SDN), могут использовать Software Load Balancer (SLB) для равномерного распределения сетевого трафика арендаторов и клиентов арендаторов между ресурсами виртуальной сети. SLB позволяет размещать одну и ту же рабочую нагрузку на нескольких серверах, что обеспечивает высокий уровень доступности и масштабирования.

Software Load Balancer can provide a multitenant, unified edge by integrating with SDN technologies such as RAS Gateway, Datacenter Firewall, and Route Reflector.

Примечание.

Мультитенантность для виртуальных ЛС не поддерживается сетевым контроллером. Однако виртуальные локальные сети можно использовать с SLB для управляемых рабочих нагрузок поставщика услуг, таких как инфраструктура центра обработки данных и веб-серверы с высокой плотностью.

С помощью Software Load Balancer можно масштабировать возможности балансировки нагрузки с помощью виртуальных машин SLB на одних вычислительных серверах Hyper-V, используемых для других рабочих нагрузок виртуальных машин. Из-за этого Software Load Balancer поддерживает быстрое создание и удаление конечных точек балансировки нагрузки, необходимых для операций CSP. Кроме того, Software Load Balancer поддерживает десятки гигабит данных на каждую систему, предоставляет простую модель развертывания и легко масштабируется как в большую, так и в меньшую сторону.

Сведения об управлении политиками Software Load Balancer с помощью Центра администрирования Windows см. в статье "Управление подсистемой балансировки нагрузки программного обеспечения для SDN".

Что включает в себя программный балансировщик нагрузки?

Software Load Balancer включает следующие возможности:

  • Службы балансировки нагрузки уровня 4 (L4) для трафика TCP/UDP на севере, юге и востоке и западе.

  • Балансировка нагрузки на общедоступный сетевой трафик и внутренний сетевой трафик.

  • Поддержка динамических IP-адресов (DIPs) в виртуальных локальных сетях (VLAN) и виртуальных сетях, создаваемых с помощью виртуализации сети Hyper-V.

  • Health probe support.

  • Ready for cloud scale, including scale-out capability and scale-up capability for multiplexers and host agents.

Дополнительные сведения см. в разделе Функции Software Load Balancer в этой статье.

Как работает подсистема балансировки нагрузки программного обеспечения

Software Load Balancer работает путем сопоставления виртуальных IP-адресов (VIPs) с DIPs, которые являются частью набора ресурсов облачной службы в центре обработки данных.

VIPs are single IP addresses that provide public access to a pool of load balanced VMs. Например, VIP-адреса — это IP-адреса, доступные в Интернете, чтобы арендаторы и клиенты арендаторов могли подключаться к ресурсам арендатора в облачном центре обработки данных.

DIPs are the IP addresses of the member VMs of a load balanced pool behind the VIP. DIPs are assigned within the cloud infrastructure to the tenant resources.

VIPs are located in the SLB Multiplexer (MUX). The MUX consists of one or more VMs. Network Controller provides each MUX with each VIP, and each MUX in turn uses Border Gateway Protocol (BGP) to advertise each VIP to routers on the physical network as a /32 route. BGP позволяет маршрутизаторам физической сети:

  • Learn that a VIP is available on each MUX, even if the MUXes are on different subnets in a Layer 3 network.

  • Spread the load for each VIP across all available MUXes using Equal Cost Multi-Path (ECMP) routing.

  • Automatically detect a MUX failure or removal and stop sending traffic to the failed MUX.

  • Spread the load from the failed or removed MUX across the healthy MUXes.

When public traffic arrives from the internet, the SLB MUX examines the traffic, which contains the VIP as a destination, and maps and rewrites the traffic so that it arrives at an individual DIP. Для входящего сетевого трафика эта транзакция выполняется в двухфакторном процессе, разделенном между виртуальными машинами MUX и узлом Hyper-V, где находится целевой DIP:

  1. Для балансировки нагрузки MUX использует VIP для выбора DIP, инкапсулирует пакет и перенаправляет трафик на узел Hyper-V, где находится DIP.

  2. Network Address Translation (NAT) - the Hyper-V host removes encapsulation from the packet, translates the VIP to a DIP, remaps the ports, and forwards the packet to the DIP VM.

The MUX knows how to map VIPs to the correct DIPs because of load balancing policies that you define by using Network Controller. К этим правилам относятся протокол, интерфейсный порт, внутренний порт и алгоритм распределения (5, 3 или 2 кортежа).

When tenant VMs respond and send outbound network traffic back to the internet or remote tenant locations, because the NAT is performed by the Hyper-V host, the traffic bypasses the MUX and goes directly to the edge router from the Hyper-V host. This MUX bypass process is called Direct Server Return (DSR).

And after the initial network traffic flow is established, the inbound network traffic bypasses the SLB MUX completely.

На следующем рисунке клиентский компьютер выполняет DNS-запрос для IP-адреса сайта SharePoint компании , в данном случае вымышленной компании Contoso. Происходит следующий процесс:

  1. DNS-сервер возвращает IP-адрес 107.105.47.60 клиенту.

  2. Клиент отправляет HTTP-запрос на VIP.

  3. The physical network has multiple paths available to reach the VIP located on any MUX. Каждый маршрутизатор на пути использует ECMP для выбора следующего сегмента, пока запрос не достигнет мультиплексора.

  4. The MUX that receives the request checks configured policies, and sees that there are two DIPs available, 10.10.10.5 and 10.10.20.5, on a virtual network to handle the request to the VIP 107.105.47.60

  5. MuX выбирает DIP 10.10.10.5 и инкапсулирует пакеты с помощью VXLAN, чтобы он смог отправить его на узел, содержащий DIP с помощью физического сетевого адреса узла.

  6. Хост получает инкапсулированный пакет и проверяет его. Он удаляет инкапсуляцию и перезаписывает пакет, так что теперь адресатом является DIP 10.10.10.5 вместо VIP, а затем отправляет трафик на виртуальную машину DIP.

  7. Запрос достигает сайта Contoso SharePoint в ферме серверов 2. Сервер создает ответ и отправляет его клиенту с помощью собственного IP-адреса в качестве источника.

  8. The host intercepts the outgoing packet in the virtual switch, which remembers that the client, now the destination, made the original request to the VIP. The host rewrites the source of the packet to be the VIP so that the client doesn't see the DIP address.

  9. Узел сети отправляет пакет непосредственно в шлюз по умолчанию физической сети, который использует стандартную таблицу маршрутизации для перенаправления пакета клиенту, который в конечном итоге получает ответ.

Процесс балансировки нагрузки программного обеспечения.

Балансировка нагрузки внутреннего трафика центра обработки данных

При балансировке сетевого трафика внутри центра обработки данных, например между ресурсами клиента, работающими на разных серверах, и являются членами одной виртуальной сети, виртуальный коммутатор Hyper-V, к которому подключены виртуальные машины, выполняют NAT.

При балансировке нагрузки внутреннего трафика первый запрос отправляется и обрабатывается MUX, который выбирает соответствующий DIP, а затем направляет трафик в DIP. From that point forward, the established traffic flow bypasses the MUX and goes directly from VM to VM.

Health probes

Software Load Balancer включает пробы работоспособности для проверки работоспособности сетевой инфраструктуры, включая следующие:

  • TCP probe to port

  • HTTP probe to port and URL

В отличие от традиционного аппаратного устройства балансировки нагрузки, где проба возникает на устройстве и перемещается по проводам к DIP, проба SLB возникает на хосте, где находится DIP, и переходит непосредственно от агента хоста SLB к DIP, обеспечивая дальнейшее распределение нагрузки между хостами.

Инфраструктура программного балансировщика нагрузки

Before you can configure Software Load Balancer, you must first deploy Network Controller and one or more SLB MUX VMs.

Кроме того, необходимо настроить локальные узлы Azure с виртуальным коммутатором Hyper-V с поддержкой SDN и убедиться, что агент узла SLB запущен. Маршрутизаторы, обслуживающие хосты, должны поддерживать маршрутизацию ECMP и протокол BGP и быть настроены для приема запросов пиринга BGP от SLB MUX.

На следующем рисунке представлен обзор инфраструктуры SLB.

Software Load Balancer infrastructure.

В следующих разделах приведены дополнительные сведения об этих элементах инфраструктуры Software Load Balancer.

Сетевой контроллер

Network Controller hosts the SLB Manager and performs the following actions for Software Load Balancer:

  • Обрабатывает команды SLB, поступающие через API Northbound из Windows Admin Center, System Center, Windows PowerShell или другого приложения управления сетями.

  • Calculates policy for distribution to Azure Local hosts and SLB MUXes.

  • Предоставляет состояние работоспособности инфраструктуры Software Load Balancer.

Вы можете использовать Windows Admin Center или Windows PowerShell для установки и настройки сетевого контроллера и другой инфраструктуры SLB.

SLB MUX

The SLB MUX processes inbound network traffic and maps VIPs to DIPs, then forwards the traffic to the correct DIP. Each MUX also uses BGP to publish VIP routes to edge routers. BGP Keep Alive notifies MUXes when a MUX fails, which allows active MUXes to redistribute the load in case of a MUX failure. Это, по сути, обеспечивает балансировку нагрузки для подсистем балансировки нагрузки.

SLB Host Agent

При развертывании Software Load Balancer необходимо использовать Windows Admin Center, System Center, Windows PowerShell или другое приложение управления для развертывания агента узла SLB на каждом сервере узла.

The SLB Host Agent listens for SLB policy updates from Network Controller. In addition, the host agent programs rules for SLB into the SDN-enabled Hyper-V virtual switches that are configured on the local computer.

Виртуальный коммутатор Hyper-V с поддержкой SDN

Для обеспечения совместимости виртуального коммутатора с SLB расширение виртуальной платформы фильтрации (VFP) должно быть включено на виртуальном коммутаторе. Это выполняется автоматически с помощью сценариев развертывания PowerShell SDN, мастера установки Windows Admin Center и диспетчера виртуальных машин System Center Virtual Machine Manager (SCVMM).

Сведения о включении VFP на виртуальных коммутаторах см. в командах Windows PowerShell Get-VMSystemSwitchExtension и Enable-VMSwitchExtension.

Виртуальный коммутатор Hyper-V с поддержкой SDN выполняет следующие действия для SLB:

  • Processes the data path for SLB.

  • Получает входящий сетевой трафик из MUX.

  • Bypasses the MUX for outbound network traffic, sending it to the router using DSR.

Маршрутизатор BGP

Маршрутизатор BGP выполняет следующие действия для Software Load Balancer:

  • Маршрутизирует входящий трафик в muX с помощью ECMP.

  • Для исходящего сетевого трафика используется маршрут, предоставленный узлом.

  • Listens for route updates for VIPs from SLB MUX.

  • Removes SLB MUXes from the SLB rotation if Keep Alive fails.

Функции Подсистемы балансировки нагрузки программного обеспечения

В следующих разделах описаны некоторые функции и возможности Software Load Balancer.

Базовая функциональность

  • SLB предоставляет службы балансировки нагрузки уровня 4 для северо-южного и восточно-западного движения трафика TCP/UDP.

  • SLB можно использовать в сети, основанной на виртуализации сети Hyper-V.

  • You can use SLB with a VLAN-based network for DIP VMs connected to an SDN enabled Hyper-V virtual switch.

  • One SLB instance can handle multiple tenants.

  • SLB и DIP поддерживают масштабируемый путь возврата с низкой задержкой, который реализован в DSR.

  • SLB functions when you're also using Switch Embedded Teaming (SET) or Single Root Input/Output Virtualization (SR-IOV).

  • SLB включает поддержку протокола Internet Protocol версии 6 (IPv6) и версии 4 (IPv4).

  • В сценариях шлюза 'сеть-сеть' SLB предоставляет функции NAT для обеспечения использования всех подключений через один общедоступный IP-адрес.

Масштаб и производительность

  • Ready for cloud scale, including scale-out and scale-up capability for MUXes and Host Agents.

  • One active SLB Manager Network Controller module can support eight MUX instances.

Высокая доступность

  • You can deploy SLB to more than two nodes in an active/active configuration.

  • MUXes can be added and removed from the MUX pool without impacting the SLB service. This maintains SLB availability when individual MUXes are being patched.

  • Individual MUX instances have an uptime of 99 percent.

  • Данные мониторинга состояния доступны для управляющих структур.

Следующие шаги

Дополнительные сведения см. также: