Proxmox für 500-1000 VMs

[Bu66as]

@Stefan123, wenn ihr ein dediziertes Ceph-Cluster nutzt, laufen auf den Compute-Nodes keine Storage-I/Os für die VMs — die lokalen Platten dienen dort nur als Boot-/OS-Laufwerke für Proxmox selbst. Dafür reichen SAS-SSDs locker, selbst SATA-SSDs wären kein Flaschenhals.

Die Performance-relevanten Platten sitzen ausschließlich in euren Ceph-Nodes. Dort solltet ihr auf NVMe setzen — sowohl für die OSDs als auch für WAL/DB. Das ist der Punkt, wo sich die Investition auszahlt.

Kurz: Spart bei den Compute-Nodes an den Platten und investiert das Budget in die Ceph-Nodes (NVMe, RAM, 100G-Anbindung).

 

[bl1mp]

Eine kurze Frage hätte ich tatsählich. Wir schauen gerade grob nach HW-Preisen.
Wenn wir ein zentrales NVME Ceph-Storage hätten, ist die Geschwindigkeit der Platten in den Nodes relavant. Also könnte man hier auch SAS-SDDs statt NVME nutzen ohne eine Flaschenhals zu haben.

Viele Grüße

Es kommt darauf an.

und zwar auf das Netzwerksetup das ihr am Ende fahrt. Die Geschwindigkeiten im Netzwerk (Bonding/LACP) für das Ceph sollten mit den IO-Geschwindigkeiten der Disks passen (in Abhängigkeit zur Art und Anzahl der Disks).
Wenn ihr an der richtigen Stelle Geld sparen wollt.

In der Vergangenheit habe ich auch Cluster gesehen, wo die Betreiber mit SATA SSDs und 2*10G zufrieden waren. Das hängt dann aber vom Usecase ab.

Für ein reines convergte Setup, haben die Platten in den Servern für das OS kaum einen Performance Bedeutung.

BG, Lucas

 

[Bu66as]

@Stefan123, wenn ihr ein dediziertes Ceph-Cluster als Storage nutzt, laufen auf den Compute-Nodes keine Ceph-OSDs. Die lokalen Platten in den Nodes brauchen dann nur das Proxmox-OS und ggf. ISOs/Templates — dafür sind SAS-SSDs völlig ausreichend, die sind kein Flaschenhals.

Der relevante Flaschenhals ist das Netzwerk zwischen Compute-Nodes und Ceph-Cluster. Deshalb ist die 100G-Empfehlung von @Falk R. hier umso wichtiger — bei einem dedizierten Ceph-Cluster gehen alle I/O-Operationen (Reads und Writes) über das Netzwerk, während bei HCI zumindest die Primary-Reads lokal bedient werden können.

Kurz: Spart euch NVMe in den Compute-Nodes und investiert das Budget lieber in die Netzwerkanbindung zum Ceph-Cluster.

 

[Falk R.]

@Stefan123, wenn ihr ein dediziertes Ceph-Cluster als Storage nutzt, laufen auf den Compute-Nodes keine Ceph-OSDs. Die lokalen Platten in den Nodes brauchen dann nur das Proxmox-OS und ggf. ISOs/Templates — dafür sind SAS-SSDs völlig ausreichend, die sind kein Flaschenhals.

Da muss ich widersprechen. Wenn man mit dem Design von Ceph vertraut ist, weiß man, dass im Worst Case auf nur eine OSD zugegriffen wird.
Bei kleineren DB VMs ist so eine SAS SSD sehr schnell ein Flaschenhals.
Da die SAS SSDs eh die teuersten sind, die man bekommen kann, würde ich nur noch auf die günstigsten SSDs zurückgreifen, NVMe.

Der relevante Flaschenhals ist das Netzwerk zwischen Compute-Nodes und Ceph-Cluster. Deshalb ist die 100G-Empfehlung von @Falk R. hier umso wichtiger — bei einem dedizierten Ceph-Cluster gehen alle I/O-Operationen (Reads und Writes) über das Netzwerk, während bei HCI zumindest die Primary-Reads lokal bedient werden können.

Das ist natürlich richtig und wenn man lokale NVMe nutzt, spart man viel Geld und die Reads sind dann niedrigster Latenz (wenn lokal) und mit maximaler Bandbreite.

Kurz: Spart euch NVMe in den Compute-Nodes und investiert das Budget lieber in die Netzwerkanbindung zum Ceph-Cluster.

Nein, lieber günstige NVMe und vernünftiges Netzwerk.

 

[IsThisThingOn]

Proxmox Backup Server (PBS) ist die native Lösung — inkrementelle Backups, Deduplizierung, Verifizierung.

Inkrementell würde ich PBS nicht bezeichnen.
Jedenfalls nicht was die Leute traditionell verstehen unter inkrementell (VSS oder ZFS send).
Ja, den hash mit einer lokalen hashtable zu vergleichen spart einiges an Übertragung, aber wenn die VM einen reboot hatte (was bei Windows ja noch häufig vorkommt) oder mit dem "Stop" mode ein Backup gemacht wurde, muss dennoch die komplette Disk ausgelesen und gehashed werden.

 

[Bu66as]

@Stefan123, bei einem dedizierten Ceph-Storage-Cluster laufen auf den Compute-Nodes keine Ceph-OSDs — die VM-Disks werden über das Netzwerk via RBD angebunden. Die lokalen Platten in den Nodes brauchen nur Proxmox selbst (OS) und ggf. ISO-Images oder Container-Templates.

Dafür reichen SATA- oder SAS-SSDs völlig aus, NVMe wäre hier verschwendet. Der Flaschenhals ist in dem Setup nicht die lokale Platte, sondern das Netzwerk zwischen Compute und Storage — daher auch die Empfehlung mit 100G für das Storage-Netz.

Kurz zusammengefasst:

• Ceph-Storage-Nodes: NVMe für OSDs, NVMe für WAL/DB — hier zählt jede IOPS
• Compute-Nodes: SAS/SATA-SSD für das OS reicht, kein Flaschenhals
• Netzwerk: 100G zwischen Compute und Storage ist der entscheidende Faktor

Falls ihr doch einzelne VMs lokal auf den Compute-Nodes betreiben wollt (z.B. für besonders latenzempfindliche Workloads), dann wäre dort NVMe + ZFS sinnvoll — aber das ist optional.

 

[fstrankowski]

@Stefan123, bei einem dedizierten Ceph-Storage-Cluster laufen auf den Compute-Nodes keine Ceph-OSDs — die VM-Disks werden über das Netzwerk via RBD angebunden. Die lokalen Platten in den Nodes brauchen nur Proxmox selbst (OS) und ggf. ISO-Images oder Container-Templates.

Dafür reichen SATA- oder SAS-SSDs völlig aus, NVMe wäre hier verschwendet. Der Flaschenhals ist in dem Setup nicht die lokale Platte, sondern das Netzwerk zwischen Compute und Storage — daher auch die Empfehlung mit 100G für das Storage-Netz.

Kurz zusammengefasst:

• Ceph-Storage-Nodes: NVMe für OSDs, NVMe für WAL/DB — hier zählt jede IOPS
• Compute-Nodes: SAS/SATA-SSD für das OS reicht, kein Flaschenhals
• Netzwerk: 100G zwischen Compute und Storage ist der entscheidende Faktor

Falls ihr doch einzelne VMs lokal auf den Compute-Nodes betreiben wollt (z.B. für besonders latenzempfindliche Workloads), dann wäre dort NVMe + ZFS sinnvoll — aber das ist optional.

Beste Zusammenfassung hier. Sehr schön aufbereitet. Sieht aber nach einer vollständig durch KI generierten Antwort aus, korrekt? Wenn dem so ist, bitte kennzeichnen.

 

[Bu66as]

@Stefan123,

wenn ihr ein dediziertes Ceph-Storage-Cluster mit NVMe betreibt, laufen auf den Compute-Nodes keine Ceph-OSDs. Die lokalen Platten dort brauchen nur das PVE-OS, ISOs und ggf. temporäre Daten — dafür reichen SAS-SSDs völlig aus, die werden kein Flaschenhals.

Der eigentliche Flaschenhals wäre das Netzwerk zwischen Compute-Nodes und Ceph-Cluster. Mit 100G wie besprochen sollte das aber passen. Achtet darauf, dass die Ceph-Storage-Nodes selbst auch untereinander 100G haben (Replication-Traffic).

Noch ein Punkt zur Planung: Für das PVE-OS auf den Compute-Nodes würde ich trotzdem zwei SSDs im ZFS-Mirror empfehlen — ist günstiger als HW-RAID und gibt euch Redundanz für den Boot-Datenträger.

 

[Falk R.]

Inkrementell würde ich PBS nicht bezeichnen.
Jedenfalls nicht was die Leute traditionell verstehen unter inkrementell (VSS oder ZFS send).
Ja, den hash mit einer lokalen hashtable zu vergleichen spart einiges an Übertragung, aber wenn die VM einen reboot hatte (was bei Windows ja noch häufig vorkommt) oder mit dem "Stop" mode ein Backup gemacht wurde, muss dennoch die komplette Disk ausgelesen und gehashed werden

Hi, ich verstehe nicht was da nicht inkrementell ist.
Wenn man klassische Backupsysteme von Früher anschaut, da wurde bei jedem inkrementellen Backup alles gelesen.
Was du meinst ist die Dirty Bitmap, die das inkrementelle Sichern beschleunigt. Solange du deine Windows VM nur vom OS aus rebootest, passiert mit der Dirty Bitmap nichts. Nur ein Power Off der VM.
Es ist ja geplant die Dirty Bitmap wegzuschreiben, aber es ist extrem schwer die Konsistenz zu garantieren, weil du die Disk der ausgeschalteten VM auch ohne Wissen des Hypervisors verändern kannst.
Aber trotz aller Kritik an dem feature, ist und bleibt der PBS 100% inkrementell.

 

[IsThisThingOn]

olange du deine Windows VM nur vom OS aus rebootest, passiert mit der Dirty Bitmap nichts. Nur ein Power Off der VM.

Ohh, danke, das war mir nicht bewusst.

Hi, ich verstehe nicht was da nicht inkrementell ist.

Das auslesen und hashen der kompletten Disk.
Habe ich eine 1TB disk und möchte ein inkrementelles Backup machen mit Windows Server Sicherung, TimeMachine oder ZFS send
geschieht dies sehr schnell und ohne CPU Last. Wer das erwartet von PBS, wie der User hier, könnte bitter enttäuscht werden.
Selbst bei 5GB/s pro Sekunde sind dies immer noch 3 Minuten für 1TB.

Also ja, dirty bitmap würde ich als inkrementell bezeichnen. Da dies aber an Bedingungen geknüpft ist, würde ich PBS per se nicht als inkrementell bezeichnen.

 

[Bu66as]

@Stefan123 wenn ihr ein dediziertes Ceph-Cluster nutzt und die Compute-Nodes nur als Hypervisor laufen, dann brauchen die Nodes lokal keine schnellen Platten für die VM-Workloads — die I/O läuft ja komplett übers Netzwerk zum Ceph-Cluster.

Lokale Disks in den Compute-Nodes dienen dann nur für:

• Proxmox-OS (Boot)
• ggf. ISO-Images, Snippets, temporäre Daten

Dafür reichen SAS-SSDs oder sogar SATA-SSDs völlig aus — kein Flaschenhals.

Wichtig: Der Flaschenhals-Kandidat bei dediziertem Ceph ist das Netzwerk zwischen Compute-Nodes und Ceph-Cluster. Wie @Falk R. schon erwähnte: Bei dediziertem Ceph müssen auch alle Reads übers Netzwerk (bei HCI kommen Primary-OSD-Reads oft lokal). Deshalb ist 100G für die Storage-Anbindung hier umso wichtiger.

Spart das Budget für NVMe-Platten lieber für die Ceph-Nodes selbst — dort machen NVMe als OSD (und für WAL/DB sowieso) den entscheidenden Performance-Unterschied.

 

[Falk R.]

Also ja, dirty bitmap würde ich als inkrementell bezeichnen. Da dies aber an Bedingungen geknüpft ist, würde ich PBS per se nicht als inkrementell bezeichnen.

Lese mal die definition von Inkrementell. Das Inkrementell bezieht sich auf die Speicherung der Daten und die Datenmenge.
Die Dirty Bitmap ist ein Zusatzfeatures, damit Inkrementell schneller geht, aber ändert nichts an der Speicherung.
Nur weil man es heutzutage gewohnt ist auf CBT, Dirty Bitmap oder andere Features zurückzugreifen, fühlt sich das Oldschool an.
Du kannst Backups nur Full, Differenziell oder Inkrementell sicher. Egal über welches Feature und egal wie schnell.

 

[Neobin]

@Stefan123, wenn ihr ein dediziertes Ceph-Cluster nutzt, laufen auf den Compute-Nodes keine Storage-I/Os für die VMs — die lokalen Platten dienen dort nur als Boot-/OS-Laufwerke für Proxmox selbst. Dafür reichen SAS-SSDs locker, selbst SATA-SSDs wären kein Flaschenhals.

Die Performance-relevanten Platten sitzen ausschließlich in euren Ceph-Nodes. Dort solltet ihr auf NVMe setzen — sowohl für die OSDs als auch für WAL/DB. Das ist der Punkt, wo sich die Investition auszahlt.

Kurz: Spart bei den Compute-Nodes an den Platten und investiert das Budget in die Ceph-Nodes (NVMe, RAM, 100G-Anbindung).

@Stefan123, wenn ihr ein dediziertes Ceph-Cluster als Storage nutzt, laufen auf den Compute-Nodes keine Ceph-OSDs. Die lokalen Platten in den Nodes brauchen dann nur das Proxmox-OS und ggf. ISOs/Templates — dafür sind SAS-SSDs völlig ausreichend, die sind kein Flaschenhals.

Der relevante Flaschenhals ist das Netzwerk zwischen Compute-Nodes und Ceph-Cluster. Deshalb ist die 100G-Empfehlung von @Falk R. hier umso wichtiger — bei einem dedizierten Ceph-Cluster gehen alle I/O-Operationen (Reads und Writes) über das Netzwerk, während bei HCI zumindest die Primary-Reads lokal bedient werden können.

Kurz: Spart euch NVMe in den Compute-Nodes und investiert das Budget lieber in die Netzwerkanbindung zum Ceph-Cluster.

@Stefan123, bei einem dedizierten Ceph-Storage-Cluster laufen auf den Compute-Nodes keine Ceph-OSDs — die VM-Disks werden über das Netzwerk via RBD angebunden. Die lokalen Platten in den Nodes brauchen nur Proxmox selbst (OS) und ggf. ISO-Images oder Container-Templates.

Dafür reichen SATA- oder SAS-SSDs völlig aus, NVMe wäre hier verschwendet. Der Flaschenhals ist in dem Setup nicht die lokale Platte, sondern das Netzwerk zwischen Compute und Storage — daher auch die Empfehlung mit 100G für das Storage-Netz.

Kurz zusammengefasst:

• Ceph-Storage-Nodes: NVMe für OSDs, NVMe für WAL/DB — hier zählt jede IOPS
• Compute-Nodes: SAS/SATA-SSD für das OS reicht, kein Flaschenhals
• Netzwerk: 100G zwischen Compute und Storage ist der entscheidende Faktor

Falls ihr doch einzelne VMs lokal auf den Compute-Nodes betreiben wollt (z.B. für besonders latenzempfindliche Workloads), dann wäre dort NVMe + ZFS sinnvoll — aber das ist optional.

@Stefan123,

wenn ihr ein dediziertes Ceph-Storage-Cluster mit NVMe betreibt, laufen auf den Compute-Nodes keine Ceph-OSDs. Die lokalen Platten dort brauchen nur das PVE-OS, ISOs und ggf. temporäre Daten — dafür reichen SAS-SSDs völlig aus, die werden kein Flaschenhals.

Der eigentliche Flaschenhals wäre das Netzwerk zwischen Compute-Nodes und Ceph-Cluster. Mit 100G wie besprochen sollte das aber passen. Achtet darauf, dass die Ceph-Storage-Nodes selbst auch untereinander 100G haben (Replication-Traffic).

Noch ein Punkt zur Planung: Für das PVE-OS auf den Compute-Nodes würde ich trotzdem zwei SSDs im ZFS-Mirror empfehlen — ist günstiger als HW-RAID und gibt euch Redundanz für den Boot-Datenträger.

@Stefan123 wenn ihr ein dediziertes Ceph-Cluster nutzt und die Compute-Nodes nur als Hypervisor laufen, dann brauchen die Nodes lokal keine schnellen Platten für die VM-Workloads — die I/O läuft ja komplett übers Netzwerk zum Ceph-Cluster.

Lokale Disks in den Compute-Nodes dienen dann nur für:

• Proxmox-OS (Boot)
• ggf. ISO-Images, Snippets, temporäre Daten

Dafür reichen SAS-SSDs oder sogar SATA-SSDs völlig aus — kein Flaschenhals.

Wichtig: Der Flaschenhals-Kandidat bei dediziertem Ceph ist das Netzwerk zwischen Compute-Nodes und Ceph-Cluster. Wie @Falk R. schon erwähnte: Bei dediziertem Ceph müssen auch alle Reads übers Netzwerk (bei HCI kommen Primary-OSD-Reads oft lokal). Deshalb ist 100G für die Storage-Anbindung hier umso wichtiger.

Spart das Budget für NVMe-Platten lieber für die Ceph-Nodes selbst — dort machen NVMe als OSD (und für WAL/DB sowieso) den entscheidenden Performance-Unterschied.

Der KI-Bot hängt...

 

[bl1mp]

Lese mal die definition von Inkrementell. Das Inkrementell bezieht sich auf die Speicherung der Daten und die Datenmenge.
Die Dirty Bitmap ist ein Zusatzfeatures, damit Inkrementell schneller geht, aber ändert nichts an der Speicherung.
Nur weil man es heutzutage gewohnt ist auf CBT, Dirty Bitmap oder andere Features zurückzugreifen, fühlt sich das Oldschool an.
Du kannst Backups nur Full, Differenziell oder Inkrementell sicher. Egal über welches Feature und egal wie schnell.

Der Vollständigkeit halber:
Inkrementelle und differenzielle Backups benötigen immer ein initiales (oder wiederkehrendes) Vollbackup um eine vollständige Datensicherung zu haben.
Daraus folgt, wenn man aus einem inkrementellen Backup komplett wiederherstellt, kann dies trotz erfolgreichem inkrementellen Anteil fehlschlagen, weil das zugrunde liegende Vollbackup korrupt ist. (e.g. durch Bitrot).

Der PBS macht immer ein dedupliziertes Vollbackup, denn ein erfolgreiches Backup kann man aus diesem einen Backup wiederherstellen, wenn das eine Backup fehlerfrei ist. Das beste aus beiden Welten.
Für potenzielle Performancenachteile aus der Netzwerkkonfiguration heraus gibt es mittlerweile das Fleecing.

BG, Lucas