Sdílet prostřednictvím

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

Pomocí možnosti připojení nconnect můžete zadat počet spojení (síťových spojení), která se mají navázat mezi klientem NFS a koncovým bodem NFS, s maximálním limitem 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í ukázalo, že nconnect=8 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 read-ahead na 15 MiB.

Při použití nconnectmě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)
    Red Hat Enterprise Linux RHEL8.3 RHEL8.3
    SUSE SLES12SP4 nebo SLES15SP1 SLES15SP2
    Ubuntu Ubuntu18.04

    Poznámka:

    Minimální verzí SUSE, která je službou Azure NetApp Files podporována pro NFSv4.1, je SLES15SP2. Všechny ostatní verze, jak je specifikováno, jsou první verze, které zavedly funkci nconnect.

  • 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 všechna přiřazení 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 není použito prvním připojením. Proto se žádná připojení ke stejnému koncovému bodu nepoužijí nconnect, i když nconnect může být na něm zadáno.

    • 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 je používán montáží pocházející z 10.10.10.10, ale ne montáží pocházející z 10.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ě. Použití těchto možností může způsobit 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 sekvenčním okně, je bezpečnostní kontext zahozen a je vyjednáván nový bezpečnostní kontext. 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.

rsize A wsize 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 oba rsize a wsize na maximálně 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ě zvyšuje výkon čtení díky rozšířenému předčítání pro připojení NFS. Další podrobnosti najdete o osvědčených postupech pro čtení dopředu NFS v Azure NetApp Files.

Při použití rsize a wsize platí následující úvahy:

  • Velikosti náhodných vstupně-výstupních operací jsou často menší než možnosti připojení zadané jako rsize a wsize. Proto nejsou omezení.
  • Při použití mezipaměti systému souborů dojde k sekvenčním vstupně-výstupním operacím ve velikosti určené možnostmi připojení rsize a wsize, pokud není velikost souboru menší než rsize nebo wsize.
  • Operace, které obcházejí mezipaměť systému souborů, i když jsou stále omezené možnostmi připojení rsize a wsize, nejsou tak velké jako maximum určené hodnotou rsize nebo wsize. Tato skutečnost je důležitá, pokud používáte generátory úloh, které mají tuto directio možnost.

Osvědčeným postupem při použití služby Azure NetApp Files je pro nejlepší celkovou propustnost a latenci nastavit rsize a wsize nejvýše na 262 144 bajtů.

Konzistence při otevírání 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, což by mělo obrovský dopad na výkon aplikace. Tento proces spravují dva mechanismy: časovače atributů mezipaměti a konzistence blízká k 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 typu close-to-open (cto) (nocto jako možnost připojení) a zvýšením časových limitů pro správu mezipaměti atributů (actimeo=600 jako možnost připojení mění časovač na 10 minut 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 řídí soudržnost 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). min Atributy max 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í hodnoty acregmin a acregmax, které jsou 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 na maximální hodnotu 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é mohou těžit z podobné sady možností připojení, i když klienti nemají plné vlastnictví, například pokud klienti používají data pouze pro čtení a aktualizace dat jsou spravovány jinou cestou. 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. Je jen málo čtení a žádné zápisy. Do úložiště se vrací mnoho getattrvolá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 lze nocto a actimeo použít k řízení období, ve kterém lze spravovat data, která nejsou aktuální. 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é testování s EDA snížilo počet vstupně-výstupních operací za sekundu na svazek nástroje z >150 K na ~6 K.) Aplikace mohou běžet výrazně rychleji, protože mohou 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í

Konzistence při otevření (volba připojení cto) zajišťuje, že bez ohledu na stav mezipaměti se při otevření souboru aplikaci vždy zobrazí jeho nejnovější data.

  • Při procházení adresáře (ls, napříkladls -l) se vydá určitá sada RPCs (vzdálená volání procedur). Server NFS sdílí své zobrazení systému souborů. Pokud všichni klienti NFS používají cto při přístupu k danému exportu 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, pokud je použito cto, soubory se zobrazují vzdáleným klientům, jakmile jsou vytvořeny a přemístěny do úložiště.
  • Při otevření souboru je jeho obsah zaručen jako aktuální z hlediska serveru NFS. Pokud dojde k podmínce závodu, kdy obsah nebyl dokončen při vyprázdnění z počítače 1 při otevření souboru na počítači 2, počítač 2 přijme pouze data, která jsou přítomná na serveru v době otevření souboru. V tomto případě počítač 2 nenačte ze souboru další data, dokud neuplyne časovač acreg, a počítač 2 znovu zkontroluje koherenci mezipaměti ze serveru. Tento scénář lze pozorovat pomocí příkazu tail -f z počítače 2, když je soubor stále zapisován z počítače 1.

Žádná konzistence mezi uzavřením a otevřením

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, napříkladls -l) se vydá určitá sada RPCs (vzdálená volání procedur). Klient odešle požadavek na server pro aktuální seznam souborů pouze tehdy, když byla překročena hodnota č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

  • Last updated on