Interview mit Kim-Norman Sahm über Ceph

Kim-Norman Sahm ist Head of Cloud Technology bei der Cloudibility und als Experte in den Bereichen OpenStack, Ceph und Kubernetes unterwegs. Als typischer Ops-ler ist er im Thema Storage Zuhause und hat schon einige Ceph-Projekte umgesetzt. Speichermöglichkeiten und -kapazitäten spielen im IT-Umfeld schon immer eine große Rolle, mit dem Gang in die Cloud verändern sich diese Möglichkeiten aber sehr, wie sie sich verändern und wie Ceph dabei eingebunden werden kann, sind wir in diesem Interview auf den Grund gegangen.

Warum ist das Thema Storage wichtig? Was ist besonders an Storage in der Cloud? Was hat sich verändert?

Storage war schon immer Thema, in der Legacy-Welt gab es die Anforderungen, alle Informationen, die anfallen, zu speichern. Alle Apps waren darauf angewiesen, persistenten Storage zur Verfügung zu haben. Generell wurde mit Storage- und Compute-Ressourcen sehr großzügig umgegangen. Selbst für kleinste Anwendungen wurden häufig zu große Server angeschafft, die normalerweise zu 90 % ungenutzt blieben. Dabei waren Systeme unflexibel und in monolithische Storage-Blöcke eingeteilt. Es gab nur wenige Storage-Hersteller und die Angebote waren oft sehr teuer.

Mit der Zeit entwickelte es sich in die Richtung, Ressourcen effizienter zu nutzen, sowohl Compute als auch Storage. Virtualisierung wurde als die Lösung gesehen, Compute-Ressourcen effizienter zu nutzen. Der Storage-Bereich wandelte sich hin zu SDS-Lösungen (Soft- ware Defined Storage), welche eine Vielzahl von Vorteilen mit sich bringen: Kosteneffizienz, Flexibilität, Elastizität, … Software-Lösungen brechen die harten Grenzen der klassischen Storage-Lösungen auf und ermöglichen verteilte Systeme, Georedundanz und, zum Beispiel mit Ceph, vermeiden sie Vendor Lock-in, das heißt, das Storage-System ist nicht länger von einem Hersteller abhängig. In der Cloud ist Storage inzwischen ein Service, der Kunde will nur bezahlen, was er wirklich nutzt. Für den Anbieter ergeben sich damit auch Vorteile, er kann den Platz flexibel und somit effizient ausnutzen.

 

Bezüglich Cloud Native Anwendungen hat sich auch die Mentalität dahingehend verändert, dass nur noch gespeichert wird, was gespeichert werden muss, nicht mehr alles. Der größte Teil von Microservices sind beispielsweise stateless, es werden keine Daten mehr gespeichert. Somit wird der Storage auch diesbezüglich effizient genutzt.

Wie kommt hier Ceph ins Spiel?

Ceph ist eine Software Defined Storage-Lösung, entstanden aus der Doktorarbeit von Sage Weil konnte sich Ceph erfolgreich auf dem damals noch dünn besiedelten Software Defined Storage-Markt behaupten. Die Open Source-Lösung bietet ein hochverfügbares Storage-Backend, welches auf jeder beliebigen X86 Server-Hardware läuft. Vereinfacht ausgedrückt fasst Ceph alle physikalischen Festplatten im Cluster-Verbund zusammen und stellt diese als logischen, hochverfügbaren Storage-Pool zur Verfügung, der dann eine Gesamtkapazität der Summe aller Platten bereitstellt. Dies kann dann in mehrere logische Pools aufgeteilt werden, die den Anwendungen zur Verfügung gestellt wer- den.

Ein großer Vorteil von Ceph ist, dass es Block-, Object- und File-Storage aus einem Backend bereitstellen kann. Man ist nicht in der Situation, für jeden Storage-Typ eine eigene Storage- Lösungen anschaffen zu müssen (Figure 1).

Wie arbeitet Ceph?

Als das Ceph-Projekt gestartet wurde, beschränkte sich das Angebot auf Block- und Object-Storage. Im Vergleich zu anderen Storage-Lösungen, die über Gateway- oder Proxy-Nodes den Client mit dem Storage-System verbinden, führte Ceph von Anfang an eine “no single point of failure” ein. Die Ceph-Architektur bestand zunächst aus Ceph Monitor (Mon) und Ceph OSD (Object Storage Daemon).

Mons stellen die Cluster-Logik bereit, es müssen mindestens 3, maximal 11 Monitoren im Cluster existieren, deren Anzahl wegen Quorum immer ungerade sein muss. Die Aufgabe der Mons ist es, den Cluster-State zu überwachen und die hochverfügbare Verteilung der Objek- te zu gewährleisten. Dafür halten die Mons die CRUSH-Map, eine Art Lageplan der Objekte, vor. Die eigentlichen Nutzdaten werden auf den OSD-Nodes gespeichert. Eine OSD stellt immer genau eine physikalische Festplatte dar. Wenn ein Client auf die Block-Storage-Daten

 

„Ein großer Vorteil von Ceph ist,

dass es Block-, Object- und File-

Storage aus einem Backend bereitstellen kann. “

 

zugreifen möchte, wendet er sich zunächst an einen der Monitor-Nodes und fordert die CRUSH-Map an. Anhand dieser Map und dem Berechnungsalgorithmus CRUSH ist der Client selbständig in der Lage zu berechnen, auf welchen OSDs die Daten liegen, die er benötigt, und kontaktiert dann direkt die entsprechenden OSD-Nodes (Figure 2).

Werden Daten geschrieben, verhält sich das System analog. Um die Hochverfügbarkeit zu gewährleisten, werden Objekte vom Ceph-Cluster dreifach (Ceph Default Wert) repliziert. Ein Objekt wird geschrieben, es existiert danach aber dreimal im Cluster. Das Replizierungslevel ist anpassbar, man begeht dabei aber den Spagat zwischen Hochverfügbarkeit und Kosteneffizienz. Die Besonderheit hierbei ist, dass der Schreibvorgang dem Client erst bestätigt wird, wenn alle Replikas geschrieben wurden. Dies stellt allerdings eine Schwierig- keit beim Aufbau von Geoclustern dar, weil die Paket-Laufzeiten zu Problemen führen können. Deshalb gibt es keine Ceph-Geocluster. Das Ceph-Projekt arbeitet aktuell unter anderem an asynchronen Schreibvorgängen, um Geocluster zu ermöglichen.

Einen großen Schritt vorwärts ging es für das Ceph-Projekt, als die OpenStack-Community auf Ceph aufmerksam wurde und sich dies hervorragend als Backend für OpenStack Cinder (Block-Storage) sowie als Ersatz für

OpenStack Swift (Object-Storage) anbietet. Diese Entwicklung verhalf Ceph zu einem höheren Marktanteil, da Ceph bis heute als das Standard-Storage-Backend für OpenStack gilt. Um die Dreifaltigkeit des Storage zu vollenden, führte Ceph mit CephFS ein Netzwerk-basiertes Filesystem ein, dessen Client-Modul sich seit Version 2.6 im Linux-Kernel befindet.

 

„Mit seiner großen Skalierbarkeit ermöglicht

Ceph, mit einem kleinen Setup zu starten.“

 

Warum wird Ceph eingesetzt? Wofür ist es wichtig?

Aufgrund seiner Vielseitigkeit eignet sich Ceph für viele Unternehmen. Mit seiner großen Skalierbarkeit ermöglicht Ceph, mit einem kleinen Setup zu starten und dieses mit der steigenden Anfrage/Nutzung wachsen zu lassen. Ob als reiner Object-Store für Backups und andere Anwendungen, als Backend für Private Cloud-Lösungen auf Basis von OpenStack oder KVM oder als NFS- Ersatz für Linux-Clients, ist Ceph flexibel verwendbar. Durch die gute Integration in Kubernetes wird auch der Einsatz von Ceph in der Container-Welt realisierbar.

In den meisten Management-Runden ist das Hauptargument für die Einführung von Ceph der preisliche Vorteil gegenüber kommerziellen Closed Source Enterprise Storage-Lösungen. Günstige Server-Hardware und Community-Software ermöglichen einen Start mit geringen Capex-Aufwänden. Wem der Einsatz von Open Source-Software mit Community-Support schlaflose Nächte bereitet, der hat die Möglichkeit über die Linux-Distributoren kommerziellen Support zu erwerben.

Das Subscriptions-Modell ist dabei sehr differenziert und sollte im Vorfeld gründlich geprüft werden. Generell gilt, so vielseitig Ceph ist, desto größer ist die Herausforderung im täglichen Betrieb. Das Ops-Team muss entsprechend fit sein.

 

Das Interview führte Friederike Zelke / Cloudibility