Netzwerkleistungsprobleme beheben

Zusammenfassung

Azure bietet eine stabile und schnelle Möglichkeit, Ihr lokales Netzwerk mit Azure zu verbinden. Methoden wie Site-to-Site VPN und ExpressRoute werden erfolgreich von Kunden aller Größen verwendet, um ihre Unternehmen in Azure zu führen. Aber was geschieht, wenn die Leistung nicht Ihren Erwartungen oder ihrer vorherigen Erfahrung entspricht? Dieser Artikel kann dabei helfen, die Art und Weise zu standardisieren, wie Sie Ihre spezifische Umgebung testen und basisieren.

Sie erfahren, wie Sie die Netzwerklatenz und Bandbreite zwischen zwei Hosts einfach und konsistent testen. Darüber hinaus erhalten Sie Ratschläge zu Möglichkeiten, das Azure Netzwerk zu betrachten, um Problempunkte zu isolieren. Für das beschriebene PowerShell-Skript und die erläuterten Tools sind zwei Hosts im Netzwerk erforderlich (am Ende der getesteten Verknüpfung). Ein Host muss ein Windows Server oder Desktop sein, und der andere kann entweder Windows oder Linux sein.

Netzwerkkomponenten

Bevor Sie sich mit der Problembehandlung befassen, befassen wir uns mit einigen allgemeinen Begriffen und Komponenten. Diese Diskussion stellt sicher, dass wir über jede Komponente in der End-to-End-Kette nachdenken, die konnektivität in Azure ermöglicht.

Auf der höchsten Ebene gibt es drei hauptnetzwerkweiterleitungsdomänen:

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

Wenn Sie das Diagramm von rechts nach links betrachten, befassen wir uns kurz mit den einzelnen Komponenten:

• Virtueller Computer – Der Server verfügt möglicherweise über mehrere NICs. Stellen Sie sicher, dass statische Routen, Standardrouten und die Einstellungen des Betriebssystems den Datenverkehr so senden und empfangen, wie Sie es erwarten. Außerdem weist jede VM-SKU eine Bandbreiteneinschränkung auf. Wenn Sie eine kleinere VM-SKU verwenden, ist ihr Datenverkehr durch die bandbreite beschränkt, die für die NIC verfügbar ist. Wir empfehlen die Verwendung eines DS5v2 zum Testen, um eine angemessene Bandbreite auf dem virtuellen Computer sicherzustellen.

• NIC – Stellen Sie sicher, dass Sie die private IP kennen, die der NIC zugeordnet ist.

• NIC NSG - Es können bestimmte NSGs auf NIC-Ebene angewendet werden. Stellen Sie sicher, dass der NSG-Regelsatz für den Datenverkehr geeignet ist, den Sie übergeben möchten. Stellen Sie sicher, dass die Ports 5201 für iPerf, 3389 für RDP oder 22 für SSH geöffnet sind, damit der Testdatenverkehr durchgeleitet werden kann.

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

• Subnetz-NSG – Genau wie die NIC können auch NSGs auf Subnetzebene angewendet werden. Stellen Sie sicher, dass der NSG-Regelsatz für den Datenverkehr geeignet ist, den Sie übergeben möchten. Für Datenverkehr, der an die NIC eintrifft, gilt zuerst das Subnetz NSG, dann die NIC NSG. Wenn der Datenverkehr von der VM ausgehend ist, wird zuerst das NIC-NSG und dann das Subnetz-NSG angewendet.

• Subnetz-UDR – User-Defined Routes können den Datenverkehr zu einem Zwischensprung leiten (z. B. zu einer Firewall oder einem Load Balancer). Stellen Sie sicher, dass Sie wissen, ob ein UDR für Ihren Datenverkehr vorhanden ist. Wenn ja, verstehen Sie, wohin es führt und was der nächste Hop für Ihren Netzwerkverkehr tun wird. Beispielsweise könnte eine Firewall Datenverkehr weiterleiten und anderen Datenverkehr zwischen denselben beiden Hosts abweisen.

• Gatewaysubnetz / NSG / UDR – Genau wie das VM-Subnetz kann das Gatewaysubnetz NSGs und UDRs haben. Stellen Sie sicher, dass Sie wissen, ob sie dort sind und welche Auswirkungen sie auf Ihren Datenverkehr haben.

• VNet-Gateway (ExpressRoute) – Sobald Peering (ExpressRoute) oder VPN aktiviert ist, gibt es nicht viele Einstellungen, die sich darauf auswirken können, wie oder ob Datenverkehr weitergeleitet wird. Wenn Sie über ein virtuelles Netzwerkgateway verfügen, das mit mehreren ExpressRoute-Schaltkreisen oder VPN-Tunneln verbunden ist, sollten Sie die Verbindungsgewichtungseinstellungen beachten. Die Verbindungsgewichtung beeinflusst die Verbindungspräferenz und bestimmt den Pfad, den Ihr Datenverkehr nimmt.

• 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 auf den Schaltkreis ordnungsgemäß angewendet wurde.

An diesem Punkt befinden Sie sich im WAN-Teil der Verbindung. Diese Routingdomäne kann Ihr Dienstanbieter, Ihr Unternehmens-WAN oder das Internet sein. Es gibt viele Sprünge, Geräte und Unternehmen, die mit diesen Links verknüpft sind, und das könnte die Problembehandlung erschweren. Sie müssen zuerst sowohl Azure als auch Ihre Unternehmensnetzwerke ausschließen, bevor Sie die Zwischenschritte dazwischen untersuchen können.

Im vorherigen Diagramm befindet sich ganz links Ihr Unternehmensnetzwerk. Je nach Größe Ihres Unternehmens kann es sich bei dieser Routingdomäne um ein paar Netzwerkgeräte zwischen Ihnen und dem WAN oder mehreren Ebenen von Geräten in einem Campus-/Unternehmensnetzwerk handeln.

Angesichts der Komplexität dieser drei unterschiedlichen High-Level-Netzwerkumgebungen ist es oft optimal, an den Rändern zu beginnen und zu zeigen, wo die Leistung gut ist und wo sie beeinträchtigt wird. Dieser Ansatz kann dabei helfen, die Problemroutingdomäne der drei zu identifizieren. Anschließend können Sie ihre Problembehandlung auf diese bestimmte Umgebung konzentrieren.

Werkzeuge

Die meisten Netzwerkprobleme können mithilfe grundlegender Tools wie Ping und Traceroute analysiert und isoliert werden. Es ist selten, dass Sie so tief wie eine Paketanalyse mit Tools wie Wireshark gehen müssen.

Um bei der Problembehandlung zu helfen, wurde das Azure Connectivity Toolkit (AzureCT) entwickelt, um einige dieser Tools in ein einfaches Paket zu versetzen. Für Leistungstests können Ihnen Tools wie iPerf und PSPing Informationen über Ihr Netzwerk bereitstellen. iPerf ist ein häufig verwendetes Tool für grundlegende Leistungstests und ist relativ einfach zu verwenden. PSPing ist ein von SysInternals entwickeltes Ping-Tool. PSPing kann sowohl ICMP- als auch TCP-Pings ausführen, um einen Remotehost zu erreichen. Beide Tools sind einfach und werden einfach durch Kopieren der Dateien in ein Verzeichnis auf dem Host "installiert".

Diese Tools und Methoden werden in ein PowerShell-Modul (AzureCT) eingeschlossen, das Sie installieren und verwenden können.

AzureCT – das Azure Connectivity Toolkit

Das AzureCT PowerShell-Modul enthält zwei Komponenten: Availability Testing und Performance Testing. Dieses Dokument konzentriert sich auf Leistungstests, insbesondere auf die beiden Verknüpfungsleistungsbefehle in diesem PowerShell-Modul.

Hier sind die drei grundlegenden Schritte zum Verwenden dieses Toolkits für Leistungstests:

1. Installieren des PowerShell-Moduls

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

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

2. Installieren der unterstützenden Anwendungen

   Install-LinkPerformance
   

   Dieser AzureCT-Befehl installiert iPerf und PSPing in einem neuen Verzeichnis C:\ACTTools und öffnet die Windows Firewallports, um ICMP- und Port 5201 (iPerf)-Datenverkehr zu ermöglichen.

3. Ausführen des Leistungstests

   Installieren und ausführen Sie iPerf zuerst auf dem Remotehost im Servermodus. Stellen Sie sicher, dass der Remotehost entweder auf 3389 (RDP für Windows) oder 22 (SSH für Linux) lauscht und Datenverkehr auf Port 5201 für iPerf zulässt. Wenn der Remotehost Windows ist, installieren Sie AzureCT, und führen Sie den befehl Install-LinkPerformance aus, um iPerf und die erforderlichen Firewallregeln einzurichten.

   Sobald der Remotecomputer bereit ist, öffnen Sie PowerShell auf dem lokalen Computer, und starten Sie den Test:

   Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 10
   

   Dieser Befehl führt eine Reihe gleichzeitiger Auslastungs- und Latenztests aus, um die Bandbreitenkapazität und Latenz Ihrer Netzwerkverbindung zu schätzen.

4. Überprüfen Sie die Testausgabe

   Das PowerShell-Ausgabeformat sieht ähnlich wie folgt aus:

   Screenshot der PowerShell-Ausgabe des Tests zur Linkleistung.

   Detaillierte Ergebnisse aller iPerf- und PSPing-Tests werden in einzelnen Textdateien im Verzeichnis der AzureCT-Tools unter gespeichert.

Problembehandlung

Wenn die Leistungstestergebnisse nicht erwartungsgemäß sind, folgen Sie einem systematischen Ansatz zur Identifizierung des Problems. Angesichts der Anzahl der Komponenten im Pfad ist ein schrittweiser Prozess effektiver als zufällige Tests.

1. Fordern Sie Ihre Annahmen an

   Stellen Sie sicher, dass Ihre Erwartungen realistisch sind. Bei einer ExpressRoute-Leitung mit 1 GBit/s und 100 ms Latenz ist es aufgrund der Leistungsmerkmale von TCP über Verbindungen mit hoher Latenz nicht realistisch, den gesamten Datenverkehr von 1 GBit/s zu erwarten. Weitere Informationen zu Leistungsannahmen finden Sie im Abschnitt "Verweise ".

2. Beginnen Sie am Rand des Netzwerks.

   Beginnen Sie an den Rändern zwischen Routingdomänen, und versuchen Sie, das Problem in eine einzelne Hauptroutingdomäne zu isolieren. Vermeiden Sie es, die Blackbox im Pfad zu beschuldigen, ohne eine gründliche Untersuchung durchzuführen, da dies die Auflösung verzögert.

3. Erstellen eines Diagramms

   Zeichnen Sie ein Diagramm des fraglichen Bereichs, um das Problem methodisch zu durchlaufen und zu isolieren. Planen Sie Testpunkte, und aktualisieren Sie die Karte, während Sie Bereiche löschen oder tiefer greifen.

4. Teilen und erobern

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

5. Berücksichtigen aller OSI-Ebenen

   Bei der Konzentration auf das Netzwerk und die Ebenen 1-3 (Physische, Daten und Netzwerkebenen) ist häufig zu beachten, dass Probleme auch auf Ebene 7 (Anwendungsschicht) auftreten können. Bleiben Sie offen, und überprüfen Sie alle Annahmen.

Erweiterte ExpressRoute-Problembehandlung

Das Isolieren Azure Komponenten kann schwierig sein, wenn Sie nicht sicher sind, wo sich der Rand der Cloud befindet. Bei ExpressRoute ist der Edge eine Netzwerkkomponente namens Microsoft Enterprise Edge (MSEE). Der MSEE ist der erste Kontaktpunkt im Microsoft-Netzwerk und der letzte Hop beim Verlassen. Wenn Sie eine Verbindung zwischen Ihrem virtuellen Netzwerkgateway und dem ExpressRoute-Schaltkreis erstellen, verbinden Sie sich mit dem MSEE. Die Erkennung des MSEE als erster oder letzter Hop ist entscheidend für die Isolierung eines Azure Netzwerkproblems. Wenn Sie die Datenverkehrsrichtung kennen, können Sie ermitteln, ob sich das Problem im WAN- oder Unternehmensnetzwerk Azure oder weiter nach unten befindet.

Diagramm mehrerer virtueller Netzwerke, die mit einem ExpressRoute-Schaltkreis verbunden sind.

Wenn zwei VNets mit dem same ExpressRoute-Schaltkreis verbunden sind, können Sie Tests durchführen, um das Problem in Azure zu isolieren.

Testplan

1. Führen Sie den Get-LinkPerformance Test zwischen VM1 und VM2 aus. Dieser Test liefert Einblicke darüber, ob das Problem lokal ist. Wenn der Test akzeptable Latenz- und Bandbreitenergebnisse erzeugt, können Sie das lokale virtuelle Netzwerk als gut markieren.

2. Wenn der lokale virtuelle Netzwerkdatenverkehr gut ist, führen Sie den Get-LinkPerformance Test zwischen VM1 und VM3 aus. Bei diesem Test wird die Verbindung über das Microsoft-Netzwerk bis zum MSEE und wieder in Azure durchgeführt. Wenn der Test akzeptable Latenz- und Bandbreitenergebnisse erzeugt, können Sie das Azure Netzwerk als gut markieren.

3. Wenn Azure ausgeschlossen ist, führen Sie ähnliche Tests in Ihrem Unternehmensnetzwerk durch. Wenn diese Tests ebenfalls gut sind, arbeiten Sie mit Ihrem Dienstanbieter oder ISP zusammen, um Ihre WAN-Verbindung zu diagnostizieren. Führen Sie beispielsweise Tests zwischen zwei Zweigstellen oder zwischen Ihrem Schreibtisch und einem Rechenzentrumsserver aus. Suchen Sie Endpunkte wie Server und Client-PCs, die den Testpfad ausführen können.

Das Problem ist isoliert, jetzt was?

Je mehr Sie das Problem isolieren, desto schneller kann die Lösung gefunden werden. Manchmal erreichen Sie einen Punkt, an dem Sie mit der Problembehandlung nicht fortfahren können. So kann es beispielsweise vorkommen, dass der Link über Ihren Dienstanbieter Zwischenschritte durch Europa nimmt, wenn Sie erwarten, dass er in Asien verbleibt. Wenden Sie sich an diesem Punkt an jemanden, um Hilfe zu erhalten, basierend auf der Routing-Domäne, in der Sie das Problem isoliert haben. Das Eingrenzen auf eine bestimmte Komponente ist noch besser.

Bei Problemen im 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 sie bei der Arbeit zu unterstützen und redundante Aufgaben zu vermeiden. Möglicherweise möchten sie Ihre Ergebnisse anhand des Vertrauensprinzips überprüfen, aber überprüfen.

Wenn Sie die Azure-Probleme so detailliert wie möglich isoliert haben, lesen Sie die Azure Network Documentation und eröffnen bei Bedarf ein Support-Ticket.

Verweise

Latenz-/Bandbreitenerwartungen

So richten wir beispielsweise ein ExpressRoute in Seattle, Washington, USA ein. Die folgende Tabelle zeigt die beobachtete Latenz und Bandbreite beim Testen an verschiedenen Azure-Standorten sowie die geschätzten Entfernungen.

Testsetup:

• Ein physischer Server, auf dem Windows Server 2016 mit einer NIC von 10 GBit/s ausgeführt wird, die mit einem ExpressRoute-Schaltkreis verbunden ist.

• Ein 10 Gbps Premium ExpressRoute-Schaltkreis mit aktiviertem privatem Peering.

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

• Eine VM DS5v2, auf der Windows Server 2016 im virtuellen Netzwerk ausgeführt wird, wobei das Standardmäßige Azure Image verwendet wird, auf dem AzureCT installiert ist.

• Alle Tests verwendeten den AzureCT-Get-LinkPerformance-Befehl mit einem 5-minütigen Auslastungstest für jeden der sechs Testläufe. 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).

• In der Spalte "Latenz" werden Daten aus dem Test "No Load" angezeigt (ein TCP-Latenztest ohne iPerf ausgeführt).

• In der Spalte "Max Bandwidth" werden Daten aus dem 16 TCP-Flusslasttest mit einer Fenstergröße von 1 Mb angezeigt.

Diagramm der Testumgebung, in der AzureCT installiert ist.

Latenz/Bandbreitenergebnisse

* Die Latenz nach Brasilien ist ein Beispiel, bei dem sich der Faserlaufabstand deutlich vom geraden Abstand unterscheidet. Die erwartete Latenz wäre etwa 160 ms, aber es ist tatsächlich 189 ms aufgrund der längeren Faserroute.

Nächste Schritte

• Laden Sie das Azure Connectivity Toolkit
• Folgen Sie den Anweisungen für link-Leistungstests