Dass die Entwicklung der Datenbestände in Unternehmen nur eine Richtung kennt (Spoiler Alert: nach oben), ist mittlerweile eine Binsenweisheit. Für Unternehmen hat dies aber spürbare Auswirkungen auf ihr Tagesgeschäft, denn zum Einen müssen Daten den Mitarbeitern im Idealfall jederzeit und überall zur Verfügung stehen – aktuell auch im Home Office –, auf der anderen Seite liefern Datenanalysen wichtige Informationen für das Management. Klassischer Highend-Storage ist in der Lage, die meisten Herausforderungen locker abzudecken. Aber das hat seinen Preis und im »real life« spielen neben der Performance die Kosten eine immer größere Rolle, weshalb viele Unternehmen eine Alternative oder Ergänzung zu kostspieligen Appliances suchen.

Hier kommt Ceph ins Spiel: Bereits 2007 wurde der Kopffüßler (Ceph leitet sich von Cephalopod ab, einer Gattung, zu der auch der Oktopus zählt) von Sage Weil im Rahmen seiner Doktorarbeit an der University of California Santa Cruz als verteiltes, hoch verfügbares und leistungsfähiges Storage-System entwickelt. Ceph ist Open Source und wird von zahlreichen Unternehmen der Branche unterstützt. Mit Ceph lässt sich auf Linux-Basis mit Standard-Hardware ein Storage-Cluster aufbauen, der sich praktisch beliebig erweitern und auf nahezu jeden Anwendungsfall anpassen lässt, egal ob File, Block oder Object Storage. Als »Software defined Storage«-Lösung ist Ceph extrem skalierbar, hoch performant (in Abhängigkeit von der eingesetzten Hardware) und zudem ausfallsicher.

Enterprise-Storage mit Standard-Hardware

Für Administratoren mit Linux-Kenntnissen ist die Einrichtung eines Ceph-Clusters in einer Testumgebung keine große Herausforderung. Zahlreiche Tutorials im Internet geben Schritt-für-Schritt-Anleitungen. In Produktionsumgebungen sind die Anforderungen und Ansprüche an ein Storage-Cluster aber naturgemäß ganz andere, Deployment- und Management müssen 1a funktionieren und sollten möglichst wenig Zeit und Manpower in Anspruch nehmen. Hier schlägt die Stunde von Unternehmen wie croit.

Die Deployment- und Management-Lösung von croit erleichtert die Einrichtung und Verwaltung von Ceph-Clustern ungemein. Der Start ist einfach: Als Installationsbasis empfiehlt sich ein dedizierter Server oder auch eine virtuelle Maschine (VM), auf der beispielsweise ein Debian Linux läuft. Im Prinzip läuft die Software aber unter jedem beliebigen Betriebssystem, das eine aktuelle Version von Docker unterstützt. Dieser Host wird als »Management Node« bezeichnet und sollte als Hardware mindestens 8 GB RAM, 100 GB SSD-Kapazität für Statistiken und Logfiles und vier CPU-Cores mitbringen. Wichtig ist auch ein dedizierter Netzwerkzugriff auf alle Ceph-Hosts, möglichst ohne eine dazwischen geschaltete Firewall. Ratsam ist zudem das Einrichten eines eigenen Layer-2-Netzwerks für die Ceph-Infrastruktur, die von anderen Servern oder Desktop-Systemen getrennt ist. croit unterstützt in diesem Zusammenhang auch die Netzwerksegmentierung mit VLANs und empfiehlt für Produktions-Setups zwei unterschiedliche Netze, eines für den administrativen Datenverkehr zwischen dem Management-Node und den einzelnen Ceph-Servern, und ein zweites, das als eigentliches Ceph-Netzwerk den Datentraffic innerhalb des Clusters und zwischen Cluster und Clients abdeckt.

Das Medium definiert die Geschwindigkeit

Neben einem performanten Netz sollte in einem Storage-Cluster auch die Hardware zur Datenspeicherung möglichst leistungsstark sein, wobei natürlich die Spezifikation auch vom jeweiligen Einsatzzweck abhängt. Im Prinzip kann via Ceph jeder Server in den Cluster eingebunden werden, der über das Netzwerk angesprochen werden kann. Erfahrungswerte aus der Praxis zeigen, welche Systeme sich für einen reibungslosen und langfristigen Einsatz im Cluster am besten eignen. Schnellere – und teurere – Technologien wie NVMe bringen dabei natürlich Performance-Vorteile, aber Ceph ermöglicht hier einen effizienten Mix, in dem sich jedem Prozess der am besten passende Storage zuteilen lässt. Gegenüber klassischen Systemen können Unternehmen Kosten einsparen, weil keine RAID-Controller benötigt werden und die Systeme anstatt einer »One-Size-fits-all«-Lösung für den jeweiligen Anwendungsfall zusammengestellt werden können.

Die beste Performance bringen aktuell PCIe NVMe SSDs. SATA-Festplatten eignen sich aufgrund ihres günstigen Preises vor allem für Backup-Zwecke. Um ein möglichst gutes Preis-/Leistungsverhältnis zu erzielen, können Daten auch in hybriden Setups gespeichert werden. Vereinfacht dargestellt liegen die Daten im Cluster einmal auf einer SSD und zweimal redundant auf Festplatten. Läuft der Cluster korrekt, liefert die SSD hohe Geschwindigkeit, bei einem Ausfall sind die Daten über die Festplatten weiter verfügbar, allerdings mit geringerer Geschwindigkeit. Ein guter Kompromiss zwischen Performance, Sicherheit und Kosten.

Von MON und OSDs

Zur Überwachung des Clusters nutzt Ceph so genannte MON (Monitor) Nodes oder Server. Hier sind die Hardwareanforderungen recht überschaubar, ein kleines System oder eine VM mit etwas lokalem Speicher (in der Regel reicht eine 256 GB SSD), 16 GB RAM und 2 CPU-Cores reicht in der Regel aus. Da es sich bei den MONs um reine Softwareprozesse handelt, können sie auch auf den Storage-Nodes mitbetrieben werden, sofern dort ausreichend RAM- und CPU-Kapazität zur Verfügung stehen. Die MON-Nodes erstellen eine »Cluster Map« und sorgen im laufenden Betrieb für die Verwaltung des Clusters.

Als Basis für den eigentlichen Speicher dienen Storage-Nodes mit Platz für mehrere Platten oder SSDs. Pro eingebautem Speichermedium sollten die Server mindestens 6 GB RAM bieten, besser sind 8 GB. Bei einer Bestückung mit zwölf 14 TB-Medien sollten also 128 GB RAM vorhanden sein. Im laufenden Betrieb wird der Arbeitsspeicher in der Regel nicht gefordert, aber beispielsweise bei einem Recovery erweist sich weniger RAM schnell als Flaschenhals.

Die CPU-Anforderungen hängen von der Zahl der Platten oder SSDs ab. Für jedes einzelne Speichermedium startet Ceph einen Software-Prozess, der als OSD bezeichnet wird (Object Storage Daemons). Als Faustregel gilt, dass für jedes Speichermedium/ jeden OSD ein echter oder Hyper-Threading-Core zur Verfügung stehen sollte. Addiert man noch etwas Rechenpower, etwa für Betriebssystem und Netzwerkkarten hinzu, sollte im oben genannten Beispiel mit zwölf Devices also im Server mindestens eine 8-Kern-CPU mit Hyper-Threading verbaut sein, bei SSDs sollte besser mit zwei Threads pro Device kalkuliert werden, bei NVMe-Speicher sogar mit vier bis acht. Teure Rechenzentrums-Hardware ist dabei nicht erforderlich, auf der anderen Seite sollte aber auch auf besonders günstige Speichermedien mit schlechter Performance verzichtet werden.

Grafische Installation erleichtert das Ceph-Leben

Die Installation eines Ceph-Clusters geht mit Hilfe von croit schnell vonstatten: Docker Container einrichten, Anwendung starten und die Basis konfigurieren ist eher eine Sache von Minuten als Stunden, wenn die entsprechende Hardware im Netz vorhanden ist. Das Feintuning nimmt dann doch etwas mehr Zeit in Anspruch, die Investition lohnt sich aber. Zuerst wird der Management Node eingerichtet, danach die einzelnen Storage-Nodes. Auf den dafür vorgesehen Servern werden die MON-Disks eingerichtet und die MON-Dienste gestartet, die später die Ceph-Monitor-Datenbank enthalten. Aus Gründen der Ausfallsicherheit werden dabei in der Regel drei oder fünf MON-Dienste genutzt. Die anderen an den Server angeschlossenen Speichermedien werden schließlich als OSDs konfiguriert und in den Cluster integriert, indem sie der bestehenden Crushmap hinzugefügt werden. Bei Ceph nativ sind dazu mehrere Befehle auf der Kommandozeile erforderlich, croit bietet dazu einen Browser-basierten Prozess. Auch neue Hosts können über das User-Interface von croit jederzeit komfortabel zum Cluster hinzugefügt werden.

Steht die technische Basis des Clusters, baut Ceph aus allen angeschlossenen Speichermedien einen Speicherpool in Form eines Objektspeichers. Dieser Objektspeicher wird als »RADOS« bezeichnet (Reliable Autonomic Distributed Object Store) und fungiert quasi als Software-Layer zwischen der Speicher-Hardware und den Clients. Der Client-Zugriff auf RADOS kann über vier Wege erfolgen:

CephFS, ein POSIX-konformes Dateisystem.
Das RADOS Block Device (RBD) oder auch Ceph Block Device.
radosgw, ein REST basierendes Web Service Gateway (via RESTful API auch S3 und OpenStack Swift kompatibel).
Über die API librados können Applikationen direkt auf RADOS zugreifen.

croit bietet darüber hinaus noch die Einrichtung weiterer Gateways für NFS, SMB und iSCSI, so dass Linux- und Windows-Clients und auch Produkte wie VMware problemlos direkt angebunden werden können.

croit – weil der Teufel im Detail steckt

Die Machtverhältnisse in der IT haben sich gedreht. Software regiert mittlerweile das Rechenzentrum, wohingegen Hardware immer standardisierter und austauschbarer wird. Die Vorteile liegen auf der Hand: Deployment-Management und Skalierung werden einfacher, Hardwarekomponenten können problemlos ausgetauscht oder aktualisiert werden. Mit Blick auf Ceph ist das Einrichten eines Clusters für einen versierten Admin kein Hexenwerk. Der Teufel liegt – wie so oft – im Detail und ein Großteil der Konfigurationsarbeit erfolgt bei »native Ceph« über die Konsole. Hier sind zahlreiche Faktoren zu berücksichtigen, an vorderster Front sind das der Durchsatz und die Latenz.

Bei croit erleichtern eine durchgängige GUI, zahlreiche Skripte und fertige Schnittstellen die Einrichtung enorm. Wie beschrieben ist dabei vor allem das »Sizing« des Clusters ohne hinreichende Erfahrung nicht gerade trivial und Fehler können üble Folgen haben: Zu gering dimensionierte Hardware kann beispielsweise dazu führen, dass Journale überlaufen oder die Performance generell in den Keller geht. Es mag paradox klingen, aber auch die Einfachheit im Aufbau von Ceph kann zu einem Problem werden, wenn wachsende Speicheranforderungen mit immer mehr Platten beantwortet werden, ohne gleichzeitig auch die Nodes entsprechend aufzurüsten.

Mit croit lassen sich die meisten Fallstricke bei der Einrichtung und Verwaltung eines Ceph-Clusters elegant umschiffen. Und falls nicht, stehen – neben der agilen Open-Source-Community – qualifizierte Consultants und Support-Mitarbeiter zur Verfügung. Der große Vorteil für die Kunden liegt darin, dass croit eine zusätzliche Ebene für Management und Deployment aufbaut. Der Vorteil dieses Ansatzes zeigt sich gerade sehr deutlich für Kunden von SUSE: Der Linux-Anbieter zieht sich aus dem Ceph-Markt zurück und vermarktet seine Ceph-basierende Storage Lösung SES nicht mehr länger. Bei Unternehmen mit Petabyte großen Clustern wird dieser Move wohl ein flaues Gefühl im Magen hinterlassen. Muss es aber nicht, denn mit der Lösung von croit lassen sich auch auf SUSE Enterprise Storage basierende Ceph-Installationen problemlos importieren und zukunftssicher weiterbetreiben oder migrieren.

Andy Muthmann, Sales Director croit

www.croit.io

149 Artikel zu „Software defined Storage“

NEWS | RECHENZENTRUM

In 5 Schritten zum Open Source Software Defined Storage

16. Mai 2019

Die Anforderungen für Speichersysteme sind in den letzten Jahren immer weiter gestiegen, Agilität, Flexibilität und die schnelle Bereitstellung von Ressourcen sind in einer bi-modalen IT die großen Herausforderungen. Wir haben heute mit mobilen und IoT-Geräten weitaus mehr Endpunkte, an denen Daten generiert werden, als noch vor einigen Jahren denkbar gewesen wäre. Besonders Videoinhalte verbreiten sich…