Dell EMC Ready Solution til HPC PixStor-lagring

Artikel skrevet af Mario Gallegos fra HPC og AI Innovation Lab i oktober 2019

Indholdsfortegnelse

1. Indledning
   1. Løsningsarkitektur
   2. Løsningskomponenter
2. Karakterisering af ydeevne
   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 ved hjælp af 4 KiB-filer
   6. Metadataydeevne ved hjælp af MDtest med 3K-filer
3. Avanceret analyse
4. Konklusioner og fremtidigt arbejde

Indledning

Løsningsarkitektur

Løsningskomponenter

Karakterisering af ydeevne

•     IOzone N til N sekventiel
•     IOR N til 1 sekventiel
•     IOzone tilfældig
•     MDtest
  
  For alle benchmarks, der er anført ovenfor, havde testsengen klienterne som beskrevet i tabel 2 nedenfor. Da antallet af beregningsnoder, der var tilgængelige til test, var 16, når der kræves 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 beregningsnoder. Da 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

  Antal klientnoder	16
  Klientnode	C6320
  Processorer pr. klientnode	2 x Intel(R) Xeon(R) Gold E5-2697V4, 18 kerner @ 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

  Sekventiel N-klient til N-filydeevne blev målt med IOzone version 3.487. De udførte tests varierede fra en enkelt tråd op til 1024 tråde. 
  Cacheeffekter 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 Dell EMC 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 tråde var variablen med antallet af anvendte tråde (1 til 1024 ø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.

  ./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
  
  
  Fra resultaterne kan vi observere, at ydeevnen stiger meget hurtigt med antallet af anvendte klienter og derefter når et plateau, der er stabilt, indtil det maksimale antal tråde, som IOzone tillader, nås, og derfor er stor filsekventiel ydeevne stabil selv for 1024 samtidige klienter. Bemærk, at den maksimale læseydelse var 23 GB/s ved 32 tråde, og at flaskehalsen sandsynligvis var InfiniBand EDR-grænsefladen, mens ME4-systemer stadig havde lidt ekstra ydeevne til rådighed. Bemærk ligeledes, at den maksimale skriveydelse på 16,7 blev nået lidt tidligt ved 16 tråde, og den er tilsyneladende lav sammenlignet med ME4-arraysspecifikationerne.
  Her er det vigtigt at huske, at GPFS foretrukne driftsform er spredt, og løsningen blev formateret til at bruge den. I denne tilstand tildeles blokke fra begyndelsen på en pseudo-tilfældig måde og spreder data over hele overfladen af hver harddisk. Mens den åbenlyse ulempe er en mindre indledende maksimal ydeevne, opretholdes denne ydeevne ret konstant, uanset hvor meget plads der bruges på filsystemet. At i modsætning til andre parallelle filsystemer, der oprindeligt bruger de ydre spor, der kan indeholde flere data (sektorer) pr. Diskrevolution, og derfor har den højest mulige ydeevne, HDD'erne kan levere, men da systemet bruger mere plads, bruges indre spor med mindre data pr. Omdrejning 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 de 16 beregningsnoder. De udførte tests varierede fra enkelt tråd op til 1024 tråde.
  Cacheeffekter blev minimeret ved at indstille GPFS-sidepuljen justerbar til 16 GiB og bruge filer, der er større end to gange så store. Denne benchmarktest brugte 8 MiB-blokke for optimal ydeevne. Det foregående afsnit om præstationstest har en mere fuldstændig forklaring på disse forhold. 
  Følgende kommandoer blev brugt til at udføre benchmarket for skrivninger og læsninger, hvor tråde var variablen med antallet af anvendte tråde (1 til 1024 forø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 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 --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 128G 

  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 128G

  
  
  Figur 3: N til 1 sekventiel ydeevne
  
  Fra resultaterne kan vi observere, at ydeevnen stiger igen meget hurtigt med antallet af anvendte klienter og derefter når et plateau, der er semistabilt for læsninger og meget stabilt for skrivninger helt til det maksimale antal tråde, der bruges på denne test. Derfor er den sekventielle ydeevne for store enkeltdelte filer stabil, selv for 1024 samtidige klienter. Bemærk, at den maksimale læseydelse var 23,7 GB/s ved 16 tråde, og sandsynligvis var flaskehalsen InfiniBand EDR-grænsefladen, mens ME4-systemer stadig havde en vis ekstra ydeevne til rådighed. Desuden faldt læseydelsen fra denne værdi, indtil den nåede plateauet på omkring 20,5 GB/s, med et midlertidigt fald til 18,5 GB/s ved 128 tråde. På samme måde skal du bemærke, at den maksimale skriveydelse på 16,5 blev nået ved 16 tråde, og den er tilsyneladende lav sammenlignet med ME4-arraysspecifikationerne.
   

  ---

  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 tråd op til 1024 tråde. Denne benchmarktest brugte 4 KiB-blokke til efterligning af små blokke trafik.
  Cachelagringseffekter blev minimeret ved at indstille GPFS-sidepuljen justerbar til 16 GiB og bruge filer, der er to gange så store. Den første ydelsestestsektion har en mere komplet forklaring på, hvorfor dette er effektivt på GPFS. 
  Følgende kommando blev brugt til at udføre benchmarket i tilfældig IO-tilstand for både skrivninger og læsninger, hvor tråde var variablen med antallet af anvendte tråde (1 til 1024 forøget i kræfter på to), og trådliste var den 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.

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

  
  Figur 4:  N til N tilfældig ydeevne
  
  Fra resultaterne kan vi observere, at skriveydelsen starter med en høj værdi på næsten 8.2K IOPS og stiger støt op til 128 tråde, hvor den når et plateau og forbliver tæt på den maksimale værdi på 16.2K IOP'er. Læseydelsen på den anden side starter meget lille ved over 200 IOPS og øger ydeevnen næsten lineært med antallet af anvendte klienter (husk, at antallet af tråde fordobles for hvert datapunkt) og når den maksimale ydeevne på 20.4K IOPS ved 512 tråde uden tegn på at nå maksimum. Brug af flere tråde på de nuværende 16 beregningsnoder med to CPU'er hver, og hvor hver CPU har 18 kerner, har dog den begrænsning, at der ikke er nok kerner til at køre det maksimale antal IOzone-tråde (1024) uden at pådrage sig kontekstskift (16 x 2 x 18 = 576 kerner), hvilket begrænser ydeevnen betydeligt. En fremtidig test med flere beregningsnoder kunne kontrollere, hvilken tilfældig læseydelse der kan opnås med 1024 tråde med IOzone, eller IOR kunne bruges til at undersøge adfærden med mere end 1024 tråde.
  
   

  ---

  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 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 mapper metadata), få antallet af oprettelser, statistik, læser og fjerner løsningen kan håndtere.
  For at kunne evaluere løsningen korrekt sammenlignet med andre Dell EMC HPC-storageløsninger blev det valgfrie High Demand Metadata-modul brugt, men med et enkelt ME4024-system, selv da den store konfiguration og testet i dette arbejde blev udpeget til at have to ME4024'er. 
  Dette metadatamodul med stor efterspørgsel kan understøtte op til fire ME4024-systemer, og det foreslås at øge antallet af ME4024-systemer til 4, før der tilføjes endnu et metadatamodul. Yderligere ME4024-arrays forventes at øge metadata-ydeevnen lineært med hvert ekstra array, undtagen måske for Stat-operationer (og læsninger for tomme filer), da tallene er meget høje, på et tidspunkt vil CPU'erne blive 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åde var variablen med antallet af anvendte tråde (1 til 512 øget i kræfter 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 for 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

  
  Da ydeevneresultater kan påvirkes af det samlede antal IOP'er, 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

  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
  
  Bemærk først, at den valgte skala var logaritmisk med base 10 for at muliggøre sammenligning af operationer, der har forskelle i flere størrelsesordener; Ellers ville nogle af operationerne se ud som en flad linje tæt på 0 på en normal graf. En loggraf med base 2 kunne være mere passende, da antallet af tråde øges i potenser på 2, men grafen ville se temmelig ens ud, og folk har en tendens til at håndtere og huske bedre tal baseret på kræfter på 10.
  
  
  Systemet får meget gode resultater med Stat- og Read-operationer, der når deres højeste værdi ved 64 tråde med henholdsvis 11.2M op/s og 4.8M op/s. Fjernelsesoperationer opnåede det maksimale på 169.4K op / s ved 16 tråde og Create-operationer, der nåede deres højdepunkt ved 512 tråde med 194.2K op / s. Stat- og Read-handlinger har større variation, men når de når deres højeste værdi, falder ydeevnen ikke til under 3M op/s for Stats og 2M op/s for Reads. Opret og Fjern er mere stabile, når de når et plateau og forbliver over 140K op/s for fjernelse og 120K op/s for Opret.
   

  ---

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

  Denne test er næsten identisk med den foregående, bortset fra at der i stedet for tomme filer blev brugt små filer på 4KiB. 
  Følgende kommando blev brugt til at udføre benchmarket, hvor tråde var variablen med antallet af anvendte tråde (1 til 512 øget i kræfter 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 for at sprede dem homogent på tværs af de 16 beregningsnoder.

  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

  
  Figur 6:  Metadataydeevne – små filer (4K)
  
  Systemet får meget gode resultater for stat- og fjernelsesoperationer, der når deres højeste værdi ved 128 tråde med henholdsvis 7.7M op / s og 1M op / s. Fjernelsesoperationer opnåede det maksimale på 37.3K op / s og Opret operationer, der nåede deres højdepunkt med 55.5K op / s, begge ved 512 tråde. Stat- og fjernelsesoperationer har større variabilitet, men når de når deres højeste værdi, falder ydeevnen ikke til under 4M op/s for statistik og 200K op/s for fjernelse. Opret og læs har mindre variation og fortsætter med at stige, efterhånden som antallet af tråde vokser.
  Da disse tal er for et metadatamodul med en enkelt ME4024, øges ydeevnen for hvert yderligere ME4024-array, men vi kan ikke bare antage en lineær stigning for hver operation. Medmindre hele filen passer ind i inoden til en sådan fil, vil datamål på ME4084s blive brugt til at gemme 4K-filerne, hvilket begrænser ydeevnen til en vis grad. Da inodestørrelsen er 4KiB, og den stadig skal gemme metadata, passer kun filer omkring 3 KiB ind, og enhver fil, der er større end det, bruger datamål.
   

  ---

  Metadataydeevne ved hjælp af MDtest med 3K-filer

  Denne test er næsten nøjagtig identisk med de foregående, bortset fra at små filer af 3KiB blev brugt. Den største forskel er, at disse filer passer helt ind i inoden. Derfor bruges lagernoderne og deres ME4084'er ikke, hvilket forbedrer den samlede hastighed ved kun at bruge SSD-medier til lagring og mindre netværksadgang. 
  Følgende kommando blev brugt til at udføre benchmarket, hvor tråde var variablen med antallet af anvendte tråde (1 til 512 øget i kræfter 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 for at sprede dem homogent på tværs af de 16 beregningsnoder.

  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 3K -e 3K

   

  
  Figur 7: Metadata ydeevne - Små filer (3K)
  
  Systemet får meget gode resultater for Stat- og Read-operationer, der når deres højeste værdi ved 256 tråde med henholdsvis 8.29M op / s og 5.06M op / s. Fjernelsesoperationer opnåede maksimum på 609K op/s ved 128 tråde og Create-operationer, der nåede deres højdepunkt med 78K op/s ved 512 tråde. Statistik- og læsehandlinger har større variation end Opret og Fjern. Fjernelse har et lille fald i ydeevnen for de to højere trådpunkter, hvilket tyder på, at den vedvarende ydeevne efter 128 tråde vil være lidt over 400K op / s. Opretter blev ved med at øge op til 512 tråde, men ser ud til at nå et plateau, så den maksimale ydeevne stadig kan være under 100K op/s.
  Da små filer som disse gemmes fuldstændigt på det SSD-baserede metadatamodul, kan programmer, der kræver overlegen ydeevne for små filer, bruge et eller flere valgfrie metadatamoduler med høj efterspørgsel til at øge ydeevnen for små filer. Filer, der passer ind i inoden, er dog små efter nuværende standarder. Da metadatamålene desuden bruger RAID1'er med SSD'er, der er relativt små (maks. størrelse er 19,2 TB), vil kapaciteten være begrænset sammenlignet med storagenoderne. Derfor skal der udvises forsigtighed for at undgå at udfylde metadatamål, hvilket kan forårsage unødvendige fejl og andre problemer.
   

  ---

  Avanceret analyse

  Blandt PixStor-funktioner kan overvågning af filsystemet via avanceret analyse være afgørende for i høj grad at forenkle administrationen, hvilket hjælper med proaktivt eller reaktivt at finde problemer eller potentielle problemer. Dernæst vil vi kort gennemgå nogle af disse funktioner.
  Figur 8 viser nyttige oplysninger baseret på filsystemets kapacitet. I venstre side er filsystemets samlede plads, der bruges, og de ti bedste brugere baseret på filsystemets anvendte kapacitet. I højre side en historisk visning med kapacitet brugt over mange år, derefter de ti bedste anvendte filtyper og de ti bedste filsæt, begge baseret på den anvendte kapacitet, i et format, der ligner pareto-diagrammer (uden linjerne for kumulative totaler). Med disse oplysninger kan det være let at finde brugere, der får mere end deres rimelige andel af filsystemet, tendenser i kapacitetsudnyttelsen for at hjælpe beslutninger om fremtidig vækst for kapacitet, hvilke filer der bruger det meste af pladsen, eller hvilke projekter der tager det meste af kapaciteten.
  
  
  Figur 8:  PixStor-analyse – visning af kapacitet
  
  Figur 9 giver en filtællingsvisning med to meget nyttige måder at finde problemer på. Den første halvdel af skærmen har de ti bedste brugere i et cirkeldiagram og top ti filtyper og top ti filsæt (tænk projekter) i et format, der ligner pareto-diagrammer (uden linjerne for kumulative totaler), alt baseret på antal filer. Disse oplysninger kan bruges til at besvare nogle vigtige spørgsmål. For eksempel hvilke brugere, der monopoliserer filsystemet ved at oprette for mange filer, hvilken type fil skaber et metadatamareridt, eller hvilke projekter der bruger de fleste ressourcer.
  Den nederste halvdel har et histogram med antal filer (frekvens) for filstørrelser ved hjælp af 5 kategorier til forskellige filstørrelser. Dette kan bruges til at få en idé om de filstørrelser, der bruges på tværs af filsystemet, som koordineret med filtyper kan bruges til at beslutte, om komprimering vil være gavnlig.
  
  
  Figur 9:  PixStor Analytics - Filoptællingsvisning

  
  
   

  ---

  Konklusioner og fremtidigt arbejde

  Den nuværende løsning var i stand til at levere ret god ydeevne, som forventes at være stabil uanset den anvendte plads (da systemet blev formateret i spredt tilstand), som det kan ses i tabel 4. Desuden skaleres løsningen lineært i kapacitet og ydeevne, efterhånden som flere lagernodemoduler tilføjes, og en lignende præstationsforøgelse kan forventes fra det valgfri metadatamodul med høj efterspørgsel. 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
  
   

  	Optimal ydeevne		Vedvarende ydeevne
  	Skrive	Læse	Skrive	Læse
  Store sekventielle N-klienter til N-filer	16,7 GB/s	23 GB/s	16,5 GB/s	20,5 GB/s
  Store sekventielle N-klienter til en enkelt delt fil	16,5 GB/s	23,8 GB/s	16,2 GB/s	20,5 GB/s
  Tilfældige små blokke N-klienter til N-filer	15,8 KIOps	20.4KIOps	15,7 KIOps	20.4KIOps
  Metadata: Opret tomme filer	169,4K IOps		127,2 K IOps
  Metadata Stat tomme filer	11,2 mio. IOps		3,3 mio. IOps
  Metadata Læs tomme filer	4,8 mio. IOps		2,4 mio. IOps
  Metadata: Fjern tomme filer	194,2 K IOps		144,8K IOps
  Metadata Opret 4KiB-filer	55,4K IOps		55,4K IOps
  Metadata Stat 4KiB-filer	6,4 mio. IOps		4 mio. IOps
  Metadata Læs 4KiB-filer	37,3K IOps		37,3K IOps
  Metadata Fjern 4KiB-filer	1 mio. IOps		219,5K IOps

  
  
  Da løsningen er beregnet til at blive frigivet med Cascade Lake-CPU'er og hurtigere RAM, når systemet har den endelige konfiguration, vil der blive udført nogle præstationsstikprøver. Og test det valgfrie High Demand Metadata Module med mindst 2 x ME4024s- og 4KiB-filer er nødvendig for bedre at dokumentere, hvordan metadataydeevnen skaleres, når datamål er involveret. Derudover vil resultaterne for gateway-noderne blive målt og rapporteret sammen med eventuelle relevante resultater fra stikprøvekontrollerne i en ny blog eller en hvidbog. Endelig er det planlagt, at flere løsningskomponenter skal testes og frigives for at give endnu flere funktioner.

  ---