Ceph als Ersatz für klassischen Block-Storage

Nach so viel Rechte-Theorie auf zu etwas Praktischem: Während viele, die sich mit dem Thema Ceph beschäftigen, durchaus begeistert von der technischen Lösung sind, fehlt oft eine Vorstellung davon, wie sich Ceph im Alltag ganz konkret einsetzen lässt. Dabei ist das durchaus möglich – dann zum Beispiel, wenn man einen Virtualisierungscluster betreibt und bei diesem immer wieder mit Problemen zu kämpfen hat, um die Kapazität des Clusters zu erweitern. Entgegen allen Unkenrufen taugt Ceph nicht nur als Monster-Storage innerhalb von Cloud-Setups, sondern leistet treue Dienste auch in kleineren Umgebungen, die klassisch mit KVM virtualisieren.

Ceph und Libvirt

Zu verdanken ist das im Wesentlichen der Tatsache, dass sich die Entwickler der »libvirt« -Virtualisierungsumgebung sehr gut mit den Ceph-Entwicklern verstehen und in Libvirt deshalb eine umfangreiche Ceph-Integration zur Verfügung stellen. Statt eines normalen Block-Devices lässt sich für eine von Libvirt verwaltete VM so auch ein RBD-Image als Backing-Device angeben, im Hintergrund greift Libvirt dann unmittelbar auf den Ceph-Cluster zu. Es liegt der Vorteil klar auf der Hand: In einem solchen Konstrukt lässt sich jede VM auf jedem Knoten eines Virtualisierungsclusters betreiben, solange der Zugriff auf den Ceph-Cluster möglich ist. Wenn CephX abgeschaltet ist, ist der nötige Umbau an den Libvirt-VM-Definitonen minimal. Ein Beispiel: Eine VM greift in einem klassischen Virtualisierungssetup im Hintergrund auf ein ganz normales Blockdevice zu. Der entsprechende Eintrag in der Datei – im Beispiel soll sie »ubuntu-amd64-alice.xml« heißen – sieht so aus wie in Listing 1 :

Eine solche VM lässt sich problemlos auf einen Ceph-Cluster umziehen. Die einschlägigen Beispiele empfehlen, VMs innerhalb von Ceph in einen eigenen Pool zu legen, der im Beispiel »libvirt« heißt. Wenn der Pool analog zum Beispiel weiter oben erstellt ist, folgt die Migration der Daten vom alten Block-Device auf das neue RBD-Image. Der neue Pool braucht ein RBD-Image mit gewünschter Größe, der Befehl »qemu-img create -f rbd rbd:libvirt/ubuntu-amd64-alice 100G« erstellt dieses mit einer Größe von 100 Gigabyte. (Achtung: Damit der Befehl funktioniert, muss »/etc/ceph/ceph.conf« korrekt und aktuell die Topologie des Ceph-Clusters wiedergeben und auch die Information enthalten, wo der Key für »client.admin« zu finden ist, falls der Cluster CephX verwendet). Dann folgt das Überspielen aller VM-Daten – für diesen Schritt muss die virtuelle Maschine allerdings ausgeschaltet sein, damit sich Ihre Daten nicht während der Migration verändern:

qemu-img convert -f raw -O rbd /dev/drbd/by-res/vm-ubuntu-amd64-alicerbd:libvirt/ubuntu-amd64-alice

Je nach Geschwindigkeit des lokalen Blockspeichers kann dieser Vorgang ein paar Minuten dauern. Wenn er beendet ist, muss Libvirt noch lernen, ab sofort RBD anstelle des alten Block-Devices zu nutzen. Der zuvor genannte Eintrag ist dafür so abzuändern, sodass er letztlich aussieht wie in Listing 2 .

Zu beachten ist dabei, dass die im Beispiel gezeigten IP-Adressen durch die tatsächlichen IP-Adressen der verfügbaren MON-Server zu ersetzen sind. Es ist übrigens sinnvoll, die Datei über »virsh edit ubuntu-amd64-alice« in einen Editor zu laden, denn Libvirt liest sie hiernach automatisch neu ein und weiß sofort um die Änderungen.

Übrigens: Das gezeigte Beispiel nutzt auch die RBD-Cache-Funktion über den Writeback-Modus, um für zusätzliche Performance innerhalb der VM zu sorgen. Im Anschluss an die beschriebenen Schritte lässt sich die VM wie gewohnt starten, Unterschiede im Handling zu einer "Nicht-RBD-VM" ergeben sich nicht. Wer ein solches Setup mit Pacemaker betreibt, kann anschließend das Block-Device aus der Pacemaker-Konfiguration entfernen.