Der RADOS-Objectstore und Ceph, Teil 5

Der RADOS-Objectstore ist ein echter Tausendsassa. Neben dem CephFS-Dateisystem, das POSIX-kompatiblen Zugriff auf RADOS bietet, steht auch RBD zur Verfügung, das RADOS-Block-Device. Das sieht aus wie ein normales Linux-Block-Device oder lässt sich – wie im Falle von Qemus RBD-Backend – wenigstens so nutzen. RADOS bietet aber noch eine dritte Zugriffsmöglichkeit, die den Objectstore für einen weiteren Use Case interessant macht: Das RADOS-Gateway. Dieser Artikel greift dessen Idee und die zugrunde liegenden Technologien auf und erläutert, wie sich mit ihm ein RADOS-Objectstore nutzen lässt, um Clients per Amazon-S3-API oder OpenStack-Swift-Protokoll das Speichern zu ermöglichen.

keystone service-create --name swift --type-object store
# Die ausgegebene ID des Dienstes ist # wichtig und zunotieren!
keystone endpoint-create --service-id <id> --publicurl \
        http://charlie.local/swift/v1         --internalurl http://charlie.          local/swift/v1 --adminurl           http://charlie.local/swift/v1

mkdir /var/ceph/nss
openssl x509 -in /etc/keystone/ssl/certs/ca.pem -pubkey | \certutil -d /var/ceph/ nss -A -n ca  -t "TCu,Cu,Tuw"openssl x509 -in /etc/keystone/ssl/certs/signing_cert.pem -pubkey | certutil -d /var/ceph/nss -A -n signing_cert -t  "TCu,Cu,Tuw"

Wozu das Ganze?

Wieso bedarf es neben des CephFS-Dateisystems und des RADOS-Block-Devices noch einer weiteren Zugriffsmöglichkeit auf RADOS? Die Antwort liegt, wie so oft, in der Wolke. Die große Mehrheit der Admins, die von Cloud-Computing auf Anbieter-Ebene redet, meint Rechenzentrumskonsolidierung und mithin auch Virtualisierung. De facto ist Virtualisierung die Kern-Komponente der Cloud. Das darf aber nicht darüber hinwegtäuschen, dass klassische Cloud-Umgebungen noch einen weiteren Dienst kennen: Leicht verfügbaren Online-Speicher. Gute Beispiele sind Dropbox und Google Drive; diese gelten für gewöhnlich auch als in der Cloud beheimatet, haben aber mit Virtualisierung nichts zu tun.

Objectstores wie RADOS eignen sich besonders gut für Online-Speicher, weil nur sie die benötigte Scale-Out-Funktionalität liefern. Schließlich kann der Betreiber eines solchen Services nur ungefähr abschätzen, wie sich der Speicherbedarf seiner Plattform entwickeln wird. Denn jederzeit kann sich ein neuer Kunde anmelden, der etliche Giga- oder Terabyte an Speicher benötigt. Die Ceph-Entwickler haben diese Verbindung erkannt und bieten in Form des RADOS-Gateways einen entsprechenden Dienst für RADOS an. Wer einen Dienst für Online-Speicherplatz plant, liegt mit der Kombination aus RADOS und dem dazu gehörenden Gateway also goldrichtig.

Die Architektur des RADOS-Gateways

Wie eingangs bereits erwähnt, ist das RADOS-Gateway ein Client, der sich im Hintergrund mit dem eigentlichen Objectstore verbindet und nach außen hin ein eigenes Interface für den HTTP-Zugriff exponiert. Das RADOS-Gateway benutzt FCGI. Grundsätzlich kann jeder FCGI-kompatible Server zum Einsatz kommen.

Daraus ergibt sich, dass das RADOS-Gateway (RGW) nicht selbst HTTP-Requests von Clients annimmt, sondern lediglich als Brücke zwischen Webserver und RADOS-Speicher fungiert. Bemerkenswert ist auch, dass das RGW hierzu eine eigene Benutzerverwaltung implementiert: Während die Kommunikation zwischen RADOS und RGW über CephX [1] abgesichert ist, müssen für RGW-Benutzer eigene Accounts auf RGW-Ebene existieren – die beiden Ebenen der Authentifizierung sind nicht miteinander zu verwechseln. Ein angelegter Nutzer in CephX hat nicht automatisch Zugriff über das RADOS-Gateway. De facto ist es gar nicht möglich, einem CephX-Nutzer Zugriff per RGW einzuräumen. Freilich ist es aber kein Problem, in RGW und CephX überlappende Benutzernamen zu haben. Ein Benutzer »karl« auf CephX-Ebene verhindert also nicht, dass auch auf RGW-Ebene ein Nutzer »karl« existiert.