Udostępnij za pośrednictwem


Rozwiązywanie problemów z wydajnością sieci

Omówienie

Platforma Azure zapewnia stabilny i szybki sposób łączenia sieci lokalnej z platformą Azure. Metody, takie jak sieć VPN typu lokacja-lokacja i usługa ExpressRoute, są pomyślnie używane przez klientów o wszystkich rozmiarach do prowadzenia firm na platformie Azure. Ale co się stanie, gdy wydajność nie spełnia Twoich oczekiwań ani wcześniejszych doświadczeń? Ten artykuł może pomóc w standaryzacji sposobu testowania i tworzenia linii bazowej określonego środowiska.

Dowiesz się, jak łatwo i spójnie testować opóźnienie sieci i przepustowość między dwoma hostami. Otrzymasz również porady dotyczące sposobów przyjrzenia się sieci platformy Azure w celu wyizolowania punktów problemów. Omówiony skrypt programu PowerShell i narzędzia wymagają dwóch hostów w sieci (na każdym końcu testowanego linku). Jeden host musi być systemem Windows Server lub pulpitem, a drugi może być windows lub Linux.

Składniki sieci

Przed rozpoczęciem rozwiązywania problemów omówimy niektóre typowe terminy i składniki. Ta dyskusja zapewnia, że myślimy o każdym składniku w łańcuchu kompleksowego, który umożliwia łączność na platformie Azure.

Diagram przedstawiający domenę routingu sieciowego między środowiskiem lokalnym a platformą Azure przy użyciu usługi ExpressRoute lub sieci VPN.

Na najwyższym poziomie istnieją trzy główne domeny routingu sieciowego:

  • Sieć platformy Azure (niebieska chmura)
  • Internet lub sieć WAN (zielona chmura)
  • Sieć firmowa (pomarańczowa chmura)

Przyjrzyjmy się diagramowi od prawej do lewej, krótko omówimy każdy składnik:

  • Maszyna wirtualna — serwer może mieć wiele kart sieciowych. Upewnij się, że wszystkie trasy statyczne, trasy domyślne i ustawienia systemu operacyjnego wysyłają i odbierają ruch tak, jak uważasz. Ponadto każda jednostka SKU maszyny wirtualnej ma ograniczenie przepustowości. Jeśli używasz mniejszej jednostki SKU maszyny wirtualnej, ruch jest ograniczony przez przepustowość dostępną dla karty sieciowej. Zalecamy użycie maszyny wirtualnej ds5v2 do testowania, aby zapewnić odpowiednią przepustowość na maszynie wirtualnej.

  • Karta sieciowa — upewnij się, że znasz prywatny adres IP przypisany do danej karty sieciowej.

  • Sieciowa grupa zabezpieczeń karty sieciowej — na poziomie karty sieciowej mogą być stosowane określone sieciowe grupy zabezpieczeń. Upewnij się, że zestaw reguł sieciowej grupy zabezpieczeń jest odpowiedni dla ruchu, który próbujesz przekazać. Na przykład upewnij się, że porty 5201 dla protokołu iPerf, 3389 dla protokołu RDP lub 22 dla protokołu SSH są otwarte, aby umożliwić testowanie ruchu do przejścia.

  • Podsieć sieci wirtualnej — karta sieciowa jest przypisywana do określonej podsieci. Upewnij się, że znasz jedną z reguł skojarzonych z tą podsiecią.

  • Sieciowa grupa zabezpieczeń podsieci — podobnie jak karta sieciowa, sieciowe grupy zabezpieczeń można również stosować na poziomie podsieci. Upewnij się, że zestaw reguł sieciowej grupy zabezpieczeń jest odpowiedni dla ruchu, który próbujesz przekazać. W przypadku ruchu przychodzącego do karty sieciowej sieciowa grupa zabezpieczeń podsieci ma zastosowanie najpierw, a następnie sieciowa grupa zabezpieczeń karty sieciowej. Gdy ruch wychodzący z maszyny wirtualnej, sieciowa grupa zabezpieczeń karty sieciowej zostanie zastosowana najpierw, a następnie zostanie zastosowana sieciowa grupa zabezpieczeń podsieci.

  • Trasa zdefiniowana przez użytkownika — trasy zdefiniowane przez użytkownika mogą kierować ruch do przeskoku pośredniego (takiego jak zapora lub moduł równoważenia obciążenia). Upewnij się, że wiesz, czy istnieje trasa zdefiniowana przez użytkownika dla ruchu. Jeśli tak, dowiedz się, gdzie to idzie, i co następny przeskok zrobi dla ruchu. Na przykład zapora może przekazać jakiś ruch i zablokować inny ruch między tymi samymi dwoma hostami.

  • Podsieć bramy/ sieciowa grupa zabezpieczeń/ trasa zdefiniowana przez użytkownika — podobnie jak podsieć maszyny wirtualnej, podsieć bramy może mieć sieciowe grupy zabezpieczeń i trasy zdefiniowane przez użytkownika. Upewnij się, że wiesz, czy są tam i jakie skutki mają na twój ruch.

  • Brama sieci wirtualnej (ExpressRoute) — po włączeniu komunikacji równorzędnej (ExpressRoute) lub sieci VPN nie ma wielu ustawień, które mogą mieć wpływ na sposób lub jeśli trasy ruchu. Jeśli masz bramę sieci wirtualnej połączoną z wieloma obwodami usługi ExpressRoute lub tunelami sieci VPN, należy pamiętać o ustawieniach wagi połączenia. Waga połączenia wpływa na preferencje połączenia i określa ścieżkę, którą zajmuje ruch.

  • Filtr tras (nie pokazano) — filtr trasy jest niezbędny w przypadku korzystania z komunikacji równorzędnej firmy Microsoft za pośrednictwem usługi ExpressRoute. Jeśli nie otrzymujesz żadnych tras, sprawdź, czy filtr trasy został skonfigurowany i zastosowany poprawnie do obwodu.

Na tym etapie znajdujesz się w części sieci WAN linku. Ta domena routingu może być dostawcą usług, firmową siecią WAN lub Internetem. Istnieje wiele przeskoków, urządzeń i firm związanych z tymi linkami, co może utrudnić rozwiązywanie problemów. Należy najpierw wykluczyć zarówno platformę Azure, jak i sieci firmowe, zanim będzie można zbadać przeskoki między nimi.

Na powyższym diagramie po lewej stronie znajduje się sieć firmowa. W zależności od wielkości firmy ta domena routingu może być kilkoma urządzeniami sieciowymi między użytkownikiem a siecią WAN lub wieloma warstwami urządzeń w sieci kampusu/przedsiębiorstwa.

Biorąc pod uwagę złożoność tych trzech różnych środowisk sieciowych wysokiego poziomu, często optymalne jest rozpoczęcie od krawędzi i próba pokazania, gdzie wydajność jest dobra i gdzie spada. Takie podejście może pomóc zidentyfikować domenę routingu problemów z trzema elementami. Następnie możesz skupić się na rozwiązywaniu problemów z tym konkretnym środowiskiem.

Narzędzia

Większość problemów z siecią można analizować i izolować przy użyciu podstawowych narzędzi, takich jak ping i traceroute. Rzadko trzeba przejść tak głęboko, jak analiza pakietów przy użyciu narzędzi takich jak Wireshark.

Aby ułatwić rozwiązywanie problemów, opracowano zestaw narzędzi Azure Connectivity Toolkit (AzureCT), aby umieścić niektóre z tych narzędzi w łatwym pakiecie. Na potrzeby testowania wydajności narzędzia, takie jak iPerf i PSPing, mogą dostarczać informacje o sieci. iPerf to powszechnie używane narzędzie do podstawowych testów wydajnościowych i jest dość łatwe w użyciu. PSPing to narzędzie ping opracowane przez sysInternals. PsPing może wykonywać polecenia ping protokołu ICMP i TCP, aby uzyskać dostęp do hosta zdalnego. Oba te narzędzia są lekkie i są instalowane po prostu przez skopiowanie plików do katalogu na hoście.

Te narzędzia i metody są opakowane w moduł programu PowerShell (AzureCT), który można zainstalować i używać.

AzureCT — zestaw narzędzi Azure Connectivity Toolkit

Moduł AzureCT PowerShell zawiera dwa składniki: testowanie dostępności i testowanie wydajności. Ten dokument koncentruje się na testowaniu wydajnościowym, w szczególności dwóch poleceniach Link Performance w tym module programu PowerShell.

Poniżej przedstawiono trzy podstawowe kroki korzystania z tego zestawu narzędzi do testowania wydajnościowego:

  1. Instalowanie modułu programu PowerShell

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

    To polecenie pobiera i instaluje moduł programu PowerShell lokalnie.

  2. Instalowanie aplikacji pomocniczych

    Install-LinkPerformance
    

    To polecenie AzureCT instaluje iPerf i PSPing w nowym katalogu C:\ACTTools i otwiera porty Zapory systemu Windows, aby zezwolić na ruch ICMP i port 5201 (iPerf).

  3. Uruchamianie testu wydajnościowego

    Najpierw na hoście zdalnym zainstaluj i uruchom narzędzie iPerf w trybie serwera. Upewnij się, że host zdalny nasłuchuje na 3389 (RDP dla systemu Windows) lub 22 (SSH dla systemu Linux) i zezwala na ruch na porcie 5201 dla iPerf. Jeśli host zdalny jest systemem Windows, zainstaluj usługę AzureCT i uruchom polecenie Install-LinkPerformance, aby skonfigurować program iPerf i niezbędne reguły zapory.

    Gdy maszyna zdalna będzie gotowa, otwórz program PowerShell na komputerze lokalnym i uruchom test:

    Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 10
    

    To polecenie uruchamia serię testów obciążenia współbieżnego i opóźnień w celu oszacowania pojemności przepustowości i opóźnienia łącza sieciowego.

  4. Przeglądanie danych wyjściowych testu

    Format danych wyjściowych programu PowerShell wygląda podobnie do następującego:

    Zrzut ekranu przedstawiający dane wyjściowe programu PowerShell w teście wydajności łącza.

    Szczegółowe wyniki wszystkich testów iPerf i PSPing są zapisywane w pojedynczych plikach tekstowych w katalogu narzędzi AzureCT pod adresem C:\ACTTools.

Rozwiązywanie problemów

Jeśli wyniki testu wydajnościowego nie są zgodne z oczekiwaniami, postępuj zgodnie z systematycznym podejściem, aby zidentyfikować problem. Biorąc pod uwagę liczbę składników w ścieżce, proces krok po kroku jest bardziej skuteczny niż losowe testowanie.

Uwaga

W tym scenariuszu występuje problem z wydajnością, a nie problem z łącznością. Aby odizolować problemy z łącznością z siecią platformy Azure, postępuj zgodnie z artykułem Weryfikowanie łączności usługi ExpressRoute.

  1. Kwestionowanie założeń

    Upewnij się, że twoje oczekiwania są uzasadnione. Na przykład w przypadku obwodu usługi ExpressRoute o przepustowości 1 Gb/s i 100 ms opóźnienia oczekiwano pełnego ruchu 1 Gb/s ze względu na charakterystykę wydajności protokołu TCP przez łącza o dużym opóźnieniu. Zapoznaj się z sekcją Dokumentacja, aby uzyskać więcej informacji na temat założeń dotyczących wydajności.

  2. Początek na krawędzi sieci

    Zacznij od krawędzi między domenami routingu i spróbuj wyizolować problem z jedną główną domeną routingu. Unikaj obwiniania "czarnej skrzynki" na ścieżce bez dokładnego badania, ponieważ może to opóźnić rozwiązanie.

  3. Tworzenie diagramu

    Rysuj diagram danego obszaru, aby metodycznie pracować i wyizolować problem. Planowanie punktów testowania i aktualizowanie mapy w miarę czyszczenia obszarów lub dokładniejszej analizy.

  4. Dzielenie i podbijanie

    Segmentuj sieć i zawężaj problem. Zidentyfikuj, gdzie działa i gdzie nie działa, i kontynuuj przenoszenie punktów testowych, aby odizolować składnik powodujący naruszenia.

  5. Rozważ wszystkie warstwy OSI

    Podczas skupienia się na sieci i warstwach 1–3 (warstwy fizyczne, dane i sieć) często występują problemy w warstwie 7 (warstwa aplikacji). Zachowaj otwarty umysł i zweryfikuj wszystkie założenia.

Zaawansowane rozwiązywanie problemów z usługą ExpressRoute

Izolowanie składników platformy Azure może być trudne, jeśli nie masz pewności, gdzie znajduje się krawędź chmury. W przypadku usługi ExpressRoute krawędź jest składnikiem sieci o nazwie Microsoft Enterprise Edge (MSEE). Rozwiązanie MSEE to pierwszy punkt kontaktu z siecią firmy Microsoft i ostatni przeskok podczas jego opuszczania. Podczas tworzenia połączenia między bramą sieci wirtualnej a obwodem usługi ExpressRoute nawiązujesz połączenie z urządzeniem MSEE. Rozpoznawanie urządzenia MSEE jako pierwszego lub ostatniego przeskoku ma kluczowe znaczenie dla izolowania problemu z siecią platformy Azure. Znajomość kierunku ruchu pomaga określić, czy problem znajduje się na platformie Azure, czy w sieci WAN lub w sieci firmowej.

Diagram przedstawiający wiele sieci wirtualnych połączonych z obwodem usługi ExpressRoute.

Uwaga

Urządzenie MSEE nie znajduje się w chmurze platformy Azure. Usługa ExpressRoute znajduje się na skraju sieci firmy Microsoft, a nie na platformie Azure. Po nawiązaniu połączenia z usługą ExpressRoute z rozwiązaniem MSEE masz połączenie z siecią firmy Microsoft, umożliwiając dostęp do usług w chmurze, takich jak Microsoft 365 (z komunikacją równorzędną firmy Microsoft) lub azure (z prywatną i/lub komunikacją równorzędną firmy Microsoft).

Jeśli dwie sieci wirtualne są połączone z tym samym obwodem usługi ExpressRoute, możesz wykonać testy w celu odizolowania problemu na platformie Azure.

Plan testu

  1. Uruchom test Get-LinkPerformance między maszynami VM1 i VM2. Ten test zapewnia wgląd w to, czy problem jest lokalny. Jeśli test generuje akceptowalne opóźnienie i wyniki przepustowości, możesz oznaczyć lokalną sieć wirtualną jako dobrą.

  2. Zakładając, że ruch w lokalnej sieci wirtualnej jest dobry, uruchom test Get-LinkPerformance między maszynami VM1 i VM3. Ten test wykonuje ćwiczenia połączenia za pośrednictwem sieci firmy Microsoft do urządzenia MSEE i z powrotem na platformę Azure. Jeśli test generuje akceptowalne opóźnienie i wyniki przepustowości, możesz oznaczyć sieć platformy Azure jako dobrą.

  3. Jeśli platforma Azure jest wykluczona, wykonaj podobne testy w sieci firmowej. Jeśli te testy są również dobre, skontaktuj się z dostawcą usług lub usługodawcą internetowy, aby zdiagnozować połączenie sieci WAN. Na przykład uruchom testy między dwoma oddziałami lub między biurkiem a serwerem centrum danych. Znajdź punkty końcowe, takie jak serwery i komputery klienckie, które mogą wykonywać testowanie ścieżki.

Ważne

Dla każdego testu oznacz godzinę dnia i zapisz wyniki w wspólnej lokalizacji. Każdy przebieg testu powinien mieć identyczne dane wyjściowe dla spójnego porównania danych. Spójność w wielu testach jest główną przyczyną używania usługi AzureCT do rozwiązywania problemów. Kluczem jest uzyskiwanie spójnych danych wyjściowych testów i danych za każdym razem. Rejestrowanie czasu i spójność danych jest szczególnie przydatne, jeśli problem jest sporadyczne. Staraj się z góry zbierać dane, aby uniknąć godzin ponownego testowania tych samych scenariuszy.

Problem jest izolowany, teraz co?

Tym bardziej izolujesz problem, tym szybciej można znaleźć rozwiązanie. Czasami dochodzisz do punktu, w którym nie można kontynuować rozwiązywania problemów. Możesz na przykład zobaczyć link między dostawcą usług, który przeskokuje przez Europę, gdy spodziewasz się, że pozostanie w Azji. W tym momencie skontaktuj się z osobą w celu uzyskania pomocy w oparciu o domenę routingu, do której odosobniłeś problem. Zawężenie go do określonego składnika jest jeszcze lepsze.

W przypadku problemów z siecią firmową wewnętrzny dział IT lub dostawca usług może pomóc w konfiguracji urządzenia lub naprawie sprzętu.

W przypadku problemów z siecią WAN udostępnij wyniki testów dostawcy usług lub usługodawcy internetowego, aby ułatwić im pracę i uniknąć nadmiarowych zadań. Mogą chcieć zweryfikować wyniki na podstawie zasady zaufania, ale zweryfikować.

W przypadku problemów z platformą Azure po wyizolowanym problemie jak najwięcej szczegółów zapoznaj się z dokumentacją usługi Azure Network i, w razie potrzeby, otwórz bilet pomocy technicznej.

Informacje

Oczekiwania dotyczące opóźnienia/przepustowości

Napiwek

Odległość geograficzna między punktami końcowymi jest największym czynnikiem opóźnienia. Podczas gdy opóźnienie sprzętu (składniki fizyczne i wirtualne, liczba przeskoków itp.) odgrywa również rolę, odległość przebiegu światłowodu, a nie odległość linii prostej, jest głównym współautorem. Ta odległość jest trudna do dokładnego mierzenia, dlatego często używamy kalkulatora odległości miejskiej do przybliżonego oszacowania.

Na przykład skonfigurujemy usługę ExpressRoute w Seattle w stanie Waszyngton w Stanach Zjednoczonych. W poniższej tabeli przedstawiono opóźnienia i przepustowość zaobserwowaną podczas testowania do różnych lokalizacji platformy Azure wraz z szacowanymi odległościami.

Konfiguracja testu:

  • Serwer fizyczny z systemem Windows Server 2016 z kartą sieciową o przepustowości 10 Gb/s podłączonym do obwodu usługi ExpressRoute.

  • Obwód usługi ExpressRoute o szybkości 10 Gb/s z włączoną prywatną komunikacją równorzędną.

  • Sieć wirtualna platformy Azure z bramą UltraPerformance w określonym regionie.

  • Maszyna wirtualna DS5v2 z systemem Windows Server 2016 w sieci wirtualnej przy użyciu domyślnego obrazu platformy Azure z zainstalowanym programem AzureCT.

  • Wszystkie testy używały polecenia AzureCT Get-LinkPerformance z 5-minutowym testem obciążeniowym dla każdego z sześciu przebiegów testów. Na przykład:

    Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 300
    
  • Przepływ danych dla każdego testu pochodzi z serwera lokalnego (klient iPerf w Seattle) do maszyny wirtualnej platformy Azure (serwer iPerf w wymienionym regionie platformy Azure).

  • W kolumnie "Opóźnienie" są wyświetlane dane z testu bez obciążenia (test opóźnienia protokołu TCP bez uruchomienia narzędzia iPerf).

  • W kolumnie "Maksymalna przepustowość" są wyświetlane dane z testu obciążenia przepływu 16 TCP o rozmiarze okna 1 MB.

Diagram środowiska testowego, w którym zainstalowano usługę AzureCT.

Wyniki opóźnienia/przepustowości

Ważne

Te liczby dotyczą tylko ogólnych odwołań. Wiele czynników wpływa na opóźnienie i chociaż te wartości są ogólnie spójne w czasie, warunki w sieci platformy Azure lub dostawcy usług mogą ulec zmianie, wpływając na opóźnienie i przepustowość. Ogólnie rzecz biorąc, te zmiany nie powodują znaczących różnic.

Lokalizacja usługi ExpressRoute Region świadczenia usługi Azure Szacowana odległość (km) Opóźnienie 1 przepustowość sesji Przepustowość maksymalna
Seattle Zachodnie stany USA 2 191 km 5 ms 262,0 Mbits/s 3,74 Gbits/s
Seattle Zachodnie stany USA 1094 km 18 ms 82,3 Mbits/s 3,70 Gbits/s
Seattle Środkowe stany USA 2357 km 40 ms 38,8 Mbits/s 2,55 Gbits/s
Seattle South Central US 2877 km 51 ms 30,6 Mbits/s 2,49 Gbits/s
Seattle Północno-środkowe stany USA 2792 km 55 ms 27,7 Mbits/s 2,19 Gbits/s
Seattle Wschodnie stany USA 2 3769 km 73 ms 21,3 Mbits/s 1,79 Gbits/s
Seattle Wschodnie stany USA 3699 km 74 ms 21,1 Mbits/s 1,78 Gbits/s
Seattle Japonia Wschodnia 7705 km 106 ms 14,6 Mbits/s 1,22 Gbits/s
Seattle Południowe Zjednoczone Królestwo 7708 km 146 ms 10,6 Mbits/s 896 Mbits/s
Seattle West Europe 7834 km 153 ms 10,2 Mbits/s 761 Mbits/s
Seattle Australia Wschodnia 12 484 km 165 ms 9,4 Mbits/s 794 Mbits/s
Seattle Southeast Asia 12 989 km 170 ms 9,2 Mbits/s 756 Mbits/s
Seattle Brazylia Południowa * 10 930 km 189 ms 8,2 Mbits/s 699 Mbits/s
Seattle Indie Południowe 12 918 km 202 ms 7,7 Mbits/s 634 Mbits/s

* Opóźnienie do Brazylii jest przykładem, w którym odległość przebiegu światłowodu znacznie różni się od odległości prostej. Oczekiwane opóźnienie będzie wynosić około 160 ms, ale to faktycznie 189 ms ze względu na dłuższą trasę światłowodową.

Uwaga

Te liczby zostały przetestowane przy użyciu usługi AzureCT na podstawie interfejsu iPerf w systemie Windows za pośrednictwem programu PowerShell. Program iPerf nie uwzględnia domyślnych opcji protokołu TCP systemu Windows dla współczynnika skalowania i używa mniejszej liczby zmian dla rozmiaru okna TCP. Dostrajając polecenia iPerf za pomocą przełącznika -w i większego rozmiaru okna TCP, można osiągnąć lepszą przepływność. Uruchamianie narzędzia iPerf w trybie wielowątkowy z wielu maszyn może również pomóc osiągnąć maksymalną wydajność łącza. Aby uzyskać najlepsze wyniki iPerf w systemie Windows, użyj polecenia "Set-NetTCPSetting -AutoTuningLevelLocal Experimental". Przed wprowadzeniem zmian sprawdź zasady organizacji.

Następne kroki