Problembehandlung bei der Bereitstellung von Software Defined Networking in Azure Local über Windows Admin Center
Gilt für: Azure Local, Versionen 23H2 und 22H2; Windows Server 2022, Windows Server 2019
Dieser Artikel enthält Anleitungen zum Behandeln von Problemen, die beim Bereitstellen der SDN-Komponenten mit Windows Admin Center auftreten können. Verwenden Sie diese Anleitung, um probleme zu beheben, bevor Sie ein Supportticket erstellen. Dieser Artikel enthält auch Anweisungen zum Sammeln von Protokollen nach der erfolgreichen Problembehandlung, um die Ursache eines Bereitstellungsfehlers zu diagnostizieren.
Problembehandlung bei Timeoutfehlern
Wenn die Bereitstellung virtueller Computer (VM) für die verschiedenen SDN-Komponenten, einschließlich Netzwerkcontroller, Softwarelastenausgleich oder Gateway-Zeitüberschreitung, auftritt, wird der folgende Fehler angezeigt:
.... ist nach dem Timeout von 1800 Sekunden nicht bereit.
Diese Meldung wird möglicherweise während der Bereitstellung von Netzwerkcontroller, Softwarelastenausgleich oder Gateway im Windows Admin Center angezeigt.
Führen Sie die folgenden Überprüfungen aus, um die Ursache des Fehlers in Ihrer SDN-Bereitstellung über Windows Admin Center zu identifizieren und zu beheben:
Vergewissern Sie sich, dass Sie die richtige VHDX-Datei heruntergeladen haben.
Überprüfen Sie die Konnektivität Ihres Verwaltungsnetzwerk-VLANs.
Stellen Sie sicher, dass Windows Defender- und Firewallrichtlinien winRM-Konnektivität von der Windows Admin Center-VM mit den VMs des Netzwerkcontrollers zulassen.
Überprüfen Sie die Konnektivität mit dem SDN-URI oder DEM SDN-Cluster.
Nachdem Sie diese Prüfungen abgeschlossen und identifizierte Probleme durch Problembehandlung behoben haben, fahren Sie mit der Bereitstellung von SDN fort. Außerdem wird empfohlen , Protokolle zu sammeln, um zu ermitteln, warum die Bereitstellung einer SDN-VM fehlgeschlagen war.
Herunterladen der richtigen VHDX-Datei
Sie müssen eine virtuelle Festplatte des Azure Stack HCI-Betriebssystems herunterladen, um sie für die VMs der SDN-Infrastruktur (Network Controller, Software Load Balancer, Gateway) zu verwenden. Downloadanweisungen finden Sie unter Herunterladen der VHDX-Datei.
Überprüfen der Konnektivität Ihres Verwaltungsnetzwerk-VLANs
Wenn keine Verbindung zwischen dem Verwaltungsnetzwerk-VLAN und Azure Local besteht, ist die VM-Bereitstellung nicht mehr verfügbar.
Führen Sie die folgenden Schritte aus, um die Konnektivität des Verwaltungsnetzwerk-VLAN zu überprüfen:
Stellen Sie sicher, dass Sie Zugriff auf das lokale Azure- und ein Verwaltungsnetzwerk-VLAN haben.
Erstellen Sie in Windows Admin Center eine neue VM auf Azure Local mit jedem unterstützten Betriebssystem.
Weisen Sie der neuen VM, die dem Verwaltungsnetzwerk zugewiesen wurde, dieselbe IP-Adresse zu.
Konfigurieren Sie dasselbe VLAN für den neuen virtuellen Computer auf dem Host, auf dem sich der virtuelle Computer befindet.
Um zu bestätigen, dass der neue virtuelle Computer die richtige IP-Adresse zugewiesen ist und um doppelte Adressprobleme auszuschließen, führen Sie den
ipconfig /all
Befehl auf der neuen VM aus.Überprüfen Sie, ob der neue virtuelle Computer die lokalen Azure-Hosts anpingen kann und umgekehrt.
Überprüfen Sie, ob die neue VM mit den DNS-Servern und dem Standardgateway des Verwaltungsnetzwerks kommunizieren kann.
Verbinden Sie den neuen virtuellen Computer mit den gleichen Anmeldeinformationen, die während der SDN-VM-Bereitstellung bereitgestellt werden.
Sicherstellen, dass Windows Defender- und Firewallrichtlinien die WinRM-Konnektivität zulassen
Sie müssen Windows Remote Management (WinRM) und PowerShell-Remoting aktivieren, um die Konfiguration auf den VMs des Netzwerkcontrollers zu starten, die bereitgestellt wurden. Wenn dies nicht geschehen ist, tritt ein Timeoutfehler auf.
Führen Sie die folgenden Schritte aus, um WinRM und PowerShell-Remoting zu überprüfen oder zu aktivieren:
Richten Sie in Windows Admin Center eine Remote-PowerShell mit der VM des Netzwerkcontrollers ein.
Enter-PSSession NCVMExample
Wenn Sie die Remotesitzung eingeben können, gibt sie an, dass die Netzwerkrichtlinien von Ihrem Domänenadministrator festgelegt werden. Um SDN erfolgreich über Das Windows Admin Center bereitzustellen, überprüfen Sie diese Richtlinien, und stellen Sie sicher, dass sie WinRM und PowerShell-Remoting zulassen.
Wenn Sie die folgende WinRM-Fehlermeldung erhalten, fahren Sie weiter in diesem Abschnitt fort, um den Fehler zu beheben. Beispiel für Fehlermeldung:
Enter-PSSession : Connecting to remote server NCVMExample failed with the following error message : WinRM cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that a firewall exception for the WinRM service is enabled and allows access from this computer. By default, the WinRM firewall exception for public profiles limits access to remote computers within the same local subnet.
Melden Sie sich bei einem der VMs des Netzwerkcontrollers entweder lokal oder mithilfe einer RDP-Verbindung (Remote Desktop Protocol) an.
Führen Sie den folgenden Befehl aus, um die Windows-Firewall zu deaktivieren:
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False
Richten Sie in Windows Admin Center eine Remote-PowerShell-Sitzung erneut auf dem virtuellen Computer des Netzwerkcontrollers ein:
Enter-PSSession NCVMExample
Wenn Sie die Remotesitzung als temporäre Maßnahme eingeben können, können Sie die Firewall auf den verbleibenden Netzwerkcontroller-VMs deaktivieren, um die SDN-Bereitstellung abzuschließen. Diese Konfigurationsänderung kann jedoch nach Anwendung von Gruppenrichtlinienupdates wiederhergestellt werden.
Überprüfen der Konnektivität mit dem SDN-URI oder SDN-Cluster
Der SDN-URI und der Clustername sind nützlich, wenn Windows Admin Center zum ersten Mal eine Verbindung mit der SDN-Umgebung herstellt und Wenn Sie PowerShell-Cmdlets für Netzwerkcontroller ausführen.
Wenn Sie keine Verbindung mit dem SDN-URI oder dem Clusternamen herstellen können, stellen Sie sicher, dass dynamisches DNS aktiviert ist. Informationen zum Aktivieren dynamischer DNS finden Sie unter Dynamische DNS-Updates.
Nachdem Sie dynamisches DNS aktiviert haben, können Sie den SDNAPI
Microservice möglicherweise verschieben, indem Sie die folgenden Schritte für die Registrierung ausführen:
Richten Sie in Windows Admin Center eine Remote-PowerShell mit der VM des Netzwerkcontrollers ein.
Enter-PSSession NCVMExample
Führen Sie den folgenden Befehl aus, um eine Verbindung mit dem Service Fabric-Cluster auf der VM des Netzwerkcontrollers herzustellen.
Connect-ServiceFabricCluster
Führen Sie den folgenden Befehl aus, um den
SDNAPI
Microservice zu verschieben:Move-ServiceFabricPrimaryReplica -ServiceName fabric:/NetworkController/ApiService
Warten Sie ungefähr fünf Minuten, und pingen Sie dann den URI-Namen des Netzwerkcontrollers.
Ping nchci.contoso.com
Sammeln von Protokollen für SDN-Komponenten
Nach der erfolgreichen Problembehandlung des Bereitstellungsproblems empfehlen wir das Sammeln von Protokollen, um zu ermitteln, warum die Bereitstellung einer SDN-VM fehlgeschlagen war.
Führen Sie die folgenden Schritte aus, um Gastprotokolle für die SDN-VM zu sammeln:
Stellen Sie mit dem Windows Admin Center- oder Hyper-V-Host eine Verbindung mit dem SDN-virtuellen Computer her, für den Sie Protokolle sammeln möchten.
Tipp
Wenn der Bildschirm "Hyper-V" nach der Anmeldung beim virtuellen Computer mit dem Hyper-V-Host nicht angezeigt wird, drücken Sie UMSCHALT+F10, um eine Eingabeaufforderung zu öffnen.
Wechseln Sie zum Laufwerk C: und sammeln Sie die Antwortdatei (unattend.xml).
Um Details zum Vm-Bereitstellungsverlauf abzurufen, wechseln Sie zum Ordner "C:\Windows\Panther", und erfassen Sie den gesamten Inhalt dieses Ordners.
Um SDN-Protokolle auf dem Server zu sammeln, stellen Sie eine Verbindung mit dem ersten physischen Knoten von Azure Local her. Suchen Sie die SDN-Protokolldatei unter Tools>Dateien & Dateifreigabe>Dieser PC>C:>Dokumente und Einstellungen.