Türkei (Türkisch)
Germany (German)
Worldwide (English)
Proxmox nennt mindestens 2 GB RAM für OS und Dienste plus Gast-RAM. ZFS oder Ceph benötigen zusätzlichen Speicher.
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Proxmox-VE-Server anhand VM-Anzahl, vCPU, RAM, ZFS, NVMe, 1/10-Gbps-Netzwerk, Backup und HA dimensionieren.
Proxmox nennt mindestens 2 GB RAM für OS und Dienste plus Gast-RAM. ZFS oder Ceph benötigen zusätzlichen Speicher.
Aktuelle Proxmox-Dokumentation empfiehlt direkten Disk-Zugriff für ZFS und unterstützt ZFS nicht auf Hardware-RAID.
Zehn leere Linux-VMs können weniger Ressourcen benötigen als drei intensive DB-/ERP-VMs. Peak-CPU, Working-Set-RAM, IOPS und Netzwerk pro Gast bestimmen.
Headroom für den Host einplanen. Gesamten physischen RAM an VMs zu vergeben kann ZFS ARC, Host-Dienste, Backups und Migrationen unter Druck setzen.
Viele Kerne erhöhen parallele VM-Kapazität, aber WordPress, Gameserver und ERP können stark von Pro-Core-Leistung abhängen. Alte 24 Kerne sind nicht automatisch besser als moderne 12.
vCPU-Overcommit ist möglich, bei CPU-intensiven Gästen erhöht aggressives Overcommit aber Scheduling-Latenz. Für kritische Workloads konservativer planen.
Praktisch: Host-Reserve + aktive Gast-Working-Sets + ZFS/Ceph + Wachstumsreserve. 2 GB Minimum ist nur Basis; Produktion mit ZFS benötigt deutlich mehr.
Memory Ballooning hilft, ersetzt aber kein Sizing. Reale Working Sets besonders bei Datenbanken und Java/.NET messen.
ZFS erwartet direkten Disk-Zugriff. Proxmox unterstützt ZFS auf Hardware-RAID nicht und warnt vor Datenverlust. HBA/JBOD oder direkter Zugriff ist vorzuziehen.
Für VM-Storage sind Enterprise-SSD/NVMe, Power-Loss-Protection und Endurance wichtig. Random IOPS, Latenz und Schreibhaltbarkeit statt nur MB/s bewerten.
Für einen Einzelnode kann 1 Gbps reichen. Live Migration, Replikation, Ceph, Backups und hoher Traffic profitieren schnell von 10 Gbps. Management, Storage und Public Traffic möglichst trennen.
Ein 3-Node-HA-Cluster löst ein anderes Problem als ein starker Einzelnode. HA benötigt Quorum, Storage und Migration; Einzelnode braucht starkes Backup und schnelle Ersatz-/Restore-Planung.
Lab: 6-8 Kerne, 32 GB RAM, 2× NVMe Mirror. Kleine Produktion: 12-16 starke Kerne, 64-128 GB ECC, Enterprise-NVMe-Mirror und separates Backup. Dichte Virtualisierung: 24+ Kerne, 128-256+ GB ECC, mehrere NVMe, 10 Gbps. Nur Startpunkte.
lscpufree -hzpool statuszpool iostat -v 1pvesm statusip -br link| Ebene | Frage | Engpass-Signal |
|---|---|---|
| CPU | Wie viele vCPU sind im Peak aktiv? | Scheduling-Latenz, hohe CPU |
| RAM | Gast-Working-Set + Host-Reserve? | Swap/Ballooning/Memory Pressure |
| Storage | Random IOPS und p99-Latenz? | IO wait, hohe VM-Disk-Latenz |
| Netzwerk | Migration-/Backup-Traffic? | Langsame Migration/Backups |
Mindestanforderungen nicht mit Produktionskapazität verwechseln. Peak-Workload, Backup, Wachstumsreserve, Ressourcenpolitik und Recovery-Plan gemeinsam bewerten.
Offiziell 2 GB für Host-Dienste plus Gast- und ZFS/Ceph-RAM. Das Minimum ist kein Produktionsziel.
Bei ZFS nicht als RAID-Schicht; Proxmox bevorzugt direkten Disk-Zugriff/HBA.
CPU, RAM, Storage, Netzwerk und Betrieb gemeinsam bewerten; ein größeres Paket ohne Engpassanalyse ist selten eine dauerhafte Lösung.