Osvědčené postupy pro možnosti připojení systému souborů NFS pro Linux pro Azure NetApp Files
Tento článek vám pomůže pochopit možnosti připojení a osvědčené postupy pro jejich použití se službou Azure NetApp Files.
Nconnect
nconnect
Pomocí možnosti připojení můžete určit počet připojení (síťových toků), která by se měla navázat mezi klientem NFS a koncovým bodem NFS až do limitu 16. Klient systému souborů NFS tradičně používá jedno připojení mezi sebou a koncovým bodem. Zvýšení počtu síťových toků výrazně zvyšuje horní limity vstupně-výstupních operací a propustnosti. Testování bylo zjištěno nconnect=8
, že je nejvýkonnější.
Při přípravě prostředí SAS GRID s více uzly pro produkční prostředí si můžete všimnout opakovatelného 30% snížení doby běhu z 8 hodin na 5,5 hodiny:
Možnost připojení | Časy spuštění úlohy |
---|---|
Ne nconnect |
8 hodin |
nconnect=8 |
5,5 hodiny |
Obě sady testů používaly stejný virtuální počítač E32-8_v4 a RHEL8.3 s nastavením na 15 MiB.
Při použití nconnect
mějte na paměti následující pravidla:
nconnect
služba Azure NetApp Files podporuje ve všech hlavních distribucích Linuxu, ale pouze v novějších verzích:Vydání Linuxu NFSv3 (minimální verze) NFSv4.1 (minimální verze) Redhat Enterprise Linux RHEL8.3 RHEL8.3 SUSE SLES12SP4 nebo SLES15SP1 SLES15SP2 Ubuntu Ubuntu18.04 Poznámka:
SLES15SP2 je minimální verze SUSE, která
nconnect
je podporována službou Azure NetApp Files pro NFSv4.1. Všechny ostatní verze, jak je uvedeno, jsou první verze, které funkci zavedlynconnect
.Všechna připojení z jednoho koncového bodu dědí
nconnect
nastavení prvního připojeného exportu, jak je znázorněno v následujících scénářích:Scénář 1:
nconnect
používá první připojení. Proto se všechna připojení ke stejnému koncovému bodu používajínconnect=8
.mount 10.10.10.10:/volume1 /mnt/volume1 -o nconnect=8
mount 10.10.10.10:/volume2 /mnt/volume2
mount 10.10.10.10:/volume3 /mnt/volume3
Scénář 2:
nconnect
První připojení nepoužívá. Proto se žádná připojení ke stejnému koncovému bodu nepoužijínconnect
, i kdyžnconnect
tam může být zadána žádná připojení.mount 10.10.10.10:/volume1 /mnt/volume1
mount 10.10.10.10:/volume2 /mnt/volume2 -o nconnect=8
mount 10.10.10.10:/volume3 /mnt/volume3 -o nconnect=8
Scénář 3:
nconnect
Nastavení se nerozšírují mezi samostatné koncové body úložiště.nconnect
se používá při montáži pocházející z10.10.10.10
, ale ne přípojnou z10.12.12.12
.mount 10.10.10.10:/volume1 /mnt/volume1 -o nconnect=8
mount 10.12.12.12:/volume2 /mnt/volume2
nconnect
může být použita ke zvýšení souběžnosti úložiště z jakéhokoli daného klienta.
Podrobnosti najdete v osvědčených postupech pro souběžnost Linuxu pro Azure NetApp Files.
Nconnect
úvahy
Nedoporučuje se používat nconnect
a sec=krb5*
připojovat možnosti společně. Při použití těchto dvou možností v kombinaci bylo pozorováno snížení výkonu.
Rozhraní GSS-API (Generic Security Standard Application Programming Interface) poskytuje aplikacím způsob ochrany dat odesílaných do partnerských aplikací. Tato data mohou být odeslána z klienta na jednom počítači na server na jiném počítači.
Při nconnect
použití v Linuxu se kontext zabezpečení GSS sdílí mezi všemi připojeními k určitému nconnect
serveru. TCP je spolehlivý přenos, který podporuje doručování paketů mimo pořadí, aby bylo možné zpracovávat pakety mimo pořadí v datovém proudu GSS pomocí posuvného okna s pořadovými čísly. Při přijetí paketů, které nejsou v okně sekvence, se kontext zabezpečení zahodí a vyjedná se nový kontext zabezpečení. Všechny zprávy odeslané v nyní zahozeném kontextu už nejsou platné, takže je nutné je odeslat znovu. Větší počet paketů v nconnect
nastavení způsobuje časté pakety mimo okno, které aktivují popsané chování. U tohoto chování nelze uvést žádné konkrétní procento snížení výkonu.
Rsize
a Wsize
Příklady v této části poskytují informace o přístupu k ladění výkonu. Možná budete muset provést úpravy tak, aby vyhovovaly vašim konkrétním potřebám aplikace.
wsize
A rsize
příznaky nastaví maximální velikost přenosu operace NFS. Pokud rsize
nebo wsize
nejsou zadané při připojení, klient a server vyjednávají největší velikost podporovanou dvěma servery. Azure NetApp Files i moderní linuxové distribuce v současné době podporují velikosti čtení a zápisu tak velké jako 1 048 576 bajtů (1 MiB). Pro zajištění nejlepší celkové propustnosti a latence však Azure NetApp Files doporučuje nastavit nastavení maximálně rsize
wsize
262 144 bajtů (256 K). Při použití rsize
a wsize
větší než 256 KiB můžete pozorovat zvýšení latence i snížení propustnosti.
Nasazení systému SAP HANA se škálováním na více instancí s pohotovostním uzlem na virtuálních počítačích Azure pomocí služby Azure NetApp Files na SUSE Linux Enterprise Serveru ukazuje 256 KiB rsize
a wsize
maximum následujícím způsobem:
sudo vi /etc/fstab
# Add the following entries
10.23.1.5:/HN1-data-mnt00001 /hana/data/HN1/mnt00001 nfs rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys 0 0
10.23.1.6:/HN1-data-mnt00002 /hana/data/HN1/mnt00002 nfs rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys 0 0
10.23.1.4:/HN1-log-mnt00001 /hana/log/HN1/mnt00001 nfs rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys 0 0
10.23.1.6:/HN1-log-mnt00002 /hana/log/HN1/mnt00002 nfs rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys 0 0
10.23.1.4:/HN1-shared/shared /hana/shared nfs rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys 0 0
Například SAS Viya doporučuje velikost čtení a zápisu 256-KiB a SAS GRID omezuje r/wsize
na 64 KiB a současně rozšiřuje výkon čtení o vyšší úroveň čtení pro připojení NFS. Podrobnosti najdete v osvědčených postupech pro čtení systému souborů NFS pro Azure NetApp Files .
Pro použití rsize
wsize
a:
- Velikosti náhodných vstupně-výstupních operací jsou často menší než
rsize
možnosti připojení awsize
možnosti připojení. Proto nejsou omezení. - Při použití mezipaměti systému souborů dojde k sekvenčníM vstupně-výstupním operacím v předdikované velikosti a
wsize
možnostmirsize
připojení, pokud není velikost souboru menší nežrsize
awsize
. - Operace, které obcházejí mezipaměť systému souborů, i když jsou stále omezené možnostmi
rsize
připojení,wsize
nejsou tak velké jako maximum určenérsize
hodnotou nebowsize
. Tato skutečnost je důležitá, pokud používáte generátory úloh, které mají tutodirectio
možnost.
Osvědčeným postupem při použití služby Azure NetApp Files je nejlepší celková propustnost a latence, která rsize
wsize
není větší než 262 144 bajtů.
Konzistenci blízko otevření a časovače atributů mezipaměti
Systém souborů NFS používá volný model konzistence. Konzistence je volná, protože aplikace nemusí při každém použití přejít do sdíleného úložiště a načíst data, a to scénář, který by měl obrovský dopad na výkon aplikace. Tento proces spravuje dva mechanismy: časovače atributů mezipaměti a konzistenci blízko otevření.
Pokud má klient úplné vlastnictví dat, to znamená, že se nesdílí mezi několika uzly nebo systémy, je zaručená konzistence. V takovém případě můžete snížit getattr
přístupové operace k úložišti a urychlit aplikaci vypnutím konzistence blízko otevření (cto
) (nocto
jako možnost připojení) a vypnutím časových limitů pro správu mezipaměti atributů (actimeo=600
jako možnost připojení se změní časovač na 10m oproti výchozím nastavením acregmin=3,acregmax=30,acdirmin=30,acdirmax=60
). V některých testech nocto
snižuje přibližně 65 až 70 % přístupových getattr
volání a úprava actimeo
těchto volání snižuje další 20 až 25 %.
Jak fungují časovače mezipaměti atributů
Atributy acregmin
, acregmax
, acdirmin
a acdirmax
řídit aktuálnost mezipaměti. Předchozí dva atributy určují, jak dlouho jsou atributy souborů důvěryhodné. Poslední dva atributy určují, jak dlouho jsou atributy samotného souboru adresáře důvěryhodné (velikost adresáře, vlastnictví adresáře, oprávnění adresáře). max
Atributy min
definují minimální a maximální dobu trvání, po kterou jsou atributy adresáře, atributy souboru a obsah mezipaměti souboru považovány za důvěryhodné. Mezi min
a max
, algoritmus slouží k definování doby, po kterou je položka uložená v mezipaměti důvěryhodná.
Představte si například výchozí acregmin
hodnoty a acregmax
hodnoty 3 a 30 sekund. Atributy se například opakovaně vyhodnocují pro soubory v adresáři. Po 3 sekundách se služba NFS dotazuje na aktuálnost. Pokud jsou atributy považovány za platné, klient zdvojnásobí důvěryhodnou dobu na 6 sekund, 12 sekund, 24 sekund a pak, protože maximum je nastaveno na 30, 30 sekund. Od tohoto okamžiku, dokud atributy uložené v mezipaměti nejsou považovány za zastaralé (v tomto okamžiku cyklu začíná), důvěryhodnost je definována jako 30 sekund, což je hodnota určená acregmax
.
Existují i jiné případy, které můžou těžit z podobné sady možností připojení, i když klienti nemají úplné vlastnictví, například pokud klienti používají data jako jen pro čtení a aktualizace dat se spravují prostřednictvím jiné cesty. U aplikací, které používají mřížky klientů, jako je EDA, hostování webů a vykreslování filmů a mají relativně statické datové sady (nástroje nebo knihovny EDA, webový obsah, texturová data), je typické chování v tom, že sada dat je z velké části uložena do mezipaměti na klientech. Existuje několik čtení a žádné zápisy. Do úložiště se vrací mnoho getattr
volání /access. Tyto datové sady se obvykle aktualizují prostřednictvím jiného klienta, který připojuje systémy souborů a pravidelně odesílá aktualizace obsahu.
V těchto případech existuje známá prodleva při vyzvednutí nového obsahu a aplikace stále funguje s potenciálně zastaralými daty. V těchto případech a actimeo
lze ji použít k řízení období, nocto
kdy je možné spravovat zastaralé data. Například v nástrojích a knihovnách EDA funguje dobře, actimeo=600
protože tato data se obvykle aktualizují zřídka. U malého hostování webů, kde klienti potřebují včas zobrazit aktualizace dat při úpravách svých webů, actimeo=10
může být přijatelné. U rozsáhlých webů, kde je obsah vložený do více systémů souborů, actimeo=60
může být přijatelný.
Použití těchto možností připojení výrazně snižuje zatížení do úložiště v těchto případech. (Například nedávné zkušenosti s EDA snižují vstupně-výstupní operace za sekundu na svazek nástroje z >150 K na ~6 K.) Aplikace můžou běžet výrazně rychleji, protože můžou důvěřovat datům v paměti. (Doba přístupu k paměti je nanosekundy vs. stovky mikrosekund pro getattr
/access v rychlé síti.)
Konzistence blízko otevření
Konzistenci blízko otevření ( cto
možnost připojení) zajišťuje, že bez ohledu na stav mezipaměti se při otevření nejnovějších dat pro soubor vždy zobrazí aplikace.
- Při procházení adresáře (
ls
ls -l
například) je vydána určitá sada rpc (vzdálená volání procedur). Server NFS sdílí své zobrazení systému souborů. Pokudcto
všichni klienti NFS přistupují k danému exportu systému souborů NFS, zobrazí se všem klientům stejný seznam souborů a adresářů. Aktuálnost atributů souborů v adresáři je řízena časovači mezipaměti atributů. Jinými slovy, pokudcto
se soubory použijí, se soubory zobrazují vzdáleným klientům, jakmile se soubor vytvoří a soubor se objeví v úložišti. - Při otevření souboru je obsah souboru zaručený čerstvě z pohledu serveru NFS.
Pokud dojde k konfliktu časování, kdy se obsah nedokončil vyprázdněním z počítače 1 při otevření souboru na počítači 2, počítač 2 přijme data, která jsou přítomné na serveru v době otevření. V tomto případě počítač 2 nenačte z souboru další data, dokud
acreg
se nedosadí časovač, a počítač 2 znovu zkontroluje aktuálnost mezipaměti ze serveru. Tento scénář lze pozorovat pomocí chvostu-f
z počítače 2, když se soubor stále zapisuje z počítače 1.
Bez otevřené konzistence
Pokud se nepoužije konzistence blízko otevření (nocto
), klient důvěřuje aktuálnosti aktuálního zobrazení souboru a adresáře, dokud nebudou porušeny časovače atributů mezipaměti.
Při procházení adresáře (
ls
ls -l
například) je vydána určitá sada rpc (vzdálená volání procedur). Klient vydá na server pouze volání aktuálního výpisu souborů, kdyžacdir
došlo k porušení hodnoty časovače mezipaměti. V tomto případě se nedávno vytvořené soubory a adresáře nezobrazují. Zobrazí se nedávno odebrané soubory a adresáře.Když je soubor otevřen, dokud je soubor stále v mezipaměti, vrátí se jeho obsah uložený v mezipaměti (pokud existuje) bez ověření konzistence se serverem NFS.
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 týkající se souběžnosti Linuxu pro službu Azure NetApp Files
- Osvědčené postupy pro čtení systému souborů NFS pro Linux
- Osvědčené postupy skladových položek virtuálních počítačů Azure
- Srovnávací testy výkonu pro Linux