Udostępnij za pośrednictwem

Rozwiązywanie problemów z programowym modułem równoważenia obciążenia dla sieci SDN

Dotyczy: Azure Local 2311.2 i nowsze; Windows Server 2022, Windows Server 2019

Jeśli skonfigurowano Programowy Moduł Równoważenia Obciążenia (SLB) dla Sieci Zdefiniowanej Programowo (SDN), a ścieżka danych nie działa za pośrednictwem SLB, może być kilka powodów, dla których tak się dzieje. Ten artykuł ułatwia identyfikowanie i rozwiązywanie typowych problemów z usługą SLB dla sieci SDN.

Aby zapoznać się z omówieniem usługi SLB i sposobem zarządzania nim, zobacz Co to jest programowy moduł równoważenia obciążenia (SLB) dla sieci SDN? i Zarządzanie programowym modułem równoważenia obciążenia dla sieci SDN.

Rozwiązywanie problemów z przepływem pracy

Oto ogólny proces rozwiązywania problemów z SLB:

  • Sprawdzanie stanu konfiguracji maszyn wirtualnych SLB Multiplexer (MUX)
  • Rozwiązywanie typowych błędów stanu konfiguracji
  • Zbieranie zrzutu stanu SLB

Sprawdzanie stanu konfiguracji maszyn wirtualnych SLB Multiplexer

Najpierw należy sprawdzić stan konfiguracji maszyn wirtualnych MUX SLB. W tym celu możesz użyć centrum administracyjnego systemu Windows lub programu PowerShell.

Wykonaj następujące kroki, aby sprawdzić stan konfiguracji SLB MUX za pośrednictwem Centrum administracyjnego systemu Windows:

  1. Na ekranie głównym Centrum administracyjnego systemu Windows w obszarze Wszystkie połączenia wybierz system, z którym chcesz nawiązać połączenie.

  2. W obszarze Narzędzia przewiń w dół do obszaru Sieć . Wybierz pozycję Infrastruktura sieci SDN , a następnie wybierz pozycję Podsumowanie. Jeśli występują problemy z usługą SLB, zobaczysz to w sekcji Load Balancers MUX. Jeśli nie ma żadnych problemów, wszystkie maszyny wirtualne MUX są w dobrej kondycji.

    Zrzut ekranu przedstawiający stronę infrastruktury SDN w centrum administracyjnym systemu Windows, która pokazuje stan MUX modułów równoważenia obciążenia.

Rozwiązywanie typowych błędów stanu konfiguracji

W tej sekcji opisano sposób rozwiązywania typowych błędów, jeśli stan konfiguracji maszyn wirtualnych MUX SLB nie jest w dobrej kondycji.

SLB MUX nie jest połączony z routerem BGP

Ten błąd występuje, gdy maszyny wirtualne MUX nie mogą ustanowić połączenia równorzędnego BGP (Border Gateway Protocol) z przełącznikami ToR (top of rack). Pamiętaj, że MUX łączy się z ToR za pomocą BGP na porcie 179.

Aby rozwiązać problem z błędami połączenia z maszynami wirtualnymi MUX i routerem BGP:

  • Upewnij się, że masz łączność między maszynami wirtualnymi MUX i przełącznikami ToR. Jeśli używasz wirtualizacji sieci, peering powinien odbywać się za pośrednictwem sieci adresu dostawcy wirtualizacji sieci Hyper-V (HNV PA).

  • Sprawdź, czy połączenie zostało nawiązane, uruchamiając następujące polecenie na maszynach wirtualnych MUX:

    Netstat -anp tcp | findstr 179

    Jeśli nie ma połączenia między MUX i ToR, sprawdź, czy ToR jest osiągalne z MUX za pomocą Test-NetConnection. Jeśli MUX nie może nawiązać połączenia z ToR, występuje problem z instrumentalną siecią lub ToR.

    Test-NetConnection -ComputerName <ToR_IP> -Port 179

    gdzie:

    • ToR_IP jest częścią zasobu loadBalancerMuxes.

    Poniżej przedstawiono fragment zasobu LoadBalancerMux z adresem IP ToR jako 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" 
        }

  • Jeśli skonfigurowano wiele przełączników, upewnij się, że wszystkie z nich są sparowane z maszynami wirtualnymi MUX.

  • Aby uzyskać dalszą diagnostykę związaną z nieudanym peeringiem BGP, uruchom skrypt Test-SDNExpressBGP na dowolnym z hostów fizycznych:

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

    gdzie:

    • RouterIPAddress to adres IP Tor
    • LocalIPAddress to adres IP PA z maszyny wirtualnej SLBMUX
    • LocalASN to SDN SLB ASN
    • ComputerName to nazwa maszyny wirtualnej SLBMUX

    Skrypt zatrzymuje usługę SLBMUX na maszynie wirtualnej MUX, stara się nawiązać połączenie, które może zakończyć się niepowodzeniem lub pomyślnie, i podaje więcej szczegółów w przypadku wystąpienia awarii.

Serwer wirtualny jest niemożliwy do osiągnięcia

Ten błąd można uzyskać z powodu błędów sieci lub odrzucenia uwierzytelniania na serwerze wirtualnym. Zwykle oznacza to, że kontroler sieci nie może nawiązać połączenia z maszynami wirtualnymi MUX SLB.

Aby rozwiązać problemy z tym, dlaczego serwer wirtualny nie jest osiągalny, sprawdź, czy:

  • Istnieje łączność między kontrolerem sieci a maszynami wirtualnymi MUX. Aby sprawdzić łączność, uruchom następujące polecenie:

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

  • Usługa MUX jest uruchomiona na maszynach wirtualnych MUX. Aby to sprawdzić, uruchom następujące polecenie z sesji programu PowerShell na maszynach wirtualnych MUX. Status musi być 'Uruchomiony.'

    Get-Service slbmux

  • Nie ma problemów z zaporą. Upewnij się, że port 8560 nie jest blokowany przez zaporę na maszynie wirtualnej MUX. Test-NetConnection Jeśli polecenie powiedzie się, oznacza to, że nie ma problemu z zaporą.

Certyfikat nie jest zaufany lub certyfikat nie jest autoryzowany

Ten błąd może wystąpić, jeśli certyfikat przedstawiony przez SLB MUX kontrolerowi sieci napotkał pewne problemy.

  1. Aby zidentyfikować certyfikat, uruchom następujące polecenie na maszynach wirtualnych MUX:

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

    gdzie:

    • NodeFQDN to nazwa FQDN maszyny wirtualnej MUX.

  2. Po zidentyfikowaniu certyfikatu sprawdź certyfikat:

    1. Aby przetestować certyfikat, uruchom następujące polecenie:

      Test-Certificate $cert

    2. Upewnij się, że certyfikat jest zaufany przez maszyny wirtualne kontrolera sieci. Jeśli certyfikat jest certyfikatem z podpisem własnym, ten sam certyfikat musi znajdować się w magazynie głównym wszystkich maszyn wirtualnych kontrolera sieci. Jeśli certyfikat jest podpisany przez urząd certyfikacji, certyfikat urzędu certyfikacji musi znajdować się w magazynie głównym wszystkich maszyn wirtualnych kontrolera sieci. Aby wyświetlić listę wszystkich certyfikatów w magazynie głównym maszyn wirtualnych kontrolera sieci, uruchom następujące polecenie na wszystkich maszynach wirtualnych kontrolera sieci:

      get-childitem "cert:\localmachine\root"

Niepowodzenie konfiguracji zasad

Ten błąd może pojawić się jako jeden z następujących: PolicyConfigurationFailureonHost, PolicyConfigurationFailureonMux, PolicyConfigurationFailureonVfp lub PolicyConfigurationFailure.

Ten błąd występuje, gdy kontroler sieci nie może przesyłać polityk do maszyn wirtualnych MUX SLB lub hostów Hyper-V z powodu problemów z dostępnością, certyfikatem lub z powodu innych problemów.

Aby rozwiązać problem błędu konfiguracji zasad, najpierw sprawdź, czy nie występują problemy z dostępnością i certyfikatami. Zobacz kroki opisane w poprzednich sekcjach: SLB MUX nie jest połączony z routerem BGP, serwer wirtualny jest niemożliwy do osiągnięcia, a certyfikat nie jest zaufany lub certyfikat nie jest autoryzowany.

Jeśli nie ma żadnego problemu z dostępnością i certyfikatem, wykonaj następujące kroki, aby sprawdzić łączność między kontrolerem sieci a maszynami wirtualnymi SLB MUX i agentem hosta SLB na hoście:

  1. Sprawdź połączenie między kontrolerem sieci i maszynami wirtualnymi SLB MUX. Należy pamiętać, że kontroler sieci (usługa SlbManager) łączy się z MUX na porcie 8560. Kontroler sieci inicjuje połączenie. Różne konfiguracje publicznych adresów IP (VIP), porty translacji adresów sieciowych (SNAT) itp. są przesyłane przez to połączenie.

    Aby sprawdzić połączenie między kontrolerem sieci i SLB MUX, uruchom polecenie netstat na maszynach wirtualnych SLB MUX.

    Przykładowe dane wyjściowe użycia polecenia wyglądają tak:

    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. Sprawdź połączenie między kontrolerem sieci a agentem hosta SLB. Należy pamiętać, że agent hosta SLB łączy się z kontrolerem sieci (usługą SlbManager) na porcie 8571. Różne zasady SLB są przesyłane za pośrednictwem tego połączenia.

    Aby sprawdzić łączność między kontrolerem sieci i agentem hosta SLB, uruchom polecenie netstat na hoście fizycznym.

    Przykładowe dane wyjściowe użycia polecenia wyglądają tak:

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

Problemy z łącznością ścieżki danych

Problemy z łącznością ścieżki danych mogą wystąpić nawet wtedy, gdy maszyny wirtualne MUX SLB są w dobrej kondycji. Oznacza to, że ruch SLB spada gdzieś po drodze. Aby określić, gdzie ruch jest tracony, należy zebrać ścieżki danych. Przed wykonaniem tej czynności upewnij się, że:

  • Przełącznik ToR może zobaczyć reklamowane VIP-y. Po skonfigurowaniu modułu równoważenia obciążenia dla potrzeb równoważenia obciążenia, NAT dla ruchu przychodzącego, NAT dla ruchu wychodzącego lub kombinacji tych, VIP modułu równoważenia obciążenia jest reklamowany do ToR. Za pomocą CLI przełącznika sprawdź, czy adres VIP jest reklamowany.

  • Adres VIP SLBM nie może być zablokowany w sieci Tor ani w jakiekolwiek fizyczne zapory. Jest to adres IP określony jako loadBalancerManagerIPAddress w zasobie LoadBalancerManager/config kontrolera sieci. Gdy pakiet przychodzący dociera i VM MUX określa prawidłowy adres IP backendu do wysłania pakietu, wysyła pakiet z adresem IP źródłowym jako adres VIP SLBM MUX. Mogą istnieć scenariusze, w których może być to pominięte w ToR.

  • Sondy diagnostyczne SLB są w górę. Jeśli skonfigurowano sondy kondycji SLB, upewnij się, że co najmniej jedna z maszyn wirtualnych zaplecza jest aktywna i może reagować na sondę kondycji. Stan sond możesz również uzyskać za pośrednictwem zrzutu stanu SLB, jak opisano w dalszej części tego artykułu.

  • Zapora wewnątrz maszyny wirtualnej w części zaplecza nie blokuje ruchu. Upewnij się, że zapora hosta w maszynach wirtualnych zaplecza nie blokuje przychodzącego ruchu sieciowego SLB.

  • Sieciowe grupy zabezpieczeń SDN nie blokują ruchu. Niektóre grupy zabezpieczeń sieci mogą być skonfigurowane bezpośrednio na tylnym interfejsie sieciowym lub na podsieci. Upewnij się, że grupa zabezpieczeń sieci nie blokuje przychodzącego ruchu SLB.

    1. Aby sprawdzić sieciowe grupy zabezpieczeń za pomocą programu PowerShell, uruchom następujące polecenia na maszynie, co może wydawać polecenia REST do kontrolera sieci:

      • Aby uzyskać szczegółowe informacje o zasobie NetworkInterface, uruchom następujące polecenie:

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

      • Aby uzyskać szczegółowe informacje o zasobie VirtualNetworkSubnet, uruchom następujące polecenie:

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

      • Aby uzyskać szczegółowe informacje o zasobie LogicalNetworkSubnet, uruchom następujące polecenie:

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

    2. Dane wyjściowe z poprzednich poleceń zawierają sekcję dla elementu AccessControlList. Możesz sprawdzić, czy do tych zasobów jest dołączone jakiekolwiek AccessControlList. Jeśli tak, możesz uruchomić następujące polecenie, aby zweryfikować szczegóły AccessControlList i sprawdzić, czy AccessControlList blokuje jakikolwiek ruch SLB:

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

    Wszystkie te informacje można również znaleźć przy użyciu następujących rozszerzeń programu Windows Admin Center:

    • Sieci logiczne - szczegóły dotyczące sieci logicznej
    • Sieci wirtualne dla szczegółów sieci wirtualnych
    • Grupy zabezpieczeń sieciowych dla szczegółów ACL

Zbieranie zrzutu stanu SLB

W razie potrzeby możesz utworzyć zrzut stanu SLB i sprawdzić, czy występują błędy. Ponadto możesz udostępnić zrzut stanu firmie Microsoft do celów zaawansowanych rozwiązywania problemów. Zrzut stanu SLB zapewnia kompleksowe informacje o wszystkich VIP-ach. Możesz uruchomić skrypt DumpSlbRestState.ps1, aby zebrać zrzut stanu SLB. W poniższej sekcji opisano różne scenariusze występowania błędów, które można sprawdzić w zrzucie stanu.

Sprawdź, czy MuxAdvertisedRoutes jest pusty lub brak w nim adresów VIP, których dotyczy problem.

Oto przykład, w którym MuxAdvertisedRoutes jest pusty. Oznacza to, że MUX nie reklamuje żadnych tras do ToR. W takim przypadku wszyscy VIP-y są niedostępni.

"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=[]"

  • Jeśli trasy są puste, problem może dotyczyć peeringu MUX-ToR lub SLBM nie przekazuje prawidłowego statusu docelowego.

  • W innych przypadkach brakuje tylko kilku tras VIP, co powoduje awarię łączności tylko u nich. Jeśli tak, problem dotyczy modułu SLBM, który nie realizuje stanu docelowego.

Łagodzenie

Przenieś główną usługę SlbManager i usługę ControllerService oraz uruchom ponownie agentów hosta.

  • Aby przenieść rolę nadrzędną SlbManager i ControllerService, na VM Kontrolera Sieci uruchom następujące polecenia:

    1. Aby określić, która maszyna modułów usługi kontrolera sieci jest używana jako podstawowa, uruchom następujące polecenie:

      Get-NetworkControllerReplica

    2. Znajdź wartość MachineName dla usług SlbManagerService i ControllerService. Przejdź do odpowiednich maszyn i uruchom następujące polecenie:

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

      Spowoduje to ponowne uruchomienie procesów na innej maszynie wirtualnej kontrolera sieci.

  • Aby ponownie uruchomić agentów hosta, na każdym hoście fizycznym uruchom następujące polecenie:

    Restart-Service nchostagent --force
Start-Service slbhostagent

Sprawdź stan programowania i łączności dla VipAddress

Ta sekcja zrzutu stanu SLB dostarcza szczegółowych informacji dotyczących VIP. Zapewnia stan VIP na SLBM, MUX i hostach. Pod hostem zrzuca wszystkie zrzuty, które są obecnie częścią VIP. Upewnij się, że lista jest zgodna z konfiguracją. Jeśli problem dotyczy połączeń wychodzących, sprawdź konfiguracje SNAT i upewnij się, że alokacje portów między interfejsami MUXes i hostem są spójne.

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

Zbieranie tras danych

Jeśli żadna z poprzednich metod nie zapewnia rozwiązania, zbierz dzienniki ścieżki danych i wyślij je do firmy Microsoft.

Zbierz następujące dzienniki:

Poniższe dzienniki powinny być zbierane tylko przez krótki czas. Uruchom rejestrowanie, odtwórz scenariusz, a następnie zatrzymaj rejestrowanie.

  • Ślady MUX. Te ślady muszą być zbierane na maszynach wirtualnych MUX. Wykonaj następujące kroki, aby zebrać ślady:

    1. Aby rozpocząć rejestrowanie, uruchom następujące polecenie:

      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. Odtwórz scenariusz.

    3. Aby zatrzymać rejestrowanie, uruchom następujące polecenie:

      netsh trace stop

    4. Aby przekonwertować plik śledzenia w formacie ETL na określony format, uruchom następujące polecenie:

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

  • Ślady agenta obsługi hosta SLB. Te ślady muszą być zbierane na hostach fizycznych. Wykonaj następujące kroki, aby zebrać ślady:

    1. Aby rozpocząć rejestrowanie, uruchom następujące polecenie:

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

    2. Odtwórz scenariusz.

    3. Aby zatrzymać rejestrowanie, uruchom następujące polecenie:

      netsh trace stop

    4. Aby przekonwertować plik śledzenia w formacie ETL na określony format, uruchom następujące polecenie:

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

  • Ślady VFP. Te ślady muszą być zbierane na hostach fizycznych, na których znajdują się maszyny wirtualne MUX i maszyny wirtualne dzierżawcy. Wykonaj następujące kroki, aby zebrać ślady:

    1. Aby rozpocząć rejestrowanie, uruchom następujące polecenie:

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

    2. Odtwórz scenariusz.

    3. Aby zatrzymać rejestrowanie, uruchom następujące polecenie:

      netsh trace stop

    4. Aby przekonwertować plik śledzenia w formacie ETL na określony format, uruchom następujące polecenie:

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

Następne kroki