Seit Jahren erwartet, ist endlich Version 4 des Samba-Servers erschienen, der nun als vollwertige Alternative zu Microsofts Active Directory dienen kann. In der ... (mehr)

Ganz leicht: Glance und Ceph

Im Falle von Glance lautet die Antwort: Sehr leicht. Glance kann nativ mit Ceph sprechen. Zur Erinnerung: Glance ist die Komponente in OpenStack, die Betriebssystem-Images für Benutzer parat hält. Wenn schon ein Object-Store da ist, liegt nichts näher, als jene Images in ihm abzulegen. Damit das klappt, sind nur wenige Vorbereitungen nötig. Vorausgesetzt, dass es in Ceph einen Pool namens »images« gibt und dass der Ceph-Benutzer »client.glance« Zugriff auf diesen hat, ist die restliche Konfiguration leicht. Mehr über die Benutzerautentifizierung in Ceph findet sich übrigens im zweiten Artikel des Autors in diesem Heft.

Jeder Host, auf dem Glance mit Ceph-Verbindung laufen soll, benötigt eine funktionierende »/etc/ceph/ceph.conf« . Aus dieser holt Glance sich alle benötigten Infos über die Topologie des Ceph-Clusters. Außerdem muss in der Datei vermerkt sein, wo der Keyring mit dem Passwort zu finden ist, der zum Glance-Benutzer in Ceph gehört. Ein entsprechender Eintrag für »ceph.conf « sieht so aus:

[client.glance]
        keyring = /etc/ceph/keyring.glance

In »/etc/ceph/keyring.glance« muss dann der Schlüssel des Benutzers zu finden sein. Die folgende Datei ist ein Beispiel:

[client.glance]
        key = AQA5XRZRUPvHABAABBkwuCgELlu...

Dann fehlt nur noch die Konfiguration von Glance selbst, die der Admin in »/etc/glance/glance-api.conf« einträgt. Der Wert für »default_store = « ist »rbd« . Wer als Benutzernamen für den Glance-Benutzer in Ceph »client.glance« und als Pool »images« nutzt, kann das File danach wieder schließen, das ist der Default. Wenn andere Namen zum Einsatz kommen, sind »rbd_storage_user« und »rbd_store_pool« weiter unten in der Datei entsprechend anzupassen. Dann ist ein Neustart von »glance-api« und »glance-registry« fällig – fertig.

Cinder ist die Block-Storage-Lösung von OpenStack, die die eigentlich nicht persistenten VMs mit dauerhaftem Block-Speicher versorgt. Auch Cinder hat ein natives Backend für Ceph, dessen Konfiguration allerdings etwas umfangreicher ist. Der Grund hierfür ist, dass Cinder das Zuweisen von Speicher direkt über »libvirt« abwickelt. Libvirt selbst ist quasi der Client, der sich direkt an Ceph anmeldet. Wenn die Authentifizierung CephX zum Einsatz kommt, muss die Virtualisierungsumgebung folglich wissen, wie sie sich gegenüber Ceph passend vorstellt. So weit, so gut: Seit Libvirt 0.9.12 ist die entsprechende Funktion in Libvirt dafür vorhanden.

Etwas komplizierter: Cinder

Das folgende Beispiel geht davon aus, dass der Ceph-Benutzer im Kontext von Cinder »client.cinder« heißt und dass ihm ein eigener Pool »cinder« zur Verfügung steht. Wie im Beispiel von Glance muss für den Benutzer ebenso ein Keyring namens »/etc/ceph/keyring.cinder« vorhanden sein, der auch in »ceph.conf« entsprechend referenziert ist. Dann ist mittels »uuidgen« auf der Kommandozeile eine UUID zu generieren – libvirt speichert Passwörter mit UUID-Namen ab. Im Beispiel kommt »2a5b08e4-3dca-4ff9-9a1d-40389758d081« zum Einsatz. Der nächste Schritt besteht darin, ein passendes Secret-File für Libvirt anzulegen. Im Beispiel ist die Datei »/etc/libvirt/secrets/ceph.xml « , ihr Inhalt ist dieser:

<secret ephemeral="no" private="no">
  <uuid>2a5b08e4-3dca-4ff9-9a1d-40389758d081</uuid>
    <usage type="ceph">
    <name>client.cinder secret</name>
  </usage>
</secret>

Das Feld »uuid« ist jeweils durch die tatsächliche UUID zu ersetzen, und wenn der Benutzer lokal nicht »client.cinder« sondern anders heißt, ist auch »name« entsprechend anzupassen. Es folgt das Aktivieren des Passworts in Libvirt:

virsh secret-define /etc/libvirt/secrets/ceph.xml

Bisher weiß Libvirt nur, dass es ein Passwort gibt, allerdings fehlt noch der eigentliche Schlüssel. Der befindet sich in »/etc/ceph/keyring.cinder« , es handelt sich um die Zeichenkette hinter "key =". Dass der Key zum eben festgelegten Passwort gehört, erfährt Libvirt so:

virsh secret-set-value UUID Schlüssel

Im konkreten Beispiel also:

virsh secret-set-value 2a5b08e4-3dca-4ff9-9a1d-40389758d081 AQA5jhZRwGPhBBAAa3t78yY/0+1QB5Z/9iFK2Q==

Der Libvirt-Teil der Konfiguration ist damit abgeschlossen, ab sofort kann sich Libvirt als »client.cinder« an Ceph anmelden und dort Storage-Devices nutzen. Was noch fehlt, ist die entsprechende Cinder-Konfiguration, damit der Storage-Dienst tatsächlich Ceph verwendet.

Schritt 1: Cinder muss lernen, als welcher Benutzer es sich selbst an Ceph anmelden muss, um Storage-Devices für VM-Instanzen anzulegen. Hierzu ist »/etc/init/cinder-volume.conf« in einem Editor so zu verändern, dass die erste Zeile der Datei »env CEPH_ARGS="--id cinder"« ist (falls der Benutername »client.cinder« lautet). Schritt 2: Jetzt fehlen nur noch die folgenden vier Zeilen in »/etc/cinder/cinder.conf« :

volume_driver=cinder.volume.driver.RBDDriver
rbd_pool=images
rbd_secret_uuid=2a5b08e4-3dca-4ff9-9a1d-40389758d081
rbd_user=cinder

Nach einem Neustart der Cinder-Dienste »cinder-api« , »cinder-volume« und »cinder-scheduler« funktioniert das Gespann aus Cinder und Ceph wie gewünscht.

Die schönste OpenStack-Installation ist nichts wert, wenn der Ausfall eines Servers sie zum Absturz bringt. Das Setup, das in Teil 2 des Workshops entstanden ist, bietet gleich zwei Points of Failure, nämlich sowohl den API-Knoten als auch den Netzwerk-Knoten.

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023