Netzwerkleistungsprobleme beheben

Zusammenfassung

Azure bietet eine stabile und schnelle Möglichkeit, Ihr lokales Netzwerk mit Azure zu verbinden. Kunden aller Größen verwenden Methoden wie Site-to-Site VPN und ExpressRoute, um ihre Geschäfte in Azure auszuführen. Aber was geschieht, wenn die Leistung nicht Ihren Erwartungen oder ihrer vorherigen Erfahrung entspricht? Dieser Artikel hilft Ihnen dabei, 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 zum Betrachten des Azure Netzwerks, 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 Host 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 Sie ü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 Betriebssystemeinstellungen Datenverkehr wie erwartet senden und empfangen. 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. Verwenden Sie einen 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 Sie auch NSGs auf Subnetzebene anwenden. 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 ausgehender Datenverkehr die VM verlässt, wird zuerst das NIC-NSG und dann das Subnetz-NSG angewendet.

• Subnetz-UDR – Benutzerdefinierte Routen können den Datenverkehr zu einem Zwischenknoten wie einer Firewall oder einem Lastenausgleichsmodul leiten. Stellen Sie sicher, dass Sie wissen, ob ein UDR für Ihren Datenverkehr vorhanden ist. Wenn dies der Fall ist, sollten Sie verstehen, wohin er weitergeleitet wird und was der nächste Hop mit Ihrem Datenverkehr macht. 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, beachten Sie die Verbindungsgewichtungseinstellungen. Die Verbindungsgewichtung beeinflusst die Verbindungspräferenz und bestimmt den Pfad, den Ihr Datenverkehr nimmt.

• Route-Filter (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. Viele Zwischenstationen, Geräte und Unternehmen sind an diesen Verbindungen beteiligt, was die Fehlerbehebung erschweren kann. 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 diese Routing-Domäne aus wenigen Netzwerkgeräten zwischen Ihnen und dem WAN oder aus mehreren Schichten von Geräten in einem Campus- oder Unternehmensnetzwerk bestehen.

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

Sie können die meisten Netzwerkprobleme analysieren und isolieren, indem Sie grundlegende Tools wie Ping und Traceroute verwenden. Es ist selten, dass Sie so tief wie paketanalyse gehen müssen, indem Sie Tools wie Wireshark verwenden.

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

Sie können ein PowerShell-Modul (AzureCT) verwenden, das diese Tools und Methoden umschließt.

AzureCT – das Azure Connectivity Toolkit

Das AzureCT PowerShell-Modul enthält zwei Komponenten: Availability Testing und Performance Testing. Dieser Artikel konzentriert sich auf Leistungstests, insbesondere auf die beiden Befehle zur Verknüpfungsleistung in diesem PowerShell-Modul.

Führen Sie die folgenden drei grundlegenden Schritte aus, um dieses Toolkit für Leistungstests zu verwenden:

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 3389 (RDP für Windows) oder 22 (SSH für Linux) überwacht 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.

   Wenn 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:

   

   Detaillierte Ergebnisse aller iPerf- und PSPing-Tests werden in einzelnen Textdateien im Verzeichnis der AzureCT-Tools unter C:\ACTToolsgespeichert.

Leistungsprobleme beheben

Wenn die Leistungstestergebnisse nicht ihren Erwartungen entsprechen, 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 angemessen 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, ohne gründliche Untersuchung vorschnell die Blackbox im Übertragungspfad verantwortlich zu machen, da diese Annahme die Problemlösung verzögern kann.

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. Ermitteln Sie, wo sie funktioniert und wo sie nicht funktioniert. Verschieben Sie Ihre Testpunkte, um die problematische Komponente zu isolieren.

5. Berücksichtigen aller OSI-Ebenen

   Während es üblich ist, sich auf das Netzwerk und die Ebenen 1-3 (physische, Daten und Netzwerkebenen) zu konzentrieren, denken Sie daran, 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.

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 finden Sie eine Lösung. 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 zusammen, um sie bei der Arbeit zu unterstützen und redundante Aufgaben zu vermeiden. Möglicherweise möchten Sie Ihre Ergebnisse nach dem Grundsatz „Vertrauen ist gut, Kontrolle ist besser“ ü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- und Bandbreitenerwartungen

Sie richten beispielsweise eine ExpressRoute in Seattle, Washington, USA ein. Die folgende Tabelle zeigt die Latenz und Bandbreite, die Sie bei Tests mit verschiedenen Azure-Standorten beobachten, zusammen mit den 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 verwenden den Befehl "AzureCT Get-LinkPerformance" mit einem 5-minütigen Auslastungstest für jede der sechs Testläufe. Beispiel:

  Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 300
  

• Der Datenfluss für jeden Test verläuft 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.

Latenz- und Bandbreitenergebnisse

* Die Latenz nach Brasilien ist ein Beispiel, bei dem sich der Faserlaufabstand deutlich vom geraden Abstand unterscheidet. Die erwartete Latenz beträgt 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