Dell EMC Ready Solution for HPC PixStor Storage

Artikkel skrevet av Mario Gallegos fra HPC og AI Innovation Lab i oktober 2019

Innholdsfortegnelse

1. Innledning
   1. Løsningsarkitektur
   2. Løsningskomponenter
2. Karakterisering av ytelse
   1. Sekvensiell IOzone ytelse N-klienter til N-filer
   2. Sekvensiell IOR-ytelse N-klienter til 1 fil
   3. Tilfeldige små blokker IOzone ytelse N-klienter til N-filer
   4. Metadataytelse med MDtest ved hjelp av tomme filer
   5. Metadataytelse med MDtest ved hjelp av 4 KiB-filer
   6. Metadataytelse ved hjelp av MDtest med 3K-filer
3. Advanced Analytics
4. Konklusjoner og fremtidig arbeid

Innledning

Løsningsarkitektur

Løsningskomponenter

Karakterisering av ytelse

•     IOzone N til N sekvensiell
•     IOR N til 1 sekvensiell
•     IOzone tilfeldig
•     MDtest
  
  For alle benchmarks nevnt ovenfor, hadde testen sengen klientene som beskrevet i tabell 2 nedenfor. Siden antall behandlingsnoder tilgjengelig for testing var 16, da et høyere antall tråder var nødvendig, ble disse trådene likt fordelt på beregningsnodene (dvs. 32 tråder = 2 tråder per node, 64 tråder = 4 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 det begrensede antallet beregningsnoder. Siden referansene støtter et høyt antall tråder, ble det brukt en maksimumsverdi på opptil 1024 (spesifisert for hver test), samtidig som man unngikk overdreven kontekstveksling og andre relaterte bivirkninger fra å påvirke ytelsesresultatene.
  
  Tabell 2 Klient test seng

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

   

  ---

  Sekvensiell IOzone ytelse N-klienter til N-filer

  Sekvensielle N-klienter til N-filers ytelse ble målt med IOzone versjon 3.487. Testene som ble utført varierte fra en enkelt tråd opp til 1024 tråder. 
  Caching-effekter ble minimert ved å sette GPFS-sidebassenget justerbart til 16GiB og bruke filer større enn to ganger så stor. Det er viktig å merke seg at for GPFS angir den justerbare mengden minne som brukes til hurtigbufring av data, uavhengig av hvor mye RAM som er installert og gratis. Det er også viktig å merke seg at mens blokkstørrelsen for store, sekvensielle overføringer er 1 MiB i tidligere Dell EMC HPC-løsninger, ble GPFS formatert med 8 MiB-blokker, og derfor brukes denne verdien på referansemålingen for optimal ytelse. Det kan se for stort ut og tilsynelatende kaste bort for mye plass, men GPFS bruker tildeling av underblokker for å forhindre den situasjonen. I den nåværende konfigurasjonen ble hver blokk delt inn i 256 underblokker på 32 KiB hver. 
  Følgende kommandoer ble brukt til å utføre referanseindeksen for skriving og lesing, der Threads var variabelen med antall tråder som ble brukt (1 til 1024 økt i potens av to), og threadlist var filen som tildelte hver tråd på en annen node, ved hjelp av rund robin for å spre dem homogent over de 16 beregningsnodene.

  ./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 observere at ytelsen stiger veldig 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 sekvensiell ytelse for store filer stabil selv for 1024 samtidige klienter. Legg merke til at maksimal leseytelse var 23 GB/s ved 32 tråder, og flaskehalsen var sannsynligvis InfiniBand EDR-grensesnittet, mens ME4-arrayer fortsatt hadde litt ekstra ytelse tilgjengelig. Tilsvarende merke til at den maksimale skriveytelsen på 16,7 ble nådd litt tidlig på 16 tråder, og det er tilsynelatende lav i forhold til ME4 arrays spesifikasjoner.
  Her er det viktig å huske at GPFS foretrukne driftsmodus er spredt, og løsningen ble formatert til å bruke den. I denne modusen tildeles blokker helt fra begynnelsen 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 uavhengig av hvor mye plass som brukes på filsystemet. Det i motsetning til andre parallelle filsystemer som i utgangspunktet bruker de ytre sporene som kan holde mer data (sektorer) per diskrevolusjon, og derfor har høyest mulig ytelse harddiskene kan 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-ytelse 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 ytelsesprøven over de 16 databehandlingsnodene. Testene som ble utført varierte fra én tråd opp til 1024 tråder.
  Caching-effekter ble minimert ved å sette GPFS-sidebassenget justerbart til 16GiB og bruke filer større enn to ganger så stor. Disse ytelsestestene brukte 8 MiB-blokker for optimal ytelse. Den forrige ytelsestestdelen har en mer fullstendig forklaring på disse forholdene. 
  Følgende kommandoer ble brukt til å utføre referanseindeksen for skriving og lesing, der Threads var variabelen med antall tråder som ble brukt (1 til 1024 økt i potens av to), og my_hosts.$Threads er den tilsvarende filen som tildelte hver tråd på en annen node, ved hjelp av round robin for å spre dem homogent over de 16 beregningsnodene.

  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 observere at ytelsen stiger igjen veldig raskt med antall klienter som brukes, og når deretter et platå som er semi-stabilt for lesing og veldig stabilt for skriveoperasjoner helt til maksimalt antall tråder som brukes på denne testen. Derfor er sekvensiell ytelse for store enkeltdelte filer stabil selv for 1024 samtidige klienter. Legg merke til at maksimal leseytelse var 23,7 GB/s ved 16 tråder, og flaskehalsen var sannsynligvis InfiniBand EDR-grensesnittet, mens ME4-arrayer fortsatt hadde litt ekstra ytelse tilgjengelig. Videre gikk leseytelsen ned fra denne verdien til den nådde platået på rundt 20,5 GB/s, med en kortvarig nedgang til 18,5 GB/s ved 128 tråder. Legg også merke til at den maksimale skriveytelsen på 16,5 ble nådd ved 16 tråder, og den er tilsynelatende lav sammenlignet med spesifikasjonene for ME4-matriser.
   

  ---

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

  Ytelsen til tilfeldige N-klienter til N-filer ble målt med IOzone versjon 3.487. Testene som ble utført varierte fra én tråd opp til 1024 tråder. Denne referansetesten brukte 4 KiB-blokker for å etterligne trafikk fra små blokker.
  Caching-effekter ble minimert ved å sette GPFS-sidebassenget justerbart til 16GiB og bruke filer to ganger den størrelsen. Den første delen om ytelsestest har en mer fullstendig forklaring på hvorfor dette er effektivt på GPFS. 
  Følgende kommando ble brukt til å utføre referanseindeksen i tilfeldig I/O-modus for både skriving og lesing, der Threads var variabelen med antall tråder som ble brukt (1 til 1024 økt i potens av to), og threadlist var filen som tildelte hver tråd på en annen node, ved hjelp av round robin for å spre dem homogent over de 16 beregningsnodene.

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

  
  Figur 4:  N til N Tilfeldig ytelse
  
  Fra resultatene kan vi observere at skriveytelsen starter med en høy verdi på nesten 8.2K IOPS og stiger jevnt opp til 128 tråder der den når et platå og forblir nær maksimumsverdien på 16.2K IOP. Leseytelsen, derimot, starter veldig liten med over 200 IOPS og øker ytelsen nesten lineært med antall klienter som brukes (husk at antall tråder dobles for hvert datapunkt) og når maksimal ytelse på 20,4K IOPS ved 512 tråder uten tegn til å nå maksimum. Bruk av flere tråder på de nåværende 16 databehandlingsnodene med to CPU-er hver og hvor hver CPU har 18 kjerner, har imidlertid begrensningen at det ikke er nok kjerner til å kjøre maksimalt antall IOzone-tråder (1024) uten å pådra seg kontekstveksling (16 x 2 x 18 = 576 kjerner), noe som begrenser ytelsen betraktelig. En fremtidig test med flere beregningsnoder kan sjekke hvilken tilfeldig leseytelse som kan oppnås med 1024 tråder med IOzone, eller IOR kan brukes til å undersøke oppførselen med mer enn 1024 tråder.
  
   

  ---

  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 ytelsesprøven over de 16 databehandlingsnodene. Testene som ble utført varierte fra én tråd opp til 512 tråder. Benchmark ble brukt for filer bare (ingen kataloger metadata), får antall oppretter, statistikk, leser og fjerner løsningen kan håndtere.
  For å evaluere løsningen riktig i forhold til andre Dell EMC HPC-lagringsløsninger, ble den valgfrie High Demand Metadata Module brukt, men med en enkelt ME4024-array, selv om den store konfigurasjonen og testet i dette arbeidet ble utpekt til å ha to ME4024. 
  Denne metadatamodulen med høy etterspørsel kan støtte opptil fire ME4024-matriser, og det anbefales å øke antallet ME4024-matriser til fire før du legger til en ny metadatamodul. Flere 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, vil CPUene på et tidspunkt bli en flaskehals og ytelsen vil ikke fortsette å øke lineært.
  Følgende kommando ble brukt til å utføre referanseindeksen, der Threads var variabelen med antall tråder som ble brukt (1 til 512 økt i potens av to), og my_hosts.$Threads er den tilsvarende filen som tildelte hver tråd på en annen node, ved hjelp av rund robin for å spre dem homogent over de 16 beregningsnodene. I likhet med Random IO-referansen var det maksimale antallet tråder begrenset til 512, siden det ikke er nok kjerner for 1024 tråder, og kontekstveksling ville påvirke resultatene, og rapportere et tall lavere enn den virkelige ytelsen til løsningen.

  mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --prefiks /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 besluttet å holde fast det totale antallet filer til 2 MiB-filer (2^21 = 2097152), antall filer per katalog fastsatt til 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 grunntall 10, for å tillate sammenligning av operasjoner som har forskjeller flere størrelsesordener; Ellers vil noen av operasjonene se ut som en flat linje nær 0 på en normal graf. En logggraf med base 2 kan være mer passende, siden antall tråder økes i potenser på 2, men grafen vil se ganske lik ut, og folk har en tendens til å håndtere og huske bedre tall basert på potenser på 10.
  
  
  Systemet får svært gode resultater med Stat og Read operasjoner nå sin topp verdi på 64 tråder med 11.2M op / s og 4.8M op / s henholdsvis. Fjerningsoperasjoner oppnådde maksimalt 169.4K op/s ved 16 tråder og Create-operasjoner nådde sitt høydepunkt på 512 tråder med 194.2K op/s. Stat- og Read-operasjoner har mer variabilitet, men når de når toppverdien, faller ikke ytelsen under 3 millioner op/s for statistikk og 2 millioner op/s for lesing. Opprett og fjern er mer stabile når de når et platå og forblir over 140K op / s for fjerning og 120K op / s for Create.
   

  ---

  Metadataytelse med MDtest ved hjelp av 4 KiB-filer

  Denne testen er nesten identisk med den forrige, bortsett fra at i stedet for tomme filer ble små filer på 4KiB brukt. 
  Følgende kommando ble brukt til å utføre referanseindeksen, der Threads var variabelen med antall tråder som ble brukt (1 til 512 økt i potens av to), og my_hosts.$Threads er den tilsvarende filen som tildelte hver tråd på en annen node, ved hjelp av rund robin for å spre dem homogent over de 16 beregningsnodene.

  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 Stat og fjerning operasjoner nå sin topp verdi på 128 tråder med 7.7M op / s og 1M op / s henholdsvis. Fjerningsoperasjoner oppnådde maksimalt 37.3K op/s og Create-operasjoner og oppnådde sitt høydepunkt med 55.5K op/s, begge på 512 tråder. Stat- og fjerningsoperasjoner har mer variabilitet, men når de når toppverdien, faller ytelsen ikke under 4M op / s for statistikk og 200K op / s for fjerning. Opprett og Les har mindre variasjon og fortsetter å øke etter hvert som antall tråder vokser.
  Siden disse tallene er for en metadatamodul med en enkelt ME4024, vil ytelsen øke for hver ekstra ME4024-array, men vi kan ikke bare anta en lineær økning for hver operasjon. Med mindre hele filen passer inn i inoden for en slik fil, vil datamål på ME4084s bli brukt 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 enhver fil større enn det vil bruke datamål.
   

  ---

  Metadataytelse ved hjelp av MDtest med 3K-filer

  Denne testen er nesten nøyaktig identisk med de forrige, bortsett fra at små filer med 3KiB ble brukt. Hovedforskjellen er at disse filene passer helt inn i inoden. Derfor brukes ikke lagringsnodene og deres ME4084-er, noe som forbedrer den totale hastigheten ved å bruke bare SSD-medier for lagring og mindre nettverkstilganger. 
  Følgende kommando ble brukt til å utføre referanseindeksen, der Threads var variabelen med antall tråder som ble brukt (1 til 512 økt i potens av to), og my_hosts.$Threads er den tilsvarende filen som tildelte hver tråd på en annen node, ved hjelp av rund robin for å spre dem homogent over de 16 beregningsnodene.

  mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --prefiks /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: Metadataytelse - Små filer (3K)
  
  Systemet får svært gode resultater for Stat- og Read-operasjoner som når sin toppverdi på 256 tråder med henholdsvis 8.29M op/s og 5.06M op/s. Fjerningsoperasjoner oppnådde maksimum 609K op/s ved 128 tråder og skapte operasjoner som oppnådde sitt høydepunkt med 78K op/s ved 512 tråder. Stat- og leseoperasjoner har større variabilitet enn oppretting og fjerning. Fjerning har en liten nedgang i ytelse for de to høyere tråder poeng tyder på vedvarende ytelse etter 128 tråder vil være litt over 400K op / s. Oppretter holdt økende opp til 512 tråder, men ser ut som er å nå et platå så maksimal ytelse kan fortsatt være under 100K op / s.
  Siden små filer som disse lagres helt på SSD-basert metadatamodul, kan programmer som krever overlegen ytelse for små filer, bruke én eller flere valgfrie metadatamoduler med høy etterspørsel for å øke ytelsen til små filer. Filer som passer i inoden er imidlertid små etter gjeldende standarder. Siden metadatamålene bruker RAID1-er med SSD-er relativt små (maksimal størrelse er 19,2 TB), vil kapasiteten være begrenset sammenlignet med lagringsnodene. Derfor må det utvises forsiktighet for å unngå å fylle opp metadatamål, noe som kan forårsake unødvendige feil og andre problemer.
   

  ---

  Advanced Analytics

  Blant PixStor evner, overvåking av filsystemet via avansert analyse kan være avgjørende for å i stor grad forenkle administrasjonen, bidrar til å proaktivt eller reaktivt finne problemer eller potensielle problemer. Nå skal vi kort gjennomgå noen av disse funksjonene.
  Figur 8 viser nyttig informasjon basert på filsystemets kapasitet. På venstre side, filsystemets totale plass brukt, og de ti beste brukerne basert på filsystemkapasiteten som brukes. På høyre side, en historisk visning med kapasitet brukt over mange år, deretter de ti beste filtypene som brukes og topp ti filsett, begge basert på anvendt kapasitet, i et format som ligner på paretodiagrammer (uten linjene for kumulative summer). Med denne informasjonen kan det være enkelt å finne brukere som får mer enn sin rettferdige andel av filsystemet, trender for kapasitetsbruk for å hjelpe beslutninger om fremtidig vekst for kapasitet, hvilke filer som bruker mesteparten av plassen eller hvilke prosjekter som tar mesteparten av kapasiteten.
  
  
  Figur 8:  PixStor Analytics - Kapasitet visning
  
  Figur 9 gir en filtellingsvisning med to svært nyttige måter å finne problemer på. Den første halvdelen av skjermen har de ti beste brukerne i et sektordiagram og topp ti filtyper og topp ti filsett (tenk prosjekter) i et format som ligner på paretodiagrammer (uten linjene for kumulative totaler), alt basert på antall filer. Denne informasjonen kan brukes til å svare på noen viktige spørsmål. For eksempel hvilke brukere som monopoliserer filsystemet ved å opprette for mange filer, hvilken type fil som skaper et metadatamareritt eller hvilke prosjekter som bruker mesteparten av ressursene.
  Den nederste halvdelen har et histogram med antall filer (frekvens) for filstørrelser ved hjelp av 5 kategorier for forskjellige filstørrelser. Dette kan brukes til å få en ide om filstørrelsene som brukes på tvers av filsystemet, som koordinert med filtyper kan brukes til å avgjøre om komprimering vil være gunstig.
  
  
  Figur 9:  PixStor Analytics - Visning av antall filer

  
  
   

  ---

  Konklusjoner og fremtidig arbeid

  Den nåværende løsningen var i stand til å levere ganske god ytelse, som forventes å være stabil uavhengig av brukt plass (siden systemet ble formatert i spredt modus), som det fremgår av tabell 4. I tillegg skalerer løsningen i kapasitet og ytelse lineært etter hvert som flere moduler for lagringsnoder legges til, og en lignende ytelsesøkning kan forventes fra den valgfrie metadatamodulen med høy etterspørsel. Denne løsningen gir HPC-kunder et svært pålitelig, parallelt filsystem som brukes av mange av de 500 største HPC-klyngene. I tillegg gir den eksepsjonelle søkefunksjoner, avansert overvåking og administrasjon, og å legge til valgfrie gatewayer tillater fildeling via allestedsnærværende standardprotokoller som NFS, SMB og andre til så mange klienter som nødvendig.
  
  Tabell 4  Topp og vedvarende ytelse
  
   

  	Førsteklasses ytelse		Vedvarende ytelse
  	Skrive	Lese	Skrive	Lese
  Store sekvensielle N-klienter til N-filer	16,7 GB/s	23 GB/s	16,5 GB/s	20,5 GB/s
  Store sekvensielle N-klienter til én delt fil	16,5 GB/s	23,8 GB/s	16,2 GB/s	20,5 GB/s
  Tilfeldige små blokker N-klienter til N-filer	15.8KIOps	20.4KIOps	15.7KIOps	20.4KIOps
  Metadata: Opprette tomme filer	169,4K IOps		127,200 IOps
  Metadata Stat tomme filer	11,2 M IOps		3,3 måneders IOps
  Metadata: Lese tomme filer	4,8 måneders IOps		2,4 måneders IOps
  Metadata Fjern tomme filer	194,200 IOps		144,8 000 IOps
  Metadata: Opprett 4KiB-filer	55,4 K IOps		55,4 K IOps
  Metadata Stat 4KiB-filer	6,4 måneders IOps		4M IOps
  Metadata Les 4KiB-filer	37,3 000 IOps		37,3 000 IOps
  Metadata Fjern 4KiB-filer	1 M IOps		219,5 000 IOps

  
  
  Siden løsningen er ment å bli utgitt med Cascade Lake CPUer og raskere RAM, når systemet har den endelige konfigurasjonen, vil noen ytelsesstikkprøver bli gjort. Og test den valgfrie High Demand Metadata Module med minst 2x ME4024s og 4KiB-filer er nødvendig for bedre å dokumentere hvordan metadataytelsen skaleres når datamål er involvert. I tillegg vil ytelsen for gateway-nodene bli målt og rapportert sammen med relevante resultater fra stikkprøvene i en ny blogg eller et white paper. Til slutt er det planlagt at flere løsningskomponenter skal testes og lanseres for å gi enda flere funksjoner.

  ---