Beheben von Problemen bei der Netzwerkleistung

Übersicht

Azure bietet stabile und schnelle Möglichkeiten für Verbindungen über das lokale Netzwerk mit Azure. 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.

Sie erfahren, 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 und 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.

Hinweis

Das Vorgehen bei der Problembehandlung sowie die verwendeten Tools und Methoden können nach persönlichen Vorlieben gewählt werden. In diesem Dokument werden der Ansatz und die Tools erläutert, die ich häufig verwende. Ihr Ansatz unterscheidet sich wahrscheinlich. Nichts spricht gegen unterschiedliche Ansätze zur Behebung von Problemen. Wenn Sie jedoch noch keinen Ansatz etabliert haben, kann Ihnen dieses Dokument als Einstieg für eigene Methoden, Tools und Präferenzen bei der Behebung von Netzwerkproblemen dienen.

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. 1

Auf der obersten Ebene beschreibe ich drei wesentliche Netzwerkroutingdomänen:

  • das Azure-Netzwerk (blaue Cloud rechts)
  • das Internet oder WAN (grüne Cloud in der Mitte)
  • das Unternehmensnetzwerk (orangefarbene Cloud links)

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

  • VM: Der Server verfügt möglicherweise über mehrere Netzwerkkarten (NICs). 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. Ich verwende normalerweise einen virtuellen DS5v2-Computer zum Testen (und lösche ihn nach dem Testen, um Geld zu sparen), um ausreichend Bandbreite auf dem virtuellen Computer sicherzustellen.
  • 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. (Bei eingehendem Datenverkehr an der Netzwerkkarte wird zuerst die Subnetz-NSG und dann die NIC-NSG angewendet. Bei Datenverkehr, der vom virtuellen Computer ausgeht, 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; 2) Installieren der Hilfsanwendungen iPerf und PSPing; 3) Ausführen des Leistungstests.

  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 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. Ausführen des Leistungstests

    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 der Ausgabe der Tests

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

    4

    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 entlang des Pfads bietet ein systematisches Verfahren einen schnelleren Weg zur Auflö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. Wenn überhaupt kein Datenverkehr weitergeleitet wird, werden andere Schritte ausgeführt.

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 Kanten zwischen den Routingdomänen zu versuchen, das Problem auf eine einzelne wesentliche 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 Auflö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. Durch Zeichnen eines Diagramms auf einem Whiteboard, in einem Editor oder in Visio 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-Verbindung 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.

2

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 Tageszeit notieren, zu der der Test durchgeführt wird, und dass Sie die Ergebnisse in einem allgemeinen Speicherort speichern (z.B. OneNote oder Excel). 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, warum ich AzureCT zur Problembehandlung verwende, ist die Konsistenz über mehrere Tests hinweg. Das Geheimnis liegt nicht in den exakten ausgeführten Auslastungsszenarien, sondern stattdessen wichtig ist die Tatsache, dass ich eine konsistente Test- und Datenausgabe in jedem einzelnen Test erhalte. 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 bei der Datenerfassung gewissenhaft sind, ersparen Sie sich viele Stunden, in denen Sie dieselben Szenarien wieder und wieder testen (das habe ich vor vielen Jahren am eigenen Leib erfahren müssen).

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.

Beim WAN können Sie Ihre Testergebnisse an Ihren Dienstanbieter oder Internetdienstanbieter weitergeben, da diese Informationen bei den ersten Schritten helfen. Außerdem verhindern Sie damit, dass Arbeit, die Sie bereits ausgeführt haben, erneut erledigt werden muss. Nehmen Sie es nicht persönlich, wenn sie Ihre Ergebnisse selbst überprüfen möchten. „Vertrauen ist gut – Kontrolle ist besser“ ist ein gutes Motto bei der Problembehandlung basierend auf den Testergebnissen von anderen Personen.

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 verwende ich im Allgemeinen einen Entfernungsrechner im Internet. Dabei bin ich mir bewusst, dass dies eine sehr ungenaue Methode ist, die für eine allgemeine Erwartung aber ausreicht.

Ich habe einen ExpressRoute-Dienst in Seattle, Washington in den USA eingerichtet. In der nachfolgenden Tabelle sind die Werte für die Latenz und Bandbreite aufgeführt, die sich bei Tests von verschiedenen Azure-Standorten ergaben. Die geografische Entfernung zwischen jedem Ende des Tests habe ich 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 Azure-VNET mit einem UltraPerformance-Gateway befindet sich in der angegebenen Region.

  • Ein virtueller DS5v2-Computer unter Windows Server 2016 befindet sich im VNET. Der virtuelle Computer 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.

3

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.

Nächste Schritte

  1. Laden Sie das Azure Connectivity Toolkit von GitHub unter https://aka.ms/AzCT herunter.
  2. Befolgen Sie die Anweisungen zum Testen der Verbindungsleistung.