Libvirt mit CephX

Etwas komplizierter gestaltet sich die Nutzung von Libvirt und RBD, wenn der Cluster CephX verwendet. Denn dann muss sich die Libvirt natürlich auch als ganz normaler Client an Ceph anmelden, um Zugriff auf die Daten zu haben. Seit Libvirt 0.9.12 kann Libvirt mit CephX umgehen, die Einrichtung ist aber wenig intuitiv. Das folgende Beispiel basiert auf der Annahme, dass im Ceph ein Benutzer namens »libvirt« existiert und der zum Nutzer passende Keyring in »/etc/ceph/keyring.libvirt« zu finden ist. Libvirt speichert intern Passwörter mit UUID-Bezeichnungen, sodass zunächst mittels »uuidgen« auf der Kommandozeile eine UUID zu generieren ist, im Beispiel »46d801da-7f82-4fa4-92cd-a19e6999d2e6« .

Dann ist zunächst eine Datei namens »ceph.xml« anzulegen, die diesen Inhalt hat:

<secret ephemeral="no" private="no">
  <uuid>46d801da-7f82-4fa4-92cd-a19e6999d2e6</uuid>
  <usage type="ceph">
     <name>client.libvirt secret</name>
  </usage>
</secret>

Es folgt ein »virsh secret-define ceph.xml« , wonach Ceph einen Eintrag für das Passwort in »/etc/libvirt/secrets« anlegt ( Abbildung 3 ). Was noch fehlt, ist der tatsächliche Schlüssel, den Libvirt für dieses Passwort braucht. Der passende Befehl ist dieser:

Abbildung 3: Libvirt verfolgt eine etwas eigene Strategie für Ceph-Passwörter und legt diese unter /etc/libvirt/secrets ab.

virsh secret-set-value 46d801da-7f82-4fa4-92cd-a19e6999d2e6 `ceph-authtool --nameclient.libvirt --print-key /etc/ceph/keyring.libvirt`

Das Kommando liest mittels »ceph-authtool« den korrekten Schlüssel des Benutzers »client.libvirt« aus und assoziiert diesen mit der erstellten UUID in Libvirts interner Passwort-Datenbank. Die VM-XML-Konfiguration muss danach noch lernen, dass für den Zugriff auf Ceph ein Key nötig ist. Anstelle des oben genannten Beispiels ist mittels »virsh edit ubuntu-amd64-alice« die VM so anzupassen wie in Listing 3 . Danach funktioniert auch das Gespann aus Libvirt und RBD mit CephX.

Wer sich mit Storage beschäftigt, wird sich früher oder später natürlich die Frage stellen, wie sich aus der vorhandenen Hardware mehr Performance herauskitzeln lässt.

Das Problem mit SSDs

Zwar performt ein typischer Ceph-Cluster bereits ab Werk deutlich besser als klassisches Block-Storage, weil Ceph Schreib- wie Lesevorgänge parallellisiert, doch gibt es auch bei Ceph durchaus Schrauben, an denen sich drehen lässt. Admins berichten von externen Proof-of-Concept- Installationen, bei denen die einzelnen Knoten mit gebondetem 10 GBit-Netz miteinander verbunden waren und Datentransferraten von 2 GByte/s das Maß der Dinge waren. Auch mit klassischem GBit-Netz lässt sich die Performence von Ceph-Clustern aber steigern. Eine im Netz immer wieder zu findende Empfehlung lautet, die Journale der OSDs auf SSDs abzulegen.

Dazu ein kleiner Ausflug in die Ceph-Interna: Jedes OSD hat ein eigenes Journal, quasi eine Art vorgeschalteten Cache, in dem die Daten für das OSD zunächst landen. Ceph erklärt einen Schreibvorgang auf Client-Seite für abgeschlossen, wenn die zu schreibenden Daten die Journale von so vielen OSDs erreicht haben, wie es die Replikationseinstellung vorsieht. Klar ist damit auch: Je schneller die Schreibvorgänge im Journal abgeschlossen sind, desto schneller ist der Storage-Cluster. Ab Werk speichern die OSDs ihre Journale selbst, per Konfigurationseinstellung lassen sich aber auch externe Journale aktivieren ( Abbildung 4 ). Eigentlich logisch also, die Journale auf flotte SSDs zu legen.

Abbildung 4: Pro OSD lässt sich auch ein eigenes Block-Device für das Journal angeben, im Normalfall eine Partition auf einer SSD. Dabei ist aber Vorsicht geboten, damit OSD-Ausfälle nicht die MONs lahmlegen.

Die Sache hat aber einen Haken, der sich aus der typischen Hardware von Ceph-Storage-Knoten ergibt. Oft handelt es sich um Server mit zwölf Slots für Platten, in denen zwei SSDs und zehn normale SATA-Platten stecken. Auf den SSDs liegt das System selbst sowie die OSD-Journale. Drei Knoten dieser Art ergeben zusammen einen Ceph-Cluster. Fällt einer der drei Knoten aus, heißt das für Ceph nichts anderes, als dass der Inhalt von insgesamt zehn OSDs auf die verbliebenen OSDs zu verteilen ist. Das sorgt für jede Menge Random I/O, dem oft genug auch die SSD-Platten nicht gewachsen sind. Weil aber auf den SSDs eben auch das System läuft und mit ihm die MON-Server von Ceph, geraten eben jene in dieser SItuation immer wieder in Timeouts und verlieren die Verbindung zum anderen noch verbliebenen MON. Der Cluster verliert sein Quorum und erklärt sich für funktionsuntüchtig – das Storage funktioniert dann nicht mehr.

Umgehen lässt sich dieser Effekt auf mehreren Wegen. Einerseits ist es generell keine schlechte Idee, MON-Server auf Maschinen zu betreiben, die selbst keine OSDs sind. Denn dann funktionieren die MONs unabhängig von der Frage, wie viel I/O gerade auf den OSD-Servern passiert. Ebenfalls als praktikabel hat es sich herausgestellt, die maximale Anzahl an OSDs pro Host zu beschränken. Der beschriebene Effekt verschwindet nahezu völlig, wenn nur der Inhalt von 6 OSDs auf die verbliebenen Cluster-Knoten zu verteilen ist. Last but not least hilft es in solchen Szenarien ebenfalls, die SSDs lediglich für das System zu verwenden und die OSDs ihre Journale selbst speichern zu lassen. So grotesk es klingt: In einem Setup wie dem beschriebenen richten SSDs im schlimmsten Fall mehr Schaden an, als sie Nutzen bringen. Die Hardware eines Ceph-Setups will also gut geplant sein.