© Dmytro Dudchenko / 123RF.com

Die Zeiten großer Umbrüche bei Ceph sind vorbei, aktuell schneiden die Entwickler eher historisch gewachsene alte Zöpfe ab. Es gibt aber auch neue Features, etwa in Sachen Performance und bei Cephs eingebauter Automation.

Nichts ist so stetig wie der Wandel, und auf die IT trifft diese Weisheit noch mehr zu als auf andere Branchen. Einst hippe Lösungen wie OpenStack haben den Zenit ihres Hype-Zyklus längst überschritten, bei anderen Lösungen wie Kubernetes bahnt sich das zumindest an. Auch Ceph löst heute bei vielen Admins längst nicht mehr die Euphorie der frühen Tage aus. Klar: Anfangs galt es als neu, hip und innovativ, weil es skalierbaren Speicher versprach, ohne eine Verbindung zu den bis dahin etablierten Speicherlösungen zu haben. Wer von SANs, Fibre Channel und komplizierten Management-Werkzeugen die Nase voll hatte, fand in Ceph eine Lösung, die sich erfrischend anders präsentierte und obendrein keine spezielle und teure Hardware mehr benötigte.

Mittlerweile gilt Ceph in der IT aber als Commodity, also als etablierte Lösung für spezifische Einsatzbereiche, und längst gibt es einen Markt für Trainings ebenso wie für Fachpersonal mit Ceph-Wissen. Da wundert es kaum, dass selbst neue Ceph-Releases nicht mehr mit der einstigen Feature-Kanonade punkten, sondern es etwas ruhiger angehen lassen. Die frisch erschienene Ceph-Version 17.2 [1] zeugt genau davon: Statt an großen Rädern drehten ihre Entwickler hier eher an Rädchen, allzu viel ändert sich für Admins bestehender Cluster nicht. Lediglich wer sehr alte Ceph-Cluster betreibt und dort noch auf das alte On-Disk-Format FileStore (Abbildung 1) setzt, sieht sich zur unmittelbaren Aktion veranlasst. Wieso das der Fall ist und womit Admins bei Ceph 17.2 sonst noch rechnen müssen und dürfen, erläutert dieser Artikel.

Abbildung 1: FileStore heißt das alte On-Disk-Format für Ceph, bei dem auf den OSDs noch ein POSIX-kompatibles Dateisystem zum Einsatz kam.

Goodbye, FileStore

Obwohl das im Alltag noch gar keine praktischen Konsequenzen hat, zählt zu den wichtigsten Neuerungen in Ceph 17.2 zweifelsohne, dass das alte On-Disk-Format FileStore aus den frühen Ceph-Tagen nun als “deprecated” markiert ist. Eigner Red Hat lässt keinen Zweifel daran, dass FileStore früher oder später aus Ceph entfernt werden wird, und fordert Admins bestehender Systeme dringend auf, ihre Ceph-Festplatten auf den aktuellen Stand der Technik zu bringen.

Zur Erinnerung: Wie jede Speicherlösung setzt auch Ceph im Hintergrund auf Blockspeicher, um seine Daten irgendwo abzulegen. Als Objektspeicher ist aber die zentrale Funktion der Lösung, eine Abstraktionsschicht zwischen den physischen Speichern einerseits und den auf sie zugreifenden Clients andererseits einzuziehen. Die Clients brauchen sich dabei um die physische Architektur des Clusters nicht zu kümmern, und der Admin kann beinahe beliebig viele physische Geräte als Storage-Device im Hintergrund verwenden. Die allermeisten Ceph-Cluster setzen heute zumindest für Massenspeicher weiter auf langsame Festplatten, weil der Break Even gemessen an den Kosten pro Gigabyte bei flotten Speichern auf Flash-Basis noch nicht erreicht ist.

Damit der zu Ceph gehörende Objektspeicher RADOS seine Daten auf Blockgeräten ablegen kann, benötigt er darauf eine Struktur. Frühere Ceph-Versionen setzen hier auf ein klassisches Dateisystem nach POSIX-Standard. Das galt es auf dem jeweiligen Datenträger zunächst anzulegen, um dem Objektspeicher RADOS das Ablegen von binären Objekten zu ermöglichen. Lange genug empfahlen die Entwickler den Einsatz von XFS zu diesem Zweck (Abbildung 2). Im Hintergrund jedoch schielte man eigentlich auf Btrfs, das in der Kombination mit RADOS ganz erhebliche Geschwindigkeitsvorteile versprach. Das Konstrukt aus einem POSIX-Dateisystem und den zu Ceph gehörenden Metadaten auf OSD-Blockgeräten erhielt im Nachhinein den Namen FileStore.

Abbildung 2: FileStore sollte eigentlich in Kombination mit Btrfs seine volle Schlagkraft entfalten. Doch dann flog Btrfs aus RHEL, sodass Ceph üblicherweise mit dem alles andere als optimalen XFS im Gespann auftrat.

Wie Red Hats Btrfs-Abenteuer endete, ist hinlänglich bekannt: Bereits seit Red Hat Enterprise Linux 8 liegt das Dateisystem der Distribution gar nicht mehr bei. Selbst in RHEL 7 hatte Btrfs es nur zum Status einer Technical Preview gebracht, in den Augen von Red Hat war das Dateisystem für den produktiven Einsatz also nie zu gebrauchen. Das wurde für die Ceph-Entwickler schnell zum Problem, denn der Notnagel XFS erwies sich immer häufiger als Performance-Bremse.

Das verwundert bei näherem Hinsehen wenig: RADOS ist so konzipiert, dass es für neue Daten auf seinen OSDs neue Verzeichnisse anlegt und neue Objekt-IDs vergibt, statt alte zu recyclen. Selbst wenn ein Benutzer also eine vorhandene Datei über eines der drei Standard-Interfaces in RADOS (CephFS, Ceph Block Device, Ceph Object Gateway) überschreibt, ersetzt RADOS im Hintergrund keine bestehenden Objekte. Viel mehr legt es die neuen Daten als gleichermaßen neues Objekt an und markiert die alten Daten als obsolet, sodass sie zeitnah überschrieben werden.

POSIX funktioniert nicht

Die Krux an der Sache: POSIX-kompatible Dateisysteme bieten für Fälle wie das Überschreiben vorhandener Daten viele Integritätschecks und Konsistenzgarantien, deren technische Umsetzung an der Performance knabbert. Ceph und sein altes Format FileStore befanden sich damit in einer Lose-Lose-Situation: Weil effektiv nur XFS als On-Disk-Dateisystem für OSDs zur Verfügung stand, musste man dessen Garantien im Hinblick auf Konsistenz und Integrität nutzen, obwohl das im Ceph-Kontext gar keinen Sinn ergab.

Vor ein paar Jahren riss den Ceph-Entwicklern dann endgültig der Geduldsfaden, und man begann mit der Arbeit an einem FileStore-Nachfolger. Die Idee dahinter: Statt eines aufgeblähten POSIX-Dateisystems würde es genügen, eine Art Datenbank in den Metadaten eines OSDs zu pflegen, die die physische Speicheradresse eines Objekts auf dem Datenträger enthält. Dafür würde ein Key-Value-Speicher völlig ausreichen, flankiert von einem Rumpfdateisystem, das das Ablegen der Daten auf dem physischen Gerät ermöglicht.

Es dauerte eine Weile, bis man sich auf die Kombination der richtigen Werkzeuge geeinigt hatte. Als Datenbank kam in der Zwischenzeit etwa LevelDB zum Einsatz, das den Entwicklern allerdings noch immer nicht schnell genug war und bald ebenfalls in Ungnade fiel. Das Rennen machte am Ende RocksDB, ein extrem flotter Key-Value-Speicher von Facebook, der das Herz des neuen On-Disk-Formats wurde. Um das neue Format deutlich vom alten zu unterscheiden, bekam es den klingenden neuen Namen BlueStore.

Bei Ceph-Anwendern schlug BlueStore bald ein wie eine Bombe: Krude Hacks wie das Auslagern der Journale des FileStore-Formats auf schnelle SSDs, waren dank der neuen Lösung nicht mehr notwendig. Für klassische Workloads ließen sich mit BlueStore auch ohne zusätzliche Hardware im Einzelfall Geschwindigkeitszuwächse von 50 Prozent und mehr erreichen (Abbildung 3). Hinzu kommt, dass die Entwickler FileStore kaum noch weiterentwickelten, weil sie es für eine tote Technologie hielten. Viel mehr als das unbedingt nötige Minimum, um FileStore funktional zu halten, hat sich seit Jahren in Ceph also kaum getan.

Abbildung 3: BlueStore ermöglicht in Ceph erhebliche Performance-Gewinne, drückt aber auch die Latenz beim Zugriff auf OSDs – die Latenz ist seit jeher die Achillesferse von Ceph . Quelle: Micron

Mehr Effizienz

Hinzu kommt, dass BlueStore seit einigen Releases in Ceph als Standard fungiert und die Ceph-Entwickler etwa auf der Mailing-Liste des Projekts bereits mehrfach öffentlich diskutierten, FileStore den Gnadenschuss zu verpassen.

Was aus Sicht der Anwender Sinn ergibt, ist auch aus Entwicklersicht nur folgerichtig: Bloß noch alte Setups, die die Admins zwischenzeitlich nicht migriert haben, dürften heute überhaupt noch FileStore nutzen – und für die lohnt es sich kaum, große Mengen an Code in Ceph weiter aktiv zu pflegen. Das gilt umso mehr, da BlueStore mittlerweile praktisch keine Features mehr fehlen, die in FileStore einst zur Verfügung standen. Wenn Admins heute also noch FileStore verwenden, geschieht das regelmäßig vor allem deswegen, weil sie sich bisher nicht die Zeit zum Update genommen haben oder nehmen konnten.

Eben diesen Admins rücken die Ceph-Entwickler in Ceph 17.2 nun allerdings auf die Pelle. Die Entscheidung, FileStore offiziell als “deprecated” zu markieren, ist ein klares Warnsignal und der eindeutige Hinweis darauf, dass laufende Ceph-Cluster mit FileStore von künftigen Updates ausgeschlossen sein werden. Wer also noch einen FileStore-basierten Cluster betreibt, beginnt idealerweise zeitnah damit, seine OSDs auf BlueStore zu konvertieren.

Wie es geht

Dafür bieten sich mehrere Möglichkeiten an. Wer seine Automation im Griff hat, setzt idealerweise auf den Ansatz, bestehende FileStore-OSDs aus dem Cluster zu entfernen und als BlueStore-OSDs neu anzulegen. Eine Mischung aus BlueStore und FileStore innerhalb desselben Clusters stellt aus Ceph-Sicht kein Problem dar, und alle zu Ceph gehörenden Deployment-Werkzeuge unterstützen das Anlegen neuer OSDs. Wer bereits auf das Deployment-Werkzeug Cephadm baut, das zu Cephs eigener Automationsumgebung Ceph-Mgr gehört, findet die passenden Befehle für das Ersetzen von OSDs darin ebenfalls.

Wichtig: Vor der Migration auf BlueStore sollte man seinen Cluster auf die neueste Ceph-Version aktualisieren, also auf 17.2. Danach lassen sich die einzelnen OSDs über die bekannten Werkzeuge auf der Kommandozeile entfernen und als neue OSDs dem Cluster wieder hinzufügen. Die üblichen Einschränkungen gelten: So sollte der Admin gerade in eher kleinen Installationen darauf achten, nur wenige OSDs gleichzeitig aus dem Cluster zu entfernen, um allzu große Recovery-Operationen im Backend zu vermeiden. Am Ende müssen so oder so alle Objekte mehrmals innerhalb des Clusters hin und her kopiert werden, um alle OSDs zu ersetzen. Wer diese Operation für zu viele OSDs gleichzeitig anstößt, läuft Gefahr, den laufenden Betrieb zu stören.

Eine explizite Option in Werkzeugen wie Cephadm oder Ceph, die bestehende OSDs von FileStore auf BlueStore umstellt, gibt es indes nicht. Das ist aus Sicht der Entwickler durchaus sinnvoll: Ein großer Vorteil von Ceph liegt ja gerade darin, dass bestehende OSDs ausfallen können, ohne dass Daten verloren gehen oder die Performance leidet. Aus Entwicklersicht wäre es insofern unsinnig, extra Code zu erschaffen, der eine triviale Operation ermöglicht.

Mehr Durchblick für den Admin

Mit zu den schwierigsten Aufgaben beim Betrieb eines Ceph-Clusters zählt es aus Sicht des Admins bis heute, sich schnell einen Überblick über den Zustand eines Clusters zu verschaffen. In den vergangenen Jahren hat sich hier einiges getan. Erinnert sei etwa an das Ceph-Dashboard, das die wichtigsten Vitalparameter des Clusters grafisch aufbereitet darstellt und dabei auch auf Daten aus Ceph-Mgr zugreift. Bis heute gilt aber auch: Wer einem Ceph-Cluster wirklich zu Leibe rücken möchte, kommt um die Kommandozeile nicht herum.

Ein ausgezeichnetes Beispiel dafür bietet der Befehl »ceph pg dump«. Unter der Haube teilt sich der Objektspeicher RADOS bekanntlich in mehrere Schichten auf, bevor es um die eigentlichen binären Objekte geht. Jedes binäre Objekt gehört dabei zu einer sogenannten Placement Group (»pg«), und Placement Groups sind logisch mittels der sogenannten Pools voneinander getrennt. Das hat vorrangig Performance-Gründe: Riesige Cluster enthalten schnell etliche Millionen von binären Objekten; würde RADOS selbst Entscheidungen wie jene, auf welchem OSD ein Objekt landet, also pro Objekt treffen, brächte das Performance-Einbußen mit sich und würde bei sehr großen Objektmengen gar nicht mehr funktionieren. Placement Groups verhindern das, und seit einigen Jahren beherrscht Ceph auch das dynamische Skalieren von PGs pro Cluster. Mittels »ceph pg dump« lässt der Admin sich für jede Placement Group im Cluster anzeigen, wie ihr aktueller Status ist, ob sie auf jenen OSDs liegt, die der CRUSH-Algorithmus für sie vorgibt, und ob gerade etwa ein Recovery stattfindet.

In Ceph 17.2 bekommt die Ausgabe des Werkzeugs eine neue Spalte dazu, die auch Auskunft darüber gibt, ob eine Placement Group gerade dem Ceph-eigenen Mechanismus zur Prüfung der Datenkonsistenz unterworfen ist, dem sogenannten Scrubbing. Scrubbing und insbesondere das gründlichere Deep Scrubbing können dazu führen, dass der Zugriff auf einzelne Placement Groups deutlich langsamer vonstatten geht als üblicherweise. Nicht selten haben Admins in der Vergangenheit umfassende Performance-Analysen angestoßen, um ein paar Minuten später zu merken, dass die Probleme verschwunden sind. Die erweiterte Anzeige von »ceph pg dump« hilft dabei, solche Probleme künftig zu vermeiden.

Aufgepasst bei Hyperkonvergenz

Admins hyperkonvergenter Setups achten in Ceph 17.2 besonders auf den Parameter »osd_memory_target_autotune« von Ceph-Mgr. Der ist ab Werk nun auf den Faktor »0.7« gesetzt. Auf Systemen mit dieser Einstellung konfiguriert Ceph-Mgr die OSDs so, dass sie insgesamt 70 Prozent des verfügbaren Hauptspeichers eines Systems in Beschlag nehmen.

Nun liegt der Sinn und Zweck hyperkonvergenter Setups freilich genau darin, neben dem Betrieb der Teile von Ceph auch den Betrieb virtueller Instanzen zu ermöglichen. Die indes werden kaum glücklich werden, wenn sie sich mit nicht einmal 30 Prozent des verfügbaren Speichers des Systems begnügen müssen: Der laufende Kernel und die zu ihm gehörenden Dienste wollen vom RAM schließlich auch noch etwas abhaben.

Hier zeigt sich einmal mehr, dass die Ceph-Entwickler hyperkonvergenten Setups sehr kritisch gegenüberstehen, auch wenn Red Hat solche mittlerweile offiziell unterstützt und als kostengünstige Alternative zu reinen Ceph-Clustern vermarktet. Wer ein solches Setup betreibt und auf Ceph 17.2 aktualisiert, sollte deshalb unbedingt den Parameter »mgr/cephadm/autotune_memory_target_ratio« in Ceph-Mgr auf »0.2« setzen – das beschränkt die OSDs auf insgesamt 20 Prozent des verfügbaren RAMs.

Komprimierung

Wie bei Ceph mittlerweile üblich, kommen die einzelnen Ceph-Komponenten zudem mit einem Füllhorn kleiner, aber feiner Änderungen daher. Die OSDs unterstützen für die Kommunikation untereinander nun Komprimierung. Das trägt dem Umstand Rechnung, dass viele Ceph-Systeme heute viel zu leistungsstarke CPUs besitzen, die Planer aber vor dem Einsatz neuester Netzwerktechnologien wie 400-Gbit/s-Verbindungen aus finanziellen Gründen noch immer zurückschrecken. Ceph-Cluster, denen zur Stoßzeit das Netzwerk überläuft, verschaffen sich zulasten ihrer CPUs mit dieser Funktion etwas Luft zum Atmen. Allzu hohe Erwartungen sollten Admins allerdings nicht an sie haben. Ein dauerhaft überlastetes Netz lässt sich letztendlich nur durch den Einsatz flinkerer Hardware in den Griff bekommen.

Mehr Übersicht bei Logs

Über eine – im Changelog unscheinbare – Änderung werden Admins sich bei ihren OSDs ebenso freuen wie über die verbesserte Ansicht bei »ceph pg dump«: Slow Requests wollen die OSDs in Zukunft nämlich deutlich übersichtlicher protokollieren, als das bisher der Fall war. Unter einem Slow Request versteht RADOS grundsätzlich jede Schreiboperation auf ein OSD, die nicht in einem festgelegten Zeitraum erfolgreich zum Abschluss kommt. Praktisch jede Art von Problem hat auch das Potenzial, massive Mengen an Slow Requests zu produzieren, ganz gleich ob es um Störungen im Netz, Probleme einzelner OSDs oder Konfigurationsfehler geht.

Die Krux: Jeder Client, der etwas in RADOS hochlädt, löst in der Standardkonfiguration damit drei Schreiboperationen aus. Die erste geht direkt auf das eigentliche Ziel-OSD, von dort aus werden aber Replikate der jeweiligen Objekte auch an die Secondary OSDs gesandt. Bei umfassenderen Problemen entstehen so in kurzer Zeit extrem viele Slow Requests, die der Cluster nicht abgearbeitet bekommt. Bislang leitete RADOS entsprechende Meldungen einfach in die Ausgabe von »ceph -w« weiter, wo sie schon nach kurzer Zeit nicht mehr sinnvoll nachzuvollziehen sind.

Das neue Format bündelt die Meldungen nun und produziert mithin deutlich weniger Text im Terminal. Wer das alte Format braucht, etwa weil Monitoring-Skripte davon abhängen, kann per Konfiguration aber auch das alte Format wieder aktivieren.

Aufgebohrte Automation

Während mancher Admin über Ceph-Mgr und das dazu gehörende Cephadm die Nase rümpft, greifen andere gern auf das Werkzeug zurück. Beide Positionen sind berechtigt. Einerseits muss die Frage erlaubt sein, wieso sich Ceph im Grunde ein Konkurrenzprodukt zu Ansible & Co. leistet (Abbildung 4), während Alternativen wie »ceph-ansible« existieren und gut funktionieren. Andererseits hat sich Ceph-Mgr in Ceph mittlerweile längst zu viel mehr als einer reinen Automation entwickelt.

Abbildung 4: In Form von Cephadm leistet Ceph sich eine komplette eigene Automationssuite, die in Ceph 17.2 nochmals neue Features bekommt und mehr Formate für den Export von Daten unterstützt.

Die Management-Dienste des Werkzeugs sind nicht nur perfekt an Ceph und seine Bedürfnisse angepasst, sondern stellen mittlerweile auch die Schnittstelle für andere Programme dar, um Daten über Ceph zu erhalten. Wer etwa Prometheus Daten aus Ceph abgreifen lassen will, um sie in modifizierten Dashboards grafisch darzustellen (Abbildung 5), redet mittlerweile ebenfalls mit dem Manager, denn der bietet ein natives Prometheus-Interface mit Daten im passenden Format.

Abbildung 5: Das Dashboard von Ceph hat sich mittlerweile zur etablierten Komponente der Lösung gemausert und bringt auch in Version 17.2 moderate Änderungen.

In Ceph 17.2 erfährt die Managementkomponente der Lösung allerdings nur behutsame Updates. Neben der Abfrage über das Prometheus-Protokoll steht nun etwa auch eine SNMP-Schnittstelle zur Verfügung, um verschiedene Vitalwerte aus Ceph zu extrahieren und in anderen Monitoring-Lösungen zu verarbeiten.

Obendrein haben die Entwickler die Fähigkeiten der Lösung massiv erweitert, einzelne Ceph-Dienste wie die eigentliche Mgr-Komponente, Metadaten-Server oder Instanzen des RADOS-Gateways parallel auf dieselben Systeme auszurollen. Außerdem lassen sich OSDs beim Entfernen aus dem Cluster künftig automatisch per »zap« bearbeiten, sodass die darauf existierenden Daten zuverlässig gelöscht werden. Schließlich beherrscht Cephadm nun einen Server-Agent-Modus, der die Performance der Lösung deutlich erhöhen soll.

Wenige Änderungen am Dateisystem

Einst das hässliche Entlein in der Liste der Ceph-Schnittstellen, hat sich CephFS längst zu einem vollwertigen Frontend gemausert. In Ceph 17.2 fallen die Änderungen allerdings übersichtlich aus. Bestehende Dateisysteme lassen sich nun mit einem neuen Namen versehen, wobei man Anpassungen von CephX-Schlüsseln aber händisch ausführen muss. Alternativ hat jede CephFS-Instanz künftig eine einmalige ID, über die sich das Dateisystem ebenfalls ansprechen lässt.

Ähnlich mager sieht es in Sachen Änderungen beim Ceph-Frontend für den Zugriff über eine Blockgeräteschnittstelle aus. Das Ceph Block Device lässt sich von Anfang an auf mehreren Wegen nutzen; neu hinzu gekommen ist in Ceph 16 bereits die Option »rbd-nbd«. Sie hängt ein RBD-Gerät mithilfe eines Userspace-Daemons über ein »nbd«-Gerät, sodass lediglich der »nbd«-Treiber des Linux-Kernels eine Rolle spielt. Zwar gibt es im Kernel auch einen nativen RBD-Treiber (»krbd«), doch kämpfen Anwender hier immer wieder mit Versionsunterschieden zwischen Cluster und Client, besonders auf Enterprise-Systemen mit ihren oft angestaubten Kerneln. »rbd-nbd« erfreut sich insbesondere im Kubernetes-Umfeld großer Beliebtheit, wo der Zugriff auf ein lokales Blockgerät noch immer als bevorzugter Weg für den Zugriff auf persistente Volumes dient, selbst wenn eine native Anbindung von Ceph an Kubernetes existiert.

QoS für das RADOS Object Gateway

Quasi im Windschatten der anderen Frontends für RADOS hat sich das Ceph Object Gateway (auch RADOS-Gateway oder Rgw) in den vergangenen Jahren fortwährend verbessert. Ceph 17.2 bringt einige interessante Änderungen der Komponente mit. Die wichtigste dabei dürfte die nun unterstützte Bandbreitenlimitierung auf Basis von Benutzern oder Buckets sein. Rgw erweitert RADOS um eine Schnittstelle für den Zugriff per ReST-HTTP-Protokoll, es emuliert wahlweise das Swift-Protokoll von OpenStack oder Amazon S3.

Vielerorts kommt das RADOS-Gateway als Ergänzung für Anbieter zum Einsatz, die ihren Kunden On-Demand-Online-Speicher anbieten wollen, ohne dafür eigene Infrastruktur auszurollen. Besonders Setups ohne vorgeschalteten Load Balancer waren dabei bisher allerdings vom Risiko betroffen, dass einzelne aus dem öffentlichen Internet erreichbare Dateien das RADOS-Gateway oder sogar den gesamten Cluster lahmlegen konnten. Das lässt sich nun zumindest abschwächen, indem der Admin Limits für den jeweiligen Nutzer oder die zugehörende Bucket Rate definiert. Hier ergibt sich zudem eine Möglichkeit für mehr Umsatz: Definiert ein Unternehmen nämlich Standard-Limits für alle Anwender, lässt sich die Abschaltung eines Limits pro Benutzer als Funktion mit separatem Preisschild vermarkten.

Der Weg zu Ceph 17.2

In Summe präsentiert sich Ceph 17.2 als robustes Update ohne viel Chichi und bietet für die allermeisten Ceph-Admins vor allem erhöhte Stabilität und mehr Features ohne viel Aufwand. Wer auf die neue Version aktualisieren will, die übrigens nach dem gleichnamigen Charakter aus “Spongebob Schwammkopf” auf den Namen “Quincy” getauft ist, hat dafür mehrere Möglichkeiten.

Der einfachste Weg besteht darin, auf die Ceph-eigene Orchestrierung Cephadm zu setzen. Die Aktualisierung eines laufenden Ceph-Cluster mit RocksDB lässt sich dann mittels »ceph orch upgrade start –ceph-version 17.2.0« anstoßen, wobei es im Anschluss je nach Einsatzszenario noch die beschriebenen Änderungen zu vollziehen gilt.

Wer seine Ceph-Dienste noch händisch oder per Automation – etwa Ansible – ausrollt, ist auf Handarbeit oder die Schützenhilfe der jeweiligen Entwickler angewiesen. Die Entwickler von Rook etwa, das Ceph in Kubernetes betreibbar macht, arbeiteten zu Redaktionsschluss bereits an passenden neuen Helm-Charts, sodass diese bei Veröffentlichung dieser Ausgabe womöglich schon zur Verfügung stehen.

Angst vor einem Upgrade ist jedenfalls unbegründet, denn wer mit Ceph 16 zurechtgekommen ist, sieht sich auch in Ceph 17.2 keinen großen Problemen gegenüber. (jcb)