Erfahrungen und Empfehlungen für Multi-Site Proxmox Cluster Setup gesucht

[Gjoker86]

Hallo zusammen,

ich stehe vor der Herausforderung, ein neues Cluster-Setup für Proxmox zu planen und könnte eure Expertise gut gebrauchen. Bisher habe ich mehrere Proxmox VE Cluster unterschiedlicher Größe (von 2 bis 12 Nodes) betrieben und bin nun in der Phase der Hardwareevaluierung für ein neues Projekt. Geplant ist die Anschaffung von 6 Nodes, ausgestattet mit jeweils zwei AMD Epyc CPUs, 1,5 bis 2 TB RAM und etwa 220 TB SSD NVME Speicher. Zudem ist die Nutzung von 100GB SFP für das Cluster-Netzwerk und 10GB Ethernet für das öffentliche Netzwerk vorgesehen.

Die Herausforderung besteht darin, dass das Setup auf zwei Standorte verteilt werden soll. Ich erwäge, entweder ein Multi-Site Cluster mit allen 6 Nodes über zwei Standorte hinweg zu betreiben oder zwei separate 3-Node Cluster, jeweils an einem Standort. Meine Bedenken bei der 6-Node Variante sind die möglichen Latenzprobleme zwischen den Standorten, die besonders beim Einsatz von Ceph problematisch sein könnten.

Nun meine Frage an Euch: Ist es möglich, an zwei Standorten jeweils einen 3-Node Cluster zu betreiben und die Daten so zu replizieren, dass bei einem Ausfall eines Standorts der andere Standort nahtlos übernehmen kann? Hat jemand Erfahrungen mit einem ähnlichen Setup oder kann praktische Tipps zur Umsetzung geben? Oder kann jemand auch ein gestretchten Cluster empfehlen, also ein Cluster mit 6 Nodes an zwei Standorten? Falls das überhaupt möglich ist... Vielleicht sagt auch jemand, dass ist ein totaler Quatsch und hat einen besseren Lösungsvorschlag. Dazu bin ich natürlich stehts offen...

Vielen Dank im Voraus für eure Unterstützung und Ratschläge!

Beste Grüsse an alle

 

[XMarcR]

Moin. So ein Setup habe ich vor ~10 Jahren mal gebaut, allerdings mit DRBD. Linbit bietet mit Linstor auch heute noch ein entsprechendes Storage für Proxmox.

 

[abufrejoval]

Ganz ehrlich, daß ist der Punkt wo man sich die Beratung einfach auch mal einkaufen muß, zumal man da nichts empfehlen kann, ohne daß man einen ganzen großen Fragenkatalog zu den SLAs ausgearbeitet und beantwortet hat.

Bei HA und DRM gibt es keine einfache Lösung, sondern nur eine große Anzahl unterschiedlicher Kompromisse, die man immerhin teilweise sogar mit der gleichen Hardware und mit Proxmox abbilden kann, aber dann immer noch mit unterschiedlichen Strategien für verschiedene Dienste und VMs.

Ich habe die letzten 20 Jahre mit dem Entwurf von HA Architekturen verbracht und die so gern gewünschte "Nahtlosigkeit" erfordert regelmäßig Quantenkommunikation mit 100% Zuverlässigkeit, die es nun mal nicht gibt.

Es gilt immer noch das CAP-Theorem von Eric Brewer und damit kann man immer nur zwei von drei gewünschten Qualitäten der Nahtlosigkeit bekommen, was immer noch erfordert, daß man mit dem Verlust der 3. über Prozesse oder Logik umgehen muß über so Umwege wie "schlußendliche Konsistenz" (eventual consistency).

Und nein, ich will mich hier nicht als Berater anbieten, ich habe jetzt schon mehr Arbeit als mir gefällt. Aber bei Proxmox kann man sowas sicher kaufen.

 

[Gjoker86]

Hallo Zusammen

Danke euch für eure Antworten. Linbit schaue ich mir gerne mal an. Hört sich interessant an.

Das ist korrekt. Das werde ich auch noch machen. Ich habe bereits mehrere Subscribtions bei Proxmox und werde dabei auch nicht sparen. Das Ziel ist es, eine Stabile Umgebung zu haben und eine Desaster Recovery Side integrieren zu können. Damit, wenn wirklich etwas total in die Hose geht, eine zweite, komplette Infrastruktur steht, welche hochgefahren werden könnte. Natürlich am besten Nahtlos, aber wie du bereits gesagt hast, ist dies beinahe nicht möglich. Das ist mir bewusst. Es geht mir lediglich um den Weg. Auch wenn ich direkt bei Proxmox anklopfe, nimmt es mich einfach wunder, was so alles bereits gebaut wurde und ob jemand bereits ein ähnliches Setup gebaut hat und seine Erfahrungen teilen möchte.

Vielleicht findet sich so ja noch ein Weg, an welchen man nicht gedacht hat und erhält noch einen Schups in die richtige Richtung

Ich danke euch viel Mals für eure Zeit die ihr für euer Feedback aufgewendet habt.

 

[abufrejoval]

Meinem Gefühl nach liegt die Zusammenarbeit mit Linbit gerade etwas im Argen: Erstaunlich und bemerkenswert, wenn man von der einen zur anderen Firma zu Fuß laufen kann...

Ceph ist schon ziemlich gut, bietet aber selbst keine Replikation, wie sie z.B. ZFS hat. Warm-Standby kann man natürlich trotzdem irgendwie machen.

Je nachdem wie groß die Latenzen tatsächlich sind kann man aber ggf. die gemeinsame Storage aktiv von beiden Standorten betreiben (sowie an beiden Standorten die DR-Kopie), da ist es eben nötig zu wissen, was genau gebraucht wird.

Und die meisten Clouds etc. arbeiten immer minimal mit einem 2+1 oder 2+2 Ansatz, um eben lokal synchrone HA anbieten zu können und trennen den Disasterfall von HA.

Wenn man erst mal mit der Aufallsicherheit anfängt, wird das ganz schnell ein großes Thema, welches anfänglich vor allem auch viel mehr Fehlerszenarien beschert. Da gibt es keinen organischen Schritt-für-Schritt-Ansatz, wenn man nicht sehr sorgfältig plant und mit Kompromissen leben kann.

Und leider wollen praktisch alle Chefs immer eine einfache und billige Lösung...

 

[Falk R.]

Nun meine Frage an Euch: Ist es möglich, an zwei Standorten jeweils einen 3-Node Cluster zu betreiben und die Daten so zu replizieren, dass bei einem Ausfall eines Standorts der andere Standort nahtlos übernehmen kann? Hat jemand Erfahrungen mit einem ähnlichen Setup oder kann praktische Tipps zur Umsetzung geben? Oder kann jemand auch ein gestretchten Cluster empfehlen, also ein Cluster mit 6 Nodes an zwei Standorten? Falls das überhaupt möglich ist... Vielleicht sagt auch jemand, dass ist ein totaler Quatsch und hat einen besseren Lösungsvorschlag. Dazu bin ich natürlich stehts offen...

Wie lang ist denn die Strecke zwischen den RZ? Ich habe auch schon einen Ceph Cluster über knapp 40km gebaut. Die ca. 0,7ms zusätzliche Latenz muss man dann in kauf nehmen, und solange die Applikation damit kein Problem hat, geht das wunderbar.

 

[fireon]

Grundsätzlich hat mir die DRBD Lösung (vor 10 Jahren) sehr gut gefallen. Vor allem weil diese Activ/Activ läuft. Dann wurde Linbit mit der neuen Lizenzierung leider etwas träge. Wir nutzen es daher seit dem nicht mehr. Aber wie gesagt, technisch sehr gute Lösung. Würde ich in dem Fall auch in betracht ziehen.

 

[Gjoker86]

@Falk R. Die Strecke ist ca. 35KM... Das es eine Latenz geben wird ist mir klar und würde ich auch in Kauf nehmen. Die Applikationen sollten das auch vertragen können...

@fireon Ich kam leider noch nicht dazu, mir das genau anzusehen. Zur Zeit teste ich gerade die CEPH mirror funktion um die Daten von Cluster A in den Cluster B zu replizieren. Leider will das nochnicht ganz so, wie ich mir das erhofft habe. Zur Zeit schwebt mir an zwei Standorten jeweils einen 4 Node Cluster vor, mit Ceph Storage und replizierung. Damit der Standort B im Desaster Fall übernehmen kann.... Könnte auch eine Lösung sein. Werde mehr Wissen, sobald ich die Replizierung mal hinbekommen habe

 

[fireon]

schwebt mir an zwei Standorten jeweils einen 4 Node Cluster

Achtung für Corosync Quorum benötigst du immer eine ungerade Anzahl an Nodes. Für Ceph selbst machen das die Monitore. Siehe auch https://www.thomas-krenn.com/de/wiki/Ceph Bedeutet also du benötigst noch ne vollwertige Node oder hängst ne Mininode nur für Corosync dazu.

 

[Gjoker86]

Danke für den Hinweis. Das stimmt natürlich Zur Zeit läuft das LAB noch virtuell... Da habe ich nun mal auf 5 Nodes erhöht pro Seite. Leider komme ich noch nicht weiter. Wegen den CEPH Monitoren: Da meinst du, bsp. bei dem 4 Node Cluster einfach nur auf 3 Nodes die Monitore aktivieren? Oder resp. bei 5 Nodes auf allen Nodes ein Monitor einrichten?

 

[fireon]

Danke für den Hinweis. Das stimmt natürlich Zur Zeit läuft das LAB noch virtuell... Da habe ich nun mal auf 5 Nodes erhöht pro Seite. Leider komme ich noch nicht weiter. Wegen den CEPH Monitoren: Da meinst du, bsp. bei dem 4 Node Cluster einfach nur auf 3 Nodes die Monitore aktivieren? Oder resp. bei 5 Nodes auf allen Nodes ein Monitor einrichten?

Ich würde 3 machen. Und dann kommst es halt auch noch darauf was für ein Replica du baust, also wie viele Kopien vorliegen sollen. Grundsätzlich gilt bei Ceph, desto mehr Nodes desto besser .

In einem Ceph Cluster laufen typischerweise eine ungerade Anzahl an Monitors, bei kleineren Clustern 3 oder 5. Von dieser Anzahl muss zumindest die Hälfte am laufen sein, ansonsten verliert der Cluster seinen definierten Zustand und wird für Clients unzugänglich.

 

[UdoB]

Achtung für Corosync Quorum benötigst du immer eine ungerade Anzahl an Nodes.

Stimmt das? Im engeren Sinne? In meiner Wahrnehmung ist das eine sinnvolle Empfehlung, aber kein "muss".

• mit drei Nodes darf nur einer ausfallen
• mit vier Nodes darf ebenfalls nur einer ausfallen

Man ist (hinsichtlich "Quorum") also nicht schlechter gestellt, gewinnt aber auch nix...

 

[fireon]

mit drei Nodes darf nur einer ausfallen

Richtig.

mit vier Nodes darf ebenfalls nur einer ausfallen

Mit vier Nodes hast du kein HA. Also auf Proxmox selbst bezogen. https://pve.proxmox.com/wiki/Cluster_Manager

 

[fabian]

das kommt auch ein bisschen auf die sichtweise an..

3 nodes: 2 nodes die sich sehen haben quorum und laufen weiter
4 nodes: 2 nodes die sich sehen haben kein quorum und fallen aus

d.h. wenn du z.b. zwei racks/raeume/.. hast und die connection dazwischen ausfaellt .. usw

 

[UdoB]

Mit vier Nodes hast du kein HA.

Ich bleibe bei meiner Aussage: EIN Node darf ausfallen. Dann funktioniert alles korrekt, insbesondere auch inklusive HA-failover.

Tatsächlich habe ich einen (momentan ausgeschalteten) Vierer-Test-Cluster auf Dell-Servern in Reichweite. Ich könnte das mit echter Hardware testen - wenn du meine Überzeugung ernsthaft erschüttern könntest, was die schlichte Aussage oben ohne Weiteres nicht schafft...

 

[fabian]

drum sag ich ja - es kommt auf die sichtweise an. bei einer geraden anzahl an nodes kann je nach topologie die chance dass *alle* nodes quorum verlieren (aufgrund eines 50:50 split) groesser sein, als bei einer ungeraden zahl (weil da bei einem zerfall in zwei partitionen zwangslaeufig eine partition groesser ist). selbst wenn die anzahl der nodeausfaelle die der cluster vertraegt gleich bleibt

 

[fireon]

Stimmt schon. Es kommt natürlich auf die Sichtweise an. Wir haben bis jetzt im HA "IMMER" Cluster mit ungerader Anzahl gebaut (außer DRBD). Damit ist man auf der sichereren Seite. Und wenn man schon neu baut, sollte man meiner Ansicht an der Stelle nicht sparen und immer das beste für sich heraus holen. Zur Not würde ich beim 4er einfach (wenn's um Kosten/Platz... was auch immer gehen sollte) noch nen NUC als Member hinzufügen. Dann dürfen auch zwei Nodes ausfallen. Aber das darf man dann wenn alle Vorteile bekannt sind, ja selbst entscheiden

 

[Gjoker86]

Ich möchte mich herzlich für den regen Austausch bedanken. Alle hier genannten Vorschläge werde ich in Betracht ziehen und zu gegebener Zeit über unsere Entscheidung berichten. Aktuell sind wir bereits bei einen 7-Node-Cluster am Standort A und einen 3-Node-Cluster am Standort B, der im Falle eines Desaster-Recovery-Szenarios die wichtigsten Systeme auffangen soll. Wie die endgültige Lösung aussehen wird, werde ich in den kommenden Monaten berichten. Danke nochmals an alle!

Beste Grüsse

 

[Der Harry]

Ich möchte mich herzlich für den regen Austausch bedanken. Alle hier genannten Vorschläge werde ich in Betracht ziehen und zu gegebener Zeit über unsere Entscheidung berichten. Aktuell sind wir bereits bei einen 7-Node-Cluster am Standort A und einen 3-Node-Cluster am Standort B, der im Falle eines Desaster-Recovery-Szenarios die wichtigsten Systeme auffangen soll

So geil ich Proxmox / HA / Cluster finde - das ist halt nicht "immer" das Tool #1 für "Jedes" Problem.

Ich will dir einen alternativen Denkansatz geben. Ggf. hast du reines Windows Gedäns und das geht nicht (!). Wir haben für Multistandort folgendes gewählt.

- Kubernetes (bare metal oder in VMs in Proxmox, es geht auch easy k3s für 90% der kleinen Dinge)
- wenn Proxmox keine Proxmox Cluster, weil das Kubernetes ja schon macht
- Als Kubernetes Filesystem entweder LonghornFS (das ist das gleiche wie Cepfs - aber direkt in Kubernetes) oder einen NFS Server - abhänig ob du Datenbanken hast oder einen DB Restore auf einen bestimmten Zeitpunkt gewährleisten musst)
- Kubernetes kann deine Software horizontal Skalieren (einfach Nodes dazuhängen, Replicas erhöhen, warten wie die Pods starten - fertig).

Die Ausfallsicherheit / Redundanz / HA hast du durch Kubernetes. Ein Update ist easy. Wir killen eine Node in K8s und setzen die Kiste / VMs neu auf und hängen sie wieder and en Cluster.

-> das ist keine Lösung die generisch für jeden Menschen alle Probleme auf einmal löst
-> es ersetzt keine Windows Software
-> k8s ist hardcore

Man braucht aber kein HA auf VM Ebene - sondern hat die Skalierung / Verfügbarkeit auf Service Ebene. Das ist halt immer abstrakter und meistens smarter.

 

[Gjoker86]

Hi Der Harry

Danke für deine Anregungen. Ehrlichgesagt, habe ich nur wenig erfahrungen mit k8s. Ich habe ein kleines Lab mit 4 Raspis mit k3s am laufen und sehe durchaus einen Vorteil. LonghornFS habe ich auch noch keine nennenswerte Berührungen gehabt bis jetzt, aber trotzdem ein sehr spannender Ansatz.

Ich werde hierzu mal ein neues LAB aufbauen (auf den Proxmox Hosts ) und versuchen mehr Erfahrungen zu sammeln. Leider kommen wir nicht um die eine oder andere Windows Maschine herum, aber auch dafür wird es Lösungen geben

Danke nochmals für den tollen Input und ich stehe zu 100% hinter der ersten Aussage deines Posts

Liebe Grüsse