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.
No one has commented on this page yet.
RSS feed for comments on this page | RSS feed for all comments
address alpha test api bazaar beta büroräume cloudcamp cloud computing cloudcontrol cloud hosting core faq feedback fragen frankfurt glusterfs invites jobs lean startup linux node paas performance php platform as a service presse pressebereich redesign registrierung relaunch ressourcenverbrauch screencast seed-finanzierung standortentscheidung stellenangebot systemadministrator team veranstaltung webmontag website