best-practices für Enterpriseumgebungen

B

Blopeye

New Member
Apr 2, 2025
4
0
1
Hallo Proxmox-Community,

Proxmox ist mir nicht neu, ich habe schon vor 7 Jahren kleine Umgebungen (keine Cluster) in den produktiven Betrieb geschickt. Nun bin ich für eine Wiener KMU tätig welche aus allgemein bekanntem Anlass Proxmox evaluiert und ein klein wenig auch versucht zu pitchen.

Natürlich bekannt ist: https://pve.proxmox.com/wiki/Storage

Jetzt bin ich aktuell am recherchieren welches Setup das bestehende am besten ergänzen/ablösen kann und hätte bezüglich Storage ein paar kleine Fragen die ich nicht 100% beantwortet finden konnte:

Bisher gab es das klassische Setup mit zentralem (geteiltes) Storage wie es so üblich ist beim Mitbewerb. Sprich SAN/FC angebunden an X Nodes welche nur das OS zum booten oben haben ohne disks on board.

In Proxmox setzt man ja stark auf Ceph, daher "hyperconverged". Wenn ich nun alle Features nutzen will, sprich Snapshotting und live migration: welche optionen bleiben mir denn dann für eine mittelgroße Umgebung für den Enterprisebetrieb übrig? LVM mittels FC kann es ja schon einmal nicht sein da ich dann kein snapshotting habe. LVM-thin ist scheinbar nicht möglich über FC.

Somit zu meiner finalen Frage:
Was ist für eine Enterpriseumgebung (5 Nodes+, 50TB+ Storage), Hochverfügbarkeit, Snapshotting, Livemigration die empfohlene Storagekonfiguration? Ist es nur ceph oder gibt es auch eine Lösung mit "klassischem" storage via FibreChannel / SAN?
 
Last edited:
Blopeye said:
Somit zu meiner finalen Frage:
Was ist für eine Enterpriseumgebung (5 Nodes+, 50TB+ Storage), Hochverfügbarkeit, Snapshotting, Livemigration die empfohlene Storagekonfiguration? Ist es nur ceph oder gibt es auch eine Lösung mit "klassischem" storage via FibreChannel / SAN?
Click to expand...
Hi,
wenn du FC oder iSCSI Storage nutzen möchtest, bleibt dir als Supporteter Weg nur LVM. Keine Snapshots sind eigentlich kein echtes Problem, ich predige auch unter vSphere seit vielen Jahren statt Snapshots lieber Backups zu nutzen. Snapshot Backup ist auch auf LVM möglich.

Willst du neues Storage anschaffen, dann kannst du auf ein Filersystem wie NetApp setzen und NFS nutzen, Systeme wie JovianDSS per ZFS over iSCSI anbinden oder halt klassisch auf Ceph setzen. Ich nutze am liebsten Ceph, da man damit am flexibelsten ist.
Kunden in der Größe habe ich alle mit Ceph angebunden, außer das alte FC storage musste noch weiter benutzt werden.
 
  • Like
Reactions: Johannes S
Falk R. said:
Hi,
wenn du FC oder iSCSI Storage nutzen möchtest, bleibt dir als Supporteter Weg nur LVM. Keine Snapshots sind eigentlich kein echtes Problem, ich predige auch unter vSphere seit vielen Jahren statt Snapshots lieber Backups zu nutzen. Snapshot Backup ist auch auf LVM möglich.

Willst du neues Storage anschaffen, dann kannst du auf ein Filersystem wie NetApp setzen und NFS nutzen, Systeme wie JovianDSS per ZFS over iSCSI anbinden oder halt klassisch auf Ceph setzen. Ich nutze am liebsten Ceph, da man damit am flexibelsten ist.
Kunden in der Größe habe ich alle mit Ceph angebunden, außer das alte FC storage musste noch weiter benutzt werden.
Click to expand...
danke für deine Antwort!

snapshots sind halt schon handy für kurze changes, das kann ich glaube ich schlecht argumentieren.

ist NFS wirklich ein gangbarer weg mit guter performance und zuverlässigkeit? Ich habe damit gemischte Erfahrungen gemacht im normalen Serverbetrieb (nicht für Disk-Storage), gerade was Datenbanken (oder sogar sqlite) betrifft ist dringend davon abzuraten. Unser storage könnte NFS ähnlich wie NetApp.

Das heist aber trotzdem: CEPH ist defacto DER bevorzugte Weg für größere Umgebungen? Es gibt ja aktuell mehrere größere Unternehmen im DACH-Bereich die von vmware zu proxmox migriert (haben) und das heist die gehen alle den CEPH-Weg?
 
Last edited:
Blopeye said:
snapshots sind halt schon handy für kurze changes, das kann ich glaube ich schlecht argumentieren.
Click to expand...
Snapshots sind manchmal echt praktisch, aber oft eine Seuche. Viele nutzen ständig Snapshots ohne sich der Probleme bewusst zu sein.
Mache ich ein Update einer Software und kann diese direkt danach testen und den Snapshot löschen, dann ist das ein valider Einsatz. Viele lassen die Snapshots über Tage oder Wochen liegen und wenn dann jemanden auffällt, dass etwas nicht funktioniert, rollt hoffentlich keiner den Snapshot zurück. Damit hätte man einen großen Datenverlust, den man vermeiden kann. Aus einem Backup kann ich einzelne Dateien holen, mir einen Restore neben die produktive VM stellen um einen Compare zu machen und im Notfall auch ein Full Restore. Mit dem Live restore des PBS, ist die VM ja auch extrem schnell wieder online.
Daher besser Backups statt Snapshots nutzen, egal ob das Storage es kann.
Blopeye said:
ist NFS wirklich ein gangbarer weg mit guter performance und zuverlässigkeit? Ich habe damit gemischte Erfahrungen gemacht im normalen Serverbetrieb (nicht für Disk-Storage), gerade was Datenbanken (oder sogar sqlite) betrifft ist dringend davon abzuraten. Unser storage könnte NFS ähnlich wie NetApp.
Click to expand...
Naja, NetApp ist ein Filer, der Stabilität und Verfügbarkeit mitbringt. FC und iSCSI ist bei denen eher das Abfallprodukt.
Andere Storages haben einen Filer Modus, diese sind aber sehr unterschiedlich gut. Bei Huawei funktioniert das ganz gut, aber bei einigen anderen Herstellern, die ich mal nicht namentlich erwähne, nicht so gut.
Blopeye said:
Das heist aber trotzdem: CEPH ist defacto DER bevorzugte Weg für größere Umgebungen? Es gibt ja aktuell mehrere größere Unternehmen im DACH-Bereich die von vmware zu proxmox migriert (haben) und das heist die gehen alle den CEPH-Weg?
Click to expand...
Naja, die Wege sind schon verschieden. Ceph skaliert extrem gut in die Breite. Wenn du aber einzelne VMs hast die auf einer Disk extreme Last erzeugen, dann ist Ceph nicht das richtige. Man kann sagen 95% lassen sich super mit einem vernünftigen Ceph Sizing erschlagen. Ich habe auch einen Kunden wo wir für den einen Datenbankserver auf den Nodes ZFS Pools erzeugt haben. Die VM ist per Always On geclustert, aber damit wir bei Updates nicht eine VM herunterfahren müssen, machen wir noch je VM eine Replika, womit wir auch Live Migration machen können, mit beiden VMs.
 
  • Like
Reactions: Johannes S
absolut, das ist genau unser usecase. wir haben automatismen für patching größerer server-gruppen die automatisch snapshots anlegen, dann patchen und dann nach einem monitoring-check wieder löschen. ich gehe davon aus, die PVE API kann das?

Okay, das heist angenommen man hätte ein Huawei Storage mit NFS, dies wäre ein gangbarer weg für ordentliche performance und stabilität? Also NFS wird eingebunden und dann wird es wo die Auswahl geben für QCOW2 und snapshotting passiert dann mittels qcow.

Dein Beispiel mit den Always-On habe ich nicht ganz verstanden. Für uns wichtig wäre keine hochverfügbarkeit im sinne von Zero-Downtime bei Nodeverlust (reboot auf einem anderen node ist okay) aber bei Node-Patching soll die VM live-migriert werden können - so wie es bei Vmware auch möglich ist.

Wie würde NFS dann in den Nodes eingebunden werden? Wäre das dann shared nehme ich an und nicht jeder node bekommt sein eigenes NFS-Laufwerk?
 
Blopeye said:
absolut, das ist genau unser usecase. wir haben automatismen für patching größerer server-gruppen die automatisch snapshots anlegen, dann patchen und dann nach einem monitoring-check wieder löschen. ich gehe davon aus, die PVE API kann das?
Click to expand...
Ja das geht
Blopeye said:
Okay, das heist angenommen man hätte ein Huawei Storage mit NFS, dies wäre ein gangbarer weg für ordentliche performance und stabilität? Also NFS wird eingebunden und dann wird es wo die Auswahl geben für QCOW2 und snapshotting passiert dann mittels qcow.
Click to expand...
Ich würde jetzt nicht extra Huawei kaufen, aber wenn eh vorhanden, dann einfach den NFS Share an alle Hosts geben und qcow2 nutzen. Qcow nutzt du auf NFS für Snapshots.
Blopeye said:
Dein Beispiel mit den Always-On habe ich nicht ganz verstanden. Für uns wichtig wäre keine hochverfügbarkeit im sinne von Zero-Downtime bei Nodeverlust (reboot auf einem anderen node ist okay) aber bei Node-Patching soll die VM live-migriert werden können - so wie es bei Vmware auch möglich ist.
Click to expand...
Ich wollte nur erwähnen, man kann Live Migration auch ohne Shared Storage, mit Replizierten VMs die auf ZFS liegen.
Blopeye said:
Wie würde NFS dann in den Nodes eingebunden werden? Wäre das dann shared nehme ich an und nicht jeder node bekommt sein eigenes NFS-Laufwerk?
Click to expand...
Einfach unter Datacenter einbinden, shared anklicken und fertig.
 
  • Like
Reactions: Johannes S
Wir machen reflink copies (als snapshots) per cron in xfs auf nfs server, da ist es dann völlig egal welches vm/lxc disk Format vorliegt (qcow2, raw, tpm, ...).
Qcow2 wird mit der Zeit langsamer (durch die Anzahl an Files, die dann miteinander spielen müssen) je mehr snapshots man mit dem qcow eigenen Mechanismus macht, insofern wir jenes nicht nutzen.
 
Last edited:
waltar said:
Wir machen reflink copies (als snapshots) per cron in xfs auf nfs server, da ist es dann völlig egal welches vm/lxc disk Format vorliegt (qcow2, raw, tpm, ...).
Qcow2 wird mit der Zeit langsamer (durch die Anzahl an Files, die dann miteinander spielen müssen) je mehr snapshots mit dem qcow eigenen Mechanismus macht, insofern wir jenes nicht nutzen.
Click to expand...
Naja, dauerhaft mit vielen Snapshots zu arbeiten soll man eh nicht, außer bei ZFS/BTRFS kann man das aufgrund der Architektur.
Die Reflink Clones sind eine coole Methode, aber da wird es schwierig mit Konsistenz, außer man baut sich da etwas Scriptwerk drum herum.
 
  • Like
Reactions: Johannes S
Klar, kleines Scriptwerk umrum gehört natürlich dazu (incl. vm/lxc suspend+resume) für den cronjob. Snapshots sind ja eigentlich auch nur ein extrem schneller Backup-Restore Cache, indem man alle oder einzelne vdisks widerum in msec wieder mit beliebig älterem Stand zurückholen kann, allerdings in Shell auf Fileserver, auf dem pve node macht man dazu halt noch einen vm/lxc stop+start. Backup des jeweils letzten snapshots läuft dann unabhängig wieder auf einen anderen Node mit Platz dafür (zzgl. pbzip+dedup) weiter, falls uns mal der Fileserver unerwartet "verläßt", entweder zum zurückkopieren oder komplettem Übernehmen der Fileserveraufgabe. Natürlich sind neben den Maschinen Images auch die diversen pve Konfigs, alle etc's und anderweitige Skripte usw. mit im Scriptwerk enthalten, man kann insofern alles von dem einen oder anderen beliebig zurückholen. Geht halt nur nicht aus dem pve GUI heraus, aber ohne Shell ist's auch langweilig ... :)
 
Last edited:
Mmh, das sollte aber konfigurierbar sein, wieviel snapshots gehalten werden sollen und dann halt täglich auch wieder den/die Ältersten autom. löschen, je nachdem wieviel snapshots man täglich macht, dann kann eigentlich nichts volllaufen. Und falls man zu wenig Platz hat, weil es zuviel Änderungen gibt, halt die Anzahl etwas verringern.
 
You must log in or register to reply here.
Top Bottom