Zvýšení výkonu sdílených složek Azure NFS

Tento článek vysvětluje, jak můžete zlepšit výkon sdílených složek Azure systému souborů NFS (Network File System).

Platí pro

Model správy	Model fakturace	Mediální vrstva	Přebytečnost	protokol SMB	NFS
Microsoft.Storage	Zajištěno v2	SSD (Premium)	Místní (LRS)
Microsoft.Storage	Zajištěno v2	SSD (Premium)	Zóna (ZRS)
Microsoft.Storage	Zajištěno v2	HDD (standard)	Místní (LRS)
Microsoft.Storage	Zajištěno v2	HDD (standard)	Zóna (ZRS)
Microsoft.Storage	Zajištěno v2	HDD (standard)	Geografie (GRS)
Microsoft.Storage	Zajištěno v2	HDD (standard)	GeoZone (GZRS)
Microsoft.Storage	Poskytnuto v1	SSD (Premium)	Místní (LRS)
Microsoft.Storage	Poskytnuto v1	SSD (Premium)	Zóna (ZRS)
Microsoft.Storage	Platba dle skutečné spotřeby	HDD (standard)	Místní (LRS)
Microsoft.Storage	Platba dle skutečné spotřeby	HDD (standard)	Zóna (ZRS)
Microsoft.Storage	Platba dle skutečné spotřeby	HDD (standard)	Geografie (GRS)
Microsoft.Storage	Platba dle skutečné spotřeby	HDD (standard)	GeoZone (GZRS)

Zvýšením velikosti pro čtení dopředu zvýšíte propustnost čtení.

Parametr read_ahead_kb jádra v Linuxu představuje množství dat, která by se měla "přečíst dopředu" nebo předem načíst během sekvenční operace čtení. Verze linuxových jader starších než 5.4 nastavují hodnotu přednačítání na ekvivalent 15násobku připojeného souborového systémursize, což představuje připojovací možnost na straně klienta pro velikost vyrovnávací paměti pro čtení. Tím se nastaví hodnota "read-ahead" dostatečně vysoká, aby se ve většině případů zlepšila sekvenční propustnost čtení u klienta.

Od jádra Linuxu verze 5.4 však klient systému Linux NFS používá výchozí read_ahead_kb hodnotu 128 KiB. Tato malá hodnota může snížit propustnost čtení velkých souborů. U zákazníků, kteří upgradují z linuxových verzí s vyšší hodnotou čtení na verze s výchozí hodnotou 128 KiB, může dojít ke snížení výkonu sekvenčního čtení.

Pro linuxová jádra 5.4 nebo novější doporučujeme trvale nastavit read_ahead_kb 15 MiB, aby se zlepšil výkon.

Pokud chcete tuto hodnotu změnit, nastavte dopředu velikost čtení přidáním pravidla v udev, což je správce zařízení jádra Linuxu. Postupujte následovně:

1. V textovém editoru vytvořte soubor /etc/udev/rules.d/99-nfs.rules zadáním a uložením následujícího textu:

   SUBSYSTEM=="bdi" \
   , ACTION=="add" \
   , PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi) {ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
   , ATTR{read_ahead_kb}="15360"
   

2. V konzole použijte pravidlo udev spuštěním příkazu udevadm jako superuživatele a opětovným načtením souborů pravidel a dalších databází. Tento příkaz je potřeba spustit jenom jednou, abyste udev věděli o novém souboru.

   sudo udevadm control --reload
   

Nfs nconnect

Nfs nconnect je možnost připojení na straně klienta pro sdílené složky NFS, která umožňuje používat více připojení TCP mezi klientem a sdílenou složkou NFS.

Výhody

S nconnect můžete zvýšit výkon ve velkém měřítku pomocí menšího počtu klientských počítačů, abyste snížili celkové náklady na vlastnictví. Funkce nconnect zvyšuje výkon pomocí více kanálů TCP na jednom nebo více síťových rozhraních pomocí jednoho nebo více klientů. Bez připojení byste potřebovali zhruba 20 klientských počítačů, abyste dosáhli limitů škálování šířky pásma (10 GiB/s), které nabízí největší velikost zřizování sdílených složek SSD. S připojením nconnect můžete dosáhnout těchto limitů pouze pomocí 6 až 7 klientů, což snižuje náklady na výpočetní prostředky téměř o 70% a současně poskytuje významná vylepšení vstupně-výstupních operací za sekundu (IOPS) a propustnost ve velkém měřítku. Viz následující tabulka.

Metrika (operace)	Velikost vstupně-výstupních operací	Zlepšení výkonu
IOPS (zápis)	64 KiB, 1 024 KiB	3x
IOPS (čtení)	Všechny velikosti vstupně-výstupních operací	2–4x
Propustnost (zápis)	64 KiB, 1 024 KiB	3x
Propustnost (čtení)	Všechny velikosti vstupně-výstupních operací	2–4x

Požadavky

• Nejnovější distribuce Linuxu plně podporují nconnect. U starších linuxových distribucí se ujistěte, že je verze jádra Linuxu 5.3 nebo vyšší.
• Konfigurace na úrovni připojení je podporována pouze tehdy, když je na úložišťový účet používán jeden sdílený souborový systém přes privátní koncový bod.

Dopad na výkon

Při použití možnosti připojení nconnect se sdílenými složkami Azure NFS ve velkém měřítku jsme dosáhli následujících výsledků výkonu. Další informace o tom, jak jsme tyto výsledky dosáhli, najdete v konfiguraci testu výkonnosti.

Doporučení

Pokud chcete dosáhnout nejlepších výsledků, nconnectpostupujte podle těchto doporučení.

Nastavit nconnect=4

Azure Files sice podporuje nastavení nconnect až k maximálnímu nastavení 16, ale doporučujeme nakonfigurovat možnosti připojení optimálním nastavením nconnect=4. V současné době neexistují žádné zisky nad rámec čtyř kanálů pro implementaci nconnect služby Azure Files. Překročení čtyř kanálů do jedné sdílené složky Azure z jednoho klienta může mít nepříznivý vliv na výkon kvůli přetížení sítě TCP.

Pečlivě dimenzujte virtuální počítače

V závislosti na požadavcích na úlohy je důležité správně nastavit velikost klientských virtuálních počítačů, aby se zabránilo omezení podle očekávané šířky pásma sítě. K dosažení očekávané propustnosti sítě nepotřebujete více řadičů síťového rozhraní. I když je běžné používat virtuální počítače pro obecné účely se službou Azure Files, různé typy virtuálních počítačů jsou dostupné v závislosti na vašich potřebách úloh a dostupnosti oblastí. Další informace najdete v tématu Výběr virtuálních počítačů Azure.

Zachovat hloubku fronty menší nebo rovnou 64

Hloubka fronty je počet nevyřízených vstupně-výstupních požadavků, které může prostředek úložiště obsluhovat. Nedoporučujeme překročit optimální hloubku fronty 64, protože to nepřinese žádné další zvýšení výkonu. Další informace najdete v tématu Hloubka fronty.

Konfigurace připojení

Pokud úloha vyžaduje připojení více sdílených složek s jedním nebo více účty úložiště s různými nastaveními nconnect z jednoho klienta, nemůžeme zaručit, že tato nastavení po připojení přes veřejný koncový bod zachovají. Konfigurace připojení se podporuje jenom v případě, že se pro každý účet úložiště používá jedna sdílená složka Azure přes privátní koncový bod, jak je popsáno ve scénáři 1.

Scénář 1: Konfigurace připojení přes privátní koncový bod s více účty úložiště (podporováno)

• StorageAccount.file.core.windows.net = 10.10.10.10
• StorageAccount2.file.core.windows.net = 10.10.10.11
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

Scénář 2: Konfigurace připojení přes veřejný koncový bod (nepodporuje se)

• StorageAccount.file.core.windows.net = 52,239,238,8
• StorageAccount2.file.core.windows.net = 52,239.238.7
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

Poznámka:

I když se účet úložiště přeloží na jinou IP adresu, nemůžeme zaručit zachování této adresy, protože veřejné koncové body nejsou statické adresy.

Scénář 3: Konfigurace připojení přes privátní koncový bod s více sdílenými složkami v jednom účtu úložiště (nepodporuje se)

• StorageAccount.file.core.windows.net = 10.10.10.10
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare3

Konfigurace testu výkonu

K dosažení a měření výsledků popsaných v tomto článku jsme použili následující zdroje informací a srovnávací nástroje.

• Jeden klient: Virtuální počítač Azure (DSv4-Series) s jedním síťovým rozhraním
• Operační systém: Linux (Ubuntu 20.40)
• Úložiště NFS: Sdílená složka SSD (zřízená 30 TiB, sada nconnect=4)

Velikost	vCPU	Paměť	Dočasné úložiště (SSD)	Maximální počet datových disků	Maximální počet síťových adaptérů	Očekávaná šířka pásma sítě
Standard_D16_v4	16	64 GiB	Pouze vzdálené úložiště	32	8	12 500 Mb/s

Srovnávací nástroje a testy

Použili jsme flexibilní I/V Tester (FIO), bezplatný opensourcový I/V nástroj pro vstupně-výstupní operace, který se používá k srovnávacímu testu i k ověření zatížení/hardwaru. Pokud chcete nainstalovat FIO, postupujte podle části Binární balíčky v souboru FIO README a nainstalujte platformu podle vašeho výběru.

I když se tyto testy zaměřují na vzory náhodného přístupu k vstupně-výstupním operacím, při použití sekvenčních vstupně-výstupních operací získáte podobné výsledky.

Vysoké IOPS: 100 % čtení

Velikost vstupně-výstupních operací 4k – náhodné čtení – hloubka fronty 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Velikost vstupně-výstupních operací 8k – náhodné čtení – hloubka fronty 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Vysoká propustnost: 100 % čtení

Velikost vstupně-výstupních operací KiB 64 KiB – náhodné čtení – hloubka fronty 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

1 024 velikost vstupně-výstupních operací KiB – 100% náhodné čtení – hloubka fronty 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Vysoká IOPS: 100 % zápisů

4 Velikost vstupně-výstupních operací KiB – 100% náhodný zápis – hloubka fronty 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

8 Velikost vstupně-výstupních operací KiB – 100% náhodného zápisu – 64 hloubky fronty

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Vysoká propustnost: 100 % zápisů

64 Velikost vstupně-výstupních operací KiB – 100% náhodného zápisu – 64 hloubka fronty

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

1024 Velikost vstupně-výstupních operací KiB – 100% náhodného zápisu – hloubka fronty 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Důležité informace o výkonu pro nconnect

Při použití nconnect možnosti připojení byste měli pečlivě vyhodnotit úlohy, které mají následující charakteristiky:

• Úlohy zápisu citlivé na latenci, které jsou s jedním vláknem nebo používají nízkou hloubku fronty (menší než 16)
• Jednovláknové úlohy čtení citlivé na latenci, nebo ty, které používají nízkou hloubku fronty v kombinaci s menšími velikostmi I/O

Ne všechny úlohy vyžadují vysoce škálovatelné IOPS nebo v celém výkonu. U menších úloh nemusí nconnect dávat smysl. V následující tabulce se můžete rozhodnout, jestli nconnect je pro vaši úlohu výhodné. Scénáře zvýrazněné zelenou barvou se doporučují, zatímco scénáře zvýrazněné červeně nejsou. Scénáře zvýrazněné žlutou barvou jsou neutrální.

Viz také

• Připojení sdílené složky NFS k Linuxu
• Seznam možností připojení
• Vysvětlení výkonu služby Azure Files