Ceph als iSCSI-Datastore für VMware

Starkes Gespann

Lothar Gesslein

Ein Einsatz als Cloud-Storage ist für Ceph ein Brot-und-Butter-Geschäft. Mit der richtigen Konfiguration lässt sich damit eben auch eine günstige Alternative zu EMC, NetApp und Co. realisieren.

Standardhardware kombiniert mit intelligenter Storage-Software als redundanter und ausfallsicher Speicher (Software-defined Storage) erfreut sich großer Beliebtheit und ist eine günstige und skalierbare Alternative zu den SAN- und RAID-Hardwareboxen der bekannten Hersteller. Im Open-Source-Bereich führt hier kein Weg mehr an Ceph vorbei. Viele kommerzielle Linux-Distributoren bieten es – ergänzt um Support und Administrationswerkzeuge – als eigenes Produkt an. So lässt sich Ceph selbst für unternehmenskritische Geschäftsanwendungen einsetzen.

Neben den Kosten und der Skalierbarkeit sind Hochverfügbarkeit und Redundanz von Ceph überzeugende Argumente, diese Technik als Speicher-Backend für möglichst viele Plattformen zu nutzen. Offensichtlich ist die Kombination Linux mit einem KVM-Hypervisor (oft in Form einer Private Cloud mit OpenStack), der über native Treiber für Ceph verfügt. Doch auch die proprietären Hypervisoren benötigen redundanten und hochverfügbaren Storage. Das hier beschriebene Konzept konzentriert sich auf die Kombination von Ceph mit VMware, ist jedoch genauso auf praktisch jede andere Hypervisor-Plattform übertragbar.

ceph-deploy install ceph-1 ceph-2 ceph-3
ceph-deploy new ceph-1 ceph-2 ceph-3
ceph-deploy mon create-initial
ceph-deploy mgr create ceph-1 ceph-2 ceph-3
ceph-deploy osd create --data /dev/sdb ⤦
 ceph-1
ceph-deploy osd create --data /dev/sdb ⤦
 ceph-2
ceph-deploy osd create --data /dev/sdb ⤦
 ceph-3

In einer Reihe von Artikeln stellte iX Design, Installation, Verwaltung und Tuning eines Ceph-Clusters vor [1–4]. Der weitere Artikel setzt einen Ceph-Cluster voraus und konzentriert sich auf das Installieren und Konfigurieren des iSCSI-Gateways. Mit dem Werkzeug ceph-deploy lässt sich, wie in Listing 1 beschrieben, in wenigen Schritten ein Ceph-Cluster zu Testzwecken installieren.

Anforderungsprofil Redundanz

Für wichtige Anwendungen gibt es im Prinzip nur zwei Möglichkeiten: Entweder sie implementieren die (Daten-)Redundanz selbst als Teil der Softwareebene (etwa eine Datenbankreplikation), oder sie verlassen sich auf eine zugrunde liegende Plattform oder Hardware, die die nötige Ausfallsicherheit schafft. Häufig nutzt man dazu die Virtualisierungsplattform, die heutzutage sowieso kaum noch eine Anwendung umgehen sollte. Eine virtuelle Maschine bei einem Hardwaredefekt innerhalb weniger Minuten wieder zu starten, erfüllt zwar nicht die allerstrengsten Servicegarantien, ist aber simpel, günstig, betriebssystemübergreifend und lässt sich vor allem vollständig automatisieren.

Dafür unverzichtbar ist eine redundante Datenspeicherung, unabhängig von den lokalen Festplatten der Hypervisor-Hardware. Klassisch verzichtet man auf Festplatten direkt im Hypervisor und verwendet externe Storage-Hardware, die eigenständig und in sich geschlossen die Daten auf mehrere Festplatten verteilt und durch redundante Komponenten eine hohe Verfügbarkeit garantiert. Steigt der Platzbedarf, lässt sich der Storage in Kapazität oder Leistung skalieren. Es bietet sich also an, einen großen Verbund wie Ceph als unternehmensweite Ressource bereitzustellen und auch für weitere Systeme oder Plattformen zu nutzen.

Ceph kommuniziert mit Client-Anwendungen ausschließlich über das objektbasierte RADOS-Protokoll, bei dem einzelne Dateien oder Datenstrukturen als einzelne Objekte redundant auf mehrere Storage-Server (OSD) abgelegt und von diesen wieder heruntergeladen werden können. Darauf aufbauend lassen sich RADOS Block Devices (RBD) definieren, die eine logisch zusammenhängende „Festplatte“ in kurze Datenblöcke unterteilen und als einzelne Objekte im Ceph-Cluster speichern.

Anwender können das RDB – durch einen Linux-Kerneltreiber als Blockgerät dargestellt – ganz normal mit einem Dateisystem formatieren und mounten. So können beliebige lokale Applikationen auch ohne spezielle Unterstützung für das Ceph-Protokoll den Storage verwenden. Schwierig ist aber, damit im Fehlerfall sauber und ohne Datenverlust denselben Storage automatisch einem Ersatzsystem zu präsentieren oder die gleichen Daten auf mehreren Systemen parallel zu nutzen.

Eleganter ist ein nativer und anwendungsspezifischer Treiber, wie er mittlerweile für den Open-Source-Hypervisor QEMU/KVM existiert. Ohne weitere Umwege über Blockgeräte, Dateisysteme oder Kerneltreiber kann dieser mit minimalem Overhead die virtuellen Festplatten eines Gastsystems über das Netzwerk direkt aus dem jeweiligen Ceph-Cluster bereitstellen.

Übersetzer gesucht

Für eine geschlossene Plattform wie VMware gibt es jedoch keinen eigenen Ceph-Client. Das erfordert einen „Übersetzer“ für das Ceph-RADOS-Protokoll in ein von der Plattform unterstütztes Netzwerkprotokoll. Für Ethernet-basierte Speichernetze ist iSCSI das Protokoll der Wahl; es lässt sich von praktisch jedem Betriebssystem und auch von VMware nutzen. Ein Linux-System dient als iSCSI-Gateway (iSCSI-Target), das mit dem Ceph-Cluster kommuniziert und ein oder mehrere RADOS Block Devices als iSCSI-Festplatte (LUN) präsentiert. Diese können die Clients (iSCSI-Initiatoren) wie ein Blockgerät einbinden (siehe Abbildung 1).