Ceph-Storage in der Praxis - Teil 1

Autor: Armin Krauß - K&K Software AG

Zentrale, Shared Storage Systeme haben im Serverumfeld einen festen Platz. Mit wachsenden Anforderungen an Kapazität, Skalierbarkeit und Ausfallsicherheit spielen verteilte Storage-Lösungen dabei eine immer größere Rolle. Nicht zuletzt durch die Aussicht auf Kostenersparnis sowie einen hohen Grad an Flexibilität wächst die Anwenderzahl des Ceph-Dateisystem stetig und rasant an, weshalb wir nachfolgend einen Anwendungsfall aus der Praxis betrachten wollen.

bilder/20180403_ceph-grafana-1_0.jpg

1. Grundkonzept

 

1.1 Merkmale

Bei Ceph handelt es sich um ein verteiltes Dateisystem für Hochverfügbarkeit, mit dem sich große und sehr große Storages realisieren lassen.

Zentrale Merkmale von Ceph sind:

  • Robustes Design gegen Ausfallsicherheit (kein Single Point of Failure) durch die Verteilung auf mehrere Nodes
  • Hohe Skalierbarkeit sowohl was die Storage-Kapazität als auch die Erweiterbarkeit der beteiligten Nodes betrifft
  • Hohe Flexibilität
  • Software basierende Lösung (keine starren Raid-Systeme erwünscht)
  • Selbst-verwaltend und mit eigenständigen Mechanismen zur Fehlerbehebung
  • Open Source

Als verteiltes Dateisystem erstreckt sich ein Ceph-Storage über mehrere (bis viele) Einzelrechner – sogenannte Nodes –, die im Verbund zusammenarbeiten. Dieser Verbund wird auch als Ceph-Cluster bezeichnet.

 

1.2 Aufbau und Architektur

In einem Ceph-Cluster gibt es unterschiedliche Rollen (Aufgabenbereiche), die von den einzelnen Nodes erledigt werden.

 

Monitore und Manager

Monitore verwalten sie sogenannte Cluster Map und erfüllen eine organisatorische Aufgabe im fortlaufenden Betrieb. Seit Version 12 des Ceph-Dateisystems werden daneben noch Manager benötigt als Schnittstelle für externe Zugriffe und für zusätzliche Monitoring-Aufgaben.

Zum Betrieb eines lauffähigen Clusters wird immer mindestens 1 funktionierender Monitor sowie 1 Manager benötigt. Um einen Single Point of Failure zu vermeiden, sollte man in der Praxis mehrere Monitore und Manager vorhalten. Dabei sollte man auf eine ungerade Anzahl setzen, damit der Cluster im Fall eines internen Konflikts entscheidungsfähig ist.

Bei einem Minimal-Cluster bestehend aus 3 Nodes macht es daher Sinn, auf allen 3 Nodes Monitore und Manager bereitzustellen.

 

Object Storage Node (OSD)

Object Storage Nodes stellen die eigentliche Speicherkomponente im Ceph-Storage dar. Bei einem OSD handelt es sich typischerweise um eine (einzelne) Festplatte in einem Ceph Node. Der Ceph-Storage setzt sich also insgesamt aus vielen OSDs zusammen bzw. die Daten in einem Ceph-Dateisystem verteilen sich auf die vielen verfügbaren OSDs.

Jedes OSD verfügt über seinen eigenen Dienst (OSD Daemon), der die Anfragen und Zugriffe auf die dahinterliegende Speichereinheit verwaltet.

Ursprünglich verwendete Ceph zur Datenspeicherung auf den OSDs bewährte Linux Dateisysteme (XFS, Ext4, btrfs). Neben dem endgültigen Speicherplatz auf einem Datenträger wurde außerdem ein sogenanntes Journal angelegt, das als Zwischenspeicher für alle eingehenden Schreibzugriffe zum Einsatz kam.

Seit Version 12 des Ceph-Dateisystems werden OSDs mittlerweile standardmäßig im sogenannten BlueStore-Format erzeugt. Hierbei handelt es sich um ein natives Dateisystem von Ceph, das mit einigen Nachteilen des Vorgängerkonzepts aufräumt, u.a. das zuvor separate Journal in den Datenspeicher integriert und dadurch insgesamt für einen spürbaren Performancegewinn sorgt.

 

Die nachstehende Abbildung zeigt schematisch den Aufbau eines Ceph-Storages:

RADOS steht für Reliable Autonomic Distributed Object Store und stellt innerhalb von Ceph die Schicht zur Datenspeicherung dar.

 

1.3 Schnittstellen und Zugriffswege

Ceph-Storages können auf unterschiedliche Art und Weise genutzt werden. Hierfür stellt Ceph mehrere Schnittstellen zur Verfügung, die zum Teil über spezielle Anpassungen für den jeweiligen Einsatzzweck verfügen. Durch die zunehmende Verbreitung und Beliebtheit von Ceph als zuverlässigen und kostengünstigen Storage entstehen fortlaufend neue Szenarien und werden seitens Ceph neue Möglichkeiten und Verbesserungen vorangetrieben.

 

Die grundsätzlichen Zugriffskonzepte zeigt die nachstehende Abbildung:

RADOSGW ist ein Web Service Gateway mit RESTful API, der eine Anbindung zu Amazon S3 und OpenStack ermöglicht.

RBD (RADOS Block Device) stellt Speicherkapazität auf dem Ceph-Storage in Form von Block Devices zur Verfügung. Damit lassen sich beispielsweise virtuelle Festplattenimages im Ceph-Storage ablegen, die zum Betrieb von VMs genutzt werden.

CephFS bietet ein POSIX konformes Dateisystem auf dem Ceph-Cluster.

LIBRADOS stellt eine native Schnittstelle zum direkten Zugriff auf RADOS dar, über die Applikationen Zugang zum verteilten Storage bekommen.

 

1.4 iSCSI-Schnittstelle

Die zuvor beschriebenen Schnittstellen stellen die grundsätzlichen Zugangswege zum Ceph-Storage dar. Weiterer Zugriffsmöglichkeiten lassen sich auf Basis der o.g. Schnittstellen und unter Zuhilfenahme zusätzlicher Applikationen und Dienste realisieren.

Für die in klassischen Storagekonzepten beliebte iSCSI-Schnittstelle gibt es unter Linux mehrere Umsetzungen. Eine gute Ceph-Integration bietet das Linux SCSItargetframework (TGT).

 

Den schematischen Aufbau einer Ceph/iSCSI-Anbindung zeigt die nachstehende Abbildung:

Durch Bereitstellen des TGT iSCSI-Dienstes auf mehreren Nodes erhält man eine hochverfügbare iSCSI-Anbindung. Clientseitig erfordert dies eine Konfiguration mit Multipath.

 

Die Namensnennung von Firmen oder Markennamen dient lediglich der redaktionellen Verwendung, zur Abgrenzung und zur Kenntlichmachung der Kompatibilität im Rahmen des jeweiligen Geschäftsumfanges. Die Zeichen, Begriffe und Namen sind gegebenenfalls geschützte Marken- und Warenzeichen der jeweiligen Rechteinhaber. Die angebotene Ware ist zu vielen Produkten namhafter Marken kompatibel, es handelt sich aber keinesfalls um Produkte der betreffenden Firmen und Marken!
 
Autor: Armin Krauß - K&K Software AG - eine Serie in 3 Teilen
 
Lesen Sie hier: Teil 2 und Teil 3

Beitrag vom 04.04.2018

Kommentar abgeben: