Nejlepší praktiky pro souběžný běh Linuxu v Azure NetApp Files – Sloty relací a položky tabulky slotů

Tento článek vám pomůže pochopit osvědčené postupy souběžnosti pro sloty relací a položky tabulky slotů protokolu NFS služby Azure NetApp Files.

NFSv3

NFSv3 nemá mechanismus pro vyjednávání souběžnosti mezi klientem a serverem. Klient a server každý definuje svůj limit bez konzultace s druhým. Pro dosažení nejlepšího výkonu byste měli sladit maximální počet položek slotové tabulky na straně sunrpc klienta s těmi, které jsou podporovány bez zpětného odeslání na serveru. Když klient přetíží kapacitu síťového zásobníku serveru pro zpracování úlohy, server reaguje snížením velikosti okna pro připojení, což není ideálním výkonovým scénářem.

Ve výchozím nastavení moderní linuxová jádra definují velikost sunrpc položky tabulky slotů pro připojení sunrpc.tcp_max_slot_table_entries jako podporu 65 536 nevyřízených operací, jak je znázorněno v následující tabulce.

Server NFSv3 Azure NetApp Files Maximální počet kontextů spuštění na připojení	Klient Linuxu Maximální výchozí počet sunrpc položek tabulky slotů na připojení
128	65 536

Tyto položky tabulky slotů definují omezení souběžnosti. Hodnoty, které jsou vysoké, nejsou nutné. Například pomocí teorie fronty známé jako Littles Law zjistíte, že míra vstupně-výstupních operací je určena souběžností (tj. nevyřízených vstupně-výstupních operací) a latencí. Algoritmus například prokáže, že 65 536 slotů je řádově vyšší, než je potřeba k řízení i extrémně náročných úloh.

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

Úroveň souběžnosti již od 155 je dostatečná k dosažení 155 000 operací Oracle DB NFS za sekundu pomocí Oracle Direct NFS nconnect, což je technologie podobná možnosti připojení:

• Vzhledem k latenci 0,5 ms je potřeba souběžnost 55 k dosažení 110 000 I/OPS.
• Vzhledem k latenci 1 ms je potřeba souběžnost 155 k dosažení 155 000 I/OPS.

Podrobnosti najdete v tématu Výkon databáze Oracle na jednotlivých svazcích Azure NetApp Files.

Tunable sunrpc.tcp_max_slot_table_entries je parametr pro ladění na úrovni připojení. Osvědčeným postupem je nastavit tuto hodnotu na 128 nebo méně na připojení a nepřekročit 10 000 slotů v celém prostředí.

Příklady počtu slotů na základě doporučení pro souběžné zpracování

Příklady v této části ukazují počet slotů na základě doporučení pro souběžnost.

Příklad 1 – jeden NFS klient, 65 536 sunrpc.tcp_max_slot_table_entries, a žádné nconnect pro maximální souběžnost 128, podle limitu 128 na serverové straně.

Příklad 1 je založen na jedné úloze klienta s výchozí sunrpc.tcp_max_slot_table_entry hodnotou 65 536 a jedním síťovým připojením, to znamená ne nconnect. V tomto případě je souběžnost 128 dosažitelná.

• 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 může teoreticky vydat ne více než 65 536 požadavků současně na server na jedno připojení.
    • Server z tohoto jediného připojení nebude přijímat více než 128 požadavků.

Příklad 2 – jeden klient NFS, 128 sunrpc.tcp_max_slot_table_entriesa ne nconnect pro maximální souběžnost 128

Příklad 2 je založený na jedné úloze klienta s sunrpc.tcp_max_slot_table_entry hodnotou 128, ale bez nconnect možnosti připojení. Díky tomuto nastavení je souběžnost 128 dosažitelná z jednoho síťového připojení.

• 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 nebude vydávat více než 128 požadavků na server pro každé připojení.
    • Server z tohoto jediného připojení nebude přijímat více než 128 požadavků.

Příklad 3 – jeden klient NFS, 100 sunrpc.tcp_max_slot_table_entries a nconnect=8 pro maximální souběžnost 800

Příklad 3 je založený na jediném úkolu klienta, ale s nižší sunrpc.tcp_max_slot_table_entry hodnotou 100. Tentokrát se použitá nconnect=8 možnost připojení využila pro rozdělení pracovního zatížení mezi 8 připojení. Díky tomuto nastavení je souběžnost 800 dosažitelná napříč 8 připojeními. Toto je úroveň souběžnosti potřebná k dosažení 400 000 I/O operací za sekundu.

• 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)
  • Připojení 1
    • Klient z tohoto připojení odešle na server nejvýše 100 požadavků.
    • Očekává se, že server nebude přijímat více než 128 požadavků z klienta pro toto připojení.
  • Připojení 2
    • Klient z tohoto připojení odešle na server nejvýše 100 požadavků.
    • Očekává se, že server nebude přijímat více než 128 požadavků z klienta pro toto připojení.
  • …
  • …
  • Připojení 8
    • Klient z tohoto připojení odešle na server nejvýše 100 požadavků.
    • Očekává se, že server nebude přijímat více než 128 požadavků z klienta pro toto připojení.

Příklad 4 – 250 klientů NFS, 8 sunrpc.tcp_max_slot_table_entriesa ne nconnect pro maximální souběžnost 2000

Příklad 4 používá pro prostředí EDA 250 sníženou hodnotu na klienta sunrpc.tcp_max_slot_table_entry o 8. V tomto scénáři je dosaženo souběžnosti 2000 v celém prostředí, což je hodnota větší než dostatečná pro řízení 4 000 MiB/s úlohy back-endu EDA.

• 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 nebude mít více než osm požadavků současně na server na jedno připojení.
    • Server z tohoto jediného připojení nebude přijímat více než 128 požadavků.
• 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 nebude mít více než osm požadavků současně na server na jedno připojení.
    • Server z tohoto jediného připojení nebude přijímat více než 128 požadavků.
• …
• …
• 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 nebude mít více než osm požadavků současně na server na jedno připojení.
    • Server z tohoto jediného připojení nebude přijímat více než 128 požadavků.

Při použití NFSv3 byste měli společně zachovat počet slotů koncového bodu úložiště na 10 000 nebo méně. Nejlepší je nastavit hodnotu na připojení pro sunrpc.tcp_max_slot_table_entries na méně než 128, když se aplikace škáluje na mnoho síťových připojení, zejména v případě HPC a EDA.

Jak vypočítat to nejlepší sunrpc.tcp_max_slot_table_entries

Pomocí funkce Littles Law můžete vypočítat celkový požadovaný počet položek tabulky slotů. Obecně zvažte následující faktory:

• Scale-out úlohy mají často převážně sekvenční charakter.
• Databázové úlohy, zejména zpracování online transakcí, jsou často náhodné povahy.

Následující tabulka ukazuje ukázkovou studii souběžnosti s libovolnou latencí:

Velikost I/O	Latence	Vstup/výstup nebo propustnost	Souběžnost
8 KiB	0,5 ms	110 000 I/OPS | 859 MiB/s	55
8 KiB	2 ms	400 000 I/OPS | 3 125 MiB/s	800
256 KiB	2 ms	16 000 I/OPS | 4 000 MiB/s	32
256 KiB	4 ms	32 000 I/OPS | 8 000 MiB/s	128

Výpočet nastavení souběžnosti podle počtu připojení

Například pokud je pracovní zatížení farmu EDA a 1 250 klientů všichni posílají pracovní zatížení do stejného koncového bodu úložiště, což je IP adresa úložiště, potom vypočítáte požadovanou I/O rychlost a rozdělíte souběžnost napříč farmou.

Předpokládejme, že úloha je 4 000 MiB/s pomocí průměrné velikosti operace 256 KiB a průměrné latence 10 ms. Pokud chcete vypočítat souběžnost, použijte následující vzorec:

(concurrency = operation rate × latency in seconds)

Výpočet odpovídá souběžnosti 160:

(160 = 16,000 × 0.010)

Vzhledem k tomu, že potřebujete 1 250 klientů, můžete bezpečně nastavit sunrpc.tcp_max_slot_table_entries 2 na klienta, abyste dosáhli 4 000 MiB/s. Můžete se však rozhodnout vytvořit rezervu tím, že nastavíte počet slotů na jednoho klienta na 4 nebo dokonce 8, přičemž zůstanete dobře pod doporučeným stropem 10 000 slotů.

Jak nastavit sunrpc.tcp_max_slot_table_entries na klientovi

1. Přidejte sunrpc.tcp_max_slot_table_entries=<n> do konfiguračního /etc/sysctl.conf souboru.
   Pokud se při ladění najde optimální hodnota nižší než 128, nahraďte hodnotu 128 odpovídajícím číslem.
2. Spusťte následující příkaz:
   $ sysctl -p
3. Připojte (nebo znovu připojte) všechny systémy souborů NFS, protože laditelný parametr se vztahuje pouze na připojení vytvořená po jeho nastavení.

NFSv4.1

V NFSv4.1 relace definují vztah mezi klientem a serverem. Bez ohledu na to, zda jsou připojené systémy souborů NFS umístěny nad jedním nebo více připojeními (jak je tomu v případě nconnect), platí pravidla pro relaci. Při nastavení relace klient a server vyjednávají maximální požadavky na relaci a uspokojuje se na nižších ze dvou podporovaných hodnot. Azure NetApp Files podporuje 180 nevyřízených požadavků a klienti Linuxu mají výchozí hodnotu 64. V následující tabulce jsou uvedené limity relací:

Server Azure NetApp Files NFSv4.1 Maximální počet příkazů na relaci	Klient Linuxu Výchozí maximální počet příkazů na relaci	Vyjednaný maximální počet příkazů pro sezení
180	64	64

Ačkoli mají klienti s Linuxem výchozí hodnotu 64 maximálních požadavků na relaci, hodnota max_session_slots je nastavitelná. Aby se změny projevily, vyžaduje se restartování. systool -v -m nfs Pomocí příkazu zobrazíte aktuální maximum používané klientem. Aby příkaz fungoval, musí být na místě alespoň jedno připojení NFSv4.1:

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

Chcete-li ladit max_session_slots, vytvořte konfigurační soubor pod /etc/modprobe.d takovým způsobem. Ujistěte se, že pro řádek v souboru nejsou žádné uvozovky. Jinak se tato možnost neprojeví.

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

Azure NetApp Files omezuje každou relaci na maximálně 180 příkazů. Proto zvažte maximální hodnotu 180, která je aktuálně konfigurovatelná. Klient nebude moct dosáhnout souběžnosti větší než 128, pokud není relace rozdělena mezi více než jedno připojení, protože Azure NetApp Files omezuje každé připojení na maximálně 128 příkazů NFS. Pokud chcete získat více než jedno připojení, doporučuje se použít možnost připojení nconnect a je vyžadována hodnota dvě nebo více.

Příklady očekávaných maxim souběžnosti

Příklady v této části ukazují očekávané maximum souběžnosti.

Příklad 1 – 64 max_session_slots a ne nconnect

Příklad 1 je založen na výchozím nastavení 64 max_session_slots a ne nconnect. Díky tomuto nastavení je souběžnost 64 dosažitelná, a to vše z jednoho síťového připojení.

• 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 vydá na server pro relaci maximálně 64 požadavků najednou.
    • Server nebude přijímat více než 64 požadavků od klienta během relace. (64 je vyjednaná hodnota.)

Příklad 2 – 64 max_session_slots a nconnect=2

Příklad 2 je založen na 64 max session_slots , ale s přidanou možností montáže nconnect=2. Souběžnost 64 je dosažitelná, ale rozdělená mezi dvě spojení. Ačkoli více připojení v tomto scénáři nepřináší větší souběžnost, menší hloubka fronty pro každé připojení má pozitivní dopad na latenci.

max_session_slots stále na 64, ale nconnect=2 všimněte si, že maximální počet požadavků se rozdělí mezi připojení.

• 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)
  • Připojení 1
    • Klient z tohoto připojení neodešle na server více než 32 požadavků.
    • Očekává se, že server nebude přijímat více než 32 aktuálně zpracovávaných požadavků od klienta pro toto připojení.
  • Připojení 2
    • Klient z tohoto připojení neodešle na server více než 32 požadavků.
    • Očekává se, že server nebude přijímat více než 32 aktuálně zpracovávaných požadavků od klienta pro toto připojení.

Příklad 3 – 180 max_session_slots a ne nconnect

Příklad 3 vypustí možnost připojení nconnect a nastaví hodnotu max_session_slots na 180, což odpovídá maximální souběžnosti relace NFSv4.1 na serveru. V tomto scénáři, jakmile je k dispozici pouze jedno připojení a danému maximu 128 nevyřízených operací Azure NetApp Files na jedno připojení NFS, je relace omezená na 128 operací současně.

I když max_session_slots je nastavená hodnota 180, jedno síťové připojení je omezené na 128 maximálních požadavků, jako například:

• 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 vydá na server pro relaci maximálně 180 požadavků.
    • Server nebude přijímat více než 180 požadavků od klienta pro danou relaci.
    • Server nebude přijímat více než 128 požadavků na jedno připojení.

Příklad 4 – 180 max_session_slots a nconnect=2

Příklad 4 přidá nconnect=2 volbu připojení a znovu použije hodnotu 180 max_session_slots. Vzhledem k tomu, že je celkové zatížení rozděleno mezi dvě připojení, je možné dosáhnout 180 nevyřízených operací.

Se dvěma zapojenými připojeními relace podporuje úplné přidělení 180 nevyřízených požadavků.

• 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)
  • Připojení 1
    • Očekává se, že klient nebude uchovávat více než 90 požadavků na server z připojení.
    • Očekává se, že server bude v rámci relace zpracovávat maximálně 90 požadavků klienta pro toto připojení.
  • Připojení 2
    • Očekává se, že klient nebude uchovávat více než 90 požadavků na server z připojení.
    • Očekává se, že server bude v rámci relace zpracovávat maximálně 90 požadavků klienta pro toto připojení.

Poznámka:

Pro maximální souběžnost nastavte max_session_slots hodnotu 180, což je maximální souběžnost na úrovni relace podporovaná službou Azure NetApp Files.

Postup ověření maximálního počtu nevyřízených požadavků v relaci

Pokud chcete zobrazit session_slot velikosti podporované klientem a serverem, zachyťte příkaz mount v trasování paketů. Vyhledejte CREATE_SESSION hovor a CREATE_SESSION odpověď, jak je znázorněno v následujícím příkladu. Volání pochází z klienta a odpověď pochází ze serveru.

K zachycení příkazu mount použijte následující tcpdump příkaz:

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

Pomocí Wiresharku jsou pakety, které jsou zajímavé, následující:

V rámci těchto dvou paketů se podívejte na max_reqs pole v prostřední části trasovacího souboru.

• Systém souborů sítě
  • Operace
    • Opcode
      • csa_fore_channel_attrs
      • max reqs

Paket 12 (maximální počet požadavků klienta) ukazuje, že klient měl max_session_slots hodnotu 64. V další části si všimněte, že server podporuje paralelismus 180 v rámci relace. Sezení nakonec jedná o nižší ze dvou zadaných hodnot.

Následující příklad ukazuje paket 14 (maximální počet požadavků serveru):

Další kroky

• Osvědčené postupy pro přímé vstupně-výstupní operace Linuxu pro Azure NetApp Files
• Osvědčené postupy mezipaměti systému souborů Linuxu pro Azure NetApp Files
• Osvědčené postupy pro možnosti připojení systému souborů NFS pro Linux pro Azure NetApp Files
• Osvědčené postupy pro čtení systému souborů NFS pro Linux
• Osvědčené postupy pro SKU (skladové jednotky) virtuálních počítačů Azure
• Srovnávací testy výkonu pro Linux