Wahl der richtigen Proxmox Lösung

[Kollwa]

Hallo zusammen,

ich habe gleich mehrere (Anfänger, bitte um Nachsicht) Fragen bzgl. einer mir eventuell vorschwebenden Lösung mit Proxmox.
Bis dato virtualisieren wir mit HyperV - das fliegt raus. Da wir zusätzlich einiges in die Cloud auslagern, sind unsere Anforderungen an die virtuelle Umgebung überschaubar.

- 3-4 VM's produktiv (Windows, Linux)
.... eine der produktiven VM soll quasi den Fileserver abbilden - benötigter Speicherplatz: ~ 8TB

- ca. 5 VM's für Test & Deployment (Windows)
... ausrollen, Software testen, 'wegwerfen'

Die produktiven virtuellen Systeme sollten bei einem Ausfall relativ schnell ("in den nächsten Stunden") wieder herstellbar sein - also HA wird nicht zwingend benötigt. Wenn ich es richtig verstanden habe (mit der Bitte um Korrektur), kann ich eine Ausfallsicherheit wie folgt sicherstellen:

1. Shared Storage bzw. lagern die VM's auf einem zentralen Storage.
= 2 Nodes, 1 Shared Storage
Fällt eine Node aus, kann die VM von einer anderen Node aus gestartet werden. (Ist das noch state-of-the-art ?)

2. Proxmox Backup Server
= 2 Nodes, 1 Backup-Server
VM's werden zyklisch auf einem separaten Backup Server gesichert. Bei Ausfall einer Node kann das Backup auf einer anderen Node wiederhergestellt werden.

3. Ceph
= 3 Nodes (plus ggf. zusätzlich Backup-Server)
Daten bzw. VM's werden über alle Nodes hinweg repliziert (somit kein zentrales Storage notwendig). Bei Ausfall einer Node übernimmt automatisch eine andere.

Meines Erachtens passt zu unserer Anforderung Variante 2.

Dazu könnte ich 2 ggf. bestehende (bis dato Hyper-V) Systeme für den Backup-Node und den Backup-Server her-nehmen (davon ausgehend das die Systemvoraussetzungen erfüllt sind). Die primäre Node wird neu geordert.
Fällt der primäre Node aus, kann ich ein Backup der relevanten VM's auf der Backup-Node aufspielen und laufen lassen.
Die Hardware zwischen den Nodes unterscheidet sich allerdings - ist das relevant ?

Variante 3 wäre wohl der Königsweg. Allerdings benötige ich dazu wohl mindestens 3 Nodes um im Cluster das Quorum zu erfüllen - in unserem Fall etwas oversized. Wie gelesen haben wohl einige auch nur 2 Nodes im Einsatz und eine 3te "Instanz" auf einem Raspi (or whatever) laufen um eben das Quorum zu erfüllen. Das wäre natürlich umsetzbar - wobei zu prüfen gilt ob der Bestandsserver sich dafür einsetzen lässt. Oder eher Finger weg von solch einer Bastelei ?

Vielleicht noch etwas wirr auf dem Weg zu einer einer vernünftigen Lösung - mit der Bitte um Schützenhilfe

 

[aaron]

EIn paar Gedanken von meiner Seite dazu.

8 TiB wiederherzustellen wird wohl ein bisschen mehr als ein paar Stunden dauern. In Kombination mit einem Backupserver kann Proxmox VE zwar einen live restore (VM wird gestartet während der restore läuft), aber damit der Spaß macht, muss das Gesamtsystem flott genug sein. Sprich, der Backupserver braucht einen schnellen Storage (SSD) und das Netzwerk dazwischen sollte entsprechend flott sein.

Grundsätzlich spricht nichts gegen einen kleinen 2-Node cluster plus Backupserver auf eigener Hardware.

Ein Proxmox VE Cluster basiert auf dem Mehrheitsprinzip (quorum). Jede Node hat gleich viele Stimmen. Wenn nun eine der zwei Nodes ausfällt, hat die verbleibende nur noch 50% der Stimmen und somit keine Mehrheit mehr.

Hier kommt nun der dritte (Backup) Server ins Spiel. Man könnte darauf auch ein Proxmox VE parallel zum Backup Server installieren und dem Cluster hinzufügen. Da die HW aber für einen Backupserver deutlich anders aussieht, als einen Hypervisor, macht das nur bedingt Sinn.

Man könnte für das QDevice den externen Teil (corosync-qnetd) direkt am Backupserver installieren. Oder ein Standalone Proxmox VE paralell zum Backupserver auf der gleichen Hardware installieren und dort nur einen Container betreiben, in dem das corosync-qnetd installiert wird.

Somit hat man eine klare Abgrenzung zum eigentlichen Proxmox VE cluster, und je nach Geschmack den externen Teil des QDevice direkt oder in einem Container am Laufen. Dadurch läuft das Qdevice auch auf guter Hardware und nicht auf einem Raspi.


Neben einem zentralen Shared Storage und Ceph gibt es noch den Mittelweg über die VM Replication. Hierfür braucht ihr in beiden Servern ZFS Storages, die genau gleich heißen. Die VMs können dann zwischen den Nodes repliziert werden. Das funktioniert auch mit HA dann, weil ja die Disk Images auf der jeweils anderen Node vorhanden sind.

Der einzige Nachteil zu Ceph oder shared storage ist, dass die Replication asynchron ist. Sprich, wenn eine Node ausfällt, werden die VMs auf der anderen Node mit dem Stand der letzten erfolgreichen Replication gestartet. Das kürzestmögliche Intervall ist aktuell jede Minute. Wenn euch das gut genug ist, hättet ihr die VMs mit einem eventuell kleinen Datenverlust schnell wieder voll am laufen.


Ich persönlich fahre so ein Setup, mit 2 Proxmox VE Servern im Cluster mit ZFS Replication und einem Backup Server auf dem noch ein Container fürs QDevice ist.

 

[Kollwa]

Hallo Aaron,

vielen Dank für die ausführliche Aufklärung! Soweit hab ich alles verstanden. Mit dem aufgezeigten Weg via ZFS Replication könnten wir also den Mix zwischen bestehender und neuer Hardware durchziehen. Denke die 10Gbit Anbindung zwischen den System ist auch ausreichend.

Was mich noch interessiert - was war ausschlaggebend das Deine beiden Server nicht via Ceph "eingebunden" sind ? Anforderungen an die Hardware ?

 

[aaron]

Was mich noch interessiert - was war ausschlaggebend das Deine beiden Server nicht via Ceph "eingebunden" sind ? Anforderungen an die Hardware ?

Für einen Ceph Cluster braucht man mindestens 3 Nodes. Mehr wären besser, bzw. machen mehr Spaß, da Ceph dadurch mehr Möglichkeiten bekommt im Fehlerfall zu reagieren / recovern.

Rein von der Leistung wäre auch ein Server genug gewesen, aber um Redundanz zu haben und Maintenance / Reboots ohne große Ausfälle machen zu können, sind es zwei geworden.

Wenn man im Fall, dass HA tatsächlich mal aktiv werden muss, man kein Problem hat, wenn es potentiell zu einem kleinen Datenverlust kommt, ist somit ZFS mit Replication ein gangbarer Mittelweg.

Die Replication hab ich auch entsprechend eingestellt, wie sehr ein Datenverlust weh tut. Der Mailserver und das PMG wird jede Minute repliziert. Der DNS und DHCP Server alle halbe Stunde oder so.

Backups zum PBS laufen alle 2 Stunden, falls doch gröber was kaputtgeht. Der PBS synct zu einem zweiten PBS am anderen Ende des Landes. Falls wirklich mal das Hochwasser, Feuer oder der Meteorit kommt

 

[Kollwa]

ich hab abschließend noch eine kleine Fragen für mein "big picture"

Ich habe einen Proxmox Server aufgesetzt um damit "warm zu werden". Dort würde ich jetzt gerne anfangen VM' zu erstellen, welche dann später auf den neuen Server in den ZFS Pool kopiert werden sollen. (Diese VM's sollen später wie vorgeschlagen zwischen den Nodes repliziert werden). Ich hab auf dem temporären Proxmox allerdings keinen ZFS-Speicher zu Verfügung um die neue VM dort abzulegen (nur EXT4). Nach Suche im Netz sollte es kein Problem sein die VM in den ZFS Pool zu werfen.

 

[aaron]

Welches Storage verwendet wird, ist grundsätzlich egal. Wenn du später VMs vom temporären Server auf den neuen Cluster bringen willst, gibt es ein paar Varianten.

Zum Beispiel: Backup der VM und restore am cluster. Entweder auf ein Netzwerkshare oder einen Proxmox Backupserver.

Den Cluster am temporären Server erstellen und die anderen 2 Nodes hinzufügen (neue Nodes in einem cluster müssen leer sein). Dann die VMs live migrieren und die temporäre Node aus dem Cluster entfernen ( https://pve.proxmox.com/pve-docs/chapter-pvecm.html#_remove_a_cluster_node )

Low Level geht natürlich noch mehr, aber erhöht die Wahrscheinlichkeit etwas dabei falsch zu machen

 

[Kollwa]

Hallo zusammen,

@aaron
kurze Wasserstandsmeldung zu unserer Proxmox Umsetzung - der neue Proxmox Node inkl. Subscription wird (leider erst) im ersten Quartal 2023 geliefert. Wie auch immer, so lange hab ich immer mal wieder Zeit zum spielen und daraus ergibt sich auch gleich eine Frage

Ich möchte unseren alten Fileserver auf kurze Sicht in Rente schicken und einen neuen am liebsten via Proxmox virtualisieren.

Best Practice bzgl. Performance wäre doch diesen als LXC Container abzubilden und ebenfalls im ZFS Pool abzulegen, oder ?
Somit könnte ich diesen ebenfalls zyklisch replizieren lassen und hätte dadurch meine Ausfallsicherheit gewährleistet.

Voraussetzungen an den Fileserver sind neben den smb Freigaben die Möglichkeit diesen an unsere Active Directory binden zu können.

Nach jetzigem Kenntnisstand würde ich das jetzt wie folgt versuchen umzusetzen:

- LXC Container (priviligiert) mit debian
- Mountpoint erstellen (im ZFS-Pool) für die Fileserver Daten
- samba installieren und konfigurieren (Freigaben, Active Directory Support etc.)

Bitte um Korrektur falls das so nicht funktionieren sollte bzw. mich in die richtige Richtung schieben. Eventuell gibt es auch eine fertige Lösung welche ich übersehen habe.

 

[aaron]

Wenn ihr nur einen Single Server haben werdet, ist das eine machbare Variante. Sobald aber ein Proxmox VE Cluster geplant ist, würde ich eine VM nehmen. Denn Container können nicht live migriert werden. Aber das hängt ganz davon ab, ob es okay ist, wenn die Netzwerklaufwerke mal kurz nicht verfügbar sind.

Somit könnte ich diesen ebenfalls zyklisch replizieren lassen und hätte dadurch meine Ausfallsicherheit gewährleistet.

Genau, wenn das rootfs und alle weiteren mountpoints auf einem ZFS Storage liegen, kannst du die Replication von PVE verwenden. Wichtig ist, dass der Pool und das Storage auf allen involvierten Nodes gleich heißt.