Ein Ceph-Cluster ist zwar schnell aufgesetzt. Für die optimale Performance muss man aber an vielen Stellschrauben drehen.
Ceph ist mittlerweile eine feste Größe im Segment des Software-defined Storage. Ein Grund dürfte in den niedrigen Einstiegshürden liegen. Es genügen virtuelle Maschinen für die ersten Gehversuche, und wer einen physischen Ceph-Cluster bauen möchte, kann ihn heute per Mausklick installieren.
Will der Administrator aber nicht nur ein stabiles, sondern auch ein schnelles Ceph, ist Handarbeit angesagt. Die gute und gleichzeitig schlechte Nachricht: Ein typischer Ceph-Cluster hat eine Unmenge Stellschrauben, die die Performance beeinflussen. Dieser Artikel zeigt die wichtigsten Hebel und Schalter und verrät, wie man einem Ceph-Cluster Beine macht.
Wer einen Ceph-Cluster tunen will, sollte zumindest grundlegend wissen, wie er funktioniert. Nur so lassen sich Flaschenhälse vermeiden. Die Kurzvorstellung im Kasten „Ceph – die schnöde Theorie“ verdeutlicht schnell, dass es der Administrator mit einem recht komplexen Gebilde zu tun hat, in dem Hard- und Software ineinandergreifen.
Ungenügende Hardwareressourcen stellen allerdings eine deutlich größere Hürde dar als Mängel in der Konfiguration: Letztere kann der Administrator mit recht geringem Aufwand beheben, während er für neue Hardware Geld investieren muss. Deshalb empfiehlt es sich, der Performance bereits in der Planung eines Ceph-Clusters hinreichend Aufmerksamkeit zu schenken.
Durchsatz und Latenz
Reden Administratoren von Performance, meinen sie nicht unbedingt dasselbe, denn sie hat bekanntlich mindestens zwei Dimensionen: Beim Durchsatz geht es um die Frage, wie viele Daten sich in einem bestimmten Zeitraum von A nach B transportieren lassen. Der Begriff Latenz hingegen wirft die Frage auf, wie lange Daten benötigen, um überhaupt von A nach B zu gelangen, genauer: welche Pausen sie unterwegs einlegen.
Wer einen Ceph-Cluster tunen möchte, muss diese beiden Dimensionen der Performance unbedingt beachten: Das Erhöhen des Durchsatzes verlangt andere Strategien als das Senken der Latenz. Letzteres ist zudem ungleich schwerer, da Ceph mit latenzlastigen Techniken arbeitet, die sich nur mit hohem Aufwand oder gar nicht umgehen lassen. Da für die Verringerung der Latenz auch weniger Stellschrauben zur Verfügung stehen, bezieht sich der weitaus größere Teil der Empfehlungen auf den Durchsatz. Die Abhängigkeit von Hard- und Software kommt besonders hier zum Tragen.
Zuvor stellen sich aber zwei andere Fragen, nämlich erstens, welche Werkzeuge dem Administrator überhaupt zur Verfügung stehen, damit er die Performance eines Ceph-Clusters bewerten kann, und zweitens, wie er herausfindet, wo in seinem Setup das größte Optimierungspotenzial liegt, also mit welchen – idealerweise eher kleinen – Veränderungen er große Performancesprünge erreichen kann. Die Antwort auf diese Frage ist ziemlich unbefriedigend und lautet: Kommt drauf an.
Grundsätzlich gilt: „Keep it simple, stupid!“ Wer etwa die Performance eines RADOS Block Device (RBD) testen möchte, kann das mit speziellen Werkzeugen erledigen, er kann aber auch auf die Bordmittel wie dd zurückgreifen, die die meisten Linux-Distributionen in der Standardinstallation bereits aufgespielt haben (siehe Kasten „Warmlaufen mit dd“).
Ceph-Performance sinnvoll messen
Mit dem separat zu installierenden iperf kann man Latenz und Durchsatz des Datentransfers zwischen zwei Hosts messen, ohne dass das entfernte Gerät lokal eingebunden ist. Auf dem einen Host startet der Administrator dazu den Befehl iperf –s und auf dem anderen Host ruft er den Befehl iperf –c IP-Adresse auf, um den Test zu starten.
Der Performance von CephFS kann man mit handelsüblichen Werkzeugen wie Bonnie++ auf den Grund gehen. Für fortgeschrittene Ansprüche eignet sich auch fio, das vielen Administratoren ebenfalls bekannt ist.
Ceph bringt zudem selbst Werkzeuge mit, die die Performance einzelner Teile des Ceph-Clusters untersuchen. Die Befehle
