Udostępnij przez

Najlepsze rozwiązania dotyczące współbieżności systemu Linux dla usługi Azure NetApp Files — miejsca sesji i wpisy tabeli gniazd

Ten artykuł pomaga zrozumieć najlepsze praktyki dotyczące jednoczesności dla slotów sesji i wpisów tabeli slotów protokołu NFS dla usługi Azure NetApp Files.

NFSv3

System plików NFSv3 nie ma mechanizmu negocjowania współbieżności między klientem a serwerem. Klient i serwer definiują swój limit bez konsultacji z innymi. Aby uzyskać najlepszą wydajność, należy ustawić maksymalną liczbę wpisów tabeli gniazda po stronie sunrpc klienta, która jest obsługiwana przez serwer bez ograniczeń. Gdy klient przeciąża zdolność stosu sieciowego serwera do przetwarzania obciążenia, serwer reaguje przez zmniejszenie rozmiaru okna dla połączenia, co nie jest idealnym scenariuszem wydajności.

Domyślnie nowoczesne jądra systemu Linux definiują rozmiar sunrpc wpisu tabeli slotów sunrpc.tcp_max_slot_table_entries jako obsługującego 65 536 oczekujących operacji, jak pokazano w poniższej tabeli.

Serwer NFSv3 usługi Azure NetApp Files
Maksymalna liczba kontekstów wykonywania na połączenie		 Klient systemu Linux
Domyślne maksymalne sunrpc wpisy tabeli gniazd na połączenie.
128 65 536

Te wpisy tabeli gniazd definiują limity współbieżności. Wartości o tym wysokim poziomie są niepotrzebne. Na przykład, korzystając z teorii kolejkowania znanej jako Littles Law, okaże się, że współczynnik we/wy jest określany przez współbieżność (czyli zaległe operacje we/wy) i opóźnienie. W związku z tym algorytm dowodzi, że 65 536 miejsc jest o wiele większe niż to, co jest potrzebne do obsługi nawet bardzo wymagających obciążeń.

Littles Law: (concurrency = operation rate × latency in seconds)

Poziom współbieżności tak niski jak 155 jest wystarczający do osiągnięcia 155 000 operacji Oracle DB NFS na sekundę przy użyciu Oracle Direct NFS, co jest technologią podobną do opcji montowania nconnect.

  • Biorąc pod uwagę opóźnienie 0,5 ms, wymagana jest współbieżność 55 w celu osiągnięcia 110 000 I/OPS (operacji wejścia/wyjścia na sekundę).
  • Biorąc pod uwagę opóźnienie wynoszące 1 ms, do osiągnięcia 155 000 operacji we/wy wymagana jest współbieżność na poziomie 155.

Krzywa opóźnienia oracle DNFS

Aby uzyskać szczegółowe informacje, zobacz Wydajność bazy danych Oracle na pojedynczych woluminach usługi Azure NetApp Files.

Regulacja sunrpc.tcp_max_slot_table_entries jest parametrem regulacji na poziomie połączenia. Najlepszym rozwiązaniem jest ustawienie tej wartości na 128 lub mniej na połączenie, a nie przekraczanie 10 000 miejsc w całym środowisku.

Przykłady liczby gniazd na podstawie rekomendacji współbieżności

Przykłady w tej sekcji przedstawiają liczbę miejsc na podstawie rekomendacji współbieżności.

Przykład 1 — jeden klient NFS, 65 536 sunrpc.tcp_max_slot_table_entries, a brak nconnect dla maksymalnej współbieżności 128 na podstawie limitu po stronie serwera 128

Przykład 1 jest oparty na pojedynczym obciążeniu klienta z wartością domyślną sunrpc.tcp_max_slot_table_entry 65 536 i jednym połączeniem sieciowym, czyli bez nconnect. W takim przypadku współbieżność 128 jest osiągalna.

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
      • Klient teoretycznie może wysłać do serwera nie więcej niż 65 536 żądań jednocześnie na jedno połączenie.
      • Serwer będzie akceptować nie więcej niż 128 żądań w locie z tego pojedynczego połączenia.

Przykład 2 — jeden klient NFS, 128 sunrpc.tcp_max_slot_table_entries i bez nconnect dla maksymalnej współbieżności 128

Przykład 2 jest oparty na pojedynczym obciążeniu klienta o sunrpc.tcp_max_slot_table_entry wartości 128, ale bez nconnect opcji instalacji. Dzięki temu ustawieniu współbieżność 128 jest osiągalna z jednego połączenia sieciowego.

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
      • Klient będzie wysyłać do serwera nie więcej niż 128 żądań w locie na połączenie.
      • Serwer będzie akceptować nie więcej niż 128 żądań w locie z tego pojedynczego połączenia.

Przykład 3 — jeden klient NFS, 100 sunrpc.tcp_max_slot_table_entries, i nconnect=8 dla maksymalnej współbieżności 800

Przykład 3 jest oparty na pojedynczym obciążeniu klienta, ale o mniejszej sunrpc.tcp_max_slot_table_entry wartości 100. Tym razem opcja montowania nconnect=8 użyta do równomiernego rozłożenia obciążenia na 8 połączeń. Dzięki temu ustawieniu współbieżność 800 jest osiągalna w 8 połączeniach. Liczba ta to współbieżność wymagana do osiągnięcia 400 000 I/OPS.

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection 1 (10.10.10.10:2049, 10.10.10.11:6543,TCP), Connection 2 (10.10.10.10:2049, 10.10.10.11:6454,TCP)… Connection 8 (10.10.10.10:2049, 10.10.10.11:7321,TCP)
    • Połączenie 1
      • Klient wystawia nie więcej niż 100 żądań w locie do serwera z tego połączenia.
      • Oczekuje się, że serwer zaakceptuje nie więcej niż 128 żądań w locie od klienta dla tego połączenia.
    • Połączenie 2
      • Klient wystawia nie więcej niż 100 żądań w locie do serwera z tego połączenia.
      • Oczekuje się, że serwer zaakceptuje nie więcej niż 128 żądań w locie od klienta dla tego połączenia.
    • …
    • …
    • Połączenie 8
      • Klient wystawia nie więcej niż 100 żądań w locie do serwera z tego połączenia.
      • Oczekuje się, że serwer zaakceptuje nie więcej niż 128 żądań w locie od klienta dla tego połączenia.

Przykład 4 – 250 klientów NFS, 8 sunrpc.tcp_max_slot_table_entriesi nie nconnect dla maksymalnej współbieżności 2000

W przykładzie 4 użyto zmniejszonej wartości sunrpc.tcp_max_slot_table_entry na klienta wynoszącej 8 dla środowiska EDA z liczbą 250 maszyn. W tym scenariuszu osiągnięto współbieżność rzędu 2000 w całym środowisku, wartość więcej niż wystarczającą do napędzania obciążenia EDA zaplecza o przepustowości 4000 MiB/s.

  • NFS_Server=10.10.10.10, NFS_Client1=10.10.10.11
    • Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
      • Klient będzie wysyłać do serwera nie więcej niż osiem żądań w locie na połączenie.
      • Serwer będzie akceptować nie więcej niż 128 żądań w locie z tego pojedynczego połączenia.
  • NFS_Server=10.10.10.10, NFS_Client2=10.10.10.12
    • Connection (10.10.10.10:2049, 10.10.10.12:7820,TCP)
      • Klient będzie wysyłać do serwera nie więcej niż osiem żądań w locie na połączenie.
      • Serwer będzie akceptować nie więcej niż 128 żądań w locie z tego pojedynczego połączenia.
  • …
  • …
  • NFS_Server=10.10.10.10, NFS_Client250=10.10.11.13
    • Connection (10.10.10.10:2049, 10.10.11.13:4320,TCP)
      • Klient będzie wysyłać do serwera nie więcej niż osiem żądań w locie na połączenie.
      • Serwer będzie akceptować nie więcej niż 128 żądań w locie z tego pojedynczego połączenia.

W przypadku korzystania z systemu plików NFSv3 należy utrzymać całkowitą liczbę slotów punktów końcowych pamięci masowej na poziomie 10 000 lub mniej. Najlepiej ustawić wartość sunrpc.tcp_max_slot_table_entries dla poszczególnych połączeń na mniej niż 128, gdy aplikacja jest skalowana w poziomie na wiele połączeń sieciowych (nconnect i ogólnie HPC, a szczególnie EDA).

Jak obliczyć najlepsze sunrpc.tcp_max_slot_table_entries

Korzystając z Prawa Littlesa, można obliczyć łączną wymaganą liczbę wpisów tabeli slotów. Ogólnie rzecz biorąc, należy wziąć pod uwagę następujące czynniki:

  • Obciążenia skalowane w poziomie są często często bardzo duże sekwencyjne.
  • Obciążenia bazy danych, zwłaszcza przetwarzanie transakcji online, są często losowe.

W poniższej tabeli przedstawiono przykładowe badanie współbieżności z podanymi dowolnymi opóźnieniami:

Rozmiar wejścia/wyjścia Opóźnienie I/O lub przepustowość Współbieżność
8 KiB 0,5 ms 110 000 operacji IOPS | 859 MiB/s 55
8 KiB 2 ms 400 000 I/OPS | 3 125 MiB/s 800
256 KiB 2 ms 16 000 IOPS | 4000 MiB/s 32
256 KiB 4 ms 32 000 operacji IOPS | 8 000 MiB/s 128

Jak obliczyć ustawienia współbieżności według liczby połączeń

Na przykład, jeśli obciążenie to farma EDA i 1250 klientów wszystkie obciążają ten sam punkt końcowy magazynu (punkt końcowy magazynu to adres IP magazynu), wtedy obliczasz wymaganą szybkość we/wy i podzielisz obciążenie współbieżności w całej farmie.

Załóżmy, że obciążenie wynosi 4000 MiB/s przy średnim rozmiarze operacji 256 KiB i średnim opóźnieniu 10 ms. Aby obliczyć współbieżność, użyj następującej formuły:

(concurrency = operation rate × latency in seconds)

Obliczenie przekłada się na współbieżność 160:

(160 = 16,000 × 0.010)

Biorąc pod uwagę potrzebę 1250 klientów, można bezpiecznie ustawić sunrpc.tcp_max_slot_table_entries wartość 2 na klienta, aby osiągnąć 4000 MiB/s. Można jednak zdecydować się na zabezpieczenie dodatkowego marginesu, ustawiając liczbę na klienta na 4 lub nawet 8, utrzymując się znacznie poniżej zalecanego pułapu miejsc 10 000.

Jak ustawić sunrpc.tcp_max_slot_table_entries na kliencie

  1. Dodaj sunrpc.tcp_max_slot_table_entries=<n> do /etc/sysctl.conf pliku konfiguracji.
    Jeśli podczas dostrajania zostanie znaleziona optymalna wartość niższa niż 128, zastąp wartość 128 odpowiednią liczbą.
  2. Uruchom następujące polecenie:
    $ sysctl -p
  3. Zainstaluj (lub ponownie zainstaluj) wszystkie systemy plików NFS, ponieważ możliwość dostosowania ma zastosowanie tylko do instalacji wykonanych po ustawieniu możliwości dostosowania.

NFSv4.1

W systemie plików NFSv4.1 sesje definiują relację między klientem a serwerem. Niezależnie od tego, czy zainstalowane systemy plików NFS są oparte na jednym połączeniu, czy na wielu (tak jak w przypadku nconnect), obowiązują zasady sesji. Podczas konfigurowania sesji klient i serwer negocjują maksymalne żądania dla sesji, rozliczając się na dolnej z dwóch obsługiwanych wartości. Usługa Azure NetApp Files obsługuje 180 zaległych żądań, a klienci systemu Linux domyślnie to 64. W poniższej tabeli przedstawiono limity sesji:

Serwer NFSv4.1 usługi Azure NetApp Files
Maksymalna liczba poleceń na sesję		 Klient systemu Linux
Domyślna maksymalna liczba poleceń na sesję		 Wynegocjowane maksymalne polecenia dla sesji
180 64 64

Mimo że klienci systemu Linux domyślnie mają maksymalną liczbę 64 żądań na sesję, wartość parametru max_session_slots jest dostrajalna. Aby zmiany zaczęły obowiązywać, wymagany jest ponowny rozruch. Użyj polecenia , systool -v -m nfs aby wyświetlić bieżącą maksymalną wartość używaną przez klienta. Aby polecenie działało, musi istnieć co najmniej jedna instalacja NFSv4.1:

$ systool -v -m nfs
{
Module = "nfs"
...
  Parameters:
...
    max_session_slots   = "64"
...
}

Aby dostroić max_session_slots, utwórz plik konfiguracyjny w katalogu /etc/modprobe.d. Upewnij się, że dla tego wiersza w pliku nie ma żadnych cudzysłowów. W przeciwnym razie opcja nie zostanie w życie.

$ sudo echo “options nfs max_session_slots=180” > /etc/modprobe.d/nfsclient.conf $ sudo reboot

Usługa Azure NetApp Files ogranicza każdą sesję do 180 maksymalnych poleceń. W związku z tym należy wziąć pod uwagę 180 wartość maksymalną, która jest obecnie konfigurowalna. Klient nie będzie mógł osiągnąć współbieżności większej niż 128, chyba że sesja jest podzielona przez więcej niż jedno połączenie, ponieważ usługa Azure NetApp Files ogranicza każde połączenie z maksymalnie 128 poleceniami NFS. Aby uzyskać więcej niż jedno połączenie, rekomendowana jest opcja montażu nconnect, a wymagana jest wartość dwa lub większa.

Przykłady oczekiwanych maksymalnych współbieżności

Przykłady w tej sekcji przedstawiają oczekiwane maksimum współbieżności.

Przykład 1 – 64 max_session_slots i nie nconnect

Przykład 1 jest oparty na domyślnym ustawieniu 64 max_session_slots i nie nconnect. Dzięki temu ustawieniu współbieżność 64 jest osiągalna— wszystko z jednego połączenia sieciowego.

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
      • Klient będzie wysyłać do serwera podczas sesji jednocześnie nie więcej niż 64 żądania.
      • Serwer będzie akceptować nie więcej niż 64 żądań w locie od klienta dla sesji. (64 jest wartością wynegocjowaną).

Przykład 2 – 64 max_session_slots i nconnect=2

Przykład 2 jest oparty na 64 maksymalnie session_slots, ale z dodaną opcją instalacji nconnect=2. Osiągnięcie współbieżności 64 jest możliwe, ale wymaga podzielenia jej na dwa połączenia. Mimo że wiele połączeń nie przynosi większej współbieżności w tym scenariuszu, zmniejszona głębokość kolejki na połączenie ma pozytywny wpływ na opóźnienie.

Przy max_session_slots nadal na poziomie 64 i nconnect=2 zauważ, że maksymalna liczba żądań jest rozdzielana między połączenia.

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection 1 (10.10.10.10:2049, 10.10.10.11:6543,TCP) && Connection 2 (10.10.10.10:2049, 10.10.10.11:6454,TCP)
    • Połączenie 1
      • Klient będzie wysyłał nie więcej niż 32 żądania w locie do serwera z tego połączenia.
      • Oczekuje się, że serwer zaakceptuje nie więcej niż 32 żądania w locie od klienta dla tego połączenia.
    • Połączenie 2
      • Klient będzie wysyłał nie więcej niż 32 żądania w locie do serwera z tego połączenia.
      • Oczekuje się, że serwer zaakceptuje nie więcej niż 32 żądania w locie od klienta dla tego połączenia.

Przykład 3 – 180 max_session_slots i nie nconnect

Przykład 3 usuwa opcję montowania nconnect i ustawia wartość max_session_slots na 180, zgodnie z maksymalną współbieżnością sesji serwera NFSv4.1. W tym scenariuszu, z tylko jednym połączeniem i biorąc pod uwagę maksymalną operację zaległą usługi Azure NetApp Files 128 na połączenie NFS, sesja jest ograniczona do 128 operacji w locie.

Pomimo że max_session_slots zostało ustawione na 180, pojedyncze połączenie sieciowe jest ograniczone do maksymalnie 128 żądań.

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
      • Klient będzie wysyłać do serwera sesji nie więcej niż 180 żądań w locie.
      • Serwer będzie akceptować nie więcej niż 180 żądań w locie od klienta dla sesji.
      • Serwer będzie akceptować nie więcej niż 128 żądań w locie dla pojedynczego połączenia.

Przykład 4 – 180 max_session_slots i nconnect=2

Przykład 4 dodaje nconnect=2 opcję montowania i ponownie używa wartości 180 max_session_slots. Ponieważ ogólne obciążenie jest podzielone na dwa połączenia, 180 zaległych operacji jest osiągalnych.

W przypadku dwóch aktywnych połączeń sesja obsługuje pełny limit 180 otwartych żądań.

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection 1 (10.10.10.10:2049, 10.10.10.11:6543,TCP) && Connection 2 (10.10.10.10:2049, 10.10.10.11:6454,TCP)
    • Połączenie 1
      • Oczekuje się, że klient będzie obsługiwać nie więcej niż 90 żądań w locie do serwera z połączenia jeden.
      • Oczekuje się, że serwer będzie obsługiwać nie więcej niż 90 żądań w locie od klienta dla tego połączenia w ramach sesji.
    • Połączenie 2
      • Oczekuje się, że klient będzie obsługiwać nie więcej niż 90 żądań w locie do serwera z połączenia jeden.
      • Oczekuje się, że serwer będzie obsługiwać nie więcej niż 90 żądań w locie od klienta dla tego połączenia w ramach sesji.

Uwaga

W przypadku maksymalnej współbieżności ustaw max_session_slots wartość równą 180, czyli maksymalną współbieżność na poziomie sesji obsługiwaną obecnie przez usługę Azure NetApp Files.

Jak sprawdzić maksymalną liczbę żądań zaległych dla sesji

Aby wyświetlić rozmiary session_slot obsługiwane przez klienta i serwer, przechwyć polecenie mount w śladzie pakietów. Szukaj CREATE_SESSION rozmowy i CREATE_SESSION odpowiedzi, jak pokazano w poniższym przykładzie. Wywołanie pochodzi z klienta, a odpowiedź pochodzi z serwera.

Użyj następującego tcpdump polecenia, aby przechwycić polecenie instalacji:

$ tcpdump -i eth0 -s 900 -w /tmp/write.trc port 2049

Za pomocą narzędzia Wireshark pakiety zainteresowania są następujące:

Zrzut ekranu przedstawiający interesujące pakiety.

Spójrz na pole max_reqs w środkowej sekcji pliku śledzenia w tych dwóch pakietach.

  • System plików sieciowych
    • Operacji
      • Opcode
        • csa_fore_channel_attrs
        • max reqs

Pakiet 12 (maksymalna liczba żądań klienta) wskazuje, że klient miał wartość max_session_slots równą 64. W następnej sekcji zwróć uwagę, że serwer obsługuje współbieżność 180 dla sesji. Sesja kończy się negocjowaniem niższej z dwóch podanych wartości.

Zrzut ekranu przedstawiający maksymalną liczbę miejsc sesji dla pakietu 12.

W poniższym przykładzie przedstawiono pakiet 14 (maksymalna liczba żądań serwera):

Zrzut ekranu przedstawiający maksymalną liczbę miejsc sesji dla pakietu 14.

Następne kroki

  • Last updated on