Řešení Dell EMC Ready pro úložiště HPC PixStor

Článek napsal Mario Gallegos z oddělení HPC and AI Innovation Lab v říjnu 2019

Obsah

1. Úvod
   1. Architektura řešení
   2. Komponenty řešení
2. Charakteristika výkonu
   1. Sekvenční výkon IOzone N klientů – N souborů
   2. Sekvenční výkon IOR N klientů –1 soubor
   3. Výkon náhodných malých bloků IOzone N klientů – N souborů
   4. Výkon metadat s nástrojem MDtest pomocí prázdných souborů
   5. Výkon metadat s nástrojem MDtest pomocí 4KiB souborů
   6. Výkon metadat pomocí MDtestu se soubory 3K
3. Advanced Analytics
4. Závěry a budoucí práce

Úvod

Architektura řešení

Komponenty řešení

Charakteristika výkonu

•     Sekvenční test IOzone N–N
•     Sekvenční test IOR N–1
•     Náhodné IOzone
•     MDtest
  
  U všech výše uvedených srovnávacích testů měli testovací klienti tak, jak je popsáno v tabulce 2 níže. Vzhledem k tomu, že počet výpočetních uzlů dostupných pro testování byl 16, při požadavku na vyšší počet vláken byla tato vlákna rovnoměrně rozložena na výpočetních uzlech (tj. 32 vláken = 2 vlákna na uzel, 64 vláken = 4 vlákna na uzel, 128 vláken = 8 vláken na uzel, 256 vláken = 16 vláken na uzel, 512 vláken = 32 vláken na uzel, 1024 vláken = 64 vláken na uzel). Záměrem bylo simulovat větší počet souběžných klientů s omezeným počtem výpočetních uzlů. Vzhledem k tomu, že srovnávací testy podporují vysoký počet vláken, byla použita maximální hodnota až 1024 (specifikovaná pro každý test) a zároveň se zabránilo nadměrnému přepínání kontextu a dalším souvisejícím vedlejším účinkům, které by ovlivnily výsledky výkonu.
  
  Tabulka 2: Klientské testovací zařízení

  Počet klientských uzlů	16
  Uzel klienta	C6320
  Procesory na uzel klienta	2x Intel(R) Xeon(R) Gold E5-2697v4, 18 jader při frekvenci 2,3 GHz
  Paměť na uzel klienta	12x 16GiB modul RDIMM 2 400 MT/s
  BIOS	2.8.0
  Jádro operačního systému	3.10.0-957.10.1
  Verze GPFS	5.0.3

   

  ---

  Sekvenční výkon IOzone N klientů – N souborů

  Sekvenční výkon N klientů – N souborů byl měřen pomocí Iozone verze 3.487. Provedené testy se lišily od jednoho vlákna až po 1024 vláken. 
  Vliv ukládání do cache byl minimalizován nastavením fondu stránek GPFS na 16 GiB a použitím souborů větších než dvojnásobek této velikosti. Je důležité si uvědomit, že pro GPFS tato možnost nastavuje maximální množství paměti používané pro ukládání dat do mezipaměti bez ohledu na množství nainstalované a volné paměti RAM. Je také důležité si uvědomit, že zatímco v předchozích řešeních Dell EMC HPC byla velikost bloku pro velké sekvenční přenosy 1 MiB, GPFS byl formátován s 8 bloky MiB, a proto se tato hodnota používá ve srovnávacím testu pro optimální výkon. Může se zdát, že to je příliš velké a zřejmě se tím příliš plýtvá místem, ale systém GPFS používá přidělování podbloků, aby této situaci zabránil. V současné konfiguraci byl každý blok rozdělen do 256 podbloků po 32 KiB. 
  Následující příkazy byly použity ke spuštění srovnávacího testu pro zápis a čtení, kde Threads byla proměnná s počtem použitých vláken (1 až 1024 se zvýšila v mocninách dvou) a threadlist byl soubor, který přidělil každé vlákno na jiném uzlu pomocí kruhového dotazování k jejich homogennímu rozprostření mezi 16 výpočetních uzlů.

  ./iozone -i0 -c -e -w -r 8M -s 128G -t $Threads -+n -+m ./seznam
  vláken ./iozone -i1 -c -e -w -r 8M -s 128G -t $Threads -+n -+m ./seznam vláken

  
  Obrázek 2:  Sekvenční výkon
  
  
  N až N Z výsledků můžeme pozorovat, že výkon velmi rychle stoupá s počtem použitých klientů a poté dosahuje plošiny, která je stabilní, dokud není dosaženo maximálního počtu vláken, který IOzone umožňuje, a proto je sekvenční výkon velkých souborů stabilní i pro 1024 souběžných klientů. Všimněte si, že maximální výkon čtení byl 23 GB/s při 32 vláknech a velmi pravděpodobně úzkým hrdlem bylo rozhraní InfiniBand EDR, zatímco pole ME4 měla stále k dispozici nějaký výkon navíc. Podobně si všimněte, že maximálního výkonu zápisu 16.7 bylo dosaženo o něco dříve na 16 vláknech a je zjevně nízký ve srovnání se specifikacemi polí ME4.
  Zde je důležité si uvědomit, že upřednostňovaný režim provozu GPFS je rozptýlený a řešení bylo naformátováno tak, aby jej používalo. V tomto režimu jsou bloky alokovány od samého začátku pseudonáhodným způsobem a data jsou rozprostřena po celé ploše každého HDD. Zjevnou nevýhodou je sice menší počáteční maximální výkon, ten se však udržuje na poměrně konstantní úrovni bez ohledu na to, kolik místa je v systému souborů využito. To je rozdíl oproti jiným paralelním systémům souborů, které zpočátku využívají vnější stopy, které mohou pojmout více dat (sektorů) na jednu otáčku disku, a mají tedy nejvyšší možný výkon, který mohou pevné disky poskytnout, ale jak systém využívá více místa, začnou se využívat vnitřní stopy s menším množstvím dat na otáčku, což má za následek snížení výkonu. 
  
   

  ---

  Sekvenční výkon IOR N klientů –1 soubor

  Sekvenční výkon N klientů na jeden sdílený soubor byl měřen pomocí IOR verze 3.3.0 s využitím OpenMPI verze 4.0.1 pro spuštění benchmarku na 16 výpočetních uzlech. Provedené testy se pohybovaly od jednoho vlákna až po 1024 vláken.
  Vliv ukládání do cache byl minimalizován nastavením fondu stránek GPFS na 16 GiB a použitím souborů větších než dvojnásobek této velikosti. V tomto benchmarku byly pro optimální výkon použity bloky o velikosti 8 MiB. Předchozí část o výkonnostních testech obsahuje úplnější vysvětlení těchto záležitostí. 
  Následující příkazy byly použity ke spuštění srovnávacího testu pro zápis a čtení, kde Threads byla proměnná s počtem použitých vláken (1 až 1024 se zvýšila v mocninách dvou) a my_hosts.$Threads je odpovídající soubor, který přidělil každé vlákno na jiném uzlu pomocí kruhového dotazování k jejich homogennímu rozprostření mezi 16 výpočetních uzlů.

  mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -w -s 1 -t 8m -b 128G 

  mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -r -s 1 -t 8m -b 128G

  
  
  Obrázek 3: N až 1 Sekvenční výkon
  
  Z výsledků můžeme pozorovat, že výkon opět velmi rychle stoupá s počtem použitých klientů a poté dosahuje plošiny, která je polostabilní pro čtení a velmi stabilní pro zápisy až do maximálního počtu vláken použitých v tomto testu. Proto je sekvenční výkon velkých jednotlivých sdílených souborů stabilní i pro 1024 souběžných klientů. Všimněte si, že maximální výkon čtení byl 23,7 GB/s při 16 vláknech a velmi pravděpodobně úzkým hrdlem bylo rozhraní InfiniBand EDR, zatímco pole ME4 měla stále k dispozici nějaký výkon navíc. Kromě toho se výkon čtení od této hodnoty snížil až do dosažení plató rychlostí přibližně 20,5 GB/s, s okamžitým poklesem na 18,5 GB/s při 128 vláknech. Podobně si všimněte, že maximálního výkonu zápisu 16,5 bylo dosaženo při 16 vláknech a ve srovnání se specifikacemi polí ME4 je zjevně nízký.
   

  ---

  Výkon náhodných malých bloků IOzone N klientů – N souborů

  Výkon převodu náhodných N klientů na N souborů byl měřen pomocí IOzone verze 3.487. Provedené testy se pohybovaly od jednoho vlákna až po 1024 vláken. Tento srovnávací test používal 4 bloky KiB pro emulaci provozu malých bloků.
  Efekty ukládání do mezipaměti byly minimalizovány nastavením fondu stránek GPFS laditelným na 16GiB a použitím souborů dvakrát větší velikosti. Část s prvním testem výkonu nabízí podrobnější vysvětlení, proč je tento postup na systému GPFS účinný. 
  Následující příkaz byl použit ke spuštění srovnávacího testu v režimu náhodných vstupně-výstupních operací pro zápisy i čtení, kde Threads byla proměnná s počtem použitých vláken (1 až 1024 zvýšených v mocninách dvou) a threadlist byl soubor, který přidělil každé vlákno na jiném uzlu pomocí kruhového dotazování k jejich homogennímu rozložení mezi 16 výpočetních uzlů.

  ./iozone -i2 -c -O -w -r 4K -s 32G -t $Threads -+n -+m ./seznam vláken

  
  Obrázek 4:  Náhodný výkon
  
  N až N: Z výsledků můžeme pozorovat, že výkon zápisu začíná na vysoké hodnotě téměř 8,2 tis. IOPS a neustále stoupá až do 128 vláken, kde dosahuje plató a zůstává blízko maximální hodnoty 16,2 tis. IOPS. Výkon čtení na druhé straně začíná velmi malý při více než 200 IOPS a zvyšuje výkon téměř lineárně s počtem použitých klientů (mějte na paměti, že počet vláken se pro každý datový bod zdvojnásobuje) a dosahuje maximálního výkonu 20,4 tisíc IOPS při 512 vláknech bez známek dosažení maxima. Použití více vláken na aktuálních 16 výpočetních uzlech se dvěma procesory a kde každý procesor má 18 jader však má omezení, že není dostatek jader pro spuštění maximálního počtu vláken IOzone (1024) bez přepínání kontextu (16 x 2 x 18 = 576 jader), což značně omezuje výkon. Budoucí test s více výpočetními uzly by mohl zkontrolovat, jakého výkonu náhodného čtení lze dosáhnout s 1024 vlákny s IOzone, nebo by bylo možné použít IOR k prozkoumání chování s více než 1024 vlákny.
  
   

  ---

  Výkon metadat s nástrojem MDtest pomocí prázdných souborů

  Výkon metadat byl měřen pomocí MDtest verze 3.3.0 s využitím OpenMPI verze 4.0.1 pro spuštění benchmarku na 16 výpočetních uzlech. Provedené testy se pohybovaly v rozmezí 1–512 vláken. Benchmark byl použit pouze pro soubory (žádná metadata adresářů), získání počtu vytvoření, statistik, čtení a odstranění, které řešení zvládne.
  Aby bylo možné řešení řádně vyhodnotit v porovnání s jinými úložnými řešeními HPC společnosti Dell EMC, byl použit volitelný modul metadat s vysokou poptávkou (High Demand Metadata Module), avšak s jedním polem ME4024, i když velká konfigurace testovaná v této práci byla určena pro dva ME4024. 
  Tento modul metadat pro vysoké nároky může podporovat až 4 pole ME4024, což i doporučujeme, než přidáte další modul metadat. Očekává se, že další pole ME4024 zvýší výkon metadat lineárně s každým dalším polem, snad s výjimkou operací Stat (a čtení prázdných souborů), protože čísla jsou velmi vysoká, v určitém okamžiku se procesory stanou úzkým hrdlem a výkon se nebude nadále lineárně zvyšovat.
  Ke spuštění benchmarku byl použit následující příkaz, kde položka Threads byla proměnná s počtem použitých vláken (1–512, rostoucí po mocnině 2) a položka my_hosts.$Threads byl odpovídající soubor, který přiděloval každé vlákno na jiný uzel, přičemž se použilo kruhové dotazování pro jejich homogenní rozložení mezi 16 výpočetních uzlů. Podobně jako u benchmarku náhodného IO byl maximální počet vláken omezen na 512, protože pro 1 024 vláken není k dispozici dostatek jader a přepínání kontextu by ovlivnilo výsledky a vykazovalo by nižší než skutečný výkon řešení.

  mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --prefix /mmfs1/perftest/ompi --mca btl_openib_allow_ib 1 /mmfs1/perftest/lanl_ior/bin/mdtest -v -d /mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F

  
  Vzhledem k tomu, že výsledky výkonu mohou být ovlivněny celkovým počtem vstupně-výstupních operací za sekundu, počtem souborů na adresář a počtem vláken, bylo rozhodnuto zachovat pevný celkový počet souborů na 2 soubory MiB (2^21 = 2097152), počet souborů na adresář pevně stanovený na 1024 a počet adresářů se lišil podle toho, jak se měnil počet vláken, jak je znázorněno v tabulce 3.
  
  Tabulka 3:  MDtest distribuce souborů v adresářích

  Počet vláken	Počet adresářů na vlákno	Celkový počet souborů
  1	2 048	2 097 152
  2	1 024	2 097 152
  4	512	2 097 152
  8	256	2 097 152
  16	128	2 097 152
  32	64	2 097 152
  64	32	2 097 152
  128	16	2 097 152
  256	8	2 097 152
  512	4	2 097 152
  1 024	2	2 097 152

  
  
  
  
  Obrázek 5: Výkon metadat – prázdné soubory
  
  Nejprve si všimněte, že zvolené měřítko bylo logaritmické se základem 10, aby bylo možné porovnávat operace, které mají rozdíly o několik řádů; V opačném případě by některé operace vypadaly jako rovná čára blízká 0 na normálním grafu. Logaritmický graf se základem 2 by mohl být vhodnější, protože počet vláken se zvyšuje v mocninách 2, ale graf by vypadal dost podobně a lidé mají tendenci pracovat a pamatovat si lepší čísla založená na mocninách 10.
  
  
  Systém dosahuje velmi dobrých výsledků s operacemi Stat a Read, které dosahují své maximální hodnoty na 64 vláknech s 11,2 M op/s a 4,8 M op/s. Operace odebrání dosáhly maxima 169,4 000 operací za sekundu při 16 vláknech a operace vytvoření dosáhly svého maxima při 512 vláknech se 194,2 000 operacemi za sekundu. Operace Stat a Read vykazují větší variabilitu, ale jakmile dosáhnou své maximální hodnoty, výkon neklesne pod 3 miliony op/s pro operace Stat a 2 miliony op/s pro operace Read. Vytvoření a odebrání jsou stabilnější, jakmile dosáhnou úrovně a zůstanou nad 140 000 op/s pro odebrání a 120 tisíc op/s pro vytvoření.
   

  ---

  Výkon metadat s nástrojem MDtest pomocí 4KiB souborů

  Tento test je téměř totožný s předchozím, jen místo prázdných souborů byly použity malé soubory o velikosti 4 KiB. 
  Ke spuštění benchmarku byl použit následující příkaz, kde položka Threads byla proměnná s počtem použitých vláken (1–512, rostoucí po mocnině 2) a položka my_hosts.$Threads byl odpovídající soubor, který přiděloval každé vlákno na jiný uzel, přičemž se použilo kruhové dotazování pro jejich homogenní rozložení mezi 16 výpočetních uzlů.

  mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --prefix /mmfs1/perftest/ompi --mca btl_openib_allow_ib 1 /mmfs1/perftest/lanl_ior/bin/mdtest -v -d /mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F -w 4K -e 4K

  
  Obrázek 6:  Výkon metadat – malé soubory (4K)
  
  Systém dosahuje velmi dobrých výsledků pro operace Stat a Removal a dosahuje své maximální hodnoty na 128 vláknech se 7,7 M op/s a 1M op/s. Operace odebrání dosáhly maxima 37,3 000 operací za sekundu a operace vytvoření dosáhly svého maxima s 55,5 tisíci operacemi/s, obě při 512 vláknech. Operace Stat a Removal mají větší variabilitu, ale jakmile dosáhnou své maximální hodnoty, výkon neklesne pod 4 M op/s pro Stats a 200 000 op/s pro Removal. Operace Create a Read mají menší variabilitu a s rostoucím počtem vláken stále rostou.
  Vzhledem k tomu, že tato čísla platí pro modul metadat s jedním polem ME4024, výkon se zvýší pro každé další pole ME4024, nemůžeme však předpokládat pouze lineární nárůst pro každou operaci. Pokud se celý soubor nevejde do uzlu inode pro takový soubor, budou datové cíle na ME4084 použity k uložení 4 000 souborů, což do jisté míry omezí výkon. Protože velikost uzlu inode je 4 KiB a je třeba do něj ještě ukládat metadata, vejdou se dovnitř pouze soubory o velikosti kolem 3 KiB a jakýkoli větší soubor bude používat datové cíle.
   

  ---

  Výkon metadat pomocí MDtestu se soubory 3K

  Tento test je téměř totožný s předchozími, až na to, že byly použity malé soubory 3KiB. Hlavní rozdíl je v tom, že tyto soubory se zcela vejdou do inode. Proto se nepoužívají uzly úložiště a jejich ME4084, což zlepšuje celkovou rychlost tím, že se pro úložiště používají pouze média SSD a je méně přístupů k síti. 
  Ke spuštění benchmarku byl použit následující příkaz, kde položka Threads byla proměnná s počtem použitých vláken (1–512, rostoucí po mocnině 2) a položka my_hosts.$Threads byl odpovídající soubor, který přiděloval každé vlákno na jiný uzel, přičemž se použilo kruhové dotazování pro jejich homogenní rozložení mezi 16 výpočetních uzlů.

  mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --prefix /mmfs1/perftest/ompi --mca btl_openib_allow_ib 1 /mmfs1/perftest/lanl_ior/bin/mdtest -v -d /mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F -w 3K -e 3K

   

  
  Obrázek 7: Výkon metadat – malé soubory (3 tis.)
  
  Systém dosahuje velmi dobrých výsledků pro operace Stat a Read, které dosahují své maximální hodnoty při 256 vláknech s 8,29 M op/s a 5,06 M op/s. Operace odebrání dosáhly maxima 609 tisíc operací za sekundu při 128 vláknech a operace vytvoření dosáhly svého vrcholu se 78 tisíci operacemi za sekundu při 512 vláknech. Operace statistik a čtení mají větší variabilitu než vytváření a odebrání. Odebrání má malý pokles výkonu pro dvě vyšší vlákna, což naznačuje, že trvalý výkon po 128 vláknech bude mírně přes 400 tisíc operací. Vytváří stále narůstající až na 512 vláken, ale vypadá to, že dosahuje plató, takže maximální výkon může být stále pod 100 tisíc op/s.
  Vzhledem k tomu, že malé soubory, jako jsou tyto, jsou zcela uloženy v modulu metadat na bázi SSD, mohou aplikace vyžadující vynikající výkon malých souborů použít jeden nebo více volitelných modulů metadat s vysokou náročností na zvýšení výkonu malých souborů. Soubory, které se vejdou do inody, jsou však podle současných standardů malé. Jelikož cíle metadat používají pole RAID 1 s disky SSD relativně malými (maximální velikost je 19,2 TB), bude kapacita ve srovnání s uzly úložiště omezená. Proto je třeba dbát na to, aby nedošlo k zaplnění cílů metadat, což může způsobit zbytečné poruchy a další problémy.
   

  ---

  Advanced Analytics

  Mezi funkcemi PixStoru může být monitorování souborového systému prostřednictvím pokročilé analytiky zásadní pro výrazné zjednodušení správy, což pomáhá proaktivně nebo reaktivně najít problémy nebo potenciální problémy. V dalším kroku se stručně podíváme na některé z těchto funkcí.
  Obrázek 8 ukazuje užitečné informace o kapacitě systému souborů. Na levé straně je uvedeno celkové využité místo v souborovém systému a deset nejlepších uživatelů podle využité kapacity souborového systému. Na pravé straně je historické zobrazení s využitou kapacitou po mnoho let, pak deset nejpoužívanějších typů souborů a deset nejpoužívanějších sad souborů, obojí na základě využité kapacity, ve formátu podobném Paretovým grafům (bez řádků pro kumulativní součty). S těmito informacemi může být snadné najít uživatele, kteří dostávají více než spravedlivý podíl na souborovém systému, trendy využití kapacity, které pomáhají při rozhodování o budoucím růstu kapacity, které soubory využívají většinu místa nebo které projekty zabírají většinu kapacity.
  
  
  Obrázek 8:  Analytika PixStor – zobrazení
  
  kapacity Obrázek 9 ukazuje počet souborů se dvěma velmi užitečnými způsoby, jak najít problémy. V první polovině obrazovky je prvních deset uživatelů ve výsečovém grafu a deset nejlepších typů souborů a deset nejlepších sad souborů (představte si projekty) ve formátu podobném Paretovým grafům (bez řádků pro kumulativní součty), vše na základě počtu souborů. Tyto informace lze použít k zodpovězení některých důležitých otázek. Například uživatelé, kteří monopolizují souborový systém tím, že vytvářejí příliš mnoho souborů, jaký typ souboru vytváří noční můru metadat nebo jaké projekty využívají většinu zdrojů.
  Spodní polovina obsahuje histogram s počtem souborů (frekvencí) pro velikosti souborů pomocí 5 kategorií pro různé velikosti souborů. To lze použít k získání představy o velikostech souborů používaných v celém systému souborů, které lze v koordinaci s typy souborů použít k rozhodnutí, zda bude komprese přínosná.
  
  
  Obrázek 9:  PixStor Analytics – Zobrazení počtu souborů

  
  
   

  ---

  Závěry a budoucí práce

  Současné řešení bylo schopno poskytnout poměrně dobrý výkon, který by měl být stabilní bez ohledu na využité místo (protože systém byl formátován v rozptýleném režimu), jak je vidět v tabulce 4. Řešení navíc lineárně škáluje kapacitu a výkon s přidáváním dalších modulů úložných uzlů a podobný nárůst výkonu lze očekávat i od volitelného modulu metadat s vysokými nároky. Toto řešení poskytuje zákazníkům HPC velmi spolehlivý paralelní systém souborů, který využívá mnoho clusterů HPC z žebříčku Top 500. Kromě toho poskytuje výjimečné možnosti vyhledávání, pokročilé monitorování a správu a přidání volitelných bran umožňuje sdílení souborů prostřednictvím všudypřítomných standardních protokolů, jako jsou NFS, SMB a další, tolika klientům, kolik je potřeba.
  
  Tabulka 4  Špičkový a trvalý výkon
  
   

  	Špičkový výkon		Stálý výkon
  	Zápis	Čtení	Zápis	Čtení
  Velký sekvenční N klientů – N souborů	16,7 GB/s	23 GB/s	16,5 GB/s	20,5 GB/s
  Velký sekvenční N klientů – jeden sdílený soubor	16,5 GB/s	23,8 GB/s	16,2 GB/s	20,5 GB/s
  Náhodné malé bloky N klientů – N souborů	15,8 KIOps	20,4 KIOps	15,7 KIOps	20,4 KIOps
  Prázdné soubory metadat – Create	169 400 IOPS		127,2 000 IOps
  Prázdné soubory metadat – Stat	11,2 milionu operací IO za sekundu		3,3 milionu IOps
  Prázdné soubory metadat – Read	4,8 milionu IOps		2,4 mil. IOPS
  Prázdné soubory metadat – Remove	194,2 000 IOps		144,8 000 IOps
  4KiB soubory metadat – Create	55,4 000 IOps		55,4 000 IOps
  4KiB soubory metadat – Stat	6,4 milionu operací IOps		4 milióny IOps
  4KiB soubory metadat – Read	37,3 000 IOps		37,3 000 IOps
  4KiB soubory metadat – Remove	1 milion IOps		219,5 000 IOps

  
  
  Vzhledem k tomu, že řešení má být vydáno s procesory Cascade Lake a rychlejší pamětí RAM, budou po finální konfiguraci systému provedeny namátkové kontroly výkonu. A je potřeba otestovat volitelný modul metadat pro vysoké nároky s alespoň 2x ME4024 a 4KiB soubory, aby bylo možné lépe zdokumentovat, jak se škáluje výkon metadat při zapojení datových cílů. Kromě toho bude změřen výkon pro uzly brány a spolu se všemi relevantními výsledky z namátkových kontrol bude uveden v novém blogu nebo dokumentu whitepaper. V neposlední řadě se plánuje testování a vydání dalších komponent řešení, které poskytnou ještě více možností.

  ---