Dell EMC Ready Solution til HPC PixStor-lagring - Kapacitetsudvidelse

Ingen

Indholdsfortegnelse

1. Indledning
   1. Løsningsarkitektur
   2. Løsningskomponenter
2. Ydeevne karakterisering
   1. Sekventielle IOzone Performance N-klienter til N-filer
   2. Sekventielle IOR Performance N-klienter til 1 fil
   3. Tilfældige små blokke IOzone Performance N-klienter til N-filer
   4. Metadataydeevne med MDtest ved hjælp af tomme filer
   5. Metadataydeevne med MDtest med 4 KiB-filer
3. Konklusioner og fremtidigt arbejde

 

---

Indledning

Nutidens HPC-miljøer har øget kravene til lynhurtig storage, der også ofte kræver høj kapacitet og distribueret adgang via flere standardprotokoller som NFS, SMB og andre. Disse høje krav til HPC er typisk dækket af parallelle filsystemer, der giver samtidig adgang til en enkelt fil eller et sæt filer fra flere noder, meget effektivt og sikkert at distribuere data til flere LUN'er på tværs af flere servere.

 

---

Løsningsarkitektur

Denne blog er en fortsættelse af PFS-løsningen (Parallel File System) til HPC-miljøer, DellEMC Ready Solution til HPC PixStor Storage, hvor PowerVault ME484 EBOD-systemer bruges til at øge løsningens kapacitet. Figur 1 præsenterer referencearkitekturen, der viser kapacitetsudvidelses-SAS-tilføjelser til de eksisterende PowerVault ME4084-storagesystemer.
PixStor-løsningen omfatter det udbredte generelle parallelle filsystem, også kendt som Spectrum Scale som PFS-komponenten, ud over mange andre Arcastream-softwarekomponenter som avanceret analyse, forenklet administration og overvågning, effektiv filsøgning, avancerede gatewayfunktioner og mange andre.


Figur 1: Referencearkitektur.

 

---

Løsningskomponenter

Denne løsning er planlagt til at blive frigivet med de nyeste Intel Xeon 2. generations skalerbare Xeon-CPU'er, også cascade Lake CPU'er, og nogle af serverne vil bruge den hurtigste RAM, der er tilgængelig (2933 MT/s). Men på grund af den aktuelle hardware, der kan arbejde på løsningens karakteristik, kan servere med Intel Xeon 1. generations skalerbare Xeon CPU'er a.k.a. Skylake-processorer og i nogle tilfælde langsommere RAM blev brugt til at karakterisere dette system. Da flaskehalsen i løsningen er hos SAS-controllerne i DellEMC PowerVault ME40x4-systemerne, forventes der ingen betydelig forskel i ydeevnen, når Skylake CPU'erne og RAM'erne udskiftes med de iberede Cascade Lake CPU'er og hurtigere RAM. Derudover blev løsningen opdateret til den nyeste version af PixStor (5.1.1.4), der understøtter RHEL 7.7 og OFED 4.7 til karakterisering af systemet.

På grund af den tidligere beskrevne situation har tabel 1 en liste over hovedkomponenterne til løsningen, men da der blev introduceret uoverensstemmelser, bruges den første beskrivelseskolonne på udgivelsestiden og er derfor tilgængelig for kunderne, og den sidste kolonne er de komponenter, der rent faktisk bruges til at angive løsningens ydeevne. De drev, der er angivet for data (12 TB NLS) og metadata (960 Gb SSD), er dem, der bruges til ydelses karakterisering, og hurtigere drev kan give bedre Tilfældige IOPer og kan forbedre metadatahandlinger for oprettelse/fjernelse.

For fuldstændighed blev listen over mulige data-HDD'er og metadata-SSD'er medtaget, som er baseret på de drev, der understøttes som anført i DellEMC PowerVault ME4-supportmatrixen, som er tilgængelige online.

Tabel 1: Komponenter, der anvendes på udgivelsestidspunktet, og dem, der anvendes på testblaget

Løsningskomponent		Ved frigivelse	Testskinne
Interne tilslutningsmuligheder		Dell Networking S3048-ON Gigabit Ethernet
Datalagringsundersystem		1x til 4x Dell EMC PowerVault ME4084 1 x til 4 x Dell EMC PowerVault ME484 (én pr. ME4084) 80-12 TB 3,5" NL SAS3 HDD-drev Muligheder 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 LUNs, lineær 8+2 RAID 6, chunk-størrelse 512 KiB. 4 x 1,92 TB SAS3 SSD'er for metadata – 2 x RAID 1 (eller 4 – Global HDD-reservedele, hvis der bruges et valgfrit High Demand-metadatamodul)
Valgfrit lagringsundersystem med høj efterspørgselsmetadata		1 x til 2 x Dell EMC PowerVault ME4024 (4 x ME4024, hvis det er nødvendigt, kun stor konfiguration) 24 x 960 GB 2,5" SSD SAS3-drev (muligheder 480 GB, 960 GB, 1,92 TB) 12 LUN'er, lineær RAID 1.
RAID Storage-controllere		12 Gbps SAS
Kapacitet som konfigureret		Rå: 8064 TB (7334 TiB eller 7,16 PiB) formateret ~ 6144 GB (5588 TiB eller 5,46 PiB)
Processor	Gateway	2x Intel Xeon Gold 6230 2,1 GHz, 20 kerner/40 T, 10,4 GT/s, 27,5 MB cache, turbo, HT (125 W) DDR4-2933	Ikke tilgængelig
	Metadata for høj efterspørgsel		2x Intel Xeon Gold 6136 ved 3,0 GHz, 12 kerner
	Storagenode		2x Intel Xeon Gold 6136 ved 3,0 GHz, 12 kerner
	Administrationsnode	2x Intel Xeon Gold 5220 2,2 GHz, 18 kerner/36 T, 10,4 GT/s, 24,75 MB cache, turbo, HT (125 W) DDR4-2666	2x Intel Xeon Gold 5118 ved 2,30 GHz, 12 kerner
Hukommelse	Gateway	12x 16 GiB 2933 MT/s RDIMM'er (192 GiB)	Ikke tilgængelig
	Metadata for høj efterspørgsel		24x 16 GiB 2666 MT/s RDIMM'er (384 GiB)
	Storagenode		24x 16 GiB 2666 MT/s RDIMM'er (384 GiB)
	Administrationsnode	12 x 16 GB DIMM-moduler, 2666 MT/s (192 GiB)	12x 8 GiB 2666 MT/s RDIMM'er (96 GiB)
Operativsystem		Red Hat Enterprise Linux 7.6	Red Hat Enterprise Linux 7.7
Kerneversion		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
Spektrumsskala (GPFS)		5.0.3	5.0.4-2
Netværkstilslutningsmuligheder med høj ydeevne		Mellanox ConnectX-5 Dual-Port InfiniBand EDR/100 GbE og 10 GbE	Mellanox ConnectX-5 InfiniBand EDR
Switch med høj ydeevne		2x Mellanox SB7800 (HA – redundant)	1 x Mellanox SB7700
OFED-version		Mellanox OFED-4.6-1.0.1.0	Mellanox OFED-4.7-3.2.9
Lokale diske (OS &analyse/overvågning)		Alle servere undtagen administrationsnoden 3 x 480 GB SSD SAS3 (RAID1 + HS) til OS PERC H730P RAID-controller Administrationsnode 3 x 480 GB SSD SAS3 (RAID1 + HS) til OS PERC H740P RAID-controller	Alle servere undtagen administrationsnoden 2 x 300 GB 15K SAS3 (RAID 1) til OS PERC H330 RAID-controller Administrationsnode 5x 300 GB 15K SAS3 (RAID 5) til os > Analyse/overvågning PERC H740P RAID-controller
Systemadministration		iDRAC 9 Enterprise + DellEMC OpenManage	iDRAC 9 Enterprise + DellEMC OpenManage

 

---

Ydeevne karakterisering

For at karakterisere denne nye Ready Solution brugte vi den hardware, der er angivet i sidste kolonne i tabel 1, herunder det valgfrie High Demand metadata-modul. For at vurdere løsningens ydeevne blev følgende benchmarks anvendt:

• IOzone N til N sekventiel
• IOR N til 1 sekventiel
• Vilkårlig IOzone
• MDtest

 For alle benchmarks angivet ovenfor havde testbøjet klienterne som beskrevet i tabel 2 nedenfor. Da antallet af beregningsnoder, der var tilgængelige for test, kun var 16, når et højere antal tråde var påkrævet, blev disse tråde ligeligt fordelt på beregningsnoderne (dvs. 32 tråde = 2 tråde pr. node, 64 tråde = 4 tråde pr. node, 128 tråde = 8 tråde pr. node, 256 tråde = 16 tråde pr. node, 512 tråde = 32 tråde pr. node, 1024 tråde = 64 tråde pr. node). Hensigten var at simulere et højere antal samtidige klienter med det begrænsede antal beregningsnoder. Da benchmarks understøtter et højt antal tråde, blev der anvendt en maksimal værdi på op til 1024 (specificeret for hver test), mens overdreven kontekstskift og andre relaterede bivirkninger blev forhindret i at påvirke ydeevneresultaterne.

Tabel 2: Klienttestseng

Antal klientnoder	16
Klientnode	C6320
Processorer pr. klientnode	2 x Intel(R) Xeon(R) Gold E5-2697v4 18 kerner ved 2,30 GHz
Hukommelse pr. klientnode	12 x 16 GiB 2400 MT/s RDIMM'er
BIOS	2.8.0
OS-kerne	3.10.0-957.10.1
GPFS-version	5.0.3

 

---

Sekventielle IOzone Performance N-klienter til N-filer

Sekventielle N-klienters til N-filers ydeevne måltes med IOzone-version 3.487. Udførte test varierede fra enkelttråd op til 1024 tråde, og resultaterne af den udvidede kapacitetsløsning (4 x ME4084s + 4x ME484s) er i kontrast til løsningen i stor størrelse (4 x ME4084s). Cachelagringseffekter blev minimeret ved at indstille GPFS-sidepuljen, der kan justeres til 16 GiB, og bruge filer, der er større end to gange så stor. Det er vigtigt at bemærke, at for GPFS indstilles den maksimale mængde hukommelse, der bruges til cachelagring af data, uanset mængden af installeret og ledig RAM. Det er også vigtigt at bemærke, at mens blokstørrelsen for tidligere DellEMC HPC-løsninger for store sekventielle overførsler er 1 MiB, blev GPFS formateret med 8 MiB-blokke, og derfor bruges denne værdi på benchmarket for optimal ydeevne. Det kan se for stort ud og tilsyneladende spilder for meget plads, men GPFS bruger underblokeringsallokering til at forhindre den situation. I den aktuelle konfiguration var hver blok opdelt i 256 underblokke på 32 KiB hver.

Følgende kommandoer blev brugt til at udføre benchmark for skrivninger og læsninger, hvor tråde var variablen med antallet af anvendte tråde (1 til 1024 trinvist i 2. styrke), og trådliste var filen, der tildelte hver tråd på en anden node, og ved hjælp af round robin kunne de homogent sprede dem på tværs af de 16 beregningsnoder.

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

Figur 2:  N til N sekventiel ydeevne


Ud fra resultaterne kan vi observere, at ydeevnen stiger meget hurtigt med antallet af anvendte klienter og derefter når en slumretilstand, der er stabil, indtil det maksimale antal tråde, som IOzone tillader, er nået, og derfor er stor filsekvensydelse stabil selv for 1024 samtidige klienter. Bemærk, at både læse- og skriveydeevnen fordobler antallet af drev. Den maksimale læseydeevne blev begrænset af båndbredden for de to IB EDR-links, der bruges på storage-noderne, startende med 8 tråde, og ME4-systemer kan have en ekstra ydeevne til rådighed. Bemærk ligeledes, at den maksimale skriveydeevne forøges fra maksimalt 16,7 til 20,4 GB/s ved 64 og 128 tråde, og at den er tættere på de maksimale SPECIFIKATIONER for ME4-systemerne (22 GB/s).

Her er det vigtigt at huske, at GPFS's foretrukne driftstilstand er spredt, og løsningen er formateret til at bruge en sådan tilstand. I denne tilstand tildeles blokke helt fra begyndelsen af driften på en pseudo-tilfældig måde og spredes data over hele overfladen af hver harddisk. Selvom den indlysende ulempe er en mindre indledende maksimal ydeevne, bevares denne ydelse ret konstant, uanset hvor meget plads der bruges på filsystemet. Det er i modsætning til andre parallelle filsystemer, der i første omgang anvender de yderste spor, der kan indeholde flere data (sektorer) pr. disk-revolution, og derfor har den bedst mulige ydeevne, som HDD'erne kan levere, men da systemet bruger mere plads, anvendes der indvendige spor med færre data pr. revolution med den deraf følgende reduktion af ydeevnen.

 

---

Sekventielle IOR Performance N-klienter til 1 fil

Sekventielle N-klienter til en enkelt delt filydeevne blev målt med IOR-version 3.3.0, assisteret af OpenMPI v4.0.1 for at køre benchmarket over 16 beregningsnoder. Udførte test varierede fra én tråd op til 512 tråde (da der ikke var nok kerner til 1024 tråde), og resultaterne er kontrasteret til løsningen uden kapacitetsudvidelsen.
Cachelagringseffekter blev minimeret ved at indstille GPFS-sidepuljen, der kan justeres til 16 GiB, og bruge filer, der er større end to gange så stor. Denne benchmarktest brugte 8 MiB-blokke for optimal ydeevne. Det forrige afsnit til ydeevnetest har en mere fuldstændig forklaring på disse spørgsmål.

Følgende kommandoer blev brugt til at udføre benchmark for skrivninger og læsninger, hvor tråde var variablen med antallet af anvendte tråde (1 til 1024 forøget i to kompetencer), og my_hosts.$Threads er den tilsvarende fil, der tildelte hver tråd på en anden node, ved hjælp af Round Robin til at sprede dem homogent på tværs af de 16 beregningsnoder.

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 -e -k -o /mmfs1/perftest/tst.file -r -s 1 -t 8m -b 128G

Figur 3: N til 1 Sekventiel ydeevne

Ud fra resultaterne kan vi igen observere, at de ekstra drev har fordel af læse- og skriveydeevne. Ydeevnen stiger igen meget hurtigt med antallet af anvendte klienter og når derefter en indikator, der er ret stabil for læsninger og skrivninger helt til det maksimale antal tråde, der anvendes i denne test. Bemærk, at den maksimale læseydeevne var 24,8 GB/s ved 16 tråde, og flaskehalsen var InfiniBand EDR-grænsefladen, mens ME4-systemer stadig havde en ekstra ydelse til rådighed. Fra det tidspunkt blev læseydeevnen reduceret fra denne værdi, indtil den blev på omkring 23,8 GB/s. På samme måde bemærkes det, at den maksimale skriveydeevne på 19,3 blev nået ved 8 tråde og nå en fejl.
 

---

Tilfældige små blokke IOzone Performance N-klienter til N-filer

Tilfældige N-klienter til N-filers ydeevne blev målt med FIO-version 3.7 i stedet for den traditionelle Iozone. Hensigten, som angivet i den forrige blog, var at drage fordel af en større kødybde til at undersøge den maksimalt mulige ydeevne, som ME4084-systemer kan levere (tidligere tests til forskellige ME4-løsninger viste, at ME4084-systemer har brug for et større IO-tryk, som Iozone kan levere for at nå deres tilfældige IO-grænser).

Udførte test varierede fra enkelttråd op til 512 tråde, da der ikke var nok klientkerner til 1024 tråde. Hver tråd brugte en anden fil, og trådene blev tildelt round robin på klientnoderne. Denne benchmarktest brugte 4 KiB-blokke til at sætte trafik i mindre blokke og bruge en kødybde på 16. Resultaterne fra løsningen i stor størrelse og kapacitetsudvidelsen sammenlignes.

Cachelagringseffekter blev igen minimeret ved at indstille GPFS-sidepuljen, der kan indstilles til 16 GiB, og bruge filer to gange så stor. Det første afsnit til ydeevnetest har en mere fuldstændig forklaring på, hvorfor dette gælder for GPFS.

 
Figur 4:  N til N Random Performance

Ud fra resultaterne kan vi observere, at skriveydeevnen starter med en høj værdi på 29,1K IOps og stiger støt op til 64 tråde, hvor det ser ud til at nå en lav værdi på omkring 40K IOps. Læseydeevnen starter derimod med 1,4K IOps og øger ydeevnen næsten lineært med antallet af anvendte klienter (husk, at antallet af tråde fordoblet for hvert datapunkt) og når den maksimale ydeevne på 25,6K IOPS ved 64 tråde, hvor det ser ud til at være tæt på at nå et login. Hvis du bruger flere tråde, kræver det mere end de 16 beregningsnoder for at undgå, at ressourcerne nedsænkes og en lavere tilsyneladende ydeevne, hvor systemerne faktisk kan opretholde ydeevnen.

 

---

Metadataydeevne med MDtest ved hjælp af tomme filer

Metadataydeevnen blev målt med MDtest version 3.3.0, assisteret af OpenMPI v4.0.1 for at køre benchmarket over 16 beregningsnoder. Udførte test varierede fra enkelttråd op til 512 tråde. Benchmark blev kun brugt til filer (ingen mappers metadata), henter antallet af opretter, statistik, læsninger og fjerner, at løsningen kan håndtere, og resultaterne er i kontrast til løsningen i stor størrelse.

For at evaluere løsningen korrekt i forhold til andre DellEMC HPC-lagringsløsninger og de tidligere blogresultater blev det valgfri High Demand Metadata-modul brugt, men med et enkelt ME4024-system, selv at den store konfiguration og testet i dette arbejde blev udpeget til at have to ME4024'er. Dette High Demand-metadatamodul kan understøtte op til fire ME4024-systemer, og det anbefales at øge antallet af ME4024-systemer til 4, før du tilføjer et andet metadatamodul. Yderligere ME4024-systemer forventes at øge metadataydeevnen lineært for hvert ekstra array, undtagen måske for stat-handlinger (og læsninger til tomme filer), da tallene er meget høje, og CPU'erne bliver på et tidspunkt en flaskehals, og ydeevnen vil ikke fortsætte med at stige lineært.

Følgende kommando blev brugt til at udføre benchmarket, hvor trådene var variablen med antallet af anvendte tråde (1 til 512 forøget i to kompetencer), og my_hosts.$Threads er den tilsvarende fil, der tildelte hver tråd på en anden node, og ved hjælp af round robin kunne de homogent sprede dem på tværs af de 16 beregningsnoder. På samme måde som benchmarket Random IO blev det maksimale antal tråde begrænset til 512, da der ikke er nok kerner til 1024 tråde, og kontekstskift ville påvirke resultaterne og rapportere et tal, der er lavere end løsningens reelle ydeevne.

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

Da ydeevneresultaterne kan påvirkes af det samlede antal IOPer, antallet af filer pr. mappe og antallet af tråde, blev det besluttet at fastgøre det samlede antal filer til 2 MiB-filer (2^21 = 2097152), antallet af filer pr. mappe, der er rettet til 1024, og antallet af mapper varierede, efterhånden som antallet af tråde ændredes som vist i tabel 3.

Tabel 3:  MDtest-distribution af filer på mapper

Antal tråde	Antal mapper pr. tråd	Samlet antal filer
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

Figur 5: Metadataydeevne – Tomme filer

Først skal du bemærke, at den valgte skala var logaritmik med base 10 for at tillade sammenligning af handlinger, der har forskelle flere ordrer på torve; ellers vil nogle af handlingerne se ud som en flad linje tæt på 0 i et normalt diagram. Et logdiagram med base 2 kan være mere relevant, da antallet af tråde øges i 2. styrke, men diagrammet ser meget ens ud, og folk har tendens til at håndtere og huske bedre tal baseret på 10.
Systemet får meget gode resultater, når Stat- og Read-handlinger når deres spidsværdi ved 64 tråde med næsten 11 M op/s og 4,7 M op/s. Fjernelseshandlinger på maksimalt 170,6K op/s ved 16 tråde og Opret handlinger, der når deres maksimale ved 32 tråde med 222,1K op/s. Opbevarings- og læsningshandlinger har større varians, men når de når deres maksimale værdi, falder ydeevnen ikke til under 3 M op/s for Statistik og 2 M op/s for Reads. Oprettelse og fjernelse er mere stabil, når de når et skråt niveau og forbliver over 140K op/s til fjernelse og 120K op/s for Create. Bemærk, at de ekstra drev ikke påvirker meget af de fleste metadatahandlinger på tomme filer som forventet.
 

---

Metadataydeevne med MDtest med 4 KiB-filer

Denne test er næsten identisk med den forrige, bortset fra at der i stedet for tomme filer blev brugt små filer med 4 KiB. 
Følgende kommando blev brugt til at udføre benchmarket, hvor trådene var variablen med antallet af anvendte tråde (1 til 512 forøget i to kompetencer), og my_hosts.$Threads er den tilsvarende fil, der tildelte hver tråd på en anden node, og ved hjælp af round robin kunne de homogent sprede dem på tværs af de 16 beregningsnoder.

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

Figur 6:  Metadataydeevne – Små filer (4K)

Systemet får meget gode resultater for stat- og fjernelseshandlinger, der når deres spidsværdi ved 256 tråde med henholdsvis 8,2 M op/s og 400K op/s. Læsehandlinger, der har nået maks. 44,8K op/s og skaber handlinger, der når deres maksimale med 68,1K op/s, begge ved 512 tråde. Opbevarings- og fjernelseshandlinger har større varians, men når de når deres maksimale værdi, falder ydeevnen ikke til under 3 M op/s for statistik og 280K op/s for fjernelse. Oprettelse og læsning har mindre varians og bliver ved med at stige i takt med, at antallet af tråde vokser. Som det kan observeres, leverer de ekstra drev til kapacitetsudvidelserne kun de økonomiske ændringer i metadataydeevnen.
Da disse tal er for et metadatamodul med en enkelt ME4024, øges ydeevnen for hvert yderligere ME4024-system, men vi kan ikke blot antage en lineær stigning for hver handling. Medmindre hele filen passer ind i inode for en sådan fil, bruges datadestinationer på ME4084s til at gemme 4K-filerne og begrænse ydeevnen til en vis grad. Da inode-størrelsen er 4 KiB, og den stadig skal gemme metadata, er det kun filer omkring 3 KiB, der passer inden i, og alle filer, der er større end dem, bruger datadestinationer.
 

---

Konklusioner og fremtidigt arbejde

Løsningen med udvidet kapacitet var i stand til at forbedre ydeevnen, ikke kun for tilfældige adgange, men endda for sekventiel ydeevne. Det var forventet, da den spredte tilstand opfører sig som randomiserede adgange, og hvis der er flere diske, er det muligt at forbedre den. Denne ydeevne, som kan ses på tabel 4, forventes at være stabil fra et tomt filsystem, indtil det er næsten fuldt. Desuden kan løsningen skaleres i kapacitet og ydeevne lineært, efterhånden som flere storage nodes-moduler tilføjes, og der kan forventes en lignende forøgelse af ydeevnen fra det valgfrie metadatamodul med høj efterspørgsel. Denne løsning giver HPC-kunder et meget pålideligt parallelt filsystem, der anvendes af mange Top 500 HPC-klynger. Derudover giver det fremragende søgefunktioner, avanceret overvågning og administration og tilføjelse af valgfrie gateways giver mulighed for fildeling via allestedsværende standardprotokoller som NFS, SMB og andre til så mange klienter, som det er nødvendigt.

Tabel 4  Optimal og vedvarende ydeevne

	Optimal ydeevne		Vedvarende ydeevne
	Skrive	Læse	Skrive	Læse
Store sekventielle N-klienter til N-filer	20,4 GB/s	24,2 GB/s	20,3 GB/s	24 GB/s
Store sekventielle N-klienter til enkelt delt fil	19,3 GB/s	24,8 GB/s	19,3 GB/s	23,8 GB/s
Tilfældige små blokke N-klienter til N-filer	40KIOps	25,6KIOps	40.0KIOps	19.3KIOps
Metadata Opret tomme filer	169,4K IOps		123,5K IOps
Metadata Stat empty files (Tomme filer for metadata)	11 måneders IOps		3,2 M IOps
Metadata Læs tomme filer	4,7 M IOps		2,4 M IOps
Metadata Fjern tomme filer	170,6K IOps		156,5K IOps
Metadata Opret 4 KiB-filer	68.1K IOps		68.1K IOps
Metadata-stat 4 KiB-filer	8,2 M IOps		3 måneders IOps
Metadata læs 4KiB filer	44,8K IOps		44,8K IOps
Metadata Fjern 4 KiB-filer	400K IOps		280K IOps

Da løsningen er beregnet til at blive frigivet med Cascade Lake CPU'er og hurtigere RAM, vil der blive udført nogle kontrol af ydeevnen, når systemet har den endelige konfiguration. Og test det valgfri High Demand Metadata-modul med mindst 2x ME4024s og 4KiB filer er påkrævet for bedre at dokumentere, hvordan metadataydeevnen skaleres, når datadestinationer er involveret. Derudover bliver ydeevnen for gateway-noderne målt og rapporteret sammen med relevante resultater fra stedets kontroller i en ny blog eller en hvidbog. Endelig er flere løsningskomponenter planlagt til at blive testet og frigivet for at give endnu flere muligheder.