Drahtlose Netzwerke sind überall: Zu Hause, im Café und in der Firma. Im Gegensatz zu Kabelnetzen verliert der Admin bei WLANs allerdings schnell die ... (mehr)

Was Firefly bringt

Angesichts der Tatsache, dass Ceph alles andere als Feature-complete ist, stellt sich freilich die Frage nach dem Next Big Thing. Tatsächlich werkeln die Ceph-Entwickler derzeit an zwei Features für die nächste Version ("Firefly"), die Sensationspotenzial haben: Storage Tiering auf der einen und Erasure Coding auf der anderen Seite. Beide Technologien richten sich gezielt an Enterprise-Kunden – was bewirken sie, was wird durch sie besser?

Am Erasure-Coding-Feature hätte zumindest eine deutsche Kleinpartei ihre helle Freude – letztlich geht es nämlich um nichts anderes als "Mehr Netto vom Brutto". Gemeint ist freilich Speicherkapazität. Aktuelle Versionen von Ceph kranken an der Tatsache, dass sie Redundanz intern lediglich über die bloße Replikation binärer Objekte ermöglichen. Von jedem Objekt gibt es eine exakte Kopie an einer anderen Stelle im Cluster.

Wer mehr als eine Replika pro Objekt haben möchte, verliert also effektiv jedes Mal einen sehr großen Teil an verfügbarer Speicherkapazität. Mit drei Replikas pro Objekt wird aus einem 90-Terabyte-Cluster so ein deutlich kleinerer 30-Terabyte-Cluster. Dieses Verhalten ist insofern lästig, als im Storage-Umfeld ja durchaus schon fertige Lösungen dafür existieren, wie man das Problem eleganter löst: RAID-Systeme garantieren beispielsweise Redundanz ohne einen solch extremen Abfall der Nettokapazität.

Erasure Coding soll die Möglichkeit in Ceph bringen, effektiver in Hinblick auf den vorhandenen Speicherplatz Redundanz zu gewährleisten. Eine genaue Beschreibung des Prinzips würde den Rahmen des Artikels sprengen, im Grundsatz funktioniert die Lösung aber so: Anstatt von binären Objekten ganze Replikas zu bauen, führt der Cluster ein System von Paritätsdaten ein und teilt die Daten anschließend in Chunks auf (Abbildung 3). Anhand der Paritätsdaten lässt sich über eine XOR-Tabelle die Platzierung einzelner Chunks errechnen.

Abbildung 3: Erasure Coding beschreibt Entwickler Loic Dachary als "anderen Namen für RAID 5". Jedenfalls geht es um das Chunk-basierte Ablegen von Daten.

Das System ist den üblichen Mechanismen von RAID-Lösungen wie RAID 5 also sehr ähnlich, freilich gibt es aber auch einen Pferdefuß: In Abhängigkeit von der gewählten Granularität fallen in einem Erasure-Coding-Szenario beim Recovery deutlich mehr Netzwerkzugriffe und auch mehr Traffic an, sodass der gesamte Vorgang unter Umständen mehr Zeit in Anspruch nimmt. Wer seine OSDs über eine 10-Gbit-Verbindung miteinander reden lässt, dürfte von diesem Effekt nichts spüren; in Betracht ziehen sollten Administratoren ihn aber dennoch.

Der Nutzen des Erasure Coding ist im Vergleich jedenfalls kaum groß genug einzuschätzen. Wie der Upgrade-Pfad aussehen wird und ob oder wann es möglich sein wird, bestehende Installationen auf Erasure Coding zu ändern, stand zu Redaktionsschluss übrigens noch nicht fest. Dass das Feature in der Firefly-Version kommen wird, darf hingegen als sicher gelten – denn bereits Mitte Dezember waren die Alpha-Tester fleißig bei der Arbeit. Das ist insofern beruhigend, als dass Erasure Coding einige Umbauarbeiten im Code von Ceph erfordert; offenbar geht man bei Inktank auf Nummer sicher. Loic Dachary von Cloudwatt, der maßgeblich für das Erasure-Coding-Feature verantwortlich ist, ist als Speaker regelmäßig bei den Ceph-Days anwesend. Wer ihn also persönlich zum Thema befragen will, hat im Rahmen dieser Veranstaltungen die Möglichkeit dazu.

Tiering

Und dann sollte freilich auch das Thema Tiering nicht unerwähnt bleiben. In der Storage-Welt genießt dieses mittlerweile hohe Priorität, denn es ist eine attraktive Lösung, "wichtige" oder gerade benutzte Daten in einem schnellen Storage zwischenzuspeichern, während ältere, nicht mehr regelmäßig benötigte Daten durchaus auch auf langsameren Spinner-Disks liegen können. Angesichts der noch immer heftigen Preise für Flash-basierten Speicher bietet Tierung auf der Storage-Ebene auch enormes Potenzial Kosten zu sparen.

Ceph beherrscht Tiering im Ansatz ja eigentlich ohnehin schon seit etlichen Versionen. Denn über den von Ceph genutzten CRUSH-Algorithmus ist es problemlos möglich, verschiedene Pools in Ceph mit verschiedenen Speicherzielen zu verbinden. Ein Speicherpool namens »ssd« könnte also beispielsweise auf schnelles Storage zeigen, während ein Storage namens »sata« für Archivstorage gedacht wäre. In der Realität scheitert echtes Tiering in Ceph jedoch daran, dass die Daten im Moment nicht flexibel zwischen unterschiedlichen Tiering-Layern hin- und herwandern können. Es besteht also nicht die Möglichkeit, gerade genutzte Daten temporär auf das »ssd« -Storage auszulagern, um sie danach wieder auf die »sata« -Ebene zu verschieben. Tiering wird genau diese Möglichkeit bieten, und wie beim Erasure-Coding sind die Arbeiten an der Funktion bereits in vollem Gange (Abbildung 4).

Abbildung 4: Auch an Kleinigkeiten schrauben die Ceph-Entwickler bisweilen herum; die Anzeige des Watchmodes von ceph hat sich über die letzten Versionen mehrere Male geändert. Hier: Emperor.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2020