Maximilian.pottgiesser: Die Seite wurde neu angelegt: „= Ceph in Proxmox VE = == Einleitung == Ceph ist ein verteiltes Storage-System, das in Proxmox VE nativ integriert ist. Es ermöglicht es, den lokalen Speich…“

2026-03-09T06:11:48Z

Die Seite wurde neu angelegt: „= Ceph in Proxmox VE = == Einleitung == Ceph ist ein verteiltes Storage-System, das in Proxmox VE nativ integriert ist. Es ermöglicht es, den lokalen Speich…“

Neue Seite

= 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 ==

{| class="wikitable"
|-
! 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 ===

{| class="wikitable"
|-
! 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 ('''C'''ontrolled '''R'''eplication '''U'''nder '''S'''calable '''H'''ashing) 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) ===

# Ceph auf allen Nodes installieren (über die Proxmox-GUI unter ''Ceph'')
# '''MONs erstellen''' auf jedem Node
# '''OSDs erstellen''' – physische Disks zuweisen
# '''Pool anlegen''' mit gewünschtem Replikationsfaktor
# 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 ===

{| class="wikitable"
|-
! 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 ==

{| class="wikitable"
|-
! 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''':

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

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

== Nützliche Befehle ==

{| class="wikitable"
|-
! Befehl !! Beschreibung
|-
| <code>ceph status</code> || Gesamtstatus des Clusters (Health, OSDs, PGs)
|-
| <code>ceph osd tree</code> || Baumansicht aller OSDs und ihrer Zuordnung zu Nodes
|-
| <code>ceph df</code> || Speicherverbrauch pro Pool und gesamt
|-
| <code>ceph osd pool ls detail</code> || Detaillierte Pool-Informationen
|-
| <code>ceph health detail</code> || Detaillierte Gesundheitsinformationen bei Warnungen
|-
| <code>rados bench</code> || Einfacher Performance-Benchmark
|}

== Zusammenfassung ==

{{Hinweis|'''Merkregel:''' Ceph verteilt Daten über mehrere Nodes, sodass kein einzelner Ausfall zum Datenverlust führt – und Proxmox kann das out of the box.}}

== Quellen und weiterführende Links ==

* [https://docs.ceph.com/ Offizielle Ceph-Dokumentation]
* [https://pve.proxmox.com/wiki/Deploy_Hyper-Converged_Ceph_Cluster Proxmox Wiki: Deploy Hyper-Converged Ceph Cluster]
* [https://pve.proxmox.com/pve-docs/chapter-pveceph.html Proxmox VE Ceph-Dokumentation]

Proxmox Ceph - Versionsgeschichte

Maximilian.pottgiesser: Die Seite wurde neu angelegt: „= Ceph in Proxmox VE = == Einleitung == Ceph ist ein verteiltes Storage-System, das in Proxmox VE nativ integriert ist. Es ermöglicht es, den lokalen Speich…“