Dell EMC Ready Solution per HPC nello storage PixStor (in inglese)

Articolo scritto da Mario Gallegos di HPC and AI Innovation Lab nel mese di ottobre 2019

Sommario

1. Introduzione
   1. Architettura della soluzione
   2. Componenti della soluzione
2. Caratterizzazione delle prestazioni
   1. Prestazioni IOzone sequenziali da N client a N file
   2. Prestazioni IOR sequenziali da N client a 1 file
   3. Prestazioni IOzone per piccoli blocchi casuali da N client a N file
   4. Prestazioni dei metadati con MDtest utilizzando file vuoti
   5. Prestazioni dei metadati con MDtest con file da 4 KiB
   6. Prestazioni dei metadati utilizzando MDtest con file 3K
3. Advanced Analytics
4. Conclusioni e lavoro futuro

Introduzione

Architettura della soluzione

Componenti della soluzione

Caratterizzazione delle prestazioni

•     IOzone sequenziale da N a N
•     IOR sequenziale da N a 1
•     IOzone casuale
•     MDtest
  
  Per tutti i benchmark elencati in precedenza, il banco di prova aveva i client come descritto nella Tabella 2 riportata di seguito. Poiché il numero di nodi di calcolo disponibili per il test era 16, quando era necessario un numero maggiore di thread, tali thread erano distribuiti equamente sui nodi di calcolo (ad esempio, 32 thread = 2 thread per nodo, 64 thread = 4 thread per nodo, 128 thread = 8 thread per nodo, 256 thread =16 thread per nodo, 512 thread = 32 thread per nodo, 1024 thread = 64 thread per nodo). L'intenzione era quella di simulare un numero più elevato di client simultanei con il numero limitato di nodi di elaborazione. Poiché i benchmark supportano un numero elevato di thread, è stato utilizzato un valore massimo fino a 1024 (specificato per ogni test), evitando al contempo un eccessivo cambio di contesto e altri effetti collaterali correlati che influiscano sui risultati delle prestazioni.
  
  Tabella 2 Banco di prova del cliente

  Numero di nodi client	16
  Nodo client	C6320
  Processori per nodo client	2 Intel(R) Xeon(R) Gold E5-2697v4 18 core a 2,3 GHz
  Memoria per nodo client	12 RDIMM da 16 GiB e 2.400 MT/s
  BIOS	2.8.0
  OS Kernel	3.10.0-957.10.1
  Versione di GPFS	5.0.3

   

  ---

  Prestazioni IOzone sequenziali da N client a N file

  Le prestazioni sequenziali da N client a N file sono state misurate con IOzone versione 3.487. I test eseguiti variavano da un singolo thread fino a 1024 thread. 
  Gli effetti di memorizzazione nella cache sono stati ridotti al minimo impostando il pool di pagine GPFS regolabile su 16 GiB e utilizzando file di dimensioni due volte superiori. È importante notare che per GPFS tale tunable imposta la quantità massima di memoria utilizzata per la memorizzazione nella cache dei dati, indipendentemente dalla quantità di RAM installata e libera. Inoltre, è importante notare che, mentre nelle precedenti soluzioni HPC Dell EMC la dimensione dei blocchi per i trasferimenti sequenziali di grandi dimensioni era di 1 MiB, GPFS era formattato con blocchi di 8 MiB e quindi tale valore viene utilizzato nel benchmark per ottenere prestazioni ottimali. Potrebbe sembrare troppo grande e apparire come un eccessivo spreco di spazio, ma GPFS utilizza l'allocazione dei sottoblocchi per evitare questa situazione. Nella configurazione corrente, ogni blocco era suddiviso in 256 sottoblocchi da 32 KiB ciascuno. 
  I comandi seguenti sono stati usati per eseguire il benchmark per scritture e letture, dove Threads era la variabile con il numero di thread usati (da 1 a 1024 incrementati in potenze di due) e threadlist era il file che allocava ogni thread in un nodo diverso, usando round robin per distribuirli in modo omogeneo tra i 16 nodi di calcolo.

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

  
  Figura 2.  Prestazioni
  
  
  sequenziali da N a N Dai risultati possiamo osservare che le prestazioni aumentano molto velocemente con il numero di client utilizzati e quindi raggiungono un plateau stabile fino a raggiungere il numero massimo di thread consentiti da IOzone, e quindi le prestazioni sequenziali dei file di grandi dimensioni sono stabili anche per 1024 client simultanei. Si noti che le massime prestazioni di lettura erano di 23 GB/s a 32 thread e molto probabilmente il collo di bottiglia era l'interfaccia EDR InfiniBand, mentre gli array ME4 avevano ancora alcune prestazioni aggiuntive disponibili. Allo stesso modo, si noti che le massime prestazioni di scrittura di 16,7 sono state raggiunte un po' presto a 16 thread ed è apparentemente bassa rispetto alle specifiche degli array ME4.
  In questo caso è importante ricordare che la modalità di funzionamento preferita di GPFS è distribuita e che la soluzione è stata formattata per utilizzarla. In questa modalità, i blocchi vengono allocati fin dall'inizio in modo pseudo-casuale, distribuendo i dati sull'intera superficie di ciascun HDD. Sebbene l'ovvio svantaggio sia una riduzione delle prestazioni massime iniziali, tali prestazioni vengono mantenute piuttosto costanti indipendentemente dalla quantità di spazio utilizzato nel file system. Quindi, a differenza di altri file system paralleli che inizialmente utilizzano le tracce esterne in grado di contenere più dati (settori) per rivoluzione del disco e pertanto hanno le massime prestazioni possibili che gli HDD possono fornire, a mano a mano che il sistema utilizza più spazio, vengono utilizzate tracce interne con meno dati per rivoluzione, con la conseguente riduzione delle prestazioni. 
  
   

  ---

  Prestazioni IOR sequenziali da N client a 1 file

  Le sequenziali da N client a un singolo file condiviso sono state misurate con IOR versione 3.3.0, assistita da OpenMPI v4.0.1, per eseguire il benchmark sui 16 nodi di elaborazione. I test eseguiti variavano da un singolo thread fino a 1024 thread.
  Gli effetti di memorizzazione nella cache sono stati ridotti al minimo impostando il pool di pagine GPFS regolabile su 16 GiB e utilizzando file di dimensioni due volte superiori. Questo test di benchmark ha utilizzato block da 8 MiB per prestazioni ottimali. La precedente sezione relativa al test delle prestazioni fornisce una spiegazione più completa di tali questioni. 
  I seguenti comandi sono stati usati per eseguire il benchmark per scritture e letture, dove Threads era la variabile con il numero di thread usati (da 1 a 1024 incrementati in potenze di due) e my_hosts.$Threads è il file corrispondente che ha allocato ogni thread in un nodo diverso, usando Round Robin per distribuirli in modo omogeneo tra i 16 nodi di calcolo.

  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

  
  
  Figura 3. Prestazioni
  
  sequenziali da N a 1 Dai risultati possiamo osservare che le prestazioni aumentano di nuovo molto velocemente con il numero di client utilizzati e quindi raggiungono un plateau che è semi-stabile per le letture e molto stabile per le scritture, fino al numero massimo di thread utilizzati in questo test. Pertanto, le prestazioni sequenziali di un singolo file condiviso di grandi dimensioni sono stabili anche per 1.024 client simultanei. Si noti che le massime prestazioni di lettura erano di 23,7 GB/s a 16 thread e molto probabilmente il collo di bottiglia era l'interfaccia EDR InfiniBand, mentre gli array ME4 avevano ancora alcune prestazioni aggiuntive disponibili. Inoltre, le prestazioni di lettura sono diminuite da tale valore fino a raggiungere il plateau a circa 20,5 GB/s, con una diminuzione momentanea a 18,5 GB/s a 128 thread. Allo stesso modo, si noti che le massime prestazioni di scrittura di 16,5 sono state raggiunte a 16 thread e sono apparentemente basse rispetto alle specifiche degli array ME4.
   

  ---

  Prestazioni IOzone per piccoli blocchi casuali da N client a N file

  Le prestazioni da N client casuali a N file sono state misurate con IOzone versione 3.487. I test eseguiti variavano da un singolo thread fino a 1024 thread. Questo test di benchmark ha utilizzato blocchi da 4 KiB per emulare il traffico di blocchi di piccole dimensioni.
  Gli effetti di memorizzazione nella cache sono stati ridotti al minimo impostando il pool di pagine GPFS regolabile su 16 GiB e utilizzando file di dimensioni due volte superiori. La prima sezione del test delle prestazioni ha una spiegazione più completa del motivo per cui questo è efficace su GPFS. 
  Il comando seguente è stato utilizzato per eseguire il benchmark in modalità I/O casuale sia per le scritture che per le letture, dove Threads era la variabile con il numero di thread usati (da 1 a 1024 incrementati in potenze di due) e threadlist era il file che allocava ogni thread in un nodo diverso, usando Round Robin per distribuirli in modo omogeneo tra i 16 nodi di calcolo.

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

  
  Figura 4.  Prestazioni
  
  casuali da N a N Dai risultati si può osservare che le prestazioni di scrittura partono da un valore elevato di quasi 8.200 IOPS e aumentano costantemente fino a 128 thread, dove raggiungono un plateau e rimangono vicine al valore massimo di 16.200 IOPS. Le prestazioni di lettura, d'altra parte, partono da dimensioni molto ridotte a oltre 200 IOPS e aumentano quasi linearmente con il numero di client utilizzati (tenere presente che il numero di thread viene raddoppiato per ogni data point) e raggiungono le prestazioni massime di 20,4K IOPS a 512 thread senza segni di raggiungere il massimo. Tuttavia, l'utilizzo di più thread sui 16 nodi di calcolo correnti con due CPU ciascuno e in cui ogni CPU ha 18 core, presenta la limitazione che non sono presenti core sufficienti per eseguire il numero massimo di thread IOzone (1024) senza incorrere nel cambio di contesto (16 x 2 x 18 = 576 core), il che limita notevolmente le prestazioni. Un test futuro con più nodi di calcolo potrebbe verificare le prestazioni di lettura casuale che è possibile ottenere con 1024 thread con IOzone, oppure IOR potrebbe essere utilizzato per analizzare il comportamento con più di 1024 thread.
  
   

  ---

  Prestazioni dei metadati con MDtest utilizzando file vuoti

  Le prestazioni dei metadati sono state misurate con MDtest versione 3.3.0, assistita da OpenMPI v4.0.1, per eseguire il benchmark sui 16 nodi di elaborazione. I test eseguiti variavano da un singolo thread fino a 512 thread. Il benchmark è stato utilizzato solo per i file (senza metadati di directory), ottenendo il numero di creazioni, statistiche, letture e rimozioni che la soluzione è in grado di gestire.
  Per valutare correttamente la soluzione rispetto ad altre soluzioni di storage HPC Dell EMC, è stato utilizzato il modulo di metadati High Demand opzionale, ma con un singolo array ME4024, anche la configurazione di grandi dimensioni testata in questo lavoro è stata designata per avere due ME4024. 
  Questo modulo metadati high demand può supportare fino a quattro array ME4024 e si consiglia di aumentare il numero di array ME4024 a 4 prima di aggiungere un altro modulo metadati. Si prevede che gli array ME4024 aggiuntivi aumentino le prestazioni dei metadati in modo lineare con ogni array aggiuntivo, ad eccezione forse delle operazioni Stat (e delle letture per i file vuoti). Poiché i numeri sono molto alti, a un certo punto le CPU diventeranno un collo di bottiglia e le prestazioni non continueranno ad aumentare in modo lineare.
  Il comando seguente è stato utilizzato per eseguire il benchmark, dove Threads era la variabile con il numero di thread utilizzati (da 1 a 512 incrementati in potenze di due) e my_hosts.$Threads era il file corrispondente che allocava ogni thread in un nodo diverso, utilizzando Round Robin per distribuirli in modo omogeneo tra i 16 nodi di elaborazione. Analogamente al benchmark di IO casuale, il numero massimo di thread è stato limitato a 512, poiché non sono presenti core sufficienti per 1024 thread e il cambio di contesto avrebbe influito sui risultati, riportando un numero inferiore rispetto alle prestazioni reali della soluzione.

  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

  
  Poiché i risultati delle prestazioni possono essere influenzati dal numero totale di IOPS, dal numero di file per directory e dal numero di thread, si è deciso di mantenere fisso il numero totale di file a 2 MiB (2^21 = 2097152), il numero di file per directory fisso a 1024 e il numero di directory variava al variare del numero di thread, come illustrato nella Tabella 3.
  
  Tabella 3.  Distribuzione MDtest dei file nelle directory

  Numero di thread	Numero di directory per thread	Numero totale di file
  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

  
  
  
  
  Figura 5. Prestazioni dei metadati - File
  
  vuoti Innanzitutto, si noti che la scala scelta era logaritmica con base 10, per consentire di confrontare operazioni che presentano differenze di diversi ordini di grandezza; In caso contrario, alcune operazioni apparirebbero come una linea piatta vicina a 0 su un grafico normale. Un grafico logaritmico in base 2 potrebbe essere più appropriato, dal momento che il numero di thread è aumentato in potenze di 2, ma il grafico sarebbe abbastanza simile e le persone tendono a gestire e ricordare numeri migliori basati su potenze di 10.
  
  
  Il sistema ottiene ottimi risultati con le operazioni Stat e Read che raggiungono il loro valore di picco a 64 thread con 11,2 milioni di op/s e 4,8 milioni di op/s rispettivamente. Le operazioni di rimozione hanno raggiunto il massimo di 169,4K op/s a 16 thread e le operazioni di creazione hanno raggiunto il picco a 512 thread con 194,2K op/s. Le operazioni di statistica e lettura hanno più variabilità, ma una volta raggiunto il valore di picco, le prestazioni non scendono al di sotto di 3 milioni op/s per le statistiche e di 2 milioni op/s per le letture. La creazione e la rimozione sono più stabili una volta raggiunto un plateau e rimangono al di sopra di 140.000 operazioni/s per la rimozione e 120.000 operazioni/s per la creazione.
   

  ---

  Prestazioni dei metadati con MDtest con file da 4 KiB

  Questo test è quasi identico al precedente, tranne per il fatto che, anziché file vuoti, sono stati utilizzati file vuoti di piccole dimensioni da 4 KiB. 
  Il comando seguente è stato utilizzato per eseguire il benchmark, dove Threads era la variabile con il numero di thread utilizzati (da 1 a 512 incrementati in potenze di due) e my_hosts.$Threads era il file corrispondente che allocava ogni thread in un nodo diverso, utilizzando Round Robin per distribuirli in modo omogeneo tra i 16 nodi di elaborazione.

  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

  
  Figura 6.  Prestazioni dei metadati - File di piccole dimensioni (4K)
  
  Il sistema ottiene ottimi risultati per le operazioni di statistica e rimozione, raggiungendo il loro valore di picco a 128 thread con 7,7 milioni di op/s e 1 milione di op/s rispettivamente. Le operazioni di rimozione hanno raggiunto il massimo di 37,3K op/s e le operazioni di creazione hanno raggiunto il picco con 55,5K OP/s, entrambe a 512 thread. Le operazioni di statistiche e rimozioni hanno una maggiore variabilità, ma una volta raggiunto il loro valore massimo, le prestazioni non scendono al di sotto di 4 milioni di operazioni/s per le statistiche e 200.000 operazioni/s per la rimozione. La creazione e la lettura hanno meno variabilità e continuano ad aumentare al crescere del numero di thread.
  Poiché questi numeri si riferiscono a un modulo di metadati con un singolo ME4024, le prestazioni aumenteranno per ogni array ME4024 aggiuntivo, tuttavia non possiamo semplicemente ipotizzare un aumento lineare per ogni operazione. A meno che l'intero file non si adatti all'interno dell'inode per tale file, le destinazioni dei dati sui sistemi ME4084s verranno utilizzate per archiviare i file 4K, limitando in qualche modo le prestazioni. Poiché la dimensione degli inode è di 4 KiB e deve comunque archiviare i metadati, solo i file intorno a 3 KiB si adattano all'interno e qualsiasi file di dimensioni superiori utilizzerà le destinazioni di dati.
   

  ---

  Prestazioni dei metadati utilizzando MDtest con file 3K

  Questo test è quasi identico ai precedenti, tranne per il fatto che sono stati utilizzati piccoli file da 3KiB. La differenza principale è che questi file si inseriscono completamente all'interno dell'inode. Pertanto, gli storage node e i rispettivi ME4084 non vengono utilizzati, migliorando la velocità complessiva utilizzando solo supporti SSD per lo storage e meno accessi alla rete. 
  Il comando seguente è stato utilizzato per eseguire il benchmark, dove Threads era la variabile con il numero di thread utilizzati (da 1 a 512 incrementati in potenze di due) e my_hosts.$Threads era il file corrispondente che allocava ogni thread in un nodo diverso, utilizzando Round Robin per distribuirli in modo omogeneo tra i 16 nodi di elaborazione.

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

   

  
  Figura 7. Prestazioni dei metadati - File di piccole dimensioni (3K)
  
  Il sistema ottiene ottimi risultati per le operazioni Stat e Read, raggiungendo il valore di picco a 256 thread rispettivamente con 8,29 milioni di op/s e 5,06 milioni di op/s. Le operazioni di rimozione hanno raggiunto il massimo di 609.000 operazioni/s a 128 thread e le operazioni di creazione hanno raggiunto il picco con 78.000 operazioni/s a 512 thread. Le operazioni di statistica e lettura presentano una variabilità maggiore rispetto alla creazione e alla rimozione. La rimozione ha un piccolo calo delle prestazioni per i due punti di thread più alti, suggerendo che le prestazioni sostenute dopo 128 thread saranno leggermente superiori a 400.000 op/s. Le creazioni hanno continuato ad aumentare fino a 512 thread, ma sembra che stiano raggiungendo un plateau, quindi le prestazioni massime potrebbero essere ancora inferiori a 100K op/s.
  Poiché file di piccole dimensioni come questi vengono archiviati completamente nel modulo di metadati basato su SSD, le applicazioni che richiedono prestazioni superiori per i file di piccole dimensioni possono utilizzare uno o più moduli di metadati opzionali con elevata richiesta per aumentare le prestazioni dei file di piccole dimensioni. Tuttavia, i file che si adattano all'inode sono minuscoli per gli standard attuali. Inoltre, poiché le destinazioni dei metadati utilizzano RAID1 con SSD relativamente piccoli (la dimensione massima è 19,2 TB), la capacità sarà limitata rispetto agli storage node. Pertanto, è necessario prestare attenzione per evitare di riempire le destinazioni dei metadati, che possono causare errori non necessari e altri problemi.
   

  ---

  Advanced Analytics

  Tra le funzionalità di PixStor, il monitoraggio del file system tramite analisi avanzate può essere essenziale per semplificare notevolmente l'amministrazione, contribuendo a trovare problemi o potenziali problemi in modo proattivo o reattivo. Successivamente, esamineremo brevemente alcune di queste funzionalità.
  La Figura 8 mostra informazioni utili in base alla capacità del file system. Sul lato sinistro, lo spazio totale utilizzato dal file system e i primi dieci utenti in base alla capacità del file system utilizzata. Sul lato destro, una vista cronologica con la capacità utilizzata per molti anni, quindi i primi dieci tipi di file utilizzati e i primi dieci fileset, entrambi basati sulla capacità utilizzata, in un formato simile ai grafici di Pareto (senza le linee per i totali cumulativi). Con queste informazioni, può essere facile trovare gli utenti che ottengono più della loro giusta quota di file system, le tendenze di utilizzo della capacità per aiutare le decisioni sulla futura crescita della capacità, quali file utilizzano la maggior parte dello spazio o quali progetti richiedono la maggior parte della capacità.
  
  
  Figura 8.  PixStor Analytics - Vista
  
  Capacità La Figura 9 fornisce una vista di conteggio dei file con due modi molto utili per individuare i problemi. La prima metà della schermata mostra i primi dieci utenti in un grafico a torta e i primi dieci tipi di file e i primi dieci fileset (si pensi ai progetti) in un formato simile ai grafici di Pareto (senza le righe per i totali cumulativi), il tutto basato sul numero di file. Queste informazioni possono essere utilizzate per rispondere ad alcune domande importanti. Ad esempio, gli utenti che monopolizzano il file system creando troppi file, il tipo di file che crea un incubo dei metadati o i progetti che utilizzano la maggior parte delle risorse.
  La metà inferiore contiene un istogramma con il numero di file (frequenza) per le dimensioni dei file utilizzando 5 categorie per le diverse dimensioni dei file. Questo può essere utilizzato per avere un'idea delle dimensioni dei file utilizzate nel file system, che coordinate con i tipi di file possono essere utilizzate per decidere se la compressione sarà vantaggiosa.
  
  
  Figura 9.  PixStor Analytics - Vista conteggio file

  
  
   

  ---

  Conclusioni e lavoro futuro

  La soluzione attuale è stata in grado di fornire prestazioni abbastanza buone, che dovrebbero essere stabili indipendentemente dallo spazio utilizzato (poiché il sistema è stato formattato in modalità sparsa), come si può vedere nella Tabella 4. Inoltre, la soluzione è scalabile in modo lineare in termini di capacità e prestazioni a mano a mano che vengono aggiunti più moduli di storage node e si può prevedere un aumento delle prestazioni simile dal modulo metadati high demand opzionale. Questa soluzione fornisce ai clienti HPC un file system parallelo molto affidabile utilizzato da molti dei primi 500 cluster HPC. Inoltre, fornisce eccezionali funzionalità di ricerca, monitoraggio e gestione avanzati e l'aggiunta di gateway opzionali consente la condivisione di file tramite protocolli standard onnipresenti come NFS, SMB e altri a tutti i client necessari.
  
  Tabella 4  Prestazioni di picco e sostenute
  
   

  	Prestazioni di picco		Prestazioni sostenute
  	Scrittura	Lettura	Scrittura	Lettura
  Sequenziali di grandi dimensioni da N client a N file	16,7 GB/s	23 GB/s	16,5 GB/s	20,5 GB/s
  Sequenziali di grandi dimensioni da N client a file singolo condiviso	16,5 GB/s	23,8 GB/s	16,2 GB/s	20,5 GB/s
  Blocchi casuali di piccole dimensioni da N client a N file	15.8KIOps	20.4KIOps	15.7KIOps	20.4KIOps
  File vuoti per creazione di metadati	169.400 IOPS		127,2K IOps
  File vuoti per statistiche di metadati	11,2 milioni di IOps		3,3 milioni di IOps
  File vuoti per lettura di metadati	4,8 milioni di IOps		2,4 milioni di IOPS
  File vuoti per rimozione di metadati	194,2.200 IOps		144,8K IOps
  File da 4KiB per creazione di metadati	55,4K IOps		55,4K IOps
  File da 4KiB per statistiche di metadati	6,4 milioni di IOps		4 milioni di IOps
  File da 4KiB per lettura di metadati	37.300 IOps		37.300 IOps
  File da 4KiB per rimozione di metadati	1 milione di IOps		219.500 IOps

  
  
  Poiché la soluzione è destinata al rilascio con CPU Cascade Lake e RAM più veloce, una volta completata la configurazione finale del sistema, verranno eseguiti alcuni controlli a campione delle prestazioni. Inoltre, il test del modulo opzionale di metadati high demand con almeno 2 ME4024s e file da 4KiB è necessario per documentare meglio il modo in cui le prestazioni dei metadati vengono scalate quando sono coinvolti destinazioni di dati. In più, le prestazioni per i nodi gateway verranno misurate e segnalate insieme a eventuali risultati pertinenti dai controlli a campione in un nuovo blog o in un white paper. Infine, è previsto il test e il rilascio di un maggior numero di componenti della soluzione per fornire funzionalità ancora maggiori.

  ---