Zu den Hauptinhalten
  • Bestellungen schnell und einfach aufgeben
  • Bestellungen anzeigen und den Versandstatus verfolgen
  • Profitieren Sie von exklusiven Prämien und Rabatten für Mitglieder
  • Erstellen Sie eine Liste Ihrer Produkte, auf die Sie jederzeit zugreifen können.

Dell EMC Ready Solution for HPC PixStor Storage

Zusammenfassung: Referansearkitektur for løsningen sammen med innledende ytelsesevaluering.

Dieser Artikel gilt für Dieser Artikel gilt nicht für Dieser Artikel ist nicht an ein bestimmtes Produkt gebunden. In diesem Artikel werden nicht alle Produktversionen aufgeführt.

Symptome

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

Ursache

.

Lösung

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

Dagens HPC-miljøer har økte krav til høyhastighetslagring som også ofte krever høy kapasitet og distribuert tilgang via flere standardprotokoller som NFS, SMB og andre. Disse høye HPC-kravene dekkes vanligvis av parallelle filsystemer som gir samtidig tilgang til en enkelt fil eller et sett med filer fra flere noder, veldig effektivt og sikkert distribuerer data til flere LUN-er over flere servere.

 

Løsningsarkitektur

I denne bloggen presenterer vi Dell EMCs nyeste tillegg til parallellfilsystemløsningene (PFS) for HPC-miljøer, Dell EMC Ready Solution for HPC PixStor Storage. Figur 1 viser referansearkitekturen, som utnytter Dell EMC PowerEdge R740-servere og PowerVault ME4084- og ME4024-lagringsarrayer med PixStor-programvaren fra partnerselskapet vårt Arcastream.
PixStor inkluderer det utbredte General Parallel File System, også kjent som Spectrum Scale som PFS-komponenten, i tillegg til Arcastream-programvarekomponenter som avansert analyse, forenklet administrasjon og overvåking, effektivt filsøk, avanserte gateway-funksjoner og mange andre.

SLN318841_en_US__1image(11979)
Figur 1: Referansearkitektur.

 

Løsningskomponenter

Denne løsningen er planlagt å bli utgitt med de nyeste Intel Xeon 2nd Generation Scalable Xeon CPUer, aka Cascade Lake CPUer og noen av serverne vil bruke den raskeste RAM tilgjengelig for dem (2933 MT / s). Men på grunn av maskinvare tilgjengelig for prototype løsningen og karakterisere ytelsen, servere med Intel Xeon 1st generation skalerbare Xeon CPUer aka Skylake-prosessorer og tregere RAM ble brukt. Siden flaskehalsen for løsningen ligger på SAS-kontrollerne for Dell EMC PowerVault ME40x4-arrayene, forventes det ingen signifikant ytelsesforskjell når Skylake-CPU-ene og RAM-en erstattes med de planlagte Cascade Lake-prosessorene og raskere RAM. I tillegg, selv om den nyeste versjonen av PixStor som støttet RHEL 7.6 var tilgjengelig på tidspunktet for konfigurering av systemet, ble det besluttet å fortsette QA-prosessen og bruke Red Hat® Enterprise Linux® 7.5 og den forrige mindre versjonen av PixStor for å karakterisere systemet. Når systemet er oppdatert til Cascade Lake CPUer, vil PixStor programvaren også bli oppdatert til den nyeste versjonen, og noen ytelse stikkprøver vil bli gjort for å verifisere ytelsen forble lukket til tallene som er rapportert i dette dokumentet.

På grunn av den tidligere beskrevne situasjonen har tabell 1 listen over hovedkomponenter for løsningen. Den midterste kolonnen har de planlagte komponentene som skal brukes ved utgivelse og derfor tilgjengelig for kunder, og den siste kolonnen er komponentlisten som faktisk brukes til å karakterisere ytelsen til løsningen. De oppførte diskene eller data (12 TB NLS) og metadata (960 GB SSD), er de som brukes til ytelseskarakterisering, og raskere stasjoner kan gi bedre tilfeldige IOP-er og kan forbedre metadataoperasjoner for oppretting/fjerning.

For fullstendighetens skyld ble listen over mulige dataharddisker og metadata for SSD-disker inkludert, som er basert på diskene som støttes, som spesifisert i støttematrisen for Dell EMC PowerVault ME4, som er tilgjengelig på Internett.

Tabell 1 Komponenter som skal brukes ved utgivelse og de som brukes i testmiljøet

SLN318841_en_US__2image(12041)
 

Karakterisering av ytelse

For å karakterisere denne nye Ready Solution brukte vi maskinvaren som er spesifisert i den siste kolonnen i tabell 1, inkludert den valgfrie metadatamodulen med høy etterspørsel. For å vurdere løsningsytelsen ble følgende ytelsesprøver brukt:

 
  •     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

    SLN318841_en_US__3image(11984)
    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

    SLN318841_en_US__4image(11985)

    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

    SLN318841_en_US__5image(11987)
    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




    SLN318841_en_US__6image(11988)
    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

    SLN318841_en_US__7image(11989)
    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

     

    SLN318841_en_US__8image(11990)
    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.

    SLN318841_en_US__9image(11993)
    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.

    SLN318841_en_US__10image(11994)
    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.


     

Betroffene Produkte

High Performance Computing Solution Resources, Dell EMC PowerVault ME4012, Dell EMC PowerVault ME4024, Dell EMC PowerVault ME4084
Artikeleigenschaften
Artikelnummer: 000130962
Artikeltyp: Solution
Zuletzt geändert: 23 Sept. 2024
Version:  6
Antworten auf Ihre Fragen erhalten Sie von anderen Dell NutzerInnen
Support Services
Prüfen Sie, ob Ihr Gerät durch Support Services abgedeckt ist.