Share via

Zwiększanie wydajności udziałów plików platformy Azure w systemie plików NFS

  • Artykuł

W tym artykule wyjaśniono, jak zwiększyć wydajność udziałów plików platformy Azure w sieciowym systemie plików (NFS).

Dotyczy

Typ udziału plików SMB NFS
Udziały plików w warstwie Standardowa (GPv2), LRS/ZRS Nie, ten artykuł nie ma zastosowania do standardowych udziałów plików SMB platformy Azure LRS/ZRS. Udziały NFS są dostępne tylko w udziałach plików platformy Azure w warstwie Premium.
Udziały plików w warstwie Standardowa (GPv2), GRS/GZRS Nie, ten artykuł nie ma zastosowania do standardowych udziałów plików SMB platformy Azure GRS/GZRS. System plików NFS jest dostępny tylko w udziałach plików platformy Azure w warstwie Premium.
Udziały plików w warstwie Premium (FileStorage), LRS/ZRS Nie, ten artykuł nie dotyczy udziałów plików platformy Azure SMB w warstwie Premium. Tak, ten artykuł dotyczy udziałów plików platformy Azure w warstwie Premium NFS.

Zwiększanie rozmiaru z wyprzedzeniem odczytu w celu zwiększenia przepływności odczytu

read_ahead_kb Parametr jądra w systemie Linux reprezentuje ilość danych, które powinny być "odczytywane z wyprzedzeniem" lub pobierane wstępnie podczas operacji odczytu sekwencyjnego. Wersje jądra systemu Linux przed 5.4 ustawiają wartość z wyprzedzeniem odczytu na odpowiednik 15 razy zainstalowany system rsizeplików , który reprezentuje opcję instalacji po stronie klienta dla rozmiaru buforu odczytu. Spowoduje to ustawienie wartości odczytu na tyle wysokie, aby zwiększyć przepływność odczytu sekwencyjnego klienta w większości przypadków.

Jednak począwszy od jądra systemu Linux w wersji 5.4, klient systemu plików NFS systemu Linux używa wartości domyślnej read_ahead_kb 128 KiB. Ta mała wartość może zmniejszyć przepływność odczytu dla dużych plików. Klienci uaktualniając wersje systemu Linux z większą wartością z wyprzedzeniem odczytu do wersji z domyślną wartością 128 KiB mogą wystąpić spadek wydajności odczytu sekwencyjnego.

W przypadku jąder systemu Linux w wersji 5.4 lub nowszej zalecamy trwałe ustawienie wartości read_ahead_kb 15 MiB w celu zwiększenia wydajności.

Aby zmienić tę wartość, ustaw rozmiar z wyprzedzeniem odczytu, dodając regułę w ujściu menedżera urządzeń jądra systemu Linux. Wykonaj te kroki:

  1. W edytorze tekstów utwórz plik /etc/udev/rules.d/99-nfs.rules , wprowadzając i zapisując następujący tekst:

    SUBSYSTEM=="bdi" \
, ACTION=="add" \
, PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi) {ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
, ATTR{read_ahead_kb}="15360"

  2. W konsoli zastosuj regułę udev, uruchamiając polecenie udevadm jako superużytkownik i ponownie ładując pliki reguł i inne bazy danych. Aby rozpoznać nowy plik, wystarczy uruchomić to polecenie raz.

    sudo udevadm control --reload

Nconnect

Nconnect to opcja instalacji systemu Linux po stronie klienta, która zwiększa wydajność na dużą skalę, umożliwiając korzystanie z większej liczby połączeń protokołu TCP (Transmission Control Protocol) między klientem a usługą Azure Premium Files dla systemu plików NFSv4.1.

Korzyści wynikające z nconnect

Dzięki nconnectusłudze można zwiększyć wydajność na dużą skalę przy użyciu mniejszej liczby maszyn klienckich, aby zmniejszyć całkowity koszt posiadania (TCO). Nconnect zwiększa wydajność przy użyciu wielu kanałów TCP na co najmniej jednej kart sieciowych przy użyciu jednego lub wielu klientów. Bez nconnectsystemu potrzebujesz około 20 maszyn klienckich, aby osiągnąć limity skalowania przepustowości (10 GiB/s) oferowane przez największy rozmiar aprowizacji udziału plików platformy Azure w warstwie Premium. Dzięki nconnectusłudze można osiągnąć te limity przy użyciu tylko 6–7 klientów, zmniejszając koszty obliczeń o prawie 70% przy jednoczesnym zapewnieniu znaczących ulepszeń operacji we/wy na sekundę i przepływności na dużą skalę. Zobacz poniższą tabelę.

Metryka (operacja) Rozmiar we/wy Poprawa wydajności
Liczba operacji we/wy na sekundę (zapis) 64K, 1024K 3x
Liczba operacji we/wy na sekundę (odczyt) Wszystkie rozmiary we/wy 2–4x
Przepływność (zapis) 64K, 1024K 3x
Przepływność (odczyt) Wszystkie rozmiary we/wy 2–4x

Wymagania wstępne

  • Najnowsze dystrybucje systemu Linux w pełni obsługują program nconnect. W przypadku starszych dystrybucji systemu Linux upewnij się, że wersja jądra systemu Linux to 5.3 lub nowsza.
  • Konfiguracja instalacji jest obsługiwana tylko wtedy, gdy jeden udział plików jest używany na konto magazynu za pośrednictwem prywatnego punktu końcowego.

Wpływ na wydajność nconnect

Uzyskaliśmy następujące wyniki wydajności podczas korzystania z nconnect opcji instalacji z udziałami plików platformy Azure NFS na dużą skalę na klientach systemu Linux. Aby uzyskać więcej informacji na temat sposobu osiągnięcia tych wyników, zobacz Konfiguracja testu wydajnościowego.

Zrzut ekranu przedstawiający średnią poprawę liczby operacji we/wy na sekundę podczas korzystania z połączenia nconnect z udziałami plików platformy Azure NFS.

Zrzut ekranu przedstawiający średnią poprawę przepływności podczas korzystania z połączenia nconnect z udziałami plików platformy Azure NFS.

Rekomendacje dlanconnect

Postępuj zgodnie z tymi zaleceniami, aby uzyskać najlepsze wyniki z witryny nconnect.

Ustawić nconnect=4

Chociaż usługa Azure Files obsługuje konfigurowanie nconnect maksymalnie 16 ustawień, zalecamy skonfigurowanie opcji instalacji przy użyciu optymalnego nconnect=4ustawienia . Obecnie nie ma żadnych zysków poza czterema kanałami implementacji usługi Azure Files.nconnect W rzeczywistości przekroczenie czterech kanałów do pojedynczego udziału plików platformy Azure z jednego klienta może niekorzystnie wpłynąć na wydajność z powodu nasycenia sieci TCP.

Dokładne ustawianie rozmiaru maszyn wirtualnych

W zależności od wymagań dotyczących obciążenia ważne jest prawidłowe ustawianie rozmiaru maszyn wirtualnych klienta w celu uniknięcia ograniczenia ich oczekiwanej przepustowości sieci. Aby osiągnąć oczekiwaną przepływność sieci, nie potrzebujesz wielu kontrolerów interfejsu sieciowego. Chociaż często używane są maszyny wirtualne ogólnego przeznaczenia w usłudze Azure Files, różne typy maszyn wirtualnych są dostępne w zależności od potrzeb obciążeń i dostępności regionu. Aby uzyskać więcej informacji, zobacz Selektor maszyn wirtualnych platformy Azure.

Zachowaj głębokość kolejki mniejszą lub równą 64

Głębokość kolejki to liczba oczekujących żądań we/wy, które może obsłużyć zasób magazynu. Nie zalecamy przekraczania optymalnej głębokości kolejki wynoszącej 64, ponieważ nie zobaczysz jeszcze większej wydajności. Aby uzyskać więcej informacji, zobacz Głębokość kolejki.

Nconnect konfiguracja na instalację

Jeśli obciążenie wymaga instalowania wielu udziałów przy użyciu co najmniej jednego konta magazynu z różnymi nconnect ustawieniami jednego klienta, nie możemy zagwarantować, że te ustawienia będą utrwalane podczas instalowania w publicznym punkcie końcowym. Konfiguracja instalacji jest obsługiwana tylko wtedy, gdy jeden udział plików platformy Azure jest używany na konto magazynu za pośrednictwem prywatnego punktu końcowego zgodnie z opisem w scenariuszu 1.

Scenariusz 1: nconnect konfiguracja na instalację za pośrednictwem prywatnego punktu końcowego z wieloma kontami magazynu (obsługiwane)

  • StorageAccount.file.core.windows.net = 10.10.10.10
  • StorageAccount2.file.core.windows.net = 10.10.10.11
    • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
    • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

Scenariusz 2: nconnect konfiguracja instalacji za pośrednictwem publicznego punktu końcowego (nieobsługiwane)

  • StorageAccount.file.core.windows.net = 52.239.238.8
  • StorageAccount2.file.core.windows.net = 52.239.238.7
    • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
    • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
    • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

Uwaga

Nawet jeśli konto magazynu rozpozna inny adres IP, nie możemy zagwarantować, że ten adres będzie się powtarzać, ponieważ publiczne punkty końcowe nie są adresami statycznymi.

Scenariusz 3: nconnect konfiguracja na instalację za pośrednictwem prywatnego punktu końcowego z wieloma udziałami na jednym koncie magazynu (nieobsługiwane)

  • StorageAccount.file.core.windows.net = 10.10.10.10
    • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
    • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
    • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare3

Konfiguracja testu wydajnościowego

Użyliśmy następujących zasobów i narzędzi do testów porównawczych, aby osiągnąć i zmierzyć wyniki opisane w tym artykule.

  • Pojedynczy klient: maszyna wirtualna platformy Azure (seria DSv4) z pojedynczą kartą sieciową
  • System operacyjny: Linux (Ubuntu 20.40)
  • Magazyn NFS: udział plików Usługi Azure Files w warstwie Premium (aprowizowany 30 TiB, zestaw nconnect=4)
Rozmiar Procesor wirtualny Pamięć Magazyn tymczasowy (SSD) Maksymalna liczba dysków danych Maksymalna liczba kart sieciowych Oczekiwana przepustowość sieci
Standard_D16_v4 16 64 GiB Tylko magazyn zdalny 32 8 12 500 Mb/s

Narzędzia i testy testów porównawczych

Użyliśmy elastycznego testera we/wy (FIO), bezpłatnego narzędzia we/wy dysku typu open source używanego zarówno do weryfikacji porównawczej, jak i sprzętowej. Aby zainstalować program FIO, postępuj zgodnie z sekcją Pakiety binarne w pliku FIO README, aby zainstalować wybraną platformę.

Testy te koncentrują się na losowych wzorcach dostępu we/wy, ale uzyskujesz podobne wyniki podczas korzystania z sekwencyjnych operacji we/wy.

Duża liczba operacji we/wy na sekundę: odczyty na poziomie 100%

Rozmiar we/wy 4k — losowy odczyt — głębokość kolejki 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Rozmiar we/wy 8k — losowy odczyt — głębokość kolejki 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Wysoka przepływność: odczyty w 100%

Rozmiar operacji we/wy 64k — losowy odczyt — głębokość kolejki 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Rozmiar operacji we/wy 1024k — 100% losowego odczytu — głębokość kolejki 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Duża liczba operacji we/wy na sekundę: 100% operacji zapisu

Rozmiar operacji we/wy 4k — 100% losowego zapisu — 64 głębokość kolejki

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Rozmiar operacji we/wy 8k — 100% losowego zapisu — 64 głębokość kolejki

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Wysoka przepływność: 100% zapisów

Rozmiar operacji we/wy 64k — 100% losowego zapisu — 64 głębokość kolejki

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Rozmiar operacji we/wy 1024k — 100% losowego zapisu — głębokość kolejki 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Zagadnienia dotyczące wydajności nconnect

W przypadku korzystania z nconnect opcji instalacji należy dokładnie ocenić obciążenia, które mają następujące cechy:

  • Obciążenia zapisu wrażliwego na opóźnienia, które są pojedyncze wątkowe i/lub używają małej głębokości kolejki (mniej niż 16)
  • Obciążenia odczytu wrażliwe na opóźnienia, które są pojedyncze wątkowe i/lub używają małej głębokości kolejki w połączeniu z mniejszymi rozmiarami operacji we/wy

Nie wszystkie obciążenia wymagają dużej liczby operacji we/wy na sekundę lub w całej wydajności. W przypadku obciążeń o mniejszej nconnect skali może nie mieć sensu. Skorzystaj z poniższej tabeli, aby zdecydować, czy nconnect jest korzystne dla obciążenia. Zalecane są scenariusze wyróżnione kolorem zielonym, natomiast scenariusze wyróżnione na czerwono nie są. Scenariusze wyróżnione na żółto są neutralne.

Zrzut ekranu przedstawiający różne scenariusze odczytu i zapisu we/wy z odpowiednim opóźnieniem, aby wskazać, kiedy nconnect jest zalecane.

Zobacz też