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

Typ sdílené složky	SMB	NFS
Sdílené složky úrovně Standard (GPv2), LRS/ZRS
Sdílené složky úrovně Standard (GPv2), GRS/GZRS
Sdílené složky úrovně Premium (FileStorage), LRS/ZRS

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 jádra Linuxu starší než 5.4 nastavují hodnotu před čtením na ekvivalent 15krát připojeného systému rsizesouborů, což představuje možnost připojení na straně klienta pro velikost vyrovnávací paměti pro čtení. Tím se nastaví hodnota pro čtení dostatečně vysoká, aby se ve většině případů zlepšila propustnost sekvenčního čtení 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
   

Nconnect

Nconnect je možnost připojení linuxu na straně klienta, která zvyšuje výkon ve velkém, protože umožňuje používat více připojení TCP (Transmission Control Protocol) mezi klientem a službou Azure Premium Files pro NFSv4.1.

Výhody nconnect

Díky nconnecttomu 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í. Nconnect zvyšuje výkon pomocí více kanálů TCP na jednom nebo více síťových kartách pomocí jednoho nebo více klientů. Bez nconnecttoho 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 Azure úrovně Premium. Díky nconnecttomu 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)	64K, 1024K	3x
IOPS (čtení)	Všechny velikosti vstupně-výstupních operací	2–4x
Propustnost (zápis)	64K, 1024K	3x
Propustnost (čtení)	Všechny velikosti vstupně-výstupních operací	2–4x

Požadavky

• Nejnovější linuxové distribuce plně podporují nconnect. U starších linuxových distribucí se ujistěte, že je verze jádra Linuxu 5.3 nebo vyšší.
• Konfigurace připojení se podporuje jenom v případech, kdy se pro každý účet úložiště používá jedna sdílená složka přes privátní koncový bod.

Dopad na výkon nconnect

Při použití nconnect možnosti připojení 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í pro nconnect

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

Nastavit nconnect=4

Azure Files sice podporuje nastavení nconnect až do maximálního nastavení 16, ale doporučujeme nakonfigurovat možnosti připojení s optimálním nastavením nconnect=4. V současné době neexistují žádné zisky nad rámec čtyř kanálů pro implementaci nconnectsluž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 sytosti sítě TCP.

Pečlivě velikost virtuálních počítačů

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 neuvidíte žádné další zvýšení výkonu. Další informace najdete v tématu Hloubka fronty.

Nconnect konfigurace pro jednotlivé 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 nconnect nastaveními od jednoho klienta, nemůžeme zaručit, že se tato nastavení při připojování 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: nconnect Konfigurace pro 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: nconnect Konfigurace pro 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, že se tato adresa zachová, protože veřejné koncové body nejsou statické adresy.

Scénář 3: nconnect Konfigurace pro 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 Azure Files Úrovně Premium (zřízená 30 TiB, sada nconnect=4)

Velikost	Virtuální procesory	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ý počet vstupně-výstupních operací za sekundu: 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í 64k – 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

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

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ů

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

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

Velikost vstupně-výstupních operací 8k – 100% náhodný zápis - 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ů

Velikost vstupně-výstupních operací 64k – 100% náhodný zápis - 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

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

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)
• Úlohy čtení citlivé na latenci, které jsou s jedním vláknem nebo používají nízkou hloubku fronty v kombinaci s menšími vstupně-výstupními velikostmi

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