For alle benchmarks, der er anført ovenfor, havde testbænken klienterne som beskrevet i tabel 2 nedenfor. Da antallet af beregningsnoder, der var tilgængelige til test, kun var 16, når der krævedes et større antal tråde, var 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 større antal samtidige klienter med det begrænsede antal tilgængelige beregningsnoder. Da nogle benchmarks understøtter et stort antal tråde, blev der anvendt en maksimal værdi på op til 1024 (specificeret for hver test), samtidig med at overdreven kontekstskift og andre relaterede bivirkninger blev undgået i at påvirke ydeevneresultaterne.

Tabel 2 Klienttestbænk

Sekventielle IOzone Performance N-klienter til N-filer

Sekventiel N-klient til N-filydeevne blev målt med IOzone version 3.487. De udførte tests varierede fra enkelt gevind op til 1024 tråde i trin af kræfter på to.

Cacheeffekter på serverne blev minimeret ved at indstille GPFS-sidepuljen justerbar til 16 GiB og bruge filer, der er større end to gange så store. Det er vigtigt at bemærke, at for GPFS indstiller tunable den maksimale mængde hukommelse, der bruges til caching af data, uanset mængden af RAM installeret og ledig. Det er også vigtigt at bemærke, at mens blokstørrelsen for store sekventielle overførsler i tidligere DellEMC HPC-løsninger 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 spilde for meget plads, men GPFS bruger underblokallokering for at forhindre denne situation. I den nuværende konfiguration blev hver blok opdelt i 256 underblokke på 32 KiB hver.

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

For at undgå mulige datacacheeffekter fra klienterne var filernes samlede datastørrelse dobbelt så stor som den samlede mængde RAM i de anvendte klienter. Det vil sige, da hver klient har 128 GiB RAM, for trådtællinger lig med eller over 16 tråde var filstørrelsen 4096 GiB divideret med antallet af tråde (variablen $Size nedenfor blev brugt til at administrere denne værdi). I de tilfælde med mindre end 16 tråde (hvilket indebærer, at hver tråd kørte på en anden klient), blev filstørrelsen fastsat til dobbelt så meget hukommelse pr. klient eller 256 GiB.

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

Figur 2 N til N sekventiel ydeevne

Fra resultaterne kan vi observere, at skriveydelsen stiger med antallet af anvendte tråde og derefter når et plateau på omkring 64 tråde for skrivninger og 128 tråde for læsninger. Derefter stiger læseydelsen også hurtigt med antallet af tråde og forbliver derefter stabil, indtil det maksimale antal tråde, som IOzone tillader, nås, og derfor er stor filsekventiel ydeevne stabil, selv for 1024 samtidige klienter. Skriveydelsen falder ca. 10 % ved 1024 tråde. Da klientklyngen har mindre end dette antal kerner, er det imidlertid usikkert, om faldet i ydeevne skyldes swapping og lignende faste omkostninger, der ikke observeres i roterende medier (da NVMe-ventetiden er meget lav sammenlignet med roterende medier), eller om RAID 10-datasynkroniseringen er ved at blive en flaskehals. Der er behov for flere klienter for at afklare dette punkt. En anomali på læsningerne blev observeret ved 64 tråde, hvor ydeevnen ikke blev skaleret med den hastighed, der blev observeret for tidligere datapunkter, og derefter på det næste datapunkt bevæger sig til en værdi meget tæt på den vedvarende ydeevne. Mere test er nødvendig for at finde årsagen til en sådan anomali, men er uden for rammerne af denne blog.

Den maksimale læseydelse for læsninger var under den teoretiske ydeevne for NVMe-enhederne (~ 102 GB / s) eller ydeevnen for EDR-links, selv hvis det antages, at et link mest blev brugt til NVMe over strukturtrafik (4x EDR BW ~ 96 GB / s).
Dette er dog ikke en overraskelse, da hardwarekonfigurationen ikke er afbalanceret med hensyn til NVMe-enhederne og IB HCA'erne under hver CPU-stik. Den ene CX6-adapter er under CPU1, mens CPU2 har alle NVMe-enhederne og den anden CX6-adapter. Enhver storagetrafik, der bruger den første HCA, skal bruge UPI'erne til at få adgang til NVMe-enhederne. Derudover skal enhver kerne i CPU1, der bruges, få adgang til enheder eller hukommelse, der er tildelt CPU2, så datalokaliteten lider, og UPI-links bruges. Det kan forklare reduktionen for den maksimale ydeevne sammenlignet med NVMe-enhedernes maksimale ydeevne eller linjehastigheden for CX6 HCA'er. Alternativet til at rette op på denne begrænsning er at have en afbalanceret hardwarekonfiguration, hvilket indebærer at reducere densiteten til halvdelen ved at bruge en R740 med fire x16-slots og bruge to x16 PCIe-ekspandere til at fordele NVMe-enheder ligeligt på to CPU'er og have en CX6 HCA under hver CPU.

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 de 16 beregningsnoder. De udførte tests varierede fra en tråd, op til 512 tråde, da der ikke var nok kerner til 1024 eller flere tråde. Denne benchmarktest brugte 8 MiB-blokke for optimal ydeevne. Den tidligere præstationstestsektion har en mere komplet forklaring på, hvorfor det betyder noget.

Datacacheeffekter blev minimeret ved at indstille GPFS-sidepuljen justerbar til 16 GiB, og den samlede filstørrelse var dobbelt så stor som den samlede mængde RAM i de anvendte klienter. Det vil sige, da hver klient har 128 GiB RAM, for trådtællinger lig med eller over 16 tråde var filstørrelsen 4096 GiB, og en lige stor mængde af denne total blev divideret med antallet af tråde (variablen $Size nedenfor blev brugt til at administrere denne værdi). I de tilfælde med mindre end 16 tråde (hvilket indebærer, at hver tråd kørte på en anden klient), var filstørrelsen dobbelt så meget hukommelse pr. klient, der blev brugt gange antallet af tråde, eller med andre ord blev hver tråd bedt om at bruge 256 GiB.

Følgende kommandoer blev brugt til at udføre benchmarket for skrivninger og læsninger, hvor $Threads var variablen med antallet af anvendte tråde (1 til 1024 øget i beføjelser på to), og my_hosts.$Threads er den tilsvarende fil, der tildelte hver tråd på en anden node ved hjælp af round robin for 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 --præfiks /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 $ G

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --præfiks /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 $ G

Figur 3 N til 1 Sekventiel ydeevne

Fra resultaterne kan vi observere, at læse- og skriveydelsen er høj uanset det implicitte behov for låsemekanismer, da alle tråde har adgang til den samme fil. Ydeevnen stiger igen meget hurtigt med antallet af anvendte tråde og når derefter et plateau, der er relativt stabilt for læsninger og skrivninger hele vejen til det maksimale antal tråde, der bruges på denne test. Bemærk, at den maksimale læseydelse var 51,6 GB/s ved 512 tråde, men plateauet i ydeevne er nået til omkring 64 tråde. Bemærk ligeledes, at den maksimale skriveydelse på 34,5 GB/s blev opnået ved 16 tråde og nåede et plateau, der kan observeres indtil det maksimale antal anvendte tråde.

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

Ydeevnen for tilfældige N-klienter til N-filer blev målt med IOzone version 3.487. De udførte tests varierede fra enkelt gevind op til 1024 tråde i trin af kræfter på to.

De udførte tests varierede fra enkelttråde 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 efterligne små blokke trafik og bruge en kødybde på 16. Resultater fra den store størrelsesløsning og kapacitetsudvidelsen sammenlignes.

Cacheeffekter blev igen minimeret ved at indstille GPFS-sidepuljen justerbar til 16 GiB, og for at undgå mulige datacacheeffekter fra klienterne var filernes samlede datastørrelse dobbelt så stor som den samlede mængde RAM i de anvendte klienter. Det vil sige, da hver klient har 128 GiB RAM, for trådtællinger lig med eller over 16 tråde var filstørrelsen 4096 GiB divideret med antallet af tråde (variablen $Size nedenfor blev brugt til at administrere denne værdi). I de tilfælde med mindre end 16 tråde (hvilket indebærer, at hver tråd kørte på en anden klient), blev filstørrelsen fastsat til dobbelt så meget hukommelse pr. klient eller 256 GiB.

iozone -i0 -I -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./nvme_threadlist <= Opret filerne sekventielt
iozone -i2 -I -c -O -w -r 4k -s $ G -t $Threads -+n -+m ./nvme_threadlist <= Udfør de vilkårlige læsninger og skrivninger.

Figur 4 N til N tilfældig ydeevne

Fra resultaterne kan vi observere, at skriveydelsen starter med en høj værdi på 6K IOps og stiger støt op til 1024 tråde, hvor det ser ud til at nå et plateau med over 5M IOPS, hvis flere tråde kunne bruges. Læseydelse starter på den anden side ved 5K IOPS'er og øger ydeevnen støt med antallet af anvendte tråde (husk, at antallet af tråde fordobles for hvert datapunkt) og når den maksimale ydeevne på 7.3M IOPS ved 1024 tråde uden tegn på at nå et plateau. Brug af flere tråde vil kræve mere end de 16 beregningsnoder for at undgå ressourcesult og overdreven bytte, der kan sænke den tilsyneladende ydeevne, hvor NVMe-noderne faktisk kunne opretholde ydeevnen.

Metadataydeevne med MDtest ved hjælp af 4 KiB-filer

Metadataydeevnen blev målt med MDtest version 3.3.0, assisteret af OpenMPI v4.0.1 til at køre benchmarket over de 16 beregningsnoder. De udførte tests varierede fra enkelt gevind op til 512 tråde. Benchmarket blev kun brugt til filer (ingen katalogmetadata), der fik antallet af oprettelser, statistikker, læsninger og fjernelser, som løsningen kan håndtere, og resultaterne blev kontrasteret med løsningen i stor størrelse.

Det valgfri High Demand Metadata Module blev brugt, men med et enkelt ME4024-array, selv at den store konfiguration og testet i dette arbejde blev udpeget til at have to ME4024'er. Årsagen til at bruge dette metadatamodul er, at disse NVMe-noder i øjeblikket kun bruges som lagermål for data. Noderne kan dog bruges til at gemme data og metadata eller endda som et flash-alternativ til metadatamodulet med høj efterspørgsel, hvis ekstreme metadatakrav kræver det. Disse konfigurationer blev ikke testet som en del af dette arbejde.

Da det samme High Demand Metadata-modul er blevet brugt til tidligere benchmarking af DellEMC Ready Solution til HPC PixStor Storage-løsningen, vil metadataresultaterne være meget ens sammenlignet med tidligere blogresultater. Af den grund blev undersøgelsen med tomme filer ikke udført, og i stedet blev 4 KiB-filer brugt. Da 4KiB-filer ikke kan passe ind i en inode sammen med metadataoplysningerne, vil NVMe-noder blive brugt til at gemme data for hver fil. Derfor kan MDtest give en grov idé om små filers ydeevne til læsninger og resten af metadataoperationerne.

Følgende kommando blev brugt til at udføre benchmarket, hvor $Threads var variablen med antallet af anvendte tråde (1 til 512 øget i beføjelser på to), og my_hosts.$Threads er den tilsvarende fil , der tildelte hver tråd på en anden knude ved hjælp af round robin til at sprede dem homogent på tværs af de 16 beregningsnoder. I lighed med Random IO-benchmarket var 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 lavere end løsningens reelle ydeevne.

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --præfiks /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

Da ydeevneresultater kan påvirkes af det samlede antal IOPS, antallet af filer pr. mappe og antallet af tråde, blev det besluttet at holde det samlede antal filer fast til 2 MiB-filer (2^21 = 2097152), antallet af filer pr. mappe fastsat til 1024, og antallet af mapper varierede, da antallet af tråde ændrede sig som vist i tabel 3.

Tabel 3 MDtest distribution af filer på mapper

Figur 5 Metadata ydeevne - 4 KiB-filer

Bemærk først, at den valgte skala var logaritmisk med base 10 for at muliggøre sammenligning af operationer, der har forskelle med flere størrelsesordener; Ellers ville nogle af operationerne se ud som en flad linje tæt på 0 på lineær skala. En loggraf med base 2 kunne være mere passende, da antallet af tråde øges i potenser på 2, men grafen ville se meget ens ud, og folk har tendens til at håndtere og huske bedre tal baseret på kræfter på 10.

Systemet får meget gode resultater som tidligere rapporteret med Stat-operationer, der når topværdien ved 64 tråde med næsten 6.9M op / s og derefter reduceres for højere trådtællinger, der når et plateau. Oprettelseshandlinger når maksimum på 113K op/s ved 512 tråde, så det forventes at fortsætte med at stige, hvis der anvendes flere klientnoder (og kerner). Reads and Remove-operationer nåede deres maksimum ved 128 tråde og opnåede deres højdepunkt ved næsten 705K op/s for Reads og 370K op/s for fjernelser, og derefter når de plateauer. Stat-operationer har større variabilitet, men når de når deres højeste værdi, falder ydeevnen ikke til under 3.2M op / s for statistik. Opret og fjernelse er mere stabile, når de når et plateau og forbliver over 265K op/s for fjernelse og 113K op/s for oprettelse. Endelig når læsninger et plateau med ydeevne over 265K op / s.

Konklusioner og fremtidigt arbejde

NVMe-noderne er en vigtig tilføjelse til HPC-storageløsningen, da de giver et meget højtydende niveau med god tæthed, meget høj ydeevne for vilkårlig adgang og meget høj sekventiel ydeevne. Desuden skaleres løsningen lineært ud i kapacitet og ydeevne, efterhånden som flere NVMe-nodemoduler tilføjes. Ydeevnen fra NVMe-noderne kan ses i tabel 4, forventes at være stabil, og disse værdier kan bruges til at estimere ydeevnen for et andet antal NVMe-noder.
Husk dog, at hvert par NVMe-noder giver halvdelen af ethvert tal, der vises i tabel 4.
Denne løsning giver HPC-kunder et meget pålideligt parallelt filsystem, der bruges af mange Top 500 HPC-klynger. Derudover giver den enestående søgefunktioner, avanceret overvågning og styring og tilføjelse af valgfrie gateways tillader fildeling via allestedsnærværende standardprotokoller som NFS, SMB og andre til så mange klienter som nødvendigt.

Tabel 4 Maksimal og vedvarende ydeevne for 2 par NVMe-noder

Da NVMe-noder kun blev brugt til data, kan muligt fremtidigt arbejde omfatte brug af dem til data og metadata og have et selvstændigt flashbaseret niveau med bedre metadataydeevne på grund af den højere båndbredde og lavere ventetid for NVMe-enheder sammenlignet med SAS3 SSD'er bag RAID-controllere. Hvis en kunde har ekstremt høje metadatakrav og har brug for en løsning, der er mere kompakt end det, som det krævende metadatamodul kan levere, kan nogle eller alle de distribuerede RAID 10-enheder bruges til metadata på samme måde, som RAID 1-enheder på ME4024s bruges nu.
En anden blog, der snart frigives, vil karakterisere PixStor Gateway-noderne, som gør det muligt at forbinde PixStor-løsningen til andre netværk ved hjælp af NFS- eller SMB-protokoller og kan skalere ydeevnen ud. Løsningen vil også blive opdateret til HDR100 meget snart, og en anden blog forventes at tale om det arbejde.