GlusterFS Benchmark

2 November 2009

Als SUN4Startups Mitglied hatten wir die Möglichkeit auf drei von SUN gestellten Serversystemen verschiedene Benchmarks durchzuführen. Was wir dabei an Erkenntnissen hinsichtlich GlusterFS gewonnen haben fassen wir mit diesem Artikel zusammen.

Bei jedem Benchmark kommt es erstmal auf die zu Grunde liegenden Systeme an. Zur Verfügung standen uns die folgenden 3 Maschinen.

Name Gorman Vasques Ferro
Typ Sun Fire X4150 Sun Fire X4150 Sun Fire X4450
CPU 2 Quad Core Intel Xeon X5335 @2.66 Ghz 2 Quad Core Intel Xeon X5335 @2.66 Ghz 4 Quad Core Intel Xeon X7350 @2.93 GHz
RAM 32 GB 32 GB 64 GB
HDD 4 x 146 GB RAID 10 4 x 146 GB RAID 10 4 x 146 GB RAID 10
NET 1000 Mbit 1000 Mbit 1000 Mbit

Auf den Systemen war Debian Sid, XEN und Eucalyptus installiert. Die Tests liefen in virtuellen Instanzen von ca. 1,7 GB Ram und max einem CPU Kern jeweils. Dadurch sollten die Instanzen ungefähr, mit Ausnahme der CPU, mit den kleinsten Amazon EC2 Instanzen vergleichbar sein.

GlusterFS ist ein verteiltes Netzwerkdateisystem. Aufbauend auf bricks und volumes kann man in verschiedenen Konfigurationen RAID ähnliche Speicherlösungen über Netzwerk realisieren. Wir nutzen GlusterFS intern um die während der Laufzeit der Anwendung anfallenden Dateien zu speichern. Dadurch sind die Dateien zu jederzeit auf jeder Node Verfügbar ohne, dass bei der Entwicklung der Applikation hierauf geachtet werden muss. Im Gegensatz zu einem reinen NAS Speicher gibt es allerdings keinen Single Point of Failure, weil Daten gleichzeitig auf mehreren physischen Systemen vorgehalten werden können.

Die Schreib- / Lesegeschwindigkeit in den drei unterschiedlichen Szenarien, ohne und mit GlusterFS sah dabei wie folgt aus. Die Zahlen sind dabei die Anzahl 1Mb großer Dateien pro Sekunde. GlusterFS war dabei als NUFA Volume konfiguriert. Hierbei werden die verschiedenen Nodes zu einem gemeinsamen Speicher zusammengefasst, es wird aber bevorzugt der lokale Speicherplatz verwendet. Die nachfolgenden Zahlen sind allerdings so, dass jede Datei jeweils nur auf einem der Server gespeichert wurde.

Lesen Schreiben
ohne GlusterFS
17,7 35,7
mit GlusterFS 1 Thread pro Server
33,1 27,85
mit GlusterFS 15 Lese- und 5 Schreibthreads pro Server
57,56 11,88

Die Ergebnisse zeigen, dass gerade bei mehreren parallelen Lesezugriffen GlusterFS durch die Verteilung seine Stärken ausspielen kann. Schreibzugriffe sind verständlicherweise durch die zu Grunde liegende Hardware limitiert. Durch die Benchmarkskripte war sichergestellt, dass jeder neue Lesezugriff eine zufällige Datei gelesen hat und das nach jeder einzelnen Datei der Betriebssystem Cache gelöscht wurde. Ausserdem wurde nach jeder geschriebenen Datei synchronisiert. So sollten externe Einflüsse weitestgehend ausgeschlossen werden. Im realen Betrieb würde man dies natürlich nicht tun und hat dementsprechend auch nochmals bessere Performance zu erwarten.

Weiter hat uns die Frage interessiert, ob es hinsichtlich Ressourcenverbrauch einen Unterschied macht ein großes Glustershare zu betreiben, oder mehrere kleine. Hinsichtlich Performance sind hierbei keine großen Unterschiede zu erkennen. Was den Ressourcenverbrauch angeht, muss man allerdings festellen, dass pro Glustershare ca. 4 Mb Ram zusätzlich verbraucht werden. Dieser Mehrverbrauch bietet allerdings den Vorteil die einzelnen Shares bedarfsgerechter auf verschiedene Nodes verteilen zu können. Sollte man wie wir, für seinen speziellen Einsatzzweck nicht auf jeder Node alle Daten benötigen.

Wir bedanken uns bei SUN Deutschland und insbesondere bei Christian Müller (@sun4startups) und den anderen Teammitgliedern für die Bereitstellung der Hardware und die tatkräftige Unterstützung.

0 Kommentar(e) zum Artikel von Tobias Wilken zu den Themen , , , , .

Post your comment

Comments

No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments