Neues Backend bei Ceph
Massiv beschleunigt
Mit dem neuen Storage-Backend BlueStore lässt sich Ceph ohne darunterliegendes Dateisystem nutzen. Das bringt mehr Tempo.
Wer skalierbaren Speicher für große Umgebungen baut, landet irgendwann fast automatisch bei Ceph. Möchte man etwa eine OpenStack-Cloud mit Storage zuverlässig versorgen, ist Ceph eine gute Option. Zudem wächst es bei Bedarf mit: Wird die Cloud größer, lässt sich der Speicher problemlos um mehr Knoten erweitern. Ceph eignet sich für große Installationen aus diversen Gründen: Es ist stabil und zuverlässig, sodass Admins sich keine Gedanken um die Sicherheit ihrer Daten machen müssen. Zudem steht Red Hat als Besitzer von Inktank hinter Ceph – ein Hersteller also, der sowohl finanziell potent ist als auch unter Beweis gestellt hat, dass er die Idee von Open-Source-Software versteht und umzusetzen weiß.
Obwohl viele produktive Ceph-Cluster seit Jahren stabil laufen, arbeiten die Entwickler kontinuierlich an Ceph-Verbesserungen. Der neueste Clou ist BlueStore, das sie mit der jetzt erfolgten Freigabe als „stabil“ und damit als für den produktiven Einsatz geeignet eingestuft haben. Dahinter verbirgt sich ein neues On-Disk-Format für die Arbeitstiere in Ceph, die Object Storage Devices oder kurz OSDs: BlueStore soll einen massiven Schub in Sachen Performance bringen und verschiedene Probleme aus der Welt schaffen, die Entwickler und Nutzer seit Jahren nerven. Dieser Artikel stellt das neue Konzept vor und erklärt, warum ein Ceph-Cluster mit BlueStore besser und schneller funktioniert als bisher.
Um die Auswirkungen von BlueStore zu verstehen, ist ein kleiner Ausflug in das Innenleben von Ceph nötig. Zur Erinnerung: Die OSDs sind in einem Ceph-Cluster die Datensilos. Hier liegen also die tatsächlichen Nutzdaten, die Anwender in den Cluster hochgeladen haben. Weil Ceph ein Objektspeicher ist, zerteilt es jene Daten in kleine Stücke – eben die Objekte. In der Standardkonfiguration sind diese vier Megabyte groß. Intern organisiert Ceph sich allerdings nicht auf Basis einzelner Objekte, sondern nutzt dafür Placement Groups, kurz PGs: Jedes binäre Objekt innerhalb eines Ceph-Clusters gehört zu einer solchen PG. Die Zugehörigkeit zu einer Placement-Gruppe entscheidet darüber, welche OSDs innerhalb des Clusters die Replicas des jeweiligen Objektes beherbergen. Auch das Überprüfen der Integrität von Daten oder das erneute Kopieren nach einem OSD-Ausfall geschieht auf Basis eben jener Placement-Gruppen.
Ein Blick auf Ceph-Interna
Aber: Sowohl die Aufteilung in Placement Groups als auch die in binäre Objekte passiert innerhalb von Ceph. „An der Außenseite“ ist davon nichts zu sehen – guckt man sich stattdessen den Inhalt eines OSD auf der Kommandozeile an, findet man lediglich einzelne Dateien mit kryptischen Namen, die auf den Festplatten in einer bestimmten Struktur abgelegt sind. Dass dieses Nachschauen überhaupt funktioniert, liegt daran, dass auf den OSDs fast immer ein Dateisystem werkelt. Im ersten Augenblick klingt das ganz logisch: OSDs sind in der Regel ganz normale Festplatten – also Blockgeräte.
Ab Werk lassen sich auf diesen Daten bekanntlich gar nicht strukturiert ablegen. Der OSD-Daemon von Ceph könnte seine Objekte zwar auf eine Platte schreiben; er könnte aber ohne eine wie auch immer geartete Protokollierung anschließend nicht zielgerichtet auf diese zugreifen. Um die zu einer bestimmten Placement-Gruppe gehörenden binären Objekte zu finden, müsste er stattdessen den Datenträger durchsuchen. Weil dabei unmöglich die bei modernen Storages benötigte Performance zu erreichen ist, hat sich XFS quasi als Standarddateisystem für OSDs etabliert (siehe Abbildung 1 und 2).
Das vermag aber nicht darüber hinwegzutäuschen, dass innerhalb der Community und aufseiten der Entwickler viele Menschen mit XFS und generell mit POSIX auf der OSD-Ebene unzufrieden sind. Zwar bieten POSIX-kompatible Dateisysteme viele Garantien, die Ceph aber nichts nützen. Ein binäres Objekt etwa verändert sich – einmal auf ein OSD geschrieben – praktisch nicht mehr.
Ungeliebtes POSIX
Auch der konkurrierende Schreibzugriff auf einzelne Objekte ist im Grunde unproblematisch, denn Ceph kümmert sich darum komplett selbst: Nutzer greifen stets nur über den Umweg des OSD auf die Objekte zu, die auf einem OSD-Dateisystem liegen. Und für eine Festplatte ist nur ein einzelner Daemon zuständig, der alle Zugriffe koordiniert. POSIX-Dateisysteme jedoch müssen all diese Optionen per Standard sinnvoll abdecken. Sie enthalten viel Logik, das Korrumpieren von Daten zu verhindern. Ceph entstehen dadurch nur Nachteile, die sich besonders in verminderter Performance niederschlagen. Hinzu kommt, dass sich mit POSIX-kompatiblen Dateisystemen viele Funktionen nur schwierig oder gar nicht nutzen lassen, die Ceph eigentlich benötigt – weil es, anders als jene, verteilt ist. Ein gutes Beispiel dafür sind atomare Transaktionen.
Herkömmliche Dateisysteme können Schreibvorgänge nicht atomar abwickeln. Wer sich schon mit Datenbanken beschäftigt hat, kennt von dort das ACID-Prinzip: Danach sind Transaktionen „atomar“ (atomic) durchzuführen – also ganz oder gar nicht. Zudem ist sicherzustellen, dass die Daten konsistent (consistent) sind, das heißt der vorliegende Datensatz jederzeit vollständig ist. Transaktionen müssen auch voneinander isoliert (isolated) sein – jede der vorgenommenen Änderungen muss den Datensatz in konsistentem Zustand zurücklassen. Zudem zielt die Haltbarkeit (durability) der Daten darauf ab, dass diese sich nicht nach einer erfolgreichen Transaktion von alleine verändern.