Dell EMC Ready-løsning for HPC PixStor-lagring – kapasitetsutvidelse

None

Innholdsfortegnelse

1. Innledning
   1. Løsningsarkitektur
   2. Løsningskomponenter
2. Ytelsestegning
   1. Sekvensielle IOzone Performance N-klienter til N-filer
   2. Sekvensiell IOR Performance N-klienter til 1 fil
   3. Tilfeldige små blokker IOzone Performance N-klienter til N-filer
   4. Metadataytelse med MDtest ved hjelp av tomme filer
   5. Metadataytelse med MDtest ved hjelp av fire KiB-filer
3. Konklusjoner og fremtidig arbeid

 

---

Innledning

Dagens HPC-miljøer har økt etterspørselen etter svært høyhastighets lagring som også ofte krever høy kapasitet og distribuert tilgang via flere standardprotokoller som NFS, SMB og andre. HPC-kravene med høy etterspørsel dekkes vanligvis av parallelle filsystemer som gir samtidig tilgang til én enkelt fil eller et sett med filer fra flere noder, og som på en svært effektiv måte distribuerer data til flere LUN-er på tvers av flere servere.

 

---

Løsningsarkitektur

Denne bloggen er en fortsettelsesløsning for HPC-miljøer (Parallel File System) for HPC-miljøer, DellEMC Ready Solution for HPC PixStor Storage, der PowerVault ME484 EBOD-arrayer brukes til å øke kapasiteten til løsningen. Figur 1 viser referansearkitekturen som viser SAS-tilleggene for kapasitetsutvidelse til eksisterende PowerVault ME4084-lagringsarrayer.
PixStor-løsningen inkluderer det omfattende generelle parallelle filsystemet, også kjent som Spectrum Scale som PFS-komponenten, i tillegg til mange andre Arcastream-programvarekomponenter, for eksempel avansert analyse, forenklet administrasjon og overvåking, effektiv filsøk, avanserte gateway-funksjoner og mange andre.


Figur 1: Referansearkitektur.

 

---

Løsningskomponenter

Denne løsningen er planlagt lansert med de nyeste skalerbare Intel Xeon 2. generasjons Skalerbare Xeon-prosessorer, f.eks. Cascade Lake-prosessorer, og noen av serverne vil bruke den raskeste RAM-en som er tilgjengelig for dem (2933 MT/s). Men på grunn av gjeldende maskinvare som er tilgjengelig for å jobbe med løsningens prototype for å kjennetegne ytelsen, må servere med Skalerbare Xeon Xeon-prosessorer fra første generasjon, også kjent som Intel Xeon-prosessorer, f.eks. Skylake prosessorer og i noen tilfeller tregere RAM ble brukt til å kjennetegne dette systemet. Siden flaskehalsen til løsningen ligger i SAS-kontrollerne i DellEMC PowerVault ME40x4-matrisene, forventes det ingen betydelig ytelse før Skylake CPU-ene og RAM erstattes med de forekommede Cascade Lake-CPU-ene og raskere RAM. I tillegg ble løsningen oppdatert til den nyeste versjonen av PixStor (5.1.1.4) som støtter RHEL 7.7 og OFED 4.7 for å kjennetegne systemet.

På grunn av den tidligere beskrevne situasjonen har tabell 1 listen over hovedkomponenter for løsningen, men når avvik ble innført, har den første beskrivelseskolonnen komponenter som ble brukt på utgivelsestidspunktet, og den siste kolonnen er komponentene som faktisk brukes til å kjennetegne ytelsen til løsningen. Diskene som er oppført for data (12 TB NLS) og metadata (960 Gb SSD), er de som brukes til ytelsestegning, og raskere stasjoner kan gi bedre tilfeldige IP-er og kan forbedre metadataoperasjoner for oppretting/fjerning.

Til slutt, for fullstendighet, ble listen over mulige data-HDD-er og metadata-SSD-er inkludert, som er basert på diskene som støttes som nummerert på DellEMC PowerVault ME4-støttematrisen, tilgjengelig på Internett.

Tabell 1 Komponenter som brukes på utgivelsestidspunkt og de som brukes i testmiljøet

Løsningskomponent		Ved utgivelse	Testmiljø
Intern tilkoblingsmulighet		Dell Networking S3048-ON Gigabit Ethernet
Undersystem for datalagring		1 x til 4 x Dell EMC PowerVault ME4084 1 x til 4 x Dell EMC PowerVault ME484 (én per ME4084) 80–12 TB 3,5" NL SAS3 HDD-disker alternativer for 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-er, lineær 8 + 2 RAID 6, delstørrelse 512KiB. 4 x 1,92 TB SAS3 SSD-disker for metadata – 2 x RAID 1 (eller 4 – globale hdd-reservedisker, hvis metadatamodulen med høy etterspørsel (ekstrautstyr) brukes)
Valgfritt undersystem for lagring med høy etterspørsel		1 x til 2 x Dell EMC PowerVault ME4024 (4 x ME4024 om nødvendig, kun stor konfigurasjon) 24 x 960 GB 2,5" SSD SAS3-disker (alternativer 480 GB, 960 GB, 1,92 TB) 12 LUN-er, lineær RAID 1.
RAID-lagringskontrollere		12 Gbps SAS
Kapasitet som konfigurert		Rå: 8064 TB (7334 TiB eller 7,16 PiB) formatert ~ 6144 GB (5588 TiB eller 5,46 PiB)
Prosessor	Gateway	2 x Intel Xeon Gold 6230 2,1 GB, 20 °C/40 T, 10,4 GT/s, 27,5 M hurtigbuffer, turbo, HT (125 W) DDR4-2933	Ikke relevant
	Metadata med høy etterspørsel		2 x Intel Xeon Gold 6136 ved 3,0 GHz, 12 kjerner
	Lagringsnode		2 x Intel Xeon Gold 6136 ved 3,0 GHz, 12 kjerner
	Administrasjonsnode	2 x Intel Xeon Gold 5220 2.2G, 18C/36T, 10,4 GT/s, 24,75 M hurtigbuffer, turbo, HT (125 W) DDR4-2666	2 x Intel Xeon Gold 5118 ved 2,30 GHz, 12 kjerner
Minne	Gateway	12 x 16 GiB 2933 MT/s RDIMM-er (192 GiB)	Ikke relevant
	Metadata med høy etterspørsel		24 x 16 GiB 2666 MT/s RDIMM-er (384 GiB)
	Lagringsnode		24 x 16 GiB 2666 MT/s RDIMM-er (384 GiB)
	Administrasjonsnode	12 x 16 GB DIMM-er, 2666 MT/s (192 GiB)	12 x 8 GiB 2666 MT/s RDIMM-er (96 GiB)
Operativsystem		Red Hat Enterprise Linux 7.6	Red Hat Enterprise Linux 7.7
Kjerneversjon		3.10.0-957.12.2.el7.x86_64	3.10.0-1062.9.1.el7.x86_64
PixStor-programvare		5.1.0.0	5.1.1.4
Spectrum Scale (GPFS)		5.0.3	5.0.4-2
Nettverkstilkobling med høy ytelse		Mellanox ConnectX-5 Dual-Port InfiniBand EDR/100 GbE og 10 GbE	Mellanox ConnectX-5 InfiniBand EDR
Svitsj med høy ytelse		2 x Mellanox SB7800 (HA – redundant)	1 x Mellanox SB7700
OFED Version (BIOS-versjon)		Mellanox OFED-4.6-1.0.1.0	Mellanox OFED-4.7-3.2.9
Lokale disker (OS &analyse/overvåking)		Alle servere unntatt administrasjonsnode 3 x 480 GB SSD SAS3 (RAID1 + HS) for operativsystem PERC H730P RAID-kontroller Administrasjonsnode 3 x 480 GB SSD SAS3 (RAID1 + HS) for operativsystem PERC H740P RAID-kontroller	Alle servere unntatt administrasjonsnode 2 x 300 GB 15K SAS3 (RAID 1) for operativsystem PERC H330 RAID-kontroller Administrasjonsnode 5 x 300 GB 15K SAS3 (RAID 5) for operativsystem og analyse/overvåking PERC H740P RAID-kontroller
Systemadministrasjon		iDRAC 9 Enterprise + DellEMC OpenManage	iDRAC 9 Enterprise + DellEMC OpenManage

 

---

Ytelsestegning

For å betegne denne nye Ready Solution brukte vi maskinvaren som er angitt i den siste kolonnen i tabell 1, inkludert valgfri metadatamodul for høy etterspørsel. For å vurdere løsningsytelsen ble følgende ytelsestestinger brukt:

• IOzone N til N sekvensiell
• IOR N til 1 sekvensiell
• Tilfeldig IOzone
• MDtest

 For alle ytelsesprøvene som er oppført ovenfor, hadde testmiljøet klientene som beskrevet i tabell 2 nedenfor. Siden antallet databehandlingsnoder som var tilgjengelige for testing, bare var 16, når et høyere antall tråder var nødvendig, disse trådene ble like distribuert på databehandlingsnodene (dvs. 32 tråder = to tråder per node, 64 tråder = fire tråder per node, 128 tråder = 8 tråder per node, 256 tråder = 16 tråder per node, 512 tråder = 32 tråder per node, 1024 tråder = 64 tråder per node). Hensikten var å simulere et høyere antall samtidige klienter med begrenset antall databehandlingsnoder. Siden ytelsesprøvene støtter et høyt antall tråder, ble det brukt en maksimal verdi på opptil 1024 (spesifisert for hver test), samtidig som man unngår overdreven kontekstsvitsjing og andre relaterte bivirkninger som påvirker ytelsesresultatene.

Tabell 2 Klienttestingsmiljø

Antall klientnoder	16
Klientnode	C6320
Prosessorer per klientnode	2 x Intel(R) Xeon (R) Gold E5-2697v4 18 kjerner ved 2,30 GHz
Minne per klientnode	12 x 16 GiB 2400 MT/s RDIMM-er
BIOS	2.8.0
OS Kernel	3.10.0-957.10.1
GPFS-versjon	5.0.3

 

---

Sekvensielle IOzone Performance N-klienter til N-filer

Sekvensielle N-klienter til N-filytelse ble målt med IOzone versjon 3.487. Utførte tester varierte fra én tråd opptil 1024 tråder, og resultatene av den kapasitetsutvidede løsningen (4x ME4084s + 4x ME484s) står i kontrast til løsningen med stor størrelse (4x ME4084s). Hurtigbufringseffektene ble minimert ved å angi GPFS-sideutvalget som kan justeres til 16 GiB, og bruke filer som er større enn to ganger så store. Det er viktig å legge merke til at for GPFS som kan justeres, angir den maksimale mengden minne som brukes til hurtigbufringsdata, uavhengig av hvor mye RAM som er installert og ledig. Det er også viktig å legge merke til at i tidligere DellEMC HPC-løsninger er blokkstørrelsen for store sekvensielle overføringer 1 MiB, GPFS ble formatert med 8 MiB-blokker, og derfor brukes denne verdien på ytelsestesten for optimal ytelse. Det kan se for stort ut og tilsynelatende kaste bort for mye plass, men GPFS bruker allokering av underblokkering for å forhindre denne situasjonen. I den gjeldende konfigurasjonen ble hver blokk delt inn i 256 underblokker på 32 KiB hver.

Følgende kommandoer ble brukt til å utføre ytelsestesten for skriving og lesing, der threads var variabelen med antall tråder som ble brukt (1 til 1024 økt i to krefter), og threadlist var filen som tilordnet hver tråd på en annen node, og brukte ringdistribusjon til å spre dem homogent på tvers av 16 databehandlingsnoder.

./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 sekvensiell ytelse


Fra resultatene kan vi se at ytelsen stiger svært raskt med antall klienter som brukes, og deretter når et platå som er stabilt til det maksimale antallet tråder som IOzone tillater er nådd, og derfor er stor filsekvensytelse stabil selv for 1024 samtidige klienter. Vær oppmerksom på at både lese- og skriveytelsen hadde en dobling av antall stasjoner. Den maksimale leseytelsen var begrenset av båndbredden til de to IB EDR-koblingene som ble brukt på lagringsnodene fra åtte tråder, og ME4-matriser kan ha litt ekstra ytelse tilgjengelig. På samme måte merker du at den maksimale skriveytelsen økte fra maksimalt 16,7 til 20,4 GB/s ved 64 og 128 tråder, og at den er nærmere maksimalt antall ME4-arrayer (22 GB/s).

Her er det viktig å huske at foretrukket GPFS-driftsmodus er spredt, og løsningen ble formatert til å bruke denne modusen. I denne modusen tilordnes blokker helt fra begynnelsen av operasjonen på en pseudo tilfeldig måte, og sprer data over hele overflaten av hver HDD. Selv om den åpenbare ulempen er en mindre innledende maksimal ytelse, opprettholdes ytelsen ganske konstant uansett hvor mye plass som brukes på filsystemet. I motsetning til andre parallelle filsystemer som i utgangspunktet bruker de ytre sporene som kan inneholde mer data (sektorer) per disk revolusjon, og som derfor har høyest mulig ytelse, kan HDD-ene gi, men ettersom systemet bruker mer plass, brukes indre spor med mindre data per revolusjon, med den påfølgende reduksjonen av ytelsen.

 

---

Sekvensiell IOR Performance N-klienter til 1 fil

Sekvensielle N-klienter til én enkelt delt filytelse ble målt med IOR-versjon 3.3.0, assistert av OpenMPI v4.0.1 for å kjøre ytelsestesten over 16 databehandlingsnoder. Utførte tester varierte fra én tråd opptil 512 tråder (siden det ikke var nok kjerner for 1024 tråder), og resultatene står i kontrast til løsningen uten kapasitetsutvidelse.
Hurtigbufringseffektene ble minimert ved å angi GPFS-sideutvalget som kan justeres til 16 GiB, og bruke filer som er større enn to ganger så store. Disse ytelsestestene brukte 8 MiB-blokker for optimal ytelse. Delen om tidligere ytelsestest har en mer fullstendig forklaring på disse sakene.

Følgende kommandoer ble brukt til å utføre ytelsestesten for skriving og lesing, der tråder var variabelen med antall tråder som ble brukt (1 til 1024 økt i to krefter), og my_hosts.$Threads er den tilsvarende filen som tilordnet hver tråd på en annen node, og brukte ringdistribusjon til å spre dem homogent på tvers av 16-databehandlingsnodene.

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

Figur 3: N-til-1 sekvensiell ytelse

Fra resultatene kan vi på nytt observere at de ekstra diskene drar nytte av lese- og skriveytelsen. Ytelsen stiger igjen svært raskt med antall klienter som brukes, og når deretter et platå som er ganske stabilt for lesing og skriving helt til det maksimale antallet tråder som brukes på denne testen. Legg merke til at den maksimale leseytelsen var 24,8 GB/s ved 16 tråder, og flaskehalsen var InfiniBand EDR-grensesnittet, med ME4-matriser som fortsatt hadde litt ekstra ytelse tilgjengelig. Fra dette tidspunktet reduserte leseytelsen fra denne verdien til den nådde platået på rundt 23,8 GB/s. På samme måte merker du at den maksimale skriveytelsen på 19,3 ble nådd i åtte tråder og når et platå.
 

---

Tilfeldige små blokker IOzone Performance N-klienter til N-filer

Tilfeldige N-klienter til N-filer ble målt med FIO versjon 3.7 i stedet for den tradisjonelle Iozone. Hensikten, som oppført i forrige blogg, var å dra nytte av en større kødybde for å undersøke maksimal mulig ytelse som ME4084-matriser kan levere (tidligere tester for forskjellige ME4-løsninger viste at ME4084-arrayene trenger mer IO-press som Iozone kan levere for å nå sine tilfeldige IO-grenser).

Utførte tester varierte fra én tråd opptil 512 tråder siden det ikke var nok klientkjerner for 1024 tråder. Hver tråd brukte en annen fil, og trådene ble tilordnet ringdistribusjon på klientnodene. Disse ytelsestestene brukte 4 KiB-blokker for å emulere trafikk med små blokker og bruke en kødybde på 16. Resultater fra løsningen med stor størrelse og kapasitetsutvidelsen sammenlignes.

Hurtigbufringseffektene ble igjen minimert ved å angi GPFS-sideutvalget som er justerbart til 16 GiB og bruke filer to ganger så store. Den første ytelsestesten har en mer fullstendig forklaring på hvorfor dette er effektivt på GPFS.

 
Figur 4:  N til N Tilfeldig ytelse

Fra resultatene kan vi se at skriveytelsen starter på en høy verdi på 29,1K IOps og stiger jevnt opp til 64 tråder der det ser ut til å nå et platå på rundt 40 000 IOps. Leseytelsen på den annen side starter på 1,4K IOps og øker ytelsen nesten lineært med antall klienter som brukes (husk at antall tråder dobles for hvert datapunkt) og når den maksimale ytelsen på 25,6K IOPS ved 64 tråder der det ser ut til å være nær et platå. Bruk av flere tråder vil kreve mer enn de 16 databehandlingsnodene for å unngå ressurssult og lavere tilsynelatende ytelse, der matrisene faktisk kunne opprettholde ytelsen.

 

---

Metadataytelse med MDtest ved hjelp av tomme filer

Metadataytelsen ble målt med MDtest versjon 3.3.0, assistert av OpenMPI v4.0.1 for å kjøre ytelsestesten over 16 databehandlingsnoder. Utførte tester varierte fra én tråd opptil 512 tråder. Ytelsestesten ble bare brukt for filer (ingen katalogmetadata), hvor du fikk antall opprettere, statistikk, lesing og fjerning som løsningen kan håndtere, og resultatene står i kontrast til løsningen med stor størrelse.

For å evaluere løsningen på riktig måte sammenlignet med andre DellEMC HPC-lagringsløsninger og tidligere bloggresultater ble valgfri metadatamodul for høy etterspørsel brukt, men med én enkelt ME4024-matrise, selv om den store konfigurasjonen og testet i dette arbeidet ble utpekt til å ha to ME4024-er. Denne metadatamodulen med høy etterspørsel kan støtte opptil fire ME4024-matriser, og det anbefales å øke antallet ME4024-matriser til 4 før du legger til en annen metadatamodul. Ytterligere ME4024-matriser forventes å øke metadataytelsen lineært med hver ekstra matrise, bortsett fra kanskje for stat-operasjoner (og leser for tomme filer), siden tallene er svært høye, på et tidspunkt vil CPU-ene bli et flaskehals, og ytelsen vil ikke fortsette å øke lineært.

Følgende kommando ble brukt til å utføre ytelsestestingstesten der tråder var variabelen med antall tråder som ble brukt (1 til 512 økt i to krefter), og my_hosts.$Threads er den tilsvarende filen som tilordnet hver tråd på en annen node, og brukte ringdistribusjon til å spre dem homogent på tvers av 16 databehandlingsnoder. I likhet med den tilfeldige IO-ytelsestesten var det maksimale antallet tråder begrenset til 512, siden det ikke er nok kjerner for 1024 tråder, og kontekstsvitsjing vil påvirke resultatene, og rapporterer et tall som er lavere enn den virkelige ytelsen til løsningen.

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

Siden ytelsesresultatene kan påvirkes av det totale antallet IOP-er, antall filer per katalog og antall tråder, ble det bestemt å beholde løst det totale antallet filer til 2 MiB-filer (2^21 = 2097152), antall filer per katalog fast på 1024, og antall kataloger varierte ettersom antall tråder endret som vist i tabell 3.

Tabell 3:  MDtest distribusjon av filer på kataloger

Antall tråder	Antall kataloger per tråd	Totalt antall 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: Metadataytelse – tomme filer

Legg først merke til at den valgte skalaen var logaritmisk med base 10, for å tillate sammenligning av operasjoner som har forskjeller på flere ordrer avlemminger; Ellers vil noen av operasjonene se ut som en flat linje nær 0 på et vanlig diagram. Et loggdiagram med base 2 kan være mer hensiktsmessig, siden antallet tråder økes i strøm til 2, men grafen vil se svært lik ut, og folk har en tendens til å håndtere og huske bedre tall basert på strøm til 10.
Systemet får svært gode resultater med stat- og leseoperasjoner som når sin maksimale verdi på henholdsvis 64 tråder med henholdsvis nesten 11 M op/s og 4,7 M op/s. Fjerningsoperasjoner oppnår maksimalt 170,6K operasjoner ved 16 tråder, og Opprett operasjoner oppnår topp på 32 tråder med 222,1K op/s. Driftsoperasjoner for statistikk og lesing har større variabilitet, men når de når toppverdien, faller ikke ytelsen under 3 M operasjoner for statistikk og 2 M operasjoner for lesing. Oppretting og fjerning er mer stabilt når de når et plateau og holder seg over 140 000 o/s for fjerning og 120 000 operasjoner for oppretting. Legg merke til at de ekstra diskene ikke påvirker mye av de fleste metadataoperasjoner på tomme filer som forventet.
 

---

Metadataytelse med MDtest ved hjelp av fire KiB-filer

Denne testen er nesten identisk med den forrige, bortsett fra at små filer på 4KiB ble brukt i stedet for tomme filer. 
Følgende kommando ble brukt til å utføre ytelsestestingstesten der tråder var variabelen med antall tråder som ble brukt (1 til 512 økt i to krefter), og my_hosts.$Threads er den tilsvarende filen som tilordnet hver tråd på en annen node, og brukte ringdistribusjon til å spre dem homogent på tvers av 16 databehandlingsnoder.

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:  Metadataytelse – små filer (4K)

Systemet får svært gode resultater for operasjoner for statistikk og fjerning som når toppverdien på henholdsvis 256 tråder med henholdsvis 8,2 M op/s og 400 000 operasjoner. Leseoperasjoner oppnår maksimalt 44,8K op/s, og oppretting av operasjoner oppnår topp med 68,1K op/s, begge ved 512 tråder. Driftsoperasjoner for statistikk og fjerning har større variabilitet, men når de når toppverdien, faller ikke ytelsen under 3 M op/s for statistikk og 280 000 operasjoner for fjerning. Oppretting og lesing har mindre variasjon og fortsetter å øke etter hvert som antall tråder vokser. Som det kan observeres, gir de ekstra stasjonene i kapasitetsutvidelsene bare store endringer i metadataytelsen.
Siden disse tallene gjelder for en metadatamodul med én enkelt ME4024, vil ytelsen øke for hver ekstra ME4024-matrise, men vi kan ikke bare anta en lineær økning for hver operasjon. Med mindre hele filen passer i inoden for en slik fil, brukes datamålene på ME4084 til å lagre 4K-filene, noe som begrenser ytelsen til en viss grad. Siden inodestørrelsen er 4KiB og den fortsatt trenger å lagre metadata, vil bare filer rundt 3 KiB passe inn og alle filer som er større enn den, vil bruke datamål.
 

---

Konklusjoner og fremtidig arbeid

Løsningen med utvidet kapasitet var i stand til å forbedre ytelsen, ikke bare for tilfeldige tilganger, men også for sekvensiell ytelse. Det var forventet siden den spredte modusen oppfører seg som randomiserte tilganger, og det å ha flere disker gjør det mulig å forbedre den. Denne ytelsen, som kan oversikts over tabell 4, forventes å være stabil fra et tomt filsystem til den nesten er full. Løsningen skaleres i tillegg i kapasitet og ytelse lineært etter hvert som flere moduler for lagringsnoder legges til, og en lignende ytelsesøkning kan forventes fra metadatamodulen med høy etterspørsel ( tilleggsutstyr). Denne løsningen gir HPC-kunder et svært pålitelig parallellfilsystem som brukes av mange topp 500 HPC-klynger. I tillegg gir den eksepsjonelle søkefunksjoner, avansert overvåking og administrasjon, og tillegging av valgfrie gatewayer muliggjør fildeling via forestående standardprotokoller som NFS, SMB og andre, til så mange klienter som nødvendig.

Tabell 4  Topp og vedvarende ytelse

	Topp ytelse		Vedvarende ytelse
	Skrive	Lese	Skrive	Lese
Store sekvensielle N-klienter til N-filer	20,4 GB/s	24,2 GB/s	20,3 GB/s	24 GB/s
Store sekvensielle N-klienter til én delt fil	19,3 GB/s	24,8 GB/s	19,3 GB/s	23,8 GB/s
Tilfeldige små blokker N-klienter til N-filer	40KIOps	25,6KIOps	40,0 KIOps	19,3KIOps
Opprette tomme filer for metadata	169,4K IOps		123,5K IOps
Tomme metadatastatistikkfiler	11 M IOps		3,2 M IOps
Tomme filer for metadatalesing	4,7 M IOps		2,4 M IOps
Fjerne tomme filer for metadata	170,6K IOps		156,5K IOps
Opprette 4KiB-filer for metadata	68,1K IOps		68,1K IOps
MetadataStat 4KiB-filer	8,2 M IOps		3 M IOps
4KiB-filer for metadatalesing	44,8K IOps		44,8K IOps
Fjerne 4KiB-filer for metadata	400 000 000 IOps		280 000 000 IOps

Siden løsningen er ment å bli lansert med Cascade Lake-CPU-er og raskere RAM, vil det bli utført enkelte ytelsesspørringskontroller når systemet har den endelige konfigurasjonen. Test metadatamodulen med høy etterspørsel (ekstrautstyr) med minst 2 ME4024- og 4KiB-filer for å dokumentere hvordan metadataytelsen skaleres når datamålene er involvert. I tillegg vil ytelsen for gateway-nodene bli målt og rapportert sammen med relevante resultater fra spotsjekkene i en ny blogg eller en rapport. Til slutt er det planlagt at flere løsningskomponenter testes og lanseres for å gi enda flere muligheter.