Login
Login-Name Passwort


 
Newsletter
Werbung

Do, 5. Dezember 2013, 15:00

Ceph

Verteilter Object Store

Bei Ceph handelt es sich um einen über beliebig viele Server redundant verteilten »Object Store«. »Objects« sind dabei (meist) binäre Dateien, die Ceph unter anderem zu einem über mehrere Server verteilten »Block Device« zusammenfassen kann. Daher eignet sich Ceph hervorragend für die Datenspeicherung von einzelnen Dateien (Objects) oder als Backend-Storage für virtuelle Maschinen.

Bei verteilten Systemen ist es sehr gerne gesehen, ein sogenanntes »Shared Nothing«-Prinzip anzuwenden – jeder Host kann ohne den anderen überleben, denn es gibt bei solchen Systemen keinen zentralen Master, der unbedingt erforderlich ist. Ein Problem, das bei solchen Systemen auftreten kann, ist der sogenannte »Split Brain«, also beispielsweise ein Netzwerkausfall zwischen den Systemen. Dabei glaubt jedes System, dass es weiterarbeiten kann (»shared nothing«), und es können irreparable Schäden in so einem System entstehen.

Vorweg: Ceph hat keinen »Single Point of Failure«. In Ceph kann jede Komponente ausfallen, und Ceph ist doch in der Lage, sich selbst zu heilen, d.h., die fehlenden Daten von kaputten Festplatten werden von Replikaten auf anderen Speichermedien wiederhergestellt. Es ist aber auch kein Shared-Nothing-System; daher hat es die Fähigkeit, die Split-Brain-Situation zu erkennen und sie dadurch konzeptuell zu verhindern. Obwohl Ceph von der Firma Inktank entwickelt wird, ist Ceph Open-Source-Software. Es gibt keine kommerzielle Version von Ceph, lediglich Support kann man bei Inktank kaufen.

Das Konzept

Ceph speichert im untersten Layer Objekte, die im Prinzip Dateien sind. Diesen Layer nennt Ceph »RADOS« (Reliable Autonomic Distributed Object Store). Es ist kein Dateisystem im eigentlichen Sinne, sondern besteht einfach nur aus losen, nicht zusammenhängenden Dateien, die in diesem System niedergeschrieben werden. Auf diesen Layer kann man als Entwickler entweder mit librados (einer Bibliothek für C, C++, Java, Python, Ruby und PHP) direkt zugreifen, oder aber mit verschiedenen Schichten darüber arbeiten, die Ceph zur Verfügung stellt.

Das Konzept von Ceph

Wolfgang Hennerbichler

Das Konzept von Ceph

Funktionsweise

Ceph baut auf einem Algorithmus auf, der sich »CRUSH« (Controlled Replication Under Scalable Hashing) nennt. Muss ein Objekt gelesen oder geschrieben werden, fragt ein Client bei Ceph keinen Metadaten-Server ab, auf welchem Ceph-Node dieses Objekt liegt, sondern es wird vielmehr aus dem Dateinamen ein Hash gebildet, der einer sogenannten »Placement Group« entspricht. Der CRUSH-Algorithmus berechnet anhand der Placement Group und dem aktuellen Zustand des Clusters (d.h., welche Server laufen, welche Server sind ausgefallen) einen eindeutigen Ort, wo das Objekt liegen muss, und sendet die Lese-/Schreibanfrage dann direkt an diesen Server.

Eine Placement Group ist dabei ein Container, in dem scheinbar zufällig Objekte zusammengefasst auf einem Server gespeichert werden. Scheinbar zufällig, da mit CRUSH der Ort der Dateien immer wieder reproduzierbar auffindbar ist.

Object Storage Nodes

Die sogenannten »Object Storage Daemons« (OSD) sind in Ceph die Arbeitstiere. Diese Server melden sich an den sogenannten »Monitor Nodes« (siehe unten) an und replizieren die Objekte, sofern notwendig, untereinander. In Ceph bricht man normalerweise RAID-1- oder RAID-5-Konfigurationen auseinander und spricht stattdessen jede Festplatte einzeln an. Pro Festplatte wird ein OSD gestartet, der diese Festplatte im Clusternetz verfügbar macht. OSDs werden in Ceph aufsteigend nummeriert, und der oben genannte CRUSH-Algorithmus berechnet für jeden Objektnamen den zugehörigen OSD.

Monitor Nodes

»Monitor Nodes« sind Server in einem Ceph-Cluster, die den Status des Clusters überwachen. Ein Client meldet sich bei einem Monitor an, um den Status des Clusters zu erfahren, und über den Status des Clusters wird anhand der CRUSH-Map ja eindeutig die Position von Objekten bestimmt. Fällt ein OSD aus, so bemerkt das der Monitor, und die Clients bekommen somit sehr schnell die Information, dass ein OSD fehlt. CRUSH berechnet in diesem Fall, wo ein mögliches Replikat eines Objektes liegen kann. Monitor Nodes sind also der kritische Schwachpunkt in Ceph.

Ceph kann zwar auch mit nur einem Monitor Daemon problemlos funktionieren, man sollte in Ceph aber mindestens drei Monitor Nodes betreiben. Diese verbinden sich untereinander und stellen ein sogenanntes Quorum her. Ein Quorum bedeutet, dass sich die Monitor Nodes eine gemeinsame Meinung über den Status des Clusters bilden, wobei eine Mehrheit sich einig sein muss, damit dieser Status festgelegt werden kann. Und genau in diesem Argument steckt eine Genialität und eine Fatalität im Konzept von Ceph.

Genial ist, dass dadurch Split-Brains automatisch vermieden werden. Fällt ein Ceph-Cluster mit drei Monitor Daemons in der Mitte auseinander, so bleiben auf Seite A zwei Monitor Nodes mit X OSDs, und auf Seite B ein Monitor mit Y OSDs über. Die Seite B kann keine mehrheitliche Meinung erzeugen, da es nur einen Monitor gibt, und die OSDs stellen sofort den Betrieb ein. Die Seite A kann weiterhin arbeiten. Wird der Defekt im Netzwerk korrigiert, erkennen die OSDs auf Seite B, dass sie einen alten Stand der Daten haben, und sie replizieren die Änderungen seit dem Split Brain (und nicht, wie bei einem RAID, binär die ganze Festplatte) zurück auf sich selbst. Das hält die Replikationszeit bei einem Fehler sehr gering.

Das Fatale daran ist, dass Ceph nicht gut auf zwei Standorte aufteilbar ist. Fällt die Netzwerkverbindung zwischen den beiden Standorten aus, steht auf jeden Fall die Seite mit der kleineren Zahl der Monitor Daemons still. Explodiert einer der Standorte, ist es aber möglich, mit ein paar Eingriffen in der sogenannten »monmap« die Daten auf dem anderen Standort zugänglich zu machen.

Replikationsfaktoren und Failure Domains

Bei Ceph erstellt man »Storage Pools«. In diesen Pools definiert man gewisse Einstellungen, wie z.B. den Replikationsfaktor, der angibt, wie oft ein in diesem Pool befindliches Objekt im Ceph-Cluster abgebildet werden soll. Ein findiger Leser könnte jetzt einen Fehler im Konzept finden: Wenn man ein Objekt z.B. sicherheitshalber dreimal in Ceph speichern lässt, aber alle drei Objekte auf dem gleichen Server liegen, hat man nichts an Redundanz gewonnen, wenn der Server ausfällt.

Aus diesem Grund kann man in Ceph »CRUSH-Maps« definieren. In diesen »Landkarten« kann man seinen Ceph-Cluster in Bereiche einteilen. Beispielsweise kann man damit sicherstellen, dass Objekte auf jeden Fall in unterschiedlichen Racks gespeichert werden, oder auf unterschiedlichen Stromkreisen. Das ist möglich, indem man in der CRUSH-Map »Failure Domains« festlegt.

Die Möglichkeiten der Gestaltung einer CRUSH-Map sind sehr flexibel, wenn auch etwas komplex. Mit einer korrekt gestalteten CRUSH-Map ist es möglich, Daten auf zwei Standorte aufzuteilen. Man beachte aber, dass es bei Ceph keinen asynchronen Schreibvorgang gibt. Im Klartext: wenn ein Client ein Objekt niederschreibt, wird auf jeden Fall gewartet, bis alle OSDs (anhand des im Pool angegebenen Replikationsfaktors) das Objekt niedergeschrieben haben. Eine langsame WAN-Leitung kann in Ceph dadurch zum Flaschenhals werden.

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung