Meiner erster Proxmox HA Cluster...

[Barungar]

Nachdem ich nun schon einige Zeit Erfahrung mit Promox gesammelt habe, ist bei mir (wieder einmal) das Optimierungs-Gen durchgebrochen.

Ein Proxmox-Server ist zwar schön und wenn er wie mittlerweile auch 11 LCXs bzw. VMs hält ist das auch gut, aber ist das sicher?!
Diese kleine Stimme nagte schon seit Tagen an meinem Gewissen... also habe ich kurzer Hand ein neues kleines Projekt in Angriff genommen.

Und es steht kurz vor der Vollendung... Ich nenne es "Aus 1 mach HA". Mein bisheriger Promox bestand aus einem АMD Ryzen 7 7730 (8 Kerne) und 48 GB RAM mit 500 GB SSD.
Mein neuer HA-Cluster wird bestehen aus: 2x Intel Core i7-8700 (6 Kerne) mit jeweils 40 GB RAM und 500 GB SSD - sowie drei Netzwerkkarten (1G, 2.5G und 10G).
Die Nutzung der Netzwerkkarten: 1G isoliertes Management & Heartbeat Netz, 2.5G VLAN-Trunk für die VMs/LXCs und 10G isoliertes Storage & Migration Netz.

Die beiden Cluterknoten befinden sich 30m von einandern entfernt, in getrennten Brandabschnitten auf getrennten Stromzuführungen mit jeweils eigener USV und redundanter Anbindung (mind. 2x10G LWL) an mein LAN.

Seit gestern befinde ich mich in Aufbau... Hardware ist fertig, Software ist grundinstalliert. Netzwerk ist verbunden... Storage-Pools sind eingerichtet, Storage-Sync muss ich noch einrichten. Heartbeat und Quorum sind eingerichtet sowie erfolgreich getestet. Ein Split Brain wird aktiv verhindert. Dazu verwende ich eine zusätzliche externe Vote, die zur Zeit über den Standalone Proxmox Server bereitgestellt wird. Somit gibt es im Cluster: zwei Knoten und 3 Stimmen bei Quorum 2.

Am Wochenende werde ich die ersten Gast-Systeme auf den Cluster umziehen...

 

[blurrrr]

Glückwunsch!

Mein neuer HA-Cluster wird bestehen aus: 2x Intel Core i7-8700 (6 Kerne) mit jeweils 40 GB RAM und 500 GB SSD - sowie drei Netzwerkkarten (1G, 2.5G und 10G).

Ein Split Brain wird aktiv verhindert. Dazu verwende ich eine zusätzliche externe Vote, die zur Zeit über den Standalone Proxmox Server bereitgestellt wird

Kannst den dritten Node auch in den Cluster integrieren, allerdings muss man aufpassen, wenn man bei den VMs die "Host"-CPU nutzt. Betrieb mit gemixten CPUs ist bei automatischem Failover auch gerne mal ein Schuss ins Knie

Storage-Pools sind eingerichtet, Storage-Sync muss ich noch einrichten

Sowas würde ich persönlich eher vermeiden. Kann man natürlich machen, alternativ kann man auch das integrierte Ceph nutzen, oder - wie bei Deinem Netzwerk - den Storage einfach extern halten (z.B. iSCSI, NFS, etc.). Lokaler Storage ist i.d.R. halt doch um einiges flotter, bringt aber eben auch Nachteile mit sich. Ich weiss grade garnicht (das Thema mit lokalem Storage ist bei mir schon viele Jahre her), ob ein Failover dann mittlerweile auch vernünftig funktioniert. Problem mit dem Sync ist halt "kein Echtzeit" - weiss ja nicht, wie wichtig das für Dich ist. Im schlimmsten Fall sind halt ein paar Minuten weg. Nebst Failover wäre auch die Live-Migration noch ein Thema, aber da weiss ich auch nicht, wie es derzeit bei PVE darum bestellt ist. Diese Dinge würde ich auf jeden Fall mal genauer in Augenschein nehmen, ansonsten ist die Cluster- bzw. "HA"-Geschichte schon relativ witzlos.

Ich habe hier auch noch ein paar Projekte auf dem Tisch, wo z.B. evtl. Ceph zum Einsatz kommt (HCI, wobei das für den Use-Case eigentlich viel zu fett ist und viel zu viele Ressourcen frisst), oder eben eine andere Variante mit einem HA-NFS-Share.

10G isoliertes Storage & Migration Netz.

Also doch "Storage"-Network? Dann nur für Backup/Replication, oder hast Du dann doch noch externen Storage für anderweitige Nutzung angebunden? Du sprachst halt von "Sync"...

 

[Barungar]

Ich habe mich bewusst erstmal entschieden, den "alten" Promox außerhalb des Clusters zu lassen und ihn nur als "dritte Stimme" für das Quorum zu missbrauchen. Ich möchte das Cluster "sortenrein"... gleiche CPU, gleiches RAM, gleiches Board, gleiche SSD, gleiche Netzwerkkarten... Ich mag es nicht Hardware die aktiv zusammenarbeitet zu mischen ... das wäre so, als wenn man HDDs oder SSDs in einem RAID-Verbund mischen würde... igittt.

Ich habe mich bewusst für den Storage-Sync entschieden. Wenn ich auf das NAS ausweiche habe ich wieder einen Single Point of Failure. Oder ich müsst zwei NAS mit QTShero nutzen, die ebenfalls Storage Sync beherrschen.

Bei der Wahl zwischen Ceph und Snapshot Sync habe ich mir erstmal für letztes entschieden. Und mache das auf einem eigenen dezidieren VLAN für den Proxmox-Cluster. Das VLAN 10 (PVE Storage Sync), der Heartbeat läuft auf VLAN 11 (PVE Hearthbeat). Die restlichen Sachen, Management und Gast-Systeme bekommen das VLAN, was wie brauchen.

Der Snapshot-Sync geht minütlich... somit ist die RPO (Recovery Point Objective) < 60 Sekunden. Damit kann ich (noch) leben, falls im "Notfall" der virtuelle Gast die letzten 60 Sekunden vergessen hat. Das wäre ja nur im "Crash-Moment", wenn ich z.B. Wartung machen will, weil ich ein Proxmox-Update oder so einspiele, kann ich die Gäste ja vorher "sauber" auf den anderen Cluster-Knoten "schieben".

P.S.: Der erste LXC läuft. Der initiale Sync 2,9 GB hat 3,5 Sekunden gedauert... die folgenden minütlichen inkrementellen Syncs brauchen keine Sekunde. Und ich habe auch schon von Knoten A zu Knoten B manuell verschoben... alles gut.

 

[blurrrr]

Oder ich müsst zwei NAS mit QTShero nutzen, die ebenfalls Storage Sync beherrschen.

Dachte Du hättest da evtl. sowieso schon einen HA-Verbund laufen. Nachdem es jahrelang nicht vorhanden war, sollen die QNAP-Geräte doch mittlerweile auch HA unterstützen.

Bei der Wahl zwischen Ceph und Snapshot Sync habe ich mir erstmal für letztes entschieden.

Das ist auch deutlich günstiger

Und mache das auf einem eigenen dezidieren VLAN für den Proxmox-Cluster. Das VLAN 10 (PVE Storage Sync), der Heartbeat läuft auf VLAN 11 (PVE Hearthbeat).

Jo, so sollte es auch sein... Hast Du Sync und Heartbeat "direkt" verkabelt (Node zu Node), oder geht das noch über einen Switch? Bei einem 2-Node-Cluster würde sich die direkte Verkabelung halt anbieten bzgl. Sync und Heartbeat, womit man den Switch als "Problem" ausräumen würde. Alternativ halt - würde ich jetzt bei Dir einfach mal vermuten - alles brav mit Bonding auf 2 Switche gepackt?

Der Snapshot-Sync geht minütlich... somit ist die RPO (Recovery Point Objective) < 60 Sekunden.

Okay... kann man machen... Backup dann via PBS?

wenn ich z.B. Wartung machen will, weil ich ein Proxmox-Update oder so einspiele, kann ich die Gäste ja vorher "sauber" auf den anderen Cluster-Knoten "schieben".

Funktioniert das dann "live" einfach so "out of the box" bzgl. des Sync? Storage muss ja mitwandern... Also ggf. kurz freeze, sync, VM migrieren und drüben wieder fortsetzen? Hab mich damit nie wirklich beschäftigt, weil es damals (ist schon ziemlich lange her) für mich einfach so gar keine Option war (runterfahren, verschieben, etc.). Wollte halt schon richtig HA haben inkl. Live-Migration, automatischem Start auf einem anderen Host (falls ein Host abschmiert), etc.

EDIT: Ich vermute aber schon mal, dass die lokale Storage-Definition vermutlich auf beiden Hosts gleich lauten muss?

 

[Barungar]

Dachte Du hättest da evtl. sowieso schon einen HA-Verbund laufen. Nachdem es jahrelang nicht vorhanden war, sollen die QNAP-Geräte doch mittlerweile auch HA unterstützen.

Nein, ich habe bisher nur ein QNAP mit QTShero... das beherrscht zwar Storage-Sync, aber es fehlt ihm der Partner in Form des zweiten QTShero NAS.

Jo, so sollte es auch sein... Hast Du Sync und Heartbeat "direkt" verkabelt (Node zu Node), oder geht das noch über einen Switch? Bei einem 2-Node-Cluster würde sich die direkte Verkabelung halt anbieten bzgl. Sync und Heartbeat, womit man den Switch als "Problem" ausräumen würde. Alternativ halt - würde ich jetzt bei Dir einfach mal vermuten - alles brav mit Bonding auf 2 Switche gepackt?

Da die beiden Knoten rechtweit auseinander stehen... ich sag mal da sind zwei Etagen, und mehrere Brandabschnitte dazwischen. Muss es über einen Teil meiner (redundanten) Switch-Infrastruktur laufen. Im Normallfall ohne Ausfall sind drei Switche beteiligt, sollte es zu einer Störung kommen, so werden es auf Grund von RSTP mehr.
Daher schrieb ich ja auch, dass die Switche an denen jeweils die Knoten angeschlossen sind redundant mit mindestens 2x 10G LWL an der restlichen LAN-Infrastruktur hängen.

Okay... kann man machen... Backup dann via PBS?

Jo, ist angedacht. Als Backup-Ziele habe ich zur Zeit das NAS, die Cloud (über das NAS) und der PBS... ist schon im Hinterkopf.

Funktioniert das dann "live" einfach so "out of the box" bzgl. des Sync? Storage muss ja mitwandern... Also ggf. kurz freeze, sync, VM migrieren und drüben wieder fortsetzen? Hab mich damit nie wirklich beschäftigt, weil es damals (ist schon ziemlich lange her) für mich einfach so gar keine Option war (runterfahren, verschieben, etc.). Wollte halt schon richtig HA haben inkl. Live-Migration, automatischem Start auf einem anderen Host (falls ein Host abschmiert), etc.

Nope, der Storage wandert ja eben nicht mit. In der Art wie ich Promox eingerichtet habe, hat jeder der Knoten eine SDD mit ZFS. Somit erhält jeder LXC oder jede VM im ZFS-Storage Pool ein "eignes ZFS-Volume". Das Ganze wird dann über einen minütlichen ZFS-Volume Snapshot Sync zwischen den beiden Storage Pool gleichgehalten. Wie gesagt mit RPO < 60 Sekunden. Bei der Migration wird der Gast auf Knoten A kurz "pausiert", ein akut-Snapshot Sync gemacht und anschließend der Gast auf Knoten B fortgeführt.

EDIT: Ich vermute aber schon mal, dass die lokale Storage-Definition vermutlich auf beiden Hosts gleich lauten muss?

Exakt, die ZFS-Pool müssen auf beiden Knoten gleich sein. Und zwar so gleich, dass sogar die PoolIDs identisch sind, sowie natürlich die ZFS-Pool Größe.

 

[blurrrr]

Naja, solange sichergestellt ist, dass der Heartbeat funktioniert (egal was passiert), sei's drum...

Wie ist denn das mit einem harten Failover - werden die Container auf den 2. Node dann automatisch neugestartet, oder musst Du da doch noch händisch eingreifen?

 

[Barungar]

Ich weiß ja nicht, wie lange Du Dir Proxmox–Cluster nicht mehr angesehen hast... gut es ist natürlich kein VMware ESX, aber einiges haben sie mittlerweile auch "im Bauch".

Also ja, wenn Knoten A ausfällt werden alle "Ressourcen" auf Knoten B übernommen und neugestartet.
Man kann sogar "Affinities" definieren z.B. LCX 100 und LCX 103 müssen immer auf dem gleichen Knoten laufen oder LCX 102 und LCX 103 drüfen NIE auf dem gleichen Knoten laufen.

Er kann auch auto-rebalancen... also wenn die Gäste auf einem Knoten gerade viel arbeiten und die Gäste auf anderen Knoten Däumchen drehen, dann verschiebt er die Gäste, so dass beide Knoten eine ungefähr gleiche Last haben.

Das ist bei zwei Knoten natürlich, nun ja... egal... aber wenn man z.B. ein drei-, vier- oder fünf-Knoten Proxmox Cluster betreibt macht dass schon Sinn.

 

[blurrrr]

Ich weiß ja nicht, wie lange Du Dir Proxmox–Cluster nicht mehr angesehen hast...

Ich hab es an div. Stellen produktiv im Einsatz und das schon seit etlichen Jahren (die älteste ISO, welche ich noch auf dem NAS liegen habe ist "proxmox-ve_2.0-ff6cd700-24.iso" aus 2012 ). 4-Knoten-Cluster ist auch ein Pfui, dann eher 3 oder 5 (bei Ceph auch eher 5 für den produktiven Einsatz). Das bzgl. HA- und Affinity-Regeln ist mir durchaus geläufig, mir ging es grade nur primär um die Container, weil ich damit eigentlich nix am Hut habe. Bei mir ist i.d.R. alles auf vollständiges HA ausgerichtet, weil ich schlichtweg keine Lust habe zu "rennen" (Du weisst, was ich meine... ).