Udostępnij za pośrednictwem

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

  • Artykuł

Ten artykuł pomaga zrozumieć najlepsze rozwiązania dotyczące współbieżności dla miejsc sesji i wpisów tabeli miejsc protokołu NFS 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 z obsługą bez wypychania na serwerze. Gdy klient przeciąża zdolność stosu sieciowego serwera do przetwarzania obciążenia, serwer reaguje, zmniejszając rozmiar okna dla połączenia, co nie jest idealnym scenariuszem wydajności.

Domyślnie nowoczesne jądra systemu Linux definiują rozmiar sunrpc.tcp_max_slot_table_entries wpisu tabeli dla gniazda połączenia sunrpc jako obsługę 65 536 wybitnych 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 155 jest wystarczający do osiągnięcia 155 000 operacji systemu plików Oracle DB NFS na sekundę przy użyciu systemu plików Oracle Direct NFS, co jest technologią podobną do nconnect opcji instalacji:

  • Biorąc pod uwagę opóźnienie 0,5 ms, wymagana jest współbieżność 55, aby osiągnąć 110 000 operacji we/wy na sekundę.
  • Biorąc pod uwagę opóźnienie 1 ms, wymagana jest współbieżność 155, aby osiągnąć 155 000 operacji we/wy na sekundę.

Oracle DNFS latency curve

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

Dostrajanie sunrpc.tcp_max_slot_table_entries jest parametrem dostrajania 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 miejsc 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_entriesi nie 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 wydać do serwera nie więcej niż 65 536 żądań w locie na serwer na 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_entriesi nie 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_entriesi 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 instalacji użyła nconnect=8 rozłożenia obciążenia na 8 połączeń. Dzięki temu ustawieniu współbieżność 800 jest osiągalna w 8 połączeniach. Ta kwota jest współbieżnością wymaganą do osiągnięcia 400 000 operacji we/wy na sekundę.

  • 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 ion 1
      • Klient będzie wysyłać do serwera nie więcej niż 100 żądań w locie 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 ion 2
      • Klient będzie wysyłać do serwera nie więcej niż 100 żądań w locie 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 ion 8
      • Klient będzie wysyłać do serwera nie więcej niż 100 żądań w locie 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 na klienta sunrpc.tcp_max_slot_table_entry 8 dla 250 środowisk EDA z liczbą maszyn. W tym scenariuszu osiągnięto współbieżność z 2000 r. w całym środowisku— wartość większa niż wystarczająca do obsługi 4000 miB/s obciążenia EDA zaplecza.

  • 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ż 8 żą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ż 8 żą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ż 8 żą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 łącznie zachować liczbę miejsc punktu końcowego magazynu do 10 000 lub mniej. Najlepiej ustawić wartość sunrpc.tcp_max_slot_table_entries na połączenie na wartość mniejszą niż 128, gdy aplikacja skaluje się w poziomie między wieloma połączeniami sieciowymi (nconnect i HPC w szczególności, a w szczególności EDA).

Jak obliczyć najlepsze sunrpc.tcp_max_slot_table_entries

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

  • Skalowanie obciążeń w poziomie jest często często bardzo duże sekwencyjne.
  • Obciążenia baz danych, zwłaszcza OLTP, są często losowe.

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

Rozmiar we/wy Opóźnienie We/Wy lub przepływność Współbieżność
8 KiB 0,5 ms 110 000 operacji we/wy na sekundę | 859 MiB/s 55
8 KiB 2 ms 400 000 operacji we/wy na sekundę | 3125 MiB/s 800
256 KiB 2 ms 16 000 operacji we/wy na sekundę | 4000 MiB/s 32
256 KiB 4 ms 32 000 operacji we/wy na sekundę | 8000 MiB/s 128

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

Jeśli na przykład obciążenie jest farmą EDA i 1250 klientów obciążenie wszystkich dysków do tego samego punktu końcowego magazynu (punkt końcowy magazynu jest adresem IP magazynu), obliczysz wymaganą szybkość we/wy i podzielisz współbieżność w farmie.

Załóżmy, że obciążenie wynosi 4000 MiB/s przy użyciu 256-KiB średniego rozmiaru operacji i średnie opóźnienie wynoszące 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 budowę dodatkowego miejsca, ustawiając liczbę na klienta na 4 lub nawet 8, utrzymując się dobrze poniżej zalecanego pułapu gniazda 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 znajdują się na szczycie jednego połączenia, czy wielu (tak jak w przypadku nconnectprogramu ), mają zastosowanie reguły dla 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ślne maksymalne polecenia na sesję		 Wynegocjowane maksymalne polecenia dla sesji
180 64 64

Mimo że klienci systemu Linux domyślnie do 64 maksymalnych żą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_slotsplik konfiguracji, utwórz plik konfiguracji w obszarze /etc/modprobe.d . Upewnij się, że dla wiersza w pliku nie ma żadnych cudzysłowów. W przeciwnym razie opcja nie zacznie obowiązywać.

$ 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, zalecana nconnect jest opcja instalacji i wymagana jest wartość co najmniej dwóch.

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 sesji nie więcej niż 64 żądania w locie.
      • 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 wartości session_slots maksymalnej 64, ale z dodaną opcją nconnect=2instalacji . Współbieżność 64 jest osiągalna, ale podzielona 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.

max_session_slots Z nadal na poziomie 64, ale nconnect=2zwróć uwagę, że maksymalna liczba żądań jest podzielona 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 ion 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 ion 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 nconnect opcję instalacji i ustawia max_session_slots wartość 180, pasując do maksymalnej 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.

Mimo max_session_slots że ustawiono wartość 180, jedno połączenie sieciowe jest ograniczone do 128 maksymalnych żądań, takich jak:

  • 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ę instalacji 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 połączeń w grze sesja obsługuje pełne przydziały 180 zaległych żą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 ion 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 ion 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ć session_slot rozmiary obsługiwane przez klienta i serwer, przechwyć polecenie instalacji w ślad pakietu. CREATE_SESSION Poszukaj połączenia 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:

Screenshot that shows packets of interest.

W tych dwóch pakietach przyjrzyj max_reqs się polu w środkowej sekcji pliku śledzenia.

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

Pakiet 12 (maksymalna liczba żądań klienta) pokazuje, że klient miał max_session_slots wartość 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.

Screenshot that shows max session slots for Packet 12.

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

Screenshot that shows max session slots for Packet 14.

Następne kroki