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

Žádné

Obsah

1. Úvod
   1. Architektura řešení
   2. Komponenty řešení
2. Charakteristika výkonu
   1. Sekvenční výkon N klientů IOzone se soubory N
   2. Sekvenční výkon klientů IOR N na 1 soubor
   3. Náhodné malé bloky klientů IOzone Performance N do souborů N
   4. Výkon metadat pomocí nástroje MDtest pomocí prázdných souborů
   5. Výkon metadat pomocí nástroje MDtest pomocí 4 souborů KIB
3. Závěry a budoucí práce

 

---

Úvod

Dnešní prostředí SUPERC zvyšují nároky na velmi vysokorychlostní úložiště, které také často vyžaduje vysokou kapacitu a distribuovaný přístup prostřednictvím několika standardních protokolů, jako je NFS, SMB a další. Požadavky hpC na vysoké nároky jsou obvykle kryty paralelními systémy souborů, které poskytují souběžný přístup k jedinému souboru nebo sadě souborů z více uzlů, velmi efektivně a bezpečně distribuují data do více jednotek LUN v několika serverech.

 

---

Architektura řešení

Tento blog představuje pokračování řešení Parallel File System (PFS) pro prostředí HPC, řešení DellEMC Ready pro úložiště HPC PixStor, kde se používají pole PowerVault ME484 EBOD ke zvýšení kapacity řešení. Obrázek 1 představuje referenční architekturu zobrazující rozšíření kapacity DISKŮ SAS do stávajících diskových polí PowerVault ME4084.
Řešení PixStor zahrnuje rozsáhlý systém souborů General Parallel File System, známý také jako komponenta Spectrum Scale, a to kromě řady dalších softwarových komponent Arcastream, jako je pokročilá analýza, zjednodušená správa a monitorování, efektivní vyhledávání souborů, pokročilé možnosti brány a mnoho dalších.


Obrázek 1: Referenční architektura.

 

---

Komponenty řešení

Toto řešení bude vydáno s nejnovějšími procesory Intel Xeon 2. generace Scalable Xeon, neboli procesory Cascade Lake a některé servery budou používat nejrychlejší dostupnou paměť RAM (2 933 MT/s). Vzhledem k aktuálnímu dostupnému hardwaru, který je však dostupný na jádru řešení a charakterizuje výkon, se servery s procesory Intel Xeon Scalable Xeon 1. generace, také jako K charakterizovat tento systém byly použity procesory Skylake a v některých případech pomalejší paměť RAM. Vzhledem k tomu, že problematické místo řešení spočívá u řadičů SAS polí DellEMC PowerVault ME40x4, po výměně procesorů Skylake a paměti RAM za představované procesory Cascade Lake a rychlejší paměť RAM se neočekávaná výrazná rozdílnost výkonu. Řešení bylo navíc aktualizováno na nejnovější verzi aplikace PixStor (5.1.1.4), která podporuje systémy RHEL 7.7 a OFED 4.7, aby bylo zajištěno charakteristiky systému.

Z důvodu výše popsané situace obsahuje tabulka 1 seznam hlavních komponent pro řešení, ale při zavedení nesouladu se ve sloupci s prvním popisem používají komponenty v době vydání, a proto jsou pro zákazníky k dispozici. Poslední sloupec je komponenty, které se skutečně používají k charakterizovat výkon řešení. Disky uvedené pro data (12TB NLS) a metadata (960Gb disk SSD) jsou disky používané pro charakterizaci výkonu a rychlejší disky mohou poskytovat lepší náhodné IOPs a mohou zlepšit operace vytvoření/odebrání metadat.

Pro úplnost byl také zahrnut seznam možných datových pevných disků a disků SSD s metadaty, který je založen na podporovaných discích uvedených v matici podpory úložiště DellEMC PowerVault ME4, která je dostupná online.

Tabulka 1 Komponenty používané v době uvolnění a komponenty použité na testbedu

Komponenta řešení		Ve vydání	TestBed
Interní konektivita		Gigabitový ethernet Dell Networking S3048-ON
Subsystém datového úložiště		1x až 4x Dell EMC PowerVault ME4084 1x až 4x dell EMC PowerVault ME484 (jeden na ME4084) 80 – 12TB 3,5" disky NL SAS3 s kapacitou 900 GB @15K, 1,2 TB @10K, 1,8 TB @10K, 2,4 TB @10K, 4 TB NLS, 8 TB NLS, 10 TB NLS, 12 TB NLS     8 LUN, lineární 8+2 RAID 6, velikost bloku 512 KiB. 4x 1,92TB disk SSD SAS3 pro metadata – 2x RAID 1 (nebo 4 – globální náhradní disky HDD, pokud se používá volitelný modul metadat vysoké poptávky)
Volitelný subsystém úložiště metadat vysoké poptávky		1x až 2 pevné disky Dell EMC PowerVault ME4024 (v případě potřeby 4x ME4024, pouze velká konfigurace) 24 960GB 2,5" disků SSD SAS3 (možnosti 480 GB, 960 GB, 1,92 TB), 12 jednotek LUN, lineární RAID 1.
Řadiče úložiště RAID		12 Gb/s SAS
Kapacita dle konfigurace		Syrové: 8 064 TB (7 334 TIB nebo 7,16 PB) – naformátováno ~ 6 144 GB (5 588 tiB nebo 5,46 PB)
Procesor	Gateway	2x procesor Intel Xeon Gold 6230, 2,1 GHz, 20C/40T, 10,4 GT/s, 27,5 MB cache, Turbo, HT (125 W), paměť DDR4-2933	Není k dispozici
	Metadata vysoké poptávky		2x Intel Xeon Gold 6136 s frekvencí 3,0 GHz, 12 jader
	Uzel úložiště		2x Intel Xeon Gold 6136 s frekvencí 3,0 GHz, 12 jader
	Uzel pro správu	2x procesor Intel Xeon Gold 5220, 2,2 GHz, 18C/36T, 10,4 GT/s, 24,75 MB cache, Turbo, HT (125 W), paměť DDR4-2666	2x Intel Xeon Gold 5118 s frekvencí 2,30 GHz, 12 jader
Paměť	Gateway	12x 16GB moduly RDIMM 2 933 MT/s (192 GB)	Není k dispozici
	Metadata vysoké poptávky		24x 16GB moduly RDIMM 2 666 MT/s (384 GB)
	Uzel úložiště		24x 16GB moduly RDIMM 2 666 MT/s (384 GB)
	Uzel pro správu	12 x 16 GB modulů DIMM, 2 666 MT/s (192 GB)	12x 8GB moduly RDIMM 2 666 MT/s (96 GB)
Operační systém		Red Hat Enterprise Linux 7.6	Red Hat Enterprise Linux 7.7
Verze jádra		3.10.0-957.12.2.el7.x86_64	3.10.0-1062.9.1.el7.x86_64
PixStor Software		5.1.0.0	5.1.1.4
Škála Spectrum (GPFS)		5.0.3	5.0.4-2
Vysoce výkonná síťová konektivita		Mellanox ConnectX-5 Dual-Port InfiniBand EDR/100 GbE a 10 GbE	Mellanox ConnectX-5 InfiniBand EDR
Vysoce výkonný přepínač		2x Mellanox SB7800 (HA – redundantní)	1x Mellanox SB7700
Verze systému OFED		Mellanox OFED-4.6-1.0.1.0	Mellanox OFED-4.7-3.2.9
Místní disky (OS & Analýza/monitorování)		Všechny servery kromě uzlu pro správu 3x 480GB disk SSD SAS3 (RAID1 + HS) pro operační systém Řadič PERC H730P RAID Uzel pro správu 3x 480GB disk SSD SAS3 (RAID1 + HS) pro operační systém Řadič PERC H740P RAID	Všechny servery kromě uzlu pro správu 2x 300GB disk SAS3 (RAID 1), 15 000 ot./min., pro operační systém Řadič PERC H330 RAID Uzel pro správu 5x 300GB disk SAS3 (RAID 5), 15 000 ot./min., pro operační systém a analýzu/monitorování Řadič PERC H740P RAID
Správa systému		iDRAC 9 Enterprise + DellEMC OpenManage	iDRAC 9 Enterprise + DellEMC OpenManage

 

---

Charakteristika výkonu

Chcete-li toto nové řešení Ready Solution charakterizovat, použili jsme hardware uvedený v posledním sloupci tabulky 1, včetně volitelného modulu metadat vysoké poptávky. Pro posouzení výkonu řešení byly použity následující srovnávací testy:

• Sekvenční IOzone N na N
• IOR N až 1 sekvenční
• Náhodný IOzone
• Test MD

 U všech srovnávacích testů uvedených výše měl testbed klienty, jak je popsáno v tabulce 2 níže. Vzhledem k tomu, že počet výpočetních uzlů, které byly k dispozici pro testování, byl pouze 16, když byl vyžadován vyšší počet vláken, tyto vlákna byly rovnoměrně distribuovány 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, 1 024 vláken = 64 vláken na uzel). Záměrem bylo simulovat vyšší 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 (pro každý test) a zároveň se zabránilo nadměrnému přepínání kontextu a dalším vedlejším efektům ovlivnění výsledků výkonu.

Tabulka 2 Testbed pro klienty

Počet klientských uzlů	16
Uzel klienta	C6320
Procesory na uzel klienta	2x procesor Intel(R) Xeon(R) Gold E5-2697v4, 18 jader, 2,30 GHz
Paměť na uzel klienta	12x 16GB moduly 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 N klientů IOzone se soubory N

Sekvenční výkon klientů N k souborům N byl měřen pomocí verze IOzone 3.487. Provedené testy se liší od jednoho vlákna až do 1 024 vláken a výsledky řešení s rozšířením kapacity (4x ME4084s + 4x ME484s) jsou kontrastovány s řešením velké velikosti (4x ME4084s). Efekty mezipaměti byly minimalizovány nastavením fondu stránek GPFS vyladěného na 16 Gb a využitím souborů větších než dvojnásobná velikost. U systému GPFS, který lze vyladit, je důležité zaznamenat, že nastaví maximální velikost paměti používané pro data v mezipaměti bez ohledu na velikost nainstalované a volné paměti RAM. Je také důležité si všimnout, že i když u předchozích řešení DellEMC HPC má velikost bloku pro velké sekvenční přenosy hodnotu 1 MiB, formát GPFS byl formátován 8 bloky MiB, a proto se tato hodnota používá v benchmarku pro optimální výkon. Tento vzhled může vypadat příliš velký a patrně zaplněn příliš mnoho místa, ale soubor GPFS používá k zabránění vzniku dané situace přidělení podbloku. V aktuální 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 navýšila o mocniny dvou) a threadlist byl soubor, který přiděloval každé vlákno na jiný uzel a pomocí kruhového dotazování je homogenním způsobem rozprostřel na 16 výpočetních uzlů.

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

Obrázek 2:  Sekvenční výkon


N–NZ výsledků můžeme pozorovat, že výkon se velmi rychle zvyšuje s počtem používaných klientů a poté dosáhne tuhnutí, které je stabilní, dokud nedosáhne maximálního počtu vláken povolených aplikací IOzone, a proto je velký souborový výkon stabilní i u 1 024 souběžných klientů. Všimněte si, že výkon čtení i zápisu těžil ze zdvojnásobení počtu disků. Maximální čtecí výkon byl omezen šířkou pásma dvou odkazů IB EDR POUŽÍVANÝCH na uzlech úložiště s 8 vlákny a pole ME4 mohou mít k dispozici určitý další výkon. Podobně si všimněte, že maximální rychlost zápisu se zvýšila z maximálně 16,7 na 20,4 GB/s při 64 a 128 vláknech a je blíže k maximálním specifikacím polí ME4 (22 GB/s).

Zde je důležité si uvědomit, že upřednostňovaný provozní režim systému SOUBORŮ GPFS je rozptýlený a řešení bylo formátováno tak, aby používalo tento režim. V tomto režimu jsou bloky přidělovány od samého začátku provozu pseudo náhodným způsobem a rozkládají se data po celém povrchu každého pevného disku. I když je zřejmá nevýhoda menší počáteční maximální výkon, výkon se udržuje poměrně neustále bez ohledu na to, kolik místa se v souborovém systému používá. Na rozdíl od jiných paralelních souborových systémů, které původně používají vnější obory, které mohou pojmout více dat (sektorů) na jednu revoluci na disk, a proto mají nejvyšší možný výkon, který mohou pevné disky poskytnout, ale jelikož systém využívá více místa, používají se vnitřní obory s menším počtem dat na revoluci, s následným snížením výkonu.

 

---

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

Sekvenční klienti N k výkonu jednoho sdíleného souboru se změřili s verzí IOR 3.3.0 a s pomocí OpenMPI v4.0.1 spustili srovnávací test na 16 výpočetních uzlech. Provedené testy se liší od jednoho vlákna až do 512 vláken (protože pro 1 024 vláken nebyla dostatečná jádra) a výsledky jsou kontrastovány k řešení bez rozšíření kapacity.
Efekty mezipaměti byly minimalizovány nastavením fondu stránek GPFS vyladěného na 16 Gb a využitím souborů větších než dvojnásobná velikost. Tyto srovnávací testy používaly pro optimální výkon 8 bloků MiB. Předchozí část testu výkonu obsahuje úplnější vysvětlení všech 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 zvyšuje o mocniny po dvou) a my_hosts.$Threads je odpovídající soubor, který přidělil každé vlákno na jiný uzel, pomocí kruhového dotazování homogenního šíření napříč 16 výpočetními uzly.

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 /mmfs 1/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: Sekvenční výkon

N až 1. Z výsledků můžeme znovu pozorovat, že dodatečné disky využívají výkon čtení a zápisu. Výkon se opět velmi rychle zvyšuje díky počtu použitých klientů a poté dosáhne ustálení, které je poměrně stabilní pro čtení a zápis až na maximální počet vláken použitých v tomto testu. Všimněte si, že maximální čtecí výkon činil 24,8 Gbit/s při 16 vláknech a problematickou pozicí bylo rozhraní InfiniBand EDR, přičemž pole ME4 měla stále nějaký další výkon. Od tohoto okamžiku se výkon čtení od uvedené hodnoty snižuje, dokud se nedosáhnete usmyše na přibližně 23,8 GB/s. Podobně si všimněte, že maximální zápisový výkon 19,3 bylo dosaženo na 8 vláknech a dosáhnete astmy.
 

---

Náhodné malé bloky klientů IOzone Performance N do souborů N

Výkon náhodných klientů N pro soubory N byl měřen pomocí FIO verze 3.7 namísto tradičního Iozone. Záměr, jak je uveden v předchozím blogu, měl využít větší hloubku fronty a prozkoumat maximální možný výkon polí ME4084 (předchozí testy různých řešení ME4 ukázaly, že pole ME4084 vyžadují větší tlak IO, který může systém Iozone dodávat k dosažení jejich náhodných limitů IO).

Testy se měnily od jednoho vlákna až do 512 vláken, protože pro 1 024 vláken nebylo dostatek klientských jader. Každé vlákno používalo jiný soubor a vlákna byla přiřazena kruhového dotazování na uzlech klienta. Tyto srovnávací testy používaly 4 bloky KiB pro emulaci provozu malých bloků a použití hloubky fronty 16. Porovnávají se výsledky řešení velké velikosti a rozšíření kapacity.

Efekty mezipaměti byly znovu minimalizovány nastavením fondu stránek GPFS vyladěného na 16 Gb a využitím souborů dvojnásobné velikosti. První část testu výkonu obsahuje úplnější vysvětlení, proč je to v systému GPFS efektivní.

 
Obrázek 4:  Náhodný výkon

N–N Z výsledků můžeme pozorovat, že výkon zápisu začíná na vysoké hodnotě 29,1 000 IOps a plynule se zvyšuje až na 64 vláken, kde se zdá, že dosahuje přibližně 40 000 IOps. Čtecí výkon na druhou stranu začíná na 1,4 kB IOps a zvyšuje výkon téměř lineárním způsobem s počtem použitých klientů (mějte na paměti, že počet vláken se zdvojnásobuje pro každý datový bod) a dosahuje maximálního výkonu 25,6 tisíc IOPS při 64 vláknech, kde se zdá, že se blíží k uvažování. Použití více vláken bude vyžadovat více než 16 výpočetních uzlů, aby nedocházelo k nepotřebným prostředkům a nižšímu patrnému výkonu, kde by pole mohla ve skutečnosti zachovat výkon.

 

---

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

Výkon metadat byl měřen pomocí nástroje MDtest verze 3.3.0, s pomocí nástroje OpenMPI verze 4.0.1, který spustil srovnávací test na 16 výpočetních uzlech. Provedené testy se liší od jednoho vlákna až do 512 vláken. Srovnávací test byl použit pouze pro soubory (bez metadat adresářů), získávání počtu vytvoření, statistiky, čtení a odebrání řešení, které může řešení zpracovat, a výsledky byly kontrastovány s řešením Large size.

Ke správnému vyhodnocení řešení v porovnání s jinými úložnými řešeními DellEMC HPC a předchozími výsledky na blogu byl použit volitelný modul metadat vysoké poptávky, ale s jedním polem ME4024 i to, že velká konfigurace a otestovaná v tomto provedení byla určena pro dva monitory ME4024. Tento modul metadat vysoké poptávky může podporovat až čtyři pole ME4024 a doporučuje se před přidáním dalšího modulu metadat zvýšit počet polí ME4024 na 4. Očekává se, že další pole ME4024 zvýší výkon metadat lineálně s každým doplňkovým polem, s výjimkou operací statistiky (a čtení prázdných souborů), protože čísla jsou velmi vysoká, v určitém okamžiku se procesor změní na problematická místa a výkon se nebude nadále zvyšovat linelogicky.

K provedení srovnávacího testu byl použit následující příkaz, kde Threads byla proměnná s počtem použitých vláken (1 až 512 navýšených mocnin po dvou) a my_hosts.$Threads je odpovídající soubor, který přidělil každé vlákno na jiný uzel, pomocí kruhového dotazování homogenního šíření napříč 16 výpočetními uzly. Podobně jako u srovnávacího testu Random IO byl maximální počet vláken omezen na 512, protože pro 1 024 vláken není dostatek jader a přepínání kontextu by ovlivnilo výsledky a nahlásilo číslo nižší, než je 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 IOP, počtem souborů na adresář a počtem vláken, bylo rozhodně opraven celkový počet souborů na 2 soubory MiB (2^21 = 2097152), počet souborů na adresář opravený číslem 1024 a počet adresářů se liší podle počtu vláken změněných podle tabulky 3.

Tabulka 3:  Distribuce souborů VDtest v adresářích

Počet vláken	Počet adresářů ve vlákně	Celkový počet souborů
1	2048	2,097,152
2	1024	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
1024	2	2,097,152

Obrázek 5: Výkon metadat – prázdné soubory

Nejprve si povšimněte, že zvolené měřítko bylo logaritmické se základní 10, aby bylo možné porovnávat operace s různými řády; v opačném případě by některé operace v normálním grafu vypadaly jako plochá čára blízko 0. Graf protokolů se základem 2 může být vhodnější, protože počet vláken se zvyšuje o mocniny 2, ale graf by vypadal velmi podobně a lidé obvykle manipulují s lepšími čísly na základě mocnin 10.
Systém získává velmi dobré výsledky díky operacím statistiky a čtení, které dosahují maximální hodnoty při 64 vláknech, s téměř 11 mb/s a 4,7 mb provozu/s. Operace demontáže zaškrtly maximální výkon 170 600 ot./s při 16 vláknech a vytvářely maximální výkon při 32 vláknech s rychlostí 222 100 ot./min. Operace statistiky a čtení nabízejí větší variabilitu, ale jakmile dosáhnou maximální hodnoty, výkon pro statistiky neklesne pod 3 mb/s a rychlost čtení 2 mb. Tvorba a odebrání jsou stabilnější, jakmile dosáhnou ustálení a zůstanou nad 140 000 000 operací k odebrání a 120 000 ot./min. k vytvoření. Všimněte si, že dodatečné disky nemají vliv na většinu operací metadat u prázdných souborů podle očekávání.
 

---

Výkon metadat pomocí nástroje MDtest pomocí 4 souborů KIB

Tento test je téměř identický s tím předchozím, kromě toho, že místo prázdných souborů byly použity malé soubory 4 KiB. 
K provedení srovnávacího testu byl použit následující příkaz, kde Threads byla proměnná s počtem použitých vláken (1 až 512 navýšených mocnin po dvou) a my_hosts.$Threads je odpovídající soubor, který přidělil každé vlákno na jiný uzel, pomocí kruhového dotazování homogenního šíření napříč 16 výpočetními uzly.

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 získává velmi dobré výsledky při operacích statistiky a odstraňování, které dosahují maximální hodnoty při 256 vláknech s rychlostí 8,2 mb/s a rychlostí 400 000 ot./min. Operace čtení dosáhly maximálního počtu operací 44 800 ot./s a vytvářely maximální výkon s rychlostí 68 100 ot./min. při 512 vláknech. Operace statistiky a demontáže mají větší variabilitu, ale jakmile dosáhnou maximální hodnoty, výkon pro statistiky neklesne pod 3 mb/s a rychlost 280 000 ot./min. k odstranění. Vytvářejte a čtěte méně variability a s rostoucím počtem vláken se neustále zvyšuje. Jak je patrné, dodatečné disky rozšíření kapacity poskytují pouze okrajové změny výkonu metadat.
Jelikož jsou tato čísla odpovědná za modul metadat s jedním procesorem ME4024, u každé další pole ME4024 se výkon zvýší, nicméně u každé operace nelze pouze předpokládat lineární zvýšení. Pokud se celý soubor nezapadne do struktury inode tohoto souboru, budou k ukládání souborů 4K použity datové cíle na zařízení ME4084s, čímž se výkon do určité míry omezí. Vzhledem k tomu, že velikost uzlu inode je 4 KiB a přesto musí ukládat metadata, vejdou se dovnitř pouze soubory o velikosti přibližně 3 KIB a jakýkoli soubor větší, než který využívá datové cíle.
 

---

Závěry a budoucí práce

Řešení s rozšířenou kapacitou bylo schopné zlepšit výkon nejen pro náhodný přístup, ale i pro sekvenční výkon. To se očekávalo, protože rozptylovaný režim se chová tak, jak dvojitý přístup a má více disků, a to umožňuje zlepšení. Očekává se, že výkon, který lze zobrazit v tabulce 4, bude z prázdného systému souborů stabilní, dokud nebude téměř plný. Řešení se dále lineárním škálováním kapacity a výkonu při přidávání více úložných uzlů a od volitelného modulu metadat vysoké poptávky lze očekávat podobný nárůst výkonu. Toto řešení poskytuje zákazníkům HPC velmi spolehlivý paralelní souborový systém používaný mnoha clustery TOP 500 HPC. 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 je NFS, SMB a další, pro tolik klientů, kolik je potřeba.

Tabulka 4  Špičkový a trvalý výkon

	Špičkový výkon		Udržovaný výkon
	Zápis	Read	Zápis	Read
Velké sekvenční N klienty k souborům N	20,4 GB/s	24,2 GB/s	20,3 GB/s	24 GB/s
Velký sekvenční klient N pro jeden sdílený soubor	19,3 GB/s	24,8 GB/s	19,3 GB/s	23,8 GB/s
Náhodné malé bloky klientů N do souborů N	40 KIOps	25,6 KIOps	40.0KiOps	19.3KiOps
Metadata – Vytvoření prázdných souborů	169,4 tisíce IOps		123,5 tisíce IOps
Prázdné soubory statistiky metadat	11měsíční služba IOps		3,2m IOps
Metadata – prázdné soubory ke čtení	4,7m IOps		2,4M IOps
Metadata Odebrat prázdné soubory	170,6 tisíce IOps		156,5 tisíce IOps
Metadata vytvářejí soubory 4 KiB	68 100 IOps		68 100 IOps
Statistiky metadat se soubory 4 KiB	8,2m IOps		3m IOps
Soubory 4KiB ke čtení metadat	44 800 IOps		44 800 IOps
Odstranění souborů 4KiB metadat	400 000 IOps		280 000 IOps

Vzhledem k tomu, že řešení je určeno k vydání s procesory Cascade Lake a rychlejší paměti RAM, po dokončení poslední konfigurace systému budou provedeny některé kontroly výkonu. A otestujte volitelný modul metadat vysoké poptávky s alespoň 2 soubory ME4024s a 4 KiB, abyste lépe zdokumentujte, jak se výkon metadat škáluje při zapojení datových cílů. Kromě toho bude výkon uzlů brány měřen a hlášen spolu s veškerými relevantními výsledky kontrol místa v novém blogu nebo dokumentu whitepaper. V neposlední části je plánováno testování a vydání dalších součástí řešení, které zajistí ještě více možností.