Datacenter und/oder Cluster mit local storage only

S

sgw

Member
Proxmox Subscriber
Apr 5, 2024
57
0
6
www.oops.co.at
Meine ursprüngliche Aufgabenstellung wurde schon hier drin beschrieben, weil es nun nicht mehr um FC geht, beginne ich einen neuen Thread.

Kurz: ich baue auf 3 Stk HPE DL360 Gen9 mit je 2 internen 2TB SAS SSDs 3 Proxmox-Nodes auf, die vorübergehend etwa 30-40 VMs betreiben sollen.

Hintergrund ist der Abbau eines VMware-Clusters aus 3 ESXis, mit einem HPE MSA-2060 Storage (SAS). Das Projekt-Ziel ist der Aufbau eines Proxmox-Clusters auf diesen 3 Servern, die DL360Gen9 sind nur temporäre Nodes.

Solange ich nur intern die 2x2TB SAS-SSDs habe (als hw-raid1), kann ich ja nach meinem Verständnis kein PVE-Cluster aufbauen: fehlendes Shared Storage. Richtig?

Für die Übergangszeit wäre das akzeptabel, ich hab bereits den Backup Server am Laufen, und wir haben Sicherungen auf Veeam und nun in PBS.

Ein Node läuft schon vor Ort, der Techniker der Firma migriert schon VMs ... diesen Node fasse ich also erst mal nicht allzu viel an.

Sobald ich Platten für die restlichen 2 Nodes habe, installiere ich darauf PVE.

Was macht da nun Sinn?

Ich stelle mir vor, die beiden Nodes in ein gemeinsames Datacenter zu packen? Extra Netzwerk zwischen den beiden?
Oder kann das doch ein PVE-Cluster werden, vorläufig auch ohne Shared Storage am MSA?

Für den Produktiv-Cluster später würde ich natürlich gerne schon vorab Dinge lernen und testen können.

Macht es Sinn, die 3 prod-Server nach Entfernen der ESXis (das wird noch etwas dauern) als Nodes 4-6 dem Datacenter hinzuzufügen? Oder ist das overkill und bringt nix? (ich denke in Richtung Übersiedelung der dann laufenden produktiven VMs)

Für jegliche Tips und Beruhigung bin ich dankbar ;)

Schönen Tag, Stefan
 
Den Cluster kannst Du schon aufbauen und auch VMs drauf betreiben.
Es wird nur keine Hochverfügbarkeit für die VMs geben, da deren Images ja auf lokalem Storage liegen, der eben weg ist, wenn der Proxmox-Knoten stirbt.
Im Normalbetrieb lassen sich die VMs dank Storage-Migration aber auch live verschieben.
 
Was mit einer Fußnote schon geht, ist ZFS als Local Storage zu verwenden und das Replication Feature zu nutzen. Geht auch mit mehr als 2 Nodes, wird aber bei vielen Nodes recht schnell unübersichtlich.

Dadurch kann man auch HA nutzen mit dem einen Nachteil, dass im HA Fall die VM mit einem etwas älteren Stand der Disk Images auf einer anderen Node recovered wird.

Die Gast Replication ist Asynchron, entsprechend kann es selbst beim kürzesten Intervall (1min) zu ein wenig Datenverlust kommen. Wenn man damit leben kann, ist es eine Option. Wenn nicht, dann wirst du ein echtes shared Storage brauchen.
Die ZFS Pools auf dein einzelnen Nodes müssen dafür auch genau gleich heißen.
 
  • Like
Reactions: gurubert
gurubert said:
Den Cluster kannst Du schon aufbauen und auch VMs drauf betreiben.
Es wird nur keine Hochverfügbarkeit für die VMs geben, da deren Images ja auf lokalem Storage liegen, der eben weg ist, wenn der Proxmox-Knoten stirbt.
Im Normalbetrieb lassen sich die VMs dank Storage-Migration aber auch live verschieben.
Click to expand...
Das klingt gut, danke.

Gibt es einen bevorzugten Weg?

"pve1" läuft aktuell standalone und hat schon produktive VMs drauf (gesichert vom PBS).

"pve2" und "pve3" sind noch bei mir und warten auf ihre Platten. Ich würde die hier vorinstallieren.
Ist es besser, die beiden schon vorab zu einem Cluster zu verbinden, und dann beim Kunden auch noch "pve1" hinzuzufügen?

Oder starte ich am "pve1" mit dem Cluster-Setup? Vielleicht egal, ich will nur nicht irgendwas am falschen Fuß beginnen.

Soweit ich verstehe, geht das dann los per "pvecm create <cluster>" etc, korrekt?

Wenn ich mit "pve2" und "pve3" bei mir beginne, kann ich ein wenig testen etc bevor es produktiv wird.
 
Hi,

sgw said:
Ist es besser, die beiden schon vorab zu einem Cluster zu verbinden, und dann beim Kunden auch noch "pve1" hinzuzufügen?
Click to expand...

nein, da ein Node mit bestehenden VM's nicht zu einem Cluster hinzugefügt werden kann, daher den Cluster auf "pve1" erstellen und dann die restlichen leeren Nodes hinzufügen.

sgw said:
Soweit ich verstehe, geht das dann los per "pvecm create <cluster>" etc, korrekt?
Click to expand...

etweder über die CLI mit pvecm oder über die GUI.
https://pve.proxmox.com/pve-docs/pve-admin-guide.html#pvecm_create_cluster

Greetz
 
  • Like
Reactions: gurubert
Ich hab das jetzt mit den 2 Nodes "pve2" und "pve3" bei mir hier vorab getestet (die 2 Nodes installiere ich dann noch mal frisch vor Platzierung beim Kunden). Lokales Storage in LVM, eine VM konnte ich bereits migrieren. Corosync habe ich über separate NICs realisiert, wie empfohlen.

Jetzt am Demo verstehe ich einiges besser, wunderbar. Danke Euch soweit!
 
So, mein Kunde berichtet, dass er bereits alle VMs migriert hat. Demnach ist der VMware-Cluster nun leer und außer Betrieb ... rechtzeitig vor dem gefürchteten Termin zum Monatsende ;-)

Ich würde ja jetzt mal etwas durchatmen und beobachten, der Kunde fragt aber schon nach next steps (eh erfreulich).

Die Hardware, die bislang VMware betreibt, wird komplett "geleert" und neu mit Proxmox installiert.

Dh. 3 Server und das MSA-2060 per FC ... Soweit ist mir das Vorgehen prinzipiell klar, vermutlich werde ich die bestehende LUN am Storage wieder verwenden und halt für Proxmox "formatieren" oder?

Bzw. vielleicht besser "from scratch" eine LUN erstellen? Habt Ihr da einen Link zu einem Thread oder Howto, der mir da hilft?

Weiters würde ich evtl. die 3 "neuen" Server mit in den bereits bestehenden PVE-Cluster aufnehmen ... von wegen einfacherer Migration der VMs (Ziel ist ja: weg von den jeweils lokalen SSDs hin zu Storage am MSA-Storage ... und in Folge HA ...).

Spricht was dagegen?

Danke für jegliche Hinweise, Hilfestellungen ... oder schlicht Zuspruch :)

EDIT: Zusatzidee: einen der ESXis runter fahren, SD-Card raus ... PVE auf irgendein temporäres Medium installieren und booten und davon testen, wie ich das MSA erreiche ... *bevor* ich LUNs anfasse etc / macht Sinn?
 
Last edited:
Unsupported lässt sich auf einer FC-LUN ein OCFS2 anlegen und an jedem Proxmox-Knoten mounten. Proxmox sieht das dann als gemeinsam genutztes Verzeichnis-Storage (wie NFS) und mit qcow2-Images gibt es dann Thin-Provisioning und Snapshots.
 
sgw said:
So, mein Kunde berichtet, dass er bereits alle VMs migriert hat. Demnach ist der VMware-Cluster nun leer und außer Betrieb ... rechtzeitig vor dem gefürchteten Termin zum Monatsende ;-)

Ich würde ja jetzt mal etwas durchatmen und beobachten, der Kunde fragt aber schon nach next steps (eh erfreulich).

Die Hardware, die bislang VMware betreibt, wird komplett "geleert" und neu mit Proxmox installiert.

Dh. 3 Server und das MSA-2060 per FC ... Soweit ist mir das Vorgehen prinzipiell klar, vermutlich werde ich die bestehende LUN am Storage wieder verwenden und halt für Proxmox "formatieren" oder?

Bzw. vielleicht besser "from scratch" eine LUN erstellen? Habt Ihr da einen Link zu einem Thread oder Howto, der mir da hilft?

Weiters würde ich evtl. die 3 "neuen" Server mit in den bereits bestehenden PVE-Cluster aufnehmen ... von wegen einfacherer Migration der VMs (Ziel ist ja: weg von den jeweils lokalen SSDs hin zu Storage am MSA-Storage ... und in Folge HA ...).

Spricht was dagegen?

Danke für jegliche Hinweise, Hilfestellungen ... oder schlicht Zuspruch :)

EDIT: Zusatzidee: einen der ESXis runter fahren, SD-Card raus ... PVE auf irgendein temporäres Medium installieren und booten und davon testen, wie ich das MSA erreiche ... *bevor* ich LUNs anfasse etc / macht Sinn?
Click to expand...
HI,
zuerest dein letzter Punkt. Ja testen ist immer eine gute Idee. ;)

Ich habe auch einige Migrationen von vSphere gemacht mit nutzung des alten Storages.
Die betreiben wir generell supportet mit LVM, das Thin Provisioning können heutzutage alle Storages.
Das Thema Snapshots umgehen wir komplett. Ich predige schon seit viele Jahren, lieber Backups statt Snapshots zu nutzen, aus mehreren Gründen:
1. Snapshots bleiben genr mal zu lange liegen
2. Bei Updates geht eventuell mal nur eine Konfigdatei kaputt und dafür den Snapshot zurückrollen und neu anfangen ist blöd. Bei einem Backup kann man ja auch einzele Dateien zurückholen.
3. Echte Rollback werden extrems selten gemacht und ein Snapshot Rollback hat immer einen Impact, das Baclkup löschen nicht.
4. Das Backup kann ich auch schützen und notfalls sehr lange aufbewahren.

Das setzt natürlich einen vernünftigen PBS voraus.

Du kannst auch die alten LUNs benutzen, aber optimaler ist neu, damit das Thin Provisioning im Storage vernünfig ohne Altlasten arbeiten kann.

Einen gemeinsamen Cluster mit den anderen Hosts geht natürlich, wenn die jetzt schon in einem Cluster sind. Ein Cluster Join geht immer nur mit einem leeren Host.

P.S. die SD-Cards kannst du alle raus werfen und niemals wieder benutzen. ;)
 
  • Like
Reactions: gurubert
Die Anbindung macht keinen Unterschied, solange die LUN an allen Knoten die selbe ist.
Ja, die Präsi ist von mir, da sind inzwischen aber wieder neue Kenntnisse hinzugekommen.

Insbesondere beim Formatieren der LUN sollte mkfs.ocfs2 mit -T vmstore aufgerufen werden, damit die Blocksize und vor allem die Clustersize möglichst groß sind.
Die Erfahrung hat gezeigt, dass es bei zu kleinen Größen zu Deadlocks im OCFS2 kommt und der gesamte Cluster neu gestartet werden darf.
 
  • Like
Reactions: XMarcR and sgw
gurubert said:
Die Anbindung macht keinen Unterschied, solange die LUN an allen Knoten die selbe ist.
Ja, die Präsi ist von mir, da sind inzwischen aber wieder neue Kenntnisse hinzugekommen.

Insbesondere beim Formatieren der LUN sollte mkfs.ocfs2 mit -T vmstore aufgerufen werden, damit die Blocksize und vor allem die Clustersize möglichst groß sind.
Die Erfahrung hat gezeigt, dass es bei zu kleinen Größen zu Deadlocks im OCFS2 kommt und der gesamte Cluster neu gestartet werden darf.
Click to expand...

Ah, ich hatte es schon vermutet, dass die Präsi von Dir sein könnte ;-)

Der Format-Tip ist ja sehr wertvoll: danke!

Ich werde versuchen, einen der zukünftigen pves temporär als PVE zu starten, und dann eine Test-LUN im freien Platz am Storage dafür anzulegen. Dann mal Dein Howto durchgehen und schauen, wie weit ich damit komme. Wenn ich mich dann soweit damit wohlfühle, denke ich übers tatsächliche "Resetten" von Servern und Storage nach. Aktuell läuft deren VMware-Umgebung quasi ohne VMs im Leerlauf, das ist ja schon mal ein schöner Zwischenstand.
 
Falk R. said:
HI,
zuerest dein letzter Punkt. Ja testen ist immer eine gute Idee. ;)

Ich habe auch einige Migrationen von vSphere gemacht mit nutzung des alten Storages.
Die betreiben wir generell supportet mit LVM, das Thin Provisioning können heutzutage alle Storages.
Das Thema Snapshots umgehen wir komplett. Ich predige schon seit viele Jahren, lieber Backups statt Snapshots zu nutzen, aus mehreren Gründen:
1. Snapshots bleiben genr mal zu lange liegen
2. Bei Updates geht eventuell mal nur eine Konfigdatei kaputt und dafür den Snapshot zurückrollen und neu anfangen ist blöd. Bei einem Backup kann man ja auch einzele Dateien zurückholen.
3. Echte Rollback werden extrems selten gemacht und ein Snapshot Rollback hat immer einen Impact, das Baclkup löschen nicht.
4. Das Backup kann ich auch schützen und notfalls sehr lange aufbewahren.

Das setzt natürlich einen vernünftigen PBS voraus.

Du kannst auch die alten LUNs benutzen, aber optimaler ist neu, damit das Thin Provisioning im Storage vernünfig ohne Altlasten arbeiten kann.

Einen gemeinsamen Cluster mit den anderen Hosts geht natürlich, wenn die jetzt schon in einem Cluster sind. Ein Cluster Join geht immer nur mit einem leeren Host.

P.S. die SD-Cards kannst du alle raus werfen und niemals wieder benutzen. ;)
Click to expand...
PBS bereits produktiv, klappt soweit. Das war Bedingung, um etwaige VMs drauf zu ziehen.

Wenn keine Snapshots: dennoch OCFS2, oder was Anderes? Thin Provisioning ist für den Kunden derzeit eigtl auch keine Anforderung: die Platten im Storage sind nur etwa halb durch die produktive VMware-LUN in Verwendung.

(a) da ist noch Platz auf den vorhandenen Platten im Storage
(b) da sind noch zig Slots frei im Storage (ob die alle auch einen Controller dran haben, weiß ich ad hoc nicht)
(c) die SAS-SSDs, die ich aktuell lokal als RAID-1 (2 disks) in den 3 Temporär-PVEs betreibe, kann man dann später evtl ins Storage rein siedeln (Rahmen und Controller vorausgesetzt)
(d) es werden noch VMs dazu kommen, aber nicht Faktor 2 oder mehr

Ich denke, das ist jetzt eine sehr grundlegende und weitreichende Entscheidung, wie man dieses Storage aufbaut (no na), da höre ich gerne Eure Empfehlungen und pros and cons. Gerne immer das Beste, sofern ich es ausreichend verstehen und betreiben kann ;-)

danke vorerst, sonniges Wochenende, Stefan

ps: SD-Cards entferne ich dann gerne, wenn es soweit ist ;-)
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back