PowerScale, Isilon OneFS: Test delle prestazioni HBase su Isilon (in inglese)

Introduzione

Abbiamo effettuato una serie di test di benchmarking delle prestazioni su un cluster Isilon X410 utilizzando la suite di benchmarking YCSB e CDH 5.10.

L'ambiente POC Lab CAE è stato configurato con 5 nodi Isilon x410 che eseguono OneFS 8.0.0.4 e versioni successive 8.0.1.1 Benchmark di streaming di block di grandi dimensioni NFS dovrebbe aspettarsi 5x ~700 MB/s scritture (3,5 GB/s) e 5x ~1 GB/s letture (5 GB/s) per i nostri massimi aggregati teorici in uno di questi test.

I (9) nodi di elaborazione sono server Dell PowerEdge FC630 con CentOS 7.3.1611 ciascuno configurato con 2 CPU Intel Xeon® da 18 C/36 TB E5-2697 v4 a 2,3 GHz con 512 GB di RAM. Lo storage locale è 2XSSD in RAID 1 formattato come XFS sia per il sistema operativo che per i file con spazio scratch/versamento di liquidi.

Sono stati utilizzati anche tre server edge aggiuntivi per gestire il carico YCSB.

La rete back-end tra i nodi di elaborazione e Isilon è di 10 Gbps con set di frame Jumbo (MTU=9162) per le NIC e le porte dello switch.

Test iniziale

La prima serie di test ha dovuto determinare i parametri rilevanti sul lato HBASE che hanno interessato l'output complessivo. Abbiamo utilizzato lo strumento YCSB per generare il carico per HBASE. Questo test iniziale è stato eseguito utilizzando un singolo client (edge server) utilizzando la fase di "caricamento" di YCSB e 40 milioni di righe. Questa tabella è stata eliminata prima di ogni esecuzione.
 

ycsb load hbase10 -P workloads/workloada1 -p table='ycsb_40Mtable_nr' -p columnthread=family -threads 256 -p recordcount=40000000

hbase.regionserver.maxlogs - Numero massimo di file WAL (Write-Ahead Log). Questo valore moltiplicato per la dimensione block HDFS (dfs.blocksize) è la dimensione del WAL che deve essere riprodotto in caso di arresto anomalo di un server. Questo valore è inversamente proporzionale alla frequenza di svuotamento sul disco.

hbase.wal.regiongrouping.numgroups - Quando si utilizza più HDFS WAL come WALProvider, imposta il numero di log write-ahead che ogni server regionale deve eseguire. Genera questo numero di pipeline HDFS. Le scritture per una determinata regione passano a una singola pipeline, distribuendo il carico totale di RegionServer.

La filosofia qui era quella di parallelizzare il maggior numero di scritture possibile, aumentando quindi il numero di WAL e quindi il numero di thread (pipeline) per OGNI WAL. I due grafici precedenti mostrano che per un determinato numero di "maxlogs" 128 o 256 non vediamo alcun cambiamento reale che indichi che non stiamo davvero spingendo questo numero dal lato client. O variando il numero di "pipeline" per file, vediamo la tendenza che indica il parametro sensibile alla parallelizzazione. La domanda successiva è quindi: in che modo Isilon "ostacola la strada" con I/O del disco, rete, CPU o OneFS e possiamo esaminare il report delle statistiche di Isilon.


 
I grafici di rete e CPU indicano che il cluster Isilon è sottoutilizzato e ha margine di lavoro. La CPU sarebbe > l'80% e la larghezza di banda di rete sarebbe superiore a 3 GB/s.



Questi grafici mostrano le statistiche del protocollo HDFS e il modo in cui vengono tradotte da OneFS. Le operazioni HDFS sono multipli di dfs.blocksize di 256 MB qui. L'aspetto interessante in questo caso è che il grafico "Heat" mostra le operazioni dei file OneFS e si può vedere la correlazione di scritture e blocchi. In questo caso, HBase aggiunge al WAL in modo che OneFS blocchi il file WAL per ogni scrittura aggiunta. Questo è ciò che ci aspettiamo per scritture stabili su un file system in cluster. Sembra che questi fattori contribuiscano al fattore limitante in questa serie di test.

Aggiornamenti HBase

Questo test successivo doveva fare qualche altro esperimento per trovare cosa succede su larga scala, quindi ho creato una tabella da un miliardo di righe, che ha richiesto un'ora utile per la generazione, e poi ho eseguito un'esecuzione YCSB che ha aggiornato 10 milioni di righe utilizzando le impostazioni "workloada" (50/50 lettura/scrittura). Questa operazione è stata eseguita su un singolo client e cercavo anche il throughput più elevato che potrei generare, quindi l'ho eseguito come funzione del numero di thread YCSB. Un'altra nota è che abbiamo ottimizzazione di Isilon e siamo passati a OneFS 8.0.1.1 con modifiche delle prestazioni per il servizio data node. È possibile riscontrare un aumento delle prestazioni rispetto al set di esecuzioni precedente. Per queste esecuzioni, abbiamo impostato hbase.regionserver.maxlogs = 256 e hbase.wal.regiongrouping.numgroups = 20

Osservando queste esecuzioni, la prima cosa evidente è la caduta in un numero elevato di thread. Mi interessava se si trattasse di un problema di Isilon o lato client. Nei prossimi paragrafi vediamo alcuni ulteriori test in merito. Ma posso dire che promuovere oltre 200.000 Ops con una latenza di aggiornamento di < 3 ms è impressionante. Ciascuno di questi aggiornamenti è stato eseguito in modo rapido ed è stato possibile eseguirli uno dopo l'altro e il grafico seguente mostra il bilanciamento uniforme tra i nodi Isilon per queste esecuzioni.



Anche in questo caso, è possibile vedere dal grafico Heat che le operazioni di file sono scritture e blocchi corrispondenti alla natura aggiunta dei processi WAL.

Dimensionamento dei server dell'area geografica

Il test successivo è stato quello di determinare il prezzo dei nodi Isilon (cinque di essi) rispetto a un numero diverso di server dell'area geografica. Lo stesso script di aggiornamento eseguito nel test precedente è stato eseguito qui. Una tabella da un miliardo di righe e 10 milioni di righe aggiornate utilizzando "workloada" con un singolo client e thread YCSB a 51, abbiamo inoltre mantenuto la stessa impostazione su maxlog e pipeline (rispettivamente 256 e 20).

 
I risultati sono informativi, anche se non sorprendenti. La natura scale-out di HBase si combina con la natura scale-out di Isilon e altro ancora,meglio. Si tratta di un test che consiglio ai clienti di eseguire sui propri ambienti nell'ambito del proprio esercizio di dimensionamento. Potrebbe arrivare a un punto di diminuzione dei ritorni, ma qui abbiamo nove server pesanti che spingono cinque nodi Isilon e sembra che ci sia spazio per ulteriori informazioni.

Più client

L'ultima serie di test viene svolta da quella sede scura profonda che fa si desidera rompere il sistema che si sta testando. Dopo tutto, è un metodo scientifico perfettamente valido per eseguire un test fino a quando le cose non si rompono e in questo modo si conosce il limite superiore dei parametri testati. In questa serie di test, disponevo di due server aggiuntivi da cui poter eseguire il client, inoltre ho eseguito due client YCSB su ciascuno di essi, consentendomi di eseguire lo scale-up fino a sei client ciascuno con 512 thread, che sarebbero stati 4.096 thread complessivi. Sono tornato indietro e ho creato due tabelle diverse, una con 4 miliardi di righe suddivise in 600 regioni e una con 400milioni di righe suddivise in 90 regioni.  

 



 

Come si può vedere, le dimensioni della tabella sono poco importanti in questo test. Esaminando nuovamente i grafici Heat di Isilon, si può notare una differenza percentuale nel numero di operazioni di file per lo più in linea con le differenze tra una tabella da quattro miliardi di righe a 400 milioni di righe.

Conclusione

HBase è un ottimo candidato per l'esecuzione su Isilon, soprattutto per via delle architetture scale-out a scale-out. HBase esegue gran parte della propria memorizzazione nella cache e divide la tabella in un buon numero di aree geografiche in cui è possibile eseguire lo scale-out di HBase con i dati. In altre parole, fa un buon lavoro nell'occuparsi delle proprie esigenze e il file system è lì per la persistenza. Non siamo stati in grado di spingere i test di carico fino al punto di rompere effettivamente le cose, ma se si esaminano quattro miliardi di righe nella progettazione di HBase e ci si aspetta 800.000 operazioni con meno di 3 ms di latenza, questa architettura lo supporta. Se non ho menzionato molto di più su una miriade di altre modifiche lato client che potreste applicare alla stessa HBase, mi aspetto che tutte queste modifiche siano ancora valide e che esulano dall'ambito di questo test.