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

Platí pro: ✔️ Sdílené složky NFS

Tento článek popisuje různé způsoby, jak zlepšit výkon sdílených složek Azure Files pomocí systému NFS. Témata zahrnují konfiguraci parametru linuxového jádra read_ahead_kb pro lepší sekvenční propustnost čtení, využití možnosti mountu nconnect pro škálování propustnosti s menším počtem klientských strojů a umístění vašeho úložného účtu do stejné dostupnosti jako vaši klienti pro snížení latence.

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 menší hodnota může snížit množství čtení u velkých souborů. Uživatelé přecházející z linuxových verzí s větší hodnotou předčtení na verze s výchozím 128 KiB mohou zaznamenat pokles výkonu sekvenčního čtení.

Pro linuxová jádra 5.4 nebo novější nastavte trvale read_ahead_kb na 15 MiB pro lepší 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 stačí spustit jednou, aby udev věděl o novém souboru.

   sudo udevadm control --reload
   

NFS nconnect

NFS nconnect je možnost připojení na straně klienta pro NFS sdílené soubory, kterou používáte k vytvoření více TCP spojení mezi klientem a vaším NFS souborovým sdílením. To je obzvlášť užitečné pro rozsáhlé úlohy, kde se jediné připojení TCP stává úzkým hrdlem.

Výhody nconnect

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 nconnect potřebujete přibližně 20 klientských strojů, abyste dosáhli limitů škálování šířky pásma (10 GiB/s), které nabízí největší velikost SSD pro sdílení souborů. 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

Předpoklady nconnect

• 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

Následující výsledky výkonu byly naměřeny při použití volby připojení nconnect se sdílenými složkami Azure Files protokolu NFS na klientech se systémem Linux ve velkém měřítku. Pro více informací o tom, jak byly tyto výsledky dosaženy, viz konfigurace testu výkonu.

Doporučení pro nconnect

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

Nastavit nconnect=4

Zatímco Azure Files podporuje nastavení nconnect na maximální hodnotu 16, možnosti připojení nastavte s 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 pracovní zátěž vyžaduje připojení více sdílených částí s jedním nebo více úložnými účty s různými nastaveními nconnect od jednoho klienta, není zaručeno, že nastavení přetrvávají při připojování přes veřejný endpoint. Konfigurace pro jednotlivá připojení podporuje pro každý účet úložiště pouze jednu sdílenou složku Azure Files prostřednictvím privátního koncového bodu, jak je popsáno ve scénáři 1.

Scénář 1: Konfigurace připojení prostřednictvím privátního koncového bodu 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řevede na jinou IP adresu, není zaručeno, že adresa přetrvá, 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ě (není podporováno)

• 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ů uvedených v tomto článku použijte následující zdroje a benchmarkingové nástroje.

• Jeden klient: Virtuální počítač Azure (DSv4-Series) s jedním síťovým rozhraním
• OS: Linux (Ubuntu 20.04)
• Úložiště NFS: Sdílená složka SSD (předem přidělená 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

Tyto testy využívají Flexible I/O Tester (FIO), bezplatný, open-source disk I/O nástroj, který slouží jak pro benchmarking, tak pro ověřování stresu nebo hardwaru. Pro instalaci FIO navštivte sekci Binary Packages v souboru FIO README a postupujte podle instrukcí pro platformu, kterou si vyberete.

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í

64 KiB velikost I/O - 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 KiB velikost I/O – 100% náhodný zápis – hloubka fronty 64

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 I/O 64 KiB – 100% náhodný zápis – hloubka fronty 64

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 pracovní zátěže vyžadují vysoký IOPS nebo výkonnost v propustnosti. U menších pracovních zátěží nconnect to nemusí být výhodné. 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í.

Použijte zónové umístění

U klasických sdílených složek vytvořených pomocí poskytovatele prostředků Microsoft.Storage doporučujeme použít zónové umístění a vybrat konkrétní zónu dostupnosti, ve které se nachází váš účet úložiště. To vám umožní umístit virtuální počítače do stejné zóny dostupnosti jako úložiště, což může snížit latenci až o 30 procent. Tato funkce je aktuálně dostupná jenom pro účty úložiště SSD využívající místně redundantní úložiště (LRS) v podporovaných oblastech.

Viz také

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