PowerScale, Isilon OneFS: HBase-Performancetests auf Isilon

Einführung

Wir haben eine Reihe von Performance-Benchmarkingtests auf einem Isilon X410-Cluster mithilfe der YCSB Benchmarking Suite und CDH 5.10 durchgeführt.

Die CAE POC-Übungsumgebung wurde mit 5 Isilon x410-Nodes konfiguriert, auf denen OneFS 8.0.0.4 und höher 8.0.1.1 NFS-Benchmarks für große Blockstreamings ausgeführt werden. Wir sollte für unsere theoretischen aggregierten Höchstwerte in jedem dieser Tests 5 x ~700 MB/s Schreibvorgänge (3,5 GB/s) und 5 x ~1 GB/s Lesevorgänge (5 GB/s) erwarten.

Die (9) Rechner-Nodes sind Dell PowerEdge FC630-Server mit CentOS 7.3.1611, die jeweils mit 2 x 18C/36T-Intel Xeon® CPU E5-2697 v4 bei 2,30 GHz mit 512 GB RAM konfiguriert sind. Lokaler Speicher ist 2xSSD in RAID 1, formatiert als XFS für das Betriebssystem und Scratch-Speicherplatz/verschüttete Dateien.

Es gab auch drei zusätzliche Edge-Server, die für die YCSB-Last verwendet wurden.

Das Back-end-Netzwerk zwischen Rechner-Nodes und Isilon beträgt 10 Gbit/s mit Jumbo Frames (MTU = 9162) für die NICs und die Switchports.

Erste Tests

Die erste Testserie war die Ermittlung der relevanten Parameter auf der HBASE-Seite, die sich auf die Gesamtausgabe auswirkten. Wir haben das YCSB-Tool verwendet, um die Last für HBASE zu erzeugen. Dieser anfängliche Test wurde mit einem einzigen Client (Edge-Server) unter Verwendung der Lastphase von YCSB und 40 Millionen Zeilen ausgeführt. Diese Tabelle wurde vor jeder Ausführung gelöscht.
 

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

hbase.regionserver.maxlogs – Maximale Anzahl von WAL-Dateien (Write-Ahead Log). Dieser Wert multipliziert mit der HDFS-Blockgröße (dfs.blocksize) ist die Größe des WAL, die nach einem Serverabsturz wiedergegeben werden muss. Dieser Wert ist umgekehrt proportional zur Frequenz der Leerungen auf der Festplatte.

hbase.wal.regiongrouping.numgroups : Wenn Sie mehrere HDFS-WAL als WALProvider verwenden, legt fest, wie viele Write-Ahead-Protokolle jeder RegionServer ausführen soll. Führt zu dieser Anzahl von HDFS-Pipelines. Schreibvorgänge für eine bestimmte Region gehen nur zu einer einzigen Pipeline und verteilen die gesamte RegionServer-Last.

Die Philosophie hier bestand darin, so viele Schreibvorgänge zu parallelisieren, wie wir konnten, sodass die Anzahl der WALs erhöht und dann die Anzahl der Threads (Pipeline) pro WAL erreicht wird. Die beiden vorherigen Diagramme zeigen, dass bei einer bestimmten Zahl für "maxlogs" 128 oder 256 keine echte Änderung angezeigt wird, die darauf hinweist, dass wir diese Zahl nicht wirklich von der Clientseite eingeben. Die Anzahl der "Pipelines" pro Datei variiert, obwohl der Trend auf den Parameter hinweist, der auf Parallelisierung reagiert. Die nächste Frage ist dann, wo Isilon entweder mit Festplatten-E/A, Netzwerk, CPU oder OneFS "im Weg steht", und wir können uns ansehen, welche Isilon-Statistiken berichten.


 
Die Netzwerk- und CPU-Diagramme zeigen uns, dass der Isilon-Cluster nicht ausgelastet ist und Platz für mehr Arbeit hat. Die CPU würde > 80 % und die Netzwerkbandbreite mehr als 3 Gbit/s betragen.



Diese Darstellungen zeigen die HDFS-Protokollstatistiken und ihre Übersetzung durch OneFS. Die HDFS-Vorgänge sind Vielfaches von dfs.blocksize, was hier 256 MB beträgt. Das Interessante daran ist, dass das Diagramm "Heat" die OneFS-Dateivorgänge anzeigt und Sie die Korrelation von Schreibvorgängen und Sperren sehen können. In diesem Fall hängt HBase an die WAL an, sodass OneFS die WAL-Datei für jeden angehängten Schreibvorgang sperrt. Das ist es, was wir für stabile Schreibvorgänge auf einem Clusterdateisystem erwarten würden. Diese scheinen zu dem einschränkenden Faktor in dieser Reihe von Tests beizutragen.

HBase-Aktualisierungen

Dieser nächste Test bestand darin, etwas mehr zu experimentieren, um herauszufinden, was im großen Maßstab geschieht. Daher habe ich eine Tabelle mit einer Milliarde Zeilen erstellt, die eine gute Stunde gedauert hat, um zu erzeugen, und dann eine YCSB ausgeführt, bei der 10 Millionen Zeilen mithilfe der "Workloada"-Einstellungen (50/50 Lese-/Schreibvorgänge) aktualisiert wurden. Dies wurde auf einem einzigen Client ausgeführt und ich suchte auch nach dem größten Durchsatz, den ich erzeugen konnte, also habe ich dies als Funktion der Anzahl der YCSB-Threads ausgeführt. Ein weiterer Hinweis war, dass wir ein gewisses Tuning von Isilon durchgeführt haben und zu OneFS 8.0.1.1 gegangen sind, das Leistungsoptimierungen für den Data Node-Service bietet. Sie können die Leistungssteigerung im Vergleich zu den vorherigen Ausführungen sehen. Für diese Ausführungen legen wir hbase.regionserver.maxlogs = 256 und hbase.wal.regiongrouping.numgroups = 20 fest.

Wenn sie sich diese Ausführungen ansehen, ist das erste, was offensichtlich ist, dass der Fall bei hoher Thread-Anzahl abfällt. Ich war neugierig, ob es sich um ein Isilon-Problem oder ein clientseitiges Problem handelte. Wir sehen einige weitere Tests dazu in den kommenden Abschnitten. Aber ich kann sagen, dass das Vorantreiben von mehr als 200.000 Ops mit einer Updatelatenz von < 3 ms beeindruckend ist. Jede dieser Aktualisierungsläufe war schnell und ich konnte sie nacheinander durchführen. Das folgende Diagramm zeigt das gleichmäßige Gleichgewicht zwischen den Isilon-Nodes für diese Ausführungen.



Im Heat-Diagramm sehen Sie erneut, dass die Dateivorgänge Schreibvorgänge und Sperren sind, die der Anhängeart der WAL-Prozesse entsprechen.

Serverskalierung in der Region

Der nächste Test bestand darin, zu bestimmen, wie sich die Isilon-Nodes (fünf davon) mit einer anderen Anzahl von Regionsservern absetzen würden. Das gleiche Updateskript, das im vorherigen Test ausgeführt wurde, wurde hier ausgeführt. Eine Tabelle mit einer Milliarde Zeilen und 10 Millionen Zeilen, die mit "Workloada" mit einem einzigen Client und YCSB-Threads bei 51 aktualisiert wurden, wir haben auch die gleiche Einstellung für maxlogs und Pipelines beibehalten (256 bzw. 20).

 
Die Ergebnisse sind informativ, aber nicht überraschend. Die Scale-out-Beschaffenheit von HBase kombiniert mit der Scale-out-Natur von Isilon und mehr==besser. Dies ist ein Test, den ich Kunden empfehlen würde, sie im Rahmen ihrer eigenen Dimensionierungsübung in ihren Umgebungen auszuführen. Es kann zu einer sinkenden Rendite kommen, aber hier haben wir neun starke Server, die fünf Isilon-Nodes übertragen, und es sieht so aus, als ob es Raum für mehr gibt.

Mehr Clients

Die letzte Testserie stammt von diesem tiefen, dunklen Ort, an dem Sie das system, das Sie testen, unterbrechen möchten. Schließlich ist es eine vollkommen gültige wissenschaftliche Methode, einen Test so lange zu ratieren, bis die Dinge kaputt sind, und dabei zu wissen, was die Obergrenze für die getesteten Parameter ist. In dieser Reihe von Tests hatte ich zwei zusätzliche Server, die ich verwenden konnte, um den Client von auszuführen. Darüber hinaus habe ich zwei YCSB-Clients auf jedem einzelnen ausgeführt, sodass ich auf bis zu sechs Clients skalieren konnte, die jeweils 512 Threads betreiben, was insgesamt 4.096 Threads entspricht. Ich bin zurückgegangen und habe zwei verschiedene Tabellen erstellt, eine mit 4 Milliarden Zeilen, die in 600 Regionen aufgeteilt sind, und eine mit 400 Millionen Zeilen, die in 90 Regionen aufgeteilt sind.  

 



 

Wie Du siehst, ist die Größe der Tabelle in diesem Test wenig wichtig. Wenn Sie sich die Isilon Heat-Diagramme noch einmal ansehen, können Sie sehen, dass es einen Unterschied in Prozent bei der Anzahl der Dateivorgänge gibt, die größtenteils inline mit den Unterschieden einer Vier-Milliarden-Zeilen-Tabelle zu 400 Millionen Zeilen sind.

Entscheidung

HBase ist ein guter Kandidat für die Ausführung auf Isilon, hauptsächlich aufgrund der Scale-out-zu-Scale-out-Architekturen. HBase führt viel eigenes Caching durch und teilt die Tabelle auf eine gute Anzahl von Regionen auf, in denen HBase mit Ihren Daten skaliert werden kann. Mit anderen Worten: Es leistet gute Arbeit, wenn es sich um seine eigenen Anforderungen kümmert, und das Dateisystem ist für die Persistenz da. Wir waren nicht in der Lage, die Lasttests auf den Punkt zu bringen, an dem die Dinge tatsächlich unterbrochen wurden, aber wenn Sie sich vier Milliarden Zeilen in Ihrem HBase-Design ansehen und 800.000 Vorgänge mit weniger als 3 ms Latenz erwarten, unterstützt diese Architektur sie. Wenn Sie bemerken, dass ich nicht viel mehr über eine der unzähligen anderen Client-Optimierungen erwähnt habe, die Sie auf HBase selbst anwenden könnten, würde ich erwarten, dass alle diese Optimierungen weiterhin gültig sind und über den Umfang dieses Tests hinausgehen.