Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
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. Zawiera on podstawowe omówienie technik i sposób dostrajania maszyn wirtualnych.
Typowe techniki dostrajania protokołu TCP/IP
Jednostki MTU, fragmentacja i duże wspomaganie wysyłania
MTU
Maksymalna jednostka transmisji (MTU) to największy rozmiar ramki (pakiet wraz z nagłówkami dostępu do sieci) określony w bajtach, który może być wysyłany 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, a jego rozmiar przekracza wartość MTU interfejsu sieciowego. Stos TCP/IP dzieli pakiet na mniejsze części (fragmenty), które odpowiadają 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 1500 MTU, pakiet jest 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 fragmentuj w pakiecie IP
Bit DF (Don’t Fragment) 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 efekt fragmentacji i ponownego składania pakietów na działanie procesora i pamięci. Gdy urządzenie sieciowe musi fragmentować pakiet, musi przydzielić zasoby procesora CPU/pamięci w celu 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
Platforma Azure nie przetwarza fragmentowanych pakietów z przyspieszoną siecią. Gdy maszyna wirtualna odbiera sfragmentowany pakiet, ścieżka nieprzyspieszona przetwarza go. W związku z tym pofragmentowane pakiety nie mają zalet przyspieszonej sieci, takich jak mniejsze opóźnienia, mniejsze zakłócenia i wyższe pakiety na sekundę. Z tego powodu zalecamy unikanie fragmentacji, jeśli jest to możliwe.
Domyślnie platforma Azure odrzuca pofragmentowane pakiety, które docierają do maszyny wirtualnej w niewłaściwej kolejności, co oznacza, że pakiety nie odpowiadają sekwencji transmisji ze źródłowego punktu końcowego. Ten problem może wystąpić, gdy pakiety są przesyłane przez Internet lub inne duże sieci WAN.
Dostrajanie MTU
Możesz zwiększyć wewnętrzną przepływność sieci wirtualnej, zwiększając MTU dla ruchu sieciowego maszyny wirtualnej. Jeśli jednak maszyna wirtualna komunikuje się z miejscami docelowymi spoza sieci wirtualnej, które mają inną jednostkę MTU, może wystąpić fragmentacja, co zmniejszy wydajność.
Aby uzyskać więcej informacji na temat ustawiania jednostki MTU na maszynach wirtualnych platformy Azure, zobacz Konfigurowanie maksymalnej jednostki transmisji (MTU) dla maszyn wirtualnych na platformie Azure.
Odciążenie wysyłania danych na dużą skalę
Duże odciążanie wysyłania (LSO) może poprawić wydajność sieci, przenosząc proces segmentacji pakietów na kartę sieciową 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. Zaleta LSO polega na tym, że zwalnia procesor CPU z dzielenia pakietów na rozmiary zgodne z jednostkami MTU i przekazuje to przetwarzanie do sprzętu interfejsu Ethernet. Aby dowiedzieć się więcej na temat zalet LSO, zobacz Obsługa funkcji Large Send Offload.
Po włączeniu funkcji LSO klienci platformy Azure mogą zauważyć duże rozmiary ramek podczas przechwytywania pakietów. Te duże rozmiary ramek mogą spowodować, że niektórzy klienci zakładają, że fragmentacja występuje lub że jest używana duża jednostka MTU, choć tak nie jest. W przypadku LSO karta ethernet może deklarować większy maksymalny rozmiar segmentu (MSS) do stosu TCP/IP, aby utworzyć większy pakiet TCP. Następnie adapter ethernet dzieli całą niesegmentowaną ramkę na wiele mniejszych ramek zgodnie z jego jednostką MTU, które są widoczne w przechwytywaniu pakietów wykonanym na maszynie wirtualnej.
Skalowanie okna 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. Interfejs z MTU 1 500 ma MSS 1 460. 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 wartości MTU źródła i celu nie są jedynymi czynnikami określającymi 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.
Odkrywanie MTU trasy
Usługa MSS jest negocjowana, ale może nie wskazywać rzeczywistej usługi MSS, która może być używana. 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 wartość MTU jest mniejsza niż pakiet, odrzuca go. Urządzenie wysyła z powrotem komunikat wymaganej fragmentacji protokołu ICMP (typ 3, kod 4), który zawiera jego MTU. Ten komunikat ICMP umożliwia hostowi źródłowemu odpowiednie zmniejszenie MTU ścieżki. Proces nazywa się Odkrywaniem maksymalnego rozmiaru jednostki przekazu na ścieżce (PMTUD).
Proces PMTUD zmniejsza wydajność sieci ze względu na nieefektywność. Kiedy zostanie przekroczona maksymalna jednostka transmisyjna (MTU) ścieżki sieciowej, pakiety muszą zostać ponownie przesłane z mniejszym MSS (Maksymalny Rozmiar Segmentu). Jeśli zapora sieciowa blokuje komunikat ICMP Fragmentation Needed (Wymagana fragmentacja protokołu ICMP), nadawca pozostaje nieświadomy konieczności obniżenia msS i wielokrotnego ponownego przesłania pakietu. Z tego powodu zalecamy, aby nie zwiększać wartości MTU maszyny wirtualnej platformy Azure.
VPN i MTU
Jeśli używasz maszyn wirtualnych, które wykonują hermetyzację (np. sieci VPN protokołu IPsec), istnieją inne zagadnienia dotyczące rozmiaru pakietów i jednostki MTU. Sieci VPN dodają więcej nagłówków do pakietów. Dodane nagłówki zwiększają rozmiar pakietu i wymagają mniejszego MSS.
W przypadku Azure zalecamy ustawienie zaciskania TCP MSS na 1350 bajtów i 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 przejścia w obie strony i skalowanie okna TCP
Opóźnienie i czas podróży w obie strony
Szybkość światła określa opóźnienie sieci za pośrednictwem sieci światłowodowej. Czas okrążenia (RTT) między dwoma urządzeniami sieciowymi wpływa na przepustowość sieci TCP.
Marszruta | Odległość | Jednokierunkowy czas | 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. Prędkość propagacji to odległość, w kilometrach, która porusza się światłem w 1 milisekundach.
Weźmy Nowy Jork do San Francisco jako przykład. Odległość prosta wynosi 4148 km. Wprowadzenie tej wartości do równania powoduje następujące równanie:
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 przed potwierdzeniem z odbiornika. Jeśli nadawca nie otrzyma potwierdzenia, ponownie przetransmituje dane. 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 | 0.73 | 5,83 |
65,535 | 120 | 0.55 | 4.37 |
Jeśli pakiety zostaną utracone, maksymalna przepływność połączenia TCP zostanie zmniejszona, podczas gdy nadawca ponownie przesyła wysyłane dane.
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 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.
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 dla współczynnika skalowania okna wynoszącego 3 oraz rozmiaru okna 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 to 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.) Aby wyświetlić typ połączenia skalowania okna, użyj polecenia Get-NetTCPConnection
PowerShell:
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
Następujące wartości to obowiązujące ustawienia protokołu TCP dla programu AutoTuningLevel
:
AutoTuningLevel | Współczynnik skalowania | Mnożnik skalowania | Formuła na obliczanie maksymalnego rozmiaru okna |
---|---|---|---|
Wyłączone | Brak | Brak | Rozmiar okna |
Podlega ograniczeniom | 4 | 2^4 | Rozmiar okna * (2^4) |
Wysoce ograniczone | 2 | 2^2 | Rozmiar okna * (2^2) |
Normalna | 8 | 2^8 | Rozmiar okna * (2^8) |
Eksperymentalny | 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 maszyn wirtualnych były historycznie obciążające dla procesora zarówno w przypadku maszyny wirtualnej gościa, jak i hypervisora/gospodarza. Procesor główny hosta przetwarza w oprogramowaniu wszystkie pakiety, które tranzytują przez hosta, w tym wszystkie enkapsulacje i dekapsulacje sieci wirtualnej. Im większy ruch przechodzi przez hosta, tym większe obciążenie procesora. Jeśli procesor CPU hosta jest zajęty innymi operacjami, które mają wpływ na przepływność i opóźnienie sieci. Platforma Azure rozwiązuje ten problem z wykorzystaniem przyspieszonej sieci.
Przyspieszona sieć zapewnia spójne, bardzo niskie opóźnienie w sieci dzięki wewnętrznemu, programowalnemu sprzętowi usługi Azure i technologiom takim jak SR-IOV. Przyspieszona sieć przenosi wiele funkcji sieci zdefiniowanej programowo na platformie Azure z CPU do inteligentnych kart sieciowych opartych na układach FPGA. Ta zmiana umożliwia aplikacjom końcowym odzyskiwanie cykli obliczeniowych, które zmniejszają obciążenie maszyny wirtualnej, zmniejszając zakłócenia i niespójność opóźnienia. Innymi słowy, wydajność może być bardziej deterministyczna.
Przyspieszona sieć zwiększa wydajność, umożliwiając wirtualnej maszynie gościa (VM) obejście hosta i ustanowienie ścieżki danych bezpośrednio z 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, rozkładając przetwarzanie tego odbierania na wiele jednostek 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.
Manipulacja oraz zamknięcie TIME_WAIT w TCP
TIME_WAIT TCP to inne typowe ustawienie wpływające na wydajność sieci i aplikacji. Obciążone maszyny wirtualne często otwierają i zamykają wiele gniazd, działając jako klienci lub serwery. Podczas normalnych operacji TCP gniazdo często wchodzi w stan TIME_WAIT i pozostaje tam przez dłuższy czas. Ten stan zapewnia dostarczanie pozostałych danych w gniazdie przed jego zamknięciem. W związku z tym stosy TCP/IP zwykle uniemożliwiają ponowne użycie gniazda przez dyskretne usunięcie pakietu TCP SYN klienta.
Możesz skonfigurować czas przechowywania gniazda w stanie TIME_WAIT. Czas trwania może wynosić od 30 sekund do 240 sekund. Gniazda to zasoby skończone, których dostępność można konfigurować. Zazwyczaj około 30 000 gniazd jest dostępnych do użycia w danym momencie. Jeśli system korzysta ze wszystkich dostępnych gniazd lub jeśli klienci i serwery używają niezgodnych ustawień TIME_WAIT, maszyna wirtualna może podjąć próbę ponownego użycia gniazda nadal w stanie TIME_WAIT. W takich przypadkach nowe połączenia kończą się niepowodzeniem, ponieważ pakiety TCP SYN są porzucane w trybie dyskretnym.
Wartość zakresu portów dla gniazd wychodzących można skonfigurować 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ć techniki "TIME_WAIT assassination". TIME_WAIT zakończenie pozwala na ponowne użycie gniazda w określonych sytuacjach, takich jak wtedy, gdy numer sekwencji w pakiecie IP nowego połączenia jest większy niż numer sekwencji ostatniego pakietu z poprzedniego połączenia. W takim przypadku system operacyjny umożliwia nawiązanie nowego połączenia (akceptuje nowe połączenie SYN/ACK) i wymusza 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 udostępnia 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 maszyna wirtualna ma limit 1000 MB/s, ten limit ma zastosowanie, czy ruch wychodzący jest przeznaczony dla innej maszyny wirtualnej w tej samej sieci wirtualnej, czy spoza platformy Azure.
Przepływ wchodzą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 zobaczyć maksymalną przepustowość, wybierz typ, na przykład 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 liczą się do limitu wychodzącego ruchu.
Protokół: cały ruch wychodzący we wszystkich protokołach jest liczony do limitu.
Aby uzyskać więcej informacji, zobacz Przepustowość sieci maszyny wirtualnej.
Optymalizacja maszyn wirtualnych z systemem Linux
Nowoczesne jądra systemu Linux mają funkcje, które mogą pomóc w osiągnięciu spójności i wydajności, czasami wymagane przez niektóre obciążenia.
Aby uzyskać więcej informacji, zobacz Optymalizowanie przepustowości sieci na maszynach wirtualnych platformy Azure
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 przejścia w obie strony między dwoma punktami końcowymi jest wpływany przez problemy na sieciach pośrednich, ruch sieciowy, który nie wybiera 'najkrótszej' możliwej drogi, oraz przez nieoptymalne trasy peeringowe.
Utrata pakietów: utrata pakietów jest spowodowana przeciążeniem sieci, problemami ze ścieżkami fizycznymi i niedostateczną wydajnością urządzeń sieciowych.
Rozmiar jednostki MTU/Fragmentacja: Fragmentacja wzdłuż ścieżki może prowadzić do opóźnień w nadejściu danych lub do przychodzenia pakietów w niewłaściwej kolejności, co może wpływać na ich dostarczanie.
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 architektura centralna, która kieruje globalny ruch do jednej wirtualnej sieci centrali, powoduje opóźnienia w sieci, co wpływa 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. W modelu piasta-szprycha, jeśli ruch przechodzi przez wirtualne urządzenie sieciowe szprychy i urządzenie wirtualne koncentratora, zanim trafi do internetu, wirtualne urządzenia sieciowe wprowadzają pewne 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łowodu lub kilometrami światłowodu. 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 ma wpływ na konfigurację zestawów dostępności, grup umieszczania w pobliżu i stref 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 NAT
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. Platforma Azure dynamicznie mapuje prywatny adres IP na publiczny adres IP, gdy wystąpienie inicjuje połączenie wychodzące. Po utworzeniu tego mapowania przez platformę Azure, ruch powrotny związany z przepływem rozpoczętym wychodząco może także dotrzeć do prywatnego adresu IP, z którego się rozpoczął.
W przypadku każdego połączenia wychodzącego usługa Azure Load Balancer musi zachować to mapowanie przez pewien czas. Z uwagi na wielodostępny charakter platformy Azure, utrzymanie tego mapowania dla każdego przepływu wychodzącego dla każdej maszyny wirtualnej może być wymagające pod względem zasobów. Istnieją więc limity, które są ustawiane i oparte na konfiguracji sieci wirtualnej platformy Azure. Możesz też powiedzieć, że dokładniej maszyna wirtualna platformy Azure może wykonywać tylko niektóre połączenia wychodzące w danym momencie. Po osiągnięciu tych limitów maszyna wirtualna nie będzie wykonywać większej liczby połączeń wychodzących.
Jednak to zachowanie można skonfigurować. Aby uzyskać więcej informacji na temat SNAT i wyczerpania portów SNAT, zobacz ten artykuł.
Mierzenie wydajności sieci na platformie Azure
Wiele maksymalnych wartości wydajnościowych w tym artykule jest związanych z opóźnieniem sieciowym / czasem podróży w obie strony (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. Wprowadź wartości opóźnienia, jednostki MTU, MSS i rozmiaru okna w obliczeniach podanych wcześniej i porównaj teoretyczne wartości maksymalne z rzeczywistymi wartościami zaobserwowanymi podczas testowania.
Zmierzyć czas podróży w obie strony i utratę 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 pokazują minimalne/maksymalne/średnie opóźnienie między źródłem a miejscem docelowym. Pokazuje utratę pakietu. 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.
Polecenia ping protokołu ICMP i TCP nie mierzą ścieżki danych przyspieszonej sieci. Aby zmierzyć ścieżkę danych, przeczytaj informacje na temat latte i SockPerf w tym artykule.
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 aplikacji, systemu operacyjnego 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 duplikaty ACK są normalnym zjawiskiem w sieci. Protokoły TCP zostały skompilowane tak, aby były niezawodne. Obecność tych pakietów TCP w zapisie pakietów niekoniecznie wskazuje na systemowy problem sieciowy, chyba że występują w nadmiernej ilości.
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 rozważ zapoznanie się z innymi czynnikami planowania sieci wirtualnych. Możesz również dowiedzieć się więcej na temat łączenia i konfigurowania sieci wirtualnych.