Probleme 2 Standorte HA

[danielz87]

Hallo zusammen,


wir betreiben einen Proxmox-Cluster (8.4.10) mit folgender Konfiguration:

• 2 Rechenzentren (Standort A und Standort B)
  
  • Jeweils 3 Nodes, verbunden über Darkfiber
• 3. Standort mit QDevice (per Side-to-Side VPN angebunden)
• Ceph als Shared Storage (repliziert zwischen beiden Rechenzentren)
• HA ist für relevante VMs und Services aktiviert

CEPH:

ceph osd pool get cephpool min_size
size: 2
min_size: 1


cluster:
id: 637edacf-be40-4a4d-a7d3-22bdff69de56
health: HEALTH_OK

services:
mon: 6 daemons, quorum ESC-PVE-01,ESC-PVE-02,ESC-PVE-03,RUE-PVE-01,RUE-PVE-02,RUE-PVE-03 (age 11h)
mgr: ESC-PVE-01(active, since 3d), standbys: RUE-PVE-01
osd: 120 osds: 120 up (since 11h), 120 in (since 23h); 1 remapped pgs

data:
pools: 2 pools, 8193 pgs
objects: 10.22M objects, 34 TiB
usage: 67 TiB used, 353 TiB / 419 TiB avail
pgs: 11/20436499 objects misplaced (0.000%)
8191 active+clean
1 active+clean+scrubbing+deep
1 active+clean+remapped

io:
client: 197 MiB/s rd, 138 MiB/s wr, 5.20k op/s rd, 4.55k op/s wr

Crushmap, Corosync, Pvecmstatus im Anhang



Problem:
Wenn wir einen kompletten Ausfall eines Rechenzentrums simulieren (z. B. Standort A offline), funktioniert das HA-Failover nicht wie erwartet.
Die VMs aus dem ausgefallenen Standort werden nicht automatisch auf den verbleibenden Standort übernommen – stattdessen bleiben sie im HA-Status „stopped“ oder „frozen“.


Bisherige Erkenntnisse:

• Netzwerkverbindung zwischen den Standorten ist ansonsten stabil (Darkfiber, geringe Latenz).
• QDevice ist erreichbar und wurde in den Cluster integriert.
• Es ist egal ob ein Server oder 3 Server am Standort "ausfallen", die ganzen Maschinen Freezen
• Alle Maschinen waren in HA in einer eigenen Gruppe, ich musste Sie aber dann wieder entfernen, nach dem Test ging einfach nichts richtig, Maschinen waren im Freeze, erst nach dem entfernen konnte ich Sie Stoppen und wieder Booten dann war es wieder OK.

Danke für jede Hilfe oder Hinweise, wie wir das Setup optimieren können.


Viele Grüße

 

[FrankList80]

Sehr cooles Setup! Sorry kann die Frage nicht beantworten vorab.

Etwas "Ranting": als IT-Veteran sehe ich immer wieder, insb. bei Virtzilla Nutzern die gleiche "Auto-Failover"-Leier von Heavy VMs mit monolithischen Applikationen. Es ist ein Graus, und i.d.R. ein Setup hat so viele "Points of Failure" im Betrieb (ich erinnere nur an RTT bei Active/Active SAN Storage), dass man m.E. manchmal bei den hohen IT Betriebskosten fragen sollte - warum schreibt ihr die Applikation nicht neu "Cloud native" :-/

Ich persönlich bin auch ein Fan eines 2.ten Technologiestacks aus Sovereignity-Gründen, sowie eines anderen Paradigmas (Ja, in der tat kein RTO Zero): lass die Backup COTS das Ganze doch "sehr schnell asynchron machen", dafür hab ich dann aber ein "lightweight" Compute-Setup, jeweils auf Site A und Site B (kein Shared Storage) - manueller Start, in der Tat, aber mit einem guten Monitoring, HW Refresh wäre ich hoffnungsvoll. Ich meine Bald kommt von VEEAM (no affiliation) auch ein "Universal CDP" (Agent-based?) - das würde die harten Requirements an Quoren und Fibre/MPLS Strecken auch minimieren.

Just my 2 cent. Es gibt bestimmt Gründe, warum Sie dieses Design gewählt haben. Viel Erfolg!

---

[Virtualization Support for SME and NGOs | DLI Solutions ]

 

[danielz87]

Hey, kein Ding – vielen Dank für deine Rückmeldung, auch wenn du die Frage nicht ganz beantworten konntest.
Ich verstehe, was du mit den "Heavy VMs" und dem "automatischen Failover" meinst. Deine Idee mit einem zweiten Tech-Stack, "lightweight Server Setup" an Standort A und B, und ohne gemeinsam genutzten Speicher klingt ziemlich gut – weniger potentielle Ausfallpunkte und weniger Abhängigkeiten.

Ich mag es aber auch, mit den neuesten Trends zu gehen – und bin total begeistert von Automatisierung . Ich finde es immer faszinierend, wie gut man Hochverfügbarkeit und Failover automatisieren kann, ohne dabei neue Schwachstellen zu schaffen.

 

[UdoB]

size: 2
min_size: 1

Ist das mit Kenntnis der damit verbundenen Risiken so eingerichtet worden?

Mir läuft es jedenfalls eiskalt den Rücken runter, aber ich bin kein Ceph Spezialist (und habe auch noch nie mit zwei Datacentern hantiert).

 

[Falk R.]

Hallo zusammen,


wir betreiben einen Proxmox-Cluster (8.4.10) mit folgender Konfiguration:

• 2 Rechenzentren (Standort A und Standort B)
  • Jeweils 3 Nodes, verbunden über Darkfiber
• 3. Standort mit QDevice (per Side-to-Side VPN angebunden)
• Ceph als Shared Storage (repliziert zwischen beiden Rechenzentren)

Wie genau ist die Replikation konfiguriert?

• HA ist für relevante VMs und Services aktiviert

CEPH:

ceph osd pool get cephpool min_size
size: 2
min_size: 1

Ich hoffe so betreibt ihr das nicht Produktiv.

cluster:
id: 637edacf-be40-4a4d-a7d3-22bdff69de56
health: HEALTH_OK

services:
mon: 6 daemons, quorum ESC-PVE-01,ESC-PVE-02,ESC-PVE-03,RUE-PVE-01,RUE-PVE-02,RUE-PVE-03 (age 11h)

Da ist schon mal ein echtes Problem. bei ceph immer nur 3 oder 5 Monitor konfigurieren.
Euer Quorumrechner muss natürlich auch Monitor für Ceph spielen.

mgr: ESC-PVE-01(active, since 3d), standbys: RUE-PVE-01
osd: 120 osds: 120 up (since 11h), 120 in (since 23h); 1 remapped pgs

data:
pools: 2 pools, 8193 pgs
objects: 10.22M objects, 34 TiB
usage: 67 TiB used, 353 TiB / 419 TiB avail
pgs: 11/20436499 objects misplaced (0.000%)
8191 active+clean
1 active+clean+scrubbing+deep
1 active+clean+remapped

io:
client: 197 MiB/s rd, 138 MiB/s wr, 5.20k op/s rd, 4.55k op/s wr

Crushmap, Corosync, Pvecmstatus im Anhang



Problem:
Wenn wir einen kompletten Ausfall eines Rechenzentrums simulieren (z. B. Standort A offline), funktioniert das HA-Failover nicht wie erwartet.
Die VMs aus dem ausgefallenen Standort werden nicht automatisch auf den verbleibenden Standort übernommen – stattdessen bleiben sie im HA-Status „stopped“ oder „frozen“.

Natürlich, Ceph schaltet auf ReadOnly wenn keine Quorum Mehrheit da ist. (Mon)

Bisherige Erkenntnisse:

• Netzwerkverbindung zwischen den Standorten ist ansonsten stabil (Darkfiber, geringe Latenz).

Was ist bei dir eine gute Latenz?

• QDevice ist erreichbar und wurde in den Cluster integriert.

Mit welcher Latenz?

• Es ist egal ob ein Server oder 3 Server am Standort "ausfallen", die ganzen Maschinen Freezen

Da scheint noch mehr falsch konfiguriert zu sein.

• Alle Maschinen waren in HA in einer eigenen Gruppe, ich musste Sie aber dann wieder entfernen, nach dem Test ging einfach nichts richtig, Maschinen waren im Freeze, erst nach dem entfernen konnte ich Sie Stoppen und wieder Booten dann war es wieder OK.

Danke für jede Hilfe oder Hinweise, wie wir das Setup optimieren können.


Viele Grüße

 

[danielz87]

Wie genau ist die Replikation konfiguriert? -> Die Daten liegen auf einer OSD in Datacenter 1 und eine im Datacenter 2

Ich hoffe so betreibt ihr das nicht Produktiv. -> Wir haben uns bewusst dazu entschieden, Das Szenario. Datacenter Down + 1 Server im anderen RZ wird nicht vorkommen

Da ist schon mal ein echtes Problem. bei ceph immer nur 3 oder 5 Monitor konfigurieren. -> Habe ich angepasst
Euer Quorumrechner muss natürlich auch Monitor für Ceph spielen.

Natürlich, Ceph schaltet auf ReadOnly wenn keine Quorum Mehrheit da ist. (Mon)
QDevice Latenz -> 30ms
Was ist bei dir eine gute Latenz? --> 1m

Danke schonmal

 

[Falk R.]

Naja, 1 Server Down für Patching und während dessen stirbt irgend eine SSD, ist gar nicht so unwahrscheinlich und dann hast du schon Datenverlust.
30ms ist auch keine gute Latenz, vor allem weil da ein Ceph.mon laufen muss.

 

[fba]

Ich sehe da nur einen Link für Corosync in der corosync.conf. Wo ist denn da der mindestens notwendige zweite?

 

[danielz87]

Kurzes Update: Nach einer Korrektur der Monitor-Konfiguration läuft unser Cluster nun wie geplant. Vielen Dank an Falk für die Unterstützung!

Wir können jetzt problemlos einen ganzen Standort herunterfahren, ohne dass es Auswirkungen auf den Betrieb hat.


Das QDevice ist inzwischen korrekt als Ceph-Monitor eingebunden – hier lag der ursprüngliche Fehler. Aktuell sind insgesamt fünf Monitore aktiv.

 

[danielz87]

Ich sehe da nur einen Link für Corosync in der corosync.conf. Wo ist denn da der mindestens notwendige zweite?

Wir nutzen bewusst nur einen Corosync-Link. Dieser läuft jedoch über ein Bond-Interface mit zwei NICs, angebunden an zwei unabhängige Switches. Damit ist die Cluster-Kommunikation physisch redundant ausgelegt, auch wenn in der corosync.conf nur ein Ring sichtbar ist.

 

[Falk R.]

Wir nutzen bewusst nur einen Corosync-Link. Dieser läuft jedoch über ein Bond-Interface mit zwei NICs, angebunden an zwei unabhängige Switches. Damit ist die Cluster-Kommunikation physisch redundant ausgelegt, auch wenn in der corosync.conf nur ein Ring sichtbar ist.

Das ist trotzdem nicht optimal. Weitere Ringe in der Corosync Konfiguration kosten nix extra und werde ja sowieso nur genutzt, wenn der erste ausfällt, oder voll ausgelastet ist.
Wie ist denn der Bond konfiguriert? Wenn die Umschaltzeit zu lang ist, kann das zum Fencing führen und wenn die zwei Switches im Stack sind, zählt das eh nicht als volle Redundanz, da beim Update beide booten und auch eine gemeinsame Konfiguration haben, was bei logischen Fehler suboptimal ist.

 

[danielz87]

Das ist trotzdem nicht optimal. Weitere Ringe in der Corosync Konfiguration kosten nix extra und werde ja sowieso nur genutzt, wenn der erste ausfällt, oder voll ausgelastet ist.
Wie ist denn der Bond konfiguriert? Wenn die Umschaltzeit zu lang ist, kann das zum Fencing führen und wenn die zwei Switches im Stack sind, zählt das eh nicht als volle Redundanz, da beim Update beide booten und auch eine gemeinsame Konfiguration haben, was bei logischen Fehler suboptimal ist.

Unsere beiden Switches sind nicht gestackt, sondern komplett unabhängig voneinander. Der Bond läuft im Active/Passive-Modus, die Umschaltzeit liegt im Millisekundenbereich – wir haben das getestet und bisher kein Fencing erlebt.


Ich verstehe absolut, worauf du hinauswillst. Aktuell sehe ich durch die Architektur keine Notwendigkeit für einen zweiten Ring, nehme den Hinweis aber gerne auf und behalte es im Hinterkopf.

 

[Falk R.]

Unsere beiden Switches sind nicht gestackt, sondern komplett unabhängig voneinander. Der Bond läuft im Active/Passive-Modus, die Umschaltzeit liegt im Millisekundenbereich – wir haben das getestet und bisher kein Fencing erlebt.


Ich verstehe absolut, worauf du hinauswillst. Aktuell sehe ich durch die Architektur keine Notwendigkeit für einen zweiten Ring, nehme den Hinweis aber gerne auf und behalte es im Hinterkopf.

Wie viele ms habt ihr denn eingestellt? Default ist bis zu 100ms was für Corosync schon zu viel sein kann, weil da bis 5ms empfohlen wird.
Beim stumpfen ziehen eines Kabels, sollte das immer sauber funktionieren, nur leider sind echte Ausfälle nicht immer so klar. Manchmal braucht die NIC auch etwas um den Link Loss zu bemerken, wenn dieser nur halb tot ist.
Daher empfehle ich auch gern andere netzwerke wie Ceph und so, auch für Corosync zu nutzen. Zu viel Redundanz habe ich noch nicht gesehen.

 

[danielz87]

Wie viele ms habt ihr denn eingestellt? Default ist bis zu 100ms was für Corosync schon zu viel sein kann, weil da bis 5ms empfohlen wird.
Beim stumpfen ziehen eines Kabels, sollte das immer sauber funktionieren, nur leider sind echte Ausfälle nicht immer so klar. Manchmal braucht die NIC auch etwas um den Link Loss zu bemerken, wenn dieser nur halb tot ist.
Daher empfehle ich auch gern andere netzwerke wie Ceph und so, auch für Corosync zu nutzen. Zu viel Redundanz habe ich noch nicht gesehen.

Machen wir es kurz. Ich machs ! Danke dir!

 

[fba]

Das QDevice ist inzwischen korrekt als Ceph-Monitor eingebunden – hier lag der ursprüngliche Fehler. Aktuell sind insgesamt fünf Monitore aktiv.

Hast Du die election policy angepasst, so dass dieser MON kein leader wird (werden kann)? (s. https://docs.ceph.com/en/latest/rados/operations/change-mon-elections/#disallow-mode)