Dell EMC-färdig lösning för lagring med HPC PixStor – kapacitetsutökning

Inget

Innehållsförteckning

1. Introduktion
   1. Lösningsarkitektur
   2. Lösningskomponenter
2. Prestanda karakterisering
   1. Sekventiell IOzone Performance N-klienter till N-filer
   2. Sekventiell IOR Performance N-klienter till 1 fil
   3. Slumpmässigt små block IOzone Performance N-klienter till N-filer
   4. Metadataprestanda med MDtest med tomma filer
   5. Metadataprestanda med MDtest med fyra KiB-filer
3. Slutsatser och framtida arbete

 

---

Introduktion

Dagens HPC-miljöer har ökat kraven på mycket snabb lagring som också ofta kräver hög kapacitet och distribuerad åtkomst via flera standardprotokoll som NFS, SMB och andra. Dessa HPC-krav med hög efterfrågan omfattas vanligtvis av parallellfilsystem som ger samtidig åtkomst till en enda fil eller en uppsättning filer från flera noder, och som mycket effektivt och säkert distribuerar data till flera LUN över flera servrar.

 

---

Lösningsarkitektur

Den här bloggen är en återkommande PFS-lösning (Parallel File System) för HPC-miljöer, DellEMC Ready Solution for HPC PixStor Storage, där PowerVault ME484 EBOD-disksystem används för att öka kapaciteten för lösningen. Bild 1 visar referensarkitekturen som beskriver KAPACITETsexpansionens SAS-tillägg till befintliga PowerVault ME4084-lagringsdisksystem.
PixStor-lösningen omfattar det vanliga parallella filsystemet (Allmänt parallellfilsystem) som även kallas Spectrum Scale som PFS-komponent. Dessutom finns det många andra Programvarukomponenter för Arcastream, till exempel avancerad analys, förenklad administration och övervakning, effektiv filsökning, avancerade gatewayfunktioner och många andra.


Bild 1: Referensarkitektur.

 

---

Lösningskomponenter

Lösningen är planerad att lanseras med den senaste andra generationens Intel Xeon Scalable Xeon-processorer, dvs. Cascade Lake-processorer, och vissa av servrarna använder det snabbaste RAM-minnet som finns tillgängligt för dem (2 933 MT/s). På grund av den maskinvara som finns tillgänglig för arbete med prototypen av lösningen för karakterisera prestanda finns det dock servrar med Intel Xeon första generationens Skalbara Xeon-processorer, till exempel Skylake-processorer och i vissa fall långsammare RAM-minne användes för att karakterisera det här systemet. Eftersom flaskhalsen i lösningen finns hos SAS-styrenheterna i DellEMC PowerVault ME40x4-disksystemen förväntas inga betydande prestandaskillnader när Skylake-processorerna och RAM ersätts med de tänkta Cascade Lake-processorerna och snabbare RAM. Dessutom har lösningen uppdaterats till den senaste versionen av PixStor (5.1.1.4) med stöd för RHEL 7.7 och OFED 4.7 för karakterisering av systemet.

På grund av den tidigare beskrivna situationen har tabell 1 en lista med huvudkomponenter för lösningen, men när avvikelser infördes innehåller den första beskrivningskolumnen komponenter som användes vid lanseringstiden och därför tillgängliga för kunder, och den sista kolumnen är de komponenter som faktiskt används för att karakterisera lösningens prestanda. De enheter som anges för data (12 TB NLS) och metadata (960 Gb SSD) är de som används för prestanda karakterisering, och snabbare enheter kan ge bättre slumpmässiga IP-adresser och kan förbättra åtgärderna för att skapa/ta bort metadata.

Slutligen omfattades en lista över möjliga hårddiskar och metadata för SSD:er för data. Listan baseras på de enheter som stöds som uppräknade i stödmatrisen för DellEMC PowerVault ME4, som är tillgänglig online.

Tabell 1: Komponenter som användes vid lanseringstid och de som användes i testbädden

Lösningskomponent		Vid lansering	Testbädd
Interna anslutningsmöjligheter		Dell Networking S3048-ON Gigabit Ethernet
Undersystem för datalagring		1x till 4 gånger Dell EMC PowerVault ME4084 1x till 4 × Dell EMC PowerVault ME484 (en per ME4084) 80–12 TB 3,5-tums NL SAS3 HDD-hårddiskalternativ på 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, linjär 8+2 RAID 6, segmentstorlek 512 KiB. 4x 1,92 TB SAS3 SSD för metadata – 2x RAID 1 (eller 4 – globala HDD-reservdiskar, om den valfria metadatamodulen med hög begäran används)
Metadatalagringsundersystem med hög begäran som tillval		1x till 2x Dell EMC PowerVault ME4024 (4 × ME4024 vid behov, endast stor konfiguration) 24 × 960 GB 2,5-tums SSD SAS3-enheter (alternativ 480 GB, 960 GB, 1,92 TB) 12 LUN, linjär RAID 1.
RAID-lagringsstyrenheter		12 Gbit/s SAS
Kapacitet enligt konfiguration		Raw: 8 064 TB (7334 TiB eller 7,16 PiB) formaterad ~ 6 144 GB (5 588 TiB eller 5,46 PiB)
Processor	Gateway	2x Intel Xeon Gold 6230 2.1G, 20C/40T, 10,4 GT/s, 27,5 M cacheminne, Turbo, HT (125 W) DDR4-2933	Ej tillämpligt
	Metadata för hög begäran		2x Intel Xeon Gold 6136 vid 3,0 GHz, 12 kärnor
	Lagringsnod		2x Intel Xeon Gold 6136 vid 3,0 GHz, 12 kärnor
	Hanteringsnod	2x Intel Xeon Gold 5220 2.2G, 18C/36T, 10,4 GT/s, 24,75 M cacheminne, Turbo, HT (125 W) DDR4-2666	2x Intel Xeon Gold 5118 vid 2,30 GHz, 12 kärnor
Minne	Gateway	12x 16 GiB 2933 MT/s RDIMM (192 GiB)	Ej tillämpligt
	Metadata för hög begäran		24x 16 GiB 2666 MT/s RDIMM (384 GiB)
	Lagringsnod		24x 16 GiB 2666 MT/s RDIMM (384 GiB)
	Hanteringsnod	12 × 16 GB DIMM-moduler, 2 666 MT/s (1 92 GiB)	12x 8 GiB 2666 MT/s RDIMM (96 GiB)
Operativsystem		Red Hat Enterprise Linux 7.6	Red Hat Enterprise Linux 7.7
Kernel-version		3.10.0–957.12.2.el7.x86_64	3.10.0–1062.9.1.el7.x86_64
Programvara för PixStor		5.1.0.0	5.1.1.4
Spektrumskala (GPFS)		5.0.3	5.0.4-2
Nätverksanslutning med höga prestanda		Mellanox ConnectX-5 InfiniBand EDR/100 GbE med dubbla portar och 10 GbE	Mellanox ConnectX-5 InfiniBand EDR
Högprestandaswitch		2x Mellanox SB7800 (HA – redundant)	1 × Mellanox SB7700
OFED Version		Mellanox OFED-4.6-1.0.1.0	Mellanox OFED-4.7-3.2.9
Lokala diskar (OS &analys/övervakning)		Alla servrar utom hanteringsnoden 3 × 480 GB SSD SAS3 (RAID1 + HS) för operativsystem PERC H730P RAID-styrenhet Hanteringsnod 3 × 480 GB SSD SAS3 (RAID1 + HS) för operativsystem PERC H740P RAID-styrenhet	Alla servrar utom hanteringsnoden 2 × 300 GB 15 000 SAS3 (RAID 1) för operativsystem PERC H330 RAID-styrenhet Hanteringsnod 5 × 300 GB 15 000 SAS3 (RAID 5) för operativsystem och analys/övervakning PERC H740P RAID-styrenhet
Systemhantering		iDRAC 9 Enterprise + DellEMC OpenManage	iDRAC 9 Enterprise + DellEMC OpenManage

 

---

Prestanda karakterisering

För att karakterisera den nya Ready Solution använde vi den maskinvara som anges i den sista kolumnen i tabell 1, inklusive den valfria metadatamodulen High Demand. För att bedöma lösningsprestanda användes följande prestandatest:

• IOzone N till N sekventiellt
• IOR N till 1 sekventiell
• IOzone slumpmässigt
• MDtest

 För alla prestandatest som anges ovan hade testbädden klienterna enligt beskrivningen i tabell 2 nedan. Eftersom antalet beräkningsnoder som är tillgängliga för testning endast var 16 när ett högre antal trådar krävdes distribuerades dessa trådar lika på beräkningsnoderna (dvs. 32 trådar = 2 trådar per nod, 64 trådar = 4 trådar per nod, 128 trådar = 8 trådar per nod, 256 trådar = 16 trådar per nod, 512 trådar = 32 trådar per nod, 1 024 trådar = 64 trådar per nod). Avsikten var att simulera ett högre antal samtidiga klienter med det begränsade antalet beräkningsnoder. Eftersom prestandatesterna stöder ett stort antal trådar användes ett maximalt värde på upp till 1 024 (specificerat för varje test), samtidigt som man undviker allt för många kontextväxlingar och andra relaterade bieffekter som påverkar prestandaresultaten.

Tabell 2: Klienttestbädd

Antal klientnoder	16
Klientnod	C6320
Processorer per klientnod	2 x Intel(R) Xeon(R) Gold E5-2697v4 18 kärnor vid 2,30 GHz
Minne per klientnod	12 x 16 GiB 2 400 MT/s RDIMM-moduler
BIOS	2.8.0
OS-kärna	3.10.0-957.10.1
GPFS-version	5.0.3

 

---

Sekventiell IOzone Performance N-klienter till N-filer

Sekventiella N-klienter till N-filers prestanda mättes med IOzone version 3.487. Testerna som utfördes varierade från en tråd upp till 1 024 trådar och resultatet av den utökade kapacitetslösningen (4 x ME4084s + 4 x ME484) står i kontrast till lösningen med stor storlek (4x ME4084). Cacheeffekter minimerades genom att ställa in gpFS-sidpoolen till 16 GiB och använda filer som är större än två gånger så stora. Det är viktigt att observera att för GPFS anger valbart minne den maximala mängden minne som används för cachedata, oavsett hur mycket RAM-minne som är installerat och ledigt. Observera också att medan blockstorleken för stora sekventiella överlåtelser är 1 MiB i tidigare DellEMC HPC-lösningar har GPFS formaterats med 8 MiB-block och därför används det värdet på prestandatestet för optimal prestanda. Det kan se för stort ut och inte alls slösa för mycket utrymme, men GPFS använder delblocksallokering för att förhindra den situationen. I den aktuella konfigurationen underdelades varje block i 256 underblock om 32 KiB vardera.

Följande kommandon användes för att utföra prestandatestet för skrivningar och läsningar, där trådar var variabeln med det antal trådar som användes (1 till 1 024 inkrementella över två), och threadlist var den fil som allokerade varje tråd på en annan nod, med round robin för att sprida dem homogent över de 16 beräkningsnoderna.

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

Bild 2:  N till N sekventiell prestanda


Utifrån resultaten kan vi se att prestandan ökar mycket snabbt med antalet klienter som används och sedan når en platta som är stabil tills det maximala antalet trådar som IOzone tillåter har nåtts, och därför är prestandan för stor fils sekventiell prestanda stabil även för 1 024 samtidiga klienter. Observera att både läs- och skrivprestanda har fördelen med en dubblering av antalet enheter. Den maximala läsprestandan begränsades av bandbredden för de två IB EDR-länkar som används på lagringsnoderna från och med 8 trådar, och ME4-disksystem kan ha vissa extra prestanda tillgängliga. Observera också att den maximala skrivprestandan har ökat från maximalt 16,7 till 20,4 Gbit/s vid 64 och 128 trådar och att den är närmare ME4-disksystemets maximala specifikationer (22 GB/s).

Här är det viktigt att komma ihåg att gpfs föredragna åtgärdsläge är utspridda och att lösningen har formaterats för användning av det läget. I det här läget allokeras block från driftstarten på ett pseudo-slumpmässigt sätt, vilket sprider data över hela ytan på varje hårddisk. Även om den uppenbara nackdelen är en mindre initial maximal prestanda, bibehålls den prestandan ganska konstant oavsett hur mycket utrymme som används i filsystemet. Det i motsats till andra parallella filsystem som ursprungligen använder de yttre spåren och som kan innehålla mer data (sektorer) per diskrotation och därför har högsta möjliga prestanda som hårddiskarna kan tillhandahålla, men i takt med att systemet använder mer utrymme används inre spår med mindre data per revolution, vilket minskar prestandan.

 

---

Sekventiell IOR Performance N-klienter till 1 fil

Sekventiella N-klienter till en enda delad filprestanda mättes med IOR-version 3.3.0, assisterad av OpenMPI v4.0.1 för att köra prestandatestet över de 16 beräkningsnoderna. Testerna som utfördes varierade från en tråd upp till 512 trådar (eftersom det inte fanns tillräckligt med kärnor för 1 024 trådar), och resultaten ställs i kontrast till lösningen utan kapacitetsutökning.
Cacheeffekter minimerades genom att ställa in gpFS-sidpoolen till 16 GiB och använda filer som är större än två gånger så stora. I det här prestandatestet användes åtta miB-block för optimal prestanda. Det föregående avsnittet för prestandatest har en mer fullständig förklaring till dessa frågor.

Följande kommandon användes för att utföra prestandatestet för skrivningar och läsningar, där trådar var variabeln med det antal trådar som användes (1 till 1 024 inkrementell behörighet på två), och my_hosts.$Threads är motsvarande fil som allokerade varje tråd på en annan nod, med round robin för att sprida dem homogent över de 16 beräkningsnoderna.

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/omftestpi /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

Bild 3: N till 1 Sekventiell prestanda

Enligt resultaten kan vi återigen se att de extra enheterna drar nytta av läs- och skrivprestanda. Prestandan ökar återigen mycket snabbt med antalet klienter som används och når sedan en platta som är ganska stabil för läsning och skrivning hela vägen till det maximala antalet trådar som används i det här testet. Observera att den maximala läsprestandan var 24,8 Gbit/s vid 16 trådar och flaskhalsen var InfiniBand EDR-gränssnittet, med ME4-disksystem som fortfarande hade en del extra prestanda tillgängligt. Därifrån minskade läsprestandan från det värdet tills den nådde plattan på cirka 23,8 Gbit/s. Observera på liknande sätt att den maximala skrivprestandan på 19,3 har nåtts vid 8 trådar och når en plateau.
 

---

Slumpmässigt små block IOzone Performance N-klienter till N-filer

Prestanda för slumpmässiga N-klienter till N-filer mättes med FIO-version 3.7 i stället för den traditionella Iozone. Avsikten, som angavs i föregående blogg, var att dra nytta av ett större ködjup för att undersöka den maximala prestanda som ME4084-disksystem kan leverera (tidigare tester för olika ME4-lösningar visade att ME4084-disksystemen behöver mer IO-tryck som Iozone kan leverera för att nå sina slumpmässiga IO-gränser).

Testerna som utfördes varierade från en tråd upp till 512 trådar eftersom det inte fanns tillräckligt med klientkärnor för 1 024 trådar. Varje tråd använde en annan fil och trådarna tilldelades round robin på klientnoderna. I det här prestandatestet användes fyra KiB-block för emulering av trafik med små block och ett ködjup på 16. Resultatet från lösningen med stor storlek och kapacitetsexpansionen jämförs.

Cacheeffekterna minimerades återigen genom att ställa in gpfs-sidpoolen till 16 GiB och använda filer som var två gånger så stora. Det första avsnittet för prestandatest har en mer fullständig förklaring till varför detta gäller för GPFS.

 
Bild 4:  N till N Slumpmässig prestanda

Enligt resultaten kan vi se att skrivprestandan börjar med ett högt värde på 29,1 K IOps och stiger stadigt upp till 64 trådar där det verkar nå en plateau vid cirka 40 K IOps. Läsprestanda å andra sidan börjar vid 1,4K IOps och ökar prestandan nästan linjärt med det antal klienter som används (tänk på att antalet trådar fördubblas för varje datapunkt) och når den maximala prestandan på 25,6 K IOPS vid 64 trådar där det verkar vara nära att nå en platå. Om fler trådar används krävs mer än de 16 beräkningsnoderna för att undvika brist på resurser och en lägre synbar prestanda, där disksystemen faktiskt kan bibehålla prestandan.

 

---

Metadataprestanda med MDtest med tomma filer

Metadataprestanda mättes med MDtest version 3.3.0, assisterad av OpenMPI v4.0.1 för att köra prestandatestet över de 16 beräkningsnoderna. Testerna som utfördes varierade från en tråd upp till 512 trådar. Prestandatestet användes endast för filer (inga katalogmetadata), för att få antalet skapade, statistik, läsningar och borttagning som lösningen kan hantera, och resultaten kontrasterades mot lösningen med stor storlek.

För att korrekt utvärdera lösningen jämfört med andra DellEMC HPC-lagringslösningar och resultaten från föregående blogg användes den valfria High Demand-metadatamodulen, men med ett enda ME4024-disksystem, även om den stora konfigurationen och testades i detta arbete skulle ha två ME4024. Denna metadatamodul med hög begäran kan stödja upp till fyra ME4024-disksystem, och vi föreslår att du ökar antalet ME4024-disksystem till 4 innan du lägger till en annan metadatamodul. Ytterligare ME4024-disksystem förväntas öka metadataprestandan linjärt med varje ytterligare disksystem, förutom kanske för statistikåtgärder (och läsningar för tomma filer), eftersom antalet är mycket höga någon gång blir processorerna en flaskhals och prestandan fortsätter inte att öka linjärt.

Följande kommando användes för att köra prestandatestet, där trådar var variabeln med det antal trådar som användes (1 till 512 ökade med en ström på två), och my_hosts.$Threads är motsvarande fil som allokerade varje tråd på en annan nod, med round robin för att sprida dem homogent över de 16 beräkningsnoderna. Liksom för det slumpmässiga IO-prestandatestet var det maximala antalet trådar begränsade till 512, eftersom det inte finns tillräckligt med kärnor för 1 024 trådar och kontextväxling skulle påverka resultaten och rapportera ett tal som är lägre än lösningens verkliga prestanda.

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

Eftersom prestandaresultaten kan påverkas av det totala antalet IP-adresser, antalet filer per katalog och antalet trådar, har man beslutat att behålla det totala antalet filer till 2 MiB-filer (2^21 = 2097152), antalet filer per katalog korrigerat till 1 024 och antalet kataloger varierade eftersom antalet trådar ändrades enligt tabell 3.

Tabell 3:  MDtest-distribution av filer på kataloger

Antal trådar	Antal kataloger per tråd	Totalt 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

Bild 5: Metadataprestanda – tomma filer

Observera först att den valda skalan var logarithmic med bas 10 för att tillåta jämförelse av åtgärder som har skillnader mellan flera storleksordningar; annars skulle vissa av åtgärderna se ut som en plan linje nära 0 på ett normalt diagram. Ett loggdiagram med bas 2 kan vara mer lämpligt, eftersom antalet trådar ökar med en strömmängd på 2, men diagrammet skulle se väldigt lika ut och folk tenderar att hantera och komma ihåg bättre siffror baserat på 10 strömkrafter.
Systemet får mycket bra resultat när statistik- och läsåtgärder når sitt högsta värde vid 64 trådar med nästan 11 M op/s respektive 4,7 M op/s. Vid borttagning uppnås maximalt 170,6 K op/s vid 16 trådar och Create operations achieving their peak at 32 threads with 222.1K op/s. Statistik- och läsåtgärder har större variationer, men när de når sitt högsta värde sjunker inte prestandan under 3 M för statistik och 2 M op/s för läsningar. Det är stabilare att skapa och ta bort dem när de har nått en platta och ligger kvar på över 140 000 för borttagning och 120 000 för Create (120 000 op/s). Observera att de extra enheterna inte påverkar mycket av metadataåtgärderna för tomma filer som förväntat.
 

---

Metadataprestanda med MDtest med fyra KiB-filer

Det här testet är nästan identiskt med det föregående, förutom att i stället för tomma filer användes små filer på 4 KiB. 
Följande kommando användes för att köra prestandatestet, där trådar var variabeln med det antal trådar som användes (1 till 512 ökade med en ström på två), och my_hosts.$Threads är motsvarande fil som allokerade varje tråd på en annan nod, med round robin för att sprida dem homogent över de 16 beräkningsnoderna.

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

Bild 6:  Metadataprestanda – små filer (4K)

Systemet får mycket bra resultat för statistik- och borttagningsåtgärder som når sitt högsta värde vid 256 trådar med 8,2 M op/s respektive 400 000 op/s. Läsåtgärder ger maximalt 44,8 K op/s och Create operations achieving their peak with 68.1K op/s, båda vid 512 trådar. Statistik- och borttagningsåtgärder har större variationer, men när de når sitt högsta värde sjunker inte prestanda under 3 M för statistik och 280 000 för borttagning. Create och Read har mindre variationer och fortsätter att öka i takt med att antalet trådar växer. Som observeras ger de extra enheterna i kapacitetsexpansionerna endast marginaländringar av metadataprestanda.
Eftersom dessa siffror är för en metadatamodul med en enda ME4024 ökar prestandan för varje ytterligare ME4024-disksystem, men vi kan inte bara anta en linjär ökning för varje åtgärd. Såvida inte hela filen får plats i inoden för en sådan fil, kommer datamål på ME4084s att användas för att lagra 4K-filerna, vilket begränsar prestandan i viss utsträckning. Eftersom inodstorleken är 4 KiB och fortfarande behöver lagra metadata får endast filer på cirka 3 KiB plats i och alla filer som är större än de som använder datamål.
 

---

Slutsatser och framtida arbete

Lösningen med utökad kapacitet kunde förbättra prestanda, inte bara för slumpmässiga åtkomster, utan även för sekventiella prestanda. Det var förväntat eftersom det utspridda läget beter sig som randomiserade åtkomster och att ha fler diskar gör det möjligt att förbättra. Den prestandan, som kan översiktas i tabell 4, förväntas vara stabil från ett tomt filsystem tills den nästan är full. Dessutom skalas lösningen i kapacitet och prestanda linjärt när fler lagringsnodsmoduler läggs till, och en liknande prestandaökning kan förväntas från den valfria metadatamodulen med höga krav. Den här lösningen ger HPC-kunder ett mycket tillförlitligt parallellfilsystem som används av många av de 500 viktigaste HPC-klustren. Dessutom ger den enastående sökfunktioner, avancerad övervakning och hantering och tillägg av valfria gateways gör det möjligt att dela filer med hjälp av allestädes omfattande standardprotokoll som NFS, SMB och andra för så många klienter som behövs.

Tabell 4  Maximal och kontinuerlig prestanda

	Maximala prestanda		Kontinuerlig prestanda
	Skriva	Läsa	Skriva	Läsa
Stora sekventiella N-klienter till N-filer	20,4 GB/s	24,2 GB/s	20,3 GB/s	24 GB/s
Stora sekventiella N-klienter till en enda delad fil	19,3 GB/s	24,8 GB/s	19,3 GB/s	23,8 GB/s
Slumpmässigt små blockerar N-klienter till N-filer	40KIOps	25,6KIOps	40.0KIOps	19.3KIOps
Metadata Skapa tomma filer	169,4 K IOps		123,5 K IOps
Metadatastatistik tomma filer	11 miljoner IOps		3,2 M IOps
Metadata läs tomma filer	4,7 M IOps		2,4 M IOps
Ta bort tomma filer från metadata	170,6 K IOps		156,5 K IOps
Skapa 4 KiB-filer med metadata	68.1K IOps		68.1K IOps
Metadatastatistik 4 KiB-filer	8,2 M IOps		3 M IOps
Metadataläs 4 KiB-filer	44,8 K IOps		44,8 K IOps
Ta bort 4 KiB-filer med metadata	400 000 IOps		280 000 IOps

Eftersom lösningen är avsedd att släpps med Cascade Lake-processorer och snabbare RAM-minne, när systemet har den slutliga konfigurationen, utförs vissa kontroller av prestandaplats. Och testa den valfria metadatamodulen med hög begäran med minst 2x ME4024- och 4 KiB-filer för att bättre dokumentera hur metadataprestanda kan skalas när datamål tas med. Dessutom mäts prestanda för gatewaynoderna och rapporteras tillsammans med relevanta resultat från platskontrollerna i en ny blogg eller ett informationsdokument. Slutligen planeras fler lösningskomponenter som testas och släpps för att ge ännu fler funktioner.