Dostosowywanie wydajności protokołu TCP/IP dla maszyn wirtualnych platformy Azure
W tym artykule omówiono typowe techniki dostrajania wydajności protokołu TCP/IP i kilka kwestii, które należy wziąć pod uwagę podczas ich używania na maszynach wirtualnych działających na platformie Azure. Będzie on zawierać podstawowe omówienie technik i dowiedzieć się, jak można je dostroić.
Typowe techniki dostrajania protokołu TCP/IP
Jednostki MTU, fragmentacja i duże odciążanie wysyłania
MTU
Maksymalna jednostka transmisji (MTU) to największa ramka (pakiet), określona w bajtach, którą można wysyłać za pośrednictwem interfejsu sieciowego. MTU jest konfigurowalnym ustawieniem. Domyślna wartość jednostki MTU używana na maszynach wirtualnych platformy Azure i ustawienie domyślne większości urządzeń sieciowych globalnie wynosi 1500 bajtów.
Fragmentacja
Fragmentacja występuje, gdy pakiet jest wysyłany, który przekracza jednostki MTU interfejsu sieciowego. Stos TCP/IP podzieli pakiet na mniejsze elementy (fragmenty), które są zgodne z jednostki MTU interfejsu. Fragmentacja występuje w warstwie adresu IP i jest niezależna od podstawowego protokołu (takiego jak TCP). Gdy pakiet 2000 bajtów jest wysyłany za pośrednictwem interfejsu sieciowego z jednostki MTU 1500, pakiet zostanie podzielony na jeden pakiet 1500 bajtów i jeden pakiet 500 bajtów.
Urządzenia sieciowe w ścieżce między źródłem i miejscem docelowym mogą usuwać pakiety przekraczające jednostki MTU lub fragmentować pakiet na mniejsze elementy.
Bit Nie fragmentu w pakiecie IP
Bit Nie fragmentu (DF) jest flagą w nagłówku protokołu IP. Bit df wskazuje, że urządzenia sieciowe na ścieżce między nadawcą i odbiornikiem nie mogą fragmentować pakietu. Ten bit można ustawić z wielu powodów. (Zobacz sekcję "Odnajdywanie ścieżki MTU" tego artykułu, aby zapoznać się z jednym przykładem). Gdy urządzenie sieciowe odbiera pakiet z ustawionym bitem Don't Fragment, a pakiet przekracza interfejs jednostki MTU urządzenia, standardem jest usunięcie pakietu przez urządzenie. Urządzenie wysyła komunikat ICMP Fragmentation Needed z powrotem do oryginalnego źródła pakietu.
Wpływ na wydajność fragmentacji
Fragmentacja może mieć negatywne skutki dla wydajności. Jedną z głównych przyczyn wpływu na wydajność jest wpływ procesora CPU/pamięci na fragmentację i ponowne składanie pakietów. Gdy urządzenie sieciowe ma fragmentować pakiet, będzie musiało przydzielić zasoby procesora CPU/pamięci do wykonania fragmentacji.
Dzieje się tak samo, gdy pakiet zostanie ponownie rozsyłany. Urządzenie sieciowe musi przechowywać wszystkie fragmenty, dopóki nie zostaną odebrane, aby można było je ponownie umieścić w oryginalnym pakiecie.
Platforma Azure i fragmentacja
Pofragmentowane pakiety na platformie Azure nie są przetwarzane przez przyspieszoną sieć. Gdy maszyna wirtualna odbiera pofragmentowany pakiet, zostanie ona przetworzona za pośrednictwem ścieżki nieprzyśpieszonej. Oznacza to, że pofragmentowane pakiety nie będą otrzymywać korzyści z przyspieszonej sieci (mniejsze opóźnienia, mniejsze zakłócenia i większe pakiety na sekundę). Z tego powodu zalecamy unikanie fragmentacji, jeśli jest to możliwe.
Domyślnie platforma Azure usuwa fragmenty zamówień, czyli pofragmentowane pakiety, które nie docierają do maszyny wirtualnej w kolejności, w której zostały one przesłane z punktu końcowego źródłowego. Może się to zdarzyć, gdy pakiety są przesyłane przez Internet lub inne duże sieci WAN. W niektórych przypadkach można włączyć zmienianie kolejności fragmentów poza kolejnością. Jeśli aplikacja tego wymaga, otwórz zgłoszenie do pomocy technicznej.
Dostrajanie jednostki MTU
Nie zalecamy, aby klienci zwiększali liczbę jednostek MTU na kartach sieciowych maszyn wirtualnych. Jeśli maszyna wirtualna musi komunikować się z miejscami docelowymi, które nie znajdują się w sieci wirtualnej z podobnym zestawem jednostek MTU, fragmentacja prawdopodobnie spadnie, co zmniejszy wydajność.
Duże odciążanie wysyłania
Duże odciążanie wysyłania (LSO) może zwiększyć wydajność sieci przez odciążanie segmentacji pakietów do karty Ethernet. Po włączeniu funkcji LSO stos TCP/IP tworzy duży pakiet TCP i wysyła go do karty Ethernet na potrzeby segmentacji przed przekazaniem go. Zaletą LSO jest to, że może zwolnić procesor z segmentowania pakietów w rozmiary zgodne z MTU i odciążać to przetwarzanie do interfejsu Ethernet, w którym jest wykonywane w sprzęcie. Aby dowiedzieć się więcej na temat zalet LSO, zobacz Obsługa dużego odciążania wysyłania.
Po włączeniu funkcji LSO klienci platformy Azure mogą zobaczyć duże rozmiary ramek podczas przechwytywania pakietów. Te duże rozmiary ramek mogą prowadzić niektórych klientów do myślenia, że fragmentacja występuje lub że duża jednostka MTU jest używana, gdy nie jest. W przypadku LSO karta Ethernet może anonsować większy maksymalny rozmiar segmentu (MSS) do stosu TCP/IP w celu utworzenia większego pakietu TCP. Cała niesegmentowana ramka jest następnie przekazywana do karty Ethernet i będzie widoczna w przechwyceniu pakietów wykonywanym na maszynie wirtualnej. Ale pakiet zostanie podzielony na wiele mniejszych ramek przez kartę Ethernet, zgodnie z karty Ethernet karty MTU.
Skalowanie okien PROTOKOŁU TCP MSS i PMTUD
Maksymalny rozmiar segmentu TCP
Maksymalny rozmiar segmentu TCP (MSS) to ustawienie, które ogranicza rozmiar segmentów TCP, co pozwala uniknąć fragmentacji pakietów TCP. Systemy operacyjne zazwyczaj używają tej formuły do ustawiania usługi MSS:
MSS = MTU - (IP header size + TCP header size)
Nagłówek IP i nagłówek TCP to 20 bajtów każdy lub 40 bajtów łącznie. Dlatego interfejs z mtU 1500 będzie miał msS 1460. Jednak usługa MSS jest konfigurowalna.
To ustawienie jest uzgodnione w trójkierunkowym uzgadnianiu TCP, gdy sesja TCP jest skonfigurowana między źródłem a miejscem docelowym. Obie strony wysyłają wartość MSS, a dolna z dwóch jest używana dla połączenia TCP.
Należy pamiętać, że jednostki MTU źródła i miejsca docelowego nie są jedynymi czynnikami określającymi wartość msS. Pośredniczące urządzenia sieciowe, takie jak bramy sieci VPN, w tym usługa Azure VPN Gateway, mogą dostosowywać jednostki MTU niezależnie od źródła i miejsca docelowego, aby zapewnić optymalną wydajność sieci.
Odnajdywanie ścieżki jednostki MTU
Usługa MSS jest negocjowana, ale może nie wskazywać rzeczywistej usługi MSS, która może być używana. Dzieje się tak, ponieważ inne urządzenia sieciowe w ścieżce między źródłem a miejscem docelowym mogą mieć niższą wartość jednostki MTU niż źródło i miejsce docelowe. W takim przypadku urządzenie, którego jednostki MTU jest mniejsze niż pakiet, porzuca pakiet. Urządzenie wyśle z powrotem komunikat Wymagany fragmentacji protokołu ICMP (typ 3, kod 4), który zawiera jego jednostki MTU. Ten komunikat ICMP umożliwia hostowi źródłowemu odpowiednie zmniejszenie jednostki MTU ścieżki. Proces jest nazywany odnajdywaniem jednostki MTU ścieżki (PMTUD).
Proces PMTUD jest nieefektywny i wpływa na wydajność sieci. Gdy pakiety są wysyłane, które przekraczają jednostki MTU ścieżki sieciowej, pakiety muszą zostać ponownie przetransmitowane przy użyciu niższego msS. Jeśli nadawca nie otrzyma komunikatu ICMP Fragmentation Needed (Wymagana fragmentacja protokołu ICMP), być może ze względu na zaporę sieciową w ścieżce (często określanej jako blackhole PMTUD), nadawca nie wie, że musi obniżyć usługę MSS i będzie stale ponownie wysyłać pakiet. Dlatego nie zalecamy zwiększenia jednostki MTU maszyny wirtualnej platformy Azure.
Sieć VPN i jednostki MTU
Jeśli używasz maszyn wirtualnych, które wykonują hermetyzację (na przykład sieci VPN protokołu IPsec), istnieją pewne dodatkowe zagadnienia dotyczące rozmiaru pakietów i jednostki MTU. Sieci VPN dodają więcej nagłówków do pakietów, co zwiększa rozmiar pakietu i wymaga mniejszej usługi MSS.
W przypadku platformy Azure zalecamy ustawienie zaciskania protokołu TCP MSS na 1350 bajtów i jednostki MTU interfejsu tunelu na 1400. Aby uzyskać więcej informacji, zobacz stronę urządzeń sieci VPN i parametrów protokołu IPSec/IKE.
Opóźnienie, czas rundy i skalowanie okien TCP
Opóźnienie i czas rundy
Opóźnienie sieci podlega szybkości światła przez sieć światłowodową. Przepływność sieci PROTOKOŁU TCP jest również skutecznie zarządzana przez czas rundy (RTT) między dwoma urządzeniami sieciowymi.
| Marszruta | Odległość | Jednorazowy | RTT |
|---|---|---|---|
| Nowy Jork do San Francisco | 4148 km | 21 ms | 42 ms |
| Nowy Jork do Londynu | 5585 km | 28 ms | 56 ms |
| Nowy Jork do Sydney | 15 993 km | 80 ms | 160 ms |
W tej tabeli przedstawiono odległość liniową między dwiema lokalizacjami. W sieciach odległość jest zwykle dłuższa niż odległość liniowa. Oto prosta formuła do obliczenia minimalnej wartości RTT zgodnie z prędkością światła:
minimum RTT = 2 * (Distance in kilometers / Speed of propagation)
Dla szybkości propagacji można użyć wartości 200. Jest to odległość, w kilometrach, która światła podróżuje w 1 milisekundach.
Weźmy Nowy Jork do San Francisco jako przykład. Odległość prosta wynosi 4148 km. Podłączanie tej wartości do równania uzyskujemy następujące elementy:
Minimum RTT = 2 * (4,148 / 200)
Dane wyjściowe równania są w milisekundach.
Jeśli chcesz uzyskać najlepszą wydajność sieci, logiczną opcją jest wybranie miejsc docelowych z najkrótszą odległością między nimi. Należy również zaprojektować sieć wirtualną, aby zoptymalizować ścieżkę ruchu i zmniejszyć opóźnienie. Aby uzyskać więcej informacji, zobacz sekcję "Zagadnienia dotyczące projektowania sieci" w tym artykule.
Wpływ opóźnienia i czasu rundy na protokół TCP
Czas rundy ma bezpośredni wpływ na maksymalną przepływność PROTOKOŁU TCP. W protokole TCP rozmiar okna jest maksymalną ilością ruchu, który można wysłać za pośrednictwem połączenia TCP, zanim nadawca musi odebrać potwierdzenie od odbiorcy. Jeśli dla protokołu TCP MSS ustawiono wartość 1460, a rozmiar okna TCP jest ustawiony na 65 535, nadawca może wysłać 45 pakietów, zanim będzie musiał odbierać potwierdzenie od odbiorcy. Jeśli nadawca nie otrzyma potwierdzenia, przetransmituje dane ponownie. Oto formuła:
TCP window size / TCP MSS = packets sent
W tym przykładzie 65 535 / 1460 jest zaokrąglane do 45.
Ten stan "oczekiwanie na potwierdzenie", mechanizm zapewniający niezawodne dostarczanie danych, jest przyczyną wpływu protokołu RTT na przepływność protokołu TCP. Tym dłużej nadawca czeka na potwierdzenie, tym dłużej musi czekać przed wysłaniem większej ilości danych.
Oto formuła obliczania maksymalnej przepływności pojedynczego połączenia TCP:
Window size / (RTT latency in milliseconds / 1,000) = maximum bytes/second
W tej tabeli przedstawiono maksymalną przepływność megabajtów/na sekundę pojedynczego połączenia TCP. (W celu zapewnienia czytelności megabajty są używane dla jednostki miary).
| Rozmiar okna TCP (bajty) | Opóźnienie RTT (ms) | Maksymalna przepływność megabajtów/sekund | Maksymalna przepływność megabitu/sekundy |
|---|---|---|---|
| 65,535 | 1 | 65.54 | 524.29 |
| 65,535 | 30 | 2.18 | 17.48 |
| 65,535 | 60 | 1.09 | 8.74 |
| 65,535 | 90 | .73 | 5,83 |
| 65,535 | 120 | 55. | 4.37 |
Jeśli pakiety zostaną utracone, maksymalna przepływność połączenia TCP zostanie zmniejszona, podczas gdy nadawca ponownie przesyła dane, które już wysłał.
Skalowanie okien TCP
Skalowanie okien TCP to technika, która dynamicznie zwiększa rozmiar okna TCP, aby umożliwić wysyłanie większej ilości danych przed wymaganym potwierdzeniem. W poprzednim przykładzie przed potwierdzeniem zostanie wysłanych 45 pakietów. Jeśli zwiększysz liczbę pakietów, które można wysłać przed potwierdzeniem, zmniejszasz liczbę przypadków oczekiwania nadawcy na potwierdzenie, co zwiększa maksymalną przepływność protokołu TCP.
W tej tabeli przedstawiono te relacje:
| Rozmiar okna TCP (bajty) | Opóźnienie RTT (ms) | Maksymalna przepływność megabajtów/sekund | Maksymalna przepływność megabitu/sekundy |
|---|---|---|---|
| 65,535 | 30 | 2.18 | 17.48 |
| 131,070 | 30 | 4.37 | 34.95 |
| 262,140 | 30 | 8.74 | 69.91 |
| 524,280 | 30 | 17.48 | 139.81 |
Jednak wartość nagłówka TCP dla rozmiaru okna TCP wynosi tylko 2 bajty, co oznacza, że maksymalna wartość okna odbierania wynosi 65 535. Aby zwiększyć maksymalny rozmiar okna, wprowadzono współczynnik skalowania okien TCP.
Współczynnik skalowania jest również ustawieniem, które można skonfigurować w systemie operacyjnym. Oto formuła obliczania rozmiaru okna TCP przy użyciu czynników skalowania:
TCP window size = TCP window size in bytes * (2^scale factor)
Oto obliczenie współczynnika skalowania okien 3 i rozmiar okna o rozmiarze 65 535:
65,535 * (2^3) = 524,280 bytes
Współczynnik skalowania 14 powoduje, że rozmiar okna TCP wynosi 14 (dozwolone maksymalne przesunięcie). Rozmiar okna TCP będzie wynosić 1073 725 440 bajtów (8,5 gb).
Obsługa skalowania okien TCP
System Windows może ustawić różne czynniki skalowania dla różnych typów połączeń. (Klasy połączeń obejmują centrum danych, Internet itd.) Polecenie programu PowerShell służy Get-NetTCPConnection do wyświetlania typu połączenia skalowania okna:
Get-NetTCPConnection
Możesz użyć Get-NetTCPSetting polecenia programu PowerShell, aby wyświetlić wartości każdej klasy:
Get-NetTCPSetting
Początkowy rozmiar okna TCP i współczynnik skalowania TCP w systemie Windows można ustawić przy użyciu Set-NetTCPSetting polecenia programu PowerShell. Aby uzyskać więcej informacji, zobacz Set-NetTCPSetting.
Set-NetTCPSetting
Są to obowiązujące ustawienia protokołu TCP dla programu AutoTuningLevel:
| AutoTuningLevel | Współczynnik skalowania | Mnożnik skalowania | Formuła do obliczanie maksymalnego rozmiaru okna |
|---|---|---|---|
| Disabled | Brak | Brak | Rozmiar okna |
| Podlega ograniczeniom | 100 | 2^4 | Rozmiar okna * (2^4) |
| Wysoce ograniczone | 2 | 2^2 | Rozmiar okna * (2^2) |
| Normalna | 8 | 2^8 | Rozmiar okna * (2^8) |
| Eksperymentalne | 14 | 2^14 | Rozmiar okna * (2^14) |
Te ustawienia są najbardziej prawdopodobne, aby wpłynąć na wydajność protokołu TCP, ale należy pamiętać, że wiele innych czynników w Internecie, poza kontrolą platformy Azure, może również mieć wpływ na wydajność protokołu TCP.
Przyspieszona sieć i skalowanie po stronie odbierającej
Przyspieszona sieć
Funkcje sieciowe maszyny wirtualnej były historycznie intensywnie obciążane zarówno na maszynie wirtualnej gościa, jak i na hoście/funkcji hypervisor. Każdy pakiet przesyłany przez host jest przetwarzany w oprogramowaniu przez procesor hosta, w tym całą hermetyzację sieci wirtualnej i decapsulation. Tym większy ruch przechodzi przez hosta, tym większe obciążenie procesora CPU. A jeśli procesor CPU hosta jest zajęty innymi operacjami, będzie to również miało wpływ na przepływność i opóźnienie sieci. Platforma Azure rozwiązuje ten problem z przyspieszoną siecią.
Przyspieszona sieć zapewnia spójne ultralowne opóźnienie sieci za pośrednictwem wewnętrznego programowalnego sprzętu platformy Azure i technologii, takich jak SR-IOV. Przyspieszona sieć przenosi większość stosu sieci zdefiniowanego programowo na platformie Azure z procesorów CPU i do opartych na układach FPGA SmartNICs. Ta zmiana umożliwia aplikacjom końcowym odzyskiwanie cykli obliczeniowych, co powoduje mniejsze obciążenie maszyny wirtualnej i zmniejsza zakłócenia i niespójność w opóźnieniu. Innymi słowy, wydajność może być bardziej deterministyczna.
Przyspieszona sieć zwiększa wydajność, umożliwiając maszynie wirtualnej gościa obejście hosta i ustanowienie ścieżki danych bezpośrednio z funkcją SmartNIC hosta. Poniżej przedstawiono niektóre zalety przyspieszonej sieci:
Mniejsze opóźnienie /wyższe pakiety na sekundę (pps): Usunięcie przełącznika wirtualnego ze ścieżki danych eliminuje czas spędzony na hoście na potrzeby przetwarzania zasad i zwiększa liczbę pakietów, które można przetworzyć na maszynie wirtualnej.
Mniejsze zakłócenia: przetwarzanie przełącznika wirtualnego zależy od ilości zasad, które należy zastosować, oraz obciążenia procesora CPU, który wykonuje przetwarzanie. Odciążanie wymuszania zasad do sprzętu powoduje usunięcie tej zmienności przez dostarczanie pakietów bezpośrednio do maszyny wirtualnej, eliminując komunikację między hostem a maszyną wirtualną oraz wszystkie przerwania oprogramowania i przełączniki kontekstowe.
Mniejsze wykorzystanie procesora: Pominięcie przełącznika wirtualnego na hoście prowadzi do mniejszego wykorzystania procesora CPU na potrzeby przetwarzania ruchu sieciowego.
Aby użyć przyspieszonej sieci, należy jawnie włączyć ją na każdej odpowiedniej maszynie wirtualnej. Aby uzyskać instrukcje, zobacz Tworzenie maszyny wirtualnej z systemem Linux z przyspieszoną siecią .
Skalowanie po stronie odbierającej
Skalowanie po stronie odbierającej (RSS) to technologia sterowników sieciowych, która bardziej efektywnie dystrybuuje odbieranie ruchu sieciowego przez dystrybucję przetwarzania odbierania na wiele procesorów CPU w systemie wieloprocesorowym. Mówiąc prosto, funkcja RSS umożliwia systemowi przetwarzanie większej liczby odebranych ruchu, ponieważ używa wszystkich dostępnych procesorów CPU, a nie tylko jednego. Aby zapoznać się z bardziej technicznym omówieniem funkcji RSS, zobacz Wprowadzenie do skalowania po stronie odbierającej.
Aby uzyskać najlepszą wydajność po włączeniu przyspieszonej sieci na maszynie wirtualnej, należy włączyć funkcję RSS. Funkcja RSS może również zapewnić korzyści dla maszyn wirtualnych, które nie korzystają z przyspieszonej sieci. Aby zapoznać się z omówieniem sposobu określania, czy funkcja RSS jest włączona i jak ją włączyć, zobacz Optymalizowanie przepływności sieci dla maszyn wirtualnych platformy Azure.
Zabójstwo TIME_WAIT TCP i TIME_WAIT
TIME_WAIT TCP to inne typowe ustawienie, które wpływa na wydajność sieci i aplikacji. W przypadku zajętych maszyn wirtualnych, które otwierają i zamykają wiele gniazd, jako klientów lub jako serwerów (źródłowy port IP:źródłowy + docelowy port IP:docelowy), podczas normalnego działania protokołu TCP dane gniazdo może zakończyć się w stanie TIME_WAIT przez długi czas. Stan TIME_WAIT jest przeznaczony do umożliwienia dostarczenia wszelkich dodatkowych danych na gniazdo przed jego zamknięciem. Dlatego stosy TCP/IP zwykle uniemożliwiają ponowne użycie gniazda przez dyskretne usunięcie pakietu TCP SYN klienta.
Czas, przez jaki gniazdo znajduje się w TIME_WAIT jest konfigurowalny. Może to wahać się od 30 sekund do 240 sekund. Gniazda są zasobem skończonym, a liczba gniazd, które mogą być używane w dowolnym momencie, jest konfigurowalna. (Liczba dostępnych gniazd wynosi zwykle około 30 000). Jeśli dostępne gniazda są używane lub klienci i serwery mają niezgodne ustawienia TIME_WAIT, a maszyna wirtualna próbuje ponownie użyć gniazda w stanie TIME_WAIT, nowe połączenia nie powiedzą się, ponieważ pakiety TCP SYN są porzucane w trybie dyskretnym.
Wartość zakresu portów dla gniazd wychodzących jest zwykle konfigurowalna w stosie TCP/IP systemu operacyjnego. To samo dotyczy ustawień TIME_WAIT TCP i ponownego użycia gniazda. Zmiana tych liczb może potencjalnie zwiększyć skalowalność. Jednak w zależności od sytuacji te zmiany mogą powodować problemy ze współdziałaniem. Jeśli te wartości zostaną zmienione, należy zachować ostrożność.
Aby rozwiązać ten problem ze skalowaniem, możesz użyć TIME_WAIT zabójstwa. TIME_WAIT zabójstwo umożliwia ponowne użycie gniazda w niektórych sytuacjach, na przykład gdy numer sekwencji w pakiecie IP nowego połączenia przekracza numer sekwencji ostatniego pakietu z poprzedniego połączenia. W takim przypadku system operacyjny zezwoli na nawiązanie nowego połączenia (zaakceptuje nowe połączenie SYN/ACK) i wymusi zamknięcie poprzedniego połączenia, które było w stanie TIME_WAIT. Ta funkcja jest obsługiwana na maszynach wirtualnych z systemem Windows na platformie Azure. Aby dowiedzieć się więcej o obsłudze innych maszyn wirtualnych, zapoznaj się z dostawcą systemu operacyjnego.
Aby dowiedzieć się więcej na temat konfigurowania ustawień TIME_WAIT TCP i zakresu portów źródłowych, zobacz Ustawienia, które można zmodyfikować w celu zwiększenia wydajności sieci.
Czynniki sieci wirtualnej, które mogą mieć wpływ na wydajność
Maksymalna przepływność ruchu wychodzącego maszyny wirtualnej
Platforma Azure oferuje różne rozmiary i typy maszyn wirtualnych, z których każda ma różne możliwości wydajności. Jedną z tych funkcji jest przepływność sieci (lub przepustowość), która jest mierzona w megabitach na sekundę (Mb/s). Ponieważ maszyny wirtualne są hostowane na udostępnionym sprzęcie, pojemność sieci musi być współdzielona sprawiedliwie między maszynami wirtualnymi przy użyciu tego samego sprzętu. Większe maszyny wirtualne są przydzielane większą przepustowość niż mniejsze maszyny wirtualne.
Przepustowość sieci przydzielona do każdej maszyny wirtualnej jest mierzona w ruchu wychodzącym (wychodzącym) z maszyny wirtualnej. Cały ruch sieciowy opuszczający maszynę wirtualną jest liowany do przydzielonego limitu, niezależnie od miejsca docelowego. Jeśli na przykład maszyna wirtualna ma limit 1000 MB/s, ten limit dotyczy tego, czy ruch wychodzący jest przeznaczony dla innej maszyny wirtualnej w tej samej sieci wirtualnej, czy spoza platformy Azure.
Ruch przychodzący nie jest mierzony ani ograniczony bezpośrednio. Istnieją jednak inne czynniki, takie jak limity procesora CPU i magazynu, które mogą mieć wpływ na zdolność maszyny wirtualnej do przetwarzania danych przychodzących.
Przyspieszona sieć została zaprojektowana w celu zwiększenia wydajności sieci, w tym opóźnienia, przepływności i wykorzystania procesora CPU. Przyspieszona sieć może zwiększyć przepływność maszyny wirtualnej, ale może to zrobić tylko do przydzielonej przepustowości maszyny wirtualnej.
Maszyny wirtualne platformy Azure mają dołączony co najmniej jeden interfejs sieciowy. Mogą mieć kilka. Przepustowość przydzielona do maszyny wirtualnej to suma całego ruchu wychodzącego we wszystkich interfejsach sieciowych dołączonych do maszyny. Innymi słowy, przepustowość jest przydzielana dla poszczególnych maszyn wirtualnych, niezależnie od liczby interfejsów sieciowych dołączonych do maszyny.
Oczekiwana przepływność ruchu wychodzącego i liczba interfejsów sieciowych obsługiwanych przez poszczególne rozmiary maszyn wirtualnych są szczegółowo opisane w temacie Rozmiary maszyn wirtualnych z systemem Windows na platformie Azure. Aby wyświetlić maksymalną przepływność, wybierz typ, taki jak Ogólnego przeznaczenia, a następnie znajdź sekcję dotyczącą serii rozmiarów na wyświetlonej stronie (na przykład "Dv2-series"). Dla każdej serii znajduje się tabela, która zawiera specyfikacje sieci w ostatniej kolumnie, która nosi tytuł "Maksymalna liczba kart sieciowych / Oczekiwana przepustowość sieci (Mb/s)."
Limit przepływności dotyczy maszyny wirtualnej. Przepływność nie ma wpływu na następujące czynniki:
Liczba interfejsów sieciowych: limit przepustowości ma zastosowanie do sumy całego ruchu wychodzącego z maszyny wirtualnej.
Przyspieszona sieć: chociaż ta funkcja może być przydatna w osiągnięciu opublikowanego limitu, nie zmienia limitu.
Miejsce docelowe ruchu: wszystkie miejsca docelowe są liczone do limitu ruchu wychodzącego.
Protokół: cały ruch wychodzący przez wszystkie protokoły jest liczone do limitu.
Aby uzyskać więcej informacji, zobacz Przepustowość sieci maszyny wirtualnej.
Zagadnienia dotyczące wydajności internetu
Zgodnie z opisem w tym artykule czynniki w Internecie i poza kontrolą platformy Azure mogą mieć wpływ na wydajność sieci. Oto niektóre z tych czynników:
Opóźnienie: czas rundy między dwoma miejscami docelowymi może mieć wpływ na problemy w sieciach pośrednich, przez ruch, który nie zajmuje "najkrótszej" ścieżki odległości i przez nieoptymalne ścieżki komunikacji równorzędnej.
Utrata pakietów: utrata pakietów może być spowodowana przeciążeniem sieci, problemami ze ścieżkami fizycznymi i niewystarczającą wydajnością urządzeń sieciowych.
Rozmiar/fragmentacja jednostki MTU: fragmentacja wzdłuż ścieżki może prowadzić do opóźnień w nadejściu danych lub w pakietach przychodzących z zamówienia, co może mieć wpływ na dostarczanie pakietów.
Traceroute to dobre narzędzie do mierzenia charakterystyk wydajności sieci (takich jak utrata pakietów i opóźnienie) wzdłuż każdej ścieżki sieciowej między urządzeniem źródłowym a urządzeniem docelowym.
Zagadnienia dotyczące projektowania sieci
Oprócz zagadnień omówionych wcześniej w tym artykule topologia sieci wirtualnej może mieć wpływ na wydajność sieci. Na przykład projekt piasty i szprych, który globalnie kieruje ruch wsteczny do sieci wirtualnej z jednym koncentratorem, wprowadzi opóźnienie sieci, co wpłynie na ogólną wydajność sieci.
Liczba urządzeń sieciowych, przez które przechodzi ruch sieciowy, może również mieć wpływ na ogólne opóźnienie. Na przykład w projekcie piasty i szprych, jeśli ruch przechodzi przez wirtualne urządzenie sieciowe szprychy i urządzenie wirtualne koncentratora przed tranzytem do Internetu, wirtualne urządzenia sieciowe mogą wprowadzać opóźnienia.
Regiony platformy Azure, sieci wirtualne i opóźnienie
Regiony platformy Azure składają się z wielu centrów danych, które istnieją w ogólnym obszarze geograficznym. Te centra danych mogą nie znajdować się fizycznie obok siebie. W niektórych przypadkach są one oddzielone aż o 10 kilometrów. Sieć wirtualna jest logiczną nakładką na sieć fizycznych centrów danych platformy Azure. Sieć wirtualna nie oznacza żadnej konkretnej topologii sieci w centrum danych.
Na przykład dwie maszyny wirtualne, które znajdują się w tej samej sieci wirtualnej i podsieci, mogą znajdować się w różnych stojakach, wierszach, a nawet centrach danych. Mogą być oddzielone stopami światłowodowego lub kilometrami światłowodowego. Ta odmiana może wprowadzić zmienne opóźnienie (kilka milisekund różnicy) między różnymi maszynami wirtualnymi.
Geograficzne rozmieszczenie maszyn wirtualnych i potencjalne wynikające z tego opóźnienie między dwiema maszynami wirtualnymi może mieć wpływ na konfigurację zestawów dostępności i Strefy dostępności. Jednak odległość między centrami danych w regionie jest specyficzna dla regionu, a przede wszystkim przez topologię centrum danych w regionie.
Wyczerpanie źródłowego portu translatora adresów sieciowych
Wdrożenie na platformie Azure może komunikować się z punktami końcowymi spoza platformy Azure w publicznym Internecie i/lub w publicznej przestrzeni adresów IP. Gdy wystąpienie inicjuje połączenie wychodzące, platforma Azure dynamicznie mapuje prywatny adres IP na publiczny adres IP. Po utworzeniu tego mapowania przez platformę Azure ruch powrotny dla przepływu wychodzącego może również uzyskać dostęp do prywatnego adresu IP, z którego pochodzi przepływ.
W przypadku każdego połączenia wychodzącego usługa Azure Load Balancer musi zachować to mapowanie przez pewien czas. Dzięki wielodostępnej charakterowi platformy Azure utrzymanie tego mapowania dla każdego przepływu wychodzącego dla każdej maszyny wirtualnej może być intensywnie obciążane zasobami. Istnieją więc limity, które są ustawiane i oparte na konfiguracji sieci wirtualnej platformy Azure. Można też powiedzieć, że dokładniej maszyna wirtualna platformy Azure może wykonywać tylko określoną liczbę połączeń wychodzących w danym momencie. Po osiągnięciu tych limitów maszyna wirtualna nie będzie mogła wykonywać większej liczby połączeń wychodzących.
Jednak to zachowanie można skonfigurować. Aby uzyskać więcej informacji na temat wyczerpania portów SNAT i SNAT, zobacz ten artykuł.
Mierzenie wydajności sieci na platformie Azure
Liczba maksymalnej wydajności w tym artykule jest związana z opóźnieniem sieci /czasem rundy (RTT) między dwiema maszynami wirtualnymi. Ta sekcja zawiera sugestie dotyczące testowania opóźnienia/protokołu RTT oraz testowania wydajności protokołu TCP i wydajności sieci maszyn wirtualnych. Możesz dostroić i przetestować wydajność wartości TCP/IP i sieci omówione wcześniej przy użyciu technik opisanych w tej sekcji. Możesz podłączyć wartości opóźnienia, jednostki MTU, MSS i rozmiaru okna do podanych wcześniej obliczeń i porównać teoretyczne wartości maksymalne z rzeczywistymi wartościami obserwowanymi podczas testowania.
Mierzenie czasu rundy i utraty pakietów
Wydajność protokołu TCP w dużym stopniu zależy od protokołu RTT i utraty pakietów. Narzędzie PING dostępne w systemach Windows i Linux zapewnia najprostszy sposób mierzenia RTT i utraty pakietów. Dane wyjściowe polecenia PING pokażą minimalne/maksymalne/średnie opóźnienie między źródłem a miejscem docelowym. Spowoduje to również wyświetlenie utraty pakietów. Polecenie PING domyślnie używa protokołu ICMP. Do testowania protokołu TCP RTT można użyć narzędzia PsPing. Aby uzyskać więcej informacji, zobacz PsPing.
Mierzenie rzeczywistej przepustowości maszyny wirtualnej
Aby dokładnie zmierzyć przepustowość maszyn wirtualnych platformy Azure, postępuj zgodnie z poniższymi wskazówkami.
Aby uzyskać więcej informacji na temat testowania innych scenariuszy, zobacz następujące artykuły:
Wykrywanie nieefektywnych zachowań protokołu TCP
W przypadku przechwytywania pakietów klienci platformy Azure mogą widzieć pakiety TCP z flagami TCP (SACK, DUP ACK, RETRANSMIT i FAST RETRANSMIT), które mogą wskazywać na problemy z wydajnością sieci. Te pakiety wskazują w szczególności nieefektywność sieci, które wynikają z utraty pakietów. Jednak utrata pakietów nie musi być spowodowana problemami z wydajnością platformy Azure. Problemy z wydajnością mogą wynikać z problemów z aplikacją, problemów z systemem operacyjnym lub innych problemów, które mogą nie być bezpośrednio związane z platformą Azure.
Należy również pamiętać, że niektóre retransmisje i zduplikowane zestawy ACL są normalne w sieci. Protokoły TCP zostały skompilowane tak, aby były niezawodne. Dowody tych pakietów TCP w przechwytywaniu pakietów niekoniecznie wskazują na problem z siecią systemową, chyba że są one nadmierne.
Mimo to te typy pakietów wskazują, że przepływność PROTOKOŁU TCP nie osiąga maksymalnej wydajności, z powodów omówionych w innych sekcjach tego artykułu.
Następne kroki
Po zapoznaniu się z informacjami na temat dostrajania wydajności protokołu TCP/IP dla maszyn wirtualnych platformy Azure warto zapoznać się z innymi zagadnieniami dotyczącymi planowania sieci wirtualnych lub dowiedzieć się więcej na temat łączenia i konfigurowania sieci wirtualnych.