© Sergey Peterman, 123RF

Ceph ist ein großes Projekt und hat eine sehr aktive Entwickler-Community im Rücken. Das Linux-Magazin berichtet regelmäßig über Neuerungen – diesmal im Fokus: Version 14.2 alias Nautilus.

Als Ceph und die zugehörige Firma Inktank vor ein paar Jahren von Red Hat geschluckt wurden, waren die Sorgen in der Community unüberhörbar: Würden die roten Hüte aus Raleigh den Ceph-Leuten die Daumenschrauben anlegen? Kann die Entwicklung in der Geschwindigkeit weiterlaufen, die sie bis dahin hatte? Oder würde der Hersteller Ressourcen verlagern und die Ceph-Entwicklung ausbremsen?

Aus heutiger Sicht stehen die Zeichen klar auf Entwarnung: Praktisch die gesamte Kerntruppe von Inktank ist dem Unternehmen treu geblieben und die Ceph-Entwicklung hat nichts von ihrer Geschwindigkeit eingebüßt. Manche sagen sogar, es würde heute in Ceph mehr und zielgerichteter entwickelt [1].

Das Linux-Magazin hat den Finger seit vielen Jahren am Puls der Ceph-Entwicklung. Zuletzt war die Lösung 2016 Gegenstand der Betrachtung. Damals hatten viele neue Funktionen wie die Einführung des On-Disk-Dateisystems Blue Store für Furore in der Ceph-Gemeinde gesorgt. Denn indem die Entwickler auf XFS & Co. beim Ceph-Journal verzichteten und stattdessen ihr eigenes Mini-Dateisystem bauten, sorgten sie für einen großen Performance-Sprung. Als wegweisend hat sich auch herausgestellt, dass Ceph-FS – die ursprüngliche Keimzelle der Lösung – endlich in einen stabilen Zustand gelangte und für den produktiven Einsatz gereift ist.

Das alles hält die Ceph-Entwickler aber nicht davon ab, fleißig weiter an ihrer Lösung zu basteln. Zwei Major-Releases hat es seit dem letzten Ceph-Überblick im Linux-Magazin gegeben: 13.2 sowie 14.2 – letztere erschien erst vor wenigen Wochen. Grund genug, mal wieder genau hinzusehen: Was tut sich bei Ceph und über welche neuen Funktionen dürfen Admins sich freuen? Lohnt sich die – in den meisten Fällen ziemlich aufwändige – Update-Prozedur?

Runderneuertes GUI

Fragt man die Ceph-Entwickler selbst nach der wichtigsten Ceph-Neuerung der vergangenen Jahre, antworten die meisten unwillkürlich mit dem Verweis auf die neue grafische Management-Oberfläche. Wer sich mit Ceph in dessen frühen Tagen beschäftigt hat, erinnert sich: Eingangs gab es kaum Kommandozeilenwerkzeuge, um Ceph sinnvoll auszurollen oder zu verwalten. An ein GUI war gar nicht zu denken.

Diverse Ceph-Kunden signalisierten Inktank seinerzeit allerdings sehr deutlich, dass ein Management-GUI durchaus wünschenswert sei. Klar: Wer aus der SAN-Welt kommt und die bunten Oberflächen von Dell-EMC oder Netapp gewohnt ist, fühlt sich beim Anblick der Linux-Konsole in ein anderes Jahrzehnt zurückgeworfen.

Also unternahm Inktank selbst den Versuch, ein GUI für Ceph zu etablieren – mit sehr überschaubarem Erfolg: Calamari war architektonisch herausfordernd und kam mit einem eigenen Automationstool (Salt) im Gepäck. So sehr der Hersteller das Tool auch bewarb: Die Nutzer waren wenig begeistert (Abbildung 1).

Abbildung 1: Calamari war Inktanks erster Versuch eines Ceph-Dashboard – doch die Lösung entpuppte sich letztlich als Rohrkrepierer.

Ausgerechnet Suse holte das Thema Ceph-GUI aber 2017 aus der Versenkung – und obendrein auf ausgesprochen elegante Art und Weise. Von der Fuldaer Firma IT-Novum verleibten die Nürnberger sich nämlich kurzerhand Open Attic (Abbildung 2) ein – und das hatte zum Zeitpunkt der Übernahme bereits ein sehr funktionales Ceph-GUI an Bord.

Abbildung 2: Bei IT-Novum erkannte man schnell, dass Open Attic sich prächtig als Ceph-GUI machen würde, und entwickelte die Lösung in diese Richtung.

Denn während IT-Novum anfangs Open Attic als generisches Storage-Frontend für im Grunde jede Art von Storage vorgesehen hatte, schossen die Entwickler sich beim Redesign im Rahmen von Open Attic 2 auf Ceph ein, wohl auch – oder gerade deshalb – weil für dieses weit und breit kein brauchbares GUI zu finden war. Mit Erfolg: Schnell galt Open Attic als ein besseres Ceph-GUI, als Calamari es je hätte werden können.

Als Suse das Produkt von Open Attic übernommen hatte, machten die Nürnberger schnell reinen Tisch und begannen damit, das Produkt in Richtung Community zu pushen. Seit Ceph 12.2 ist das vorherige Tool namens Open Attic 2 als Ceph-Dashboard [2] fester Bestandteil der Lösung, und noch immer entwickelt das Programm sich mit großen Schritten fort (Abbildungen 3 und 4).

Abbildung 3: Nachdem Suse Open Attic von IT-Novum übernahm, konzentrierte man sich vollends auf Ceph – mit Erfolg, denn …

Abbildung 4: … seit 2017 gibt es ein neues Ceph-Dashboard, das großteils auf vorherigem Open-Attic-Code basiert.

Alles sehr praktisch

Das gilt auch für die Dashboard-Version, die in der im März veröffentlichten Version 14.2 enthalten ist. Erstmals bietet das Dashboard in dieser Version Support für ein Nutzer- und Rollenschema. Damit lässt sich der Zugriff nun gezielt und fein abgestuft steuern. In diesem Kontext ebenso wichtig ist, dass das Dashboard nun Single-Sign-on (SSO) unterstützt. Dafür kommt das weit verbreitete SAML2-Protokoll zur Anwendung – das zuvor beschriebene Schema für Rollen und Nutzer mappt im Hintergrund dann spezifische Berechtigungen auf die per SSO identifizierten Nutzer.

Gerade im Enterprise-Umfeld von großer Bedeutung ist die Auditing-Funktion, die im Ceph-Dashboard in Version 14.2 Einzug gehalten hat. Audit Trails lassen sich nun etwa so anlegen, wie es die gängigen Zertifizierer erwarten.

Große Unterschiede ergeben sich aber auch schon auf der ersten Seite, die der Benutzer unmittelbar nach dem Log-in sieht: Hier begrüßt ihn nun eine neue Standardansicht, die mehr Details zum Zustand des Clusters und zu diversen Storage-Metriken zusammenführt. Dabei ist den Entwicklern das Kunststück gelungen, das neue Dashboard gar nicht unübersichtlich wirken zu lassen. Jede Anzeige hat erkennbar ihren Platz, und die Komposition ist geeignet, dem Admin schnell einen guten Überblick über den ganzen Cluster zu verschaffen.

Das Dashboard lässt sich nun auch lokalisieren. Im administrativen Alltag hat diese Eigenschaft vermutlich nur geringe Auswirkungen, ist Englisch hier doch die allgemein genutzte Sprache. Wer Ceph allerdings öffentlich präsentieren möchte, sei es klassisch per Beamer oder im Gespräch mit potenziellen Kunden, der greift auf diese Funktion womöglich ganz gerne zurück. Denn längst nicht jeder ist der englischen Sprache so mächtig, dass er sie im Alltag sicher nutzen kann.

Ein API fürs GUI

Eine weitere GUI-Änderung wirkt auf den ersten Blick etwas absurd, denn in der neuen Ceph-Version kommt das GUI mit einer eigenen Schnittstelle daher, die auf Basis von Swagger konzipiert ist. Das mutet zuerst komisch an, ist es aber nicht: Metriken, die per GUI angezeigt werden, möchten viele Kunden auch in ihre eigenen Metriksysteme wie Prometheus übernehmen. Aus gutem Grund ist der Zugriff auf die Hardware von Ceph-Clustern sehr strikt begrenzt.

Das Ceph-Dashboard fungiert hier gewissermaßen als Mittler zwischen den Welten und gibt den Kunden Zugriff auch auf Metrikdaten, an die sie sonst gar nicht herankämen. Sie können diese Daten nun maschinell aus dem Dashboard auslesen und weiterverarbeiten.

Admins Liebling

Das Dashboard hat nicht nur solche Neuerungen spendiert bekommen, die es selbst betreffen, es kann zum Beispiel nun auch deutlich effizienter mit einem Ceph-Cluster umgehen.

OSDs lassen sich per GUI nun etwa als »down« und »out« markieren, faktisch also aus dem Cluster entfernen. Ceph-Pools sind per Dashboard editierbar, ein separater Viewer für die CRUSH-Map steht ebenso bereit wie ein Modul, um den NFS-Server Ganesha zu steuern. I-SCSI-Targets setzt das Dashboard künftig selbstverständlich auf. Und wer in seinem Setup auf Prometheus & Co. setzt, kann aus dem Dashboard heraus auch Prometheus-Alarme steuern.

Zusammengefasst gehört das Ceph-Dashboard damit zu jenen Teilen der Software, die sich am meisten verändert haben – und zwar sehr zum Positiven.

Änderungen bei Rados

Ceph ist aber weit mehr als ein GUI mit angehängtem Speicher. Auch beim eigentlichen Kern der Lösung, dem Objektspeicher Rados, hat sich einiges getan. Nachgerüstet haben die Entwickler (mal wieder) beim Thema Placement Groups. Zur Erinnerung: Placement Groups sind in Rados eine Art Namensschild, das jedes Objekt angehängt bekommt. Intern organisiert Rados auf Basis der Placement Groups (PGs) zum Beispiel die Replikation. Jedes Objekt gehört von Anfang an einer Placement Group an. Objekte, die zur selben PG gehören, sind immer colocated, liegen also immer auf denselben Hosts.

Die Zahl der Placement Groups ist allerdings dynamisch, lediglich eine Mindestmenge ist festgelegt. Entsprechend ranken sich viele Mythen darum, wie die ideale PG-Zahl zu berechnen sei. Fest stand bisher nur: Wer einmal zu viele Placement Groups angelegt hatte, konnte sie nicht mehr reduzieren. Genau diese Funktion beherrscht Ceph aber in Version 14.2. Hinzugekommen ist auch eine Auto-Tuning-Funktion: Stellt Ceph anhand der aktuellen Cluster-Auslastung oder auf Basis von Admin-Einstellungen fest, dass die aktuelle PG-Zahl nicht ideal ist, kann es sie automatisch anpassen.

Ein neues Protokoll

Für Auditoren und Mitarbeiter aus dem Bereich Security bekommt Ceph in der neuen Version ein neues On-Wire-Protokoll, das den etwas unspektakulären Namen “v2” hat. Es ermöglicht eine On-Wire-Verschlüsselung, die in Ceph bisher fehlte. Vor allzu großen Freudensprüngen sei jedoch gewarnt – denn eine Verschlüsselung geht letztlich immer zulasten der CPU. Und die kann in einem Ceph-Cluster schon beansprucht sein, wenn gerade der Ausfall eines Knotens zu kompensieren und etliche Terabyte an Daten hin und her zu schaufeln sind.

Ob das Feature also als General-Purpose-Verschlüsselung in jedem Cluster zum Einsatz kommen kann, muss sich erst noch herausstellen. Gerade ältere Systeme oder solche mit wenigen CPU-Kernen dürften hier jedenfalls früher oder später deutlich an ihre Grenzen stoßen.

OSD-Buchhaltung

Bisher überprüft Ceph nur den aktuellen Zustand der Festplatten im Cluster, die bei Ceph OSDs heißen. Es legt aber keine Aufzeichnungen über diese Werte an und enthält auch keine historischen Daten, die eine Aktion auslösen könnten. In Ceph 14.2 wird das möglich: Anhand von Patterns bringt der Admin dem Cluster bei, in bestimmten Situationen bestimmte Aktionen zu starten.

Die Inhalte der SMART-Werte der OSDs sind dabei ausdrücklich ein ausschlaggebender Faktor – knirscht es also beim SMART eines OSD, kann der Admin den Cluster so konfigurieren, dass er die entsprechende Platte präventiv aus dem Cluster entfernt. Äquivalent dazu kann Ceph auch Notifications beim Eintreten bestimmter SMART-Events verschicken, etwa wenn anhand der SMART-Werte eines Speichergeräts davon auszugehen ist, dass es bald den Löffel abgibt.

Allerdings ist bei SMART stets eine gehörige Portion Vorsicht geboten: Gelegentlich versagt das System bei der Voraussage komplett, und wieder ein anderes Mal ruft es feurio, obwohl es den jeweiligen Geräten bestens geht.

Verbesserungen beim Erasure Coding

Wohl jeder Storage-Admin dürfte schon mal mit seinem Manager eine sehr leidige Diskussion geführt haben: Warum bleibt von der Bruttokapazität netto so wenig übrig? Wer Ceph im Standard-Modus mit dreifacher Replikation nutzt, investiert immerhin zwei Drittel seines Speicherplatzes in Replikation. Das Problem ist auch nicht neu oder Ceph-spezifisch: Wer schon Raid 1 oder Raid 10 verargumentieren musste, weiß, worum es geht.

Im Falle von Raid haben die Hersteller sich für das Problem Raid 5 & Co. etwas ausgedacht: Hier werden nicht mehr von jeder Information mehrere Replika angelegt, im Falle einer Resynchronisation werden stattdessen Teile der benötigten Daten aus den vorhandenen Metadaten berechnet. Das nutzt vorhandenen Speicher viel effizienter, die Brutto-Netto-Bilanz fällt viel positiver aus.

Allerdings ist diese Funktion ziemlich teuer erkauft, denn ein Resync im Falle eines Falles dauert viel länger und frisst mehr CPU- und Netzwerkressourcen. Im blödesten Falle ist ein Storagegerät dadurch über mehrere Stunden offline.

Bei Ceph steht der Admin vor der gleichen Wahl: Stumpfe Replikation binärer Objekte mit einhergehender geringer Nettokapazität oder Erasure Coding – so heißt das zuvor beschriebene Konzept, das beispielsweise auch bei Raid 5 zum Einsatz kommt. Immerhin: Seit Ceph 12.2 (Ende 2017) funktionieren Erasure Coded Pools auch für Ceph-FS sowie für RBD-Geräte, wobei die Erasure-Coded-Eigenschaft in Ceph stets über die Pools definiert wird. Anders als Placement Groups sind Pools eine logische Kategorie, in die Ceph-Cluster aufgeteilt werden. Entsprechend ist »Erasure Coded« ein Konfigurationsparameter, der ebenfalls für den spezifischen Pool gilt.

In Ceph Nautilus liefern die Entwickler erstmals ein Ceph-internes Plugin namens Clay aus, das mit einem großen Versprechen antritt: Es soll sowohl die CPU-Last als auch den Netzwerkverkehr im Resync-Falle für Erasure Coded Pools eindämmen, also die zentralen Nachteile von Erasure Coding wenigstens abfedern. Aktuell bezeichnen die Entwickler das Plugin denn auch noch als experimentell – von einem produktiven Einsatz ist insofern abzusehen.

Etwas überlegt haben sich die Ceph-Entwickler auch für jene Admins, die von Erasure Coding nichts wissen wollen. Wer die ganz normale Replikation im Gegenzug für schnelle Resynchronisation und geringe CPU- und Netzwerklast nutzt, freut sich in Ceph Nautilus über eine deutlich effizientere Priorisierung der Placement Groups. Anhand verschiedener Faktoren erkennt Ceph nämlich automatisch, welche PGs bei einer Resynchronisation die höchste Priorität haben, und behandelt diese bevorzugt.

Und »ceph status«, das dem Admin als zentrales Werkzeug dient, um sich umfassend über den Gesundheitszustand des Clusters zu informieren, zeigt während einer Resynchronisation nun einschlägige Informationen inklusive der verbleibenden Zeit an – auch wenn dieser Wert lediglich geschätzt ist und sich gerne auch während des Vorgangs noch verändern kann.

Neues auch beim Object Gateway

Auch bei der Restful-Schnittstelle zu Ceph, dem Ceph Object Gateway – intern aus historischen Gründen noch immer Rados Object Gateway oder kurz RGW genannt –, hat sich in den vergangenen Monaten einiges getan. Zunächst haben die Entwickler wie üblich die Kompatibilität mit Amazons S3-Protokoll verbessert. Was nicht leicht ist, denn S3 ist kein offenes Protokoll und alle existierenden Nachbauten basieren entweder auf der Beschreibung aus der S3-Entwicklerdokumentation oder auf Reverse Engineering. Daher verwundert es nicht, dass es immer mal wieder Dinge gibt, die nicht wie gewünscht funktionieren. Konkret kommt die S3-Implementation in RGW jetzt besser mit den Lifecycle-Operationen zurecht, die das offizielle S3-Protokoll vorsieht.

Auch beim Thema Authentifizierung hat sich viel getan: Das RGW hat nun nicht nur ein neues und runderneuertes Webinterface, sondern es bietet offiziell auch Support für STS nach verschiedenen Standards an. Prominent vertreten ist etwa Oauth. Aber auch Open ID steht auf der Liste der unterstützten Protokolle.

Archive anlegen mit dem Rados Gateway

Die wohl wichtigste Neuerung in RGW hängt allerdings mit den dortigen Funktionen für Offsite-Replikation zusammen. Schon sehr früh in der Ceph-Entwicklung merkten viele Anwender an, dass Replikation hin zu anderen Standorten für moderne Storage-Lösungen ein wichtiger Faktor sei. Denn im Jahre 2019 darf die IT-Infrastruktur vielerorts selbst dann nicht zum Stillstand kommen, wenn das jeweilige Rechenzentrum einer Katastrophe zum Opfer gefallen ist. Server, die unter Wasser stehen, erfüllen ihren Zweck nur noch bedingt.

Cluster, die mehrere Standorte überspannen, sind in Ceph aber prinzipbedingt keine Option: Ceph kopiert seine Daten stets synchron, ein schreibender Client bekommt das Okay für einen Write also erst, wenn die entsprechende Information so oft im Cluster vorhanden ist, wie es die vom Admin definierte Replikationsrichtinie vorgibt.

Das würde bei Offsite-Replikation bedeuten, dass das Okay erst rausgeht, wenn in jeder Site eine Kopie des Objekts existiert. Der Client würde dann allerdings auch die Latenz abbekommen, die zwischen den Sites vorhanden ist. Für verschiedene Aufgaben würde Ceph dadurch unbrauchbar.

Daher suchten die Ceph-Entwickler bereits früh nach Möglichkeiten, Offsite-Replikation zu implementieren, die Wahl fiel schließlich auf eine Lösung auf Basis des Ceph Object Gateway. Nach und nach haben die Entwickler das so genannte Federation-Feature seither ausgebaut. RGW funktioniert in derartigen Setups als eine Art Agent, der zuvor vom Admin festgelegte Regeln befolgt und Objekte asynchron hin und her kopiert, die unter die Replikationspolicy fallen. Den laufenden Betrieb des Clusters stört das nicht, die Latenz-Katastrophe aus Anwendersicht bleibt also erfreulicherweise aus.

Der übliche Betriebsmodus der Federation im RGW bestand bisher allerdings darin, einzelne Objekte zu replizieren – nicht jedoch den gesamten Inhalt eines Clusters. Aus verschiedenen technischen und Performance-Gründen war RGW darauf im Grunde nicht ausgelegt.

In Version 14.2 reichen die Entwickler diese Funktionen nun nach: Der Archiv-Modus ermöglicht es, eine gesamte Ceph-Installation mit Hilfe des Federation-Feature zu einer anderen Ceph-Instanz zu kopieren. Kombiniert der Admin diese Funktion mit der Kompression, die Ceph bereits seit einiger Zeit beherrscht, ergibt sich ein echtes Szenario für Desaster Recovery. Erneut hinterlässt Ceph so eine imposante Duftmarke im angestammten Terrain proprietärer Storage-Systeme.

Ganz viel Neues bei Ceph-FS

Nicht zuletzt enthält Nautilus auch eine ganze Lkw-Ladung voller Neuerungen für das Posix-kompatible Ceph-FS. Dies nutzt bekanntlich den Rados-Objektspeicher und war eingangs sogar die Keimzelle der gesamten Ceph-Entwicklung. Später gab Inktank allerdings RBD und RGW den Vorzug, wohl auch, weil sich mit jenen Funktionen gerade im Fahrwasser der Cloud einfach mehr Geld verdienen ließ. Red Hat hat Ceph-FS aber wieder auf Kurs gebracht, mittlerweile gilt Ceph-FS offiziell als reif für den Einsatz in produktiven Umgebungen.

Auch wenn der Feature-Umfang zumindest anfangs sicherlich nicht den Ansprüchen von Ceph-Mastermind Sage Weil genügte. Denn damit Ceph-FS Posix liefern kann, ist zusätzlich zu den MON- und OSD-Diensten im Cluster auch zumindest ein MDS nötig, nämlich ein Metadata-Server. Sage Weils Wunschszenario bestand jedoch darin, dass die Anwender so viele MDS parallel betreiben sollen wie möglich – diese sollten sich die einzelnen Äste des Dateisystems untereinander aufteilen und jeweils nur für ihre Äste verantwortlich sein. Fällt ein MDS aus, sollte automatisch ein anderer übernehmen. So trug Inktank dem Umstand Rechnung, dass der MDS der neuralgische Punkt eines Setups ist.

Als Red Hat Ceph-FS an den Start brachte, ließen sich MDS nur im Aktiv-Passiv-Modus betreiben. Das beschriebene Subtree-Partitioning funktionierte noch nicht. In Ceph 12.2 haben die Entwickler das Feature allerdings nachgereicht. Und in der aktuellen Nautilus-Release kommt einiges an Funktionalität hinzu. So sollen sich verschiedene MDS-Instanzen nun insbesondere in großen Hochlast-Setups viel stabiler verhalten als bisher. Außerdem bremsen die MDS-Instanzen Clients nun künstlich aus, wenn diese zu viele Anfragen stellen und so den MDS in Bedrängnis bringen.

Zudem kooperiert Ceph nun deutlich besser mit Rook [3] – jener Lösung, die in einer Kubernetes-Umgebung einen Ceph-Cluster so startet, dass er in den Containern seine Volumes zur Verfügung stellt. Kommt in einem Cluster Ceph-FS auf Basis von Rook zum Einsatz, lässt sich dieses künftig problemlos per NFS-Ganesha auch als NFS-Export anbieten. Wobei sich dieses Feature wohl getrost als Liebhaberei bezeichnen lässt, denn allzu viele Nutzer dürfte die Kombination in freier Wildbahn nicht haben.

Dass es das Feature trotzdem gibt, ist denn auch eher ein Beweis dafür, dass die Ceph-Community neben dem großen Ganzen auch die Corner Cases im Blickfeld hat und für sie entsprechende Funktionen baut (Abbildung 5).

Abbildung 5: Rook integriert Ceph in Kubernetes – in der aktuellen Version von Ceph lassen sich Ceph-FS-Volumes per NFS-Ganesha als NFS-Ressource exportieren.

Bessere Zusammenarbeit mit Orchestrierern

So etwas wie ein Stachel im Fleisch von Ceph ist der Umstand, dass es keine echte kanonische Lösung für das automatische Ceph-Deployment gibt. Anfangs hatten die Entwickler es schlicht verschlafen, eine entsprechende Lösung anzubieten – lange genug existierte ja nicht einmal »ceph-deploy« für das händische Deployment. Und als man sich des Problems dann endlich annehmen wollte, präsentierte der Markt bereits eine Vielzahl von mal mehr, mal weniger gut funktionierenden Lösungen, die wahlweise als eigene Appliance (etwa Deep Sea von Suse) oder als Aufsatz für die bekannteren Automatisierer (Puppet, Chef, Ansible …) fungierten.

In Ceph Nautilus treten die Entwickler nun die Flucht nach vorne an und statten ihre Lösung mit einer generischen CLI-Schnittstelle aus, die allen Automatisierern den gleichen Funktionsumfang liefern soll. Noch ist jene Schnittstelle allerdings nicht fertig und die Entwickler warnen ausdrücklich vor dem Einsatz im produktiven Umfeld.

Jederzeit, so die Aussage, könnte sich das API noch ändern. Der eingeschlagene Weg jedoch ist der richtige, und die Entwickler der verschiedenen Automatisierer dürfen sich auf das Endergebnis zweifelsohne schon heute freuen.

Fazit: Bewährtes und Revolutionäres

Ceph gibt sich ambivalent. Die wichtigsten Funktionen existieren seit Jahren und sind mittlerweile so ausgereift, dass sie im Alltag praktisch kaum noch Probleme hervorrufen. Wer Ceph mit allen als stabil markierten Funktionen nutzen möchte, kann sich beruhigt auf tragfähigem Eis bewegen.

Andererseits ist in der Ceph-Entwicklung aber nach wie vor einige Musik – neue Funktionen, die vielen Anwendern wirklich helfen, fließen regelmäßig in die Entwicklung ein. Die vollständig renovierte Oberfläche, die seither kontinuierlich erneuert und erweitert wird, ist dafür ein perfektes Beispiel.

Fest steht damit aber auch: Die Befürchtungen aus der Zeit kurz nach der Übernahme, Red Hat werde Inktank eine Entwicklungsagenda vorgeben, die womöglich hauptsächlich Red Hat nützt, haben sich nicht bestätigt. Im Gegenteil: Wie eh und je steht Ceph fest auf Open-Source-Boden und ist den Grundsätzen der Open-Source-Community ohne jeden Zweifel verhaftet.

Behält das Projekt weiter den eingeschlagenen Kurs bei, wird es in naher Zukunft voraussichtlich noch unangenehmer für die namhaften und etablierten Storage-Anbieter wie Dell-EMC, Netapp und all die anderen werden.