Das Titelthema im ADMIN 04/14 "Vernetzt speichern" sind Netzwerkdateisysteme, etwa Samba 4, verteilter Storage mit Ceph & GlusterFS und der Unix-Klassiker ... (mehr)

Replikation bei Ceph

Während sich konventionelle Storage-Systeme oft verschiedener Tricks und Kniffe bedienen, um Redundanz über Replikation zu gewährleisten, ist bei Ceph das Thema Replikation (im Formationsflug mit Hochverfügbarkeit der Daten) quasi inhärent in das Design eingeflossen. Sage Weil hat sich viel Mühe dabei gegeben, einerseits zuverlässige Replikation möglich zu machen und andererseits den Nutzer davon so wenig wie möglich merken zu lassen. Grundlage für die Replikation im Hintergrund ist die Plauderei, die innerhalb eines Clusters zwischen einzelnen OSDs abläuft: Sobald ein Nutzer ein binäres Objekt auf ein OSD hochlädt, bemerkt das OSD diesen Vorgang und fängt mit der Replikation an: Es rechnet sich anhand der im Cluster vorhandenen OSD- und MON-Server mit dem CRUSH-Algorithmus aus, auf welche OSDs er das neue Objekt kopieren muss und tut das dann auch entsprechend.

Der Administrator legt über einen separaten Wert für jeden Pool (das ist der Name für eine logische Organisationseinheit, in welche sich ein Ceph-Cluster aufteilen lässt) fest, wie viele Replikas jedes Objekts in diesem Pool vorhanden sein sollen. Weil Ceph grundsätzlich synchron funktioniert, erhält ein Benutzer für einen Schreibvorgang erst in dem Augenblick eine Bestätigung, in dem entsprechend viele Kopien des vom Client hochgeladenen Objekts Cluster-weit existieren.

Zusätzlich kann Ceph sich selbst heilen, wenn etwas schiefgeht: Den Ausfall einer Festplatte quittiert es nach einer festgelegten Zeit (ab Werk fünf Minuten) damit, dass es alle nun fehlenden Objekte sowie deren Replikas auf andere OSDs neu kopiert. So stellt Ceph sicher, dass die Replikationsvorgaben des Admins durchgehend erfüllt sind – von dem erwähnten Interval direkt nach dem Ausfall einer Platte einmal abgesehen.

Der Anwender merkt von alledem übrigens nichts; das Unified-Storage-Prinzip versteckt Ausfälle innerhalb des Clusters vor den Clients.

Frontends – ein Nachtrag

Auf den ersten Blick mutet es eigenartig an, nach eventuell vorhandenen Programmierschnittstellen bei einer Speicherlösung zu fragen; schließlich kennen die meisten Admins zentrale Speicher aus SAN-Zeiten und wissen, dass diese ein einheitliches Interface anbieten, mehr aber nicht. Das liegt im Normalfall daran, dass SAN-Storages intern nach einem festgelegten Muster funktionieren, das einen Programmierzugriff so ohne Weiteres gar nicht ermöglicht: Was sollte beispielsweise der Zugriff auf Programmierebene im SAN-Kontext bringen?

Bei Ceph ist die Sache anders, denn Ceph bietet durch sein Design eben jene Flexibilität, die Blockspeicher nicht haben: Weil es seine Daten im Inneren selbst verwaltet, kann Ceph im Grunde jedes beliebige Interface zur Außenwelt exponieren, solange dafür entsprechender Code vorhanden ist. Bei Ceph gibt es also durchaus Verwendung für Programmierbibliotheken, die den Zugriff auf Objekte standardisiert betreuen. Tatsächlich bieten in Ceph gleich mehrere Bibliotheken diese Funktionalität. Einerseits ist die Librados eine C-Bibliothek, deren Benutzung den direkten Zugriff auf in Ceph gespeicherte Objekte ermöglicht. Zusätzlich gibt es für die beiden Frontends RBD und CephFS eigene Bibliotheken namens »librbd« und » libcephfs« , welche Userspace-Zugriff auf deren Funktionalität möglich machen.

Für »librados« existieren obendrein mehrere Bindings für diverse Skriptsprachen, sodass auch dort der Userspace-Zugriff auf Ceph möglich wird – beispielsweise für Python und PHP.

Die Vorteile dieser Programmierschnittstellen lassen sich anhand von zwei Beispielen gut verdeutlichen: Einerseits ist auf Basis der »librbd « und der »librados« das RBD-Backend von Qemu realisiert, dass es Qemu erlaubt, auf VMs direkt im Ceph-Speicher zuzugreifen, ohne den Umweg über das »rbd.ko« -Kernelmodul zu gehen,andererseits ist eine ähnliche Funktionalität auch in »tgt« implementiert, sodass der TGT-Daemon ein RBD-Image als iSCSI-Export anlegen kann, ohne dafür irgendwie im Kern des Betriebssystems unterwegs zu sein. Sogar für das PHP-Binding gibt es einen nützlichen Anwendungsfall: Image-Hoster arbeiten mit großen Mengen Bildern, die Binärdateien sind – üblicherweise liegen diese allerdings auf einem POSIX-kompatiblen Dateisystem [10] und werden zum Beispiel mittels NFS exportiert. POSIX-Funktionalität ist in solchen Fällen allerdings fast immer überflüssig. Über das PHP-Binding von »librados« lässt sich eine Webapplikation bauen, die im Hintergrund Bilder direkt in Ceph ablegt, sodass der POSIX-Umweg entfällt. Das ist effizient und spart Ressourcen, die anderen Diensten zugutekommen können.

Ä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 /2021