Proxmox muss nicht immer hyperkonvergent sein.
Ceph ist stark, aber nicht für jedes Umfeld die beste Antwort. In klassischen 3-Tier-Architekturen bleiben Compute, Storage und Netzwerk bewusst getrennt. Das passt gut, wenn bereits SAN-Erfahrung vorhanden ist, wenn Performance vorhersehbar sein soll oder wenn ein Storage-System wie IBM FlashSystem standalone oder im Policy Based HA eingesetzt wird. Wir planen solche Proxmox-Setups ohne Ceph-Dogma, mit Blick auf Betrieb, Wartung und echte Ausfallszenarien.
Compute-Cluster
Wir planen Proxmox-Nodes als reine Compute-Schicht mit klaren Ressourcenreserven, HA-Gruppen, Wartungsfenstern und sauberer Trennung von Management-, VM- und Storage-Traffic.
Shared Storage
Externer Storage kann über Fibre Channel, iSCSI, NFS oder andere passende Verfahren angebunden werden. Entscheidend ist nicht der Produktname, sondern ein Pfadmodell, das Ausfälle und Wartung verkraftet.
IBM FlashSystem
IBM FlashSystem passt sehr gut in solche Architekturen, gerade standalone oder mit Policy Based HA. Wir betrachten dabei LUN-Layout, Host-Zuordnung, Copy Services, Performance und den Betrieb aus Proxmox-Sicht.
Storage- und Netzwerkgrenzen
3-Tier funktioniert nur, wenn Zuständigkeiten und Fehlerbereiche klar sind. Wir definieren, welche Schicht für HA, Replikation, Backup, Snapshots und Monitoring verantwortlich ist.
Wartbarkeit
Controller-Updates, Switch-Wartung, Host-Reboots und Pfadtests müssen planbar sein. Wir bauen Abläufe, mit denen Wartung nicht jedes Mal zum Risiko für produktive VMs wird.
Backup und Restore
Shared Storage ersetzt keine Backups. Wir planen Proxmox Backup Server, Storage-Snapshots und Restore-Prozesse so, dass klar ist, welcher Mechanismus welches Risiko abdeckt.
Wann 3-Tier sinnvoller als Ceph ist
Gibt es bereits SAN-Kompetenz?
Wenn ein Team Fibre Channel, iSCSI, Storage-Zoning und Multipath sicher betreibt, kann 3-Tier für Proxmox sehr stabil und nachvollziehbar sein.
Wie kritisch ist Storage-Latenz?
Für bestimmte Datenbank-, ERP- oder Windows-Workloads kann ein dediziertes Storage-System berechenbarer sein als ein kleiner oder falsch dimensionierter Ceph-Cluster.
Wer besitzt die Hochverfügbarkeit?
HA kann in Proxmox, im Storage, im Netzwerk oder in der Applikation stattfinden. Wir trennen diese Ebenen, damit nicht mehrere Systeme denselben Fehler unterschiedlich behandeln.
Was passiert bei Storage-Wartung?
Controller-Failover, Firmware-Updates, Pfadverlust und Switch-Wartung müssen getestet werden. Ein 3-Tier-Design ist erst gut, wenn diese Szenarien nicht nur theoretisch funktionieren.
3-Tier sauber planen
Bestand aufnehmen
Wir prüfen Hosts, Switches, Storage-Systeme, Fabrics, IP-Netze, Workloads, Backup-Ziele und vorhandene Betriebsprozesse.
Zielarchitektur definieren
Compute, Storage, Netzwerk, HA, Backup, Monitoring und Wartung werden als getrennte, aber zusammenhängende Ebenen geplant.
Anbindung validieren
LUNs, Pfade, Multipath, Failover, Performance und Proxmox-Storage-Konfiguration werden vor produktiver Nutzung getestet.
Betrieb übergeben
Am Ende stehen Doku, Runbooks, Wartungsabläufe und klare Checks für Host-, Switch- und Storage-Arbeiten.
Technologien
Weitere Detailseiten
Cluster-Planung
Quorum, Corosync, Netzwerk, HA und Betriebsmodell.
Ceph-Storage
OSD-Design, CRUSH, Recovery-Verhalten und Kapazität.
VMware-Migration
Bestandsaufnahme, Testmigration, Cutover und Fallback.
Proxmox Backup Server
Datastores, Retention, Offsite-Sync und Restore-Tests.
Automatisierung
API, Ansible, OpenTofu, Templates und cloud-init.
Monitoring & Wartung
Health Checks, Updates, Firmware und Kapazitätstrends.
Multipath-Architekturen
Fibre Channel, iSCSI, ALUA, multipathd und Failover-Tests.
Proxmox Workshops
Beratung, UI-Durchgang, Betriebspraxis und Team-Enablement.
3-Tier-Proxmox-Architektur planen?
Wir bewerten, ob Ceph, 3-Tier oder eine Mischform zu deiner Umgebung passt und planen die Storage-Anbindung pragmatisch.
Proxmox-Projekt besprechen