iX 8/2017
S. 40
Titel
Massenspeicher
Aufmacherbild

Ceph-Pakete von Red Hat und SUSE im Vergleich

Storage Wars

Ohne Software-defined Storage lassen sich moderne Cloud-Umgebungen nicht oder nur mit erheblichem Aufwand realisieren. Ceph, einen der bekanntesten Vertreter, würdigen die beiden großen Enterprise-Linux-Anbieter mit eigens geschnürten Paketen: Red Hat Ceph Storage 2 und SUSE Enterprise Storage 4.

Aus aktuellen IT-Topologien ist SDS – Software-defined Storage – nicht mehr wegzudenken. Einer der bekanntesten SDS-Vertreter ist sicherlich Ceph unter Linux [1]. Hinter dem Projekt steckt die ehemalige Truppe von Inktank, die in ihren Anfängen nicht zuletzt durch Mark Shuttleworth als Platin-Sponsor stark Ubuntu-lastig ausgelegt war (siehe Kasten „Ceph-Entwicklung“). 2014 übernahm Red Hat schließlich die Firma Inktank, wodurch Ceph und Gluster „aus einem Stall“ kommen.

Gluster, der früher von Red Hat präferierte Storage-Ansatz, findet sich nun an zweiter Stelle wieder und kommt entsprechend seinen Fähigkeiten für andere Aufgaben als Ceph zum Einsatz. Ob Gluster bei Red Hat lange überleben wird, sei dahingestellt, da sich einige Bereiche überlappen und Ceph immer mehr Funktionen bietet, die früher allein Glusters Spezialität waren. Andersherum tut sich hingegen eher wenig.

Ein erster Blick auf den Cephalopoden

Ceph vereint Hochverfügbarkeit sowie extreme Skalierbarkeit bis in den Exabyte-Bereich. Als typischer Vertreter einer neuen SDS-Generation basiert es auf dem Prinzip des Object Storage: Dateien legt es dabei nicht direkt in Daten-Chunks auf den unterliegenden Storage Devices ab, sondern „abstrahiert“ diese.

Über den SDS-Layer, in dem Ceph auch die sogenannten CRUSH-Funktionen (Controlled Replication under Scalable Hashing) implementiert, zeigt Ceph seine extreme Anpassungsfähigkeit und Skalierbarkeit: Über entsprechende Einstellungen des SDS-Layers – im Detail: der CRUSH-Map – können Ceph-SDS-Systeme im Object Store nahezu alle physischen Speicherkomponenten und -strukturen wie RZs, Räume, Racks, Rechner oder Disks 1:1 für die punktgenaue Ablage berücksichtigen. Die Architektur hat keinen Single Point of Failure (SPoF), ist hochredundant ausgelegt und fällt beim Versagen einer oder mehrerer Komponenten – je nach Redundanz-Level – nicht aus.

Die aktuelle Ceph-LTS-Version ist 10.2.x alias „Jewel“. Sie bringt alles mit, was aktuelle SDS-Architekturen ohne Hardwarebindung benötigen: Kernkomponente ist RADOS (Reliable Autonomic Distributed Object Store). Es stellt die Speicherressourcen in verschiedenen Verfahren bereit – als RADOS Block Device (RBD), als Cluster-Filesystem CephFS oder mithilfe des RADOS Gateway (RGW) als Object Store über HTTP(S). Ein flexibler CRUSH-Layer steuert Datenablage, -aufteilung und -replikation. Neben vielen anderen Funktionen stehen Tiering-Mechanismen für Hot/Cold-Storage-Architekturen in Verbindung mit Erasure Coding zur Verfügung.

SDS-Cluster verstehen sich vor allem als autonome Systeme, die – einmal sauber eingerichtet beziehungsweise skaliert – ausfallsicher arbeiten. Das heißt: Sie kompensieren Fehler automatisch, sofern genügend Speicherplatz vorhanden ist, und stellen die Verfügbarkeit der in ihnen gehosteten Daten sicher. Bei Bedarf können HA-Cluster wie Pacemaker hochverfügbare SDS-Frontends, etwa ausfallsichere iSCSI-Heads, NFS- oder CIFS-Shares, HTTP-Frontends für den RGW oder geklonte CephFS-Mounts, vorschalten.

Die Storage-Bereitstellungsverfahren RBD und RGW sind in Ceph mittlerweile sehr robust. Anders sieht es auf der ewigen Baustelle CephFS aus, auch wenn Red Hat nun endlich offiziell beteuert, dass es mittlerweile „stable“ beziehungsweise so „awesome“ wie die RBD- und RGW-Verwandtschaft sei. Untrügliche Zeichen dafür, dass hier weiterhin Vorsicht geboten ist, sind nach wie vor das standardmäßige Deaktivieren der Multi-Active-MDS-Funktion (Metadata-Server) sowie der Snapshot-Fähigkeiten. Diese sind in Jewel immer noch nur experimentell. Hinzu kommen potenzielle Hakeleien bei den ACLs, ein etwas träger MDS-Failover im Fehler-Fall, schwankende CephFS-Schreib-Performance und einiges mehr.

Ohne Verwaltungs-Tools funktioniert es nicht

Dass die aktuellen SDS-Managementansätze von SUSE und Red Hat abseits der standardmäßig vorhandenen Ceph-Methoden, -Tools und -CLI-Befehle keine Möglichkeiten zum Verwalten von CephFS und des RGW bieten, unterstreicht dies umso mehr. Schade, waren es doch CephFS und mkcephfs, mit denen Ceph und Inktank überhaupt begonnen hatten.

Ein Ceph-Storage-Cluster stellt allein bei den Einstellmöglichkeiten eines der umfangreichsten, aber auch komplexesten SDS-Systeme dar. Die Betrachtung all dieser Aspekte ist nicht Teil dieses Artikels und würde auch dessen Rahmen sprengen. Der Autor arbeitet gerade an einem Ceph/SDS-Buch, in dem allein dieser Abschnitt derzeit über 500 Seiten umfasst.

Frühe Ceph-GUIs wie Calamari oder das Ceph-Dashboard sind nicht dazu angetan, das Leben von Storage-Administratoren wirklich zu erleichtern: Es sind eher einfach gestrickte GUI-Werkzeuge, die unwesentlich mehr machen, als den Status diverser Ceph-Komponenten HTML-tauglich zu projizieren. Eingriffsmöglichkeiten oder Kernfunktionen des Managements wie die CRUSH-Maps, Rulesets und deren Profile, Cache-Tiering sowie ceph.conf-Einstellungen und Injects glänzten bisher durch Abwesenheit.

Für Storage-Administratoren soll und muss daher ein zugekaufter distributionsspezifischer Ansatz vor allem die zum Teil sehr komplexen Vorgänge hinter den Kulissen des Ceph-Clusters vereinfachen – in diesem Fall durch grafische Frontends. Derzeit stehen zwei Kandidaten zur Auswahl: Red Hat Ceph Storage 2.2 (RHCS2) und SUSE Enterprise Storage 4 (SES4).

Gemeinsamkeiten der Probanden

Sowohl SUSEs als auch Red Hats SDS-Paket verwendet im Unterbau Cephs LTS-Version „Jewel“, insofern sind ihre Kern-Funktionen identisch. Zu ihnen gehören unter anderem die asynchrone, Cluster-übergreifende Replikation von RBDs, die dynamisch setzbaren RBD-Funktionen, die Option, RBD-Snapshots umzubenennen. Für die Verwaltung aller Ceph-Dämonen ist systemd zuständig. Weiter gehören dazu CephFS, cephfs-volume-manager für OpenStack, Cache-Tiering sowie Erasure Coding. Ausführliche Details liefern die Release Notes von Ceph (siehe „Alle Links“ am Ende des Artikels).