Im dritten und letzten Teil unserer Blog-Serie zu unseren Ceph-Erfahrungen berichten wir über den letzten Schliff unseres NVMe-Ceph-Clusters.

Benchmarks in den VMs

Nach der Sammlung diverser Eckdaten des gesamten Clusters begannen wir mit dem Testen der Schreib- und Lesegeschwindigkeit direkt in den VMs, welche den Storage benutzen. Bei diesen Benchmarks experimentierten wir zudem mit verschiedenen Einstellungen und vor allem mit unterschiedlichen Prozessoren.

Der erste Test basierte pro Node auf zwei Intel E5-2630 v4 (10x 2.2Ghz) Prozessoren. Diese Prozessoren wählten wir dann auch für das produktive Setup, da der Preis der anderen CPUs für die minimale Steigerung der Performance zu hoch war.

Mit diesem ersten CPU kamen wir zu folgenden Testresultaten:

Die darauffolgende zweite Testserie nutzte zwei Intel E5-2680 v4 (14x 2.4Ghz) Prozessoren:

Für den letzten Test mit unterschiedlichen CPUs verwendeten wir wieder Intel E5-2680 v4 Prozessoren - dieses Mal jedoch nur mit 10 anstelle der eigentlichen 14 Kerne. Dieser finale Test diente hauptsächlich dazu, herauszufinden, ob die Taktung der Kerne oder die Anzahl der Kerne entscheidende Performance-Änderungen bringt.

Aus allen gesammelten Resultaten kristallisierte sich für uns heraus, dass sich schnellere CPUs nicht lohnen, wenn wir mit diesen nur etwa dieselben Resultate erzielten wie mit 10x2.2Ghz.

Mit den Ergebnissen erhielten wir zudem einen guten Überblick über die Performance einzelner virtueller Maschinen. Es war für uns wichtig herauszufinden, ab welcher Last eine Beeinträchtigung der Geschwindigkeit auf einer Maschine des Clusters spürbar ist. Dazu erzeugten wir auf dem Cluster eine Grundlast, welche von mehreren parallel laufenden FIO Jobs erzeugt wurde. In einer spezifischen virtuellen Maschine testeten wir anschliessend die Performance bei der jeweiligen Grundlast. Zur Erzeugung dieser Basislast nutzen wir folgende FIO Parameter:

[global]
invalidate=1
ioengine=rbd
iodepth=1
time_based
runtime=7200
size=10G
bsrange=4k-4m
rw=randrw
direct=1
buffered=0
percentage_random=50
rate=5M
pool=volumes
clientname=libvirt

Wir haben mit diesen Parametern viele verschiedene Last-Profile getestet, jedoch bei dauerhaftem Lesen von unter 1GB/s und ca. 1.5GB/s Schreiblast keine wirkliche Veränderung wahrgenommen. Nach dem Erreichen dieser Werte erhielten wir folgende Messwerte in einer VM:

Die Messungen bei ca. 50MB/s lesender und 110MB/s schreibender Basislast sahen so aus:

Mehr OSDs pro NVMe

Nach den umfangreichen Tests interessierten wir uns nun noch für einen möglichen Einfluss von mehr OSDs pro NVMe auf die Geschwindigkeit des Clusters. Um dies herauszufinden bauten wir unseren Cluster so um, dass wir auf jeder NVMe neu 2 OSDs und entsprechend auch zwei Journal-Partitionen hatten. Dieser Umbau hatte vor allem auf die Lesegeschwindigkeit einen erheblichen Einfluss, wohingegen die Schreibperformance nur ein wenig litt:

Um auch hier das Verhalten bei höherer Auslastung des Ceph-Storages zu sehen, generierten wir wiederum etwa 1GB Lese- und 1.5GB Schreiblast:

So machte sich dann eine doch erhebliche Verbesserung gegenüber der Konfiguration mit nur einer OSD auf jedem NVMe-Device bemerkbar.

Zum Schluss versuchten wir zur Leistungssteigerung einen Lösungsansatz von Samsung, der in Zusammenarbeit mit RedHat als beste Variante vorgeschlagen wurde. Mit dem empfohlenen Upgrade auf 4 OSDs pro NVMe konnten wir keine Steigerung der Leistung feststellen, bemerkten sogar eine Verschlechterung beim Schreiben und Lesen grösserer Blöcke. Somit waren unsere Benchmarks nun abgeschlossen und mit 2 OSDs pro NVMe konnten wir das Performance-Optimum aus der Hardware herausholen.

Ausfallsicherheit

Um zum Abschluss der verschiedenen Tests nun noch die Ausfallsicherheit unseres Setups zu testen, simulierten wir unter Last verschiedene Ausfallszenarien:

NVMe-Ausfall

Den Ausfall einer NVMe-Disk simulierten wir im laufenden Betrieb und mit einiger Last auf dem Cluster, indem wir eine NVMe aus dem Server herauszogen.

Dies resultierte darin, dass einige Sekunden lang keine IO-Operationen mehr möglich waren. Danach arbeitete der Storage wieder normal weiter und es konnten keine Einbussen auf den VMs festgestellt werden.

Im produktiven Betrieb ist dieser Ausfall genügend kurz, sodass in den virtuellen Maschinen keine Beeinträchtigung gespürt werden sollte.

NVMe-Ausfall mit Neuverteilung

Mit diesem Szenario testeten wir mögliche Probleme mit der Performance durch das Herausziehen einer NVMe-Disk und einer Wartezeit bis alle Daten wieder neu verteilt wurden. Ein weiteres Ziel dieses Versuch war festzustellen, wie lange es dauert, bis alle Daten wieder korrekt redundant vorhanden sind.

Das Resultat betrug 5 Minuten. Diese Zeitspanne ab dem Herausziehen der Disk benötigte der Cluster, sich selbst wieder zu reparieren. Hierzu musste er einiges an Daten kopieren, was jedoch bei den VMs nicht spürbar war. Für den Test waren etwa 6182GB Daten auf dem Cluster vorhanden, wodurch der Recovery ca. 20 Minuten dauerte.

Nodeausfall

Diese Situation stellten wir nach, um herauszufinden, was im Falle eines Cluster-Node-Ausfalls durch beispielsweise einen Stromausfall oder bei einem Reboot geschieht.

Wir generierten auch hier wieder viel Load auf dem Cluster, bevor wir einem Node den Strom entzogen. Das Verhalten ähnelte dem Ausfall eines OSD sehr. Der Cluster verarbeitete demnach einige Sekunden lang keine IO-Operationen, funktionierte danach aber wieder korrekt. Auch hier begann nach ca. 5 Minuten das Recovery der “verlorenen” Daten.

Selbst ein Reboot eines Ceph-Servers zeigte dieselben Auswirkungen. Es konnten für einige Sekunden keine IO-Operationen durchgeführt werden, doch danach lief der Cluster wieder normal. Die Daten, welche in der Zeit des Reboots nicht redundant gespeichert werden konnten, wurden nun in sehr kurzer Zeit synchronisiert.

Produktionsumgebung

Nach Abschluss aller Tests konnten wir die Hardware aus den Lab-Racks in die produktive Umgebung umziehen. Nach dem Umzug führten wir noch einen Performance-Test durch, um unsere Ergebnisse aus dem Lab auch in der Produktionsumgebung zu verifizieren. Aufgrund einer weiteren Empfehlung von RedHat migrierten wir die Server zusätzlich von Ubuntu Trusty auf Ubuntu Xenial. Durch den abschliessenden Performance-Test konnten wir zusätzlich ausschliessen, dass das Distributions-Upgrade Auswirkungen auf die Performance des Clusters hatte.

Hier finden Sie den ersten und zweiten Teil der Serie.