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 Groß- und Kleinkunden 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.

Hier erfahren Sie, wie Sie die Netzwerklatenz und Bandbreite zwischen zwei Hosts einfach und konsistent testen können. Außerdem erhalten Sie einige Hinweise zu unterschiedlichen Möglichkeiten der Untersuchung des Azure-Netzwerks zum Isolieren von Problempunkten. 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 Windows Desktop-Host 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: Auf NIC-Ebene werden möglicherweise spezifische Netzwerksicherheitsgruppen (NSGs) angewendet. 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 Netzwerkkarte ist einem bestimmten Subnetz zugewiesen. Stellen Sie sicher, dass Sie das Subnetz und die diesem Subnetz zugeordneten Regeln kennen.

• Subnetz-NSG: Genau wie bei der Netzwerkkarte können Netzwerksicherheitsgruppen auch auf das Subnetz angewendet werden. Stellen Sie sicher, dass sich der NSG-Regelsatz für den weiterzuleitenden Datenverkehr eignet. Auf den eingehenden Datenverkehr an der Netzwerkkarte wird zuerst die Subnetz-NSG und dann die NIC-NSG angewendet. Auf den ausgehenden Datenverkehr von der VM wird 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.

Angesichts der Komplexität dieser drei unterschiedlichen Netzwerkumgebungen auf hoher Ebene empfiehlt es sich oftmals, an den Kanten zu beginnen und zu ermitteln, 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 PowerShell-Modul AzureCT enthält zwei Komponenten: Verfügbarkeitstests und Leistungstests. Dieses Dokument befasst sich nur mit Leistungstests. Daher konzentrieren wir uns auf die zwei Befehle 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 Sie die Hilfsanwendungen.

   Install-LinkPerformance
   

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

3. Führen Sie den Leistungstest aus.

   Zunächst müssen Sie auf dem Remotehost iPerf im Servermodus installieren und ausführen. Stellen Sie zudem sicher, dass der Remotehost auf Port 3389 (RDP für Windows) oder Port 22 (SSH für Linux) lauscht und für iPerf Datenverkehr auf Port 5201 zulässt. Wenn auf dem Remotehost Windows ausgeführt wird, installieren Sie AzureCT, und führen Sie den Befehl „Install-LinkPerformance“ aus. Mit dem Befehl werden iPerf und die Firewallregeln eingerichtet, die zum erfolgreichen Starten von iPerf im Servermodus erforderlich sind.

   Ö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 Sie die Ausgabe der Tests.

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

   

   Die detaillierten Ergebnisse aller iPerf- und PSPing-Tests befinden sich in einzelnen Textdateien im Verzeichnis der AzureCT-Tools unter „C:\ACTTools“.

Problembehandlung

Wenn Sie beim Leistungstest nicht die erwarteten Ergebnisse erhalten, sollten die Gründe in einem ausführlichen Prozess untersucht werden. Aufgrund der Anzahl der Komponenten unter dem Pfad bietet ein systematisches Verfahren einen schnelleren Weg zur Lösung als unkoordinierte Tests. Durch eine systematische Problembehandlung können Sie unnötige Testwiederholungen vermeiden.

Hinweis

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

Wägen Sie zunächst Ihre Annahmen ab. Ist Ihre Erwartung angemessen? Dies ist beispielsweise der Fall, wenn Sie bei einer ExpressRoute-Leitung mit 1 GBit/s eine Latenz von 100 ms erzielen. Es kann nicht davon ausgegangen werden, dass beim Datenverkehr die gesamten 1 GBit/s erreicht werden. Dies liegt auch an den Leistungsmerkmalen von TCP über Verbindungen mit hoher Latenz. Weitere Annahmen zur Leistung finden Sie im Abschnitt Referenzen.

Als Nächstes empfiehlt es sich, an den Rändern zwischen den Routingdomänen zu beginnen und zu versuchen, das Problem auf eine einzelne große Routingdomäne einzugrenzen. Sie können mit dem Unternehmensnetzwerk, dem WAN oder dem Azure-Netzwerk beginnen. Häufig geben Benutzer der „Blackbox“ im Pfad die Schuld. Dies ist zwar sehr einfach, kann aber die Lösung erheblich verzögern. Das gilt besonders dann, wenn das Problem in einem Bereich auftritt, in dem Sie Änderungen vornehmen können, um das Problem zu beheben. Leiten Sie das Problem erst an Ihren Dienstanbieter oder Internetdienstanbieter weiter, nachdem Sie es eingehend geprüft haben.

Nachdem Sie die wesentliche Routingdomäne identifiziert haben, in der das Problem aufzutreten scheint, sollten Sie ein Diagramm des betreffenden Bereichs erstellen. Wenn Sie ein Diagramm zeichnen, können Sie das Problem methodisch durcharbeiten und isolieren. Sie können Testpunkte planen und die Karte aktualisieren, wenn Sie im Verlauf der Tests bestimmte Bereiche ausschließen oder in tiefere Bereiche vordringen.

Unterteilen Sie im erstellten Diagramm das Netzwerk in Segmente, und grenzen Sie das Problem ein. Finden Sie heraus, wo es funktioniert und wo nicht. Verändern Sie die Testpunkte fortlaufend, um die betreffende Komponente zu identifizieren.

Vergessen Sie auch nicht, andere Schichten des OSI-Modells zu überprüfen. Es genügt möglicherweise nicht, sich auf das Netzwerk und die Schichten 1–3 (Bitübertragungsschicht, Datenschicht und Vermittlungsschicht) zu konzentrieren, die Probleme können auch in der Anwendungsschicht (Schicht 7) auftreten. Bleiben Sie offen, und überprüfen Sie Ihre 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 Verwendung von ExpressRoute ist der Rand die Netzwerkkomponente Microsoft Enterprise Edge (MSEE). Bei Verwendung von ExpressRoute ist MSEE der erste Kontaktpunkt im Microsoft-Netzwerk und der letzte Hop beim Verlassen des Microsoft-Netzwerks. Wenn Sie ein Verbindungsobjekt zwischen dem VNET-Gateway und der ExpressRoute-Leitung erstellen, stellen Sie eigentlich eine Verbindung mit MSEE her. MSEE als ersten oder letzten Hop (je nach Richtung des Datenverkehrs) anzunehmen, ist für die Isolierung eines Netzwerkproblems in Azure entscheidend. Wenn Sie die Richtung kennen, können Sie ermitteln, ob das Problem in Azure oder außerhalb im WAN oder im Unternehmensnetzwerk seinen Ursprung hat.

Hinweis

Beachten Sie, dass sich MSEE nicht in der Azure-Cloud befindet. ExpressRoute befindet sich am Rand des Microsoft-Netzwerks und nicht in Azure. Nachdem Sie mit ExpressRoute eine Verbindung mit einem MSEE hergestellt haben, wird eine Verbindung mit dem Microsoft-Netzwerk hergestellt. Von hier aus gelangen Sie zu allen Clouddiensten, z. B. zu 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 eine Reihe von 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 diesem Test akzeptable Latenz- und Bandbreitenergebnisse zurückgegeben werden, können Sie das lokale VNet als gut 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 diesem Test akzeptable Latenz- und Bandbreitenergebnisse zurückgegeben werden, können Sie das Azure-Netzwerk als gut markieren.

3. Wenn Azure ausgeschlossen werden konnte, können Sie eine ähnliche Testreihe für das Unternehmensnetzwerk durchführen. Wenn auch diese Tests gute Ergebnisse liefern, ist es an der Zeit, dass Sie sich an Ihren Dienstanbieter oder Internetdienstanbieter wenden, um eine Diagnose der WAN-Verbindung durchzuführen. Beispiel: Führen Sie diesen Test zwischen zwei Filialen oder zwischen Ihrem Computer und einem Server im Rechenzentrum durch. Abhängig davon, was Sie testen, suchen Sie Endpunkte (z. B. Server oder Kunden-PCs), über die dieser Pfad geprüft werden kann.

Wichtig

Es ist wichtig, dass Sie für jeden Test die Uhrzeit notieren, zu der der Test durchgeführt wird, und dass Sie die Ergebnisse an einem zentralen Speicherort aufzeichnen. Jeder Testlauf sollte identische Ausgaben zurückgeben, sodass Sie die Ergebnisdaten der einzelnen Testläufe vergleichen können und in den Daten keine Lücken entstehen. Der Hauptgrund zur Verwendung von AzureCT für die Fehlersuche ist die testübergreifende Konsistenz. Der Schlüssel zum Erfolg sind dabei nicht die genauen Lastszenarien, die wir ausführen, sondern vielmehr die Tatsache, dass wir bei jedem einzelnen Test eine konsistente Test- und Datenausgabe erhalten. Die Aufzeichnung der Zeit und konsistente Daten bei jeder Ausführung sind besonders nützlich, wenn sich später herausstellt, dass das Problem sporadisch auftritt. Wenn Sie im Vorfeld eine sorgfältige Datenerfassung durchführen, vermeiden Sie stundenlange Wiederholungstests derselben Szenarien.

Das Problem ist isoliert, was nun?

Je weiter 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. An diesem Punkt sollten Sie anderweitig Unterstützung suchen. Wen Sie fragen können, hängt vom Routingbereich ab, in dem Sie das Problem isolieren konnten. Wenn Sie es auf eine bestimmte Komponente eingrenzen können, ist das sogar noch besser.

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

Eine bewährte Methode für die Problembehandlung beim WAN besteht darin, die Testergebnisse an Ihren Dienstanbieter oder ISP weiterzuleiten, da diese bei ihrer Arbeit hilfreich sein können. Mit Ihren Testergebnissen können Sie auch vermeiden, dass Sie die gleichen Aufgaben, die Sie bereits erledigt haben, noch einmal ausführen. Es kann jedoch sein, dass sie Ihre Ergebnisse selbst überprüfen möchten. Dies basiert auf dem Prinzip Vertrauen ist gut – Kontrolle ist besser.

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 geöffnet werden.

References

Erwartungen im Hinblick auf Latenz und Bandbreite

Tipp

Die geografische Latenz (Meilen oder Kilometer) zwischen den getesteten Endpunkten macht bei Weitem den größten Teil der Latenz aus. Auch wenn Latenz zwischen Geräten (physische und virtuelle Komponenten, Anzahl der Hops usw.) zu verzeichnen ist, hat sich in Bezug auf WAN-Verbindungen die geografische Latenz als wichtigster Aspekt der gesamten Latenz erwiesen. Dabei ist auch zu beachten, dass es sich bei der Entfernung um die Entfernung der Faserstrecke und nicht um die Luftlinie oder die Entfernung nach Karte handelt. Diese Entfernung ist unglaublich schwierig genau zu bestimmen. Daher verwenden wir in der Regel einen Entfernungsrechner im Internet. Diese Messung ist zwar sehr ungenau, aber sie reicht aus, um eine allgemeine Erwartung zu formulieren.

Wir haben zum Beispiel eine ExpressRoute-Dienst in Seattle, Washington in den USA eingerichtet. In der nachfolgenden Tabelle sind die Werte für Latenz und Bandbreite aufgeführt, die sich bei Tests von verschiedenen Azure-Standorten ergaben. Die geografische Entfernung zwischen den Endpunkten für den Test wurde geschätzt.

Testeinrichtung:

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

• Eine ExpressRoute-Premium-Verbindung mit 10 GBit/s im identifizierten Standort ist mit privaten Peering aktiviert.

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

• Ein virtueller DS5v2-Computer unter Windows Server 2016 befindet sich im VNet. Die VM war nicht in die Domäne eingebunden und wurde über das Azure-Standardimage erstellt (keine Optimierung oder Anpassung); AzureCT war installiert.

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

  Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 300
  

• Beim Datenfluss für jeden Test wurde die Last vom lokalen physischen Server (iPerf-Client in Seattle) bis zum virtuellen Azure-Computer (iPerf-Server in der aufgeführten Azure-Region) geleitet.

• 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-Fluss-Auslastungstest 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, kann der Datenverkehr aufgrund bestimmter Bedingungen im Azure-Netzwerk oder dem Netzwerk der Dienstanbieter jederzeit über andere Pfade weitergeleitet werden, sodass dadurch die Latenz und Bandbreite beeinflusst werden. Grundsätzlich führen diese Änderungen zu keinen wesentlichen Unterschieden.

ExpressRoute Position	Azure Region	Geschätzte Entfernung (km)	Latency	1 Sitzung: Bandbreite	Maximum Bandbreite
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 gutes Beispiel dafür, dass sich die Luftlinie erheblich von der Entfernung der Faserstrecke unterscheiden kann. Die Latenz sollte ungefähr bei 160 ms liegen, tatsächlich sind es aber 189 ms. Der Unterschied bei der Latenz könnte ein Hinweis auf ein Netzwerkproblem sein. In der Realität verläuft das Glasfaserkabel nach Brasilien aber nicht in einer geraden Linie. Sie sollten also für die Strecke von Brasilien nach Seattle einen zusätzlichen Weg von ca. 1.000 km einberechnen.

Hinweis

Obwohl diese Zahlen berücksichtigt werden sollten, wurden sie mit AzureCT getestet, das auf IPERF in Windows über PowerShell basiert. In diesem Szenario berücksichtigt IPERF nicht die standardmäßigen Windows-TCP-Optionen für Skalierungsfaktor und verwendet eine viel niedrigere Umschaltanzahl für die TCP-Fenstergröße. Die hier dargestellten Zahlen wurden mit IPERF-Standardwerten ausgeführt und dienen nur der allgemeinen Referenz. Durch die Optimierung von IPERF-Befehlen mit -w-Switch und einer großen TCP-Fenstergröße kann über Langstrecken ein besserer Durchsatz erzielt werden, was deutlich bessere Durchsatzzahlen zeigt. Um sicherzustellen, dass eine ExpressRoute die volle Bandbreite nutzt, ist es ideal, die IPERF-Option in Multithreading gleichzeitig von mehreren Computern auszuführen, um sicherzustellen, dass die Rechenkapazität die maximale Linkleistung erreichen kann und nicht durch die Verarbeitungskapazität einer einzelnen VM eingeschränkt wird. Um die besten Iperf-Ergebnisse unter Windows zu erhalten, verwenden Sie „Set-NetTCPSetting -AutoTuningLevelLocal Experimental“. Bitte ü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.