Ceph mit Proxmox aufbauen: MON/OSD/MGR‑Layout, Placement‑Groups und Performance‑Troubleshooting

Ceph mit Proxmox ist eine verbreitete Kombination in virtualisierten Infrastrukturen. In diesem Beitrag beschreibe ich praxisnah, wie Sie MON/OSD/MGR planen, Placement‑Groups (PGs) richtig dimensionieren und Performance‑Probleme systematisch diagnostizieren und beheben. Das Fokus‑Keyword Ceph mit Proxmox steht bewusst früh: die Integration beeinflusst Betrieb, Monitoring, Migration und SLA‑Einhaltung.

Warum Architekturplanung bei Ceph wichtig ist

Bevor Sie Ceph in Proxmox integrieren, sollten Sie die Verantwortung der Komponenten verstehen. Kurz zusammengefasst: MONs (Monitore) verwalten Cluster‑Quorum und Konfiguration; OSDs (Object Storage Daemon) speichern die Daten und führen Replikation und Scrubbing aus; MGRs (Manager) liefern Dashboard, API und Metriken. Diese Aufgabentrennung bestimmt Hardware‑, Netzwerk‑ und Betriebsentscheidungen — und damit Performance und Ausfallsicherheit.

Grundregeln für MON/OSD/MGR‑Layout

Die Verteilung von MONs, OSDs und MGRs beeinflusst Stabilität und Wartbarkeit. Basisregeln:

• MONs: Immer eine ungerade Anzahl (mindestens 3) für Quorum‑Resilienz; MONs sind leichtgewichtig, brauchen aber stabilen Netzwerkzugang.
• OSDs: Verteilen Sie OSDs über Hosts und Failure‑Domains (Host, Rack); OSDs sind I/O‑kritisch und bilden den Engpass im System.
• MGRs: Mindestens zwei Manager‑Instanzen für Redundanz beim Dashboard und den Exportern; Ausfall eines MGR wirkt sich primär auf Observability aus, nicht auf Konsistenz.

Empfehlung für typische Cluster

Für kleine bis mittelgroße Proxmox‑Installationen (6–20 Knoten) ist eine mögliche Konfiguration: 3 MONs auf separaten Hosts, 2 MGRs verteilt, und OSDs so verteilen, dass mindestens drei OSDs pro Failure‑Domain vorhanden sind. Vermeiden Sie MON/MGR‑Co‑Lokation mit allen OSDs eines Racks, um die Blast‑Radius zu reduzieren.

Ceph mit Proxmox: Realistische Performance‑Tuning‑Maßnahmen

Performance‑Tuning beginnt mit Messung. Ceph‑Engpässe lassen sich nur mit Metriken, I/O‑Profilen und kontrollierten Tests verstehen. Typische Bereiche sind Netzwerk, OSD‑Device, CPU/Memory auf den OSDs und die PG‑Konfiguration (Placement‑Groups, logische Verteilungsgruppen).

Wichtige Ceph‑Konfigurationen und ihre Wirkung

• osd_memory_target (Ceph): Steuerung des RAM‑Footprints der OSD‑Cache‑Strukturen — zu niedrig → Performanceeinbruch, zu hoch → Memory‑Pressure. Werte abhängig von OSD‑RAM und PG‑Anzahl.
• osd_recovery_max_active / osd_recovery_op_priority: Drosseln die parallelen Recovery‑Tasks, reduzieren kurzfristig Backfill‑Load, verlängern aber Recovery‑Zeit.
• osd_max_backfills: Begrenzung paralleler Backfills pro OSD; sinnvoll bei Netzwerk‑Sättigung.

Empfehlungen (konservativ)

Beginnen Sie mit konservativen Defaults und justieren Sie schrittweise. Beispielwerte, die Sie testen sollten:

# Beispiel: vorsichtigere Recovery‑Limits setzen
ceph config set osd osd_recovery_max_active 2
ceph config set osd osd_max_backfills 1
# Memory‑Target nach OSD‑RAM anpassen (Beispiel 8GB RAM)
ceph config set osd osd_memory_target 5368709120 # 5GB

Warum: Diese Einstellungen reduzieren den gleichzeitigen I/O‑Druck auf Netzwerk und CPU, verhindern kurzfristige Latenzspitzen und sind reversibel. Testen und dokumentieren Sie jede Änderung.

Placement‑Groups (PGs): Konzept, Berechnung und pg_autoscaler

Placement‑Groups bündeln Objekte und sind die atomare Einheit, die CRUSH an OSDs verteilt. Die PG‑Anzahl beeinflusst Datenverteilung, Rebalancing‑Größe und OSD‑Memory‑Footprint.

Berechnungsansatz und Praxisbeispiel

Als Faustregel gelten 50–200 PGs pro OSD; eine vereinfachte Formel:

target_pgs = (osd_count * pgs_per_osd) / replication_size

Beispiel: 12 OSDs, repl_size=3, pgs_per_osd=100 → target_pgs = (12*100)/3 = 400 → wählen Sie 256 oder 512 (Potenz von 2 wird oft empfohlen). Moderne Ceph‑Versionen bieten pg_autoscaler, das PG‑Zahlen schrittweise anpasst — prüfen Sie Kompatibilität mit Ihrer Proxmox‑Version.

pg_autoscaler: Vor‑ und Nachteile

pg_autoscaler automatisiert Anpassungen und reduziert menschliche Fehler. Nachteile: In älteren Versionen kann es zu unerwünschtem Rebalancing kommen, daher nur aktivieren, wenn Sie die Version und Verhalten geprüft haben.

CRUSH‑Map, Failure Domains und Device Classes

Die CRUSH‑Map bestimmt physische Platzierung. Definieren Sie Failure‑Domains (z. B. host, rack) und Device‑Classes (ssd/hdd) klar, damit Policies (z. B. separates Placement für SSD‑Tier) greifen. Falsche CRUSH‑Map führt zu ungleichmäßiger Verteilung und erhöhtem Datenverkehr beim Ausfall.

Scrubbing, Backfilling und Recovery: Unterschiede und Betriebsregeln

Scrubbing (Regelprüfung der Datenintegrität) ist eine geplante Aktivität; Deep‑Scrub prüft Inhalte intensiver. Backfilling beschreibt das Kopieren von Daten nach Hinzufügen/Entfernen von OSDs. Recovery ist die synchronisierte Wiederherstellung nach Ausfällen. Diese Prozesse beanspruchen I/O und Netzwerk unterschiedlich — planen Sie Maintenance‑Fenster und setzen Sie Limits auf parallele Tasks.

Performance‑Troubleshooting: Systematischer Incident‑Runbook

Bei Performance‑Vorfall folgen Sie einem strukturierten Vorgehen: Erst messen, dann intervenieren, nie blind global konfigurieren.

Sofortmaßnahmen (erste 10 Minuten)

1. Cluster‑Übersicht prüfen:

ceph -s
ceph osd df tree
ceph pg stat
ceph osd perf

2. Netzwerkdaten und Switch‑Statistiken prüfen (MTU, Errors, Drops).
3. OSD‑I/O prüfen: iostat, iotop, blktrace.
4. Clients beobachten (Proxmox VM‑IO per iostat in den VMs).

Gängige Interventionen und Befehle

Wenn Backfill die Ursache ist, drosseln Sie Recovery/Backfill:

# Temporär OSD Noout (Achtung: nur bei geplanter Wartung)
ceph osd set noout
# Drosseln
ceph config set osd osd_recovery_max_active 1
ceph config set osd osd_max_backfills 1
# Überwachen
ceph -w

Wenn OSD‑CPU/Memory der Flaschenhals ist, prüfen Sie PG‑Zahl und osd_memory_target. Reduzieren Sie PGs nur schrittweise und beobachten OSD‑Stabilität.

Konkreter Runbook‑Ablauf für kritische Latzenzspitzen

1. Identifizieren: ceph osd perf, ceph pg dump | grep stuck/degraded.
2. Isolieren: temporär Clients reduzieren (QoS auf Proxmox), set noout falls Wartung.
3. Drosseln: recovery/ backfill Werte wie oben setzen.
4. Ursache suchen: Switch counters, ethtool -S, iostat, dmesg für Device‑Errors.
5. Schrittweise Rücksetzen: wenn Last sinkt, Werte zurücknehmen und Monitoring beobachten.

Tests und Validierung: fio als Werkzeug

Validieren Sie Storage‑Profile mit fio (I/O‑Pattern‑Simulation). Ein Beispiel für 4k Random R/W Mix:

fio --name=randrw --ioengine=libaio --direct=1 --rw=randrw --rwmixread=70 
    --bs=4k --numjobs=8 --size=1G --runtime=300 --group_reporting

Führen Sie solche Tests isoliert auf einer Test‑VM oder direkt auf OSD‑Devices durch; interpretieren Sie IOPS und Latenz in Bezug auf erwartete Workloads der Proxmox‑VMs.

OSD Replacement: Sicherer Ablauf und Rückfall

Beim Austausch eines OSD dokumentieren Sie Status vorab, setzen OSD out, überwachen Recovery bis zur Stabilität und erstellen Backups der CRUSH‑Map und MON‑State. Beispielbefehle:

# OSD aus dem Cluster nehmen
ceph osd out 
# Überwachen
ceph -w
# Nach Austausch neu anlegen (Beispiel ceph-volume)
sudo ceph-volume lvm create --data /dev/sdb

Rückfallstrategie: Wenn Replace fehlschlägt, können Sie das alte Device wieder temporär anbringen und den OSD re‑attachen oder die Weight‑Scale anpassen, um unkontrolliertes Rebalancing zu verhindern.

Metriken, Alerts und Observability

MGR‑Module liefern Prometheus‑Metriken. Prioritäre Alerts sollten sein: ceph_health != OK, hohe recovery/backfill‑Raten, OSD‑latency Anstieg, viele PGs in STATE ‚active+undersized‘ oder ‚degraded‘. Dashboards helfen, Trendverhalten zu sehen und nicht nur Einzelereignisse.

Praktische Betriebsregeln und typische Stolperfallen

• Setzen Sie MTU/Jumbo‑Frames nur nach Ende‑zu‑Ende‑Test; inkonsistente MTUs erzeugen Fragmentierung und Drops.
• Vermeiden Sie RAID‑Mode bei Storage‑Controllern für OSDs; HBA/Pass‑through reduziert unerwartete Latenzen.
• Änderungen an PG‑Zahlen oder CRUSH‑Map immer gestaffelt und mit Monitoring‑Sprints begleiten.
• Planen Sie Scrub‑ und Deep‑Scrub‑Fenster in Zeiten mit geringem I/O.

Checkliste vor Produktivsetzung

1. Proxmox‑ und Ceph‑Versionskompatibilität geprüft.
2. Public/Cluster Netz konfiguriert, MTU geprüft.
3. MON/MGR‑Anzahl und Verteilung gesetzt (mind. 3 MONs, 2 MGRs).
4. OSD‑Sizing: Device‑Klassen, WAL/DB‑Devices geplant.
5. PG‑Planung: Ziel‑PGs berechnet und in Testumgebung validiert.
6. Backups: MON/MGR/CRUSH‑Map‑Backup Workflow etabliert.
7. Monitoring: MGR‑Module, Prometheus Exporter und Alerting eingerichtet.
8. Rollback‑Pläne dokumentiert und getestet (OSD Replace, MON‑Restore).

Fazit: Operationale Disziplin statt magischer Einstellungen

Ceph mit Proxmox bietet hohe Skalierbarkeit und gute Integrationsmöglichkeiten in virtualisierte Umgebungen — vorausgesetzt, Architektur, Netzwerk und PG‑Planung sind abgestimmt. Beginnen Sie konservativ, messen Sie Effekte und optimieren Sie schrittweise. Bei Performance‑Problemen hilft ein strukturierter Schichten‑Check (Hardware → Kernel → Netzwerk → Ceph → Client) und gezieltes Drosseln von Recovery/Backfill. Dokumentation, Monitoring und getestete Rückfallstrategien reduzieren Betriebsrisiken und machen das System vorhersehbar.

Nutzen Sie die Checkliste als Betriebsdokument und ergänzen Sie interne Links zu tiefergehenden How‑tos (z. B. Proxmox‑Upgrades, ZFS‑Design), um ein vollständiges Betriebsbuch zu erstellen.

Betriebs- und Integrationsaspekte, die oft übersehen werden

Bei Ceph‑Deployments in Proxmox entscheidet nicht nur die reine Cluster‑Konfiguration über den Erfolg, sondern auch, wie Sie den Speicher in die Betriebsprozesse, Backups und das Change‑Management einbinden. Nachfolgend praxisnahe Aspekte, die in Projekten oft zu späteren Überraschungen führen, sowie konkrete Empfehlungen.

Backup‑ und Snapshot‑Strategie für VMs

RBD‑Snapshots sind schnell, ersetzen aber kein systematisches Backup. Nutzen Sie Snapshots für kurzfristige Konsistenzpunkte (z. B. vor Patches), aber exportieren Sie regelmäßige Offsite‑Backups (z. B. Export der VM‑Daten oder Nutzung eines Object‑Backends wie RGW/S3). Achten Sie darauf, dass Snapshots selbst I/O‑Last erzeugen und bei vielen Snapshots zu Performanceeinbrüchen führen können. Planen Sie daher ein Löschintervall und Automatisierung zur Snapshot‑Bereinigung.

Koordination mit Proxmox‑Funktionen

Stellen Sie sicher, dass Proxmox Storage Pools (RBD) korrekt getaggt sind und Sie Admission‑Kontrollen für VM‑Platzierung verwenden, um Hot‑OSD‑Hosts zu vermeiden. Legen Sie Regeln fest, die verhindern, dass zu viele I/O‑schwere VMs auf OSD‑reichen Hosts zusammenlaufen — das reduziert Hot‑Spot‑Risiken.

Sicherheits‑ und Compliance‑Layer

Aktivieren Sie Transportverschlüsselung zwischen Ceph‑Diensten (mTLS) und überlegen Sie Verschlüsselung der Devices (dmcrypt) bei sensiblen Daten. Achten Sie auf Schlüsselmanagement: Schlüssel sollten nicht nur lokal liegen, sondern in Ihrer PKI/externen Geheimnisverwaltung (z. B. HashiCorp Vault) referenziert werden. Dokumentieren Sie den Entschlüsselungs‑ und Recovery‑Prozess, damit sich Betriebsmitarbeitende in Notfällen zurechtfinden.

Upgrade‑ und Rollback‑Playbook

Ein formelles Upgrade‑Playbook reduziert Risiken. Grundprinzipien: rollenweise Upgrades, Health‑Checks nach jeder Stufe, konservative Timeouts und eine definierte Rückroll‑Prozedur. Testen Sie das Upgrade auf einer Replikationsumgebung und halten Sie Backups der MON‑ und MGR‑State‑Daten bereit.

# Beispiel: Health‑Check vor Upgrade (Kurzversion)
ceph status --format=json | jq '.health'
ceph osd tree --format=json | jq '.nodes | length'

Automatisierung und Orchestrierung

Nutzen Sie Orchestrierungstools (cephadm, Ansible) für wiederholbare Deployments und dokumentierte Konfigurationen. Bewahren Sie Ceph‑Konfigurationsänderungen in einem Git‑Repository und verknüpfen Sie sie mit Ihrem Change‑Control‑System. Automatisierte Tests (Smoke‑Checks nach Konfigurationsänderungen) vermeiden ungeplante Nebenwirkungen in produktiven Pools.

Multi‑Site, Replikation und DR‑Szenarien

Wenn georedundante Anforderungen bestehen, planen Sie für RGW‑Bucket‑Replikation oder Ceph‑RADOS‑Mirroring. Solche Setups verändern Latenz‑ und Bandbreitenanforderungen drastisch; testen Sie Replikations‑Resilienz bei simulierten Netzwerkausfällen und quantifizieren Sie die notwendigen Bandbreiten‑SLA für Recovery‑Fenster.

Observability: sinnvolle Schwellenwerte und Alerts

Ein Alert ist nur so gut wie seine Aktion. Definieren Sie Verantwortliche und automatische Runbooks zu Alerts wie steigender OSD‑Latency, erhöhte Backfill‑Rate oder PG‑Degradation. Beispiele für pragmatische Schwellenwerte:

• latency p95 > X ms über Y Minuten → Ticket + Ausrollen drosselnder Recovery‑Parameter
• mehrere OSDs offline gleichzeitig → sofortige Eskalation
• PGs in degraded/stuck > 0 für Z Minuten → Wartungsmodus prüfen

Organisatorische Empfehlung

Schaffen Sie ein kleines Betriebs‑Playbook (2–3 Seiten) mit Checklisten für: tägliche Health‑Checks, Vorgehen bei OSD‑Austausch, Upgrade‑Sequenz und Rollback‑Schritten. Kombinieren Sie dieses Playbook mit technischen Automatisierungen und regelmäßigen Chaos‑Tests (kontrollierte Fehler) — so stellen Sie sicher, dass Ihre Teams Vertrautheit mit Recovery‑Abläufen erlangen und die Technologie stabil in den Produktionsalltag integriert wird.

Für dieses Thema sind auch Mon Osd Mgr und Ceph Performance wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.