PowerEdge: Řešení Dell Ready pro vysoce výkonné úložiště HPC BeeGFS

Článek napsala Nirmala Sundararajanová z laboratoře Dell HPC and AI Innovation Lab v listopadu 2019

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

Tým Dell HPC s hrdostí oznamuje vydání "Dell EMC Ready Solutions for HPC BeeGFS Storage", což je nejnovější přírůstek do portfolia úložišť HPC. Toto řešení používá servery R740xd, každý s 24 1,6TB disky Intel P4600 NVMe pro smíšené použití Express Flash a dvěma adaptéry Mellanox ConnectX-5 InfiniBand EDR. V této konfiguraci s 24 disky NVMe se 12 disků NVMe SSD připojuje k přepínači PCIe a každý přepínač je připojen k jednomu procesoru pomocí rozšiřující karty x16 PCIe. Kromě toho je každé rozhraní IB připojeno k jednomu procesoru. Takto vyvážená konfigurace, kdy je každý procesor připojen k jednomu adaptéru InfiniBand a pracuje s 12 disky SSD NVMe, poskytuje maximální výkon, protože zajišťuje, že procesory jsou rovnoměrně vytíženy zpracováním vstupně-výstupních požadavků na a z disků NVMe.

Řešení se zaměřuje na vysoce výkonné I/O a bylo navrženo jako vysokorychlostní pomocné řešení. Jádrem řešení je použití vysokorychlostních NVMe SSD, které nabízejí vysokou šířku pásma a nízkou latenci odstraněním úzkých míst plánovače a fronty z blokové vrstvy. Souborový systém BeeGFS také podporuje vysokou agregovanou propustnost I/O.

Referenční architektura řešení

Obrázek 1 znázorňuje referenční architekturu řešení. Server pro správu je připojen pouze prostřednictvím sítě Ethernet k serverům metadat a serverům úložiště. Každý server metadat a úložiště má dvě linky InfiniBand a je připojen k privátní síti přes Ethernet. Klienti mají jednu linku InfiniBand a jsou připojeni k privátnímu rozhraní přes Ethernet.

Obrázek 1:  Řešení Dell Ready Solutions for HPC Úložiště BeeGFS – referenční architektura

Konfigurace hardwaru a softwaru

Tabulky 1 a 2 popisují hardwarové parametry serveru pro správu a metadata/serveru úložiště. Tabulka 3 popisuje verze softwaru používané pro řešení.

Podrobnosti o konfiguraci řešení

Architektura BeeGFS se skládá ze čtyř hlavních služeb:

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

S výjimkou klientské služby, která je modulem jádra, jsou služby správy, metadat a úložiště procesy uživatelského prostoru. Obrázek 2 znázorňuje, jak je referenční architektura řešení Dell EMC Ready Solutions pro úložiště HPC BeeGFS mapovaná na obecnou architekturu systému souborů BeeGFS.

Obrázek 2:  Systém souborů BeeGFS na serveru PowerEdge R740xd s disky NVMe SSD

Služba správy

Každý systém souborů nebo obor názvů BeeGFS má pouze jednu službu správy. Služba správy je první službou, kterou je třeba nastavit, protože když nakonfigurujeme všechny ostatní služby, musí se zaregistrovat u služby správy. Jako server pro správu se používá server PowerEdge R640. Kromě hostování služby správy (beegfs-mgmtd.service) hostuje také službu monitorování (beegfs-mon.service), která shromažďuje ze systému statistiky a poskytuje je uživateli pomocí databáze časových řad InfluxDB. K vizualizaci dat poskytuje služba beegfs-mon předem definované panely Grafana, které lze používat hned při prvním použití. Server pro správu má 6 pevných disků s kapacitou 300 GB nakonfigurovaných v poli RAID 10 pro operační systém a databázi InfluxDB.

Služba metadat

Služba metadat je horizontálně škálovaná služba, což znamená, že v systému souborů BeeGFS může být použito mnoho služeb metadat. Každá služba metadat má však pro ukládání metadat přesně jeden cíl. V cíli metadat vytvoří BeeGFS jeden soubor metadat pro každý soubor vytvořený uživatelem. Metadata BeeGFS jsou distribuována v jednotlivých adresářích. Služba metadat poskytuje klientům informace o prokládání dat a nepřistupuje k datům mezi otevřením/zavřením souboru.

Pro úložiště metadat se používá server PowerEdge R740xd s 24 disky Intel P4600 NVMe 1,6 TB. Vzhledem k tomu, že požadavky na kapacitu úložiště pro metadata BeeGFS jsou velmi malé, místo použití vyhrazeného serveru metadat se k hostování metadat (MDT) použilo pouze 12 jednotek v zóně NUMA 0, zatímco zbývajících 12 jednotek na hostiteli zóny NUMA Storage Targetů (ST).

Obrázek 3 znázorňuje server metadat. 12 disků ohraničených žlutým obdélníkem představuje MDT v zóně NUMA 0, zatímco 12 disků ohraničených zeleným obdélníkem představuje ST v zóně NUMA 1. Tato konfigurace se nejen vyhýbá problémům se zónami NUMA, ale také zajišťuje dostatek úložiště metadat pro usnadnění škálování kapacity a výkonu podle potřeby.

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.

Obrázek 4:  Konfigurace jednotek v serveru

metadat 12 jednotek používaných pro metadata je nakonfigurováno jako skupina disků 6x RAID 1 se dvěma jednotkami, z nichž každá slouží jako MDT. Spuštěno je šest služeb metadat, z nichž každá zpracovává jeden MDT. Zbývajících 12 úložných disků je nakonfigurováno do skupin disků 3x RAID 0 po čtyřech discích. V zóně NUMA 1 jsou spuštěny 3 služby úložiště, jedna služba pro každý cíl ST. Takže server, který spoluhostuje cíle metadat a úložiště, má 6 cílů MDT a 3 cíle ST. Provozuje také šest služeb metadat a tři služby úložiště. Každý cíl MDT je systém souborů ext4 založený na konfiguraci RAID 1. ST jsou založeny na souborovém systému XFS nakonfigurovaném v poli RAID 0.
 

Služba úložiště

Stejně jako službu metadat lze i službu úložiště škálovat. V systému souborů BeeGFS může být mnoho instancí služby úložiště. Na rozdíl od služby metadat však může být v každé službě úložiště několik cílů úložiště. Služba úložiště ukládá prokládaný obsah uživatelských souborů, označovaný také jako soubory bloků dat.

Obrázek 5 znázorňuje 5x servery PowerEdge R740xd používané jako servery úložiště.

Obrázek 5:  Servery

vyhrazených úložišť Každý server úložiště je konfigurován se 6 skupinami RAID 0, z nichž každá obsahuje čtyři disky, takže hostuje 6 ST na server (3 na zónu NUMA), jak je znázorněno na obrázku 6 níže:

Obrázek 6:  Konfigurace jednotek na serverech

úložišť Celkem základní konfigurace referenční architektury hostí 6 MDT a 33 ST. 5 vyhrazených úložných serverů poskytuje celkovou kapacitu 211 TB a využitelnou kapacitu 190 TiB. Odhadovaná využitelná kapacita v TiB = počet disků × kapacita jednoho disku v TB × 0,99 (režie systému souborů) × (10^12/2^40). Jedná se o ideální řešení úložiště dočasných dat středního rozsahu s dostatečnou kapacitou úložiště metadat, které usnadní přidání dalších úložných serverů při nárůstu požadavků na kapacitu.

S ohledem na následující faktory byla pro cíle úložiště vybrána konfigurace RAID 0 namísto konfigurace RAID 10.

1. Výkon zápisu byl měřen pomocí příkazu dd vytvořením 10GB souboru o velikosti bloku 1 MB a přímého I/O pro data, pro zařízení RAID 0 byl průměr přibližně 5,1 GB/s na každé zařízení, zatímco pro zařízení RAID 10 byl průměr 3,4 GB/s na každé zařízení.
2. Srovnávací testy StorageBench ukázaly, že maximální propustnost byla 5,5 GB/s pro konfiguraci RAID 0, zatímco pro konfiguraci RAID 10 je to 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 drahé a nabízejí zrychlení, které se nejlépe využije v konfiguraci RAID 0

Služba klienta

Klientský modul BeeGFS musí být načten na všech hostitelích, kteří musí přistupovat k systému souborů BeeGFS. Když je načten klient beegfs, připojí souborové systémy definované v souboru/etc/beegfs/beegfs-mounts.conf namísto obvyklého přístupu založeného na /etc/fstab. Zavedením tohoto přístupu spustíte klienta beegfs jako jakoukoli jinou linuxovou službu prostřednictvím skriptu spuštění služby. Umožňuje také automatickou rekompilaci modulu klienta BeeGFS po aktualizacích systému. 

Když je klientský modul načten, připojí souborové systémy definované v souboru beegfs-mounts.conf. Na stejném klientovi lze připojit několik instancí beegfs, jak je znázorněno níže:

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

Výše uvedený příklad ukazuje dva různé systémy souborů připojené ke stejnému klientovi. Pro účely tohoto testování jsme jako klienty použili 32 uzlů C6420.

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

V konfiguraci 24xNVMe serveru PowerEdge R740xd jsou dvě propojovací karty NVMe x16, které předávají data přepínači PCIe na backplane, který data rozdělí a předává na disky (disky jsou x4), jak je znázorněno na obrázku 7 níže:


Obrázek 7:  Podrobnosti o mapování procesoru v serveru R740xd s 24x disky NVMe

V rámci NUMA (Non-Uniform Memory Access) je systémová paměť rozdělena do zón nazývaných uzly, které jsou přiděleny procesorům nebo socketům. Přístup k místní paměti procesoru je rychlejší než přístup k paměti připojené ke vzdáleným procesorům v systému. Aplikace s vlákny obvykle pracuje nejlépe, když vlákna přistupují k paměti na stejném uzlu NUMA. Dopad chyb NUMA na výkon je významný, obvykle minimálně 10%. Za účelem zlepšení výkonu jsou služby nakonfigurovány pro používání specifických zón NUMA, aby nedocházelo ke zbytečnému křížení socketů UPI, čímž se snižuje latence. Každá zóna NUMA má na starost 12 disků a používá jedno ze dvou rozhraní InfiniBand EDR na serverech. Tohoto rozdělení NUMA je dosaženo ruční konfigurací vyvažování NUMA, kdy jsou vytvořeny vlastní soubory jednotek systemd a je nakonfigurována služba multihoming. Z tohoto důvodu je automatické vyvažování NUMA deaktivováno, jak je znázorněno níže:

# cat /proc/sys/kernel/numa_balancing
0

Obrázek 8 znázorňuje testovací prostředí, kde jsou zvýrazněná připojení InfiniBand k zóně NUMA. Každý server má dvě propojení IP a provoz přes zónu NUMA 0 je předáván rozhraním IB0, zatímco provoz přes zónu NUMA 1 zpracovává rozhraní IB1.

Obrázek 8:  Konfigurace testbedu
 

Charakteristika výkonu

Tato část obsahuje hodnocení výkonu, které pomáhá charakterizovat řešení Dell EMC Ready Solution pro HPC BeeGFS – vysoce výkonné úložné řešení. Další podrobnosti a aktualizace naleznete v dokumentu whitepaper, který bude zveřejněn později. Výkon systému byl vyhodnocen pomocí benchmarku IOzone. Řešení je testováno pro propustnost sekvenčního čtení a zápisu a IOPS náhodného čtení a zápisu. Tabulka 4 popisuje konfiguraci serverů C6420, které byly použity jako klienti BeeGFS pro studie výkonu na tomto blogu.
 

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 prováděny s více počty vláken, počínaje jedním vláknem a zvyšujícím se výkonem 2 až na 1024 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. Agregovaná velikost souboru byla zvolena dostatečně velká, aby se minimalizoval vliv ukládání do mezipaměti ze serverů a 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 pro každé spuštění použili velikost záznamu 1 MB. 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

Mezipaměti operačního systému byly také vyřazeny nebo vyčištěny na 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 nastavena na 2 MB a počet prokládání byl zvolen na 3, protože na každou zónu NUMA připadají tři cíle, 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: 

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

Obrázek 9:  Sekvenční agregovaná velikost souboru IOzone 8 TB.

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í máme celkem 11 odkazů InfiniBand EDR pro servery úložišť. 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ý. Protože až do osmi vláken máme osm klientů, kteří zapisují osm souborů napříč 24 cíli, což znamená, že ne všechny cíle úložiště jsou plně využity. V systému máme 33 storage targetů, a proto je potřeba alespoň 11 vláken, abychom plně využili všechny servery. Výkon čtení registruje stálý lineární nárůst s nárůstem počtu souběžných vláken a pozorujeme téměř podobný výkon u 512 a 1024 vláken.

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).
• Kompletátor odešle potvrzení do MRR.
• Zpracovatel vrátí dokončení s daty.

Propustnost čtení závisí na prodlevě mezi vydáním požadavku na čtení a dokončováním 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). Mezipaměti operačního systému byly zahozeny mezi spuštěními na serverech BeeGFS a klientech BeeGFS. Příkaz používaný k provádění náhodných zápisů a čtení je uveden níže:

Náhodné čtení a zápisy: 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 pomocí IOzone s agregovanou velikostí souboru 8 TB.

Náhodné zápisy jsou ve špičce ~ 3,6 milionu IOPS při 512 vláknech a náhodné čtení ve špičce ~ 3,5 milionu IOPS při 1024 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. Tento velký fond front NVMe poskytuje vyšší úrovně vstupně-výstupního paralelismu, a proto pozorujeme překročení počtu IOPS nad 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. Část 3 blogové série pojednává o dalších funkcích BeeGFS a zdůrazňuje použití "StorageBench", vestavěného srovnávacího testu cílů úložiště BeeGFS.

V rámci dalších kroků později zveřejníme dokument whitepaper s výkonem metadat a výkonem IOR N vláken do jednoho souboru a s dalšími podrobnostmi o aspektech návrhu, ladění a konfiguraci.

Reference

[1] Dokumentace BeeGFS:  https://www.beegfs.io/wiki/
[2] Jak připojit dvě rozhraní ke stejné podsíti:  https://access.redhat.com/solutions/30564