Ceph in Proxmox – verteiltes Storage im praktischen Einsatz

Proxmox bietet mehrere Optionen: klassische NAS- oder SAN-Ansätze mit Replikation und Ceph. Für unsere Testumgebung suchten wir eine Storage-Lösung, die unserem bisher eingesetzten VMware vSAN möglichst nahekommt: ein verteiltes, hochverfügbares Objekt-Storage-System, welches flexibel und skalierbar ist und eine automatische Lastverteilung zur Verfügung stellt. Unsere Wahl fiel daher auf Ceph.

Doch was ist Ceph eigentlich? Wie richtet man dies in Proxmox ein und welche Stolperfallen lauern bei der Umstellung? Dieser Artikel zeigt, wie wir Ceph in unserer Proxmox-Umgebung umgesetzt haben, auf welche Probleme wir dabei gestoßen sind und wie wir diese erfolgreich lösen konnten.

Was ist Ceph?

Ceph ist ein Open-Source-Storage-System, welches Daten redundant auf vielen Servern verteilt speichert und somit ein hochverfügbares und fehlertolerantes System schafft. Die Basis bilden sogenannte OSDs (Object Storage Daemons). Jeder OSD verwaltet in der Regel eine einzelne Festplatte und übernimmt Aufgaben wie die Speicherung, Replikation und Wiederherstellung von Objekten. Zudem wird er einer bestimmten Geräteklasse (Standard-Klassen oder einer eigenen) zugeordnet, worüber eine gezielte Zuweisung zu den jeweiligen Datenpools erfolgt. Die OSDs arbeiten mit der BlueStore-Architektur und verwalten somit Objekte direkt auf Blockgeräten, ohne ein Dateisystem zwischenzuschalten. Pro OSD können drei verschiedene Geräte zum Einsatz kommen: Primary Data Device, WAL (Write-Ahead Log) und DB (Datenbankgerät). Auf dem Primary Data Device liegen die tatsächlichen Objekt-Daten. Darauf werden die Daten zuerst geschrieben und anschließend die Metadatenbank aktualisiert. Der WAL ist im Prinzip ein internes Journal von BlueStore und wird genutzt, um hohe Schreibperformance sicherzustellen. Auf dem DB-Device werden die Metadaten gespeichert.

Wie die Daten im Cluster verteilt werden, bestimmen die CRUSH-MAP und die PGs (Placement Groups). Die CRUSH-MAP wird für die direkte Kommunikation zwischen den Ceph-Clients und den OSDs genutzt und beschreibt die logische und physische Struktur des Clusters. Die Struktur selbst wird über erstellte Regeln aufgebaut, worüber unter anderem die Zuordnung von Geräteklasse zu Ceph-Pool realisiert wird. PGs fungieren als logische Container innerhalb eines Ceph-Pools. Sie bündeln viele Objekte und ermöglichen so eine effizientere Verwaltung, bessere Lastverteilung und vereinfachte Recovery-Prozesse.

Damit der Cluster zuverlässig arbeitet, werden zusätzlich Monitor Daemons (MONs) und Manager Daemons (MGRs) benötigt. Der MON überwacht den Cluster-Zustand und verwaltet die Cluster-Map, wohingegen der MGR weitere Monitoring- und Management-Funktionen bietet.

Darüber hinaus kennt Ceph noch andere Komponenten: Der MDS (Metadata Server) wird benötigt, wenn man das CephFS-Dateisystem verwendet. Er verwaltet und koordiniert Metadaten wie Dateinamen, Verzeichnisse und Berechtigungen. Das RGW (RADOS Gateway) stellt eine S3- und Swift-kompatible Schnittstelle bereit, über die Anwendungen Ceph als Objektspeicher nutzen können. Das RBD (RADOS Block Device) ist eine Blockspeicherlösung, welche auf die Objektspeicherschicht (RADOS) von Ceph aufsetzt. Es ermöglicht das Erstellen von thin-provisioned, dynamisch skalierbaren Blockgeräten, z.B. Festplatten für virtuelle Maschinen (VM) oder Container.

Die Planung des ersten Ceph

Wie bereits im vorherigen Artikel angekündigt, hatten wir zum Zeitpunkt der Umstellung noch nicht ein so tiefes Verständnis von Ceph. Wir dachten damals, dass wir die SSDs nicht als Cache für die HDDs (Hard Disk Drives) – wie zuvor beim VMware-Cluster – nutzen könnten. Dementsprechend wollten wir zwei Datenpools aufbauen: CoCo-VIP für die SSDs und CoCo-Data für die HDDs. Auf CoCo-VIP sollten die für die Umgebung wichtigsten VMs laufen, auf CoCo-Data die VMs der Kollegen. Beide Datenpools sollten nach ihrer Erstellung Proxmox als RBD zur Verfügung gestellt werden.

Bei den MON- und MGR-Diensten haben wir uns dazu entschlossen, diese auf allen Servern zu installieren. Zwar hätte die Aktivierung auf nur einem Server ausgereicht, doch falls genau dieser ausfiele, stünden uns die Funktionalitäten nicht mehr zur Verfügung. Daher läuft der MON-Dienst auf allen Servern, während beim MGR-Dienst ein Server als „active“ und die anderen als „standby“ markiert sind.

Die Installation von Ceph

Bevor mit der Installation von Ceph begonnen werden konnte, musste die Netzwerkkonfiguration entsprechend vorbereitet werden. In unserem Fall wurden pro Server die beiden 10Gbit-Netzwerkkarten einem Linux-Bond und einem entsprechenden Netzwerk zugeordnet. Danach musste Ceph auf jedem Server installiert werden, was über die Weboberfläche von Proxmox unter dem Reiter Ceph des jeweiligen Nodes erfolgen konnte. Bei der Installation auf dem ersten Server wurden die Informationen zu der Netzwerkkonfiguration abgefragt und der erste MGR und MON direkt eingerichtet. Nachdem Ceph auf allen Servern installiert und automatisch dem Ceph-Cluster hinzugefügt worden war, sollten die weiteren MON- und MGR-Daemons eingerichtet werden. Dies erfolgte auf dem jeweiligen Server unter Ceph → Monitor.
Der nächste Schritt bestand darin, die benötigten OSDs zu erstellen. Dies passierte auf dem jeweiligen Server unter Ceph → OSD. Die dafür nutzbaren Festplatten wurden automatisch als Disk in der Oberfläche erkannt. Wurde keine angezeigt, musste die Festplatte vorher unter Disks gewipet werden.

Neben der Angabe der benötigten Device Class für die Zuordnung zum Datenpool sowie der DB- bzw. WAL-Disk kann die Festplatte verschlüsselt werden. Wird die Option ausgewählt, erfolgt die Verschlüsselung über „dmcrypt“, und der entsprechende Schlüssel wird im JSON-Format an den Monitor weitergeleitet. Als Device Class stehen standardmäßig drei verschiedene Klassen zur Verfügung, die automatisch erkannt werden können:

• HDD
• SSD
• NVMe

Es besteht des Weiteren die Möglichkeit, eigene Pseudo-Device-Classes zu erstellen, die manuell als eine Art Label gesetzt werden können. In unserem ersten Aufbau mit den beiden Ceph-Pools reichten die Standard-Klassen aus, und die OSDs wurden entsprechend mit den Klassen HDD bzw. SSD erstellt.

Für die Ceph-Pools musste anschließend die passende Crush Rule angelegt werden. Dies erfolgte über die CLI (Command Line Interface) mit dem Befehl „ceph osd crush rule create-replicated name default host device-class“, wobei „name“ durch den Namen der Regel und „device-class“ durch die gewünschte Device Class ersetzt wurde. Die Pools selbst konnten daraufhin wieder über die Weboberfläche erstellt werden.

Wenn das Häkchen bei Add as Storage gesetzt ist, wird der Ceph-Pool automatisch als RBD-Storage dem Proxmox-Datacenter hinzugefügt und kann somit für die VMs und Container genutzt werden.

Migration und Funktionstests

Der letzte Schritt bestand darin, alle VMs von der alten Testumgebung auf die neue Umgebung und das neue Storage zu migrieren und anschließend einem kurzen Funktionstest zu unterziehen. Uns war von Anfang an bekannt, dass die Geschwindigkeit nicht mit dem vorherigen Aufbau vergleichbar war, da die SSDs nicht mehr als Cache dienten. Der kurze Funktionstest bestand primär aus dem Hoch- und Herunterfahren der VMs sowie dem Erstellen von Snapshots. Es hat zwar etwas mehr Zeit in Anspruch genommen, doch wir konnten in die Beta-Phase übergehen und die Kollegen die detaillierteren Funktionstests durchführen lassen. Erst da wurde klar, welche Einschränkungen durch die niedrigere Schreib- und Lesegeschwindigkeit bei den verschiedenen VMs entstanden. Bei kleineren VMs, welche zum Beispiel als Jumphost fungierten oder z.B. DNS-Dienste zur Verfügung stellten, traten keine nennenswerten Einschränkungen auf. Im Gegensatz dazu waren unsere größeren VMs kaum nutzbar. Besonders bei der VM EveNG, die für die Virtualisierung von Netzwerkgeräten zum Testen von Netzwerkkonfigurationen eingesetzt wird, war die Storage-Geschwindigkeit deutlich zu gering:

dd if=/dev/zero of=/tmp/test1.img bs=1G count=1 oflag=dsync
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 21.4141 s, 50.1 MB/s

dd if=/dev/zero of=/tmp/test2.img bs=512 count=1000 oflag=dsync
1000+0 records in
1000+0 records out
512000 bytes (512 kB, 500 KiB) copied, 134.155 s, 3.8 kB/s

Wäre nur diese VM betroffen, hätte man sie auf den CoCo-VIP-Pool migrieren können. Da aber mehrere VMs einen Storage-Performance-Boost benötigten, war dieser Workaround keine Lösung, und ein neuer Plan musste her: Es soll nur noch einen Ceph-Pool mit den HDDs geben, dessen WAL/DBs auf den SSDs liegen. Die Umstellung selbst muss außerdem im laufenden Betrieb durchgeführt werden.

Umstellung der WAL/DB

Für die Umstellung der WAL/DB im laufenden Betrieb ist sehr viel Zeit nötig, da nach jedem Entfernen eines OSD das Ceph neu balanciert werden muss. Im ersten Schritt haben wir alle VMs von CoCo-VIP auf CoCo-Data migriert, um CoCo-VIP löschen zu können. Die SSDs mussten anschließend neu formatiert werden. Sollte die WAL/DB-SSD ausfallen, konnte Ceph nicht mehr auf die Daten der HDDs zugreifen, wodurch dauerhaft Daten verloren gehen konnten. Um dieses Risiko zu minimieren, wurden die beiden SSDs zu einem RAID1 zusammengeschlossen, und für jede OSD wurde eine eigene Partition erstellt. Diese Partition sollte ca. 4-5 % der HDD-Kapazität besitzen. Nachdem dies auf allen Servern konfiguriert war, begann der kritische Teil der Umstellung: das Umstellen der HDD-OSDs. Um den Betrieb aufrechtzuerhalten, sind wir serverweise vorgegangen und entfernten, löschten und konfigurierten jede OSD einzeln neu. Nach der Konfiguration der ersten OSD wurden direkt der neue Ceph-Pool CoCo und die Pseudo-Device-Class coco-class erstellt. Die Umstellung der Device Class erfolgte über die CLI, indem sie mit folgenden Befehlen zuerst gelöscht und dann neu gesetzt wurde:

ceph osd crush rm-device-class (OSD-Nr)
ceph osd crush set-device-class coco-class osd.(Nr)

Die ganze Prozedur wurde dann für den zweiten und dritten Server wiederholt, um anschließend alle VMs auf den neuen Ceph-Pool zu migrieren. Nachdem die Migration abgeschlossen war, konnten beim vierten und letzten Server alle verbleibenden OSDs direkt umgestellt werden.
Der letzte Schritt bestand wieder aus den Funktionstests, in denen wir die EveNG-VM erneut einem Performance-Test unterzogen haben:

dd if=/dev/zero of=/tmp/test1.img bs=1G count=1 oflag=dsync
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.06633 s, 520 MB/s

dd if=/dev/zero of=/tmp/test2.img bs=512 count=1000 oflag=dsync
1000+0 records in
1000+0 records out
512000 bytes (512 kB, 500 KiB) copied, 3.66194 s, 140 kB/s

Anhand dieser Werte kann man erkennen, dass die Umstellung eine deutliche Erhöhung der Geschwindigkeit gebracht hat.

Monitoring des Ceph

Neben den Logs der einzelnen MON-Daemons lässt sich in Proxmox das Ceph-Dashboard anzeigen. Dort können die aktuelle Health, der Status der OSDs, PGs und Services sowie die aktuelle Performance in Echtzeit eingesehen werden.

In der Anzeige der Performance werden neben der genutzten Kapazität lediglich ab dem Zeitpunkt des Aufrufs die aktuellen Daten von Reads, Writes, IOPS (Input/Output Operations Per Second) Reads und IOPS Writes angezeigt.

Für weiteres Monitoring gibt es noch einige andere Möglichkeiten, die zusätzlich konfiguriert werden müssen. Diese haben wir zum derzeitigen Zeitpunkt noch nicht getestet. Wenn man der Dokumentation von Ceph glauben darf, gibt es Module im Manager, um ein eigenes Webinterface als Dashboard zu konfigurieren oder die Anbindung an ein Monitoring-Tool wie z. B. Zabbix vorzunehmen.

Fazit

Die Einrichtung von Ceph über die Weboberfläche von Proxmox ist einfach gehalten und kann schnell umgesetzt werden. Ceph lässt sich über die CLI mit mehr Einstellungsmöglichkeiten konfigurieren, was für Standard-Szenarien nicht oder nur teilweise nötig ist. Mit unserer neuen Storage-Lösung konnten wir die HA (High Availability) in Proxmox konfigurieren und testen. Das Monitoring an sich ist bislang lediglich ein Grundgerüst und reicht für die Nutzung in der Testumgebung aus. In Zukunft werden wir das Monitoring erweitern, um mehr Informationen sehen zu können. Auch das Logging möchten wir an anderer Stelle speichern. Theoretisch ist dies möglich, wie es in der Praxis aussieht, werden wir sehen.