HW-Empfehlung und Sizing für Proxmox-Cluster für KMU

[felix.steinbeis]

Hallo zusammen,

für ein kleines Unternehmen mit 6 Mitarbeitern plane ich einen 2-Node Proxmox Cluster + QDevice.
Auf den zwei Nodes sollen jeweils 4-6 VMs laufen, gegenseitig repliziert und im Fehlerfall soll ein Node in der Lage sein, alle 8-12 VMs übergangsweise betreiben zu können. Die VMs sind allesamt nicht besonders lastintensiv. Im Wesentlichen sind es Windows DC und Windows Terminal Server, Fileserver, Mailserver und kaufmännische Software.

Als Fileserver plane ich TrueNAS, ggf. mit Disk Passthrough, weiß aber noch nicht, welche Auswirkungen das auf HA und Replizierung hat.

Als Dateisystem plane ich ZFS, daher folgende Überlegung:

Bord: Supermicro Mainboard H12SSL-NT
CPU: AMD EPYC 7313P (3,00 GHz, 16-Core, 128 MB)
RAM: 128 GB (4x 32GB) ECC Reg
HDD: 2 x 4 TB, SATA-3, ZFS Mirror für Proxmox+VMs, + 1 HDD Spare Drive
HDD: 2 x 8 TB, SATA-3, ZFS Mirror für TrueNAS mit Disk Passthrough + 1 HDD Spare Drive
Onboard NIC: 2 x 10 Gbit/s on Board LAN (Broadcom BCM57416) für Proxmox Cluster
Zusatz NIC: 4 x 10 Gbit/s Netzwerkkarte (Broadcom BCM5719-4P) für Management, LAN, ...

Wie ist Eure Meinung? Was würdet ihr ggf. ändern?
Passt ZFS Mirror mit HDDs? (ggf. mehr RAM oder SSD Cache)?
Wie verhält es sich mit TrueNAS und Disk Passthrough in Kombination mit Cluster und HA?

Ziel ist ein System, was insbesondere stabil läuft und fehlerredundant ist. Das Ganze mit einer soliden Geschwindigkeit, aber es muss kein hoch-performantes System sein. Das LAN ist bisher nur 100 MBit/s, tlw. 1 GB/s.

Ich freue mich über jede Hilfe.

Vielen Dank und viele Grüße
Felix

 

[UdoB]

Passt ZFS Mirror mit HDDs? (ggf. mehr RAM oder SSD Cache)?

Weder ein (Lese-) Cache noch ein SLOG wird dich mit Blechplatten glücklich werden lassen. (Ja, das ist ein Pauschalurteil.) Und steck soviel Ram hinein, wie du kriegen kannst - wie deine 128 GiB verwendet werden, hast du ja nicht dargelegt.

Ich empfehle für Blechplatten dringend ein Mirrored "Special Device" einzubauen, bestehend aus Enterprise SSDs. Such hier mal im Forum, das Konzept wurde vielfach besprochen.

Viel Erfolg!

 

[Johannes S]

Bei TrueNAS wird dazu geraten, die Datenplatten nicht virtualisiert oder per Passthrough, sondern mit einen durchgereichten PCIE-Storage-Adapter zu betreiben: https://forum.proxmox.com/threads/best-approach-for-a-truenas-vm.121527/

Das beißt sich aber natürlich mit dem Anspruch dass die NAS-VM von einen auf den anderen Knoten repliziert werden kann.

Was allerdings stattdessen gemacht werden könnte:

Jeder Knoten kriegt einen PCIE-Storage-Adapter mit angeschloßenen Festplatten für eine NAS-VM, auf beiden Knoten wird eine NAS-VM auf diesen Platten betrieben. Diese VMs tauschen ihre Daten per Replikation (funktioniert wie die in proxmox auf ZFS-Basis) untereinander aus: https://www.truenas.com/docs/scale/...rotection/replication/remotereplicationscale/

Dann muss man sich noch ein Konzept überlegen, wie man bei einen Ausfall den Benutzern plus Anwendungen klar macht, dass sie die andere VM als Datengrab nutzen müssen.
Zur Performance: Wenn du deine Netzwerkinfrastruktur so planst, dass du die vollen 10 Gbit deiner Netzwerkkarten nutzen kannst, sollte das passen. Bei Clustern wird aber empfohlen, die Datenreplikation und Cluster-Kommunikation auf je eigenen Netzwerken laufen zu lassen, ggf. noch mit einer extraverbindung für Redundanz:
https://pve.proxmox.com/wiki/Cluster_Manager

Ich verstehe doch richtig, dass du pro Server sechs Netzwerkports hast? Damit sollte sich das schmerzfrei implementieren lassen.
Generell werden bei dir eher die Festplatten der Flaschenhals sein, die VMs sollten schon auf SSDs liegen, für Daten (je nach Usecase) gehen die HDDs natürlich klar.

Was ich generell noch in deinen Konzept vermisse: Wie du die VMs und Daten backuppen möchtest. Bei Proxmox bietet sich natürlich die native Lösung (Proxmox Backup Server) an, die sollte dann aber auf einen eigenen physikalischen Server laufen. Dieser kann dann auch als qdevice fungieren und muss dafür auch nicht im Cluster-Netzwerk sein. Was hast du denn aktuell als qdevice geplant?
Zusätzlich sollte man diese Backups auf eine andere Location übertragen, dafür bietet sich ein Vserver mit installierten PBS an oder ein PBS-Clouddienst wie Tuxis: https://www.tuxis.nl/de/proxmox-backup-server/
Damit ist allerdings noch nichts über anwendungsspezifische Besonderheiten gesagt, SQL-Datenbanken wollen ja üblicherweise noch ihre eigene Sicherung haben.

Aufgrund des internen Aufbaus der Backups (viele kleine Dateien) sollten dort ebenfalls SSDs zum Einsatz kommen.
Als Kompromiss bietet sich das von UdoB erwähnte mirror special device auf SSDs an.
Dass die Platten (ob SSD, NVME oder HDD) keine Consumerhardware sind, setze ich mal als gegeben voraus, bei RAM hast du ja schon ECC eingeplant.

 

[felix.steinbeis]

Weder ein (Lese-) Cache noch ein SLOG wird dich mit Blechplatten glücklich werden lassen. (Ja, das ist ein Pauschalurteil.) Und steck soviel Ram hinein, wie du kriegen kannst - wie deine 128 GiB verwendet werden, hast du ja nicht dargelegt.

Ich empfehle für Blechplatten dringend ein Mirrored "Special Device" einzubauen, bestehend aus Enterprise SSDs. Such hier mal im Forum, das Konzept wurde vielfach besprochen.

Viel Erfolg!

Vielen Dank für Deine Rückmeldung. Mit "Special Device" schaue ich mir an.
Die 128 GB kann ich natürlich auch erweitern. Plan ist, 50% VMs und 50% ZFS.

Aktuell nutzen wir zwei Server mit Windows Hyper-V, RAID 5 und o.g. VMs. Beide Server replizieren sich gegenseitig. Ähnlich plane ich es mit Proxmox. Also anstelle von Windows Server+HyperV für VMs, zukünftig Proxmox.

Bisher haben wir 10k-SAS-Platten und keine Probleme.

Würde sich das durch Proxmox (ZFS Mirror, SATA-3) zu Windows (NTFS über SAS-Raid-Controller im Raid5) von der Performance negativ verändern?
Ich versuche abzuschätzen, ob HDDs mit Proxmox und ZFS gar nicht produktiv geeignet/sinnvoll ist, oder sich vergleichbar ist, mit dem was wir jetzt haben.

Viele Grüße
Felix

 

[UdoB]

Würde sich das durch Proxmox (ZFS Mirror, SATA-3) zu Windows (NTFS über SAS-Raid-Controller im Raid5) von der Performance negativ verändern?
Ich versuche abzuschätzen, ob HDDs mit Proxmox und ZFS gar nicht produktiv geeignet/sinnvoll ist, oder sich vergleichbar ist, mit dem was wir jetzt haben.

Wenn man einfach nur "hallo" in einer Textdatei abspeichert, benötigt ZFS schlicht mehrere Schreibvorgänge auf der Zielfestplatte. Einen Faktor 2 bis vier kann man einfach mit "schreibe ZIL + schreibe Metadaten + schreibe Daten + nochmal Metadaten" oder so erklären; bei unglücklichen RaidZ-Konstruktionen mit "falschen" Blockgrößen ergeben sich aber gerne wesentlich größere Faktoren (bis 100!), die eben als Performanceverlust zur Anwendung durchschlagen. Einiges davon lässt sich mit "Tricks" wie den Special Devices kompensieren und Mirrors sind generell weniger anfällig als andere Topologien.

Jedenfalls fährt der Kopf einer einfachen Festplatte mit ZFS wesentlich mehr hin- und her, als bei klassischen Dateisystemen wie Ext4, die eben nicht diese umfangreichen Integritätschecks usw. implementieren.

Der Nutzer bemerkt dann nur: "Oh, ZFS ist langsam!".

Ich persönlich verwende ZFS überall, wo es geht. Die Vorteile überwiegen für mich den Performanceverlust bei weitem. Ymmv!

Und: "abschätzen" ist schwierig. Es gibt Tools wie "fio", die nachvollziehbare und vor allem auch reproduzierbare Ergebnisse liefern. Auch wenn die konkrete Anwendung sich am Ende doch anders verhält, als man erwartet...

 

[felix.steinbeis]

Bei TrueNAS wird dazu geraten, die Datenplatten nicht virtualisiert oder per Passthrough, sondern mit einen durchgereichten PCIE-Storage-Adapter zu betreiben: https://forum.proxmox.com/threads/best-approach-for-a-truenas-vm.121527/

Das beißt sich aber natürlich mit dem Anspruch dass die NAS-VM von einen auf den anderen Knoten repliziert werden kann.

Was allerdings stattdessen gemacht werden könnte:

Jeder Knoten kriegt einen PCIE-Storage-Adapter mit angeschloßenen Festplatten für eine NAS-VM, auf beiden Knoten wird eine NAS-VM auf diesen Platten betrieben. Diese VMs tauschen ihre Daten per Replikation (funktioniert wie die in proxmox auf ZFS-Basis) untereinander aus: https://www.truenas.com/docs/scale/...rotection/replication/remotereplicationscale/

Dann muss man sich noch ein Konzept überlegen, wie man bei einen Ausfall den Benutzern plus Anwendungen klar macht, dass sie die andere VM als Datengrab nutzen müssen.

Vielen Dank. Das schaue ich mir mal genauer an.

Zur Performance: Wenn du deine Netzwerkinfrastruktur so planst, dass du die vollen 10 Gbit deiner Netzwerkkarten nutzen kannst, sollte das passen. Bei Clustern wird aber empfohlen, die Datenreplikation und Cluster-Kommunikation auf je eigenen Netzwerken laufen zu lassen, ggf. noch mit einer extraverbindung für Redundanz:
https://pve.proxmox.com/wiki/Cluster_Manager

Ich verstehe doch richtig, dass du pro Server sechs Netzwerkports hast? Damit sollte sich das schmerzfrei implementieren lassen.
Generell werden bei dir eher die Festplatten der Flaschenhals sein, die VMs sollten schon auf SSDs liegen, für Daten (je nach Usecase) gehen die HDDs natürlich klar.

Ja, die 2 x 10 GBit/s sollen nur die Replikation redundant machen. 2 x 1 GBit/s sind fürs Firmen-LAN. 1 x 1 GBit/s ist fürs Management-LAN.

Was ich generell noch in deinen Konzept vermisse: Wie du die VMs und Daten backuppen möchtest. Bei Proxmox bietet sich natürlich die native Lösung (Proxmox Backup Server) an, die sollte dann aber auf einen eigenen physikalischen Server laufen. Dieser kann dann auch als qdevice fungieren und muss dafür auch nicht im Cluster-Netzwerk sein. Was hast du denn aktuell als qdevice geplant?
Zusätzlich sollte man diese Backups auf eine andere Location übertragen, dafür bietet sich ein Vserver mit installierten PBS an oder ein PBS-Clouddienst wie Tuxis: https://www.tuxis.nl/de/proxmox-backup-server/
Damit ist allerdings noch nichts über anwendungsspezifische Besonderheiten gesagt, SQL-Datenbanken wollen ja üblicherweise noch ihre eigene Sicherung haben.

Aufgrund des internen Aufbaus der Backups (viele kleine Dateien) sollten dort ebenfalls SSDs zum Einsatz kommen.
Als Kompromiss bietet sich das von UdoB erwähnte mirror special device auf SSDs an.
Dass die Platten (ob SSD, NVME oder HDD) keine Consumerhardware sind, setze ich mal als gegeben voraus, bei RAM hast du ja schon ECC eingeplant.

PBS ist geplant. Allerdings mit HDDs. Wäre das echt ein Problem? Auch wenn es ein inkrementelles Backup ist, kommen doch einige Mengen über die Zeit zusammen. Zugegeben, gegen die Empfehlung, wollte ich PBS ebenfalls als VM im Cluster laufen lassen. Ein PBS sollte mir damit immer zu Verfügung stehen und im Worst-Case wäre ein PBS auch schnell wieder installiert.

Als QDevice hatte ich an sowas wie ein Lenovo ThinkCentre gedacht. Und wenn ich so drüber nachdenke, ggf. als PBS, wie Du gesagt hast.
Die Backups plane ich zusätzlich per Borg/Restic extern auszulagern.


Nochmals vielen Dank für Deine ausführlichen Anmerkungen.
Felix

 

[felix.steinbeis]

Wenn man einfach nur "hallo" in einer Textdatei abspeichert, benötigt ZFS schlicht mehrere Schreibvorgänge auf der Zielfestplatte. Einen Faktor 2 bis vier kann man einfach mit "schreibe ZIL + schreibe Metadaten + schreibe Daten + nochmal Metadaten" oder so erklären; bei unglücklichen RaidZ-Konstruktionen mit "falschen" Blockgrößen ergeben sich aber gerne wesentlich größere Faktoren (bis 100!), die eben als Performanceverlust zur Anwendung durchschlagen. Einiges davon lässt sich mit "Tricks" wie den Special Devices kompensieren und Mirrors sind generell weniger anfällig als andere Topologien.

Jedenfalls fährt der Kopf einer einfachen Festplatte mit ZFS wesentlich mehr hin- und her, als bei klassischen Dateisystemen wie Ext4, die eben nicht diese umfangreichen Integritätschecks usw. implementieren.

Der Nutzer bemerkt dann nur: "Oh, ZFS ist langsam!".

Ich persönlich verwende ZFS überall, wo es geht. Die Vorteile überwiegen für mich den Performanceverlust bei weitem. Ymmv!

Und: "abschätzen" ist schwierig. Es gibt Tools wie "fio", die nachvollziehbare und vor allem auch reproduzierbare Ergebnisse liefern. Auch wenn die konkrete Anwendung sich am Ende doch anders verhält, als man erwartet...

Vielen Dank für Deine verständlichen Erläuterungen.
Alternativ wäre zu überlegen, ob ein HW-RAID 1 oder 5 und ext4 die bessere Option gegenüber HDDs mit ZFS ist.

 

[UdoB]

Alternativ wäre zu überlegen, ob ein HW-RAID 1 oder 5 und ext4 die bessere Option gegenüber HDDs mit ZFS ist.

Ja, das ist denkbar.

Für mich ist das allerdings keine Option - ich will die Goodies von ZFS haben. (Billige Snapshots, transparente Komprimierung, Bitrot Detection, Selbstheilung, ZFS send/receive, ... )

 

[Falk R.]

Ihr habt jetzt 2,5 Zoll 10k Disks, welche deutlich schneller sind als die langsamen SATA Scheiben. Eventuell hat der alte Server einen RAID Controller mit Batteriecache, dann ist der alte grob 10x so schnell wie die neuen Platten.
Brauchst du tatsächlich so viel Kapazität oder geht auch eine Nummer kleiner und dann vernünftige SSDs. Neue Server baue ich nur noch mit NVMe und das muss nicht teuer sein.
Fileserver würde ich eher mit OMV oder einem Samba auf einem Standard Linux lösen.
Wenn du eh eine Domäne brauchst, guck dir Projekte wie Univention an, da kannst du LDAP und Filer einfach direkt zusammen erschlagen.

 

[Johannes S]

Ja, die 2 x 10 GBit/s sollen nur die Replikation redundant machen. 2 x 1 GBit/s sind fürs Firmen-LAN. 1 x 1 GBit/s ist fürs Management-LAN.

Da hat jemand die Doku gelesen, das klingt vernünftig. Mit Managment-Lan meinst du das für den Cluster/corosync? Das sollte ja deizidiert und im Idealfall auch redundant sein. Das wäre das einzige, was ich anders machen würde ( also auch für corosync für Redundanz sorgen ).

PBS ist geplant. Allerdings mit HDDs. Wäre das echt ein Problem? Auch wenn es ein inkrementelles Backup ist, kommen doch einige Mengen über die Zeit zusammen. Zugegeben, gegen die Empfehlung, wollte ich PBS ebenfalls als VM im Cluster laufen lassen. Ein PBS sollte mir damit immer zu Verfügung stehen und im Worst-Case wäre ein PBS auch schnell wieder installiert.

Ja! PBS teilt die Daten in zig kleine Daten auf, die dann bei jeden Verify/garbage-collection-job etc eingelesen werden. Bei größeren Datenmengen ( habe was ab 1 TB in Erinnerung) geht das dann in mehrere Hunderttausende bis Millionen. Mit einen ssd-Mirror als special device für Metadaten wird es besser ( da diese Hausmeisterjobs vor allen die Metadaten betrachten), aber nichts schlägt SSD. Dank der Deduplizierung benötigt man aber weniger Speicher, was die Kosten erträglich hält.

Zum Weiterlesen:
https://forum.proxmox.com/threads/pbs-extrem-langsam.123398/
https://forum.proxmox.com/threads/speed-up-backupserver-by-adding-zfs-special-device.85668/

Als QDevice hatte ich an sowas wie ein Lenovo ThinkCentre gedacht. Und wenn ich so drüber nachdenke, ggf. als PBS, wie Du gesagt hast.
Die Backups plane ich zusätzlich per Borg/Restic extern auszulagern.

Ich bin ein großer Fan von restic ( damit mache ich das Backup meines Noteboks und des NAS auf eine Hetzner Storagebox), würde aber nicht auf die Idee kommen, damit PBS Datastores zu sichern. Da beide Programme ihre Daten in viele kleine Dateien aufteilen, wäre das doppelt gemoppelt und das Risiko, dass ein Fehler in einen der Systeme/Datenordner mir beides kaputt macht zu hoch. Wofür restic und Co natürlich super ist: Die Daten der Anwender zu sichern.
Ich fahre bei mir im homelab eine Doppelstrategie fürs offsite-Backup
- Daten werden mit retic auf eine Storagebox gesichert
- Vms auf einen PBS, der auf einen günstigen Vserver läuft und die VM-Backups von meinen lokalen PBS ( als vm auf der NAS) zieht

Sollte ich da irgendwann an eine Größe kommen, dass ein dedicated Server günstiger wird, werde ich mir einen Storageserver für PBS und restic einrichten ( hdd mit ssd special device) wie hier im Thread beschrieben:
https://forum.proxmox.com/threads/ist-es-möglich-pbs-mit-aws-s3-blockspeicher-zu-betreiben.152790/

Zum mini-pc: Als qdevice reicht das locker, für ein Backupsystem würde ich mir aber einen suchen, der erlaubt mindestens zwei Devices als software-RAID mit ZFS zu nutzen.

Nochmals vielen Dank für Deine ausführlichen Anmerkungen.
Felix

Gerne, was aber bedenken ist: Ich mache beruflich Systemadministration, aber leider nichts mit Virtualisierung. Alles Gesagte beruht nur auf Wiedergabe von hier Gelesenen plus Spielerei in meinen Homelab, ist also mit Vorsicht zu genießen

 

[felix.steinbeis]

Hallo zusammen,

nochmals vielen Dank für Eure Antworten. Nachdem ich mich mir Euren Anmerkungen und Vorschlägen intensiv beschäftigt habe, bitte ich Euch nochmal um Eure Einschätzung zu folgenden zwei Varianten. Ziel soll ein solides, stabiles System mit guter Performance (kein High End) sein.

Fileservice über SAMBA, d.h. kein Disk Passthrough. PBS über Bestands-HW.


2-Node HA ZFS-Cluster + QDevice:
Bord: Supermicro Mainboard H12SSL-NT
CPU: AMD EPYC 7313P (3,00 GHz, 16-Core, 128 MB)
RAM: 128 GB (4x 32GB) ECC Reg
SSD: 2 x 4 TB, SATA SSD, 3 DWPD, ZFS Mirror für Proxmox+VMs + 1 Spare Drive
Onboard NIC: 2 x 10 Gbit/s on Board LAN (Broadcom BCM57416) für Proxmox Cluster
Zusatz NIC: 4 x 10 Gbit/s Netzwerkkarte (Broadcom BCM5719-4P) für Management, LAN, ...

2-Node (ohne HA) LVM-Cluster mit gebrauchter HW:
System: HPE DL360 oder DL380 Gen10
CPU: z.B. 2x Intel Xeon Gold 5118 12-Core 2.30 GHz
RAM: 128 GB (4x 32GB) ECC Reg
HDD: 6 x 1,8 TB 12G 10K SAS 2.5" SFF RAID10 (oder ggf. RAID5) LVM für Proxmox+VMs + 1 Spare Drive
RAID-Controller: E208i-a oder P408i-a
Onboard NIC: 4 x 1 Gbit/s on Board LAN

Beim zweiten System würde die HA-Fähigkeit entfallen, aber ich könnte bei Bedarf die VMs von einem Node auf den anderen verschieben.

Was ist Eure Empfehlung? Oder habt ihr Alternativen? Kosten pro System ca. 4.000 EUR (-/+ 1.000 EUR für gebraucht bzw. neu).

Ich freue mich auf Euren Rat. Danke sehr.

Viele Grüße
Felix

 

[Johannes S]

Hallo,
Einschätzungen zur Hardware überlasse ich Berufeneren, aber warum willst du beim zweiten das qdevice weglassen? Bei den Gesamtkosten sollten 200 Euro für einen alten Mini-PC locker drin sein (oder etwas gleichwertigen als Neugerät, das qdevice muss ja nicht viel können). Und wenn ihr eh einen PBS auf Bestandshardware (was für welche?) einrichtet, könntet ihr da auch direkt die Software fürs qdevice draufpacken. Das muss auch nicht ans dezidierte corosync-Netzwerk angeschloßen sein, solange beide Seiten überhaupt eine Route zueinander haben.

Schöne Grüße, Johannes.

 

[felix.steinbeis]

Proxmox unterstützt m.W. bei LVM keine automatische Replizierung. Damit entfällt nach meinem Verständnis auch ein automatisches Failover. Daher brauche ich doch kein QDevice. Ansonsten hast Du natürlich recht.

 

[Johannes S]

Proxmox unterstützt m.W. bei LVM keine automatische Replizierung. Damit entfällt nach meinem Verständnis auch ein automatisches Failover. Daher brauche ich doch kein QDevice. Ansonsten hast Du natürlich recht.

Stimmt, das hatte ich übersehen, sorry. Ok, dann anders gefragt: Warum LVM-thin und nicht ZFS? Wenn du eh keinen shared-storage hast, also eh im Falle eines Ausfalls einen Umgang mit Datenverlusten finden musst, dann wären die Vorteile vom ZFS (und nicht nur wegen der Replikation, auch die größere Flexibilität plus Komprimierung auf Dateisystemebene und bitrot protection) für mich Grund genug, das zu bevorzugen.
Was ich definitiv lassen würde: VMs auf HDDs speichern (dazu noch mit RAID5/6), die Performance wird damit keinen Spaß machen. Was denkbar wäre: Alte Hardware, aber trotzdem neue SSDs oder eine Kombination aus SSDs für die VMs und HDDs als Datengräber.

 

[felix.steinbeis]

Danke Dir. Bevorzugt würde ich RAID10 auf den HDDs aufsetzen wollen. Da die HPE-Systeme i.d.R. einen RAID-Controller haben, geht kein ZFS (scheinbar auch nicht so richtig im HBA-Modus).

Daher die Überlegungen:
Neues System mit SATA SSDs+ZFS Mirror oder gebrauchtes System mit RAID10 und SAS HDDs (sind ja 10K Scheiben).

Die gebrauchten Systeme sind bereits mit HDDs bestückt. Ist am Ende eine Frage des Preises.

Ergänzend zu o.g. Varianten: RAID-Controller hat BBU, PSU ist redundant und USV ist vorhanden.