wikiCeph
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 als verteiltes Dateisystem
Ceph weist folgende Eigenschaften auf:
- Skalierbar, vor allem in die Breite
- Mit Commodity Hardware einsetzbar
- Flexibel und selbst-verwaltend
- Object Store - RADOS (Reliable Autonomic Distributed Object Store)
- Kein Single Point of Failure - Verteilung auf mehrere Nodes
- Software basierend und Open Source
- Unified Storage
Ceph Cluster
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.
Monitors
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]
Object Storage Node
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:
- Einem Storage Device (HDD/SSD, RAID Volume)
- Einem Linux Datei-System (XFS, Ext4, btrfs)
- Einem Ceph OSD Daemon
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:
- Replikation, Kohärenz, Re-Balancing und Recovery
Secondary OSDs:
- sind unter der Kontrolle des Primary, können aber auch selbst primary werden.
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.
OSD Journal
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:
- Fällt die SSD aus und damit auch die Journale die darauf liegen, sind die zugehörigen OSDs auch nicht mehr verfügbar. Befinden sich z.B. alle Journale einer Ceph Node auf nur 1 SSD und diese fällt aus, sind alle OSDs der Node nicht verfügbar!
- SSDs mit Journalen mehrerer OSDs unterliegen hoher Schreiblast. Achten Sie beim Kauf die Haltbarkeit (Endurance) der SSD. Am besten überwachen Sie den aktuellen Zustand der SSD über SMART und Icinga mit dem SMART Attributes Monitoring Plugin.
- Liegen mehrere Journale auf 1 SSD, ist neben der Geschwindigkeit von zufälligen Zugriffen (Random I/O) auch der Durchsatz (Sequential I/O) entscheidend. Achten Sie beim Kauf einer SSD von einer bestimmten SSD-Serie darauf, ein Modell mit zumindest mittlerer bzw. besser hoher Kapazität zu wählen. SSD Modelle mit höherer Kapazität verfügen typischerweise über mehr Flash-Chips, die parallel vom SSD Controller verwendet werden können. Daher haben SSDs mit höherer Kapazität eine höhere Performance (z.B. beim Schreiben auf Intel DC S3610 Series SSDs 520MB/s beim 800GB Modell im Vergleich zu 110MB/s beim 100GB Modell).
Zugriffswege bzw. Ceph Interfaces
Auf einen Ceph Storage kann auf unterschiedliche Arten zugegriffen werden.
radosgw
Ein RADOS oder Ceph Gateway ist ein REST basierendes Web Service Gateway. Die RESTful API ist Amazon S3 und OpenStack Swift kompatibel.
RADOS Block Device
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
CephFS ist ein POSIX konformes, über den Ceph Cluster verteiltes Dateisystem.[7] CephFS erfordert zumindest einen Ceph Metadata Server (MDS) im Cluster.
librados
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.
Verteilung der Daten
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 Map
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:
- Replica Count
- Affinität- und Verteilungs-Regeln
- Gewichtungen
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 und Pools
Placement Groups (PGs) und Pools sind logische Konstrukte, die zur Verwaltung von Objekten eingesetzt werden. Sie dienen vor allem zur Abstraktion und Gruppierung.
Placement Groups
PGs sind Logische Gruppierungen von Objekten, die dann OSDs zugeordnet werden. Die Zuordnung von Objekt <-> PG wird bestimmt durch:
- der Hash des Objekt-Namens
- die Anzahl der Replikas
- die Gesamtanzahl an PGs
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
- wird von der PG unabhängig, pseudo-zufällig zu einem Set von OSDs gemapped
- von PGs, die auf die selben OSDs mapped, besitzt Replikas in anderen OSDs
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.
Pools
Ceph Pools sind logische Partition zum Speichern der Objekte. Pools bestehen aus einer definierten Anzahl von PGS. Pools werden außerdem zur Konfiguration von
- der Anzahl an Replicas
- der Anzahl an PGs
- der verwendeten CRUSH Regel
genutzt.
RADOS
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.
Weitere Informationen
- Ceph Community presentation channel (de.slideshare.net)
Einzelnachweise
- ↑ 1,0 1,1 1,2 1,3 Ceph: Reliable, Scalable, and high-performance distributed storage (ceph.io)
- ↑ Ceph - History (wikipedia.org)
- ↑ Ceph Essentials (storageconference.us)
- ↑ Monitoring OSDs and PGs (ceph.com)
- ↑ Journal Config Reference (ceph.com)
- ↑ Red Hat Ceph Storage 1.2.3 Hardware Guide (access.redhat.com)
- ↑ CephFS (ceph.com)
- ↑ librados Einführung (ceph.com)
 |
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.
|
