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

Non richiesto

Non richiesto

Introduzione

È stata eseguita 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 di test di laboratorio è stato configurato con cinque nodi Isilon x410 che eseguono OneFS v8.0.0.4 e versioni successive v8.0.1.1. Sono stati eseguiti benchmark di streaming NFS (Network File System) a blocchi di grandi dimensioni. Il valore massimo aggregato teorico previsto per i test era di ~700 MB/s (3,5 GB/s) in scrittura e ~1 GB/s in lettura (5 GB/s) per nodo.

I (9) nodi di elaborazione sono server Dell PowerEdge FC630 che eseguono CentOS v7.3.1611, ciascuno configurato con 2x18C/36T-Intel Xeon® CPU E5-2697 v4 @ 2,30 GHz con 512 GB di RAM. Lo storage locale è costituito da 2 SSD in RAID 1 formattati come XFS sia per il sistema operativo che per lo spazio di memoria o i file versati.

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

La rete back-end tra i nodi di calcolo e Isilon è di 10 Gbps con frame jumbo impostati (MTU=9162) per le schede di rete e le porte degli switch.
CDH 5.10 è stato configurato per l'esecuzione in una zona di accesso sull'Isilon Cluster. Gli account di servizio sono stati creati nel provider Isilon Local e localmente nei file /etc/passwd del client. Tutti i test sono stati eseguiti utilizzando un client di test di base senza privilegi speciali.

Le statistiche Isilon sono state monitorate sia con IIQ sia con il pacchetto Grafana/Data Insights. Le statistiche CDH sono state monitorate con Cloudera Manager e anche con Grafana.

Test iniziali

La prima serie di test consisteva nel determinare i parametri rilevanti sul lato HBASE che influivano sull'output complessivo. Lo strumento YCSB è stato utilizzato per generare il carico per HBASE. Questo test iniziale è stato eseguito utilizzando un singolo client (server edge) 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 columnfamily=family -threads 256 -p recordcount=40000000

• hbase.regionserver.maxlogs - Numero massimo di file di registro write-ahead (WAL): questo valore moltiplicato per HDFS Block Size (dfs.blocksize) è la dimensione del WAL che deve essere riprodotto in caso di arresto anomalo di un server. Questo valore è inversamente proporzionale alla frequenza degli scaricamenti sul disco.
• hbase.wal.regiongrouping.numgroups - Quando si utilizza Multiple HDFS WAL come WALProvider, viene impostato il numero di log write-ahead che ogni RegionServer deve eseguire. I risultati mostrano il numero di pipeline HDFS. Le scritture per una determinata regione vengono eseguite solo in una singola pipeline, distribuendo il carico totale di RegionServer.

   
La filosofia qui è stata quella di parallelizzare il maggior numero possibile di scritture. A tale scopo si ottiene aumentando il numero di WAL e quindi il numero di thread (pipeline) per WAL. I due grafici precedenti mostrano che per un dato numero di 'maxlog', 128 o 256, non viene mostrato alcun cambiamento reale. Ciò indica che il test non sta realmente influenzando i risultati dal lato client. Il numero di "pipeline" per file è stato variato, mostrando una tendenza che indica il parametro sensibile alla parallelizzazione. La domanda successiva è: dove un Isilon cluster "si intromette?" con I/O del disco, rete, CPU o OneFS? Per rispondere a questa domanda, consultare il report statistico Isilon.
I grafici della rete e della CPU indicano che il cluster Isilon è sottoutilizzato e ha spazio per ulteriori attività. La CPU sarebbe dell > 80% e la larghezza di banda della rete sarebbe superiore a 3 GB/s.
 
Questi grafici mostrano le statistiche del protocollo HDFS e il modo in cui OneFS converte l'output. Le operazioni HDFS sono multipli di dfs.blocksize che in questo caso è di 256 MB. L'aspetto interessante è che il grafico "Heat" mostra le operazioni su file OneFS e viene visualizzata la correlazione tra scritture e blocchi. In questo caso, HBase esegue aggiunte ai WAL, quindi OneFS blocca il file WAL per ogni scrittura accodata. Che è ciò che ci si aspetta per le scritture stabili in un file system cluster. Questi sembrerebbero contribuire al fattore limitante in questa serie di test.

Aggiornamenti HBase

Il test successivo consisteva nel fare più esperimenti per scoprire cosa succede su larga scala. Viene creata una tabella da 1 miliardo di righe la cui generazione ha richiesto un'ora. Viene eseguito un test YCSB che aggiorna 10 milioni di righe utilizzando le impostazioni "workloada" (lettura/scrittura 50/50). Questo test è stato eseguito su un singolo client. Il test è stato eseguito in funzione del numero di thread YCSB in modo da poter generare la maggior parte del throughput. Inoltre, sono state applicate alcune ottimizzazioni e OneFS è stato aggiornato alla versione 8.0.1.1, con modifiche alle prestazioni per il servizio del nodo dati. Il grafico seguente mostra l'aumento delle prestazioni rispetto al set di esecuzioni precedente. Per queste esecuzioni, hbase.regionserver.maxlogs è impostato su 256 e hbase.wal.regiongrouping.numgroups su 20.    
L'analisi di queste esecuzioni di test mostra un apparente calo in caso di numero elevato di thread, che può essere un problema di Isilon o del lato client. I test mostrano e impressionano 200 mila operazioni al secondo con una latenza di aggiornamento di < 3 ms. Ogni test di aggiornamento è stato veloce e poteva essere eseguito in modo consecutivo. Il grafico seguente mostra un bilanciamento uniforme tra i nodi Isilon per ogni esecuzione del test.
Il grafico Heat mostra che le operazioni sui file sono scritture e blocchi corrispondenti alla natura di accodamento dei processi WAL.

Ridimensionamento del server della regione

Il test successivo consisteva nel determinare il comportamento dei nodi Isilon (cinque nodi) rispetto a un numero diverso di server regionali. Lo stesso script di aggiornamento eseguito nel test precedente riguardava una tabella da un miliardo di righe e un aggiornamento di 10 milioni di righe utilizzando "workloada". Il test utilizzava un singolo client con thread YCSB impostati su 51. Viene applicata la stessa impostazione per maxlogs e pipeline (rispettivamente 256 e 20).  
I risultati sono informativi, anche se non sorprendenti. La natura scale-out di HBase combinata con la natura scale-out di Isilon indica che di più è meglio. Questo test è consigliato per i client da eseguire nei propri ambienti come parte del proprio esercizio di dimensionamento. Qui ci sono nove server che spingono cinque nodi Isilon e sembra che ci sia ancora spazio per altri prima di raggiungere il punto di rendimenti decrescenti.

Più clienti

L'ultima serie di test è servita a testare i limiti della configurazione hardware. Questo è stato fatto per determinare il limite superiore dei parametri testati. In questa serie di test, vengono utilizzati due server aggiuntivi da cui eseguire i client. Inoltre, da ogni server vengono eseguiti due client YCSB con un massimo di sei client ciascuno. Ogni client ha guidato 512 thread, per un totale di 4096 thread. Sono state create due diverse tabelle. Una tabella con 4 miliardi di righe suddivise in 600 aree e un'altra con 400 milioni di righe suddivise in 90 aree.  
I grafici sottostanti mostrano che la dimensione della tabella conta poco in questo test. I grafici Isilon Heat mostrano ancora una volta che c'è una differenza percentuale nel numero di operazioni sui file. La maggior parte delle differenze erano in linea con le differenze di una tabella da quattro miliardi di righe rispetto a una tabella da 400 milioni di righe.

Conclusione

HBase è un buon candidato per l'esecuzione su Isilon, principalmente a causa delle architetture scale-out to scale-out. HBase esegue gran parte della propria memorizzazione nella cache e, suddividendo la tabella in un buon numero di aree, HBase può scalare orizzontalmente con i dati. In altre parole, fa un buon lavoro nel prendersi cura delle proprie esigenze e il file system è lì per la resilienza delle applicazioni. I test non sono stati in grado di spingere il carico fino al punto di rompere le cose. Se HBase è progettato per 800.000 operazioni con meno di 3 ms di latenza, questa architettura lo supporta. HBase supporta una miriade di modifiche e modifiche alle prestazioni sia per il lato client che per HBase stesso. Il test di tutti questi aggiustamenti e modifiche andava oltre lo scopo di questo test.