1 SES und Ceph #
SUSE Enterprise Storage ist ein dezentrales Speichersystem, das auf Skalierbarkeit, Zuverlässigkeit und Leistung ausgelegt ist und auf der Ceph-Technologie basiert. Ein Ceph-Cluster kann auf Standardservern in einem gemeinsamen Netzwerk wie Ethernet ausgeführt werden. Der Cluster lässt sich gut für Tausende von Servern (im Folgenden als Knoten bezeichnet) und im Petabyte-Bereich skalieren. Im Gegensatz zu herkömmlichen Systemen, die Daten über Zuordnungstabellen speichern und abrufen, verwendet Ceph einen deterministischen Algorithmus zum Zuordnen von Speicher für Daten und hat keine zentralisierte Informationsstruktur. Ceph geht davon aus, dass in Speicher-Clustern das Hinzufügen oder Entfernen von Hardware die Regel ist und nicht die Ausnahme. Der Ceph-Cluster automatisiert Verwaltungsaufgaben wie Datenverteilung und -neuverteilung, Datenreproduktion, Ausfallerkennung und Wiederherstellung. Ceph kann sich selbst reparieren und selbst verwalten, was den Verwaltungsaufwand und die Gemeinkosten reduziert.
In diesem Kapitel erhalten Sie einen ersten Überblick über SUSE Enterprise Storage 7.1 und eine kurze Beschreibung der wichtigsten Komponenten.
1.1 Eigenschaften von Ceph #
Die Ceph-Umgebung weist die folgenden Eigenschaften auf:
- Skalierbarkeit
Ceph ermöglicht das Skalieren auf Tausende von Knoten und kann Speicher im Petabyte-Bereich verwalten.
- Kommerzielle Hardware
Zum Ausführen eines Ceph-Clusters ist keine spezielle Hardware erforderlich. Ausführliche Informationen finden Sie unter Kapitel 2, Hardwareanforderungen und Empfehlungen
- Selbstverwaltung
Der Ceph-Cluster verwaltet sich selbst. Wenn Knoten hinzugefügt oder entfernt werden oder ausfallen, verteilt der Cluster die Daten automatisch um. Er erkennt auch überlastete Festplatten.
- Keine Single Points of Failure
Kein Knoten im Cluster speichert wichtige Informationen exklusiv. Die Anzahl der Redundanzen kann konfiguriert werden.
- Open-Source-Software
Ceph ist eine Open-Source-Softwarelösung und unabhängig von spezifischer Hardware oder Anbietern.
1.2 Wichtigste Ceph-Komponenten #
Zur vollen Nutzung aller Funktionen in Ceph ist es erforderlich, einige Basiskomponenten und Konzepte zu verstehen. In diesem Abschnitt werden einige Komponenten von Ceph eingeführt, auf die oft in anderen Kapiteln verwiesen wird.
1.2.1 RADOS #
Die Basiskomponente von Ceph wird RADOS (Reliable Autonomic Distributed Object Store, Zuverlässiger autonomer dezentraler Objektspeicher) genannt. Sie ist für die Verwaltung der im Cluster gespeicherten Daten zuständig. Daten werden in Ceph normalerweise als Objekte gespeichert. Jedes Objekt besteht aus einer Kennung und den Daten.
RADOS bietet die folgenden Methoden für den Zugriff auf gespeicherte Objekte, die viele Anwendungsfälle abdecken:
- Object Gateway
Ein Object Gateway ist ein HTTP REST Gateway für den RADOS-Objektspeicher. Es ermöglicht den Direktzugriff auf Objekte, die im Ceph-Cluster gespeichert sind.
- RADOS-Blockgerät
Der Zugriff auf ein RADOS-Blockgerät (RADOS Block Device, RBD) erfolgt genauso wie der auf andere Blockgeräte. Sie werden beispielsweise für Virtualisierungszwecke in Kombination mit
libvirtverwendet.- CephFS
Das Ceph File System (CephFS) ist ein POSIX-fähiges Dateisystem.
libradoslibradosist eine Bibliothek, die mit vielen Programmiersprachen verwendet werden kann, um eine Anwendung zu erstellen, die direkt mit dem Speicher-Cluster interagiert.
librados wird vom Object Gateway und RBD verwendet, während CephFS direkt mit RADOS (Abbildung 1.1, „Schnittstellen zum Ceph-Objektspeicher“) interagiert.
1.2.2 CRUSH #
Der CRUSH-Algorithmus ist das zentrale Element eines Ceph-Clusters. CRUSH ist das Akronym für Controlled Replication Under Scalable Hashing. CRUSH ist eine Funktion für die Speicherzuordnung und benötigt vergleichsweise wenig Parameter. Es sind also nur wenige Informationen erforderlich, um die Speicherposition eines Objekts zu berechnen. Die Parameter stellen eine aktuelle Zuordnung für den Cluster dar, einschließlich Integrität, einiger vom Administrator definierter Platzierungsregeln und des Namens des Objekts, das gespeichert oder abgerufen werden muss. Mit diesen Informationen können alle Knoten im Ceph-Cluster berechnen, wo ein Objekt und dessen Reproduktionen gespeichert sind. Dies macht das Schreiben und Lesen von Daten sehr effizient. CRUSH versucht, Daten gleichmäßig auf alle Knoten im Cluster zu verteilen.
Die CRUSH-Zuordnung umfasst alle Speicherknoten und vom Administrator definierte Platzierungsregeln zum Speichern von Objekten im Cluster. Sie definiert eine hierarchische Struktur, die normalerweise mit der physischen Struktur des Clusters korrespondiert. Beispielsweise befinden sich Festplatten mit Daten in Hosts, Hosts in Racks, Racks in Reihen und Reihen in Rechenzentren. Diese Struktur wird zur Definition von Fehlerdomänen herangezogen. Ceph stellt dann sicher, dass Reproduktionen in verschiedenen Verzweigungen einer bestimmten Fehlerdomäne gespeichert werden.
Wenn die Fehlerdomäne auf „Rack“ festgelegt ist, werden Reproduktionen von Objekten auf verschiedene Racks verteilt. Dadurch werden Ausfälle entschärft, die durch einen fehlerhaften Schalter in einem Rack verursacht wurden. Wenn eine Stromversorgungseinheit eine Reihe von Racks bereitstellt, kann die Fehlerdomäne auf „Reihe“ festgelegt werden. Wenn die Stromversorgungseinheit ausfällt, sind die Reproduktionsdaten noch in anderen Reihen verfügbar.
1.2.3 Ceph-Knoten und -Daemons #
In Ceph sind Knoten Server, die für den Cluster arbeiten. Sie können verschiedene Typen von Daemons ausführen. Es wird empfohlen, nur einen Typ von Daemon pro Knoten auszuführen, ausgenommen Ceph Manager Daemons, die sich gemeinsam mit Ceph Monitors auf einem Knoten befinden können. Für jeden Client sind mindestens Ceph Monitor, Ceph Manager und Ceph OSD Daemons erforderlich:
- Admin-Knoten
Der Admin-Knoten ist ein Ceph-Cluster-Knoten, von dem aus Sie Befehle zur Verwaltung des Clusters ausführen. Der Admin-Knoten ist das Zentrum des Ceph-Clusters, weil er alle anderen Cluster-Knoten verwaltet, indem er deren Salt Minion Services abfragt und ihnen Anweisungen gibt.
- Ceph Monitor
Ceph-Monitor-Knoten (oft zu MON abgekürzt) pflegen Informationen zur Cluster-Integrität, eine Zuordnung aller Knoten und Datenverteilungsregeln (weitere Informationen hierzu finden Sie in Abschnitt 1.2.2, „CRUSH“).
Wenn Fehler oder Konflikte auftreten, entscheiden die Ceph-Monitor-Knoten im Cluster nach dem Mehrheitsprinzip, welche Informationen korrekt sind. Um eine qualifizierte Mehrheit zu bilden, empfiehlt es sich, eine ungerade Anzahl von Ceph-Monitor-Knoten einzurichten, jedoch mindestens drei davon.
Bei mehreren Standorten sollten die Ceph-Monitor-Knoten auf eine ungerade Anzahl von Standorten verteilt werden. Die Anzahl der Ceph-Monitor-Knoten pro Standort sollte so gewählt werden, dass die Hälfte der Ceph-Monitor-Knoten funktionsfähig bleiben, wenn ein Standort ausfällt.
- Ceph Manager
Der Ceph Manager sammelt die Statusinformationen aus dem gesamten Cluster. Der Ceph-Manager-Daemon wird neben den Ceph-Monitor-Daemons ausgeführt. Er bietet zusätzliche Überwachung und dient als Schnittstelle zwischen der externen Überwachung und den Verwaltungssystemen. Er umfasst auch andere Services. Beispielsweise wird die Weboberfläche des Ceph Dashboards auf demselben Knoten wie der Ceph Manager ausgeführt.
Der Ceph Manager muss nicht weiter konfiguriert werden. Sie müssen nur sicherstellen, dass er ausgeführt wird.
- Ceph OSD
Ein Ceph OSD ist ein Daemon, der Objektspeichergeräte steuert. Dabei handelt es sich um physische oder logische Speichereinheiten (Festplatten oder Partitionen). Objektspeichergeräte können physische Datenträger/Partitionen oder logische Volumes sein. Der Daemon kümmert sich außerdem um die Datenreproduktion und den Ausgleich, falls Knoten hinzugefügt oder entfernt wurden.
Ceph OSD Daemons kommunizieren mit Monitor Daemons und informieren diese über den Zustand der anderen OSD Daemons.
Für CephFS, Object Gateway, NFS Ganesha oder iSCSI Gateway sind zusätzliche Knoten erforderlich:
- Metadata Server (MDS)
CephFS-Metadaten werden in einem eigenen RADOS-Pool gespeichert (weitere Informationen finden Sie unter Abschnitt 1.3.1, „Pools“). Die Metadatenserver fungieren als intelligente Caching-Schicht für die Metadaten und serialisieren den Zugriff bei Bedarf. Dies ermöglicht den gleichzeitigen Zugriff von vielen Clients ohne explizite Synchronisierung.
- Object Gateway
Das Object Gateway ist ein HTTP-REST-Gateway für den RADOS-Objektspeicher. Es ist mit OpenStack Swift und Amazon S3 kompatibel und verfügt über eine eigene Benutzerverwaltung.
- NFS Ganesha
NFS Ganesha bietet NFS-Zugriff auf das Object Gateway oder auf das CephFS. Es wird im Benutzerbereich statt im Kernel-Bereich ausgeführt und interagiert direkt mit dem Object Gateway oder dem CephFS.
- iSCSI Gateway
iSCSI ist ein Speichernetzwerkprotokoll, über das Clients SCSI-Kommandos an SCSI-Speichergeräte (Targets) auf Remote Servern senden können.
- Samba Gateway
Das Samba Gateway bietet Samba-Zugriff auf die Daten, die auf CephFS gespeichert sind.
1.3 Ceph-Speicherstruktur #
1.3.1 Pools #
In einem Ceph-Cluster gespeicherte Objekte werden in Pools abgelegt. Pools stellen logische Partitionen des Clusters zur Außenwelt dar. Für jeden Pool kann ein Regelsatz definiert werden, beispielsweise wie viele Reproduktionen eines jeden Objekts vorhanden sein müssen. Die Standardkonfiguration von Pools wird als reproduzierter Pool bezeichnet.
Pools enthalten normalerweise Objekte, können jedoch auch so konfiguriert werden, dass sie wie ein RAID 5 funktionieren. In dieser Konfiguration werden Objekte in Datenblöcken zusammen mit zusätzlichen Codierungs-Datenblöcken gespeichert. Die Codierungs-Datenblöcke enthalten die redundanten Informationen. Die Anzahl der Daten und Codierungs-Datenblöcke werden vom Administrator definiert. In dieser Konfiguration werden Pools als Pools mit Löschcodierung oder EC-Pools (Erasure Coded Pools, EC) bezeichnet.
1.3.2 Platzierungsgruppen #
Placement Groups (PGs) dienen zur Verteilung von Daten in einem Pool. Beim Erstellen eines Pools wird eine bestimmte Anzahl von Placement Groups festgelegt. Die Placement Groups werden intern zur Gruppierung von Objekten verwendet. Sie sind ein wichtiger Faktor für die Leistung eines Ceph-Clusters. Die PG für ein Objekt wird durch den Namen des Objekts bestimmt.
1.3.3 Beispiel #
In diesem Abschnitt finden Sie ein vereinfachtes Beispiel dafür, wie Ceph Daten verwaltet (Abbildung 1.2, „Beispiel eines kleinen Ceph-Speichers“). Dieses Beispiel stellt keine empfohlene Konfiguration für einen Ceph-Cluster dar. Die Hardwareeinrichtung umfasst drei Speicher-Knoten oder Ceph OSDs (Host 1, Host 2, Host 3). Jeder Knoten hat drei Festplatten, die als OSDs (osd.1 bis osd.9) verwendet werden. In diesem Beispiel sind keine Ceph-Monitor-Knoten berücksichtigt.
Die Begriffe Ceph OSD oder Ceph OSD Daemon beziehen sich auf einen Daemon, der auf einem Knoten ausgeführt wird. Der Begriff OSD dagegen bezieht sich auf einen logischen Datenträger, mit dem der Daemon interagiert.
Der Cluster umfasst zwei Pools, Pool A und Pool B. Während Pool A Objekte nur zweimal reproduziert, ist Ausfallsicherheit für Pool B wichtiger und es gibt daher drei Reproduktionen für jedes Objekt.
Wenn eine Anwendung ein Objekt in einen Pool stellt, beispielsweise über die REST API, dann wird eine Placement Group (PG1 bis PG4) auf Basis des Pools und des Objektnamens ausgewählt. Der CRUSH-Algorithmus berechnet dann, auf welchen OSDs das Objekt gespeichert ist, basierend auf der Placement Group, die das Objekt enthält.
In diesem Beispiel ist die Fehlerdomäne auf Host festgelegt. Dadurch wird sichergestellt, dass die Reproduktionen von Objekten auf verschiedenen Hosts gespeichert sind. Je nach der für einen Pool festgelegten Reproduktionsstufe wird das Objekt auf zwei oder drei OSDs gespeichert, die von der Placement Group verwendet werden.
Eine Anwendung, die ein Objekt schreibt, interagiert nur mit einem Ceph OSD, nämlich dem primären Ceph OSD. Der primäre Ceph OSD führt die Reproduktion aus und bestätigt die Durchführung des Schreibvorgangs, nachdem alle anderen OSDs das Objekt gespeichert haben.
Wenn osd.5 ausfällt, sind alle Objekte in PG1 immer noch auf osd.1 verfügbar. Sobald der Cluster feststellt, dass ein OSD ausgefallen ist, übernimmt ein anderer OSD. In diesem Beispiel wird osd.4 als Ersatz für osd.5 verwendet. Die auf osd.1 gespeicherten Objekte werden dann auf osd.4 reproduziert, um die Reproduktionsstufe wiederherzustellen.
Die Cluster-Zuordnung ändert sich, wenn ein neuer Knoten mit neuen OSDs zum Cluster hinzugefügt wird. Die CRUSH-Funktion gibt dann verschiedene Standorte für Objekte zurück. Objekte, die neue Standorte erhalten, werden verschoben. Durch diesen Vorgang bleiben alle OSDs gleichmäßig ausgelastet.
1.4 BlueStore #
BlueStore ist seit SES 5 ein neues standardmäßiges Speicher-Back-End für Ceph. Seine Leistung ist besser als die von FileStore. Es umfasst vollständige Prüfsummenerstellung für Daten und weist eine integrierte Komprimierung auf.
BlueStore verwaltet ein, zwei oder drei Speichergeräte. Im einfachsten Fall lastet BlueStore ein einzelnes primäres Speichergerät aus. Das Speichergerät ist normalerweise in zwei Abschnitte partitioniert:
Eine kleine Partition namens BlueFS, die Dateisystem-ähnliche Funktionalitäten implementiert, die von RocksDB benötigt werden.
Eine große Partition belegt normalerweise das restliche Gerät. Sie wird direkt von BlueStore verwaltet und enthält alle Ist-Daten. Dieses primäre Gerät ist normalerweise durch eine Blocksymbolverknüpfung im Datenverzeichnis gekennzeichnet.
BlueStore kann auch auf zwei weiteren Geräten bereitgestellt werden:
Ein WAL-Gerät, das für das interne Journal oder Write Ahead-Protokoll von BlueStore verwendet wird. Es ist durch den symbolischen Link block.wal im Datenverzeichnis gekennzeichnet. Ein separates WAL-Gerät ist nur sinnvoll, wenn das Gerät schneller als das primäre Gerät oder das DB-Gerät ist. Beispiel:
Das WAL-Gerät ist ein NVMe, das DB-Gerät ist ein SSD und das Datengerät ist entweder ein SSD oder HDD.
Das WAL-Gerät und das DB-Gerät sind separate SSDs. Das Datengerät ist ein SSD oder HDD.
Ein DB-Gerät kann zum Speichern der internen Metadaten von BlueStore verwendet werden. BlueStore (eigentlich die eingebettete RocksDB) legt zur Leistungsoptimierung so viele Metadaten wie möglich auf dem DB-Gerät ab. Auch hier ist die Bereitstellung eines gemeinsam genutzten DB-Geräts nur sinnvoll, wenn es schneller ist als das primäre Gerät.
Planen Sie sorgfältig eine ausreichende Größe für das DB-Gerät. Wenn das DB-Gerät voll ist, laufen die Metadaten an das primäre Gerät über, was die Leistung des OSD extrem beeinträchtigt.
Mit dem Kommando ceph daemon osd.ID perf dump können Sie prüfen, ob eine WAL/DB-Partition voll wird und überläuft. Der Wert slow_used_bytes gibt die Anzahl der Daten an, die überlaufen:
cephuser@adm > ceph daemon osd.ID perf dump | jq '.bluefs'
"db_total_bytes": 1073741824,
"db_used_bytes": 33554432,
"wal_total_bytes": 0,
"wal_used_bytes": 0,
"slow_total_bytes": 554432,
"slow_used_bytes": 554432,1.5 Zusätzliche Informationen #
Ceph hat als Community-Projekt eine eigene Online-Dokumentation. Weitere Informationen zu Themen, die in diesem Handbuch nicht behandelt werden, finden Sie unter https://docs.ceph.com/en/pacific/.
In der ursprünglichen Veröffentlichung mit dem Titel CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data von S.A. Weil, S.A. Brandt, E.L. Miller, C. Maltzahn finden Sie nützliche Informationen zu den inneren Abläufen in Ceph. Die Lektüre empfiehlt sich vor allem für die Bereitstellung von Clustern mit großem Volumen. Sie finden die Veröffentlichung unter http://www.ssrc.ucsc.edu/papers/weil-sc06.pdf
SUSE Enterprise Storage kann zusammen mit OpenStack-Distributionen anderer Hersteller verwendet werden. Die Ceph-Clients müssen sich auf einer Ebene befinden, die mit SUSE Enterprise Storage kompatibel sind.
AnmerkungSUSE unterstützt die Serverkomponente der Ceph-Bereitstellung, der Client wird vom Anbieter der OpenStack-Distribution unterstützt.