© DENYS Rudyi, 123RF

Der Objektspeicher Ceph bleibt ein Projekt im Wandel: Ein neues GUI, ein neues Storage-Backend und die Produktionsreife von Ceph-FS melden nun die Entwickler.

Als Red Hat 2014 Inktank übernahm und sich damit den Objektspeicher Ceph [1] einverleibte, ging ein Raunen durch die Community. Einerseits, weil Red Hat in Form von Gluster-FS [2] bereits einen direkten Konkurrenten von Ceph im Portfolio hatte, andererseits, weil Inktank ein so junges Unternehmen war – für das die roten Hüte viel Geld auf den Tisch legten. Knapp zwei Jahre später ist klar, dass Gluster-FS bei Red Hat nur noch eine untergeordnete Rolle spielt und das Unternehmen stattdessen verstärkt auf Ceph setzt.

Das hat die Firma in der Zwischenzeit weiterentwickelt: Viele der Kinderkrankheiten früherer Versionen sind geheilt. Neben der Korrektur von Fehlern wünschten sich Entwickler und Admins aber auch neue Features: So können sich viele Admins mit Calamari, dem von Red Hat propagierten Ceph-GUI, schwer anfreunden, sie brauchen Alternativen. Das Ceph-FS-Dateisystem, das die Keimzelle von Ceph ist, dümpelte seit zwei Jahren im Beta-Zustand und sollte sich endlich produktiv nutzen lassen. Zudem erntete die Lösung immer wieder Kritik für ihre Performance, die in Sachen Latenz mit etablierten Speicherlösungen nicht mithalten konnte.

Raum für Verbesserung gab es also mehr als genug. Und tatsächlich hat sich bei Ceph in den letzten Monaten viel getan. Ein guter Grund, einmal genauer hinzusehen: Bringen die neuen Funktionen im Alltag echte Vorteile für Admins? Was hat es mit dem neuen GUI auf sich?

Das leidige Thema Ceph-FS

Die Situation scheint paradox: Ceph fing vor über zehn Jahren als Netzwerk-Dateisystem an. Sage Weil, der Erfinder der Lösung, hatte damals im Rahmen seiner Doktorarbeit das Thema “Verteilte Dateisysteme” aufgegriffen. Es war sein Ziel, ein besseres Lustre-FS zu schaffen, das ohne dessen Probleme auskommen sollte. Aber als Weil das Projekt Ceph zu seiner Hauptbeschäftigung und zu einem kommerziell vermarkteten Produkt machen konnte, rückte das ursprüngliche Ziel in den Hintergrund: Auf der Welle des Cloud Computing ließ sich viel mehr Geld mit Blockspeicher für virtuelle Maschinen verdienen.

Konsequenterweise floss viel Zeit in die Entwicklung der Bibliothek Librbd, die für Qemu mittlerweile ein natives Ceph-Backend anbietet. Auch Speicherdienste im Sinne von Dropbox erscheinen kommerziell vielversprechender: Cephs Rados-Gateway bietet diese Funktion im Gespann mit einem klassischen Webserver. Wer auf Ceph-FS wartete, musste in den letzten Jahren vorrangig mit Versprechungen vorlieb nehmen. Mehrmals gelobte Sage Weil, Ceph-FS werde bald fertig sein. Passiert ist in dieser Hinsicht allerdings lange wenig.

Schuld daran ist neben dem verschobenen Fokus die Komplexität der Aufgabe. Einerseits muss ein Dateisystem wie Ceph-FS Posix-kompatibel sein, weil es sich sonst nicht sinnvoll einsetzen ließe. Andererseits stellen die Ceph-Entwickler an ihre Lösung selbst hohe Anforderungen: Jede Komponente einer Ceph-Installation soll nahtlos skalieren.

Zu einem Ceph-Cluster gehören mindestens zwei Arten von Diensten: Einerseits kümmert sich ein Daemon um die Object Storage Devices (OSD-Daemon), er sorgt dafür, dass sich die einzelnen Platten im Cluster nutzen lassen. Andererseits braucht es die Monitoring-Server (MONs), die Wächter des Clusters, die die Integrität der Daten sicherstellen. Wer Ceph-FS nutzen will, benötigt nun noch einen weiteren Dienst: den Metadatenserver, kurz MDS (Abbildung 1).

Abbildung 1: Damit Ceph-FS funktioniert, braucht der Cluster neben MONs und OSDs auch Metadatenserver. Die haben die Entwickler in Ceph Jewel aufgemotzt.

Unter der Haube funktioniert der Zugriff auf den Ceph-Speicher mittels Ceph-FS fast genauso wie beim Zugriff per Blockdevice-Emulation. Clients laden ihre Daten auf ein einzelnes OSD, das im Hintergrund die Replikation selbstständig erledigt. Damit Ceph-FS tatsächlich in Posix-kompatibler Manier Metadaten anbieten kann, gesellen sich die MDS als eigenständige Dienste hinzu.

Die MDS selbst enthalten übrigens gar nicht die zu einzelnen Objekten gehörenden Metadaten. Die sind stattdessen direkt in den User-extended Attributes der einzelnen Objekte auf den OSDs abgelegt. Im Grunde fungieren die MDS-Instanzen eines Ceph-Clusters nur als Caches für jene Metadaten. Gäbe es sie nicht, würde jeder einzelne Zugriff auf eine Datei in Ceph-FS sehr lange dauern.

Performance und Skalierbarkeit

Damit das Metadatensystem auch in großen Clustern mit vielen gleichzeitigen Zugriffen funktioniert, müssen MDS-Instanzen beliebig in die Breite skalieren können. Das ist technisch komplex: Für jedes einzelne Objekt muss es immer den einen MDS geben, der in letzter Instanz verantwortlich für die Metadaten eben jenes Objekts ist. Die Zuweisung der Verantwortlichkeit muss also für alle Objekte im Cluster dynamisch funktionieren. Fügt der Admin einem bestehenden Cluster einen weiteren Metadatenserver hinzu, muss sich Ceph automatisch um die Zuweisung von Objekten zu diesem MDS kümmern.

Die Lösung für das Problem, die die Ceph-Entwickler sich ausgedacht haben, ist schlau: Sie teilen einfach den gesamten Dateisystembaum von Ceph-FS in Unterbäume (Subtrees) auf und weisen die Verantwortlichkeit für jeden einzelnen Tree dynamisch MDS-Instanzen zu. Betritt ein neuer Metadatenserver den Cluster, erhält er automatisch die Hoheit über einen Subtree. Das muss auf jeder Ebene des Posix-Baums klappen: Sind alle Bäume auf der obersten Ebene vergeben, muss der Ceph-Cluster die nächstkleinere Ebene partitionieren.

Das Prinzip nennt sich Dynamic Subtree Partitioning (DSP) und hat Sage Weil und sein Team bereits einige Nerven gekostet. Denn die Aufgabe, die Zuweisung der Posix-Metadatenbäume dynamisch für einzelne Metadatenserver zu regeln, erwies sich als hochkompliziert. Das ist einer der Hauptgründe dafür, dass Ceph-FS nicht bereits als regelmäßig verwendbar deklariert ist.

Die gute Nachricht: Für die nächste Ceph-Version (Jewel) wollen die Entwickler Ceph-FS stabilisieren. Die Arbeiten am DSP waren zu Redaktionsschluss weitestgehend abgeschlossen. Es ist also sehr wahrscheinlich, dass Ceph-FS in der Jewel-Version offiziell als einsetzbar gilt..

Neue Funktionen für Ceph-FS

Zusätzlich zur funktionierenden DSP-Implementation bringt die Jewel-Release für Ceph-FS weitere Verbesserungen. Einer der größten Kritikpunkte war bisher, dass für Ceph-FS kein Werkzeug für den Dateisystemcheck existiert. Der Kritikpunkt taucht in schöner Regelmäßigkeit in der Geschichte praktisch aller Dateisysteme auf. Erinnert sei etwa an die Schmähungen, denen der Fsck von Reiser-FS ausgesetzt war.

Bei einem Netzwerk-Dateisystem ist das Thema Fsck nochmals deutlich komplexer als bei lokalen Dateisystemen, die nur auf einem einzigen Datenträger liegen. Denn einerseits muss ein Fsck für Ceph prüfen, ob die abgelegten Metadaten korrekt sind, andererseits muss er auf Wunsch des Admin auch in der Lage sein, die Integrität aller zu einer Datei gehörenden Objekte zu checken. Nur so ist letztlich sicher, dass der Admin jede Datei aus dem Cluster herunterladen kann. Ist ein Recovery nicht mehr möglich, muss der Cluster den Admin wenigstens informieren, damit er die Backups aus der Schublade holen kann.

Jewel wird auch in Sachen Dateisystem-Check nachrüsten: Greg Farnum, der an Ceph schon zu Inktank-Zeiten arbeitete, hat sich des Themas angenommen. Zusammen mit John Spray hat er die zum Teil bereits vorhandenen Ansätze für die Jewel-Version von Ceph konsolidiert und überarbeitet. Entstanden ist kein monolithisches Fsck-Werkzeug, sondern eine Reihe von Programmen, die sich für verschiedene Zwecke eignen: »cephfs-data-scan« etwa kann den Pool von Metadaten in Ceph-FS neu erstellen, selbst wenn dieser komplett verloren gegangen ist.

Neu ist außerdem das Konzept der Damage Table: In dieser sollen die Reparaturwerkzeuge von Ceph-FS vermerken, wo sie Fehler im Dateisystem ausgemacht haben. Die Ceph-Entwickler wollen so verhindern, dass Clients immer wieder versuchen dieselben defekten Daten zu lesen. Ferner soll die Tabelle der Ausgangspunkt für spätere Reparaturversuche werden. Schließlich hilft die Damage Table auch dabei, die Stabilität des Systems zu verbessern: Finden die Ceph-Werkzeug ein Konsistenzproblem in einem spezifischen Ceph-FS-Subtree, markieren sie in Zukunft den einzelnen Subtree als defekt. Bisher war es nur möglich, größere Bereiche des Dateisystems zu umschiffen.

Klar ist: Die Ceph-FS-Änderungen in Jewel machen das Produkt deutlich reifer und schaffen eine echte Alternative etwa zu Gluster-FS. Freilich wird Ceph-FS in der ersten stabilen Version noch immer einige Bugs enthalten. Doch die Arbeit der Ceph-Entwickler in den letzten Monaten dürfte dafür gesorgt haben, dass die vorhandenen Bugs keinen Datenverlust mehr hervorrufen. Wer Ceph-FS im Rahmen eines Support-Pakets von Red Hat beziehungsweise Inktank nutzen möchte, wird in Jewel dazu höchstwahrscheinlich die Gelegenheit bekommen. Denn Jewel wird eine LTS-Release werden.

Latenzprobleme im Fokus

Die zweite signifikante Ceph-Änderung betrifft den Objektspeicher selbst: Für die Datentanks des Speicherclusters – die OSDs – haben die Entwickler ein neues Storage-Backend vorgesehen. Es soll Ceph besonders bei kleinen Schreibvorgängen deutlich schneller machen.

Nach wie vor gilt: Wenn Ceph ein Blockgerät nutzen soll, muss sich auf der Festplatte oder der SSD ein Dateisystem befinden. Denn Ceph legt Objekte auf den OSDs anhand eines speziellen Namensschemas ab, kümmert sich dabei aber bisher nicht um die Verwaltung des Blockgeräts selbst. Das Dateisystem ist also notwendig, damit der jeweilige »ceph-osd« -Daemon überhaupt den Datenträger nutzen kann.

Im Laufe seiner Geschichte hat Ceph mehrere Dateisysteme für die Aufgabe empfohlen: Zuerst rechneten die Entwickler noch damit, dass Btr-FS in Kürze reif für den produktiven Einsatz sein würde. Sie entwarfen viele Features für Ceph sogar explizit mit Blick auf Btr-FS. Als sich abzeichnete, dass es noch eine Weile bis zu dessen Produktionsreife dauert, änderte Inktank die eigene Empfehlung: Statt Btr-FS ging man nun davon aus, dass XFS am besten auf Ceph-OSDs funktionieren würde (Abbildung 2).

Abbildung 2: XFS ist bisher die Empfehlung der Ceph-Entwickler für OSDs gewesen. In Zukunft wird wohl Blue Store das Mittel der Wahl werden.

So oder so: Sage Weil merkte recht früh, dass ein Posix-kompatibles Dateisystem als Grundlage für OSDs wohl eine schlechte Idee ist. Denn die meisten Garantien, die Posix im Hinblick auf Dateisysteme gibt, sind für Objektspeicher praktisch bedeutungslos. Etwa der parallele Zugriff auf einzelne Dateien: Im Ceph-Cluster kommt dieser nicht vor, weil ein OSD stets nur von einem OSD-Daemon angefasst wird. Und dieser kümmert sich um Requests in sequenzieller Reihenfolge.

Dass Ceph-FS die meisten Posix-Funktionen gar nicht braucht, interessiert ein auf einem OSD liegendes Btr-FS oder XFS freilich wenig. So entsteht beim Schreiben auf OSDs in Ceph schon dadurch einiger Overhead, dass Dateisysteme im Hintergrund Zeit für Posix aufwenden. In Sachen Durchsatz ist das zwar zu vernachlässigen, aber gerade in Sachen Latenz tun überflüssige Checks dieser Art weh. Entsprechend schlagen viele Admins die Hände über dem Kopf zusammen, wenn sie eine VM mit MySQL beispielsweise auf einem Ceph-RBD-Volume betreiben. Ein Vergleich mit schnellen Lösungen wie Fusion I/O verbietet sich von selbst, aber Ceph übertrifft sogar die Ethernet-Latenz eklatant.

Blue Store als Rettung

Blue Store nennen die Ceph-Entwickler ihren Ansatz, um sich des Problems der Posix-Dateisysteme endgültig zu entledigen. Der Ansatz besteht aus mehreren Teilen: So ist Blue-FS ein rudimentäres Dateisystem, es hat gerade so viele Funktionen, wie für den Betrieb einer Platte als OSD nötig sind. Der zweite Teil ist ein auf Rocks DB basierender Key-Value-Speicher, in dem OSDs ihre notwendigen Informationen ablegen.

Weil die Posix-Ebene wegfällt, soll gerade bei kleinen Schreibvorgängen Blue Store seinen Kollegen XFS und Btr-FS haushoch überlegen sein. Diese Behauptung untermauern die Ceph-Entwickler mit aussagekräftigen Performance-Messwerten, die Blue Store klare Vorteile im direkten Vergleich bescheinigen.

Blue Store soll in der Jewel-Version bereits als OSD-Backend nutzbar sein. Allerdings ist die Funktion in Jewel noch als “experimentell” markiert – vom produktiven Einsatz raten die Entwickler also ab. Macht nichts: Allein die Tatsache, dass sie das Latenzproblem verstanden und mit seiner Beseitigung schon begonnen haben, wird viele Admins freuen. Neben Blue Store wird es in Jewel noch eine Reihe weiterer Änderungen geben, die sich insgesamt auf den Durchsatz wie auf die Latenz positiv auswirken sollen.

Das ewige Stiefkind: Calamari

Die etablierten Storagehersteller sind auch deshalb so erfolgreich, weil sie Storagesysteme mit einfachen GUIs ausliefern, mit deren Hilfe sie sich leicht verwalten lassen. Weil ein Objektspeicher mit Dutzenden Knoten nicht weniger komplex ist als ein typischer SAN-Speicher, erwarten Admins von Ceph in der Regel auch eine ähnlich komfortable grafische Oberfläche.

Inktank selbst reagierte vor mehreren Jahren schon auf die ständig wiederkehrenden Fragen nach einem GUI und warf Calamari auf den Markt. Ursprünglich war Calamari ein proprietäres Add-on zu Ceph-Supportverträgen, doch kurz nach der Übernahme von Inktank machten die roten Hüte ein Open-Source-Produkt daraus und luden die Community ein, sich an der Arbeit an Calamari zu beteiligen. Mit mäßigem Erfolg: Bei Admins wie bei Entwicklern stößt Calamari insgesamt auf eher wenig Gegenliebe.

Aus mehreren Gründen: So versteht sich Calamari nicht nur als GUI, sondern gleich als ein ganzes Monitoring-Werkzeug. Es schlägt etwa Alarm, wenn in einem Ceph-Cluster OSDs ausfallen. Auch die Performance eines Ceph-Clusters lässt sich mit Calamari umfassend überwachen. Wer das Tool also installiert, erhält weit mehr als ein simples GUI.

Genau das ist ein Grund dafür, dass der durchschlagende Erfolg bisher ausblieb: Es ist recht kompliziert, Calamari überhaupt zur Kooperation zu überreden. So setzt die Software etwa auf Saltstack, das es auch gleich selbst einrichten will. Wer bereits ein Tool für das Konfigurationsmanagement hat, kann Calamari damit nicht sinnvoll integrieren – und betreibt notgedrungen zwei Automatisierungstools gleichzeitig.

Zudem gibt es auch in Sachen Funktionalität bei Calamari einiges zu bemäkeln. So bietet das Programm zwar eine optische Schnittstellen für alle wichtigen Ceph-Operationen. Die Crush-Map beispielsweise, die die Platzierung einzelner Objekte in Ceph steuert, lässt sich aus Calamari heraus konfigurieren. Doch die Calamari-Oberfläche ist wenig intuitiv und setzt viel Vorwissen voraus, wenn am Ende ein funktionierender Ceph-Cluster herauskommen soll.

Suse und IT-Novum wollen die Situation verbessern

Dass Calamari kaum tauglich für den Masseneinsatz ist, hat man auch bei Suse bemerkt. Suse war – besonders in Europa – ein Pionier in Sachen Ceph; lange bevor Red Hat Inktank erwarb, bastelte Suse bereits an Storage auf der Basis des Objektspeichers. Und obgleich Suse selbst genügend Entwickler hat, die ein neues GUI bauen könnten, entschied man sich lieber dafür, mit IT-Novum zu kooperieren. IT-Novum ist die Firma hinter Open Attic [3], einer Art Appliance-Lösung, die auf Open-Source-Basis Storageverwaltung ermöglicht.

Open Attic selbst war im Linux-Magazin bereits Gegenstand eines ausführlichen Tests http://4. Seit einiger Zeit enthält es im Beta-Branch schon ein Plugin, mit dem sich Ceph-Cluster grundlegend verwalten lassen. Und auf genau diesen Teil von Open Attic bezieht sich die Kooperation mit Suse (Abbildung 3). Denn Suse will künftig mit IT-Novum das Ceph-Plugin für Open Attic verbessern und um zusätzliche Funktionen erweitern. Langfristig soll so echte Konkurrenz zu Calamari entstehen. Wer will, kann sich die Ceph-Funktionen in Open Attic schon jetzt genauer anschauen.

Abbildung 3: Open Attic soll durch eine Kooperation von Suse und IT-Novum das neue GUI der Wahl für die Ceph-Administration werden.

Wann mit ersten Resultaten der Kooperation von Suse und IT-Novum zu rechnen ist, verkündeten die blumigen Pressemitteilungen zwar nicht. Aber beide Unternehmen werden nicht allzu viel Zeit verstreichen lassen, bis erste Resultate vorliegen. Denn ein realer Bedarf ist im Moment klar erkennbar und Open Attic bietet das passende Fundament.

Auch Disaster Recovery bleibt ein Thema

Eines der größten Mankos von Ceph ist nach einhelliger Meinung von Admins der fehlende Support für asynchrone Replikation. Die ist notwendig, um mit Ceph Disaster-Recovery-Setups zu bauen. Freilich ließe sich ein Ceph-Cluster auch über mehrere Rechenzentren hinweg spannen, wenn die Verbindung zwischen den Standorten potent genug ist.

Doch hier greift wieder das Latenzproblem: In Ceph bekommt ein Client die Bestätigung für erfolgreiches Schreiben erst, wenn Kopien des geschriebenen Objekts auf so vielen OSDs vorhanden sind, wie die Replikationsrichtlinie vorgibt. Selbst wirklich gute RZ-Anbindungen haben eine höhere Latenz, als Schreibzugriffe auf Dateisysteme vertragen. Wer auf diese Weise also ein Multi-RZ-Ceph baut, nimmt auf der Client-Seite sehr hohe Wartezeiten beim Schreibzugriff auf den virtuellen Datenträger in Kauf.

Gegenwärtig gibt es mehrere Ansätze in Ceph, um das Problem zu lösen. Für klassische Speicherdienste im Stil von Dropbox eignet sich die Replikation zwischen zwei Ceph-Clustern mit der Rados Gateway Federation (Abbildung 4). Ein zum Rados-Gateway gehörender Agent synchronisiert dabei die Daten zwischen den Pools zweier Rados-Cluster in regelmäßigen Intervallen. Einziges Manko: Die Lösung lässt sich für RBD-Geräte nicht nutzen. Genau die kommen aber etwa bei Installationen auf Basis von Open Stack regelmäßig zum Einsatz.

Abbildung 4: Das Rados-Gateway bietet Dropbox-ähnliche Dienste für Ceph an. In Jewel haben die Entwickler die Off-Site-Replikation im Rados-Gateway deutlich verbessert.

Es muss also eine andere Lösung her. In der Jewel-Version von Ceph haben die Entwickler die Grundlage dafür geschaffen: Der RBD-Treiber hat in Zukunft ein Journal, in dem eingehende Schreiboperationen vermerkt sind. Für jedes RBD-Gerät ist also nachvollziehbar, welche Veränderungen stattfinden. Damit entfällt die Notwendigkeit synchroner Replikation für Inter-RZ-Links: Wenn der Inhalt des Journals regelmäßig zwischen den Standorten repliziert wird, lässt sich hüben wie drüben stets ein konsistenter Zustand herstellen.

Im Falle eines Falles kann es so zwar passieren, dass es nicht jeder Write vom aktiven ins Stand-by-Rechenzentrum schafft, wenn ersteres von einem Meteoriten getroffen wird. Dem Anbieter ist das aber vermutlich lieber als der tagelange Ausfall aller Dienste.

Übrigens: Auch die schon erwähnte Multi-Site-Replikation im Rados-Gateway haben die Entwickler für Jewel nochmals gehörig überarbeitet. So lässt sich das Setup nun im Aktiv-Aktiv-Modus betreiben. Auch der bis dato genutzte Agent soll künftig unmittelbarer Teil des Rados-Gateway selbst sein, sodass der Betrieb eines zusätzlichen Dienstes entfällt.

Alltägliches für Sysadmins

Neben den großen Baustellen waren in der Jewel-Release auch die Kleinigkeiten Thema. Zwar gab es in Ceph bereits seit Mitte 2014 offiziell Unitfiles für den Betrieb mit Systemd; für Jewel haben die Entwickler jene aber nochmals gehörig aufgemotzt. Für jeden einzelnen Ceph-Dienst existiert nun ein Unitfile, und einzelne Instanzen – etwa OSDs – lassen sich auf Systemen mit Systemd gezielt starten oder stoppen.

Ähnliches gilt für die Integration ins Security-Framework SE Linux. Ubuntu-Nutzer, die lieber auf den Ubuntu-Standard App Armor setzen, schauen aber in die Röhre und müssen, wenn es zu Problemen kommt, selbst Hand anlegen. Für Jewel haben sich die Entwickler auch das Thema Sicherheit vorgenommen: Ceph nutzt ein eigenes Authentifizierungssystem namens Ceph X, wenn sich Nutzer oder einzelne Dienste wie OSDs, Metadatenserver oder MONs am Cluster anmelden wollen (Abbildung 5).

Abbildung 5: Ceph X wird in Zukunft besser gegen Brute-Force-Angriffe gesichert sein. Unklar ist aber, ob diese Funktion es noch in Jewel schafft.

Dafür wird es künftig einen Schutz gegen Brute-Force-Angriffe geben: Versucht ein Client, sich zu oft am Cluster mit falschen Credentials anzumelden, kommt er automatisch auf eine Blacklist. Alle weiteren Anmeldeversuche lehnt Ceph dann ab, ohne Rücksicht darauf, ob die genutzte Kombination aus Username und Passwort stimmt oder nicht. Bei Redaktionsschluss war auf dieser Baustelle allerdings noch kein Fortschritt zu erkennen. Ob es die Funktion in Jewel schafft oder auf die nächste Ceph-Version warten muss, ist also unklar.

Fazit: Auf dem Weg zum universalen Speicher

In der Jewel-Release gehen die Ceph-Entwickler viele der wichtigen Probleme an, die Ceph für manche Einsatzszenarien bisher unbrauchbar gemacht haben. Gerade Ceph-FS wird als stabile Release ein neues Marktsegment eröffnen und Ceph auch als Ersatz für etwas behäbige NFS-Installationen interessant machen. Wenn Suse und IT-Novum ihren Versprechen Taten folgen lassen, dürfte die Administration von Ceph per GUI in absehbarer Zeit deutlich leichter werden. Replikation über die Grenzen von Rechenzentren hinweg macht Ceph für Disaster Recovery salonfähig.

Für Gluster-FS verheißen diese Features wenig Gutes: Zwar bekennen sich die roten Hüte bisher zu ihrem Produkt, doch mittelfristig wird man nicht Geld in die Entwicklung zweier Projekte investieren, wenn Ceph Gluster-FS ersetzen kann und zudem viel mehr Funktionalität bietet. Im Grunde stellt sich Ceph mit den Jewel-Änderungen einem universalen Anspruch in Sachen Software Defined Storage.

Die Jewel-Release verorten die Ceph-Entwickler übrigens in “Q1/2016”. Mit etwas Glück ist Jewel also bereits erschienen, wenn dieser Artikel zu lesen ist. Wie üblich gilt, dass ein Ceph-Update kein Pappenstiel ist. Ferner scheint es eine gute Idee zu sein, die ersten Bugfix-Releases von Jewel abzuwarten, die erfahrungsgemäß in den ersten Wochen nach Version 10.0 kommen.

Über einen Update-Pfad war den Ceph-Entwicklern bis zum Redaktionsschluss nichts zu entlocken. Möglich also, dass ein Ceph-Update auf Jewel keine triviale Angelegenheit wird. Die vielen neuen Funktionen und Veränderungen unter der Haube legen das jedenfalls nahe.

Der Autor

Martin Gerhard Loschwitz arbeitet als Cloud Architect bei Sys Eleven. Er beschäftigt sich dort intensiv mit den Themen Open Stack, Distributed Storage und Puppet. Außerdem pflegt er in seiner Freizeit Pacemaker für Debian.