Udostępnij za pośrednictwem


Najlepsze rozwiązania dotyczące wydajności protokołu SMB dla usługi Azure NetApp Files

Ten artykuł ułatwia zrozumienie wydajności protokołu SMB i najlepszych rozwiązań dotyczących usługi Azure NetApp Files.

SMB Multichannel

Funkcja SMB Multichannel jest domyślnie włączona w udziałach SMB. Wszystkie udziały SMB wstępnie datowane na istniejące woluminy SMB miały włączoną funkcję, a wszystkie nowo utworzone woluminy będą również miały włączoną funkcję podczas tworzenia.

Każde połączenie SMB ustanowione przed włączeniem funkcji musi zostać zresetowane, aby móc korzystać z funkcji SMB Multichannel. Aby zresetować, możesz rozłączyć i ponownie połączyć udział SMB.

System Windows obsługuje protokół SMB Multichannel od systemu Windows 2012, aby zapewnić najlepszą wydajność. Aby uzyskać szczegółowe informacje, zobacz Deploy SMB Multichannel (Wdrażanie funkcji SMB Multichannel ) i Podstawowe informacje na temat funkcji SMB Multichannel .

Zalety funkcji SMB Multichannel

Funkcja SMB Multichannel umożliwia klientowi SMB3 ustanawianie puli połączeń za pośrednictwem jednej karty sieciowej lub wielu kart sieciowych i używania ich do wysyłania żądań dla pojedynczej sesji SMB. Natomiast zgodnie z projektem protokół SMB1 i SMB2 wymagają od klienta nawiązania jednego połączenia i wysłania całego ruchu SMB dla danej sesji za pośrednictwem tego połączenia. To pojedyncze połączenie ogranicza ogólną wydajność protokołu, którą można osiągnąć z jednego klienta.

Wydajność funkcji SMB Multichannel

Poniższe testy i wykresy pokazują możliwości funkcji SMB Multichannel w obciążeniach z pojedynczym wystąpieniem.

Losowe we/wy

Po wyłączeniu funkcji SMB Multichannel na kliencie czyste 4 testy odczytu i zapisu KiB zostały wykonane przy użyciu fio i zestawu roboczego 40 GiB. Udział SMB został odłączony między każdym testem z przyrostami liczby połączeń klienta SMB na ustawienia interfejsu 1sieciowego RSS ,4,8,16, set-SmbClientConfiguration -ConnectionCountPerRSSNetworkInterface <count>. Testy pokazują, że domyślne ustawienie 4 jest wystarczające dla obciążeń intensywnie korzystających z operacji we/wy; zwiększanie i 816 miało niewielki wpływ.

Polecenie netstat -na | findstr 445 udowodniło, że dodatkowe połączenia zostały nawiązane z przyrostami od 1 do i 48 do 16. Cztery rdzenie procesora CPU były w pełni używane dla protokołu SMB podczas każdego testu, co zostało potwierdzone przez statystykę wydajności Per Processor Network Activity Cycles (nieuwzględnianą w tym artykule).

Chart that shows random I/O comparison of SMB Multichannel.

Maszyna wirtualna platformy Azure nie ma wpływu na limity operacji we/wy magazynu SMB (ani NFS). Jak pokazano na poniższym wykresie, typ wystąpienia D32ds ma ograniczoną szybkość 308 000 dla buforowanych operacji we/wy na sekundę magazynu i 51 200 dla operacji we/wy na sekundę magazynu bez buforowania. Jednak powyższy wykres pokazuje znacznie więcej operacji we/wy za pośrednictwem protokołu SMB.

Chart that shows random I/O comparison test.

Sekwencyjne we/wy

Testy podobne do losowych testów we/wy opisanych wcześniej zostały wykonane z sekwencyjnymi we/wy 64 KiB. Chociaż wzrost liczby połączeń klienta na interfejs sieciowy RSS powyżej 4 nie miał zauważalnego wpływu na losowe we/wy, to samo nie dotyczy sekwencyjnych operacji we/wy. Jak pokazano na poniższym wykresie, każdy wzrost jest skojarzony z odpowiednim wzrostem przepływności odczytu. Przepływność zapisu pozostała płaska z powodu ograniczeń przepustowości sieci nakładanych przez platformę Azure dla każdego typu/rozmiaru wystąpienia.

Chart that shows throughput test comparison.

Platforma Azure umieszcza limity szybkości sieci dla każdego typu/rozmiaru maszyny wirtualnej. Limit szybkości jest nakładany tylko na ruch wychodzący. Liczba kart sieciowych znajdujących się na maszynie wirtualnej nie ma wpływu na łączną przepustowość dostępną dla maszyny. Na przykład typ wystąpienia D32ds ma nałożony limit sieci wynoszący 16 000 Mb/s (2000 MiB/s). Jak pokazuje powyższy wykres sekwencyjny, limit wpływa na ruch wychodzący (zapisy), ale nie odczyty wielokanałowe.

Chart that shows sequential I/O comparison test.

Podpisywanie protokołu SMB

Protokół SMB stanowi podstawę udostępniania plików i wydruku oraz innych operacji sieciowych, takich jak zdalne administrowanie systemem Windows. Aby zapobiec atakom typu man-in-the-middle, które modyfikują pakiety SMB podczas przesyłania, protokół SMB obsługuje cyfrowe podpisywanie pakietów SMB.

Podpisywanie SMB jest obsługiwane dla wszystkich wersji protokołu SMB obsługiwanych przez usługę Azure NetApp Files.

Wpływ na wydajność podpisywania SMB

Podpisywanie SMB ma wpływ na wydajność protokołu SMB. Wśród innych potencjalnych przyczyn obniżenia wydajności cyfrowe podpisywanie każdego pakietu zużywa dodatkowe procesory po stronie klienta, jak pokazano poniżej w danych wyjściowych wydajności. W takim przypadku core 0 jest wyświetlany jako odpowiedzialny za protokół SMB, w tym podpisywanie SMB. Porównanie z niekanałowymi liczbami przepływności odczytu sekwencyjnego w poprzedniej sekcji pokazuje, że podpisywanie SMB zmniejsza ogólną przepływność z 875MiB/s do około 250MiB/s.

Chart that shows SMB Signing performance impact.

Wydajność pojedynczego wystąpienia z zestawem danych o rozmiarze 1 TB

Aby zapewnić bardziej szczegółowy wgląd w obciążenia z kombinacjami odczytu/zapisu, na poniższych dwóch wykresach przedstawiono wydajność pojedynczego woluminu chmury na poziomie usługi Ultra 50 TB z zestawem danych o pojemności 1 TB i wielokanałowym SMB 4. Użyto optymalnego identyfikatora we/wy 16, a parametry elastycznego we/wy (FIO) były używane w celu zapewnienia pełnego wykorzystania przepustowości sieci (numjobs=16).

Na poniższym wykresie przedstawiono wyniki dla 4k losowych operacji we/wy z pojedynczym wystąpieniem maszyny wirtualnej i mieszanką odczytu/zapisu w 10% interwałach:

Chart that shows Windows 2019 standard _D32ds_v4 4K random IO test.

Na poniższym wykresie przedstawiono wyniki sekwencyjnego we/wy:

Chart that shows Windows 2019 standard _D32ds_v4 64K sequential throughput.

Wydajność podczas skalowania w górę przy użyciu 5 maszyn wirtualnych z zestawem danych o rozmiarze 1 TB

Te testy z 5 maszynami wirtualnymi używają tego samego środowiska testowego co pojedyncza maszyna wirtualna, a każdy proces zapisuje w swoim pliku.

Na poniższym wykresie przedstawiono wyniki losowych operacji we/wy:

Chart that shows Windows 2019 standard _D32ds_v4 4K 5-instance randio IO test.

Na poniższym wykresie przedstawiono wyniki sekwencyjnego we/wy:

Chart that shows Windows 2019 standard _D32ds_v4 64K 5-instance sequential throughput.

Jak monitorować karty ethernet funkcji Hyper-V

Jedną ze strategii używanych podczas testowania za pomocą fio jest ustawienie .numjobs=16 Dzięki temu rozwidlenia każdego zadania do 16 określonych wystąpień w celu zmaksymalizowania karty sieciowej funkcji Microsoft Hyper-V.

Możesz sprawdzić działanie na każdej karcie w systemie Windows monitor wydajności, wybierając pozycję monitor wydajności > Dodaj liczniki > interfejs > sieciowy Microsoft Hyper-V.

Screenshot that shows Performance Monitor Add Counter interface.

Po uruchomieniu ruchu danych w woluminach można monitorować karty w systemie Windows monitor wydajności. Jeśli nie używasz wszystkich tych 16 wirtualnych kart sieciowych, możesz nie zmaksymalizować pojemności sieci.

Screenshot that shows Performance Monitor output.

Szyfrowanie SMB

Ta sekcja ułatwia zrozumienie szyfrowania SMB (SMB 3.0 i SMB 3.1.1)

Szyfrowanie SMB zapewnia kompleksowe szyfrowanie danych SMB i chroni dane przed podsłuchiwaniem wystąpień w niezaufanych sieciach. Szyfrowanie SMB jest obsługiwane w protokole SMB w wersji 3.0 lub nowszej.

Podczas wysyłania żądania do magazynu klient szyfruje żądanie, które następnie odszyfrowuje magazyn. Odpowiedzi są podobnie szyfrowane przez serwer i odszyfrowywane przez klienta.

Szyfrowanie SMB jest obsługiwane w systemach Windows 10, Windows 2012 i nowszych.

Szyfrowanie SMB i usługa Azure NetApp Files

Szyfrowanie SMB jest włączone na poziomie udziału dla usługi Azure NetApp Files. Protokół SMB 3.0 wykorzystuje algorytm AES-CCM, podczas gdy protokół SMB 3.1.1 stosuje algorytm AES-GCM.

Szyfrowanie SMB nie jest wymagane. W związku z tym jest on włączony tylko dla danego udziału, jeśli użytkownik żąda włączenia go przez usługę Azure NetApp Files. Udziały usługi Azure NetApp Files nigdy nie są uwidocznione w Internecie. Są one dostępne tylko z poziomu danej sieci wirtualnej, za pośrednictwem sieci VPN lub usługi Express Route, więc udziały usługi Azure NetApp Files są z natury bezpieczne. Wybór włączenia szyfrowania SMB jest całkowicie do użytkownika. Przed włączeniem tej funkcji należy pamiętać o przewidywanej karze za wydajność.

Wpływ szyfrowania SMB na obciążenia klientów

Mimo że szyfrowanie SMB ma wpływ zarówno na klienta (obciążenie procesora CPU na szyfrowanie i odszyfrowywanie komunikatów), jak i magazyn (zmniejszenie przepływności), w poniższej tabeli przedstawiono tylko wpływ na magazyn. Przed wdrożeniem obciążeń w środowisku produkcyjnym należy przetestować wpływ na wydajność szyfrowania dla własnych aplikacji.

Profil we/wy Wpływ
Obciążenia odczytu i zapisu Od 10% do 15%
Intensywnie korzystające z metadanych 5%

Accelerated Networking

Aby uzyskać maksymalną wydajność, zaleca się skonfigurowanie przyspieszonej sieci na maszynach wirtualnych tam, gdzie to możliwe. Należy pamiętać o następujących kwestiach:

  • Witryna Azure Portal domyślnie włącza przyspieszoną sieć dla maszyn wirtualnych obsługujących tę funkcję. Jednak inne metody wdrażania, takie jak Ansible i podobne narzędzia konfiguracji, mogą nie być. Niepowodzenie włączenia przyspieszonej sieci może przyspieszyć wydajność maszyny.
  • Jeśli przyspieszona sieć nie jest włączona w interfejsie sieciowym maszyny wirtualnej ze względu na brak obsługi typu lub rozmiaru wystąpienia, pozostanie wyłączona z większymi typami wystąpień. W takich przypadkach potrzebna będzie interwencja ręczna.
  • Nie ma potrzeby ustawiania przyspieszonej sieci dla kart sieciowych w dedykowanej podsieci usługi Azure NetApp Files. Przyspieszona sieć to funkcja, która ma zastosowanie tylko do maszyn wirtualnych platformy Azure. Karty sieciowe usługi Azure NetApp Files są zoptymalizowane pod kątem projektowania.

RSS

Usługa Azure NetApp Files obsługuje skalowanie po stronie odbierającej (RSS).

Po włączeniu funkcji SMB Multichannel klient SMB3 ustanawia wiele połączeń TCP z serwerem SMB usługi Azure NetApp Files za pośrednictwem karty sieciowej obsługującej pojedynczą funkcję RSS.

Aby sprawdzić, czy karty sieciowe maszyny wirtualnej platformy Azure obsługują funkcję RSS, uruchom polecenie Get-SmbClientNetworkInterface w następujący sposób i sprawdź pole RSS Capable:

Screenshot that shows RSS output for Azure virtual machine.

Wiele kart sieciowych na klientach SMB

Nie należy konfigurować wielu kart sieciowych na kliencie dla protokołu SMB. Klient SMB będzie zgodny z liczbą kart interfejsu sieciowego zwróconą przez serwer SMB. Każdy wolumin magazynu jest dostępny z jednego i tylko jednego punktu końcowego magazynu. Oznacza to, że tylko jedna karta sieciowa będzie używana dla każdej relacji protokołu SMB.

Jak wynika z poniższych danych wyjściowych Get-SmbClientNetworkInterace , maszyna wirtualna ma 2 interfejsy sieciowe — 15 i 12. Jak pokazano w poniższym poleceniu Get-SmbMultichannelConnection, mimo że istnieją dwie karty sieciowe obsługujące funkcję RSS, tylko interfejs 12 jest używany w połączeniu z udziałem SMB; interfejs 15 nie jest używany.

Screeshot that shows output for RSS-capable NICS.

Następne kroki