Řešení Dell EMC Ready pro vysokovýkonnostní úložiště HPC BeeGFS

Článek napsal(a) Nirmala Sundararajan z oddělení Dell EMC HPC and AI Innovation Lab v listopadu 2019.

Řešení Dell EMC Ready pro vysokovýkonnostní úložiště HPC BeeGFS

Obsah

1. Úvod
2. Referenční architektura řešení
3. Konfigurace hardwaru a softwaru
4. Podrobnosti o konfiguraci řešení
   • Služba správy
   • Služba metadat
   • Služba úložiště
   • Služba klienta
5. R740xd – 24 disků NVMe, podrobnosti o mapování procesoru
6. Charakteristika výkonu
   • Sekvenční čtení a zápis N-N
   • Náhodné čtení a zápis N-N
7. Závěr a budoucí práce
    

Úvod

Referenční architektura řešení

Konfigurace hardwaru a softwaru

Tabulka 1 a 2 popisují specifikace hardwaru serveru pro správu a serveru metadat / úložného serveru. Tabulka 3 popisuje verze softwaru používané pro řešení.

Podrobnosti o konfiguraci řešení

• Služba správy
• Služba metadat
• Služba úložiště
• Služba klienta

Služba správy

Služba metadat

Obrázek 3:  Server metadat

Obrázek 4 znázorňuje konfiguraci pole RAID serveru metadat. Jde na něm vidět, jak disky v serveru metadat v zóně NUMA 0 hostují cíle MDT a disky v zóně NUMA 1 hostují data úložiště, zatímco servery úložiště hostují cíle ST v obou zónách NUMA.

Služba úložiště

1. Výkon zápisu byl měřen pomocí příkazu dd a vytvořením 10GiB souboru s velikostí bloku 1MiB a přímými operacemi I/O pro data. U zařízení RAID 0 činil průměr na každé zařízení přibližně 5,1 GB/s, zatímco u zařízení RAID 10 byl průměr na každé zařízení 3,4 GB/s.
2. Srovnávací testy StorageBench ukázaly, že maximální propustnost byla 5,5 GB/s pro konfiguraci RAID 0, zatímco u konfigurace RAID 10 činila 3,4 GB/s. Tyto výsledky se podobají výstupům příkazů dd.
3. Pole RAID 10 poskytuje 50% využití kapacity disku a podobné 50% snížení výkonu zápisu. Používání pole RAID 10 je nákladný způsob, jak dosáhnout redundance úložiště.
4. Disky NVMe jsou nákladné a nabízejí rychlosti, které se nejlépe využijí v konfiguraci RAID 0.

Služba klienta

$ cat /etc/beegfs/beegfs-mounts.conf
/mnt/beegfs-medium /etc/beegfs/beegfs-client-medium.conf
/mnt/beegfs-small /etc/beegfs/beegfs-client-small.conf

R740xd – 24 disků NVMe, podrobnosti o mapování procesoru

# cat /proc/sys/kernel/numa_balancing
0

Charakteristika výkonu

Sekvenční zápis a čtení N-N

K vyhodnocení srovnávacího testu sekvenčního čtení a zápisu byl použit benchmark IOzone v režimu sekvenčního čtení a zápisu. Tyto testy byly provedeny s několika počty vláken, počínaje jedním vláknem, které narůstaly o mocniny 2 až po 1 024 vláken. Při každém počtu vláken byl vygenerován stejný počet souborů, protože tento test funguje na jeden soubor na vlákno nebo na případ N-N (N klientů na N soubor). Procesy byly distribuovány napříč 32 fyzickými uzly klienta v kruhovém dotazování nebo cyklickým způsobem tak, aby byly požadavky rovnoměrně distribuovány a zatížení bylo vyvažováno. Byla vybrána souhrnná velikost souboru 8 TB, která byla rovnoměrně rozdělena mezi počet vláken v rámci daného testu. Byl zvolen dostatečně velký soubor, aby se minimalizoval dopad ukládání do cache ze serverů i z klientů BeeGFS. Test IOzone byl spuštěn v kombinovaném režimu zápisu a poté čtení (-i 0, -i 1), aby bylo možné koordinovat hranice mezi operacemi. Pro toto testování a výsledky jsme při každém spuštění používali velikost záznamu 1 MiB. Níže jsou uvedeny příkazy použité pro sekvenční testy N-N:

Sekvenční zápisy a čtení: iozone -i 0 -i 1 -c -e -w -r 1m -I -s $Size -t $Thread -+n -+m /path/to/threadlist

Cache operačního systému byly také zahozeny nebo vymazány v klientských uzlech mezi iteracemi a mezi testy zápisu a čtení spuštěním příkazu:

# sync & echo 3 > /proc/sys/vm/drop_caches

Výchozí počet prokládání u úložiště Beegfs je 4. Velikost bloku a počet cílů na jeden soubor však lze konfigurovat pro jednotlivé adresáře. Pro všechny tyto testy byla velikost prokládání BeeGFS 2 MB a počet prokládání byl 3, protože máme 3 cíle na 1 zónu NUMA, jak je znázorněno níže:

$ beegfs-ctl --getentryinfo --mount=/mnt/beegfs /mnt/beegfs/benchmark --verbose
EntryID: 0-5D9BA1BC-1
ParentID: root
Metadata node: node001-numa0-4 [ID: 4]
Stripe pattern details:
+ Type: RAID0
+ Chunksize: 2M
+ Number of storage targets: desired: 3
+ Storage Pool: 1 (Default)
Inode hash path: 7/5E/0-5D9BA1BC-1

Transparentní obrovské stránky byly zakázány a na serverech metadat a úložných serverech byly použity následující možnosti ladění:

• vm.dirty_background_ratio = 5 
• vm.dirty_ratio = 20 
• vm.min_free_kbytes = 262144 
• vm.vfs_cache_pressure = 50
• vm.zone_reclaim_mode = 2 
• kernel.numa_balancing = 0

Kromě výše uvedených možností byly použity následující možnosti ladění BeeGFS: 

• Parametr tuneTargetChooser byl v konfiguračním souboru metadat nastaven na hodnotu „roundrobin“. 
• Parametr tuneNumWorkers byl nastaven na 24 pro metadata a 32 pro úložiště. 
• Parametr connMaxInternodeNum byl nastaven na 32 pro metadata, 12 pro úložiště a 24 pro klienty.

Na obrázku 9 je vidět, že maximální výkon čtení je 132 GB/s při 1 024 vláknech a maximální rychlost zápisu je 121 GB/s při 256 vláknech. Každá jednotka může poskytovat špičkový výkon čtení 3,2 GB/s a špičkový výkon zápisu 1,3 GB/s, což umožňuje teoretickou špičku 422 GB/s pro čtení a 172 GB/s pro zápis. Zde je však omezujícím faktorem síť. V nastavení je celkem 11 spojení InfiniBand EDR pro úložné servery. Každé spojení může poskytovat teoretický špičkový výkon 12,4 GB/s, což umožní teoretický špičkový výkon 136,4 GB/s. Dosažený špičkový výkon čtení a zápisu je 97 %, resp. 89 % teoretického špičkového výkonu.

Výkon jednoho vlákna při zápisu je přibližně 3 GB/s a při čtení přibližně 3 GB/s. Výkon zápisu se lineárním způsobem škáluje, maximum je 256 vláken a poté se začne snižovat. Při nižším počtu vláken je výkon čtení a zápisu stejný. Až do 8 vláken máme 8 klientů, kteří zapisují 8 souborů přes 24 cílů, což znamená, že ne všechny cíle úložiště jsou plně využívány. V systému máme 33 cílů úložiště, a proto je k plnému využití všech serverů potřeba alespoň 11 vláken. Výkon čtení registruje stabilní lineární nárůst se zvýšením počtu souběžných vláken a pozorujeme téměř podobný výkon na 512 a 1 024 vláknech.

Můžeme si také všimnout, že výkon čtení je nižší než v případě zápisu pro počet vláken od 16 do 128, poté se začne výkon čtení škálovat. Důvodem je to, že operace čtení PCIe je „nepřiřazená“ operace, která vyžaduje jak požadavek, tak dokončení, operace zápisu PCIe nevyžaduje po spuštění další proces. Po předání paketu transakční vrstvy spojové vrstvě se operace dokončí. Operace zápisu je „přiřazená“ operace, která se skládá pouze z požadavku.

Propustnost čtení je obvykle nižší než propustnost zápisu, protože čtení vyžaduje 2 transakce namísto 1 zápisu pro stejné množství dat. Rozhraní PCI Express používá pro čtení model rozdělené transakce. Transakce čtení obsahuje následující kroky:

• Žadatel odešle požadavek na čtení paměti (MRR).
• Zpracovatel odešle potvrzení požadavku MRR.
• Zpracovatel vrátí dokončení s daty.

Propustnost čtení závisí na prodlevě mezi dobou vydání požadavku na čtení a dobou, po kterou trvá vrácení dat. Když však aplikace vydá dostatečné množství požadavků na čtení, které tuto prodlevu vyváží, propustnost bude maximalizována. To je důvod, proč při zvýšení počtu požadavků naměříme vyšší propustnost, i když je výkon čtení nižší než výkon zápisu v rámci 16 až 128 vláken.  Nižší propustnost je naměřena, když žadatel čeká na dokončení jednoho požadavku před odesláním dalších požadavků. Vyšší propustnost je zaznamenána, když je vydáno více požadavků, aby se snížilo zpoždění po návratu prvních dat.

Náhodný zápis a čtení N-N

Pro vyhodnocení výkonnosti náhodného IO byl použit nástroj IOzone v náhodném režimu. Testy byly provedeny na vláknech od 4 do 1 024. Ke spuštění nástroje IOzone byla použita možnost Direct IO (-I), takže všechny operace obejdou vyrovnávací paměť cache a přejdou přímo na disk. Byla použity 3 prokládání BeeGFS a velikost bloku 2 MB. V nástroji IOzone se používá velikost požadavku 4 KiB. Výkon se měří v operacích I/O za sekundu (IOPS). Mezi jednotlivými spuštěními byla zahozena cache operačního systému na serverech BeeGFS i klientech BeeGFS. Příkaz použitý ke spuštění náhodných zápisů a čtení je uveden níže:

Náhodné čtení a zápis: iozone -i 2 -w -c -O -I -r 4K -s $Size -t $Thread -+n -+m /path/to/threadlist

Obrázek 10:  Výkon náhodného čtení a zápisu při použití nástroje IOzone s agregovanou velikostí souboru 8 TB

Maximální rychlost náhodného zápisu je přibližně 3,6 milionu IOPS při 512 vláknech a maximální rychlost náhodného čtení je přibližně 3,5 milionu IOPS při 1 024 vláknech, jak je znázorněno na obrázku 10. Výkon zápisu i čtení vykazuje vyšší výkon, pokud je k dispozici vyšší počet požadavků IO. Důvodem je to, že standard NVMe podporuje frontu až 64 000 operací I/O a až 64 000 příkazů na jednu frontu. Takto velký fond front NVMe poskytuje vyšší úrovně paralelismu I/O, a proto počet IOPS překračuje 3 miliony.

Závěr a budoucí práce

Tento blog představuje uvedení vysoce výkonného úložného řešení Dell EMC BeeGFS a poukazuje na jeho výkon. Řešení nabízí špičkový výkon sekvenčního čtení 132 GB/s a zápisu 121 Gb/s a maximální rychlost náhodného zápisu přibližně 3,6 milionu IOPS a rychlost náhodného čtení přibližně 3,5 milionu IOPS.

Tento blog je první částí úložného řešení BeeGFS, které bylo navrženo se zaměřením na pomocné místo s vysokým výkonem. Počkejte si na druhou část blogu, která popisuje, jak lze řešení škálovat zvýšením počtu serverů za účelem navýšení výkonu a kapacity. Třetí část blogu pojednává o dalších funkcích řešení BeeGFS a poukazuje na použití vestavěného srovnávacího testu cílů úložiště BeeGFS s názvem „StorageBench“.

V rámci dalších kroků vydáme dokument whitepaper s výkonem metadat a výkonem IOR N vláken na 1 soubor a s dalšími podrobnostmi o provedení, ladění a konfiguraci.

Reference