Dell EMC Ready Solution for HPC PixStor Storage - Espansione della capacità (in inglese)

None

Sommario

1. Introduzione
   1. Architettura della soluzione
   2. Componenti della soluzione
2. Caratterizzazione delle prestazioni
   1. Client IOzone Performance N sequenziali a N file
   2. Client IOR Performance N sequenziali a 1 file
   3. Block casuali di piccole dimensioni client IOzone Performance N a N file
   4. Prestazioni dei metadati con MDtest utilizzando file vuoti
   5. Prestazioni dei metadati con MDtest con 4 file KiB
3. Conclusioni e lavoro futuro

 

---

Introduzione

Gli ambienti HPC odierni hanno aumentato la domanda di storage ad altissima velocità che spesso richiede anche capacità elevata e accesso distribuito tramite diversi protocolli standard come NFS, SMB e altri. I requisiti HPC ad alta domanda sono in genere coperti da file system paralleli che forniscono accesso simultaneo a un singolo file o a un set di file da più nodi, distribuendo in modo molto efficiente e sicuro i dati su più LUN su più server.

 

---

Architettura della soluzione

Questo blog è una prosecuzione della soluzione PFS (Parallel File System) per gli ambienti HPC, la Dell EMC Ready Solution for HPC PixStor Storage, in cui vengono utilizzati array EBOD PowerVault ME484 per aumentare la capacità della soluzione. Figura 1. presenta l'architettura di riferimento che illustra le aggiunte SAS di espansione della capacità agli array di storage PowerVault ME4084 esistenti.
La soluzione PixStor include il diffuso file system parallelo generale noto anche come Spectrum Scale come componente PFS, oltre a molti altri componenti software Arcastream come l'analisi avanzata, l'amministrazione e il monitoraggio semplificati, la ricerca efficiente dei file, le funzionalità gateway avanzate e molti altri.


Figura 1. Architettura di riferimento.

 

---

Componenti della soluzione

Questa soluzione è prevista per il rilascio con le più recenti CPU Xeon scalabili Intel Xeon di seconda generazione, ovvero CPU Cascade Lake e alcuni server utilizzeranno la RAM più veloce disponibile (2.933 MT/s). Tuttavia, a causa dell'hardware corrente disponibile per lavorare sul prototipo della soluzione per caratterizzare le prestazioni, i server con CPU Intel Xeon Xeon scalabili di 1a generazione, ovvero Per caratterizzare questo sistema sono stati utilizzati processori Skylake e, in alcuni casi, RAM più lenta. Poiché il collo di bottiglia della soluzione è nei controller SAS degli array Dell EMC PowerVault ME40x4, non ci si aspetta differenze significative in termini di prestazioni una volta che le CPU e la RAM Skylake vengono sostituite con le CPU Cascade Lake progettate e la RAM più veloce. Inoltre, la soluzione è stata aggiornata alla versione più recente di PixStor (5.1.1.4) che supporta RHEL 7.7 e OFED 4.7 per la caratterizzazione del sistema.

A causa della situazione descritta in precedenza, nella Tabella 1 è riportato l'elenco dei componenti principali della soluzione, ma quando sono state introdotte discrepanze, la prima colonna della descrizione include componenti utilizzati al momento della release e quindi disponibili ai clienti e l'ultima colonna sono i componenti effettivamente utilizzati per caratterizzare le prestazioni della soluzione. Le unità elencate per i dati (NLS da 12 TB) e i metadati (SSD da 960 Gb) sono quelle utilizzate per la caratterizzazione delle prestazioni e le unità più veloci possono fornire ioPS casuali migliori e possono migliorare le operazioni di creazione/rimozione dei metadati.

Infine, per completezza, è stato incluso l'elenco dei possibili HDD di dati e SSD di metadati, che si basa sulle unità supportate come enumerate nella Support Matrix di Dell EMC PowerVault ME4, disponibile online.

Tabella 1 Componenti utilizzati al momento di rilascio e quelli utilizzati nel banco di prova

Componente della soluzione		Al momento della release	Banco di prova
Connettività interna		Dell Networking S3048-ON Gigabit Ethernet
Sottosistema di storage dei dati		Da 1 a 4 Dell EMC PowerVault ME4084 Da 1 a 4 Dell EMC PowerVault ME484 (uno per ME4084) Da 80 a 12 TB di unità HDD NL SAS3 da 3,5" Opzioni di @15K da 900 GB, @10K da 1,2 TB, @10K da 1,8 TB, @10K da 2,4 TB, NLS da 4 TB, NLS da 8 TB, NLS da 10 TB, NLS da 12 TB.     8 LUN, RAID 6 lineare 8+2, dimensione blocco 512 KiB. 4 SSD SAS3 da 1,92 TB per metadati - 2 RAID 1 (o 4 - spare HDD globali, se viene utilizzato il modulo opzionale di metadati high-demand)
Sottosistema di storage di metadati ad alta domanda opzionale		Da 1 a 2 Dell EMC PowerVault ME4024 (4 ME4024 se necessario, solo configurazione di grandi dimensioni) 24 unità SSD SAS3 da 960 GB da 2,5" (opzioni 480 GB, 960 GB, 1,92 TB) 12 LUN, RAID lineare 1.
Controller di storage RAID		SAS da 12 Gbps
Capacità come configurato		Crudo: 8.064 TB (7.334 TiB o 7,16 PiB) formattato ~ 6144 GB (5.588 TiB o 5,46 PiB)
Processore	Gateway	2 Intel Xeon Gold 6230 da 2,1 G, 20 C/40 T, 10,4 GT/s, 27,5 MB di cache, Turbo, HT (125 W) DDR4-2933	N/D
	Metadati ad alta richiesta		2 Intel Xeon Gold 6136 a 3 GHz, 12 core
	Storage Node		2 Intel Xeon Gold 6136 a 3 GHz, 12 core
	Nodo di gestione	2 Intel Xeon Gold 5220 da 2,2 G, 18 C/36 T, 10,4 GT/s, 24,75 MB di cache, Turbo, HT (125 W) DDR4-2666	2 Intel Xeon Gold 5118 da 2,3 GHz, 12 core
Memoria	Gateway	12 RDIMM da 16 GiB a 2.933 MT/s (192 GiB)	N/D
	Metadati ad alta richiesta		24 RDIMM da 16 GiB a 2.666 MT/s (384 GiB)
	Storage Node		24 RDIMM da 16 GiB a 2.666 MT/s (384 GiB)
	Nodo di gestione	12 DIMM da 16 GB, 2.666 MT/s (192 GiB)	12 RDIMM da 8 GiB a 2.666 MT/s (96 GiB)
Sistema operativo		Red Hat Enterprise Linux 7.6	Red Hat Enterprise Linux 7.7
Versione del kernel		3.10.0-957.12.2.el7.x86_64	3,10,0 1062.9.1.el7.x86_64
PixStor Software		5.1.0.0	5.1.1.4
Scala dello spettro (GPFS)		5.0.3	5.0.4-2
Connettività di rete a prestazioni elevate		Mellanox ConnectX-5 Dual-Port InfiniBand EDR/100 GbE e 10 GbE	Mellanox ConnectX-5 InfiniBand EDR
Switch a prestazioni elevate		2 Mellanox SB7800 (HA - Ridondante)	1 Mellanox SB7700
Versione di OFED		Mellanox OFED-4.6-1.0.1.0	Mellanox OFED-4.7-3.2.9
Dischi locali (sistema operativo e analisi/monitoraggio)		Tutti i server eccetto il nodo di gestione 3 SSD SAS3 da 480 GB (RAID1 + HS) per il sistema operativo Controller RAID PERC H730P Nodo di gestione 3 SSD SAS3 da 480 GB (RAID1 + HS) per il sistema operativo Controller RAID PERC H740P	Tutti i server eccetto il nodo di gestione 2 SAS3 da 300 GB a 15.000 rpm (RAID 1) per sistema operativo Controller RAID PERC H330 Nodo di gestione 5 SAS3 da 300 GB a 15.000 rpm (RAID 5) per sistema operativo e analisi/monitoraggio Controller RAID PERC H740P
System management		iDRAC 9 Enterprise + Dell EMC OpenManage	iDRAC 9 Enterprise + Dell EMC OpenManage

 

---

Caratterizzazione delle prestazioni

Per caratterizzare questa nuova Ready Solution, abbiamo utilizzato l'hardware specificato nell'ultima colonna della Tabella 1, incluso il modulo opzionale di metadati high-demand. Per valutare le prestazioni della soluzione, sono stati utilizzati i seguenti benchmark:

• IOzone da N a N sequenziale
• IOR N a 1 sequenziale
• IOzone casuale
• Testdi MD

 Per tutti i benchmark elencati in precedenza, il banco di prova ha avuto i clienti come descritto nella Tabella 2 riportata di seguito. Poiché il numero di nodi di elaborazione disponibili per il test era di soli 16, quando era richiesto un numero più elevato di thread, questi thread venivano distribuiti equamente sui nodi di elaborazione (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, 1.024 thread = 64 thread per nodo). L'intenzione era 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 1.024 (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 client

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

 

---

Client IOzone Performance N sequenziali a N file

Le prestazioni dei client N sequenziali ai file N sono state misurate con IOzone versione 3.487. I test eseguiti variavano da un singolo thread a 1024 thread e i risultati della soluzione espansa della capacità (4 ME4084s + 4 ME484) sono in contrasto con la soluzione di grandi dimensioni (4 ME4084). 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 che regolano 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, sebbene nelle precedenti soluzioni HPC Dell EMC le dimensioni del blocco per i trasferimenti sequenziali di grandi dimensioni siano pari a 1 MiB, GPFS è stato formattato con block da 8 MiB e quindi tale valore viene utilizzato nel benchmark per prestazioni ottimali. Potrebbe sembrare troppo grande e apparentemente spreco di troppo spazio, ma GPFS utilizza l'allocazione dei sottoblocchi per evitare questa situazione. Nella configurazione corrente, ogni blocco è stato suddiviso in 256 sottoblocchi di 32 KiB ciascuno.

I seguenti comandi sono stati utilizzati per eseguire il benchmark per le scritture e le letture, dove Thread era la variabile con il numero di thread utilizzati (da 1 a 1024 incrementati in potenza di due) e threadlist era il file che allocato ogni thread su un nodo diverso, utilizzando round robin per distribuirli in modo omogeneo tra i 16 nodi di elaborazione.

./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 NDai risultati si può osservare che le prestazioni aumentano molto rapidamente con il numero di client utilizzati e quindi raggiungono un stabilizzatore che è stabile fino al raggiungimento del numero massimo di thread consentiti da IOzone e pertanto le prestazioni sequenziali dei file di grandi dimensioni sono stabili anche per 1024 client simultanei. Si noti che le prestazioni di lettura e scrittura hanno tratto vantaggio dal raddoppiamento del numero di unità. Le prestazioni massime di lettura sono state limitate dalla larghezza di banda dei due link EDR IB utilizzati negli storage node a partire da 8 thread e gli array ME4 potrebbero avere alcune prestazioni aggiuntive disponibili. Si noti inoltre che le prestazioni massime di scrittura sono aumentate da un massimo di 16,7 a 20,4 GB/s a 64 e 128 thread e sono più vicine alle specifiche massime degli array ME4 (22 GB/s).

In questo caso è importante ricordare che la modalità di funzionamento preferita da GPFS è sparse e la soluzione è stata formattata per utilizzare tale modalità. In questa modalità, i blocchi vengono allocati all'inizio del funzionamento in modo pseudo-casuale, diffondendo i dati su tutta la superficie di ogni HDD. Sebbene l'ovvio svantaggio sia una riduzione delle prestazioni massime iniziali, tale prestazioni viene mantenuta piuttosto costante indipendentemente dalla quantità di spazio utilizzato nel file system. 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, ma man mano che il sistema utilizza più spazio, vengono utilizzate tracce interne con meno dati per rivoluzione, con la conseguente riduzione delle prestazioni.

 

---

Client IOR Performance N sequenziali a 1 file

Le prestazioni dei client N sequenziali 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 thread fino a 512 thread (poiché non c'erano core sufficienti per 1024 thread) e i risultati sono in contrasto con la soluzione senza l'espansione della capacità.
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 del test delle prestazioni ha una spiegazione più completa di queste questioni.

I seguenti comandi sono stati utilizzati per eseguire il benchmark per le scritture e le letture, dove Thread era la variabile con il numero di thread utilizzati (da 1 a 1024 incrementati in potenza di due) e my_hosts.$Threads è il file corrispondente che allocato 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 --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 è possibile osservare nuovamente che le unità aggiuntive traggono vantaggio dalle prestazioni di lettura e scrittura. Le prestazioni aumentano di nuovo molto velocemente con il numero di client utilizzati e quindi raggiungono un indicatore abbastanza stabile per le letture e le scritture fino al numero massimo di thread utilizzati in questo test. Si noti che le massime prestazioni di lettura erano di 24,8 GB/s a 16 thread e il collo di bottiglia era l'interfaccia EDR InfiniBand, con gli array ME4 che avevano ancora alcune prestazioni aggiuntive disponibili. Da quel momento, le prestazioni di lettura sono diminuite da quel valore fino a raggiungere l'indicatore a circa 23,8 GB/s. Analogamente, si noti che le prestazioni massime di scrittura di 19,3 sono state raggiunte a 8 thread e hanno raggiunto un stabilizzatore.
 

---

Block casuali di piccole dimensioni client IOzone Performance N a N file

Le prestazioni dei client N casuali ai file N sono state misurate con FIO versione 3.7 anziché con la iozone tradizionale. L'intenzione, come elencato nel blog precedente, era quella di sfruttare una maggiore profondità della coda per esaminare le massime prestazioni possibili che gli array ME4084 sono in grado di offrire (i test precedenti per diverse soluzioni ME4 hanno mostrato che gli array ME4084 necessitano di una maggiore pressione I/O che Iozone è in grado di fornire per raggiungere i limiti di I/O casuali).

I test eseguiti variavano da un singolo thread a 512 thread poiché non erano presenti core client sufficienti per 1024 thread. A ogni thread veniva utilizzato un file diverso e ai thread veniva assegnato round robin sui nodi client. Questo test di benchmark ha utilizzato 4 block KiB per emulare il traffico di piccoli blocchi e utilizzare una profondità della coda di 16. Vengono confrontati i risultati della soluzione di grandi dimensioni e l'espansione della capacità.

Gli effetti di memorizzazione nella cache sono stati nuovamente ridotti a icona impostando il pool di pagine GPFS regolabile su 16 GiB e utilizzando i file due volte superiori alle dimensioni. La prima sezione del test delle prestazioni ha una spiegazione più completa del motivo per cui questo è efficace su GPFS.

 
Figura 4.  Prestazioni casuali

da N a N Dai risultati possiamo osservare che le prestazioni di scrittura partno da un valore elevato di 29.100 IOPS e aumentano costantemente fino a 64 thread in cui sembra raggiungere un picco di circa 40.000 IOPS. Le prestazioni di lettura, dall'altra parte, partno da 1,4.000 IOPS e aumentano le prestazioni quasi linearmente con il numero di client utilizzati (tenere presente che il numero di thread è raddoppiato per ogni data point) e raggiunge le prestazioni massime di 25.600 IOPS a 64 thread dove sembra essere vicino al raggiungimento di un punto di passaggio. L'utilizzo di più thread richiederà più dei 16 nodi di elaborazione per evitare l'carenza di risorse e prestazioni evidenti inferiori, in cui gli array potrebbero effettivamente mantenere le prestazioni.

 

---

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 a 512 thread. Il benchmark è stato utilizzato solo per i file (nessun metadato di directory), ottenendo il numero di creazioni, statistiche, letture e rimozioni che la soluzione è in grado di gestire e i risultati sono stati contrastati con la soluzione di grandi dimensioni.

Per valutare correttamente la soluzione rispetto ad altre soluzioni di storage HPC Dell EMC e ai risultati del blog precedente, è stato utilizzato il Modulo metadati ad alta domanda opzionale, ma con un singolo array ME4024, anche se la configurazione di grandi dimensioni e testata in questo lavoro è stata designata per avere due ME4024. Questo modulo di metadati ad alta domanda 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 di metadati. Si prevede che altri array ME4024 aumenteranno le prestazioni dei metadati in modo lineare con ogni array aggiuntivo, tranne forse per le operazioni di statistica (e letture per i file vuoti), poiché i numeri sono molto elevati, 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 Thread era la variabile con il numero di thread utilizzati (da 1 a 512 incrementati in potenza di due) e my_hosts.$Threads è il file corrispondente che ha allocato ogni thread in un nodo diverso, utilizzando round robin per distribuirli in modo omogeneo tra i 16 nodi di elaborazione. Analogamente al benchmark di I/O casuale, il numero massimo di thread è stato limitato a 512, poiché non sono presenti core sufficienti per 1024 thread e lo switching di contesto avrebbe influito sui risultati, segnalando 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, è stato deciso di mantenere fisso il numero totale di file in 2 file MiB (2^21 = 2097152), il numero di file per directory corretto in 1024 e il numero di directory modificato man mano che il numero di thread è cambiato, come illustrato nella Tabella 3.

Tabella 3:  Distribuzione MDtest dei file sulle 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

vuotiIn primo luogo, si noti che la scala scelta è stata logaritmica con base 10, per consentire il confronto di operazioni che presentano differenze di diversi ordini di grandezza; in caso contrario, alcune operazioni appaiono come una linea piatta vicina a 0 in un grafico normale. Un grafico di log con base 2 potrebbe essere più appropriato, poiché il numero di thread viene aumentato in potenza pari a 2, ma il grafico sarebbe molto simile e le persone tendono a gestire e ricordare numeri migliori in base a potenza di 10.
Il sistema ottiene ottimi risultati con le operazioni di statistica e lettura che raggiungono il valore di picco a 64 thread con quasi 11 milioni di operazioni/s e 4,7 milioni di operazioni rispettivamente. Le operazioni di rimozione hanno raggiunto il massimo di 170.600 op/s a 16 thread e creano operazioni che raggiungono il picco a 32 thread con 222,100 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 di operazioni per le statistiche e di 2 milioni di operazioni per le letture. La creazione e la rimozione sono più stabili una volta raggiunta una stabilizzazione e rimangono al di sopra di 140.000 op/s per la rimozione e 120.000 op/s per la creazione. Si noti che le unità aggiuntive non influiscono sulla maggior parte delle operazioni sui metadati su file vuoti come previsto.
 

---

Prestazioni dei metadati con MDtest con 4 file KiB

Questo test è quasi identico a quello precedente, tranne per il fatto che, anziché file vuoti, sono stati utilizzati file di piccole dimensioni da 4 KiB. 
Il comando seguente è stato utilizzato per eseguire il benchmark, dove Thread era la variabile con il numero di thread utilizzati (da 1 a 512 incrementati in potenza di due) e my_hosts.$Threads è il file corrispondente che ha allocato 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 che raggiungono il valore di picco a 256 thread con 8,2 milioni di operazioni e 400.000 op/s rispettivamente. Le operazioni di lettura hanno raggiunto il massimo di 44.800 op/s e creano operazioni che raggiungono il picco con 68.100 operazioni/s, entrambe a 512 thread. Le operazioni di statistica e rimozione presentano una maggiore variabilità, ma una volta raggiunto il valore di picco, le prestazioni non scendono al di sotto dei 3 milioni operativi per le statistiche e di 280.000 op/s per la rimozione. La creazione e la lettura hanno meno variabilità e continuano ad aumentare man mano che aumenta il numero di thread. Come si può osservare, le unità aggiuntive delle espansioni di capacità forniscono solo variazioni marginali nelle prestazioni dei metadati.
Poiché questi numeri sono per un modulo di metadati con un singolo ME4024, le prestazioni aumenteranno per ogni array ME4024 aggiuntivo, tuttavia non possiamo assumere 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 più grande di quello utilizzerà le destinazioni di dati.
 

---

Conclusioni e lavoro futuro

La soluzione con capacità estesa è stata in grado di migliorare le prestazioni, non solo per gli accessi casuali, ma anche per le prestazioni sequenziali. Questo è previsto dal momento che la modalità sparse si comporta come accessi casuali e avere più dischi consente di migliorare. Si prevede che tali prestazioni, che possono essere generali nella Tabella 4, siano stabili da un file system vuoto fino a quando non sono quasi piene. Inoltre, la soluzione è scalabile in modo lineare in termini di capacità e prestazioni man mano che vengono aggiunti più moduli di storage node e si può prevedere un aumento delle prestazioni simile dal modulo opzionale di metadati ad alta richiesta. 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 consentono la condivisione di file tramite protocolli standard onnipresenti come NFS, SMB e altri a tutti i client in base alle esigenze.

Tabella 4  Prestazioni sostenute e di picco

	Prestazioni di picco		Prestazioni sostenute
	Scrivere	Read	Scrivere	Read
Client N sequenziali di grandi dimensioni a file N	20,4 GB/s	24,2 GB/s	20,3 GB/s	24 GB/s
Client N sequenziali di grandi dimensioni per un singolo file condiviso	19,3 GB/s	24,8 GB/s	19,3 GB/s	23,8 GB/s
Block casuali di piccole dimensioni da N client a N file	40KIOps	25,6KIOps	40.0KIOps	19.3KIOps
Creazione di file vuoti di metadati	169.400 IOPS		123.500 IOPS
File vuoti delle statistiche dei metadati	11 milioni di IOPS		3,2 milioni di IOPS
Metadati Lettura file vuoti	4,7 milioni di IOPS		2,4 milioni di IOPS
Rimozione dei metadati di file vuoti	170.600 IOPS		156.500 IOPS
Creazione metadati di file da 4 KiB	68.100 IOPS		68.100 IOPS
Metadati Stat 4KiB file	8,2 milioni di IOPS		3 milioni di IOPS
File Metadata Read 4KiB	44.800 IOPS		44.800 IOPS
Rimozione dei metadati file da 4 KiB	400.000 IOPS		280.000 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, testare il modulo opzionale di metadati ad alta domanda con almeno 2 file ME4024s e 4KiB è necessario per documentare meglio il modo in cui le prestazioni dei metadati vengono scalate quando sono coinvolti destinazioni di dati. Inoltre, 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.