Was ist Software Load Balancer (SLB) für SDN?

Artikel
04/23/2024

Gilt für: Azure Stack HCI, Versionen 23H2 und 22H2; Windows Server 2022, Windows Server 2019, Windows Server 2016

Clouddienstanbieter (Cloud Service Providers, CSPs) und Unternehmen, die Software-Defined Networking (SDN) bereitstellen, können Software Load Balancer (SLB) verwenden, um den Netzwerkdatenverkehr zwischen Mandanten und zwischen Mandanten und Kunden gleichmäßig auf virtuelle Netzwerkressourcen zu verteilen. SLB ermöglicht es Ihnen, mehrere Server zum Hosten derselben Workload zu aktivieren, um hohe Verfügbarkeit und Skalierbarkeit bereitzustellen.

Software Load Balancer kann durch die Integration in SDN-Technologien wie RAS Gateway, Datacenter Firewall und Route Reflector einen mehrinstanzenfähigen, einheitlichen Edge bieten.

Hinweis

Mehrinstanzenfähigkeit für VLANs wird vom Netzwerkcontroller nicht unterstützt. Allerdings können Sie VLANs mit SLB für vom Dienstanbieter verwaltete Workloads verwenden, z. B. die Rechenzentrumsinfrastruktur und Webserver mit hoher Dichte.

Mithilfe von Software Load Balancer können Sie Ihre Lastenausgleichsfunktionen mithilfe von virtuellen SLB-Computern (VMs) auf denselben Hyper-V-Compute-Servern, die Sie für Ihre anderen VM-Workloads verwenden, horizontal hochskalieren. Aus diesem Grund unterstützt der Software Load Balancer das schnelle Erstellen und Löschen von Lastenausgleichsendpunkten, das für den CSP-Betrieb erforderlich ist. Außerdem unterstützt der Software Load Balancer mehrere zehn Gigabyte pro Cluster, bietet ein einfaches Bereitstellungsmodell und lässt sich problemlos horizontal hoch- und herunterskalieren.

Informationen zum Verwalten von Software Load Balancer-Richtlinien mithilfe von Windows Admin Center finden Sie unter Verwalten von Software Load Balancer für SDN.

Was umfasst Software Load Balancer?

Software Load Balancer umfasst die folgenden Funktionen:

Layer 4-Load Balancing-Dienste (L4) für TCP/UDP-Datenverkehr in Nord/Süd- und Ost/West-Richtung.
Lastenausgleich des Datenverkehrs im öffentlichen Netzwerk und im internen Netzwerk.
Unterstützung dynamischer IP-Adressen (DIPs) in virtuellen lokalen Netzwerken (VLANs) und in virtuellen Netzwerken, die Sie mithilfe der Hyper-V-Netzwerkvirtualisierung erstellen.
Unterstützung für Integritätstests.
Bereit für Cloudskalierung, einschließlich Funktionen für horizontales Hochskalieren und zentrales Hochskalieren für Multiplexer und Host-Agents.

Weitere Informationen finden Sie unter Funktionen des Software Load Balancers in diesem Artikel.

Funktionsweise von Software Load Balancer

Software Load Balancer funktioniert, indem virtuelle IP-Adressen (VIPs) zu DIPs zugeordnet werden, die Teil eines Clouddienstsatzes von Ressourcen im Rechenzentrum sind.

VIPs sind einzelne IP-Adressen, die öffentlichen Zugriff auf einen Pool von virtuellen Computern mit Lastenausgleich ermöglichen. VIPs sind z. B. IP-Adressen, die über das Internet zugänglich gemacht werden, sodass Mandanten und Kunden von Mandanten eine Verbindung mit Mandantenressourcen im Cloudrechenzentrum herstellen können.

DIPs sind die IP-Adressen der virtuellen Mitgliedscomputer eines Pools mit Lastenausgleich hinter der VIP. DIPs werden den Mandantenressourcen innerhalb der Cloudinfrastruktur zugewiesen.

VIPs befinden sich im SLB-Multiplexer (MUX). Der MUX besteht aus einem oder mehreren virtuellen Computern. Der Netzwerkcontroller stellt jedem MUX jede VIP zur Verfügung, und jeder MUX verwendet wiederum das Border Gateway Protocol (BGP), um den Routern im physischen Netzwerk jede VIP als /32-Route anzukündigen. BGP ermöglicht den physischen Netzwerkroutern Folgendes:

Erfahren, dass eine VIP-Adresse an jedem MUX verfügbar ist, auch wenn sich die MUXe in unterschiedlichen Subnetzen in einem Layer 3-Netzwerk befinden.
Verteilen der Last für jede VIP über alle verfügbaren MUXe mithilfe von ECMP-Routing (Equal Cost Multi-Path).
Automatisches Erkennen eines MUX-Fehlers oder der Entfernung eines MUX sowie das Beenden des Sendens von Datenverkehr an den fehlgeschlagenen MUX.
Verteilen der Last vom fehlerhaften oder entfernten MUX auf die fehlerfreien MUXe.

Wenn öffentlicher Datenverkehr aus dem Internet eingeht, untersucht die SLB MUX den Datenverkehr, der die VIP als Ziel enthält, und ordnet den Datenverkehr zu und schreibt ihn um, sodass er an einem einzelnen DIP ankommt. Für eingehenden Netzwerkdatenverkehr wird diese Transaktion in einem zweistufigen Prozess durchgeführt, der zwischen den virtuellen MUX-Computern und dem Hyper-V-Host, auf dem sich die Ziel-DIP befindet, aufgeteilt wird:

Lastenausgleich: Der MUX verwendet die VIP, um eine DIP auszuwählen, kapselt das Paket und leitet den Datenverkehr an den Hyper-V-Host weiter, auf dem sich die DIP befindet.
Netzwerkadressübersetzung (Network Address Translation, NAT): Der Hyper-V-Host entfernt die Kapselung von dem Paket, übersetzt die VIP in eine DIP, ordnet die Ports neu zu und leitet das Paket an den virtuellen DIP-Computer weiter.

Der MUX weiß durch von Ihnen mithilfe des Netzwerkcontrollers definierten Lastenausgleichsrichtlinien, wie VIPs den richtigen DIPs zugeordnet werden. Diese Regeln umfassen Protokoll, Front-End-Port, Back-End-Port und den Verteilungsalgorithmus (5-, 3- oder 2-Tupel).

Wenn Mandanten-VMs antworten und ausgehenden Netzwerkdatenverkehr zurück an das Internet oder die Remotemandantenstandorte senden, weil die NAT vom Hyper-V-Host ausgeführt wird, umgeht der Datenverkehr den MUX und erreicht direkt vom Hyper-V-Host aus den Edgerouter. Dieser MUX-Umgehungsprozess wird als Direct Server Return (DSR) bezeichnet.

Nachdem der anfängliche Netzwerkdatenverkehrsfluss hergestellt wurde, umgeht der eingehende Netzwerkdatenverkehr den SLB-MUX vollständig.

In der folgenden Abbildung führt ein Clientcomputer eine DNS-Abfrage für die IP-Adresse einer SharePoint-Unternehmenssite aus – in diesem Fall ein fiktives Unternehmen mit dem Namen „Contoso“. Der folgende Prozess läuft ab:

Der DNS-Server gibt die VIP 107.105.47.60 an den Client zurück.
Der Client sendet eine HTTP-Anforderung an die VIP.
Das physische Netzwerk verfügt über mehrere Pfade, um die VIP zu erreichen, die sich auf einem beliebigen MUX befindet. Jeder Router entlang des Wegs verwendet ECMP, um das nächste Segment des Pfads auszuwählen, bis die Anforderung bei einem MUX eintrifft.
Der MUX, der die Anforderung empfängt, überprüft konfigurierte Richtlinien und erkennt, dass zwei DIPS, 10.10.10.5 und 10.10.20.5, in einem virtuellen Netzwerk verfügbar sind, um die Anforderung an die VIP 107.105.47.60 zu verarbeiten.
Der MUX wählt die DIP 10.10.10.5 aus und kapselt die Pakete mithilfe von VXLAN, damit er sie mithilfe der physischen Netzwerkadresse des Hosts an den Host senden kann, auf dem sich die DIP-Adresse befindet.
Der Host empfängt das gekapselte Paket und überprüft es. Er entfernt die Kapselung und schreibt das Paket so neu, dass das Ziel jetzt die DIP 10.10.10.5 anstelle der VIP ist, und sendet dann den Datenverkehr an den virtuellen DIP-Computer.
Die Anforderung erreicht die SharePoint-Site „Contoso“ in der Serverfarm 2. Der Server generiert eine Antwort und sendet sie an den Client, wobei seine eigene IP-Adresse als Quelle verwendet wird.
Der Host fängt das ausgehende Paket im virtuellen Switch ab, der sich daran erinnert, dass der Client, jetzt das Ziel, die ursprüngliche Anforderung an die VIP gestellt hat. Der Host schreibt die Quelle des Pakets um, sodass der Client die DIP-Adresse nicht sieht.
Der Host leitet das Paket direkt an das Standardgateway für das physische Netzwerk weiter, das seine Standardroutingtabelle verwendet, um das Paket an den Client weiterzuleiten, der schließlich die Antwort empfängt.

Lastenausgleich für internen Rechenzentrumsdatenverkehr

Beim Lastenausgleich des internen Netzwerkdatenverkehrs an das Rechenzentrum, z. B. zwischen Mandantenressourcen, die auf unterschiedlichen Servern ausgeführt werden und Mitglieder desselben virtuellen Netzwerks sind, führt der virtuelle Hyper-V-Switch, mit dem die virtuellen Computer verbunden sind, die NAT aus.

Beim Lastenausgleich des internen Datenverkehrs wird die erste Anforderung an den MUX gesendet und von diesem verarbeitet, wobei er die geeignete DIP auswählt und den Datenverkehr dann an die DIP weiterleitet. Ab diesem Zeitpunkt umgeht der hergestellte Datenverkehrsfluss den MUX und fließt direkt zwischen den VMs.

Integritätstests

Software Load Balancer umfasst Integritätstests zum Überprüfen der Integrität der Netzwerkinfrastruktur, einschließlich der folgenden:

TCP-Test an Port
TCP-Test an Port und URL

Anders als bei einem herkömmlichen Lastenausgleichsgerät, bei dem der Test von dem Gerät stammt und über das Kabel an die DIP gesendet wird, stammt der SLB-Test von dem Host, auf dem sich die DIP befindet, und wird direkt vom SLB-Host-Agent zu der DIP gesendet, sodass die Arbeit noch weiter auf die Hosts verteilt wird.

Software-Load Balancer-Infrastruktur

Bevor Sie Software Load Balancer konfigurieren können, müssen Sie zuerst den Netzwerkcontroller und mindestens einen virtuellen SLB-MUX-Computer bereitstellen.

Außerdem müssen Sie die Azure Stack HCI-Hosts mit dem SDN-fähigen virtuellen Hyper-V-Switch konfigurieren und sicherstellen, dass der SLB-Host-Agent ausgeführt wird. Die Router, die die Hosts versorgen, müssen ECMP-Routing und das Border Gateway Protocol (BGP) unterstützen, und Sie müssen so konfiguriert sein, dass BGP-Peeringanforderungen von den SLB-MUXen akzeptiert werden.

Die folgende Abbildung bietet eine Übersicht über die SLB-Infrastruktur.

Die folgenden Abschnitte enthalten weitere Informationen zu diesen Elementen der Software Load Balancer-Infrastruktur.

Netzwerkcontroller

Der Netzwerkcontroller hostet den SLB-Manager und führt die folgenden Aktionen für den Software Load Balancer aus:

Verarbeitung von SLB-Befehlen, die über die Northbound-API von Windows Admin Center, System Center, Windows PowerShell oder einer anderen Netzwerkverwaltungsanwendung eingehen.
Berechnung der Richtlinie für die Verteilung an Azure Stack HCI-Hosts und SLB-MUXe.
Bereitstellung des Integritätsstatus der Software Load Balancer-Infrastruktur.

Sie können das Windows Admin Center oder die Windows PowerShell verwenden, um Netzwerkcontroller und andere SLB-Infrastrukturen zu installieren und zu konfigurieren.

SLB-MUX

Der SLB-MUX verarbeitet den eingehenden Netzwerkdatenverkehr, ordnet VIPs zu DIPs zu und leitet den Datenverkehr anschließend an die richtige DIP weiter. Jeder MUX verwendet außerdem BGP zum Veröffentlichen von VIP-Routen an Edgerouter. BGP-Keep-Alive benachrichtigt MUXe, wenn ein MUX ausfällt. Dies ermöglicht es aktiven MUXen, die Last im Falle eines MUX-Ausfalls neu umzuverteilen. Dies bietet im Wesentlichen Lastenausgleich für die Load Balancer.

SLB-Host-Agent

Beim Bereitstellen des Software Load Balancers müssen Sie Windows Admin Center, System Center, Windows PowerShell oder eine andere Verwaltungsanwendung verwenden, um den SLB-Host-Agent jedem der Hostserver bereitzustellen.

Der SLB-Host-Agent lauscht auf SLB-Richtlinienaktualisierungen vom Netzwerkcontroller. Darüber hinaus programmiert der Host-Agent Regeln für SLB in die SDN-fähigen virtuellen Hyper-V-Switches, die auf dem lokalen Computer konfiguriert sind.

SDN-fähiger virtueller Hyper-V-Switch

Damit ein virtueller Switch mit SLB kompatibel ist, muss die VFP-Erweiterung (Virtual Filtering Platform) auf dem virtuellen Switch aktiviert sein. Dies erfolgt automatisch durch die PowerShell-Bereitstellungsskripts für SDN, den Bereitstellungs-Assistenten für Windows Admin Center und die System Center Virtual Machine Manager (SCVMM)-Bereitstellung.

Informationen zum Aktivieren von VFP auf virtuellen Switches finden Sie unter den Windows PowerShell-Befehlen Get-VMSystemSwitchExtension und Enable-VMSwitchExtension.

Der SDN-fähige virtuelle Hyper-V-Switch führt die folgenden Aktionen für den SLB aus:

Verarbeitung des Datenpfads für den SLB.
Empfangen eingehenden Netzwerkdatenverkehrs vom MUX.
Umgehen des MUX für ausgehenden Netzwerkdatenverkehr und Senden dieses Datenverkehrs mithilfe von DSR an den Router.

BGP-Router

Der BGP-Router führt die folgenden Aktionen für den Software Load Balancer aus:

Routing eingehenden Datenverkehrs mithilfe von ECMP an den MUX.
Bei ausgehendem Netzwerkdatenverkehr Verwendung der vom Host bereitgestellten Route.
Lauschen auf Routenaktualisierungen für VIPs vom SLB-MUX.
Entfernen von SLB-MUXen aus der SLB-Rotation, wenn Keep-Alive fehlschlägt.

Software-Load Balancer-Features

In den folgenden Abschnitten werden einige der Features und Funktionen des Software Load Balancers beschrieben.

Kernfunktionalität

Der SLB bietet Layer 4-Load Balancing-Dienste für TCP/UDP-Datenverkehr in Nord/Süd- und Ost/West-Richtung.
Sie können den SLB in einem Netzwerk verwenden, das auf Hyper-V-Netzwerkvirtualisierung basiert.
Sie können SLB mit einem VLAN-basierten Netzwerk für DIP-VMs verwenden, die mit einem virtuellen Hyper-V-Switch mit SDN-Unterstützung verbunden sind.
Eine SLB-Instanz kann mehrere Mandanten verarbeiten.
SLB und DIP unterstützen einen skalierbaren Rückgabepfad mit niedriger Latenz, wie er von DSR implementiert wird.
SLB-Funktionen, wenn Sie auch Switch Embedded Teaming (SET) oder SR-IOV (Single Root Input/Output Virtualization) verwenden.
SLB umfasst Unterstützung für die Internetprotokollversionen 6 (IPv6) und 4 (IPv4).
Für Site-to-Site-Gatewayszenarien bietet SLB NAT-Funktionen, um allen Site-to-Site-Verbindungen die Verwendung einer einzelnen öffentlichen IP-Adresse zu ermöglichen.

Skalierung und Leistung

Bereit für Cloudskalierung, einschließlich Funktionen für horizontales Hochskalieren und zentrales Hochskalieren für MUXe und Host-Agents.
Ein aktives SLB-Manager-Netzwerkcontrollermodul kann acht MUX-Instanzen unterstützen.

Hochverfügbarkeit

Sie können SLB auf mehr als zwei Knoten in einer Aktiv/Aktiv-Konfiguration bereitstellen.
MUXe können dem MUX-Pool hinzugefügt und daraus entfernt werden, ohne dass sich dies auf den SLB-Dienst auswirkt. Hierdurch wird die SLB-Verfügbarkeit aufrechterhalten, wenn einzelne MUXe gepatcht werden.
Einzelne MUX-Instanzen haben eine Uptime von 99 %.
Systemüberwachungsdaten sind für Verwaltungsentitäten verfügbar.

Nächste Schritte

Verwandte Informationen finden Sie außerdem unter: