Proxmox Ceph

Ceph in Proxmox VE

Einleitung

Ceph ist ein verteiltes Storage-System, das in Proxmox VE nativ integriert ist. Es ermöglicht es, den lokalen Speicher mehrerer Nodes zu einem gemeinsamen, hochverfügbaren Storage-Pool zusammenzufassen – ohne externe SAN- oder NAS-Appliance.

Dieses Dokument richtet sich an Schulungsteilnehmer und erklärt Ceph von den Grundlagen bis zur praktischen Einrichtung in Proxmox.

Das Problem: Warum Ceph?

In einem klassischen Proxmox-Cluster mit lokalem Speicher (z. B. ZFS auf jedem Node) gibt es ein grundlegendes Problem:

• Fällt ein Node aus, sind die darauf gespeicherten VM-Daten nicht verfügbar.
• Live-Migration von VMs zwischen Nodes erfordert gemeinsamen (shared) Speicher.
• Ein externes SAN oder NAS ist teuer und bildet einen Single Point of Failure.

Ceph löst diese Probleme, indem es die Daten verteilt und repliziert über alle beteiligten Nodes speichert.

Entstehungsgeschichte

Zeitraum	Ereignis
2004–2007	Entwicklung als Forschungsprojekt an der University of California, Santa Cruz (UCSC) durch Sage Weil im Rahmen seiner Doktorarbeit. Finanziert u. a. durch das U.S. Department of Energy und Lawrence Livermore National Laboratory.
2006	Erste Veröffentlichung als Open Source.
2007	Veröffentlichung der Dissertation: "Ceph: Reliable, Scalable, and High-Performance Distributed Storage"
2010	Aufnahme des Ceph-Clients in den Linux Mainline-Kernel.
2012	Sage Weil gründet die Firma Inktank für kommerziellen Enterprise-Support.
2014	Red Hat übernimmt Inktank für ca. 175 Mio. USD. Ceph wird zum zentralen Baustein der Red Hat Storage-Strategie.
Heute	Aktive Community-Entwicklung unter der LGPL. Releases werden alphabetisch benannt (Luminous, Nautilus, Octopus, Quincy, Reef, Squid …). Beiträge von Red Hat, Canonical, SUSE u. v. m.

Die Kernidee von Sage Weil war, ein verteiltes Dateisystem zu bauen, das ohne zentrale Metadaten-Server auskommt und stattdessen den CRUSH-Algorithmus nutzt, um die Datenverteilung rein rechnerisch zu bestimmen.

Analogie: Die verteilte Bibliothek

Ceph lässt sich gut mit einer verteilten Bibliothek vergleichen:

Stell dir vor, du hast drei Bibliotheken (Nodes) in einer Stadt. Statt jedes Buch nur in einer Bibliothek zu lagern, wird jedes Buch in Kopien (Replikate) auf mindestens zwei Bibliotheken verteilt. Wenn eine Bibliothek abbrennt, sind alle Bücher noch in den anderen verfügbar.

• Die Bibliothekare entsprechen den OSDs – sie verwalten die Bücher.
• Der zentrale Katalog entspricht den MONs – er weiß, welches Buch wo liegt.
• Die Verwaltung entspricht dem MGR – sie sammelt Statistiken und bietet Übersicht.

Kernkomponenten

MON (Monitor)

Der Buchhalter des Clusters. MONs kennen den Zustand des gesamten Clusters und verwalten die Cluster Map.

• Es wird immer eine ungerade Anzahl benötigt (1, 3, 5) wegen des Quorum-Prinzips.
• In Proxmox läuft typischerweise ein MON auf jedem Node.
• MONs speichern keine Nutzdaten, sondern nur Metadaten über den Cluster-Zustand.

OSD (Object Storage Daemon)

Die eigentlichen Arbeiter im Cluster. Jede physische Disk bekommt einen eigenen OSD.

• OSDs speichern die Daten, replizieren untereinander und melden ihren Zustand an die MONs.
• Die Anzahl der OSDs bestimmt die Gesamtkapazität und Performance des Clusters.
• Fällt ein OSD aus, übernehmen die verbleibenden OSDs automatisch die Wiederherstellung (Recovery).

MGR (Manager)

Das Dashboard des Clusters. Manager sammeln Metriken und bieten Web-GUI sowie Monitoring-Schnittstellen.

• Läuft in der Regel auf denselben Nodes wie die MONs.
• Stellt das Ceph-Dashboard in der Proxmox-Oberfläche bereit.

Zusammenfassung der Rollen

Komponente	Rolle	Anzahl (Empfehlung)
MON	Cluster-Zustand & Quorum	3 (ungerade Anzahl)
OSD	Datenspeicherung & Replikation	1 pro physischer Disk
MGR	Monitoring & Dashboard	1–2 pro Cluster

CRUSH-Map und Placement Groups

CRUSH-Algorithmus

CRUSH (Controlled Replication Under Scalable Hashing) ist das Herzstück von Ceph. Er bestimmt rein rechnerisch, wo Daten gespeichert werden – ohne zentrale Lookup-Tabelle.

Die CRUSH-Map ist ein Regelwerk, das sicherstellt:

• Replikate landen nie auf demselben Node.
• Die Verteilung berücksichtigt die physische Topologie (Racks, Nodes, Disks).
• Neue OSDs werden automatisch in die Verteilung aufgenommen.

Placement Groups (PGs)

Placement Groups sind eine Zwischenschicht zwischen den Objekten und den OSDs.

Anstatt jedes einzelne Objekt individuell einem OSD zuzuordnen, werden Objekte in PGs gruppiert. Man kann sich PGs wie Postleitzahlen vorstellen: Statt jede Adresse einzeln zu routen, wird nach Postleitzahl sortiert.

• Die Anzahl der PGs beeinflusst die Verteilungsgenauigkeit.
• Proxmox berechnet automatisch sinnvolle PG-Werte.

Pools und Proxmox-Integration

Was ist ein Pool?

Ein Pool ist ein logischer Speicherbereich in Ceph mit eigenen Regeln für:

• Replikationsfaktor (z. B. size=3, min_size=2)
• Placement Groups
• CRUSH-Regeln (auf welchen OSDs darf gespeichert werden?)

Einrichtung in Proxmox (Überblick)

1. Ceph auf allen Nodes installieren (über die Proxmox-GUI unter Ceph)
2. MONs erstellen auf jedem Node
3. OSDs erstellen – physische Disks zuweisen
4. Pool anlegen mit gewünschtem Replikationsfaktor
5. Pool als Proxmox-Storage einbinden (RBD)

Danach steht der Ceph-Pool als Storage für VMs und Container zur Verfügung. Live-Migration funktioniert sofort, da alle Nodes auf denselben Daten arbeiten.

Wichtige Praxishinweise

Mindestanforderungen

Kriterium	Empfehlung
Anzahl Nodes	Mindestens 3 (Quorum)
Netzwerk	Dediziertes Ceph-Netzwerk, mindestens 10 GbE (eigenes VLAN empfohlen)
Disks	SSDs für Performance-Pools, HDDs für Kapazitäts-Pools
RAM	Richtwert: ca. 1–2 GB RAM pro OSD

Replikationsfaktor und nutzbarer Speicher

Der Standard-Replikationsfaktor ist size=3, min_size=2. Das bedeutet:

• Jedes Objekt wird auf 3 OSDs gespeichert.
• Bei Ausfall eines OSDs sind noch 2 Kopien verfügbar (Cluster bleibt voll funktional).
• Nutzbarer Speicher = ca. ⅓ der Rohkapazität.

Beispiel: 3 Nodes mit je 1 TB = 3 TB roh → ca. 1 TB nutzbar.

Typische Stolpersteine

• Recovery Storms: Wenn ein ausgefallener OSD zurückkehrt, beginnt eine Resynchronisation, die erhebliche I/O-Last erzeugen kann.
• Netzwerk-Bandbreite: Ceph ist netzwerkintensiv. Ohne dediziertes Netzwerk leidet die Performance aller Dienste.
• Falsche PG-Anzahl: Zu wenige PGs → ungleichmäßige Verteilung. Zu viele PGs → unnötiger Overhead.
• Gemischte Disk-Typen: SSDs und HDDs im selben Pool führen zu inkonsistenter Performance. Separate Pools verwenden.

Abgrenzung zu Alternativen

Lösung	Vorteile	Nachteile
Ceph (nativ in Proxmox)	Nativ integriert, horizontal skalierbar, kein SPOF, kein externes Storage nötig	Mindestens 3 Nodes, Netzwerk-intensiv, Komplexität
ZFS-Replikation	Einfach einzurichten, gute Performance	Kein echtes Shared Storage, manuelles Failover
NFS/iSCSI (extern)	Bekannt, einfach	Externer Server = SPOF, zusätzliche Hardware nötig
GlusterFS	Einfacher als Ceph	Nicht nativ in Proxmox, weniger verbreitet

Live-Demo: Hochverfügbarkeit testen

Der effektivste Weg, Ceph zu verstehen, ist eine Live-Demo:

1. VM auf dem Ceph-Pool erstellen und starten.
2. Einen Node herunterfahren (auf dem die VM ursprünglich lief).
3. Beobachten, wie die VM auf einem anderen Node automatisch weiterläuft.
4. Ceph-Status prüfen: ceph status zeigt den degradierten Zustand.
5. Node wieder hochfahren und die automatische Recovery beobachten.

Dieser "Wow-Moment" verdeutlicht den Mehrwert von Ceph besser als jede Theorie.

Nützliche Befehle

Befehl	Beschreibung
ceph status	Gesamtstatus des Clusters (Health, OSDs, PGs)
ceph osd tree	Baumansicht aller OSDs und ihrer Zuordnung zu Nodes
ceph df	Speicherverbrauch pro Pool und gesamt
ceph osd pool ls detail	Detaillierte Pool-Informationen
ceph health detail	Detaillierte Gesundheitsinformationen bei Warnungen
rados bench	Einfacher Performance-Benchmark

Quellen und weiterführende Links

• Offizielle Ceph-Dokumentation
• Proxmox Wiki: Deploy Hyper-Converged Ceph Cluster
• Proxmox VE Ceph-Dokumentation