Das bestehende Setup erweitern

Wie verhält es sich nun also mit der Erweiterung eines RADOS-Clusters um weitere Knoten, um den verfügbaren Speicherplatz zu vergrößern? Angenommen, das Beispielsetup sei um den Knoten »daisiy« zu erweitern, so besteht der erste Schritt darin, für diesen Knoten eine ID festzulegen. Im Beispiel sind die IDs null bis drei bereits vergeben, sodass der neue Knoten die ID vier erhält, was mit »ceph osd create 4« geschieht.

Im Anschluss sind die vorhandenen »ceph.conf« -Dateien auf sämtlichen schon vorhandenen Clusterknoten so zu erweitern, dass ein Eintrag für Daisy dort vorhanden ist. Auf daisy selbst ist dazu die Ordnerstruktur anzulegen, die für die Arbeit als OSD notwendig ist, insbesondere also die Verzeichnisse in »/srv« analog zu den bisherigen Beispielen dieses Artikels. Danach ist die neue »ceph.conf« in den Ordner »/etc/ceph« auf daisy zu kopieren.

Damit daisy weiß, welche MON-Struktur vorhanden ist – sie selbst muss sich in weiterer Folge an einem existierenden MON registrieren – benötigt sie eine aktuelle Version der MONmap ( Abbildung 5 ) des existierenden RADOS-Clusters. Diese ist auf einem der existierenden RADOS-Knoten per »ceph mon getmap -o /tmp/monmap« auszulesen und dann auf Daisy per »scp« zu kopieren (das Beispiel geht davon aus, dass sie auch auf daisy in »/tmp/monmap« landet). Dann folgt die Initialisierung des OSD-Verzeichnisses auf Daisy: »ceph-osd -c /etc/ceph/ceph.conf -i 4 --mkfs --monmap /tmp/monmap --mkkey« . Hätte der zusätzliche Clusterknoten eine andere ID als vier, so wäre dieser Wert hinter -i entsprechend einzusetzen.

Abbildung 5: Die Monmap enthält Informationen darüber, welche MONs innerhalb eines RADOS-Clusters bereits vorhanden sind. Neue OSDs benötigen diese Information unbedingt.

Abbildung 6: Mittels

Schließlich lernt der schon bestehende Cluster den neuen Knoten kennen ( Abbildung 6 ). Im Beispiel existiert auf »daisy« nach dem letzten Befehl eine Datei namens »/etc/ceph/osd.4.keyring« , die mittels »scp« auf einen der bereits existierenden MONs zu kopieren ist. Danach bindet »ceph auth add osd. ID osd 'allow *' mon 'allow rwx' -i /etc/ceph/osd.4.keyring« auf eben diesem Knoten den neuen OSD in die bestehende Autentifizierungsstruktur ein. Indem per »/etc/init.d/ceph« auf daisy RADOS in Gang gesetzt wird, meldet sich der neue OSD am existierenden RADOS-Cluster an. Der allerletzte Schritt ist, die vorhandene Crush Map anzupassen, sodass der neue OSD tatsächlich auch verwendet wird. Das geschieht im Beispiel mit »ceph osd crush add 4 osd.4 1.0 pool=default host=daisy« – danach ist das neue OSD Bestandteil des existierenden RADOS/Ceph-Clusters.

Zwischenfazit

Es ist nicht besonders kompliziert, die Kombination aus RADOS und Ceph erstmalig einsatzbereit zu machen. Diese Art der Konfiguration lässt aber auch viele der großartigen Funktionen, die RADOS ab Werk bietet, komplett ungenutzt. So bietet die schon erwähnte Crush-Map-Funktionalität die Möglichkeit, riesige RADOS-Setups über ganze Racks in Rechenzentren zu deployen und obendrein intelligent ausfallsicher zu machen. Indem RADOS zudem die Möglichkeit bietet, seinen Speicher in einzelne Pools variabler Größe aufzuteilen, ist eine weitere Granulierung im Hinblick auf jeweils unterschiedliche Aufgaben und Zielgruppen möglich.

Unerwähnt geblieben sind bisher auch die RADOS-Frontends weit jenseits von Ceph. Fakt ist: Ceph ist ein Frontend von vielen, in diesem Falle erlaubt es den Zugriff auf Dateien innerhalb des Object Stores über den Umweg eines Linux-Dateisystems.

Es stehen allerdings noch einige andere Optionen im Raum, um an Daten in RADOS heranzukommen: Das Rados Block Device, kurz »rbd« ist beispielsweise gut, wenn Zugriff auf Dateien im Object Store auf Block-Device-Ebene passieren soll. Das ist unter anderem bei virtuellen Maschinen der Fall, die meist Block-Devices als Backend für ihre virtuellen Festplatten akzeptieren und so die langsamere Lösung mit Images umgehen. RADOS wird auf diese Weise zum umfassenden Storage-System für große Virtualisierungslösungen und löst für den Admin ein weiteres Problem im Kontext der Cloud. Apropos: Neben »rbd« stehen über die »librados« auch verschiedene Schnittstellen zum HTTP-Zugriff bereit, so existiert eine Variante, die kompatibel mit Amazons S3 ist genauso wie eine Swift-kompatible Variante. Außerdem ist ein generisches REST-Interface verfügbar. An Schnittstellen zur Außenwelt mangelt es RADOS insofern sicher nicht.