Der RADOS-Objectstore und Ceph, Teil 5

© tiero, 123RF

Speicher-Logistik

Teil 5 des RADOS- und Ceph-Workshops legt das Hauptaugenmerk auf das RADOS-Gateway: Mit ihm es möglich, einen Objectstore über eine ReSTful-API anzusprechen. Dadurch ist RADOS kompatibel zu Amazon S3 und zu OpenStack Swift.
Mit Hardware-Beschleunigung und schnellem Netz hilft Desktop-Virtualisierung, Administrationsaufwand und Kosten sparen, ADMIN 04/2013 verrät, wie die ... (mehr)

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.

Listing 2

Keystone und das RADOS-Gateway

Das RADOS-Gateway als Ersatz für OpenStack Swift

Der Artikel beschäftigt sich im Wesentlichen mit der Frage, wie sich ein RADOS-Gateway als Ersatz für Amazon S3 nutzen lässt. Bekanntlich kann das RADOS-Gateway aber auch OpenStacks Swift-Protokoll verstehen, sodass es als Dropin-Ersatz für ein echtes Swift fungiert. Wer OpenStack und RADOS in Kombination nutzt, erspart sich auf diese Weise den zweiten Objectstore im Setup und hat nur einen, zentral verwalteten Speicher.

Die Konfiguration dieser Lösung ist im Grunde baugleich mit der, die im S3-Falle zum Einsatz kommt. Das RADOS-Gateway muss aber zusätzlich lernen, sich mit OpenStacks zentraler Authentifizierungsschnittstelle Keystone zu unterhalten. Seit der Bobtail-Version beherrscht das RADOS-Gateway genau jene Funktion. Das Listing 2 enthält die beispielhaften Einträge für »ceph.conf« im »client.radosgw.charlie« -Abschnitt. Das Beispiel geht davon aus, dass Keystone auf dem Host »Alice« läuft. Die Werte für den DNS-Namen, die Keystone-URL und das Admin-Token sind entsprechend an die lokale Konfiguration anzupassen. Ein Neustart des RADOS-Gateway ist danach notwendig.

 

Dann benötigt OpenStack Keystone in seiner Endpunkte-Datenbank noch die Information, mit welcher ReSTful-URL sich Clients verbinden sollen, die mit Swift sprechen wollen. Achtung: Der Endpunkt für das RADOS-Gateway unterscheidet sich von dem für einen echten Swift. Die folgenden Befehle fügen die nötigen Endpunkte hinzu:

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

Schließlich gilt es noch eine Besonderheit zu beachten: Keystone stellt für Clients, die sich anmelden, sogenannte Tokens aus, die die Clients im Anschluss über einen bestimmten Zeitraum – meist über 24 Stunden – nutzen können, um sich bei anderen OpenStack-Diensten direkt anzumelden. Das RADOS-Gateway übernimmt diese Tokens und nutzt sie, um den Zugriff zu regeln.

Damit das Gateway weiß, wann ein bestimmtes Token nicht mehr gültig ist, synchronisiert es regelmäßig direkt von Keystone eine Liste der gültigen Token. Diese Liste ist SSL-signiert – damit das RADOS-Gateway die Signatur überprüfen kann, muss es das Zertifikat und die dazugehörige, meist lokal generierte CA kennen. Die folgenden Befehle sorgen dafür, dass das der Fall ist:

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"

Im Anschluss steht der Nutzung von RADOS-Gateway als direktem Ersatz für OpenStack Swift nichts mehr im Wege.

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.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
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

Google+

Ausgabe /2019