Migrationsfragen zu Proxmox

wire2hire

Member
Oct 20, 2020
13
1
23
40
Guten Morgen,

ich habe hier schon oft Lösungen gefunden und auch Denkanstöße, deswegen erstmal danke an die Community.
Ich habe unsere Abteilung endlich überzeugt , dass wir auf Proxmox wechseln.

Unser Setup bisher : vmware , mit internen speicher jeweils als raid1, dazu per veeam backup und replication zu einer nas per nfs.

Frage an sich , wegen zfs und raid. zfs möchte ja gerne die volle Kontrolle über die disk haben.
Wir haben folgenden Raid Controller: Broadcom MegaRAID 9560-8i SAS-SATA-NVMe

benutzt jemand diesen mit Proxmox und kann sagen ob er stabil läuft? Müssen wir ihn wie frühen in den IT mode flashen oder, was ich oft gelesen habe, zb von Falk (danke für dein Wissen, was du hier oft zur Verfügung stellst) oder einfach die jeweiligen disk einzeln als jbod und dann hat man alle vorteil vom controller und zfs?

Unsere sfp+ Karte wäre AOC-STG-i4S SFP+ Quad Port, auch dort weiß jemand ob diese gut läuft, bzw hat die jemand im Einsatz?

Generell Aufbau , den wir andenken:

3 PVE
storage jeweils als das , zfs raid1
dazu dann gerne replication , entweder per veeam oder zfs an sich , geht zfs wenn der storage eine nas mit nfs ist ?

empfielt ihr es zu clustern? der neue datacente rmanager scheint ja auch migration von standalone zu bringen, oder wäre ohne direkt zfs replication nicht möglich?

Backup benutzen wir derzeit veeam, pbs könnten wir uns vorstellen oder eine Mischung, wie macht ihr das?

Größe 8-10 windows VMs , Datenbank lastig, 8-10 Linux vms

Grüße und danke für jede Antwort!
 
von veeam würde ich mich durch ihr Marketing, dass es unter Proxmox VE, nutzbar ist, verabschieden.

Proxmox VE und Proxmox Backupserver auf ZFS, enterprise SSDs ist deine Wahl.
Etwas anderes kann es bedeuten, wenn man Proxmox VE und Proxmox Backupserver direkt sichern wollen würde.
Ich habe meine Proxmox Backupserver unter Proxmox VE virtualisiert.

Und Ja richtig ZFS muss direkten Zugriff auf seine "Platten" haben.

NFS auf irgendein NAS ist eher etwas für langsam sich ändernde Daten, nicht für den Proxmox Backupserver geeignet!
 
  • Like
Reactions: Johannes S
Danke für deine Antwort.

Ja mit veeam ist wirklich so eine sache, eventuell würden wir am Anfang zweigleisig fahren und den pbs dazu packen.

wie sieht denn der pbs mit iscsi angebunden storage aus (hdd im raid)?
 
Danke für deine Antwort.

Ja mit veeam ist wirklich so eine sache, eventuell würden wir am Anfang zweigleisig fahren und den pbs dazu packen.

wie sieht denn der pbs mit iscsi angebunden storage aus (hdd im raid)?
Also für den Proxmox BS nur lokale SSD, im z.B. ZFS VDEV0 2x Mirror, VDEV1 2x Mirror. So dass die IOPs maximal werden.
Wir reden hier über maximal viele N-fach Millionen 4kByte Random Read, mit einer Blockgröße von maximal 4 MByte-
Maximal Chunks, da ZFS mit compression benutzt werden kann und, aus meiner Sicht auch, sollte.
Der Proxmox BS speichert die Daten in Chunks und so wird eine De-Duplizierung der Daten erreicht.
Was da ist, wird nicht neu übertragen, aber es muss immer der GESAMTE Datenbestand, bzgl. vorhandenen Chunks, überprüft werden.
Es macht Sinn sich mit dem System Proxmox VE und BS in einer Testumgebung vertraut zu machen.
Evtl. auch mit realen VM...

Edit, danke @Johannes S
 
Last edited:
Der Proxmox BS speichert die Daten in Chunks und so wird eine Duplizierung der Daten erreicht.

Kleine Korrektur: Deduplizierung, Duplizierung ist das genaue Gegenteil ;)

Wegen Backups: Für VMs ist PBS die bessere Wahl, das kann aber keine application-awaren Backups, etwa für Datenbanken.

Wenn ihr das braucht, dann kann eine Kombination sinnvoller sein, wie der von dir genannte @Falk R. sie hier öfter beschrieben hat:
PBS für die VMs und LXC-Container, ein Veeamagent auf der jeweiligen VM kümmert sich um das Anwendungsbackup ( Datenbank, AD...).

Da Veeam dann nicht mehr für den ganzen Cluster benötigt wird, kann das wohl gut Geld sparen, je nach Szenario.

Was mir noch nicht ganz klar ist: wollt ihr eure drei Knoten als Cluster betreiben? Plant ihr Richtung high availability zu gehen?

Disclaimer: Halbwissen aus den Forum hier, keine eigene Erfahrung.
 
  • Like
Reactions: UdoB and ThoSo
Danke für deine Antwort. Zum Glück ist auch praktisches Wissen vorhanden, trotzdem nicht so viel wie beim bisherigen vmware setup.
Die Frage tat sich auf wegen den cluster . Unsere Idee, war das wir durch das das und kein ceph zb trotzdem das minimal ha per zfs nutzen sollten.
Heißt proxmox per zfs replication zu einem anderen node oder per veeam ( was bisher aber noch nicht für proxmox möglich ist).
Geht zfs replication ohne cluster? das neue tool (alpha) scheint ja ind ie richtung zu gehen, standalone nodes mehr möglichkeiten zu geben, zwecks migration usw.

Falk seine Beiträge über die Kombination, ich denke so wäre es bei uns vom Vorteil.
Schade das der PBS ssds braucht um wirklich perfomant zu laufen, für backups ist mit hdd ( größe, preis) bishe rlieber und funktionierte mit veeam auch immer hervorragend.
 
Schade das der PBS ssds braucht um wirklich perfomant zu laufen, für backups ist mit hdd ( größe, preis) bishe rlieber und funktionierte mit veeam auch immer hervorragend.
Was ist denn "performant"?
Entscheidend ist doch wohl die Frage, was wird wann und wie in welchem Umfang (Volumen / Full- /Diff ) gesichert?
Klar sind SSDs schnell (NVMe) - wenn dir die SSD die Krätsche macht ist diese futsch (e-Schrott) - eine Festplatte kann man noch an ein Speziallabor schicken wenn's sein müsste (dann ist My2Cent deine Backup Strategie nicht durchdacht).
Ich würde das zuvor einfach richtig testen um ein Gefühl zu bekommen, ob HDDs reichen (SAS Platten, 10000 Umdrehungen) oder doch SSDs (NVMe).
Ganz entscheidend dabei ist doch, die Wiederherstellung wenn nichts mehr geht! Wie lange darf der Ausfall im Idealfall sein?
 
  • Like
Reactions: Johannes S
Heißt proxmox per zfs replication zu einem anderen node oder per veeam ( was bisher aber noch nicht für proxmox möglich ist).
Geht zfs replication ohne cluster? das neue tool (alpha) scheint ja ind ie richtung zu gehen, standalone nodes mehr möglichkeiten zu geben, zwecks migration usw.

Der Datacentermanager ( falls du den meinst) ist vor allen für die Migration zwischen verschiedenen Clustern oder stand-alone-nodes und im Grunde eine WebUI für pct remote-migrate und qm remote-migrate auf der Konsole ( gibt es beides schon mehrere Jahre).

Die auf ZFS basierende storage replikation ist für die Übertragung innerhalb eines Clusters, für die Replikation zwischen Clustern/stand-alone-Knoten gibt es pve-zsync:
https://pve.proxmox.com/wiki/Storage_Replication

https://pve.proxmox.com/wiki/PVE-zsync


Zu beachten ist bei beiden, dass es im Desasterfall seit letzten Sync dazugekommen Daten weg sind ( Default 15 Minuten, kann auf eine Minute bis mehrere Stunden geändert werden). Hat man Anwendungen, wo das nicht akzeptabel sind, wäre zu prüfen, ob man die nicht auf Anwendungsebene clustert ( z.B. MySQL-Cluster).

Schade das der PBS ssds braucht um wirklich perfomant zu laufen, für backups ist mit hdd ( größe, preis) bishe rlieber und funktionierte mit veeam auch immer hervorragend.
Naja HDDs in einen striped ZFS mirror (entspricht RAID20, höhere Read-Performance als RAIDZ) plus special device auf SSDs können da durchaus einen Kompromiss zwischen Budget und Performance darstellen:

https://pve.proxmox.com/wiki/ZFS_on_Linux#sysadmin_zfs_special_device

Ihr könntet das ja mal in allen Varianten ( RAIDz, striped mirror, mit und ohne special device ) benchmarken, bevor es in Produktion geht.
 
Last edited:
  • Like
Reactions: UdoB and ThoSo
vielen dank erstmal für eure Tipps und Anregungen! Gerade für den sync auch ohne cluster, das werden wir jetzt uns anschauen, da 5-15 minuten sync absolut im rahmen wäre!


wie schaut es aus mit dem RAID Controller? jeweils als jbod konfigurieren oder doch umflashen? , zwecks zfs
 
falls möglich umflashen / hba modus, jbod ist schlecht weil zfs direkten zugriff auf die devices haben will
Braucht man nicht, die aktuellen Controller kann man alle im Bios direkt umstellen auf HBA Mode. man muss nur vorher alle Raids löschen, da er sich sonst weigert.