Zum Inhalt springenZur Seitennavigation springen: vorherige Seite [Zugriffstaste p]/nächste Seite [Zugriffstaste n]
Bezieht sich auf SUSE Enterprise Storage 5

1 SUSE Enterprise Storage 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 Nodes 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. Celph 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 und eine kurze Beschreibung der wichtigsten Komponenten.

Tipp
Tipp

Seit SUSE Enterprise Storage 5 ist DeepSea die einzige Methode zur Cluster-Bereitstellung. In Kapitel 4, Bereitstellen mit DeepSea/Salt finden Sie weitere Details zum Bereitstellungsprozess.

1.1 Eigenschaften von Ceph

Die Ceph Umgebung weist die folgenden Eigenschaften auf:

Skalierbarkeit

Ceph ermöglicht das Skalieren auf Tausende von Nodes und kann Speicher im Petabyte-Bereich verwalten.

Kommerzielle Hardware

Zum Ausführen eines Ceph Clusters ist keine spezielle Hardware erforderlich. Weitere Informationen finden Sie in Kapitel 2, Hardwareanforderungen und Empfehlungen

Selbstverwaltung

Der Ceph Cluster verwaltet sich selbst. Wenn Nodes 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 Node 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 Wichtige 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 RADOS-Blockgeräte (RADOS Block Device, RBD) erfolgt genauso wie auf andere Blockgeräte. Sie werden beispielsweise für Virtualisierungszwecke in Kombination mit libvirt verwendet.

CephFS

Das Ceph File System (CephFS) ist ein POSIX-fähiges Dateisystem.

librados

librados ist 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.

Schnittstellen zum Ceph-Objektspeicher
Abbildung 1.1: Schnittstellen zum Ceph-Objektspeicher

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 wenige 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 Zustand, einige vom Administrator definierte Platzierungsregeln und der Name des Objekts, das gespeichert oder abgerufen werden muss. Mit diesen Informationen können alle Nodes 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 Nodes im Cluster zu verteilen.

Die CRUSH Map umfasst alle Speicher-Nodes 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 Nodes und Daemons

In Ceph sind Nodes 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 Node auszuführen, ausgenommen MGR Daemons, die gemeinsam mit MONs auf einem Node laufen. Jeder Cluster benötigt mindestens MON, MGR und OSD Daemons:

Ceph Monitor

Ceph Monitor (oft als MON abgekürzt) Nodes pflegen Informationen zum Cluster-Zustand, eine Zuordnung aller Nodes und Datenverteilungsregeln (weitere Informationen hierzu finden Sie in Abschnitt 1.2.2, „CRUSH“).

Wenn Fehler oder Konflikte auftreten, entscheiden die Ceph Monitor Nodes im Cluster nach dem Mehrheitsprinzip, welche Informationen korrekt sind. Um eine qualifizierte Mehrheit zu bilden, empfiehlt es sich, eine ungerade Anzahl von Ceph Monitor Nodes einzurichten, jedoch mindestens drei davon.

Bei mehreren Standorten sollten die Ceph Monitor Nodes auf eine ungerade Anzahl von Standorten verteilt werden. Die Anzahl der Ceph Monitor Nodes pro Standort sollte so gewählt werden, dass die Hälfte der Ceph Monitor Nodes funktionsfähig bleiben, wenn ein Standort ausfällt.

Ceph Manager

Der Ceph Manager (MGR) sammelt die Statusinformationen aus dem gesamten Cluster. Der Ceph Manager Daemon wird neben den Monitor Daemons ausgeführt. Er bietet zusätzliche Überwachung und dient als Schnittstelle zwischen der externen Überwachung und den Verwaltungssystemen.

Der Ceph Manager muss nicht weiter konfiguriert werden. Sie müssen nur sicherstellen, dass er ausgeführt wird. Sie können ihn mit DeepSea als separate Rolle bereitstellen.

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 Nodes 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 Nodes erforderlich:

Metadata Server (MDS)

Metadata Server speichern Metadaten für das CephFS. Über einen MDS führen Sie einfache Dateisystemkommandos wie ls aus, ohne den Cluster zu überlasten.

Object Gateway

Das Ceph 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.

1.3 Speicherstruktur

1.3.1 Pool

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 Erasure Coded Pools bezeichnet.

1.3.2 Placement Group

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-Nodes oder Ceph OSDs (Host 1, Host 2, Host 3). Jeder Node hat drei Festplatten, die als OSDs (osd.0 bis osd.9) verwendet werden. In diesem Beispiel sind keine Ceph Monitor Nodes berücksichtigt.

Anmerkung
Anmerkung: Unterschied zwischen Ceph OSD und OSD

Die Begriffe Ceph OSD oder Ceph OSD Daemon beziehen sich auf einen Daemon, der auf einem Node 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.

Beispiel eines kleinen Ceph-Speichers
Abbildung 1.2: Beispiel eines kleinen Ceph-Speichers

Die Cluster-Zuordnung ändert sich, wenn ein neuer Node 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 ab SUSE Enterprise Storage 5 ein neues standardmäßiges Speicher-Backend 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:

  1. Eine kleine Partition namens BlueFS, die Dateisystem-ähnliche Funktionalitäten implementiert, die von RocksDB benötigt werden.

  2. 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.

Tipp
Tipp: Die DB-Größe planen

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 OSDs 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:

root@minion > 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 Weitere Informationen

  • Ceph hat als Community-Projekt eine eigene Online-Dokumentation. Weitere Informationen zu Themen, die in diesem Handbuch nicht behandelt werden, finden Sie unter http://docs.ceph.com/docs/master/.

  • 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

Diese Seite drucken