ADMIN

2023

04

2023-03-30T12:00:00

Storage

SCHWERPUNKT

064

Storage

Speicherlösung

Cloud

Neuerungen in Ceph

Ordentlich geschraubt

von Martin Loschwitz

Veröffentlicht in Ausgabe 04/2023 - SCHWERPUNKT

Ceph und seine Kernkomponente RADOS gelten bis heute als mustergültiges Beispiel für die Open-Source-Implementation eines Objektspeichers. In der jüngeren Vergangenheit hat sich beim Projekt allerdings einiges getan – technisch wie auch organisatorisch. Wir schauen genauer hin, was die Umstellung auf Container, das neue Setup und andere Feature-Verbesserungen bringen.

Wer an Objektspeicher denkt, hat zumindest im Open-Source-Kontext heute immer auch Ceph im Sinn. Das nach der Tierfamilie der Caphalopoden benannte Produkt hat sich einen Ruf als zuverlässige Software erarbeitet, die sich hinter proprietären und kommerziellen Angeboten nicht zu verstecken braucht. Mancher Beobachter tendiert dabei dazu, die durchaus umfangreiche Geschichte der Umgebung zu vergessen: In den Augen vieler ist Ceph noch immer recht jung. Tatsächlich existiert Ceph aber schon seit mehr als 15 Jahren. Kommerziell vermarktet wird es ebenfalls schon seit über zehn Jahren. Ein Newcomer ist die Software also nicht, sondern ganz im Gegenteil gut etabliert.
Still und leise geht es bei Ceph hingegen keinesfalls zu. Bis heute überraschen die Entwickler immer wieder mit Feature-Feuerwerken nach relativ kurzer Zeit. Grund genug, einmal genauer hinzusehen, was sich in den letzten Wochen und Monaten bei Ceph getan hat – und zwar sowohl im Hinblick auf jene, die an Ceph arbeiten, als auch im Hinblick auf das Produkt selbst. Welche neuen Optionen stehen Administratoren heute zur Verfügung, verglichen etwa mit etwas älteren Ceph-Versionen wie Nautilus, und wie kommen Administratoren in den Genuss jener Neuerungen und Verbesserungen?
Übernahme Schritt für Schritt
Etwas untypisch beginnt dieser Artikel mit den organisatorischen Aspekten hinter den Ceph-Kulissen. Denn hier hat sich in den vergangenen Monaten mindestens ebenso viel verändert wie auf der technischen Seite. Der Grund dafür liegt auf der Hand: Nachdem Red Hat vor etlichen Jahren den damaligen Ceph-Anbieter Inktank geschluckt hatte, lief das Unternehmen zunächst als Firma in der Firma weiter. Der Ansatz war für Red Hat nicht ungewöhnlich: Etliche Male hat Red Hat in der Vergangenheit darauf verzichtet, Unternehmen unmittelbar nach der Akquisition in die eigene Organisationsstruktur zu integrieren. Aus gutem Grund, schließlich hätte es unmittelbar nach der Übernahme von Inktank in Red Hat selbst ohnehin kaum Teams gegeben, in die Inktank hätte integriert werden können. Praktisch sämtliche Ceph-Gurus und jedenfalls das Gros der Upstream-Entwickler standen zum damaligen Zeitpunkt schließlich bei Inktank auf der Gehaltsliste. Erst über die Jahre wurden im Unternehmen einige Strukturen gestrafft: Teile des Vertriebs etwa wechselten formal von Inktank zu Red Hat wie auch Teile des Marketings.
Wer an Objektspeicher denkt, hat zumindest im Open-Source-Kontext heute immer auch Ceph im Sinn. Das nach der Tierfamilie der Caphalopoden benannte Produkt hat sich einen Ruf als zuverlässige Software erarbeitet, die sich hinter proprietären und kommerziellen Angeboten nicht zu verstecken braucht. Mancher Beobachter tendiert dabei dazu, die durchaus umfangreiche Geschichte der Umgebung zu vergessen: In den Augen vieler ist Ceph noch immer recht jung. Tatsächlich existiert Ceph aber schon seit mehr als 15 Jahren. Kommerziell vermarktet wird es ebenfalls schon seit über zehn Jahren. Ein Newcomer ist die Software also nicht, sondern ganz im Gegenteil gut etabliert.
Still und leise geht es bei Ceph hingegen keinesfalls zu. Bis heute überraschen die Entwickler immer wieder mit Feature-Feuerwerken nach relativ kurzer Zeit. Grund genug, einmal genauer hinzusehen, was sich in den letzten Wochen und Monaten bei Ceph getan hat – und zwar sowohl im Hinblick auf jene, die an Ceph arbeiten, als auch im Hinblick auf das Produkt selbst. Welche neuen Optionen stehen Administratoren heute zur Verfügung, verglichen etwa mit etwas älteren Ceph-Versionen wie Nautilus, und wie kommen Administratoren in den Genuss jener Neuerungen und Verbesserungen?
Übernahme Schritt für Schritt
Etwas untypisch beginnt dieser Artikel mit den organisatorischen Aspekten hinter den Ceph-Kulissen. Denn hier hat sich in den vergangenen Monaten mindestens ebenso viel verändert wie auf der technischen Seite. Der Grund dafür liegt auf der Hand: Nachdem Red Hat vor etlichen Jahren den damaligen Ceph-Anbieter Inktank geschluckt hatte, lief das Unternehmen zunächst als Firma in der Firma weiter. Der Ansatz war für Red Hat nicht ungewöhnlich: Etliche Male hat Red Hat in der Vergangenheit darauf verzichtet, Unternehmen unmittelbar nach der Akquisition in die eigene Organisationsstruktur zu integrieren. Aus gutem Grund, schließlich hätte es unmittelbar nach der Übernahme von Inktank in Red Hat selbst ohnehin kaum Teams gegeben, in die Inktank hätte integriert werden können. Praktisch sämtliche Ceph-Gurus und jedenfalls das Gros der Upstream-Entwickler standen zum damaligen Zeitpunkt schließlich bei Inktank auf der Gehaltsliste. Erst über die Jahre wurden im Unternehmen einige Strukturen gestrafft: Teile des Vertriebs etwa wechselten formal von Inktank zu Red Hat wie auch Teile des Marketings.
Bekanntlich hat zwischenzeitlich aber IBM seinerseits Red Hat übernommen. Und so sehr IBM stets betont, die "DNA gekaufter Unternehmen erhalten" zu wollen, so wenig steht Big Blue im Verdacht, eben das flächendeckend zu praktizieren. So kam es, wie es kommen musste, und nach einer gewissen Schonfrist kündigte IBM umfangreiche Änderungen sowohl in der Unternehmensstruktur als auch beim Portfolio an. Zunächst wechselte der komplette Storage-Vertrieb von der Red-Hat-Seite hin zu den etablierten IBM-Storage-Teams.
IBM begründete diesen Schritt mit im ersten Moment durchaus schlüssigen Argumenten. Aktuell, so die Behauptung, müssten zu Kunden mit IBM- und Red-Hat-Produkten verschiedene Sales-Teams reisen, die zum Teil aber dieselben Produkte oder Abwandlungen davon vorstellten. Stattdessen sollen Kunden künftig direkt von IBM das gesamte Storage-Portfolio des Anbieters beziehen können, auch wenn das Produkt ursprünglich von Red Hat stammte. Red Hat fiehl aus der Kommunikation im Vertrieb als Faktor praktisch heraus. Das schmeckte längst nicht jedem und so beteuerte IBM, dass die Ansprechpartner für schon bestehende Kunden dieselben bleiben, sowohl vertrieblich als auch in der Technik. Doch wäre es nicht das erste mal, dass solche Versprechen einer späteren "Reorganisation" zum Opfer fallen.
Bild 1: "cephadm" ersetzt im Gespann mit "ceph-mgr" die Deployment-Werkzeuge für Ceph und erlaubt es über einfache CLI-Befehle, Ceph-Daemons und OSDs anzulegen.
Weniger Ceph, mehr IBM
Und apropos Reorganisation: IBM dreht auch am Produktportfolio der roten Hüte. So soll Ceph künftig verstärkt als Software im Bundle mit Storage-Hardware von Big Blue vermarktet werden. Als eigenständiges Produkt samt kommerziellen Support soll es Ceph nur noch in Kombination mit Red Hats OpenStack-Plattform geben. Was für einige Unternehmen ein herber Schlag sein dürfte, denn längst nicht jede Firma betreibt im Gespann mit Ceph schließlich auch die Private-Cloud-Umgebung OpenStack. Explizit hatte Red Hat bisher darauf hingewiesen, dass Ceph in Form von Red-Hat-Storage auch ohne OpenStack zu bekommen ist, und vermutlich ist die Zahl der aktiven Nutzer dieser Lösung höher als jene der Cloudkombination. Kein Problem, beteuert IBM, an bestehenden Verträgen werde nicht gerüttelt. Echte Gewissheit, dass IBM den bisherigen Standalone-Ceph-Installationen nicht den Hahn zudreht, haben Administratoren aber nicht. Dass dies mancherorts zu flauem Gefühl im Magen führt, ist nachvollziehbar.
Panik scheint indes unangebracht. Zwar ist Inktank als Teil von Red Hat als Teil von IBM noch immer der alleinige Ceph-Upstream. Unternehmen, die Consulting für Ceph anbieten, gibt es aber auch abseits von Raleigh. Das umfasst sowohl kleine, externe Dienstleister als auch große Unternehmen wie Canonical. Und zumindest ein paar eben jener Firmen werden aller Voraussicht nach auch dafür sorgen, dass sich Ceph mit kommerziellem Support weiterhin ohne OpenStack nutzen lässt. Der Ansatz, den kleinere Consultingfirmen im Hinblick auf Ceph fahren, mag hierzulande bei vielen Ceph-Nutzern ohnehin besser ankommen. Während in den USA die typischen All-in-Verträge noch immer weitverbreitet sind, geht es hierzulande deutlich individueller zu. Das führt in manchem Fall dazu, dass unabhängige Dienstleister kommerziellen Support für Setups bieten, bei denen die roten Hüte bei IBM bloß noch abwinken.
Und apropos Abwinken: Eine Ceph-Personalie machte vor einer Weile die Runde in der Community und versetzte diese zumindest kurzzeitig in Aufruhr. Niemand Geringeres als Ceph-Erfinder Sage Weil gab nämlich bekannt, er wolle sich absehbar komplett aus der Ceph-Entwicklung zurückziehen und das Ruder anderen überlassen. Im Rahmen des US-Präsidentschaftswahlkampfes habe er in verschiedenen Gruppen zur Mobilisierung von Wählern mitgearbeitet und dabei Interesse an Wahl- und Bürgerrechtsfragen gewonnen. Und in eben diesen Themengebieten ist Weil aktiv, seit er der IT mehr oder weniger stark den Rücken gekehrt hat. Aufgehört zu drehen hat die Ceph-Welt sich ob des Abgangs ihres Hexenmeisters zum Glück aber nicht. Weil die Rechte an Ceph mittlerweile zudem einer Stiftung nach US-Recht gehören, darf Ceph als unabhängig genug gelten, um selbst herbe Einschläge beim verfügbaren Personal zu verkraften. Das Open-Source-Prinzip zeigt sich hier in Aktion und von seiner besten Seite.
Bild 2: Geht es nach den roten Hüten, läuft Ceph künftig in Container-Form. Für Admins bringt das Umgewöhnung, für den Hersteller ist es praktisch.
Manche vermuten in der Herauslösung der Storage-Truppe aus Red Hat übrigens den Anfang der Red-Hat-Filetierung durch IBM. Es wäre schließlich auch nicht das erste Mal, dass IBM einen Konkurrenten kauft, ausweidet und den unprofitablen Rest anschließend weiter verramscht. Zumindest im Moment gibt es für diese These allerdings keine echten Anhaltspunkte. Denn seit Red Hat zu IBM gehört, wächst es als dessen Sparte noch stärker als zuvor und erreicht jährlich zweistellige Wachstumsraten. Gut möglich, dass früher oder später weitere Teile von Red Hat in IBM aufgehen werden. Als Abkehr von den Technologien, die IBM sich mit Red Hat ins Haus geholt hat – und dazu gehört auch Ceph –, ist das aber nicht zu werten.
Neues Auslieferungsformat, neues Setuptool
Angesichts der Meldung, Ceph habe ein neues Setuptool, vermögen alte Hasen im Ceph-Geschäft vermutlich bloß noch gelangweilt zu gähnen. Wer sich seit ein paar Jahren mit der Software beschäftigt, hat schließlich schon viele Werkzeuge kommen und wieder gehen sehen: "mkcephfs", "ceph-install", "ceph-deploy" – und hier sind die Tools von Distributoren noch gar nicht erwähnt. Mit Puppet, Chef und Ansible lässt Ceph sich schließlich ebenfalls ausrollen. Nun aber, so versprechen die Entwickler, sei das Deployment-Werkzeug erschienen, das gekommen ist, um zu bleiben: "cephadm" (Bild 1).
Wobei "cephadm" nur die halbe Wahrheit ist. Streng genommen enthält "cephadm" wirklich nur jenen Teil der Funktionalität, der nötig ist, um die grundlegenden Dienste auf einem Host zum Laufen zu bringen. Wenn "cephadm" seine Arbeit erledigt hat, übernimmt die Managementkomponente, auch "ceph-mgmt" genannt. Hier haben die Entwickler sich nicht lumpen lassen: De facto handelt es sich bei "cephadm" und "ceph-mgmt" im Tandem nämlich um ein eigenes Automations- und Orchestrierungsframework, das Ansible und Co. zumindest für den Ceph-Teil eines Setups quasi ersetzt.
Mit der Einführung von "cephadm" geht allerdings eine weitere Änderung einher, die längst nicht jedem Admin schmecken dürfte und die bereits für ausführliche Diskussionen auf der Ceph-Mailingliste gesorgt hat. Red Hat zieht seine "Container first"-Strategie nämlich auch bei Ceph gnadenlos durch. Red Hat Storage etwa ist bereits komplett containerisiert. Die Installation rollt nicht mehr Pakete im RPM- oder Deb-Format auf dem System aus, sondern installiert Podman als Laufzeitumgebung für Container und startet die benötigten Ceph-Dienste danach in Container-Form (Bild 2). Aus Sicht des Administrators bringt das so manchen schrägen Effekt mit sich.
So ist es nicht mehr möglich, auf der Kommandozeile ceph -w aufzurufen, weil es das "ceph"-Binary im System schlicht nicht gibt. Zuvor ist stattdessen cephadm shell nötig, um einen lokalen Container mit der Shell zu starten, in dem ceph dann auch funktioniert. Zugegeben, das Problem ist relativ leicht zu umgehen. Installieren Sie "ceph-common" und sorgen dafür, dass in "/etc/ceph" die passende "ceph.conf" samt Schlüssel des CephX-Nutzers "client.admin" liegen, funktioniert "ceph" auch wieder unmittelbar von der Kommandozeile aus. Dass sämtliche Ceph-Dienste in Containern laufen, hat aber auch noch andere Implikationen. Wer die Systemmeldungen dieser Dienste sehen möchte, muss deren Containern mit podman logs auf die Pelle rücken, denn in Textdateien finden die Meldungen sich nicht mehr.
Bild 3: Das übersichtlich gestaltete Dashboard ist eine gute Möglichkeit zum Anzeigen der wichtigsten Clusterwerte.
Praktisch für den Anbieter
Warum vollzieht Red Hat dann aber diesen Schritt? Aus Sicht des Anbieters bietet er so viele Vorteile, dass es beinahe fahrlässig wäre, ihn nicht zu vollziehen. Alleine der Aufwand, Ceph als Software zu pflegen, reduziert sich durch die Container-Zwischenschicht massiv. Schließlich muss ein System, damit es Ceph ausführen kann, beim Container-Ansatz nur noch über eine Laufzeitumgebung eben für Container verfügen, und das ist auf allen RHEL-Versionen der Fall. Auch SUSE, Ubuntu & Co. lassen sich mit Podman oder Docker CE fit für Container machen.
So ist es de facto ausreichend, alle unterstützten Ceph-Versionen in nur noch genau einer Variante zu pflegen, anstatt in vielen unterschiedlichen Versionen und Paketen für diverse Distributionen. Genau das ist auch der Grund dafür, dass Red Hat und letztlich IBM von diesem Ansatz wohl eher nicht mehr abrücken werden. Schon hat Raleigh entsprechend angekündigt, das Deployment-Szenario in Form klassischer Pakete sei "legacy", wonach üblicherweise bald die Zustände "deprecated" und schließlich "unsupported" folgen. Immerhin ist es möglich, ein bestehendes Setup mittels "cephadm" in das neue Format umzubauen. Hierfür enthält die Ceph-Dokumentation entsprechende Anleitungen.
Veränderungen unter der Haube
Bei allen Ausführungen rund um die Ceph-Meta-Ebene entsteht schnell der Eindruck, technisch entwickele Ceph sich im Grunde nicht mehr weiter. Weit gefehlt: Sowohl RADOS als Objektspeicher im Herzen der Lösung als auch die Standard-Frontends Ceph Block Device, Ceph Object Gateway und CephFS haben in der jüngeren Vergangenheit erhebliche technische Fortschritte erfahren. Ein genauerer Blick auf die einzelnen Komponenten verdeutlicht das schnell.
So haben die Entwickler konstant am On-Disk-Format von Ceph-OSDs geschraubt und die dort zu findenden Dateien kleiner und effizienter gemacht. Ceph nutzt seit ein paar Releases bekanntlich ein eigenes Mini-Dateisystem namens BlueFS auf seinen OSDs, das gesamte Konstrukt nennt sich dann "BlueStore". Dank BlueStore braucht ein OSD in Ceph kein POSIX-kompatibles Dateisystem mehr auf seinem Blockgerät. In BlueStore kommt alternativ eine Zuordnungstabelle auf RocksDB-Basis zum Einsatz, die die gespeicherten Objekte und deren physische Adresse auf dem Datenträger für jedes abgelegte Objekt enthält. Weil RocksDB auch ein Write-Ahead-Log (WOL) enthält, bringt es Journaling-Fähigkeiten für Szenarien mit, in denen einzelne Komponenten der Umgebung ausfallen. Der Mühe Lohn: OSDs gehen auf ihren Speichergeräten heute wesentlich flinker ans Werk als im alten Konzept auf Basis von XFS.
Verbesserte Werkzeuge
Obendrein haben die Ceph-Entwickler einige Werkzeuge und besonders deren Ausgabe auf der Kommandozeile erheblich verbessert. "ceph" zeigt für Recovery- und Resync-Vorgänge nun Fortschrittsbalken an, was der Übersichtlichkeit zuträglich ist. Die Anzeige aller Placement Groups (PGs) im Cluster mittels ceph ph dump ist zwar immer noch ziemlich lang, bringt nun aber schon etwas weniger Spalten auf den Schirm und passt so zumindest auf Widescreen-Displays.
Änderungen ergeben sich zudem beim Handling von PGs. Das ist Cephs Einheit, um Objekte logisch zu bündeln und über die eigenen Speichergeräte, also die OSDs, zu verteilen. Am Anfang der Ceph-Entwicklung musste der Administrator die Anzahl der insgesamt im Cluster vorhandenen Ceph-PGs noch händisch festlegen. Dabei war einerseits problematisch, dass mehrere Formeln kursierten, wie denn die ideale Anzahl zu berechnen sei. Und andererseits war es anfangs weder möglich, die Zahl bestehender PGs nachträglich zu reduzieren noch unter Beibehaltung der Anzahl der OSDs zu erhöhen.
Beide Features sind mittlerweile aber implementiert. Wer sich an bestimmte Limits nach unten wie nach oben hält, kann die Anzahl der PGs in seinem Cluster frei festlegen. Einfluss auf die verfügbare Performance haben die PGs allerdings noch immer. Heute stellt RADOS dem Administrator auf Basis des "ceph-mgmt"-Frameworks deshalb einen automatischen Skalierer für die PGs zur Seite. Seit Ceph Octopus ist dieser standardmäßig zudem aktiviert. Das Schrauben an der Anzahl der insgesamt vorhandenen Placement Groups dürfte für das Gros der Admins also der Vergangenheit angehören. Lediglich in seltenen Spezialsetups wird sich mehr aus der Installation herauskitzeln lassen, als der Autoskalierer einstellt.
Ceph Block Device: Spiegelung und bessere Snapshots
Das Ceph Block Device oder RADOS Block Device (RBD), wie es manchem Ceph-Erfahrenen noch geläufig sein dürfte, wartet mit etlichen neuen Features im Hinblick auf das Spiegeln von Volumes auf. Einerseits haben die Entwickler dazu die Snapshot-Fähigkeiten erheblich verbessert. Zwar waren Snapshots in RBD schon immer inkrementell, doch hat Red Hat einmal mehr sowohl an der Performance- als auch an der Storage-Schraube gedreht. Insofern benötigen Snapshots in RBD heute weniger Platz als zuvor und bieten ein Quäntchen mehr Speed.
Gleichzeitig kommt das einst rudimentäre "rbd-mirror" heute als komplette Spiegelsuite daher, die RBD-Volumes und insbesondere deren Snapshots zwischen zwei Ceph-Clustern synchron hält. Davon profitieren Unternehmen, die zwei Cephs an unterschiedlichen Standorten betreiben und eines davon als Disaster-Recovery-Setup für das andere nutzen. Von einem RBD-Snapsot auf Site B lässt sich nämlich ohne weiteres eine VM starten, wenn Site B ausfällt. Wer seine VMs nicht komplett händisch verwaltet, ist aber darauf angewiesen, dass die eigenen Management-Tools für VMs diese Spiegelfunktionalität beherrschen. Bei OpenStack beispielsweise ist das mittlerweile der Fall.
CephFS: Mehr Dateisysteme pro Cluster
CephFS war einst die Keimzelle für das gesamte Ceph-Konstrukt. In den frühen Inktank-Jahren musste es als RADOS-Frontend jedoch hinter RBD und dem Object Gatway anstehen, weil es den geringsten Nutzen im Kontext privater Cloudsetups hatte. Gerade die wollte seinerzeit aber beinahe jeder haben. So hat es etliche Jahre gedauert, bis Inktank sich traute, CephFS endlich mit der Versionsnummer 1.0 zu versehen und für reif für den produktiven Einsatz zu erklären. Kritiker sahen die 1.0 von CephFS seinerzeit allerdings eher als "Rumpf-Release" mit stark eingedampftem Funktionsumfang. Viele der vermissten Features wurden mittlerweile aber nachgereicht. Seit kurzem ist es entsprechend möglich, innerhalb eines RADOS-Clusters mehrere CephFS-Dateisysteme zu betreiben.
Was wie ein Detail klingt, hat praktisch handfeste Auswirkungen. Zuvor konnte auf einem RADOS-Cluster nur genau ein CephFS angelegt werden. Dieser Ansatz scheitert in vielen Unternehmen aber schon ganz banal am Compliance-Thema. So ist nicht selten vorgeschrieben, dass es eine logische Trennung zwischen den eigenen Daten und den Daten anderer in der Cloud geben muss. Nur mittels ACLs und POSIX-Rechten ist das aber kaum sinnvoll zu implementieren. Besser geeignet ist ein eigenes Dateisystem pro Kunde mit eigenem CephX-Schlüssel. Dann unterbindet RADOS bereits auf der Ebene des Objektspeichers den Zugriff auf solche Objekte, mit denen zugreifende Clients nichts zu schaffen haben. Mittlerweile hat auch dieses Feature die Reife für den produktiven Einsatz erreicht. Das ermöglicht obendrein, unterschiedliche Dienste wie NFS und Samba in der eigenen Umgebung durch CephFS zu ersetzen, ohne dass die Inhalte der verschiedenen CephFSe sich ins Gehege kommen.
Bild 4: Mittlerweile lassen sich per Dashboard auch Änderungen am Cluster vornehmen, etwa bei OSDs. Auch im Bild zu sehen ist der Placement-Group-Autoscaler bei der Arbeit.
Ceph Object Gatway: Mini-CDN für Ceph
Massive Änderungen ergeben sich auch beim Ceph Object Gateway und hier insbesondere in der Art und Weise, wie Offsite-Replikation funktioniert. Das Gateway, oft auch unter dem alten Namen "RADOS Gateway" oder kurz "rgw" referenziert, war das erste Frontend in Ceph, das überhaupt die asynchrone Replikation über mehrere Standorte hinweg erlaubte. Und durchaus sinnvoll: Das Gatway erlaubt bekanntlich den ReST-basierten Zugriff auf Objekte in RADOS unter Emulation von AWS S3.
Letzteres hat sich in vielen Webanwendungen als Assetspeicher durchgesetzt. Üblich ist es etwa, Bilder, Videos und andere unveränderliche Daten in kleine Speicher in regionaler Nähe zum Client zu packen und die jeweilige Webanwendung die passenden Links je nach Herkunft des Clients automatisch generieren zu lassen. Da ergibt die Option, Inhalte zwischen Standorten zu synchronisieren, natürlich Sinn.
Heute ist diese Funktionalität zwar kein eigenes Werkzeug mehr, sondern fest in "rgw" integriert. Beachtlich ist sie dennoch: Über Reals, Zonengruppen und Zonen lassen sich spezifische Buckets oder ganze Pools zwischen RADOS-Instanzen replizieren. Es existiert in der Ceph-Dokumentation sogar eine Blaupause, wie sich ein solches Setup um Nginx erweitern lässt. Dann wird aus RADOS eine Art Mini-CDN, das massiv skalierbar ist und in Sachen Performance für die Anforderungen von HTTP und HTTPS ausreicht.
Das Dashboard macht sich
Nicht zuletzt muss auch das Dashboard kurz zur Sprache kommen. Das einst aus OpenAttic hervorgegangene Werkzeug hat von dessen Code heute zwar vermutlich nicht mehr sonderlich viel an Bord. Überproportional dazu gewachsen ist aber die vielfältige Funktionalität, mit der das offizielle Ceph-Dashboard heute auftrumpft. Neben Monitoring, Alerting und Trending (MAT) auf Basis von Prometheus und Grafana bietet es mittlerweile sogar die Möglichkeit, einige Konfigurationsdetails des Clusters zu verändern (Bilder 3 und 4).
Weil das Hinzufügen neuer OSDs nach "ceph-mgmt"-Logik ohnehin immer derselbe Ablauf ist, lässt der Prozess sich nunmehr zum Beispiel auch aus dem Dashboard heraus starten. Basale Änderungen der CRUSH-Map sind ebenso möglich. Kontinuierlich feilen seine Entwickler zudem an der UX des Dashboards. Davon zeugen gelegentliche Änderungen am Design ebenfalls wie jene an den Menüs des Programms. Als vollständiger Ersatz für die Shell eignet sich das Dashboard zwar noch immer nicht, aber letztlich ist das auch gar nicht sein Anspruch. Obendrein gehört es zum Standardumfang eines normalen, mittels "cephadm" und "ceph-mgmt" ausgerollten Ceph-Setups. Wer also beispielsweise ein Ceph-Monitoring-Dashboard braucht, um es im Operations-Room auf einem großen Fernseher darzustellen, ist mit dem Ceph-Dashboard gut bedient.
Fazit
Ceph hat sich in der jüngeren Zeit qualitativ erheblich weiterentwickelt. Viele klassische "Nice to have"-Features wurden mittlerweile nachgereicht und die organisatorischen Veränderungen hinter den Kulissen sind kein Indikator dafür, dass der Eifer des Herstellers bald nachlassen könnte. Zu tun gibt es allerdings noch immer so manches. So sehr die Ceph-Entwickler nämlich auch an den vielen Performanceschräubchen der Software drehen, ist RADOS die massive Latenz, die vor allem durch den Transportweg Ethernet einerseits und den internen Algorithmus CRUSH andererseits entsteht, bis heute nicht losgeworden. Gelängen den Entwicklern hier spürbare Verbesserungen, würde das Ceph nochmals eine komplett neue Zielgruppe eröffnen. Aktuell ist in dieser Hinsicht aber keine sonderliche Aktivität seitens des Herstellers zu vernehmen – es bleibt insofern spannend.
(dr)
Link-Codes