Beheben von Problemen bei der Netzwerkleistung

Übersicht

Azure bietet eine stabile und schnelle Möglichkeit, eine Verbindung zwischen Ihrem lokalen Netzwerk und Azure herzustellen. Methoden wie Site-to-Site-VPN und ExpressRoute werden von Kunden aller Größen für ihre Unternehmen in Azure erfolgreich eingesetzt. Was passiert jedoch, wenn die Leistung nicht Ihren Erwartungen oder früheren Erfahrungen entspricht? Anhand der Informationen in diesem Artikel können Sie die Art und Weise standardisieren, wie Sie Ihre spezifische Umgebung testen und als Baseline definieren.

Sie erfahren, wie Sie die Netzwerklatenz und Bandbreite zwischen zwei Hosts einfach und konsistent testen können. Außerdem erhalten Sie Informationen zu unterschiedlichen Möglichkeiten, wie Sie das Azure-Netzwerk zum Isolieren von Problempunkten untersuchen. Für das erörterte PowerShell-Skript und die entsprechenden Tools sind zwei Hosts im Netzwerk erforderlich (an beiden Enden der getesteten Verbindung). Ein Host muss ein Windows Server- oder Desktop-Computer sein, auf dem anderen kann Windows oder Linux ausgeführt werden.

Netzwerkkomponenten

Bevor wir uns der Problembehandlung zuwenden, erörtern wir einige allgemeine Begriffe und Komponenten. Dadurch wird sichergestellt, dass jede Komponente in der durchgehenden Kette berücksichtigt wird, die Verbindungen in Azure ermöglicht.

Auf der obersten Ebene befinden sich drei wesentliche Netzwerkroutingdomänen:

• Azure-Netzwerk (blaue Cloud)
• Internet oder WAN (grüne Cloud)
• Unternehmensnetzwerk (orangefarbene Cloud)

Die einzelnen Komponenten werden von rechts nach links kurz erläutert:

• VM: Der Server verfügt möglicherweise über mehrere Netzwerkadapter (NIC). Stellen Sie sicher, dass alle statischen Routen, Standardrouten und Einstellungen des Betriebssystems Datenverkehr wie erwartet senden und empfangen. Zudem verfügt jede VM-SKU über eine Bandbreiteneinschränkung. Bei Verwendung einer kleineren VM-SKU wird der Datenverkehr durch die für die Netzwerkkarte verfügbare Bandbreite eingeschränkt. Zum Testen wird die Verwendung von DS5v2 empfohlen, um eine ausreichende Bandbreite für die VM zu gewährleisten.

• Netzwerkkarte: Stellen Sie sicher, dass Sie die private IP-Adresse kennen, die der betreffenden Netzwerkkarte zugewiesen ist.

• NIC NSG – Es können bestimmte NSGs auf NIC-Ebene angewendet werden. Stellen Sie sicher, dass sich der NSG-Regelsatz für den weiterzuleitenden Datenverkehr eignet. Stellen Sie beispielsweise sicher, dass die Ports 5201 für iPerf, 3389 für RDP oder 22 für SSH geöffnet sind, sodass Testdatenverkehr weitergeleitet werden kann.

• VNet-Subnetz – Die NIC wird einem bestimmten Subnetz zugewiesen. Stellen Sie sicher, dass Sie wissen, welches Subnetz dies ist und welche Regeln diesem Subnetz zugeordnet sind.

• Subnetz-NSG – Genau wie bei der NIC können Netzwerksicherheitsgruppen auch auf Subnetzebene angewendet werden. Stellen Sie sicher, dass sich der NSG-Regelsatz für den weiterzuleitenden Datenverkehr eignet. Bei eingehendem NIC-Datenverkehr wird zuerst die Subnetz-NSG und dann die NIC-NSG angewendet. Im Gegensatz dazu wird bei ausgehendem Datenverkehr von der VM zuerst die NIC-NSG und dann die Subnetz-NSG angewendet.

• Subnetz-UDR: Benutzerdefinierte Routen (UDRs) können den Datenverkehr an einen zwischenzeitlichen Hop (z. B. eine Firewall oder einen Lastenausgleich) weiterleiten. Stellen Sie sicher, dass für Ihren Datenverkehr eine UDR vorhanden ist. In diesem Fall sollten Sie ihre Route kennen und wissen, welche Auswirkungen der nächste Hop auf den Datenverkehr hat. Eine Firewall kann z. B. einen Teil des Datenverkehrs zulassen und anderen Datenverkehr zwischen den gleichen beiden Hosts verweigern.

• Gatewaysubnetz/NSG/UDR: Genau wie das VM-Subnetz kann das Gatewaysubnetz NSGs und UDRs aufweisen. Sie sollten wissen, ob sie vorhanden sind und wie sie sich auf den Datenverkehr auswirken.

• VNET-Gateway (ExpressRoute): Nachdem das Peering (ExpressRoute) oder VPN aktiviert ist, gibt es nur wenige Einstellungen, die sich darauf auswirken, ob oder wie der Datenverkehr weitergeleitet wird. Wenn Sie über ein VNET-Gateway mit mehreren ExpressRoute-Leitungen oder VPN-Tunneln verfügen, sollten Sie die Einstellungen für die Verbindungsgewichtung beachten. Die Verbindungsgewichtung wirkt sich auf die Verbindungseinstellung aus und legt den Pfad des Datenverkehrs fest.

• Routenfilter (nicht angezeigt): Bei Verwendung von Microsoft-Peering über ExpressRoute ist ein Routenfilter erforderlich. Wenn Sie keine Routen empfangen, überprüfen Sie, ob der Routenfilter konfiguriert und ordnungsgemäß auf die Leitung angewandt wurde.

Im Folgenden wird das WAN der Verbindung behandelt. Diese Routingdomäne kann Ihr Dienstanbieter, das Unternehmens-WAN oder das Internet sein. An diesen Verbindungen sind viele Hops, Geräte und Unternehmen beteiligt. Dadurch kann die Problembehandlung erschwert werden. Sie müssen zunächst sowohl Azure als auch Ihre Unternehmensnetzwerke überprüfen, bevor Sie die Hops dazwischen untersuchen können.

In der Abbildung oben ist das Unternehmensnetzwerk ganz links dargestellt. Je nach Größe Ihres Unternehmens kann diese Routingdomäne einige Netzwerkgeräte zwischen Ihnen und dem WAN oder mehrere Ebenen von Geräten in einem Campus- oder Unternehmensnetzwerk umfassen.

Aufgrund der Komplexität dieser drei verschiedenen allgemeinen Netzwerkumgebungen empfiehlt es sich häufig, an den Rändern zu beginnen und herauszufinden, wo die Leistung gut ist und wo sie sich verschlechtert. Mithilfe dieses Ansatzes können Sie den Problembereich beim Routing zwischen den drei Elementen identifizieren. Anschließend können Sie die Problembehandlung auf die jeweilige Umgebung richten.

Tools

Die meisten Netzwerkprobleme können mit allgemeinen Tools wie Ping und Traceroute analysiert und isoliert werden. Nur in seltenen Fällen müssen Sie tiefer gehen und eine Paketanalyse mit Tools wie Wireshark durchführen.

Zur Unterstützung bei der Problembehandlung wurde das Azure Connectivity Toolkit (AzureCT) entwickelt. Es umfasst einige dieser Tools in einem einfachen Paket. Bei Leistungstests können Tools wie iPerf und PSPing Informationen zu Ihrem Netzwerk liefern. iPerf wird oft für allgemeine Leistungstests verwendet und ist einfach in der Anwendung. PSPing ist ein von SysInternals entwickeltes Ping-Tool. PSPing kann ICMP- und TCP-Pings ausführen, um einen Remotehost zu erreichen. Bei beiden handelt es sich um einfache Tools, die lediglich durch Kopieren der Dateien in ein Verzeichnis auf dem Host „installiert“ werden.

Diese Tools und Methoden sind in einem PowerShell-Modul (AzureCT) zusammengefasst, das Sie installieren und verwenden können.

AzureCT – das Azure Connectivity Toolkit

Das AzureCT-PowerShell-Modul enthält zwei Komponenten: Verfügbarkeitstests und Leistungstests. Der Schwerpunkt dieses Dokuments liegt auf Leistungstests, insbesondere auf den beiden Befehlen zur Verbindungsleistung in diesem PowerShell-Modul.

Die Verwendung des Toolkits für Leistungstests erfolgt in drei grundlegenden Schritten:

1. Installieren des PowerShell-Moduls

   (new-object Net.WebClient).DownloadString("https://aka.ms/AzureCT") | Invoke-Expression
   

   Mit diesem Befehl wird das PowerShell-Modul heruntergeladen und lokal installiert.

2. Installieren der unterstützenden Anwendungen

   Install-LinkPerformance
   

   Mit diesem AzureCT-Befehl werden iPerf und PSPing im neuen Verzeichnis C:\ACTTools installiert. Außerdem werden die Windows-Firewallports geöffnet, um Datenverkehr über ICMP und Port 5201 (iPerf) zuzulassen.

3. Ausführen des Leistungstests

   Zunächst installieren Sie auf dem Remotehost iPerf im Servermodus und führen das Tool aus. Stellen Sie sicher, dass der Remotehost an Port 3389 (RDP für Windows) oder Port 22 (SSH für Linux) lauscht und Datenverkehr an Port 5201 für iPerf zulässt. Wenn der Remotehost ein Windows-Remotehost ist, installieren Sie AzureCT, und führen Sie den Befehl „Install-LinkPerformance“ aus, um iPerf und die erforderlichen Firewallregeln einzurichten.

   Öffnen Sie nach dem Einrichten des Remotecomputers PowerShell auf dem lokalen Computer, und starten Sie den Test:

   Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 10
   

   Mit diesem Befehl wird eine Reihe gleichzeitiger Auslastungs- und Latenztests ausgeführt, um die Bandbreitenkapazität und Latenz der Netzwerkverbindung zu schätzen.

4. Überprüfen der Testausgabe

   Das Format der PowerShell-Ausgabe sieht in etwa wie folgt aus:

   

   Die detaillierten Ergebnisse aller iPerf- und PSPing-Tests werden in einzelnen Textdateien im Verzeichnis der AzureCT-Tools unter C:\ACTTools gespeichert.

Problembehandlung

Wenn die Ergebnisse der Leistungstests nicht Ihren Erwartungen entsprechen, gehen Sie systematisch vor, um das Problem zu identifizieren. Angesichts der Anzahl der Komponenten im Pfad ist ein schrittweiser Prozess effektiver als zufällige Tests.

Hinweis

In diesem Szenario handelt es sich um ein Leistungsproblem und um kein Verbindungsproblem. Informationen zum Isolieren von Konnektivitätsproblemen mit dem Azure-Netzwerk finden Sie im Artikel Überprüfen der ExpressRoute-Konnektivität.

1. Hinterfragen von Annahmen

   Stellen Sie sicher, dass Ihre Erwartungen realistisch sind. Bei einer ExpressRoute-Verbindung mit 1 GBit/s und einer Latenz von 100 ms ist es z. B. nicht realistisch, angesichts der Leistungsmerkmale von TCP über Verbindungen mit hoher Latenz von einem Datenverkehr im vollen Umfang von 1 GBit/s auszugehen. Weitere Annahmen zur Leistung finden Sie im Abschnitt Referenzen.

2. Am Rand des Netzwerks starten

   Beginnen Sie an den Rändern zwischen den Routingdomänen, und versuchen Sie, das Problem auf eine einzelne wesentliche Routingdomäne einzugrenzen. Vermeiden Sie, die „Black Box“ im Pfad ohne gründliche Untersuchung als Ursache zu benennen, da dies die Problemlösung verzögern kann.

3. Erstellen eines Diagramms

   Zeichnen Sie ein Diagramm des in Frage kommenden Bereichs, um das Problem methodisch durchzuarbeiten und zu isolieren. Planen Sie Testpunkte, und aktualisieren Sie das Diagramm, wenn Sie Bereiche ausschließen können oder Elemente genauer analysieren.

4. „Teile und herrsche“

   Segmentieren Sie das Netzwerk, und schränken Sie das Problem ein. Identifizieren Sie, wo alles funktioniert und wo nicht, und verschieben Sie Ihre Testpunkte, um die problematische Komponente zu isolieren.

5. Berücksichtigen aller OSI-Ebenen

   Auch wenn sich häufig auf das Netzwerk und die Schichten 1–3 (Bitübertragungsschicht, Datenschicht und Vermittlungsschicht) konzentriert wird, bedenken Sie, dass die Probleme auch in Schicht 7 (Anwendungsschicht) auftreten können. Bleiben Sie offen, und überprüfen Sie alle Annahmen.

Erweiterte ExpressRoute-Problembehandlung

Wenn Sie nicht sicher sind, wo sich der Rand der Cloud tatsächlich befindet, kann die Isolierung der Azure-Komponenten eine Herausforderung darstellen. Bei ExpressRoute ist der Rand die Netzwerkkomponente Microsoft Enterprise Edge (MSEE). MSEE ist der erste Kontaktpunkt im Microsoft-Netzwerk und der letzte Hop beim Verlassen des Microsoft-Netzwerks. Wenn Sie eine Verbindung zwischen dem VNET-Gateway und der ExpressRoute-Leitung erstellen, stellen Sie eine Verbindung mit MSEE her. MSEE als ersten oder letzten Hop zu erkennen, ist für die Isolierung eines Netzwerkproblems in Azure entscheidend. Wenn Sie die Richtung des Datenverkehrs kennen, können Sie ermitteln, ob das Problem in Azure oder außerhalb im WAN oder im Unternehmensnetzwerk seinen Ursprung hat.

Hinweis

MSEE befindet sich nicht in der Azure-Cloud. ExpressRoute befindet sich am Rand des Microsoft-Netzwerks und nicht in Azure. Nachdem Sie mit ExpressRoute eine Verbindung mit MSEE hergestellt haben, ist eine Verbindung mit dem Microsoft-Netzwerk vorhanden. Dies ermöglicht den Zugriff auf Clouddienste wie Microsoft 365 (mit Microsoft-Peering) oder Azure (mit privatem Peering und/oder Microsoft-Peering).

Wenn zwei VNets mit derselben ExpressRoute-Leitung verbunden sind, können Sie Tests ausführen, um das Problem in Azure zu isolieren.

Testplan

1. Führen Sie den Test „Get-LinkPerformance“ zwischen VM1 und VM2 aus. Dieser Test bietet einen Einblick, ob es sich um ein lokales Problem handelt. Wenn bei dem Test akzeptable Latenz- und Bandbreitenergebnisse zurückgegeben werden, können Sie das lokale VNet als problemfrei markieren.

2. Vorausgesetzt, dass der lokale VNet-Datenverkehr gut ist, führen Sie den Test „Get-LinkPerformance“ zwischen VM1 und VM3 aus. Bei diesem Test wird die Verbindung über das Microsoft-Netzwerk nach unten bis zum MSEE und zurück in Azure geprüft. Wenn bei dem Test akzeptable Latenz- und Bandbreitenergebnisse zurückgegeben werden, können Sie das Azure-Netzwerk als problemfrei markieren.

3. Wenn Azure ausgeschlossen werden konnte, führen Sie ähnliche Tests für das Unternehmensnetzwerk durch. Wenn auch diese Tests gute Ergebnisse liefern, wenden Sie sich an Ihren Dienstanbieter oder Internetdienstanbieter, um eine Diagnose der WAN-Verbindung durchzuführen. Führen Sie beispielsweise Tests zwischen zwei Filialen oder zwischen Ihrem Computer und einem Server im Rechenzentrum durch. Suchen Sie Endpunkte (z. B. Server oder Client-PCs), über die dieser Pfad geprüft werden kann.

Wichtig

Notieren Sie für jeden Test die Uhrzeit, und zeichnen Sie die Ergebnisse zentral auf. Jeder Testlauf sollte eine identische Ausgabe aufweisen, um die Daten einheitlich vergleichen zu können. Die Konsistenz über mehrere Tests hinweg ist der Hauptgrund für die Verwendung von AzureCT zur Problembehandlung. Der Schlüssel ist, jedes Mal konsistente Test- und Datenausgaben zu erhalten. Die Aufzeichnung der Zeit und konsistente Daten sind besonders nützlich, wenn das Problem sporadisch auftritt. Wenn Sie im Vorfeld eine sorgfältige Datensammlung durchführen, vermeiden Sie stundenlange Wiederholungstests derselben Szenarien.

Das Problem ist isoliert, was nun?

Je genauer Sie das Problem isolieren, desto schneller kann eine Lösung gefunden werden. Irgendwann erreichen Sie den Punkt, an dem Sie die Problembehandlung nicht weiter fortsetzen können. Sie können z. B. sehen, dass die Verbindung über Ihren Dienstanbieter Hops in Europa umfasst, während der erwartete Pfad vollständig in Asien liegt. Wenden Sie sich an dieser Stelle an jemanden, der mit der Routingdomäne arbeitet, auf der Sie das Problem isoliert haben. Das Eingrenzen auf eine bestimmte Komponente ist noch besser.

Bei Problemen mit dem Unternehmensnetzwerk kann Ihre interne IT-Abteilung oder Ihr Dienstanbieter bei der Gerätekonfiguration oder Hardwarereparatur helfen.

Teilen Sie bei WAN-Problemen Ihre Testergebnisse mit Ihrem Dienstanbieter oder ISP, um ihn bei der Analyse zu unterstützen und redundante Aufgaben zu vermeiden. Möglicherweise möchten diese Anbieter Ihre Ergebnisse anhand des Prinzips Vertrauen ist gut – Kontrolle ist besser überprüfen.

Bei Problemen in Azure sollte nach der möglichst detaillierten Isolierung des Problems die Dokumentation zum Azure-Netzwerk zurate gezogen und dann bei Bedarf ein Supportticket erstellt werden.

References

Erwartungen im Hinblick auf Latenz und Bandbreite

Tipp

Der geografische Abstand zwischen Endpunkten ist der größte Faktor bei der Latenz. Während die Latenz der Geräte (physische und virtuelle Komponenten, Anzahl der Hops usw.) ebenfalls eine Rolle spielt, ist die Länge der Faserleitung, nicht die Luftlinienentfernung, der primäre Faktor. Es ist schwer, diese Entfernung genau zu messen, daher verwenden wir oft einen Stadtabstandsrechner für eine grobe Schätzung.

Wir haben zum Beispiel eine ExpressRoute in Seattle, Washington in den USA eingerichtet. Die folgende Tabelle zeigt die Latenz und Bandbreite, die beim Testen an verschiedenen Azure-Standorten beobachtet wird, zusammen mit den geschätzten Entfernungen.

Testeinrichtung:

• Ein physischer Server unter Windows Server 2016 mit einer Netzwerkkarte von 10 GBit/s ist mit einer ExpressRoute-Verbindung verbunden.

• Eine Premium-ExpressRoute-Verbindung mit 10 Gbps und aktiviertem privatem Peering.

• Ein virtuelles Azure-Netzwerk mit einem UltraPerformance-Gateway befindet sich in der angegebenen Region.

• Eine DS5v2-VM, auf der Windows Server 2016 im virtuellen Netzwerk ausgeführt wird, unter Verwendung des Azure-Standardimages mit installiertem AzureCT.

• Alle Tests wurden mithilfe des AzureCT-Befehls „Get-LinkPerformance“ mit jeweils einem 5-Minuten-Auslastungstest bei jedem der sechs Testläufe ausgeführt. Zum Beispiel:

  Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 300
  

• Der Datenfluss für jeden Test erfolgte vom lokalen Server (iPerf-Client in Seattle) zur Azure-VM (iPerf-Server in der aufgeführten Azure-Region).

• Die Daten in der Spalte „Latenz“ stammen vom Test „No Load“ (ein Test der TCP-Latenz ohne Ausführung von iPerf).

• Die Daten der Spalte „Maximum Bandbreite“ stammen vom 16-TCP-Flussauslastungstest mit einer Fenstergröße von 1 MB.

Ergebnisse für Latenz/Bandbreite

Wichtig

Diese Zahlen dienen nur zur allgemeinen Referenz. Viele Faktoren beeinflussen die Latenz. Und obwohl diese Werte im Zeitverlauf im Allgemeinen konsistent sind, können sich die Bedingungen im Azure-Netzwerk oder im Netzwerk des Dienstanbieters ändern, wodurch Latenz und Bandbreite beeinflusst werden. Grundsätzlich führen diese Änderungen zu keinen wesentlichen Unterschieden.

ExpressRoute Speicherort	Azure-Region	Geschätzte Entfernung (km)	Latency	1 Sitzungsbandbreite	Maximalbandbreite
Seattle	USA, Westen 2	191 km	5 ms	262 MBit/s	3,74 GBit/s
Seattle	USA (Westen)	1\.094 km	18 ms	82,3 MBit/s	3,7 GBit/s
Seattle	USA (Mitte)	2\.357 km	40 ms	38,8 MBit/s	2,55 GBit/s
Seattle	USA Süd Mitte	2\.877 km	51 ms	30,6 MBit/s	2,49 GBit/s
Seattle	USA Nord Mitte	2\.792 km	55 ms	27,7 MBit/s	2,19 GBit/s
Seattle	USA (Ost) 2	3\.769 km	73 ms	21,3 MBit/s	1,79 GBit/s
Seattle	East US	3\.699 km	74 ms	21,1 MBit/s	1,78 GBit/s
Seattle	Japan, Osten	7\.705 km	106 ms	14,6 MBit/s	1,22 GBit/s
Seattle	UK, Süden	7\.708 km	146 ms	10,6 MBit/s	896 MBit/s
Seattle	Europa, Westen	7\.834 km	153 ms	10,2 MBit/s	761 MBit/s
Seattle	Australien (Osten)	12.484 km	165 ms	9,4 MBit/s	794 MBit/s
Seattle	Asien, Südosten	12.989 km	170 ms	9,2 MBit/s	756 MBit/s
Seattle	Brasilien, Süden *	10.930 km	189 ms	8,2 MBit/s	699 MBit/s
Seattle	Indien (Süden)	12.918 km	202 ms	7,7 MBit/s	634 MBit/s

* Die Latenz für Brasilien ist ein Beispiel dafür, dass sich die Luftlinienentfernung erheblich von der Länge der Faserstrecke unterscheiden kann. Die erwartete Latenz wäre etwa 160 ms, beträgt aber tatsächlich 189 ms aufgrund der längeren Faserroute.

Hinweis

Diese Werte wurden mithilfe von AzureCT basierend auf iPerf in Windows über PowerShell getestet. iPerf berücksichtigt nicht die standardmäßigen Windows-TCP-Optionen für den Skalierungsfaktor und verwendet eine niedrigere Umschaltanzahl für die TCP-Fenstergröße. Durch die Optimierung von iPerf-Befehlen mit dem -w-Switch und einer größeren TCP-Fenstergröße kann ein besserer Durchsatz erreicht werden. Das Ausführen von iPerf im Multithreadmodus von mehreren Computern kann auch dazu beitragen, die maximale Verbindungsleistung zu erreichen. Um die besten iPerf-Ergebnisse unter Windows zu erhalten, verwenden Sie „Set-NetTCPSetting -AutoTuningLevelLocal Experimental“. Überprüfen Sie ihre Organisationsrichtlinien, bevor Sie Änderungen vornehmen.

Nächste Schritte

• Laden Sie das Azure Connectivity Toolkit (AzureCT) herunter.
• Befolgen Sie die Anweisungen zum Testen der Verbindungsleistung.