Freigeben über

Problembehandlung beim Softwarelastenausgleich für SDN

Gilt für: Azure Local 2311.2 und höher; Windows Server 2022, Windows Server 2019

Wenn Sie Software Load Balancer (SLB) für Software Defined Networking (SDN) eingerichtet haben und Ihr Datenpfad nicht über SLB funktioniert, kann es mehrere Gründe dafür geben. Dieser Artikel hilft Ihnen, einige häufige Probleme in SLB für SDN zu identifizieren und zu beheben.

Eine Übersicht über die SLB und deren Verwaltung finden Sie unter Was ist Software Load Balancer (SLB) für SDN? und Manage Software Load Balancer für SDN.

Workflow bei der Problembehandlung

Hier ist der allgemeine Workflow zur Behandlung von SLB-Problemen:

  • Überprüfen des Konfigurationszustands der VMs (MUX) von SLB Multiplexer
  • Behandeln häufig auftretender Konfigurationsstatusfehler
  • SLB-Zustandsabbild sammeln

Überprüfen des Konfigurationszustands der SLB-Multiplexer-VMs

Sie müssen zuerst den Konfigurationsstatus der SLB MUX-VMs überprüfen. Dazu können Sie entweder Windows Admin Center oder PowerShell verwenden.

Führen Sie die folgenden Schritte aus, um den Konfigurationsstatus des SLB MUX über Windows Admin Center zu überprüfen:

  1. Wählen Sie auf der Startseite von Windows Admin Center unter "Alle Verbindungen" das System aus, mit dem Sie eine Verbindung herstellen möchten.

  2. Scrollen Sie unter "Extras" nach unten zum Netzwerkbereich . Wählen Sie SDN-Infrastruktur und dann "Zusammenfassung" aus. Wenn es Probleme mit SLB gibt, wird dies im Abschnitt Lastenausgleichs-MUX angezeigt. Wenn keine Probleme auftreten, befinden sich alle MUX-VMs im Zustand "Fehlerfrei ".

    Screenshot der Seite „SDN-Infrastruktur“ im Windows Admin Center, die den Status von Lastenausgleichs-MUX zeigt

Behandeln häufig auftretender Konfigurationsstatusfehler

In diesem Abschnitt wird beschrieben, wie Häufige Fehler behoben werden, wenn der Konfigurationsstatus der SLB-MUX-VMs nicht fehlerfrei ist.

SLB MUX ist nicht mit einem BGP-Router verbunden

Dieser Fehler tritt auf, wenn die MUX-VMs keine BGP-Peering (Border Gateway Protocol) mit den Top-of-Rack-Switches (ToR) herstellen konnten. Denken Sie daran, dass MUX-Peers zu ToR über BGP am Port 179 führen.

So beheben Sie den MUX-VMs und den BGP-Routerverbindungsfehler:

  • Stellen Sie sicher, dass Die Verbindung zwischen den MUX-VMs und den ToR-Switches besteht. Wenn Sie die Netzwerkvirtualisierung verwenden, sollte das Peering über das Hyper-V Network Virtualization Provider Address (HNV PA)-Netzwerk erfolgen.

  • Überprüfen Sie, ob die Verbindung hergestellt wird, indem Sie folgendes auf den MUX-VMs ausführen:

    Netstat -anp tcp | findstr 179

    Wenn keine Verbindung zwischen MUX und ToR besteht, überprüfen Sie, ob der ToR über MUX Test-NetConnectionerreichbar ist. Wenn MUX toR nicht erreichen kann, liegt ein Problem mit dem zugrunde liegenden Fabric-Netzwerk oder ToR vor.

    Test-NetConnection -ComputerName <ToR_IP> -Port 179

    Dabei gilt Folgendes:

    • ToR_IP ist Teil der loadBalancerMuxes-Ressource.

    Es folgt ein Codeausschnitt der LoadBalancerMux-Ressource mit der ToR-IP-Adresse 192.168.200.1:

        Get-NetworkControllerLoadBalancerMux -ConnectionUri $uri|ConvertTo-Json -Depth 10 

    "peerRouterConfigurations": [ 
        { 
          "localIPAddress": "", 
          "routerName": "BGPGateway-64000-64001", 
          "routerIPAddress": "192.168.200.1", 
          "peerASN": 64001, 
          "id": "be5850aa-4dce-4203-a9f2-f3de25eaacba" 
        }

  • Wenn Sie mehrere Switches konfiguriert haben, stellen Sie sicher, dass alle mit den MUX-VMs peered werden.

  • Führen Sie das Test-SDNExpressBGP Skript für einen der physischen Hosts aus, um weiteres Debuggen im Zusammenhang mit einem fehlgeschlagenen BGP-Peering durchzuführen:

    Install-Module test-sdnexpressbgp
Test-SDNExpressBGP -RouterIPAddress 10.10.182.3 -LocalIPAddress 10.10.182.7 -LocalASN 64628 -verbose -ComputerName sa18n22mux02 -force

    Dabei gilt Folgendes:

    • RouterIPAddress ist toR IP
    • LocalIPAddress ist die PA-IP-Adresse von der VM SLBMUX
    • LocalASN ist die SDN SLB ASN
    • ComputerName ist der Name der VM SLBMUX

    Das Skript beendet den SLBMUX-Dienst auf der MUX-VM, versucht, eine Verbindung herzustellen, entweder fehlgeschlagen oder abgeschlossen, und enthält weitere Details, wenn ein Fehler auftritt.

Virtueller Server ist nicht erreichbar

Sie können diesen Fehler aufgrund von Netzwerkfehlern oder einer Authentifizierungsverweigerung auf dem virtuellen Server erhalten. Dies weist in der Regel darauf hin, dass der Netzwerkcontroller keine Verbindung mit den SLB-MUX-VMs herstellen kann.

Um probleme zu beheben, warum der virtuelle Server nicht erreichbar ist, überprüfen Sie Folgendes:

  • Es gibt Verbindungen zwischen dem Netzwerkcontroller und den MUX-VMs. Führen Sie den folgenden Befehl aus, um die Konnektivität zu überprüfen:

    Test-NetConnection -ComputerName <MUX IP address> -Port 8560

  • Der MUX-Dienst wird auf den MUX-VMs ausgeführt. Um dies zu überprüfen, führen Sie den folgenden Befehl aus einer PowerShell-Sitzung auf den MUX-VMs aus. Der Status muss ausgeführt werden.

    Get-Service slbmux

  • Es gibt keine Firewallprobleme. Stellen Sie sicher, dass Port 8560 von der Firewall auf der MUX-VM nicht blockiert wird. Wenn der Test-NetConnection Befehl erfolgreich ist, bedeutet dies, dass kein Firewallproblem besteht.

Zertifikat nicht vertrauenswürdig oder Zertifikat nicht autorisiert

Sie können diesen Fehler erhalten, wenn das vom SLB MUX für den Netzwerkcontroller vorgelegte Zertifikat einige Probleme hat.

  1. Führen Sie zum Identifizieren des Zertifikats den folgenden Befehl auf den MUX-VMs aus:

    $cert= get-childitem "cert:\localmachine\my"| where-object {$_.Subject.ToUpper() eq "CN=$NodeFQDN".ToUpper()}

    Dabei gilt Folgendes:

    • NodeFQDN ist der FQDN der MUX-VM.

  2. Überprüfen Sie nach dem Identifizieren des Zertifikats das Zertifikat:

    1. Führen Sie zum Testen des Zertifikats den folgenden Befehl aus:

      Test-Certificate $cert

    2. Stellen Sie sicher, dass das Zertifikat von den VMs des Netzwerkcontrollers als vertrauenswürdig eingestuft wird. Wenn es sich bei dem Zertifikat um ein selbstsigniertes Zertifikat handelt, muss dasselbe Zertifikat im Stammspeicher aller VMs des Netzwerkcontrollers vorhanden sein. Wenn das Zertifikat ca-signiert ist, muss das Zertifizierungsstellenzertifikat im Stammspeicher aller VMs des Netzwerkcontrollers vorhanden sein. Führen Sie zum Auflisten aller Zertifikate im Stammspeicher der VMs des Netzwerkcontrollers den folgenden Befehl auf allen VMs des Netzwerkcontrollers aus:

      get-childitem "cert:\localmachine\root"

Richtlinienkonfigurationsfehler

Dieser Fehler kann als eines der folgenden Manifeste auftreten: PolicyConfigurationFailureonHost, PolicyConfigurationFailureonMux, PolicyConfigurationFailureonVfp oder PolicyConfigurationFailure.

Dieser Fehler tritt auf, wenn der Netzwerkcontroller keine Richtlinien an die SLB MUX-VMs oder die Hyper-V-Hosts übertragen kann, entweder aufgrund von Erreichbarkeits- oder Zertifikatproblemen oder einem anderen Problem.

Um den Fehler bei richtlinienkonfigurationsfehlern zu beheben, überprüfen Sie zuerst, ob es Zustellbarkeits- und Zertifikatprobleme gibt. Siehe schritte in den vorherigen Abschnitten: SLB MUX ist nicht mit einem BGP-Router verbunden, virtueller Server ist nicht erreichbar, und Zertifikat nicht vertrauenswürdig oder Zertifikat nicht autorisiert.

Wenn es keine Reichweite und kein Zertifikatproblem gibt, führen Sie die folgenden Schritte aus, um die Konnektivität zwischen dem Netzwerkcontroller und den SLB MUX-VMs und dem SLB-Host-Agent auf dem Host zu überprüfen:

  1. Überprüfen Sie die Verbindung zwischen dem Netzwerkcontroller und SLB MUX-VMs. Beachten Sie, dass der Netzwerkcontroller (SlbManager-Dienst) eine Verbindung mit MUX an Port 8560 herstellt. Der Netzwerkcontroller initiiert die Verbindung. Verschiedene Konfigurationen für virtuelle IP-Adressen (VIP), SNAT-Ports (Source Network Address Translation) usw. werden über diese Verbindung übertragen.

    Führen Sie zum Überprüfen der Verbindung zwischen dem Netzwerkcontroller und SLB MUX auf SLB MUX-VMs aus netstat .

    Hier ist eine Beispielausgabe der Befehlsverwendung:

    netstat -anp tcp | findstr 8560 
TCP    0.0.0.0:8560           0.0.0.0:0              LISTENING 
TCP    100.88.79.12:8560      100.88.79.9:59977      ESTABLISHED

  2. Überprüfen Sie die Verbindung zwischen dem Netzwerkcontroller und dem SLB-Host-Agent. Beachten Sie, dass der SLB-Host-Agent eine Verbindung mit dem Netzwerkcontroller (SlbManager-Dienst) an Port 8571 herstellt. Verschiedene SLB-Richtlinien werden über diese Verbindung übertragen.

    Um die Konnektivität zwischen dem Netzwerkcontroller und dem SLB-Host-Agent zu überprüfen, führen Sie die Ausführung netstat auf dem physischen Host aus.

    Hier ist eine Beispielausgabe der Befehlsverwendung:

    netstat -anp tcp | findstr 8571 
TCP    100.88.79.128:56258    100.88.79.9:8571       ESTABLISHED

Probleme mit der Datenpfadkonnektivität

Möglicherweise erhalten Sie Probleme mit der Datenpfadkonnektivität, auch wenn sich die SLB-MUX-VMs in einem fehlerfreien Konfigurationszustand befinden. Dies bedeutet, dass der SLB-Verkehr irgendwo auf dem Weg verworfen wird. Um zu ermitteln, wo der Datenverkehr verworfen wird, müssen Sie Datenpfadablaufverfolgungen sammeln. Bevor Sie dies tun, stellen Sie Folgendes sicher:

  • Die ToR-Option kann die angekündigten VIPs sehen. Wenn Sie einen Lastenausgleichsmodul für den Lastenausgleich, eingehende NAT, ausgehende NAT oder eine Kombination dieser eingerichtet haben, wird die Lastenausgleichs-VIP für den ToR angekündigt. Überprüfen Sie mithilfe der Switch CLI, ob die VIP angekündigt wird.

  • Die SLBM VIP darf nicht auf dem ToR oder physischen Firewalls blockiert werden. Dies ist die IP-Adresse, die als loadBalancerManagerIPAddress in der LoadBalancerManager/config-Ressource des Netzwerkcontrollers angegeben wird. Wenn das eingehende Paket eingeht und die MUX-VM die richtige Back-End-IP bestimmt, an die das Paket gesendet werden soll, sendet es das Paket mit der Quell-IP-Adresse als MUX SLBM VIP. Es kann Szenarien geben, in denen dies auf dem ToR abgelegt wird.

  • SLB Health-Sonden sind auf dem Laufenden. Wenn Sie SLB-Integritätssonden konfiguriert haben, stellen Sie sicher, dass mindestens eine der Back-End-VMs aktiv ist und auf die Integritätsprüfung reagieren kann. Sie können auch den Zustand der Tests über das SLB-Zustandsabbildabrufen, wie weiter unten in diesem Artikel beschrieben.

  • Die Firewall innerhalb der Back-End-VM blockiert keinen Datenverkehr. Stellen Sie sicher, dass die Hostfirewall in den Back-End-VMs eingehenden SLB-Datenverkehr nicht blockiert.

  • SDN-Netzwerksicherheitsgruppen blockieren keinen Datenverkehr. Möglicherweise sind einige Netzwerksicherheitsgruppen entweder direkt auf der Back-End-NIC oder im Subnetz konfiguriert. Stellen Sie sicher, dass die Netzwerksicherheitsgruppe eingehendeN SLB-Datenverkehr nicht blockiert.

    1. Um die Netzwerksicherheitsgruppen über PowerShell zu überprüfen, führen Sie die folgenden Befehle auf einem Computer aus, die REST-Befehle an den Netzwerkcontroller ausgeben können:

      • Führen Sie den folgenden Befehl aus, um die Details der NetworkInterface-Ressource abzurufen:

        Get-NetworkControllerNetworkInterface –ConnectionUri <REST uri of Network Controller> -ResourceId <Resource ID of the backend NIC>|ConvertTo-Json –Depth 10

      • Führen Sie den folgenden Befehl aus, um die Details der VirtualNetworkSubnet-Ressource abzurufen:

        Get-NetworkControllerVirtualNetwork –ConnectionUri <REST uri of Network Controller> -ResourceId <Resource ID of the network>|ConvertTo-Json –Depth 10

      • Um die Details der LogicalNetworkSubnet-Ressource abzurufen, führen Sie den folgenden Befehl aus:

        Get-NetworkControllerLogicalNetwork –ConnectionUri <REST uri of Network Controller> -ResourceId <Resource ID of the network>|ConvertTo-Json –Depth 10

    2. Die Ausgabe der vorherigen Befehle hat einen Abschnitt für AccessControlList. Sie können überprüfen, ob einer AccessControlList dieser Ressourcen zugeordnet ist. Wenn ja, können Sie den folgenden Befehl ausführen, um die Details zu AccessControlList überprüfen, um zu überprüfen, ob der AccessControlList SLB-Datenverkehr blockiert wird:

      Get-NetworkControllerAccessControlList –ConnectionUri <REST uri of Network Controller> - ResourceId <Resource ID of the AccessControlList>|ConvertTo-Json –Depth 10

    Sie finden alle diese Informationen auch mithilfe der folgenden Windows Admin Center-Erweiterungen:

    • Logische Netzwerke für logische Netzwerkdetails
    • Virtuelle Netzwerke für Details zu virtuellen Netzwerken
    • Netzwerksicherheitsgruppen für ACL – Details

SLB-Zustandsabbild sammeln

Bei Bedarf können Sie ein SLB-Zustandsabbild erstellen und nach Fehlern suchen. Darüber hinaus können Sie das Statusabbild für erweiterte Problembehandlungszwecke für Microsoft freigeben. Das SLB-Zustandsabbild enthält End-to-End-Informationen zu allen VIPs. Sie können das SkriptDumpSlbRestState.ps1 ausführen, um den SLB-Zustandsauszug zu erfassen. Im folgenden Abschnitt werden die verschiedenen Fehlerszenarien beschrieben, die Sie im Zustandsabbild überprüfen können.

Überprüfen Sie, ob die MuxAdvertisedRoutes leer sind oder ob die betroffenen VIPs fehlen

Nachfolgend sehen Sie ein Beispiel, in dem MuxAdvertisedRoutes leer ist. Dies bedeutet, dass die MUX keine Routen zum ToR werben. In diesem Fall sind alle VIPs ausgefallen.

"name": "MuxRoutes", 
"description": "Mux Routes", 
"dataRetrievalFailed": false, 
"dataUnits": [ 
		{ 
		"value": [ 

"MuxAdvertisedRouteInfo: MuxId=3951dc43-4764-4c65-a4b5-35558c479ce6 MuxDipEndpoint=[172.24.47.12:8560] MuxAdvertisedRoutes=[]", 

"MuxAdvertisedRouteInfo: MuxId=a150f826-6069-4da7-9771-642e80a45c8d MuxDipEndpoint=[172.24.47.13:8560] MuxAdvertisedRoutes=[]"

  • Wenn die Routen leer sind, könnte das Problem entweder MUX-ToR-Peering oder SLBM sein, ohne den richtigen Zielzustand zu pushen.

  • In anderen Fällen fehlen die Routen nur wenige VIPs, was zu einem Verbindungsausfall führt. Wenn dies der Grund ist, besteht das Problem darin, dass SLBM den Zielzustand nicht pusht.

Ausgleich

Verschieben Sie den primären SlbManager-Dienst und ControllerService, und starten Sie die Host-Agents neu.

  • Führen Sie die folgenden Befehle aus, um die Primäre des SlbManager und ControllerService auf einer VM des Netzwerkcontrollers zu verschieben:

    1. Führen Sie den folgenden Befehl aus, um zu ermitteln, welchen Computer die Netzwerkcontroller-Dienstmodule als primär verwenden:

      Get-NetworkControllerReplica

    2. Suchen Sie den MachineName für den SlbManagerService und ControllerService. Wechseln Sie zu den jeweiligen Computern, und führen Sie den folgenden Befehl aus:

      Get-Process Sdnctlr| Stop-Process and Get-Process SdnSlbm | Stop-Process

      Dadurch werden die Prozesse auf einer anderen VM des Netzwerkcontrollers neu gestartet.

  • Um die Host-Agents neu zu starten, führen Sie auf jedem physischen Host den folgenden Befehl aus:

    Restart-Service nchostagent --force
Start-Service slbhostagent

Überprüfen des Programmier- und Verbindungsstatus für VipAddress

Dieser Abschnitt des SLB-Zustandsabbilds enthält detaillierte Informationen zur VIP. Sie stellt den Status der VIP auf SLBM, MUX und Hosts bereit. Unter dem Host werden alle Dips abgeworfen, die derzeit Teil der VIP sind. Stellen Sie sicher, dass die Liste mit der Konfiguration konsistent ist. Wenn das Problem mit ausgehenden Verbindungen besteht, überprüfen Sie die SNAT-Konfigurationen, und stellen Sie sicher, dass die Portzuordnungen zwischen den MUXes und dem Host konsistent sind.

"name": "192.168.102.1", 
"value": [ 
"Programming and Connectivity state for VipAddress: 192.168.102.1",

Sammeln von Datenpfadablaufverfolgungen

Wenn keine der vorherigen Methoden eine Lösung bereitstellt, sammeln Sie Datenpfadprotokolle, und senden Sie sie an Microsoft.

Sammeln Sie die folgenden Protokolle:

Die folgenden Protokolle sollten nur für kurze Zeit gesammelt werden. Starten Sie die Protokollierung, reproduzieren Sie das Szenario, und beenden Sie dann die Protokollierung.

  • MUX-Ablaufverfolgungen. Diese Ablaufverfolgungen müssen auf den MUX-VMs gesammelt werden. Führen Sie die folgenden Schritte aus, um Ablaufverfolgungen zu sammeln:

    1. Führen Sie zum Starten der Protokollierung den folgenden Befehl aus:

      netsh trace start tracefile=c:\mux.etl globallevel=5 provider=`{645b8679-5451-4c36-9857-a90e7dbf97bc`} provider=`{6C2350F8-F827-4B74-AD0C-714A92E22576`} ov=yes report=disabled

    2. Reproduzieren Sie das Szenario.

    3. Führen Sie den folgenden Befehl aus, um die Protokollierung zu beenden:

      netsh trace stop

    4. Führen Sie den folgenden Befehl aus, um die Ablaufverfolgungsdatei im ETL-Format in das angegebene Format zu konvertieren:

      netsh trace convert input=<trace file> ov=yes

  • SLB-Host-Agent-Ablaufverfolgungen. Diese Ablaufverfolgungen müssen auf den physischen Hosts gesammelt werden. Führen Sie die folgenden Schritte aus, um Ablaufverfolgungen zu sammeln:

    1. Führen Sie zum Starten der Protokollierung den folgenden Befehl aus:

      netsh trace start tracefile=c:\slbHA.etl globallevel=5 provider=`{2380c5ee-ab89-4d14-b2e6-142200cb703c`} ov=yes report=disabled

    2. Reproduzieren Sie das Szenario.

    3. Führen Sie den folgenden Befehl aus, um die Protokollierung zu beenden:

      netsh trace stop

    4. Führen Sie den folgenden Befehl aus, um die Ablaufverfolgungsdatei im ETL-Format in das angegebene Format zu konvertieren:

      netsh trace convert input=<trace file> ov=yes

  • VFP-Ablaufverfolgungen. Diese Ablaufverfolgungen müssen auf den physischen Hosts gesammelt werden, auf denen die MUX-VM und die Mandanten-VMs vorhanden sind. Führen Sie die folgenden Schritte aus, um Ablaufverfolgungen zu sammeln:

    1. Führen Sie zum Starten der Protokollierung den folgenden Befehl aus:

      Netsh trace start scenario=virtualization  capture=yes capturetype=both tracefile=vfp.etl ov=yes report=di

    2. Reproduzieren Sie das Szenario.

    3. Führen Sie den folgenden Befehl aus, um die Protokollierung zu beenden:

      netsh trace stop

    4. Führen Sie den folgenden Befehl aus, um die Ablaufverfolgungsdatei im ETL-Format in das angegebene Format zu konvertieren:

      netsh trace convert input=<trace file> ov=yes

Nächste Schritte