Udostępnij za pośrednictwem

Rozwiązywanie problemów ze stosem sieci zdefiniowanym programowo w systemie Windows Server

  • Artykuł

W tym przewodniku opisano typowe błędy i scenariusze błędów sieci zdefiniowanej programowo (SDN) oraz przedstawiono przepływ pracy rozwiązywania problemów, który korzysta z dostępnych narzędzi diagnostycznych. Aby uzyskać więcej informacji na temat sieci SDN, zobacz Sieć zdefiniowana programowo.

Dotyczy: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, wersje 21H2 i 20H2

Typy błędów

Poniższa lista reprezentuje klasę problemów najczęściej występuje w przypadku wirtualizacji sieci funkcji Hyper-V (HNVv1) w systemie Windows Server 2012 R2 z wdrożeń produkcyjnych w rynku i pokrywa się na wiele sposobów, za pomocą tego samego typu problemy w Windows Server 2016 HNVv2 z nowy stos oprogramowania programowalnej sieci komputerowej (SDN).

Większość błędów można podzielić na niewielki zestaw klas:

  • Nieprawidłowa lub Nieobsługiwana konfiguracja

    Użytkownik wywołuje interfejs API typu NorthBound nieprawidłowo lub nieprawidłowe zasady.

  • Wystąpił błąd podczas stosowania zasady

    Zasady z kontrolera sieci nie zostały dostarczone do hosta funkcji Hyper-V, opóźnione lub nieaktualne na wszystkich hostach funkcji Hyper-V (na przykład po migracji na żywo).

  • Konfiguracja oprogramowania lub kilka usterek

    Ścieżka danych problemy powodujące porzuconych pakietów.

  • Błąd zewnętrzny związane z karty Sieciowej sprzętu / sterowników lub underlay sieci szkieletowej

    Błędna Odciążanie zadań (na przykład VMQ) lub underlay sieci szkieletowej nieprawidłowo skonfigurowana (takich jak rozmiar jednostki MTU)

    Ten przewodnik rozwiązywania problemów sprawdza, czy w każdej z tych kategorii błędów i zaleca najlepsze rozwiązania i narzędzia diagnostyczne, które są dostępne zidentyfikować i naprawić błąd.

Narzędzia diagnostyczne

Przed omówieniem przepływów pracy rozwiązywania problemów dla każdego z tych typów błędów przyjrzyjmy się dostępnym narzędziom diagnostycznym.

Aby użyć narzędzi diagnostycznych kontrolera sieci (ścieżki sterowania), należy najpierw zainstalować RSAT-NetworkController tę funkcję i zaimportować NetworkControllerDiagnostics moduł:

Add-WindowsFeature RSAT-NetworkController -IncludeManagementTools
Import-Module NetworkControllerDiagnostics

Aby użyć narzędzia diagnostyczne HNV diagnostyki (ścieżka danych), należy zaimportować HNVDiagnostics modułu:

# Assumes RSAT-NetworkController feature has already been installed
Import-Module hnvdiagnostics

Diagnostyka Kontroler sieci

Te polecenia cmdlet są udokumentowane w witrynie TechNet w poleceniu cmdlet Diagnostyka kontrolera sieci. Pomagają zidentyfikować problemy z spójności zasad sieciowych w ścieżce formantu węzły Kontroler sieci oraz między Kontroler sieci i hosta NC agentów na hostach funkcji Hyper-V.

Polecenia Debug-ServiceFabricNodeStatus cmdlet i Get-NetworkControllerReplica muszą być uruchamiane z jednej z maszyn wirtualnych kontrolera sieci. Wszystkie inne polecenia cmdlet diagnostyki kontrolera sieci można uruchomić z dowolnego hosta, który ma łączność z kontrolerem sieci i znajduje się w grupie zabezpieczeń Zarządzania kontrolerem sieci (Kerberos) lub ma dostęp do certyfikatu X.509 do zarządzania kontrolerem sieci.

Diagnostyka hosta funkcji Hyper-V

Te polecenia cmdlet są udokumentowane w witrynie TechNet w poleceniu cmdlet diagnostyki wirtualizacji sieci funkcji Hyper-V (HNV). Pomagają zidentyfikować problemy w ścieżce danych między maszynami wirtualnymi dzierżawy (Wschód/Zachód) i wchodzącego ruch przez SLB VIP (północ/południe).

Wszystkie Debug-VirtualMachineQueueOperationtesty lokalne , Get-CustomerRoute, Get-VMNetworkAdapterPortIdGet-VMSwitchExternalPortIdGet-PACAMappingGet-ProviderAddressi Test-EncapOverheadSettings mogą być uruchamiane z dowolnego hosta funkcji Hyper-V. Inne polecenia cmdlet wywołują testy ścieżki danych za pośrednictwem kontrolera sieci i dlatego wymagają dostępu do kontrolera sieci zgodnie z powyższym opisem.

GitHub

Repozytorium GitHub firmy Microsoft/SDN zawiera wiele przykładowych skryptów i przepływów pracy, które są oparte na tych wbudowanych poleceniach cmdlet. W szczególności skrypty diagnostycznych znajdują się w diagnostyki folder. Pomóż nam współtworzyć te skrypty, przesyłając żądania ściągnięcia.

Rozwiązywanie problemów z przepływami pracy i przewodnikami

[Hoster] Weryfikowanie kondycji systemu

Jest osadzony zasób o nazwie Stan konfiguracji w kilku zasobów kontrolera sieci. Stan konfiguracji zawiera informacje o kondycji systemu w tym spójności między konfiguracji kontrolera sieci i rzeczywisty stan (działających) na hostach funkcji Hyper-V.

Aby sprawdzić stan konfiguracji, uruchom następujące polecenie dowolnego hosta funkcji Hyper-V z połączeniem z kontrolerem sieci.

Uwaga

Wartość parametru NetworkController powinna być nazwą FQDN lub adresem IP na podstawie nazwy podmiotu certyfikatu X.509 >utworzonego dla kontrolera sieci.

Parametr Credential musi być określony tylko wtedy, gdy kontroler sieci korzysta z uwierzytelniania Kerberos (typowe w przypadku wdrożeń programu VMM). Poświadczenia muszą być dla użytkownika, który znajduje się w grupie zabezpieczeń sieci kontrolera zarządzania.

Debug-NetworkControllerConfigurationState -NetworkController <FQDN or NC IP> [-Credential <PS Credential>]

# Healthy State Example - no status reported
$cred = Get-Credential
Debug-NetworkControllerConfigurationState -NetworkController 10.127.132.211 -Credential $cred

Fetching ResourceType:     accessControlLists
Fetching ResourceType:     servers
Fetching ResourceType:     virtualNetworks
Fetching ResourceType:     networkInterfaces
Fetching ResourceType:     virtualGateways
Fetching ResourceType:     loadbalancerMuxes
Fetching ResourceType:     Gateways

Poniżej przedstawiono przykładowy komunikat o stanie konfiguracji:

Fetching ResourceType:     servers
---------------------------------------------------------------------------------------------------------
ResourcePath:     https://10.127.132.211/Networking/v1/servers/4c4c4544-0056-4b10-8058-b8c04f395931
Status:           Warning

Source:           SoftwareLoadBalancerManager
Code:             HostNotConnectedToController
Message:          Host is not Connected.
----------------------------------------------------------------------------------------------------------

Uwaga

Istnieje błąd w systemie, w którym zasoby interfejsu sieciowego dla karty Sieciowej SLB Mux przesyłania maszyny Wirtualnej są w stanie awarii z powodu błędu "Wirtualny przełącznik – nie podłączony do kontrolera hosta". Ten błąd można bezpiecznie zignorować, jeśli konfiguracji IP w zasobach maszyny Wirtualnej karty Sieciowej jest ustawione na adres IP z puli adresów IP sieci logicznej przesyłania.

Jest to błąd drugi w systemie, w którym zasoby interfejsu sieciowego dla karty interfejsu sieciowego bramy HNV dostawcy maszyny Wirtualnej są w stanie awarii z powodu błędu "Wirtualny przełącznik – PortBlocked". Ten błąd może również można bezpiecznie zignorować Jeśli konfiguracji IP w zasobach maszyny Wirtualnej karty Sieciowej jest ustawiony na wartość null (według projektu).

Poniższa tabela zawiera listę kodów błędów, wiadomości i akcje monitowania do podjęcia oparte na stanie konfiguracji przestrzegane.

Kod Komunikat Akcja
Nieznane Nieznany błąd
HostUnreachable Komputer hosta jest nieosiągalny Sprawdź łączność sieciową zarządzania między Kontroler sieci i hosta
PAIpAddressExhausted Wyczerpano adresy IP pa Zwiększ rozmiar puli IP podsieci logiczne HNV dostawcy
PAMacAddressExhausted Adresy PA Mac wyczerpana Zwiększ zakres puli Mac
PAAddressConfigurationFailure Nie można zainstalować adresy dostawcy do hosta Sprawdź łączność sieciową zarządzania między Kontroler sieci i hosta.
CertificateNotTrusted Certyfikat nie jest zaufany Usuń certyfikaty używane do komunikacji z hostem.
CertificateNotAuthorized Certyfikat nie jest autoryzowane Usuń certyfikaty używane do komunikacji z hostem.
PolicyConfigurationFailureOnVfp Błąd podczas konfigurowania zasad Visual FOXPRO Jest to błąd czasu wykonywania. Nie ma określonych obejść. Zbieranie dzienników.
PolicyConfigurationFailure Niepowodzenie w wypychanie zasady dla hostów z powodu błędów komunikacji lub innym osobom błąd w NetworkController. Nie pewne akcje. Jest to spowodowane awarii w stanie celem przetwarzania modułów kontrolera sieci. Zbieranie dzienników.
HostNotConnectedToController Host nie jest jeszcze połączony z kontrolerem sieci Profil portu nie są stosowane na hoście lub host jest nieosiągalny z kontrolera sieci. Sprawdzić, czy klucz rejestru Identyfikator_hosta zgodny z Identyfikatorem wystąpienia zasobu serwera
MultipleVfpEnabledSwitches Istnieje wiele Visual FoxPro włączone przełączników na hoście Usuń jeden z przełączników, ponieważ Agent hosta Kontroler sieci obsługuje tylko jednego przełącznika wirtualnego po włączeniu rozszerzenia Visual FOXPRO
PolicyConfigurationFailure Nie powiodło się push zasad sieci wirtualnej dla karty VmNic z powodu błędów certyfikatu lub błędy połączenia Sprawdź, czy odpowiednie certyfikaty zostały wdrożone (nazwa podmiotu certyfikatu musi odpowiadać nazwie FQDN hosta). Należy także sprawdzić łączność hosta z kontrolera sieci
PolicyConfigurationFailure Nie powiodło się push zasady przełącznika wirtualnego dla karty VmNic z powodu błędów certyfikatu lub błędy połączenia Sprawdź, czy odpowiednie certyfikaty zostały wdrożone (nazwa podmiotu certyfikatu musi odpowiadać nazwie FQDN hosta). Należy także sprawdzić łączność hosta z kontrolera sieci
PolicyConfigurationFailure Nie powiodło się push zasady zapory dla karty VmNic z powodu błędów certyfikatu lub błędy połączenia Sprawdź, czy odpowiednie certyfikaty zostały wdrożone (nazwa podmiotu certyfikatu musi odpowiadać nazwie FQDN hosta). Należy także sprawdzić łączność hosta z kontrolera sieci
DistributedRouterConfigurationFailure Nie można skonfigurować ustawień routera rozproszone na wirtualnej karty sieciowej hosta Błąd stosu protokołu TCP/IP. Może wymagać czyszczenia vNICs PA i DR hosta na serwerze, na którym został zgłoszony błąd
DhcpAddressAllocationFailure Alokacja adresów DHCP nie powiodło się dla karty VMNic Sprawdź, jeśli atrybut statyczny adres IP jest skonfigurowany w zasobie karta Sieciowa
CertificateNotTrusted
CertificateNotAuthorized		 Nie można nawiązać połączenia z Mux z powodu błędów sieci lub certyfikatu Sprawdź kod liczbowy podany w kodzie komunikat błędu: odpowiada to kod błędu usługi winsock. Błędy certyfikatów są szczegółowe (na przykład, nie można zweryfikować certyfikatu, certyfikat nie jest autoryzowany itp.)
HostUnreachable MUX jest zła (często zdarza się BGPRouter odłączony) Elementu równorzędnego protokołu BGP na usługi RRAS (BGP maszyny wirtualnej) lub przełączników Top of Rack (ToR) jest niedostępny lub nie zaglądanie pomyślnie. Sprawdź ustawienia protokołu BGP na multiplekser usługi równoważenia obciążenia oprogramowania zasobów i elementu równorzędnego protokołu BGP (ToR lub RRAS maszyny wirtualnej)
HostNotConnectedToController Agent SLB hosta nie jest podłączony. Sprawdź, czy jest uruchomiona usługa agenta hosta SLB; Odwoływać się do dzienników agenta hosta SLB (automatyczne uruchamianie) powodów dlaczego, w przypadku, gdy SLBM (NC) odrzucił certyfikat przedstawiony przez tego agenta hosta stanu są wyświetlane informacje nuanced
PortBlocked Port Visual FOXPRO jest zablokowana z powodu braku sieci Wirtualnej / ACL zasad Sprawdź, czy istnieją inne błędy, które mogłyby powodować zasady nie można skonfigurować.
Przeciążone MUX usługi równoważenia obciążenia jest przeciążona. Problem z wydajnością z MUX
RoutePublicationFailure MUX usługi równoważenia obciążenia nie jest połączony z router protokołu BGP Sprawdź, czy MUX jest połączony z routerami BGP i że zaglądanie BGP jest prawidłowo skonfigurowany
VirtualServerUnreachable MUX usługi równoważenia obciążenia nie jest podłączony do Menedżera SLB Sprawdź łączność między SLBM i MUX
QosConfigurationFailure Nie można skonfigurować zasad QOS Czy wystarczającą przepustowość jest dostępna dla wszystkich maszyn Wirtualnych, jeśli rezerwacji QOS jest używany

Sprawdź połączenie sieciowe między Kontroler sieci i Host funkcji Hyper-V (usługi agenta hosta NC)

netstat Uruchom poniższe polecenie, aby sprawdzić, czy istnieją trzy ESTABLISHED połączenia między agentem hosta NC i węzłami kontrolera sieci i jednym LISTENING gniazdem na hoście funkcji Hyper-V.

  • NASŁUCHIWANIE TCP:6640 portu na hoście funkcji Hyper-V (usługi agenta hosta NC)
  • Dwa ustanowione połączenia z adresu IP hosta funkcji Hyper-V na porcie 6640 do adresu IP węzła NC na portach efemerycznych (> 32000)
  • Jeden nawiązano połączenie z adresu IP hosta funkcji Hyper-V na portów tymczasowych z IP REST Kontroler sieci na porcie 6640

Uwaga

Może istnieć tylko dwa połączenia ustanowionym na hoście funkcji Hyper-V, jeśli nie ma żadnych maszyn wirtualnych dzierżawcy wdrożone na tym określonym hoście.

netstat -anp tcp |findstr 6640

# Successful output
  TCP    0.0.0.0:6640           0.0.0.0:0              LISTENING
  TCP    10.127.132.153:6640    10.127.132.213:50095   ESTABLISHED
  TCP    10.127.132.153:6640    10.127.132.214:62514   ESTABLISHED
  TCP    10.127.132.153:50023   10.127.132.211:6640    ESTABLISHED

Sprawdzanie usług agenta hosta

Kontroler sieci komunikuje się z dwóch usług agenta hosta na hostach funkcji Hyper-V: SLB hosta agenta i NC Host agenta. Możliwe, że jedna lub obie te usługi nie są uruchomione. Sprawdź ich stan i uruchom ponownie, jeśli nie jest uruchomiony.

Get-Service SlbHostAgent
Get-Service NcHostAgent

# (Re)start requires -Force flag
Start-Service NcHostAgent -Force
Start-Service SlbHostAgent -Force

Sprawdź kondycję Kontroler sieci

Jeśli nie ma trzech ESTABLISHED połączeń lub kontroler sieci wydaje się nie odpowiadać, sprawdź, czy wszystkie węzły i moduły usługi są uruchomione przy użyciu następujących poleceń cmdlet.

# Prints a DIFF state (status is automatically updated if state is changed) of a particular service module replica
Debug-ServiceFabricNodeStatus [-ServiceTypeName] <Service Module>

Moduły usługi kontrolera sieci są:

  • ControllerService
  • ApiService
  • SlbManagerService
  • ServiceInsertion
  • FirewallService
  • VSwitchService
  • GatewayManager
  • FnmService
  • HelperService
  • UpdateService

Sprawdź, czy ReplicaStatus to jest Ready i HealthState ma wartość Ok.

W środowisku produkcyjnym wdrożenia jest z wieloma węzłami kontrolera sieci, również można sprawdzić, który węzeł jest podstawowy na każdej usługi i jego stan poszczególnych repliki.

Get-NetworkControllerReplica

# Sample Output for the API service module
Replicas for service: ApiService

ReplicaRole   : Primary
NodeName      : SA18N30NC3.sa18.nttest.microsoft.com
ReplicaStatus : Ready

Sprawdź, czy stan repliki jest gotowe dla każdej usługi.

Sprawdź odpowiednie identyfikatory hostów i certyfikaty między kontrolerem sieci a każdym hostem funkcji Hyper-V

Na hoście funkcji Hyper-V uruchom następujące polecenia cmdlet, aby sprawdzić, czy identyfikator hosta odpowiada identyfikatorowi wystąpienia zasobu serwera na kontrolerze sieci

Get-ItemProperty "hklm:\system\currentcontrolset\services\nchostagent\parameters" -Name HostId |fl HostId

HostId : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**

Get-NetworkControllerServer -ConnectionUri $uri |where { $_.InstanceId -eq "162cd2c8-08d4-4298-8cb4-10c2977e3cfe"}

Tags             :
ResourceRef      : /servers/4c4c4544-0056-4a10-8059-b8c04f395931
InstanceId       : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**
Etag             : W/"50f89b08-215c-495d-8505-0776baab9cb3"
ResourceMetadata : Microsoft.Windows.NetworkController.ResourceMetadata
ResourceId       : 4c4c4544-0056-4a10-8059-b8c04f395931
Properties       : Microsoft.Windows.NetworkController.ServerProperties

Korygowanie

W przypadku używania skryptów SDNExpress lub ręcznego wdrażania zaktualizuj klucz HostId w rejestrze, aby był zgodny z identyfikatorem wystąpienia zasobu serwera. Uruchom ponownie agenta hosta Kontroler sieci na hoście funkcji Hyper-V (serwera fizycznego), jeśli za pomocą programu VMM, Usuń serwer funkcji Hyper-V z programu VMM i Usuń klucz rejestru Identyfikator_hosta. Następnie ponownie dodaj serwer za pośrednictwem programu VMM.

Sprawdź, czy odciski palca certyfikatów X.509 używany przez hosta funkcji Hyper-V (nazwa hosta będzie nazwa podmiotu certyfikatu) do komunikacji (SouthBound) między hostem funkcji Hyper-V (usługi agenta hosta NC) i węzły Kontroler sieci są takie same. Sprawdź również, czy certyfikat REST kontrolera sieci ma nazwę podmiotu CN=<FQDN or IP>.

# On Hyper-V Host
dir cert:\\localmachine\my

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
...

dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**

# On Network Controller Node VM
dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**
...

Możesz również sprawdzić następujące parametry każdego certyfikatu, aby upewnić się, że nazwa podmiotu jest zgodna z oczekiwaniami (nazwa hosta lub nazwa hosta REST FQDN lub adres IP), certyfikat nie wygasł i że wszystkie urzędy certyfikacji w łańcuchu certyfikatów są uwzględnione w zaufanym urzędzie głównym.

  • Nazwa podmiotu
  • Data wygaśnięcia
  • Zaufany główny urząd certyfikacji

Jeśli wiele certyfikatów ma taką samą nazwę podmiotu na hoście funkcji Hyper-V, agent hosta kontrolera sieci losowo wybierze jeden do przedstawienia kontrolerowi sieci. Może to nie być zgodne z odciskiem palca zasobu serwera znanym kontrolerowi sieci. W takim przypadku usuń jeden z certyfikatów o tej samej nazwie podmiotu na hoście funkcji Hyper-V, a następnie uruchom ponownie usługę agenta hosta kontrolera sieci. Jeśli nadal nie można nawiązać połączenia, usuń inny certyfikat o tej samej nazwie podmiotu na hoście funkcji Hyper-V i usuń odpowiedni zasób serwera w programie VMM. Następnie ponownie utwórz zasób serwera w programie VMM, który wygeneruje nowy certyfikat X.509 i zainstaluj go na hoście funkcji Hyper-V.

Sprawdzanie stanu konfiguracji usługi SLB

Stan konfiguracji SLB można określić jako część danych wyjściowych polecenia Debug-NetworkController cmdlet. To polecenie cmdlet również danych wyjściowych dla bieżącego zestawu zasobów Kontroler sieci w programie plików JSON, wszystkich konfiguracji adresu IP z każdym hoście funkcji Hyper-V (server) i zasad sieci lokalnej w tabelach bazy danych hosta agenta.

Więcej śladów zostanie zebranych domyślnie. Aby nie zbierać śladów, dodaj -IncludeTraces:$false parametr .

Debug-NetworkController -NetworkController <FQDN or IP> [-Credential <PS Credential>] [-IncludeTraces:$false]

# Don't collect traces
$cred = Get-Credential
Debug-NetworkController -NetworkController 10.127.132.211 -Credential $cred -IncludeTraces:$false

Transcript started, output file is C:\NCDiagnostics.log
Collecting Diagnostics data from NC Nodes

Uwaga

Domyślną lokalizacją wyjściową <będzie katalog working_directory>\NCDiagnostics\. Katalog wyjściowy domyślne można zmienić za pomocą -OutputDirectory parametru.

Informacje o stanie konfiguracji SLB znajduje się w slbstateResults.Json diagnostyki ten plik.

Ten plik JSON można podzielić na następujące sekcje:

  • Tkanina
    • SlbmVips — w tej sekcji wymieniono adres IP adresu VIP menedżera SLB, który jest używany przez kontroler sieci do koordynowania konfiguracji i kondycji między muksami SLB i agentami hosta SLB.
    • MuxState - tej sekcji znajduje się lista jedną wartość dla każdego SLB Mux wdrożone w ten sposób nadać stan mux
    • Konfiguracja routera — w tej sekcji spowoduje wyświetlenie listy nadrzędnego routera (element równorzędny BGP) numer systemu autonomicznego (ASN), adres IP przesyłania i identyfikator. Poda także SLB Muxes ASN i przesyłania IP.
    • Połączone informacje o hoście — w tej sekcji listy IP zarządzania dotyczą wszystkich hostów funkcji Hyper-V, dostępna do uruchamiania obciążeń równoważeniem obciążenia.
    • Zakresy adresów VIP — w tej sekcji znajduje się lista publicznych i prywatnych zakresu puli adresów IP adresu VIP. SLBM VIP zostaną dołączone jako przydzielony adres IP z jednego z tych zakresów.
    • Trasy Mux — w tej sekcji znajduje się lista jedną wartość dla każdego SLB Mux wdrożone zawierający wszystkie anonsy tras dla tej konkretnej mux.
  • Dzierżawca
    • VipConsolidatedState — w tej sekcji zostanie wyświetlona lista stanu łączności dla każdego adresu VIP dzierżawy, w tym anonsowany prefiks trasy, host funkcji Hyper-V i punkty końcowe DIP.

Uwaga

Stan SLB można ustalić bezpośrednio za pomocą DumpSlbRestState skryptu na repozytorium Microsoft SDN GitHub.

Walidacja bramy

Z poziomu kontrolera sieci:

Get-NetworkControllerLogicalNetwork
Get-NetworkControllerPublicIPAddress
Get-NetworkControllerGatewayPool
Get-NetworkControllerGateway
Get-NetworkControllerVirtualGateway
Get-NetworkControllerNetworkInterface

Z maszyny wirtualnej bramy:

Ipconfig /allcompartments /all
Get-NetRoute -IncludeAllCompartments -AddressFamily
Get-NetBgpRouter
Get-NetBgpRouter | Get-BgpPeer
Get-NetBgpRouter | Get-BgpRouteInformation

Z górnej części stojaka (ToR) przełącznik:

sh ip bgp summary (for 3rd party BGP Routers)

Router protokołu BGP systemu Windows:

Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation

Oprócz wspomnianych z problemów, które zauważono pory (szczególnie we wdrożeniach na podstawie SDNExpress) najbardziej typowe przyczyny przedziału dzierżawy pobieranie nieskonfigurowany na maszynach wirtualnych GW wydaje się być fakt, że pojemność GW w FabricConfig.psd1 jest mniejsza w porównaniu do spamerzy Spróbuj przypisać do połączeń sieciowych (tunele S2S) w TenantConfig.psd1. Można to łatwo sprawdzić, porównując dane wyjściowe następujących poleceń cmdlet:

PS > (Get-NetworkControllerGatewayPool -ConnectionUri $uri).properties.Capacity
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").properties.OutboundKiloBitsPerSecond
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").property

[Dostawcy usług hostingowych] Sprawdzanie poprawności danych płaszczyzna

Po wdrożeniu kontrolera sieci, podsieci i sieci wirtualne dzierżawcy zostały utworzone i maszyny wirtualne zostały dołączone do podsieci wirtualnych, można wykonać testy poziomu dodatkowe sieci szkieletowej przez dostawcę usług hostingowych, aby sprawdzić łączność dzierżawy.

Sprawdź łączność sieci logicznej dostawcy HNV

Po pierwszego podłączenia działające na hoście funkcji Hyper-V maszyny Wirtualnej z siecią wirtualną dzierżawy gościa Kontroler sieci przypisze dwóch HNV dostawcy adresów IP (PA IP adresów) na hoście funkcji Hyper-V. Te adresy IP będą pochodzić z puli adresów IP sieci logicznej dostawca HNV i zarządzany przez kontroler sieci. Aby dowiedzieć się, jakie są te dwa adresy IP HNV:

PS > Get-ProviderAddress

# Sample Output
ProviderAddress : 10.10.182.66
MAC Address     : 40-1D-D8-B7-1C-04
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

ProviderAddress : 10.10.182.67
MAC Address     : 40-1D-D8-B7-1C-05
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

Te adresy IP dostawcy HNV (IP PA) są przypisane do karty Ethernet utworzone w osobnym przedziału sieci TCPIP i ma nazwę karty VLANX gdzie X jest sieci VLAN przypisane do sieci logicznej dostawca HNV (transportu).

Połączenie między dwoma hostami funkcji Hyper-V przy użyciu dostawcy HNV sieci logicznej może odbywać się przez polecenia ping z dodatkowych przedziału (-c Y) parametr, gdzie t jest TCPIP przedziału sieci, w którym są tworzone PAhostVNICs. Przedział ten może zostać określony przez wykonywanie:

C:\> ipconfig /allcompartments /all

<snip> ...
==============================================================================
Network Information for *Compartment 3*
==============================================================================
   Host Name . . . . . . . . . . . . : SA18n30-2
<snip> ...

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-04
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::5937:a365:d135:2899%39(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.66(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-05
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::28b3:1ab1:d9d9:19ec%44(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.67(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

*Ethernet adapter vEthernet (PAhostVNic):*
<snip> ...

Uwaga

Karty wirtualnej karty sieciowej hosta PA nie są używane w ścieżce danych i dlatego nie mają adresów IP przypisanych do karty"vEthernet (PAhostVNic)".

Na przykład założyć, że hosty funkcji Hyper-V 1 i 2 mają adresy IP HNV dostawcy (PA):

Hyper-V Host Adres IP pa 1 Adres IP PA 2
Host 1 10.10.182.64 10.10.182.65
Host 2 10.10.182.66 10.10.182.67

Firma Microsoft może wysyłać polecenia ping między nimi przy użyciu następującego polecenia do sprawdzania łączności sieci logicznej dostawcy HNV.

# Ping the first PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.64

# Ping the second PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.64

# Ping the first PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.65

# Ping the second PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.65

Korygowanie

Jeśli polecenie ping dostawcy HNV nie działa, sprawdź łączność sieci fizycznej, w tym konfigurację sieci VLAN. Fizycznych kart sieciowych na każdym hoście funkcji Hyper-V powinien być w trybie magistrali z nie określonej sieci VLAN przypisane. Wirtualnej karty sieciowej hosta zarządzania powinna być odizolowane VLAN zarządzania sieci logicznej.

PS C:\> Get-NetAdapter "Ethernet 4" |fl

Name                       : Ethernet 4
InterfaceDescription       : <NIC> Ethernet Adapter
InterfaceIndex             : 2
MacAddress                 : F4-52-14-55-BC-21
MediaType                  : 802.3
PhysicalMediaType          : 802.3
InterfaceOperationalStatus : Up
AdminStatus                : Up
LinkSpeed(Gbps)            : 10
MediaConnectionState       : Connected
ConnectorPresent           : True
*VlanID                     : 0*
DriverInformation          : Driver Date 2016-08-28 Version 5.25.12665.0 NDIS 6.60

# VMM uses the older PowerShell cmdlet <Verb>-VMNetworkAdapterVlan to set VLAN isolation
PS C:\> Get-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName <Mgmt>

VMName VMNetworkAdapterName Mode     VlanList
------ -------------------- ----     --------
<snip> ...
       Mgmt                 Access   7
<snip> ...

# SDNExpress deployments use the newer PowerShell cmdlet <Verb>-VMNetworkAdapterIsolation to set VLAN isolation
PS C:\> Get-VMNetworkAdapterIsolation -ManagementOS

<snip> ...

IsolationMode        : Vlan
AllowUntaggedTraffic : False
DefaultIsolationID   : 7
MultiTenantStack     : Off
ParentAdapter        : VMInternalNetworkAdapter, Name = 'Mgmt'
IsTemplate           : True
CimSession           : CimSession: .
ComputerName         : SA18N30-2
IsDeleted            : False

<snip> ...

Sprawdź obsługę ramki MTU i jumbo w sieci logicznej dostawcy HNV

Innym typowym problemem w sieci logicznej dostawcy HNV jest to, że fizyczne porty sieciowe i/lub karta Ethernet nie mają wystarczająco dużej jednostki MTU skonfigurowanej do obsługi obciążenia z hermetyzacji VXLAN (lub NVGRE).

Uwaga

Niektóre karty Ethernet i sterowniki obsługują nowe *EncapOverhead słowo kluczowe, które zostanie automatycznie ustawione przez agenta hosta kontrolera sieci na wartość 160. Ta wartość zostanie następnie dodana do wartości słowa kluczowego *JumboPacket, którego sumowanie jest używane jako anonsowane jednostki MTU.

Na przykład *EncapOverhead = 160 i *JumboPacket = 1514 => MTU = 1674B

# Check whether or not your Ethernet card and driver support *EncapOverhead
PS C:\ > Test-EncapOverheadSettings

Verifying Physical Nic : <NIC> Ethernet Adapter #2
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Verifying Physical Nic : <NIC> Ethernet Adapter
Physical Nic  <NIC> Ethernet Adapter can support SDN traffic. Encapoverhead value set on the nic is  160

Aby sprawdzić, czy sieć logiczna dostawcy HNV obsługuje większy rozmiar jednostki MTU, użyj Test-LogicalNetworkSupportsJumboPacket polecenia cmdlet :

# Get credentials for both source host and destination host (or use the same credential if in the same domain)
$sourcehostcred = Get-Credential
$desthostcred = Get-Credential

# Use the Management IP Address or FQDN of the Source and Destination Hyper-V hosts
Test-LogicalNetworkSupportsJumboPacket -SourceHost sa18n30-2 -DestinationHost sa18n30-3 -SourceHostCreds $sourcehostcred -DestinationHostCreds $desthostcred

# Failure Results
SourceCompartment : 3
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1632
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1472
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.

Korygowanie

  • Dopasuj rozmiar jednostki MTU w portach przełącznika fizycznego na co najmniej 1674B (w tym nagłówek Ethernet 14B i przyczepy)
  • Jeśli karta sieciowa nie obsługuje słowa kluczowego EncapOverhead, dostosuj słowo kluczowe JumboPacket do co najmniej 1674B

Sprawdzanie łączności kart interfejsu sieciowego maszyny wirtualnej dzierżawy

Każda karta Sieciowa maszyny Wirtualnej przypisane do gościa maszyny Wirtualnej ma PA urzędu certyfikacji mapowania między prywatnych adresów klienta (CA) i miejsce HNV adresów dostawcy (PA). Te mapowania są przechowywane w tabelach serwera OVSDB na każdym hoście funkcji Hyper-V i można go znaleźć, wykonując następujące polecenie cmdlet.

# Get all known PA-CA Mappings from this particular Hyper-V Host
PS > Get-PACAMapping

CA IP Address CA MAC Address    Virtual Subnet ID PA IP Address
------------- --------------    ----------------- -------------
10.254.254.2  00-1D-D8-B7-1C-43              4115 10.10.182.67
10.254.254.3  00-1D-D8-B7-1C-43              4115 10.10.182.67
192.168.1.5   00-1D-D8-B7-1C-07              4114 10.10.182.65
10.254.254.1  40-1D-D8-B7-1C-06              4115 10.10.182.66
192.168.1.1   40-1D-D8-B7-1C-06              4114 10.10.182.66
192.168.1.4   00-1D-D8-B7-1C-05              4114 10.10.182.66

Uwaga

Jeśli oczekiwane mapowania urzędu certyfikacji nie są danymi wyjściowymi dla danej maszyny wirtualnej dzierżawy, sprawdź zasoby karty sieciowej i konfiguracji adresu IP maszyny wirtualnej na kontrolerze sieci przy użyciu Get-NetworkControllerNetworkInterface polecenia cmdlet . Należy także sprawdzić ustanowionych połączeń między węzłami NC agenta hosta i kontroler sieci.

Dzięki tym informacjom polecenie ping maszyny wirtualnej dzierżawy może być teraz inicjowane przez dostawcę usług hostingowych z kontrolera sieci przy użyciu Test-VirtualNetworkConnection polecenia cmdlet .

Konkretne scenariusze rozwiązywania problemów

Poniższe sekcje zawierają wskazówki dotyczące rozwiązywania problemów z konkretnymi scenariuszami.

Nie połączenie sieciowe między dwoma maszyn wirtualnych dzierżawcy

  1. [Dzierżawy] Upewnij się, że Zapora systemu Windows na maszynach wirtualnych dzierżawy nie blokuje ruchu.
  2. [Dzierżawa] Sprawdź, czy adresy IP zostały przypisane do maszyny wirtualnej dzierżawy, uruchamiając polecenie ipconfig.
  3. [Dostawcy usług hostingowych] Uruchom Test-VirtualNetworkConnection z hosta funkcji Hyper-V zweryfikować łączności między maszynami wirtualnymi dwóch dzierżawy zagrożona.

Uwaga

Identyfikator VSID odwołuje się do wirtualnego identyfikatora podsieci. W przypadku VXLAN to jest identyfikator sieci VXLAN (VNI). Tę wartość można znaleźć, uruchamiając Get-PACAMapping polecenie cmdlet .

Przykład

$password = ConvertTo-SecureString -String "password" -AsPlainText -Force
$cred = New-Object pscredential -ArgumentList (".\administrator", $password)

Utwórz polecenie ping urzędu certyfikacji między "Zieloną maszyną wirtualną sieci Web 1" przy użyciu adresu IP SenderCA 192.168.1.4 na hoście "sa18n30-2.sa18.nttest.microsoft.com" z adresem IP mgmt 10.127.132.153 do adresu IP odbiornika 192.168.1.5 dołączone do podsieci wirtualnej (VSID) 4114.

Test-VirtualNetworkConnection -OperationId 27 -HostName sa18n30-2.sa18.nttest.microsoft.com -MgmtIp 10.127.132.153 -Creds $cred -VMName "Green Web VM 1" -VMNetworkAdapterName "Green Web VM 1" -SenderCAIP 192.168.1.4 -SenderVSID 4114 -ListenerCAIP 192.168.1.5 -ListenerVSID 4114
Test-VirtualNetworkConnection at command pipeline position 1

Starting CA-space ping test
Starting trace session
Ping to 192.168.1.5 succeeded from address 192.168.1.4
Rtt = 0 ms

CA Routing Information:

    Local IP: 192.168.1.4
    Local VSID: 4114
    Remote IP: 192.168.1.5
    Remote VSID: 4114
    Distributed Router Local IP: 192.168.1.1
    Distributed Router Local MAC: 40-1D-D8-B7-1C-06
    Local CA MAC: 00-1D-D8-B7-1C-05
    Remote CA MAC: 00-1D-D8-B7-1C-07
    Next Hop CA MAC Address: 00-1D-D8-B7-1C-07

PA Routing Information:

    Local PA IP: 10.10.182.66
    Remote PA IP: 10.10.182.65

 <snip> ...

[Dzierżawa] Sprawdź, czy w podsieci wirtualnej lub interfejsach sieciowych maszyn wirtualnych nie określono żadnych rozproszonych zasad zapory, które blokują ruch.

Wykonaj zapytanie dotyczące interfejsu API REST kontrolera sieci znalezionego w środowisku demonstracyjnym w lokalizacji sa18n30nc w domenie sa18.nttest.microsoft.com.

$uri = "https://sa18n30nc.sa18.nttest.microsoft.com"
Get-NetworkControllerAccessControlList -ConnectionUri $uri

Zapoznaj się z konfiguracją adresów IP i podsieciami wirtualnymi odwołującymi się do tej listy ACL

  1. [Dostawcy usług hostingowych] Uruchom Get-ProviderAddress na obu funkcji Hyper-V hosting dwa hosty maszyn wirtualnych w pytaniu dzierżawy, a następnie uruchom Test-LogicalNetworkConnection lub ping -c <compartment> z hosta Hyper-V, aby sprawdzić łączność w sieci logicznej HNV dostawcy
  2. [Dostawcy usług hostingowych] Upewnij się, że ustawienia MTU są prawidłowe na hostach funkcji Hyper-V i dowolne warstwy 2 przełączanie urządzeń Between hosty funkcji Hyper-V. Uruchom Test-EncapOverheadValue na wszystkich hostach funkcji Hyper-V jest zagrożona. Również Sprawdź, czy wszystkie przełączniki warstwy 2 między mają rozmiar jednostki MTU wartość co najmniej bajtów 1674 pod uwagę maksymalne obciążenie 160 bajtów.
  3. [Dostawcy usług hostingowych] Jeśli nie są adresy IP dostawcy i/lub urzędu certyfikacji połączenie zostanie przerwane, sprawdź, upewnij się, że otrzymano zasad sieci. Uruchom Get-PACAMapping Aby zobaczyć, jeśli są poprawnie ustanowione reguły hermetyzacji i mapowanie adresu wymagane do utworzenia sieci wirtualne nakładki.
  4. [Dostawcy usług hostingowych] Sprawdź, czy Agent hosta Kontroler sieci jest połączone z kontrolerem sieci. Aby to zrobić, uruchom netstat -anp tcp |findstr 6640.
  5. [Dostawcy usług hostingowych] Sprawdź, czy Host IDENTYFIKATORA w HKLM / pasuje do Identyfikatora wystąpienia zasobów serwera hostingu maszyn wirtualnych dzierżawcy.
  6. [Dostawcy usług hostingowych] Sprawdź, czy identyfikator profilu portu zgodny z Identyfikatorem wystąpienia interfejsów sieci maszyn Wirtualnych maszyn wirtualnych dzierżawcy.

Rejestrowanie, śledzenie i zaawansowana diagnostyka

Poniższe sekcje zawierają informacje na temat zaawansowanej diagnostyki, rejestrowania i śledzenia.

Kontroler sieci centralnego rejestrowania

Kontroler sieci może automatycznie zbieranie dzienników debugera i przechowywać je w centralnej lokalizacji. Zbieranie dzienników można włączyć podczas wdrażania kontrolera sieci po raz pierwszy lub w dowolnym późniejszym czasie. Dzienniki są zbierane z kontrolera sieci i elementy zarządzane przez kontroler sieci sieci: maszyn, oprogramowania równoważenia obciążenia (SLB) i bramy maszyny hostów.

Dzienniki te obejmują dzienniki debugowania klastra kontrolera sieci, aplikację kontrolera sieci, dzienniki bramy, SLB, sieć wirtualną i rozproszoną zaporę. Zawsze, gdy nowy host/SLB/bramy jest dodawany do kontrolera sieci, rejestrowanie jest uruchomiona na tych komputerach. Podobnie gdy host/SLB/bramy jest usuwana z kontrolera sieci, rejestrowanie zostało zatrzymane na tych komputerach.

Włącz rejestrowanie

Rejestrowanie jest automatycznie włączane podczas instalowania klastra kontrolera sieci przy użyciu Install-NetworkControllerCluster polecenia cmdlet . Domyślnie dzienniki są zbierane lokalnie na węzłach Kontroler sieci w %systemdrive%\SDNDiagnostics. Zaleca się zmianę tej lokalizacji na zdalny udział plików (nie lokalny).

Dzienniki klastra Kontroler sieci są przechowywane w %programData%\Windows Fabric\log\Traces. Można określić scentralizowaną lokalizację zbierania dzienników za pomocą parametru DiagnosticLogLocation z zaleceniem, że jest to również zdalny udział plików.

Jeśli chcesz ograniczyć dostęp do tej lokalizacji można podać poświadczenia dostępu za pomocą LogLocationCredential parametru. Jeśli podano poświadczenia umożliwiające dostęp do lokalizacji dziennika, należy również podać CredentialEncryptionCertificate parametr, który jest używany do szyfrowania poświadczeń przechowywane lokalnie w węzłach kontrolera sieci.

W przypadku ustawień domyślnych zaleca się posiadanie co najmniej 75 GB wolnego miejsca w centralnej lokalizacji i 25 GB w węzłach lokalnych (jeśli nie jest używana centralna lokalizacja) dla klastra kontrolera sieci z trzema węzłami.

Zmień ustawienia rejestrowania

Można zmienić ustawienia rejestrowania w dowolnym czasie przy użyciu Set-NetworkControllerDiagnostic polecenia cmdlet. Można zmienić następujące ustawienia:

  • Scentralizowana lokalizacja dziennika.

    Możesz zmienić lokalizację do przechowywania wszystkich dzienników z DiagnosticLogLocation parametru.

  • Poświadczenia umożliwiające dostęp do lokalizacji dziennika.

    Można zmienić poświadczenia dostępu do lokalizacji dziennika z LogLocationCredential parametru.

  • Przejdź do rejestrowania lokalnego.

    Jeżeli został centralną lokalizację do przechowywania dzienników można cofnąć logowanie lokalnie węzły kontrolera sieci z UseLocalLogLocation parametru (niezalecane ze względu na wymagania dotyczące miejsca na dysku duże).

  • Zakres rejestrowania.

    Domyślnie wszystkie dzienniki są zbierane. Można zmienić zakres, aby zebrać tylko dzienniki klastra kontrolera sieci.

  • Poziom rejestrowania.

    Domyślny poziom rejestrowania jest komunikat informacyjny. Można go zmienić na błąd, ostrzeżenie lub pełne.

  • Czas starzenia dziennika.

    Dzienniki są przechowywane w sposób cykliczne. Domyślnie masz trzy dni rejestrowania danych niezależnie od tego, czy używasz rejestrowania lokalnego, czy scentralizowanego rejestrowania. Ten limit czasu można zmienić za pomocą parametru LogTimeLimitInDays .

  • Rozmiar starzenia dziennika.

    Domyślnie trzeba będzie maksymalna 75 GB rejestrowania danych jeśli za pomocą scentralizowanego rejestrowania i 25 GB, jeśli za pomocą lokalnego rejestrowania. Można zmienić ten limit z LogSizeLimitInMBs parametru.

Zbieranie dzienników i śladów

Wdrożenia programu VMM korzysta domyślnie scentralizowane rejestrowanie dla kontrolera sieci. Lokalizacja udziału plików dla tych dzienników jest określony podczas wdrażania szablonu usługi kontrolera sieci.

Jeśli nie określono lokalizacji pliku, rejestrowanie lokalne będzie używane w każdym węźle Kontrolera sieci z dziennikami zapisanymi w folderze C:\Windows\tracing\SDNDiagnostics. Dzienniki te są zapisywane przy użyciu następującej hierarchii:

  • CrashDumps
  • NCApplicationCrashDumps
  • NCApplicationLogs
  • PerfCounters
  • SDNDiagnostics
  • Ślady

Kontroler sieci korzysta z sieci szkieletowej usługi (Azure). Dzienniki usługi Service Fabric mogą być wymagane podczas rozwiązywania niektórych problemów. Te dzienniki można znaleźć w każdym węźle Kontroler sieci w folderze C:\ProgramData\Microsoft\Service Fabric.

Jeśli użytkownik uruchomi Debug-NetworkController polecenie cmdlet, więcej dzienników będzie dostępnych na każdym hoście funkcji Hyper-V, który został określony z zasobem serwera w kontrolerze sieci. Te dzienniki (i ślady, jeśli włączono) są przechowywane w folderze C:\NCDiagnostics.

Diagnostyka SLB

Błędy sieci szkieletowej SLBM (akcje dostawcy usług hostingu)

  1. Sprawdź, czy programowy menedżer równoważenia obciążenia (SLBM) działa i czy warstwy aranżacji mogą komunikować się ze sobą: SLBM —> SLB Mux i SLBM —> agenci hosta SLB. Uruchom DumpSlbRestState z dowolnego węzła z dostępem do punktu końcowego REST kontrolera sieci.
  2. Zweryfikuj elementy SDNSLBMPerfCounters w elemecie PerfMon na jednej z maszyn wirtualnych kontrolera sieci (najlepiej podstawowego węzła kontrolera sieci — Get-NetworkControllerReplica):
    1. Aparat usługi równoważenia obciążenia (kg) jest podłączony do SLBM? (SLBM LBEngine Configurations Total > 0)
    2. SLBM wiedzieć co najmniej o własne punkty końcowe? (Łączna> liczba punktów końcowych vip= 2)
    3. Hosty funkcji Hyper-V (DIP) są połączone z SLBM? (Połączonych klientów HP == num serwerów)
    4. SLBM jest podłączony do Muxes? (Muxes Connected == Muxes Healthy on SLBM == Muxes reporting healthy = # SLB Muxes VMs).
  3. Upewnij się, że skonfigurowany router BGP pomyślnie wykonuje komunikację równorzędną z interfejsem MUX SLB.
    1. W przypadku korzystania z usługi RRAS z dostępem zdalnym (czyli maszyny wirtualnej protokołu BGP):
      1. Get-BgpPeer powinna zostać wyświetlona wartość połączona.
      2. Get-BgpRouteInformation powinna zawierać co najmniej trasę dla własnego adresu VIP SLBM.
    2. Jeśli używasz fizycznego przełącznika Top-of-Rack (ToR) jako elementu równorzędnego BGP, zapoznaj się z dokumentacją:
      1. Na przykład: # show bgp instance.
  4. Sprawdź poprawność liczników SlbMuxPerfCounters i SLBMUX na maszynie wirtualnej SLB Mux.
  5. Sprawdź stan konfiguracji i zakresy adresów VIP w zasobie programowego menedżera równoważenia obciążenia.
    1. Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://\<FQDN or IP>| convertto-json -depth 8 (Sprawdź zakresy adresów VIP w pulach adresów IP i upewnij się, że protokół SLBM self-VIP (LoadBalanacerManagerIPAddress) i wszystkie adresy VIP dostępne dla dzierżawy znajdują się w tych zakresach)
      1. Get-NetworkControllerIpPool -NetworkId "<Public/Private VIP Logical Network Resource ID>" -SubnetId "<Public/Private VIP Logical Subnet Resource ID>" -ResourceId "\<IP Pool Resource Id>" -ConnectionUri $uri |convertto-json -depth 8
    2. Debug-NetworkControllerConfigurationState -

Ewentualne kontroli nad kończyć się niepowodzeniem, dzierżawy stanu SLB również będzie w trybie awarii.

Korygowanie

Oparte na następujących informacji diagnostycznych przedstawione, napraw następujące czynności:

  • Upewnij się, że multipleksery SLB są połączone
    • Rozwiąż problemy z certyfikatami
    • Rozwiąż problemy z połączeniem sieciowym
  • Upewnij się, że pomyślnie skonfigurowano BGP zaglądanie informacji
  • Upewnij się, identyfikator wystąpienia serwera w zasobie serwer odpowiada identyfikator hosta w rejestrze (odwołać dodatku dla HostNotConnected Kod błędu)
  • Zbieranie dzienników

Błędy dzierżawy SLBM (akcje dostawcy usług hostingu i dzierżawy)

  1. [Hoster] Sprawdź Debug-NetworkControllerConfigurationState , czy jakiekolwiek zasoby modułu LoadBalancer są w stanie błędu. Spróbuj zmniejszyć, wykonując następujące czynności do wykonania tabeli w dodatku.
    1. Sprawdź, czy punkt końcowy adresu VIP jest obecny i anonsuje trasy.
    2. Sprawdź, ile punktów końcowych DIP zostało odnalezionych dla punktu końcowego adresu VIP.
  2. [Dzierżawa] Sprawdź, czy zasoby modułu równoważenia obciążenia są poprawnie określone.
    1. Zweryfikuj punkty końcowe DIP zarejestrowane w programie SLBM hostują maszyny wirtualne dzierżawy, które odpowiadają konfiguracjom adresów IP puli adresów zaplecza usługi LoadBalancer.
  3. [Hoster] Jeśli punkty końcowe DIP nie są odnajdywane lub połączone:

    1. Sprawdzić Debug-NetworkControllerConfigurationState

      Sprawdź, czy agent hosta NC i SLB został pomyślnie połączony z koordynatorem zdarzeń kontrolera sieci przy użyciu polecenia netstat -anp tcp |findstr 6640).

    2. Zaewidencjonuj HostIdnchostagent klucz usługi (kod błędu odwołania HostNotConnected w dodatku) jest zgodny z identyfikatorem wystąpienia odpowiedniego zasobu serwera (Get-NCServer |convertto-json -depth 8).

    3. Sprawdź identyfikator profilu portu dla portu maszyny wirtualnej zgodny z identyfikatorem wystąpienia odpowiedniego zasobu karty sieciowej maszyny wirtualnej.

  4. [Dostawca hostingu] Zbieranie dzienników.

Śledzenie SLB Mux

Także informacji z Muxes usługi równoważenia obciążenia oprogramowania można określić za pomocą Podglądu zdarzeń.

  1. Wybierz pozycję Pokaż dzienniki analityczne i Debuguj w menu Widok Podgląd zdarzeń.
  2. Przejdź do pozycji Dzienniki>aplikacji i usług Microsoft>Windows>SlbMuxDriver>Trace w Podgląd zdarzeń.
  3. Kliknij go prawym przyciskiem myszy i wybierz pozycję Włącz dziennik.

Uwaga

Zaleca się włączenie tego rejestrowania tylko przez krótki czas podczas próby odtworzenia problemu.

Śledzenie VFP i przełączników wirtualnych

Z dowolnego hosta funkcji Hyper-V, który hostuje maszynę wirtualną gościa dołączoną do sieci wirtualnej dzierżawy, możesz zebrać ślad VFP, aby określić, gdzie mogą znajdować się problemy.

netsh trace start provider=Microsoft-Windows-Hyper-V-VfpExt overwrite=yes tracefile=vfp.etl report=disable provider=Microsoft-Windows-Hyper-V-VmSwitch
netsh trace stop
netsh trace convert .\vfp.etl ov=yes