Offsite-Replikation in Ceph: Wege und Werkzeuge

Teamsport

Martin Gerhard Loschwitz

Der Object Storage Ceph beherrscht nur die synchrone Replikation – wer Daten an einen anderen Standort kopieren will, braucht zusätzliche Funktionen.

So manche Technik hat sich im Fahrwasser der Cloud bereits Bahn gebrochen und verfestigt und stellt damit bestehende Geschäftsmodelle auf eine harte Probe. Ein Beispiel dafür ist Ceph: Mit Cloud-Setups zusammen wächst der objektbasierte Storage-Cluster beinahe ohne Grenzen.

Weil es auf Commodity-Hardware setzt, kostet Ceph nur einen Bruchteil dessen, womit klassische SAN-Systeme zu Buche schlagen: Ein PByte Nettokapazität für eine halbe Million Euro ist mit Ceph umstandslos möglich – und kostenlos dazu gibt es die panischen Blicke der Vertreter von NetApp, Dell-EMC und Konsorten, die gegen diese Preise kaum ankommen. Wie verzweifelt man bei den etablierten Storage-Herstellern ist, zeigt sich auch daran, dass diese mittlerweile versuchen, neue Geschäftsfelder anzuzapfen – NetApp etwa geht seit einiger Zeit mit einer Kubernetes-Distribution auf Kundenfang.

Suchen die Vertreter der klassischen Storage-Systeme Argumente gegen Ceph, dauert es meist nicht lange, bis der Begriff Disaster Recovery fällt. In der Tat war Ceph hier ziemlich lange ziemlich blank, denn der Objektspeicher, der Ceph zugrunde liegt, RADOS, beherrscht nur synchrone Replikation. Das indes macht das Kopieren von Daten an einen anderen Standort ziemlich kompliziert.

Die Vertreter etablierter Storage-Silos nutzten die fehlende Offsite-Replikation in der Vergangenheit gern als Totschlagargument gegen Ceph, wohl wissend, dass sie für Disaster-Recovery-Setups gleich mehrere Exemplare ihrer Produkte unters Volk bringen würden.

Doch die Welt entwickelt sich weiter und auch bei Ceph hat man sich in den vergangenen Jahren intensiv mit der Replikation hin zu einem anderen Standort beschäftigt. Heute existieren mehrere Wege in Ceph, Daten zwischen Standorten hin- und herzukopieren. Die hängen auch vom genutzten Frontend ab. Grund genug, sich des Themas detailliert anzunehmen. Dieser Artikel beschreibt die Herausforderungen der Replikation in Ceph und wie sie zu meistern sind.

Für Ceph-Admins gibt es mehrere Gründe, sich mit den Themen Offsite-Replikation und Disaster-Recovery-Setup zu befassen. Erstens sind Cloud-Umgebungen nicht selten geografisch verteilt und etwa in mehrere Zonen gesplittet. Viele Anwender wünschen sich, dass die Daten aus einer Region auch in einer anderen Region verfügbar sind. Das würde jedoch bedeuten, sie zwischen verschiedenen Standorten hin- und herzukopieren.

Warum mehrere Standorte?

Zweitens: Viel häufiger kommt Disaster Recovery als potenzieller Anwendungszweck ins Spiel. Fällt ein einzelner Standort aus, gilt es, die Wiederanlaufzeit so kurz wie möglich zu halten. Das funktioniert nur, wenn die benötigten Daten an einem anderen Standort vorliegen. Auch hier ist das Kopieren der Daten über die Grenzen eines Standortes hinweg notwendig.

Weniger valide ist hingegen ein Ansinnen, das vielen Administratoren beim Thema Ceph und Multi-Standort-Setup ebenfalls einfällt: das Anlegen von Backups. Dass Replikation und Backups nicht dasselbe sind, ist eigentlich eine Binsenweisheit. Trotzdem assoziieren nicht wenige mit Replikation auch das implizite Anlegen von Backups. Zugegeben: Fällt ein Airbus A380 auf ein Rechenzentrum, wirken die replizierten Daten an einem anderen Standort im besten Falle ähnlich wie ein Backup.

Viel häufiger brauchen Admins Backups allerdings, um Missgeschicke zu korrigieren. Löscht ein Nutzer Daten auf dem einen Ceph-Cluster, würde die korrekt konfigurierte Replikation sie auch auf der anderen Seite der Offsite-Replikation verschwinden lassen. Hier gilt wie üblich, dass der Admin eines Ceph-Clusters idealerweise ein eigenes Backup-Konzept verfasst, in dem Offsite-Replikation sicherlich eine Rolle spielen kann. Ersetzen kann sie es aber nicht.

Wie Ceph Daten entgegennimmt und verteilt

Ceph gehört zur Riege der Objektspeicher. Das heißt, ein Ceph-Cluster speichert jede in ihn hochgeladene Information als Binärdaten. Binäre Daten haben einen unschlagbaren Vorteil: Sie sind bei Bedarf beliebig trennbar und lassen sich später wieder zuverlässig zusammensetzen, solange beides in der richtigen Reihenfolge geschieht. Das bildet die Voraussetzung, Dateien über viele Speichergeräte zu verteilen.

Mit diesem Verfahren ziehen Objektspeicher eine Abstraktionsebene zwischen Blockspeichern und dem Zugriff auf Daten durch Clients. Das heißt aber, auch bei Objektspeichern bilden Blockgeräte das Rückgrat. Clients greifen darauf aber nur über den Objektspeicher zu und nicht direkt auf die Dateisysteme, die auf eben diesen Blockgeräten liegen.

Den Kern von Ceph bildet der eigentliche Objektspeicher RADOS (Reliable Autonomic Distributed Object Store). Er verteilt die binären Daten und repliziert sie innerhalb des Clusters so oft, wie der Administrator es in der Replikations-Policy vorgibt. Dazu benötigt er zwei Dienste: den OSD und den MON.

Auf jedem Blockspeicher eines Ceph-Clusters läuft ein OSD (Object Storage Daemon). OSDs bilden mithin die Silos des Clusters, in denen die Nutzdaten landen. Lädt ein Client Objekte auf ein einzelnes OSD hoch, kümmert der sich im Nachgang um die Replikation hin zu weiteren OSDs.

Die Überwachung der OSD-Kommunikation obliegt den MONs. Als Wachhunde des Clusters verhindern die Monitoring-Dienste die verhassten Split-Brain-Situationen beim Zerbrechen eines Ceph-Clusters. Hat ein Cluster etwa drei MONs und zerbricht in zwei Teile, funktioniert anschließend nur der Teil mit der Mehrheit der MON-Server. Zudem pflegen sie die Verzeichnisse aller MONs und OSDs und geben sie auf Anfrage an die Clients weiter.

Clients zerteilen die Daten, die in RADOS landen sollen, bereits vor dem Hochladen in binäre Objekte unter Zuhilfenahme des pseudozufälligen CRUSH-Algorithmus. Intern organisiert RADOS die binären Objekte nicht einzeln, sondern gruppiert sie aus Performancegründen zu sogenannten Placement Groups (PGs). Die sind immer auch „co-located“, das heißt, alle zu ihnen gehörenden binären Objekte liegen auf denselben OSDs. Die Replikation in RADOS geschieht insofern stets auf Basis der PGs, nie auf Basis einzelner Objekte.

Schreiben in Ceph

Möchte ein Client Daten in RADOS ablegen, führt er zunächst die Aufteilung in binäre Objekte und deren Zuweisung zu Placement Groups durch. Der erwähnte CRUSH-Algorithmus liefert für jede Placement Group auch das Primary OSD mit, auf das der Client die jeweilige Placement Group hochlädt. Dabei parallelisiert er das Hochladen auf so viele PGs wie möglich, um die Clusterressourcen effizient zu nutzen.

Hat der Client den Upload auf das primäre OSD abgeschlossen, führt Ceph erneut eine CRUSH-Kalkulation durch, um die restlichen OSDs für die jeweilige Placement Group zu ermitteln, und kopiert die Daten dorthin. Erst wenn die Objekte dort angekommen sind, sendet das primäre OSD dem Client das „Okay“ für den gesamten Schreibvorgang. Hierin liegt auch der Grund, warum Ceph höhere Latenzen aufweist als klassische SAN-Systeme.

Zudem setzt Ceph auf Ethernet, das nicht gerade für geringe Latenzen bekannt ist. Während der Durchsatz, den Ethernet bietet, in den vergangenen Jahren sukzessive gewachsen ist, hat sich die Latenz kaum verringert (siehe Abbildung 1).

Bei der Latenz kann Ceph keinen Blumentopf gewinnen – Ethernet und CRUSH tragen dafür die Verantwortung (Abb. 1).

Red Hat

Ein beliebter Trick in Ceph, den fast jeder produktive Ceph-Cluster nutzt, ist das Auslagern des Journals der OSDs auf schnelle SSDs. In Ceph hat jedes OSD ein Journal, das als riesiges Write-ahead-Log fungiert. Es hat dieselbe Aufgabe wie Dateisystemjournale, nämlich für den Fall einer Stromunterbrechung den zu schreibenden Inhalt zwischenzulagern. Dadurch landen Schreibvorgänge immer erst im Journal und dann auf dem eigentlichen Datenträger.

Allerdings sollte man nicht zu viele OSD-Journale auf eine SSD auslagern – der Erfahrung des Autors nach sollten es kaum mehr als vier sein. Zu bedenken ist auch: Verliert ein OSD sein Journal, kann Ceph es nicht mehr benutzen, bis der Admin es entfernt und dem Cluster erneut hinzugefügt hat. Stirbt etwa eine SSD mit 12 OSD-Journalen darauf, verliert der Cluster sofort 12 OSDs – der daraus resultierende Resynchronisationstraffic kann schlimmstenfalls andere Clusterknoten in Mitleidenschaft ziehen und sogar den gesamten Cluster abschießen.

Technisch betrachtet funktioniert der OSD-Trick mit Journalen auf SSDs übrigens auch und gerade deshalb, weil Ceph das erfolgreiche Write bereits nach dem Eintrudeln der Daten im jeweiligen Journal quittiert. Allerdings: Eine Einstellung, die Schreibbestätigung noch früher rauszuschicken, gibt es in RADOS nicht. RADOS war stets auf lokale, synchrone Replikation ausgelegt.

Stretched – den Cluster strecken

Der Kasten „Wie Ceph Daten entgegennimmt und verteilt“ beschreibt, wann Ceph einem Client einen Schreibvorgang bestätigt. Angesichts dessen stellt sich die Frage, wie sich die Offsite-Replikation von Ceph sinnvoll gestalten lässt. Viele Administratoren denken sofort daran, einfach die Knoten eines Ceph-Clusters über mehrere Standorte zu verteilen. Was im ersten Augenblick sinnvoll klingt, stellt sich bald als katastrophale Fehlplanung heraus – und das aus mehreren Gründen (siehe Abbildung 2).