Sdílet prostřednictvím

Osvědčené postupy pro možnosti připojení systému souborů NFS pro Linux pro Azure NetApp Files

  • Článek

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ím počtu síťových toků se výrazně zvýší 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í 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)
    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 zavedly nconnect .

  • Všechna připojení z jednoho koncového bodu zdě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í z 10.10.10.10 , ale ne přípojnou 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ě. 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 zadány 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ě rsizewsize 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í rsizewsizea:

  • Velikosti náhodných vstupně-výstupních operací jsou často menší než rsize možnosti připojení a wsize možnosti připojení. V důsledku toho nebudou omezeny.
  • 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žnostmi rsize připojení, pokud není velikost souboru menší než rsize a wsize.
  • Operace, které obcházejí mezipaměť systému souborů, i když jsou stále omezené možnostmi rsize připojení, wsize nemusí nutně vydávat tak velké, jako je maximum určené rsizewsizenebo . 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 nejlepší celková propustnost a latence, která rsizewsize 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řejít do sdíleného úložiště a načítat data pokaždé, když je použijete, 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 více 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, acdirmina 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 vrátí 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 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 (lsls -lnapříklad) je vydána určitá sada rpc (vzdálená volání procedur).
    Server NFS sdílí své zobrazení systému souborů. Pokud cto všichni klienti NFS přistupují k danému exportu systému souborů NFS, uvidí všichni klienti stejný seznam souborů a adresářů. Aktuálnost atributů souborů v adresáři je řízena časovači mezipaměti atributů. Jinými slovy, pokud cto 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 po otevření souboru na počítači 2 nedokončil vyprázdnění obsahu z počítače 1, počítač 2 obdrží data, která se nacházejí na serveru v době otevření. V tomto případě počítač 2 nebude z souboru načítat další data, dokud acreg se nedosáhl časovač, a počítač 2 znovu zkontroluje svoji 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 bude důvěřovat aktuálnosti aktuálního zobrazení souboru a adresáře, dokud nedojde k porušení časovačů atributů mezipaměti.

  • Při procházení adresáře (lsls -lnapří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 dojde k porušení hodnoty časovače mezipaměti. V tomto případě se nedávno vytvořené soubory a adresáře nezobrazí a nedávno odebrané soubory a adresáře se stále zobrazí.

  • 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