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 połączenie typu lokacja-lokacja między siecią VPN i usługą ExpressRoute, są z sukcesem używane przez klientów, którzy w swoich dużych i małych firmach stosują platformę Azure. Ale co się stanie, gdy wydajność nie spełnia 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. Przedstawiono również kilka porad dotyczących 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.

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, omówimy krótko 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 przypisana do określonej podsieci, upewnij się, która z nich jest skojarzona i która reguła jest skojarzona z tą podsiecią.

• Sieciowa grupa zabezpieczeń podsieci — podobnie jak karta sieciowa, sieciowe grupy zabezpieczeń można również stosować w 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 jest to optymalne, aby rozpocząć od krawędzi i spróbować pokazać, 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 radzenie sobie z plikami w 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 dotyczy tylko testowania wydajnościowego, dlatego skoncentrujmy się na dwóch poleceniach wydajności łącza w tym module programu PowerShell.

Istnieją trzy podstawowe kroki umożliwiające korzystanie 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 moduł programu PowerShell i instaluje go lokalnie.

2. Zainstaluj aplikacje pomocnicze.

   Install-LinkPerformance
   

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

3. Uruchom test wydajnościowy.

   Najpierw na hoście zdalnym należy zainstalować i uruchomić narzędzie iPerf w trybie serwera. Upewnij się również, ż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 program AzureCT i uruchom polecenie Install-LinkPerformance. Polecenie konfiguruje narzędzie iPerf i reguły zapory potrzebne do pomyślnego uruchomienia aplikacji iPerf w trybie serwera.

   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 szereg testów obciążenia współbieżnego i opóźnienia, aby ułatwić oszacowanie pojemności przepustowości i opóźnienia łącza sieciowego.

4. Przejrzyj dane wyjściowe testów.

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

   

   Szczegółowe wyniki wszystkich testów iPerf i PSPing znajdują się w poszczególnych plikach tekstowych w katalogu narzędzi AzureCT pod adresem "C:\ACTTools".

Rozwiązywanie problemów

Jeśli test wydajnościowy nie daje oczekiwanych wyników, dowiedz się, dlaczego powinien być postępowy proces krok po kroku. Biorąc pod uwagę liczbę składników na ścieżce, systematyczne podejście zapewnia szybszą ścieżkę do rozwiązania niż przechodzenie. Dzięki systematycznemu rozwiązywaniu problemów można zapobiec wielokrotnemu niepotrzebnemu testowaniu.

Uwaga

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

Najpierw zadaj swoje założenia. Czy twoje oczekiwania są uzasadnione? Na przykład jeśli masz obwód usługi ExpressRoute o przepustowości 1 Gb/s i 100 ms opóźnienia. Nie jest uzasadnione, aby oczekiwać pełnej liczby 1 Gb/s ruchu, biorąc pod uwagę charakterystykę wydajności protokołu TCP za pośrednictwem linków o dużym opóźnieniu. Zobacz sekcję Odwołania, aby uzyskać więcej informacji na temat założeń dotyczących wydajności.

Następnie zalecamy rozpoczęcie od krawędzi między domenami routingu i próbę wyizolowania problemu z jedną główną domeną routingu. Możesz rozpocząć od sieci firmowej, sieci WAN lub sieci platformy Azure. Ludzie często obwiniają "czarną skrzynkę" na ścieżce. Podczas obwiniania czarnej skrzynki jest łatwe do zrobienia, może znacznie opóźnić rozwiązanie. Szczególnie jeśli problem znajduje się w obszarze, w którym można wprowadzić zmiany w celu rozwiązania problemu. Przed przekazaniem dostawcy usług lub usługodawcy internetowy upewnij się, że należytej staranności wykonasz.

Po zidentyfikowaniu głównej domeny routingu, która wydaje się zawierać problem, należy utworzyć diagram danego obszaru. Podczas rysowania diagramu można metodycznie pracować i odizolować problem. Możesz zaplanować punkty testowania i zaktualizować mapę w miarę czyszczenia obszarów lub zagłębiania się w miarę postępu testowania.

Teraz, gdy masz diagram, zacznij podzielić sieć na segmenty i zawęzić problem. Dowiedz się, gdzie to działa i gdzie nie działa. Kontynuuj przenoszenie punktów testowania, aby odizolować się od składnika naruszającego dane.

Nie zapomnij również przyjrzeć się innym warstwom modelu OSI. Łatwo jest skupić się na sieci i warstwach 1 – 3 (warstwy fizyczne, dane i sieć), ale problemy mogą również występować w warstwie 7 w warstwie aplikacji. Zachowaj otwarty umysł i zweryfikuj założenia.

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

Jeśli nie masz pewności, gdzie faktycznie znajduje się krawędź chmury, izolowanie składników platformy Azure może być wyzwaniem. Gdy usługa ExpressRoute jest używana, krawędź jest składnikiem sieci o nazwie Microsoft Enterprise Edge (MSEE). W przypadku korzystania z usługi ExpressRoute protokół MSEE jest pierwszym punktem kontaktu z siecią firmy Microsoft i ostatnim przeskokiem podczas opuszczania sieci firmy Microsoft. Podczas tworzenia obiektu połączenia między bramą sieci wirtualnej a obwodem usługi ExpressRoute faktycznie wykonujesz połączenie z rozwiązaniem MSEE. Rozpoznawanie urządzenia MSEE jako pierwszego lub ostatniego przeskoku w zależności od kierunku, w jakim kierunku ruch ma kluczowe znaczenie dla izolowania problemu z siecią platformy Azure. Wiedza o tym, który kierunek potwierdza, czy problem znajduje się na platformie Azure, czy w dalszej części sieci WAN, czy w sieci firmowej.

Uwaga

Zwróć uwagę, że urządzenie MSEE nie znajduje się w chmurze platformy Azure. Usługa ExpressRoute znajduje się na krawędzi sieci firmy Microsoft, a nie na platformie Azure. Po nawiązaniu połączenia z usługą ExpressRoute z usługą MSEE masz połączenie z siecią firmy Microsoft, możesz następnie przejść do dowolnych usług w chmurze, takich jak Platforma 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ć serię testów w celu odizolowania problemu na platformie Azure.

Plan testu

1. Uruchom test Get-LinkPerformance między maszynami VM1 i VM2. Ten test zapewnia szczegółowe informacje, jeśli problem jest lokalny lub nie. Jeśli ten 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 ten test generuje akceptowalne opóźnienie i wyniki przepustowości, możesz oznaczyć sieć platformy Azure jako dobrą.

3. Jeśli platforma Azure zostanie wykluczona, możesz wykonać podobną sekwencję testów w sieci firmowej. Jeśli testuje to również dobrze, nadszedł czas, aby współpracować z dostawcą usług lub usługodawcą internetowy w celu zdiagnozowania połączenia sieci WAN. Przykład: uruchom ten test między dwoma oddziałami lub między biurkiem a serwerem centrum danych. W zależności od tego, co testujesz, znajdź punkty końcowe, takie jak serwery i komputery klienckie, które mogą korzystać z tej ścieżki.

Ważne

Ważne jest, aby dla każdego testu oznaczyć godzinę uruchomienia testu i zarejestrować wyniki w wspólnej lokalizacji. Każdy przebieg testu powinien mieć identyczne dane wyjściowe, aby można było porównać wynikowe dane między przebiegami testów i nie mieć "" w danych. Spójność w wielu testach jest głównym powodem, dla którego używamy usługi AzureCT do rozwiązywania problemów. Magia nie jest w dokładnych scenariuszach ładowania, które uruchamiamy, ale zamiast tego magia to fakt, że uzyskujemy spójny test i dane wyjściowe z każdego testu. Rejestrowanie czasu i spójność danych za każdym razem jest szczególnie przydatne, jeśli później okaże się, że problem jest sporadyczne. Staranne zebranie danych z góry i unikniesz godzin ponownego testowania tych samych scenariuszy.

Problem jest izolowany, teraz co?

Tym więcej izolujesz problem, tym szybciej można znaleźć rozwiązanie. Czasami dochodzisz do punktu, w którym nie możesz kontynuować rozwiązywania problemów. Na przykład zobaczysz link między dostawcą usług biorącym przeskoki przez Europę, ale oczekujesz, że ścieżka pozostanie w Całej Azji. W tym momencie należy zaangażować kogoś w pomoc. Użytkownik, którego pytasz, zależy od domeny routingu, do której odizolujesz problem. Jeśli możesz zawęzić go do określonego składnika, który byłby jeszcze lepszy.

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.

Dobrym rozwiązaniem w rozwiązywaniu problemów z siecią WAN jest udostępnienie wyników testów dostawcy usług lub usługodawcy internetowego, ponieważ może to pomóc im w pracy. Wyniki testu mogą również uniknąć ponownego wykonywania tych samych zadań, które zostały już wykonane. Mogą jednak chcieć sprawdzić wyniki samodzielnie. Jest to oparte na zasadzie zaufania, ale sprawdzaj.

Dzięki platformie Azure po odizolowaniu problemu w miarę szczegółowości, nadszedł czas, aby przejrzeć dokumentację usługi Azure Network, a następnie w razie potrzeby otworzyć bilet pomocy technicznej.

Informacje

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

Napiwek

Opóźnienie geograficzne (kilometry lub kilometry) między testowanymi punktami końcowymi jest zdecydowanie największym składnikiem opóźnienia. Chociaż występują opóźnienia sprzętu (składniki fizyczne i wirtualne, liczba przeskoków itp.), lokalizacja geograficzna okazała się największym składnikiem ogólnego opóźnienia podczas pracy z połączeniami sieci WAN. Ważne jest również, aby pamiętać, że odległość jest odległością światłowodu biegnie, a nie odległości linii prostej lub drogi. Ta odległość jest niezwykle trudna do uzyskania z jakąkolwiek dokładnością. W rezultacie zazwyczaj używamy kalkulatora odległości miasta w Internecie i wiemy, że ta metoda jest rażąco niedokładną miarą, ale wystarczy, aby określić ogólne oczekiwania.

Na przykład mamy konfigurację usługi ExpressRoute w Seattle w stanie Waszyngton w Stanach Zjednoczonych. W poniższej tabeli przedstawiono opóźnienia i przepustowość, które widzieliśmy podczas testowania w różnych lokalizacjach platformy Azure. Oszacowaliśmy odległość geograficzną między każdym końcem testu.

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 rozmiarze 10 Gb/s w lokalizacji zidentyfikowanej 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. Maszyna wirtualna nie została przyłączona do domeny, utworzona na podstawie domyślnego obrazu platformy Azure (bez optymalizacji ani dostosowywania) z zainstalowaną usługą AzureCT.

• Wszystkie testy używają 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 miał obciążenie przepływające z lokalnego serwera fizycznego (klient iPerf w Seattle) do maszyny wirtualnej platformy Azure (serwera iPerf w wyświetlonym regionie świadczenia usługi Azure).

• Dane kolumny "Opóźnienie" pochodzą z testu bez obciążenia (test opóźnienia PROTOKOŁU TCP bez uruchomionego programu iPerf).

• Dane kolumny "Maksymalna przepustowość" pochodzą z testu obciążenia przepływu 16 TCP o rozmiarze okna 1 MB.

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ą wysyłać ruch za pośrednictwem różnych ścieżek w dowolnym momencie, co może mieć wpływ na opóźnienie i przepustowość. Ogólnie rzecz biorąc, skutki tych zmian nie powodują znaczących różnic.

ExpressRoute Lokalizacja	Azure Region (Region)	Szacowane Odległość (km)	Opóźnienie	1 sesja Przepustowość	Maksymalnie Przepustowość
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 dobrym przykładem, w którym odległość liniowa znacznie różni się od odległości przebiegu światłowodowego. Oczekiwane opóźnienie będzie znajdować się w okolicy 160 ms, ale rzeczywiście wynosi 189 ms. Różnica w opóźnieniu wydaje się wskazywać na problem z siecią gdzieś. Ale rzeczywistość jest linia światłowodowa nie idzie do Brazylii w prostej linii. Więc należy spodziewać się dodatkowych 1000 km lub tak podróży, aby dostać się do Brazylii z Seattle.

Uwaga

Chociaż te liczby należy wziąć pod uwagę, zostały przetestowane przy użyciu usługi AzureCT, która jest oparta na IPERF w systemie Windows za pośrednictwem programu PowerShell. W tym scenariuszu protokół IPERF nie uwzględnia domyślnych opcji protokołu TCP systemu Windows dla współczynnika skalowania i używa znacznie niższej liczby zmian dla rozmiaru okna TCP. Liczby przedstawione w tym miejscu zostały wykonane przy użyciu domyślnych wartości IPERF i są przeznaczone tylko dla ogólnych odwołań. Dostrajając polecenia IPERF z przełącznikiem -w i dużym rozmiarem okna TCP, lepszą przepływność można uzyskać na długich odległościach, pokazując znacznie lepszą przepływność. Ponadto w celu zapewnienia, że usługa ExpressRoute korzysta z pełnej przepustowości, idealnie nadaje się do uruchamiania protokołu IPERF w wielowątkowatej opcji z wielu maszyn jednocześnie w celu zapewnienia, że wydajność obliczeniowa jest w stanie osiągnąć maksymalną wydajność połączenia i nie jest ograniczona przez wydajność przetwarzania pojedynczej maszyny wirtualnej. Aby uzyskać najlepsze wyniki Iperf w systemie Windows, użyj polecenia "Set-NetTCPSetting -AutoTuningLevelLocal Experimental". Przed wprowadzeniem zmian sprawdź zasady organizacji.

Następne kroki

• Pobieranie zestawu narzędzi Azure Connectivity Toolkit
• Postępuj zgodnie z instrukcjami dotyczącymi testowania wydajnościowego linku