Ceph ist ein hoch-verfügbares, verteiltes und robustes Dateisystem. Vorgestellt wurde es 2007 von Sage A. Weil im Rahmen seiner Dissertation an der Universität von Kalifornien, Santa Cruz.[1] Sage A. Weil war außerdem der Gründer von Inktank Storage, ein Unternehmen das sich seit 2011 hauptverantwortlich um die Entwicklung von Ceph angenommen hat und 2014 von Red Hat übernommen wurde.[2]
Ceph weist folgende Eigenschaften auf:
Ceph ist ein verteiltes Dateisystem über mehrere Nodes, daher spricht man auch von einem Ceph Cluster. In einem Ceph Cluster gibt es immer mehrere Rollen, die von einzelnen Nodes übernommen werden.
Ceph Monitors oder Monitoring Nodes bauen eine sogenannte Cluster Map auf. Sie sind dafür zuständig, einen einheitlichen Cluster Status zu generieren und zu verwalten. Ein Ceph Monitor ist ein Daemon bzw. ein System-Dienst, welcher sich um Status- und Konfigurations-Informationen kümmert.
In einem Ceph Cluster laufen typischerweise eine ungerade Anzahl an Monitors, bei kleineren Clustern 3 oder 5. Von dieser Anzahl muss zumindest die Hälfte am laufen sein, ansonsten verliert der Cluster seinen definierten Zustand und wird für Clients unzugänglich.[3]
Eine Object Storage Node ist die wesentliche Speicher-Komponente im Storage Cluster. Sie realisiert ein Object Storage Device (OSD) und verbindet es mit dem Cluster. Ein OSD besteht aus:
Der OSD Daemon ist ein Dienst, der die Clients mit den gespeicherten Objekten versorgt. OSDs können entweder primary oder secondary sein. Primary OSDs sind verantwortlich für:
Secondary OSDs:
Write Anfragen von Clients (Client initiated Writes) werden stets vom primary OSD angenommen.[4] Die intelligente Kommunikation von OSDs untereinander zur Beantwortung von Client Requests nennt man dabei auch Peering.
Standardmäßig legt Ceph mit jeder OSD auch ein Journal am selben Storage Device ab.[5]
Bevor Daten endgültig auf die OSDs geschrieben werden, kommen sie immer zuerst ins Journal. Zusätzlich werden die Replicas auf andere Nodes gemäß der Konfiguration verteilt. Der Client erhält sein ACK (Bestätigung, das Operation abgeschlossen wurde) für die Daten-Operation erst dann, wenn die Replicas seiner Daten angelegt wurden. Es genügt jedoch, wenn die Daten in den Journalen der anderen Nodes liegen. Nach und nach schreibt Ceph die Daten dann von den Journalen auf die OSDs. Aus dieser Vorgehensweise lässt sich erahnen, wie wichtig die Performance der Journale für die Abarbeitung von Client Requests im Ceph Cluster ist. Red Hat schreibt zu diesem Thema in einem Ceph Hardware Guide:[6]
Since Ceph has to write all data to the journal before it can send an ACK (for XFS and EXT4 at least), having the journal and OSD performance in balance is really important!
Zur Performance-Steigerung werden die Journale häufig auf SSDs ausgelagert. Oft werden bei diesem Setup auch mehrere Journale von unterschiedlichen OSDs auf eine SSD gegeben (empfohlen werden nicht mehr als 4-5 Journale per SSD). Folgende Punkte müssen Sie dabei beachten:
Auf einen Ceph Storage kann auf unterschiedliche Arten zugegriffen werden.
Ein RADOS oder Ceph Gateway ist ein REST basierendes Web Service Gateway. Die RESTful API ist Amazon S3 und OpenStack Swift kompatibel.
Das RADOS Block Device (RBD) oder auch Ceph Block Device ist ein von Ceph zur Verfügung gestelltes, verteiltes Block Device. Es kommuniziert mit Ceph entweder über ein Linux Kernel Modul oder die librbd Bibliothek. Die Clients arbeiten mit einem virtuellen Block Device, das aus dem Ceph Object Store gemapped wird.
CephFS ist ein POSIX konformes, über den Ceph Cluster verteiltes Dateisystem.[7] CephFS erfordert zumindest einen Ceph Metadata Server (MDS) im Cluster.
Die Bibliothek/API librados ist eine natives Interfaces für den direkten Zugriff auf RADOS. Mit librados werden Applikationen entwickelt, die direkt auf RADOS zugreifen möchten. Die oben genannten Interfaces (radosgw, rbd, CephFS) setzen selbst auf die C Variante von librados auf.[8] Daneben gibt es ebenfalls Bindings für C++, Java, Python, Ruby und PHP.
Cephs Verteilung der Daten über den Cluster hinweg ist ein Alleinstellungsmerkmal, dass von Sage A. Weil entwickelt wurde. Kern des Algorithmus ist eine CRUSH Map, ein Mechanismus zum Verteilen der Daten.
CRUSH steht als Abkürzung für Controlled Replication under scalable Hashing. Im englischen wird CRUSH als Data Placement Algorithm bezeichnet, also ein Algorithmus zur Verteilung der Daten auf die OSDs. Im Gegensatz zu Lookup-Varianten von anderen Dateisystemen setzt CRUSH auf eine pseudo-zufällige, deterministische Berechnung bei der Platzierung von Objekten.
Auf Seite 84 schreibt Sage A. Weil zu CRUSH:[1]
I have developed CRUSH (Controlled Replication Under Scalable Hashing), a pseudo-random data distribution algorithm that efficiently and robustly distributes object replicas across a heterogeneous, structured storage cluster. CRUSH is implemented as a deterministic function that maps an input value - typically an object or object group identifier—to a list of devices on which to store object replicas.
CRUSH braucht zum effizienten Verteilen eine kompakte, interne Beschreibung der verfügbaren OSDs und die Replica Placement Policy (wie viele Replikas im Cluster vorgehalten werden sollen). Der Vorteil dabei ist, dass CRUSH deterministisch ist und jede Node im Cluster und jeder Client den aktuellen Ort von Objekten berechnen kann. Außerdem ist der Metadaten-Aufwand für CRUSH niedrig, da sich diese nur ändern wenn OSDs hinzu- oder wegkommen.
Eine weitere Eigenschaft von CRUSH ist, dass es sich über Regeln konfigurieren lässt. Zum Beispiel können:
eingestellt werden.
Die Berechnungen von CRUSH beschreibt Sage A. Weil weiters als:
Given a single integer input value x, CRUSH will output an ordered list R of n distinct storage targets. CRUSH utilizes a strong multi-input integer hash function whose inputs include x, making the mapping completely deterministic and independently calculable using only the cluster map, placement rules, and x.
Placement Groups (PGs) und Pools sind logische Konstrukte, die zur Verwaltung von Objekten eingesetzt werden. Sie dienen vor allem zur Abstraktion und Gruppierung.
PGs sind Logische Gruppierungen von Objekten, die dann OSDs zugeordnet werden. Die Zuordnung von Objekt <-> PG wird bestimmt durch:
Die daraus resultierende PG fließt dann in den CRUSH Algorithmus mit ein.
Im nächsten Schritt werden die PGs den OSDs zugeordnet. Die Verteilung
PGs bringen den Vorteil, dass Operationen und Algorithmen nicht auf Objekt-Ebene arbeiten müssen. Bei Aber-Millionen Objekten wäre das auch sehr ineffizient und unrealistisch.
Ceph Pools sind logische Partition zum Speichern der Objekte. Pools bestehen aus einer definierten Anzahl von PGS. Pools werden außerdem zur Konfiguration von
genutzt.
RADOS (Reliable Autonomic Distributed Object Store) ist der eigentliche Object Store von Ceph, in dem die Objekte abgelegt werden.
Sage A. Weil beschreibt RADOS zu Beginn seiner Dissertation folgendermaßen:[1]
[...] RADOS, Ceph’s Reliable Autonomic Distributed Object Store. RADOS provides an extremely scalable storage cluster management platform that exposes a simple object storage abstraction. System components utilizing the object store can expect scalable, reliable, and high-performance access to objects without concerning themselves with the details of replication, data redistribution (when cluster membership expands or contracts), failure detection, or failure recovery.
 |
Autor: Georg Schönberger Georg Schönberger, Abteilung DevOps bei der XORTEX eBusiness GmbH, absolvierte an der FH OÖ am Campus Hagenberg sein Studium zum Bachelor Computer- und Mediensicherheit, Studium Master Sichere Informationssysteme. Seit 2015 ist Georg bei XORTEX beschäftigt und arbeitet sehr lösungsorientiert und hat keine Angst vor schwierigen Aufgaben. Zu seinen Hobbys zählt neben Linux auch Tennis, Klettern und Reisen.
|
wiki