[gelöst] Datenpool für 2 Node Cluster mittels Disks von 2 PVE Servern

[Elleni]

Ich habe 2 Server, mit jeweils 2 kleineren OS Disks, sowie je einem Dutzend SATA 2 TB ssd Disks als Datenpool. Die Aufgabe ist nun, dies analog des früheren Hyper-V Setups dieser Server aufzusetzen, das bedeutet, dass die 2 TB Disks in beiden Servern zusammen als ein Datenpool fungieren sollen, auf welchem VMs von beiden Clusternodes laufen. Dabei sollen beide Server auf den Datenpool zugreifen können, und schnelle Migrationen bzw. Failover Übernahme der VMs durch den laufenden Knoten ermöglicht werden, wenn eine Node down geht. Als Quorum werde ich auf einem dritten Server, z.B. einem Proxmox Backup Server das Quorumdevice installieren.

Bisher habe ich erste Erfahrung mit einem 2Node Cluster sammeln können ohne geteilten Datenpool, auf welchem ich jeweils Replikationsjobs für die VMs aktiviert habe, sodass Migrationen und Failover möglich war.

Könnt ihr mich bitte in die richtige Richtung schubsen, damit ich mich da einlesen kann. Ich habe gelesen, dass Ceph für diesen Einsatzbereich ein Overkill wäre und das Setup dafür zu klein.

Verstehe ich das richtig, dass ich dazu ein verteiltes Dateisystem nutzen muss? Und wie muss das setup sein, damit sichergestellt ist, dass immer nur ein Server auf eine VM Disk schreiben kann (oder ist dies bei korrektem setup sowieso gegeben?)

Die beiden Nodes werden je 2 Mellanox Connect x 3 EN 40 GB Netzwerkschnittstellen zur Clusterkommunikation nutezn können. Für das Management und für den VM Datenverkehr wird ein 10GB SPF+ nic zur Verfügung stehen.

Besten Dank voirab für Hinweise und allenfalls Verlinkung von relevanter Dokumentation und/oder Tutorials, damit ich lernen kann, was meine Optionen für so ein Setup sind.

 

[Oachkatze]

Hallo Elleni,

Du kannst beide Server in einem Cluster zusammenführen. Dadurch hast du die Möglichkeit, ZFS (falls verwendet) zu nutzen, um die VMs in regelmäßigen Abständen zwischen den Nodes zu replizieren. Dies erhöht die Ausfallsicherheit. (ZFS Replication nett man dies)

Achte jedoch darauf, dass ein 2-Node-Cluster einen dritten Quorum-Node benötigt, um ein "Split-Brain"-Szenario zu vermeiden. (kann im homelab auch ein Raspi sein)

Falls du die VMs nur manuell verschieben möchtest, reicht ein normales Cluster aus. In diesem Fall sollte die Migration bereits problemlos funktionieren.
Hier hast du aber kein Failover

Sonst wäre eine NAS/SAN interessant wo beide Nodes drauf zugreifen könnten ... dann könntest du über iSCSI oder NFS etc. zugreifen (Vorsicht - bei gewissen daten Typen gibt es keine Snapshotfunktion und Thin Provision)

Viele Grüße

 

[Elleni]

Hallo Oachkatze, danke für Deine Antwort. Mit Deinem Vorschlag habe ich schon erste Erfahrungen gemacht- das meine ich mit "Bisher habe ich erste Erfahrung mit einem 2Node Cluster sammeln können ohne geteilten Datenpool, auf welchem ich jeweils Replikationsjobs für die VMs aktiviert habe, sodass Migrationen und Failover möglich war." Da ist es dann ja aber so, dass Du immer ein Delta hast - im schlimmsten Fall für die Dauer der Replikationszyklusses, resp. bis die seit der letzen Replikation geänderten Daten kopiert wurden. Das Ziel soll aber sein - ähnlich einem SAN - dass die zweite Clusternode ohne Downtime übernehmen kann.

Ich habe eben kein NAS/SAN, sondern in beiden Servern je n Dutzend 2TB Disks eingebaut. Als dies ein Hyper-V war, wurde offenbar mittels RDNA /ROCE irgendwie direkt ein geteilter Datenpool erstellt, sodass beide Nodes - unabhängig, ob sich die VM auf Platten des einen oder andern Clusternodes befanden auf die VM zugreifen resp. sie betreiben konnten. Wenn dann eine Node down war, gab es einen Failover ohne Ausfall - das ist das Szenario, was ich nachbauen soll. Darum die Frage nach einem verteilten Datensystem. Brauche ich da sowas wie GlusterFS o.ä. resp. was ist für dieses Szenario die ProxMox Best Practice?

 

[Oachkatze]

Ah, okay, ich verstehe dich. Es gäbe noch die Möglichkeit, das Ganze über Ceph zu lösen, allerdings werden dafür mindestens drei Nodes benötigt.

So, wie du es umsetzen möchtest, ist mir aktuell keine andere Variante bekannt.

Klar, bei der Replikation hast du ein gewisses Delta, aber dieses lässt sich sehr gering halten. Falls ein Node tatsächlich ausfällt, sind die Daten dennoch relativ aktuell. Beim Verschieben einer VM werden ohnehin die Live-Daten übernommen, sodass der Vorgang meist schnell abläuft.

Außer einer NAS/SAN-Lösung fällt mir spontan leider keine andere Möglichkeit ein, das umzusetzen.

Vielleicht kann dir noch jemand anders weiterhelfen – ich lese mal still mit und überlege, ob mir noch eine Idee kommt.

 

[Elleni]

Ich hätte nichts dagegen, Ceph mal auszuprobieren, habe aber nur einen 2 Node Cluster in Planung - darum war ich der Meinung, dass dies für ceph kein geeignetes Setup wäre, obwohl ich 2 x 40 GB Mellanox/connect x 3EN Ports pro Servernode zur Verfügung habe, aber vielleicht etwas typenähnliches wäre toll, ev. ein abgespecktes cephs oder glusterfs, drb? In der Storage wiki sehe ich, dass es cephfs und ceph/rbd gibt. - lese mich weiter ein - auch was glusterfs ist, und hoffe auf weitere erhellende Inputs.

Oder wäre hier trotz allem die Empfehlung ohne ein verteiltes Datensystem zu arbeiten, und die Replikationsraten sehr kurz zu halten? Wäre es zB. sinnvoll alle 5 oder sogar alle 2 Minuten zu replizhieren, um ein nahezu gleiches failover zu einem geteilten oder verteilten Dateisystem zu erhalten?

 

[Oachkatze]

Ich hätte nichts dagegen, Ceph mal auszuprobieren, habe aber nur einen 2 Node Cluster in Planung - darum war ich der Meinung, dass dies für ceph kein geeignetes Setup wäre, obwohl ich 2 x 40 GB Mellanox/connect x 3EN Ports pro Servernode zur Verfügung habe, aber vielleicht etwas typenähnliches wäre toll, ev. ein abgespecktes cephs oder glusterfs, drb? In der Storage wiki sehe ich, dass es cephfs und ceph/rbd gibt. - lese mich weiter ein - auch was glusterfs ist, und hoffe auf weitere erhellende Inputs

Ich würde mich freuen, wenn du mir Bescheid geben könntest, ob du etwas Passendes gefunden hast. bin auch sehr gespannt

 

[Falk R.]

Hi mit 2 Nodes funktioniert Ceph auch, aber das ist nur zum Testen und Rumspielen geeignet.
Produktiv bitte wie bei VMware vSAN oder Microsoft S2D immer mit 3 Nodes beginnen. Dann ist Ceph das Richtige für dich.

2 Node Cluster baue ich immer mit ZFS und Replikation, in der Regel reicht es für kleine Kunden die wichtigen DBs alle 1 Minute zu replizieren und andere Server nicht ganz so oft.

Ein Nested Mirroring wie man es bei Microsoft S2D bauen kann, gibt es offiziell nicht, aber man könnte es theoretisch manuell bauen. Ich habe mich damit schon versucht und es funktioniert auch. Produktiv würde ich es trotzdem niemals einsetzen, da es sehr komplex einzurichten, sehr komplex beim erweitern und für Fremde völlig undurchsichtig ist.

 

[Elleni]

Hi Falk R. Vielen Dank für Deine Antwort. Ist es also denkbar, im Falle eines 2 Node Clusters, die Replikation auf sowas 1 bis 5 Mintuen je nach VM runterzuschrauben, und generiert nicht zuviel Datenverkehr? Dann wäre zfs effektiv mit Replikation effektiv eine Option.

Es handelt sich um ein Pilotprojekt, und ich habe effektiv 3 wie oben beschriebene Server zur Verfügung. Unsere Firma hat mehrere Sites, und mir schwebt vor, pro Site einen 2 Node Cluster sowie einen PBS zu installieren, wobei der PBS auch als Quorum(device) für den 2 Node Cluster fungiert. Im kleineren Testumfeld habe ich dies schon so im Einsatz, und es funktioniert ziemlich gut, selbst mit Servern, die ein wenig älter sind. Ich habe da das Replikationsintervall der VMs auf 15 Min. gesetzt.

Deinen Worten entnehme ich, dass ich mir im Prinzip das Einlesen in GlusterFS o.ä. sparen kann, da Ceph die offiziell unterstützte Lösung darstellt. Die Server haben je 2 x 40 GB Mellanox/connect x 3EN Ports pro Servernode zur Verfügung, daher dachte ich diese per Direktverbindung für den Clusterdatenverkehr zusammenzuschliessen (1 Direktverbindung für den Clusterverkehr, und eine für Ceph?). Dazu kommt noch ein 10 GB SPF+ Port für die VM Bridge. Sind die 40Gbit Verbindungen entsprechend schnell genug, um eine ansprechende Performance sowohl für die Clusterkommunikation, wie auch für Ceph zur Verfügung zu stellen? Was wäre die grundsätzliche Limitation in so einem Setup, wo nur 2 Nodes ein Ceph Dateisystem aufziehen? Würde das Datenverlust per se bedeuten, wenn eine der beiden Nodes down ist?

Dann lese ich mich entsprechend in Ceph ein, und versuche selbiges für dieses Pilotprojekt aufzusetzen. Alternativ bleibe ich beim mir bekannten und bewährten zfs & Replikations-Setup.

 

[Falk R.]

Hi Falk R. Vielen Dank für Deine Antwort. Ist es also denkbar, im Falle eines 2 Node Clusters, die Replikation auf sowas 1 bis 5 Mintuen je nach VM runterzuschrauben, und generiert nicht zuviel Datenverkehr? Dann wäre zfs effektiv mit Replikation effektiv eine Option.

Ja, die Replikation ist in der Regen in 2-5 Sekunden pro VM durch. Kommt aber immer auf Änderungsrate und Disk-Backend an.

Es handelt sich um ein Pilotprojekt, und ich habe effektiv 3 wie oben beschriebene Server zur Verfügung. Unsere Firma hat mehrere Sites, und mir schwebt vor, pro Site einen 2 Node Cluster sowie einen PBS zu installieren, wobei der PBS auch als Quorum(device) für den 2 Node Cluster fungiert. Im kleineren Testumfeld habe ich dies schon so im Einsatz, und es funktioniert ziemlich gut, selbst mit Servern, die ein wenig älter sind. Ich habe da das Replikationsintervall der VMs auf 15 Min. gesetzt.

Das kling schon gut, dann stell doch mal auf 1 Minute.

Deinen Worten entnehme ich, dass ich mir im Prinzip das Einlesen in GlusterFS o.ä. sparen kann, da Ceph die offiziell unterstützte Lösung darstellt.

GlusterFS funktiontioniert auch gut, aber das hat immer den Beigeschmack einer Bastellösung, da nicht integriert und du musst alles manuell einrichten, pflegen und testen.

Die Server haben je 2 x 40 GB Mellanox/connect x 3EN Ports pro Servernode zur Verfügung, daher dachte ich diese per Direktverbindung für den Clusterdatenverkehr zusammenzuschliessen (1 Direktverbindung für den Clusterverkehr, und eine für Ceph?). Dazu kommt noch ein 10 GB SPF+ Port für die VM Bridge. Sind die 40Gbit Verbindungen entsprechend schnell genug, um eine ansprechende Performance sowohl für die Clusterkommunikation, wie auch für Ceph zur Verfügung zu stellen? Was wäre die grundsätzliche Limitation in so einem Setup, wo nur 2 Nodes ein Ceph Dateisystem aufziehen? Würde das Datenverlust per se bedeuten, wenn eine der beiden Nodes down ist?

Das funktioniert so leider nicht. Bei MS S2D kannst du das so bauen, da S2D direkt im Cluster implementiert ist und das externe Quorum ausreicht.
Ceph ist ein extra Produkt, was nur sehr gut in die GUI integriert ist. Was sonst ein Vorteil ist, kommt hier als Nachteil, du musst das Ceph Netzwerk für einen dritten Node zugängig machen als Quorum (Monitor Service).
Wenn du deine 40G Adapter nicht auf einen Switch verbindest wo du einen dritten Node (auch langsamer) anbindest oder 3 Nodes im Mesh betreibst, wird das nichts mit Ceph. Das 2 Node Setup ist toll als Demo und Spielumgebung, aber bitte niemals produktiv betreiben, außer du hast einen Ceph Spezialisten der das Setup Pflegt. Der wird dann aber vermutlich das Setup gar nicht supporten wollen.

Dann lese ich mich entsprechend in Ceph ein, und versuche selbiges für dieses Pilotprojekt aufzusetzen. Alternativ bleibe ich beim mir bekannten und bewährten zfs & Replikations-Setup.

Teste gern Ceph, aber als 3 Node Setup. Eventuell kannst du mit deinen 3 Nodes ein Ceph Cluster hochziehen und den 3. Node als PBS auf getrennten Disks missbrauchen.

 

[Johannes S]

GlusterFS funktiontioniert auch gut, aber das hat immer den Beigeschmack einer Bastellösung, da nicht integriert und du musst alles manuell einrichten, pflegen und testen.

Es hat außerdem das Problem, dass es nicht mehr weiterentwickelt wird und qemu den Support wohl bald entfernen wird:

A

Thread 'Gluster effective end of development'

Feb 6, 2025

This may not be of interest to many here, but fyi.

https://marc.info/?l=fedora-devel-list&m=171934833215726

• alexskysilk
• Replies: 2
• Forum: Proxmox VE: Installation and configuration

• 

https://www.qemu.org/docs/master/about/deprecated.html#gluster-backend-since-9-2

Eine Alternative zu Ceph oder ZFS könnte für den OP noch Starwinds VSAN sein, das wird zumindestens auf Reddit öfter mal empfohlen. Selbst habe ich keine Erfahrungen damit und ich würde von Homelabbern auf Reddit mir nichts über den Einsatz im Unternehmen erzählen lassen, aber testen tut ja nicht weh:
https://de.starwindsoftware.com/starwind-virtual-san

 

[Falk R.]

Das Starwind VSAn ist nicht schlecht, hat aber die Krücke eines jeden iSCSI angeschlossenen Speichers, das man nur LVM nutzen kann (ocfs2 nur mit selbst basteln).

 

[Johannes S]

Das Starwind VSAn ist nicht schlecht, hat aber die Krücke eines jeden iSCSI angeschlossenen Speichers, das man nur LVM nutzen kann (ocfs2 nur mit selbst basteln).

Ja, schade dass nicht mehr Storage-Anbieter ZFS-over-ISCSI implementieren, damit hätte man wohl die gängigen Usecases abgedeckt.

 

[Elleni]

Vielen Dank Jungs, ihr seid die besten. Alle Fragen soweit perfekt beantwortet. Da unser Unternehmen die Mellanox Switches ausser Betrieb genommen hat, und ein Weiterbetreiben dieser nicht in Frage kommt, nutze ich die 2 Anschlüsse mindestens als Clusternetz zwischen den zwei Nodes. Somit bleibt in meinem Usecase das rumspielen und lernen mit Ceph erst mal verschoben, und ich baue mir ers mal den Cluser mittels mir bekanntem zfs und stelle die Replikation sehr kurz ein. - ich teste dann auch glei den Extremfall von 1 Minute und gebe hier Bescheid. Da aber die Fragen im Grunde alle geklärt sind, ändere ich den Titel auf gelöst. Nochmals herzlichen Dank für Eure hilfreichen Statements!

 

[Falk R.]

Ja, schade dass nicht mehr Storage-Anbieter ZFS-over-ISCSI implementieren, damit hätte man wohl die gängigen Usecases abgedeckt.

Welche ZFS over iSCSI Implementation hättest denn du gern? Es gibt da ja 3 verschiedene Arten.

 

[Johannes S]

Welche ZFS over iSCSI Implementation hättest denn du gern? Es gibt da ja 3 verschiedene Arten.

Ist mir im Grunde egal, hauptsache eine davon wird von den großen Storage-Anbieter angeboten , sodass diese dusseligen "Ich will aber VM-Snapshots an unseren arschteuren SAN haben" Argumente wegfallen, wenn es darum geht, ob man Broadcom weiterhin Geld in den Rachen wirft.

 

[Falk R.]

Ist mir im Grunde egal, hauptsache einedavon wird von den großen Storage-Anbieter angeboten , sodass diese dusseligen "Ich will aber VM-Snapshots an unseren arschteuren SAN haben" Argumente wegfallen, wenn es darum geht, ob man Broadcom weiterhin Geld in den Rachen wirft.

Dann nimm NetApp mit NFS, das läuft auch super stabil.