Meinung Disaster Recovery Konzept

[rothkraut]

Hallo zusammen,

ich hocke momentan an einem Konzept für ein Disaster Recovery zwischen zwei Standorten.
Mich würde mal interessieren, ob meine Idee so umgesetzt werden kann, und was eure Meinung dazu ist.

Folgendes Szenario:
Standort A und Standort B. Beide Cluster sind wie folgt aufgebaut:
-2 Nodes + QDevice
-externer Storage (ZFS) für VM-Disks (TrueNAS)

Standort A beherbergt das produktive Cluster. Sollte dieses komplett ausfallen, sollen die VMs im Standort B wieder hochgefahren werden können.


Meine Idee:

Die VM-Disks der TrueNAS werden stündlich von Standort A zu Standort B synchronisiert. Die TrueNAS ist an das Cluster in Standort B als Storage angebunden

Ich übertrage die .conf files der VMs von den beiden Hosts von Standort A zu den beiden Hosts in Standort B direkt in den Path "/etc/pve/nodes/ServerName/qemu-server".
Auch dies findet stündlich statt und überschriebt immer die bereits existierenden .conf-Files.
Dafür würde ich mir ein Skript bauen.


Sobald die .conf-File auf dem Host liegt, sollte ja eine VM mit dieser Config angelegt sein. Und wenn der Storage in beiden Clustern die selbe Bezeichnung hat (z.B. storage-zfs-01), sollten die virtuellen Disk ja auch direkt gefunden werden. Oder!?

Sprich es werden stündlich die VMs neu angelegt und die Festplatten werden auch stündlich aktualisiert.


Wenn es jetzt auf Seite A zum totalen Ausfall kommt, sollte ich doch in der Lage sein, die VMs an Standort B zu starten.

Wenn Standort A wieder laufen würde, müsste man den ganzen Spieß umdrehen, also Storage und .conf Fiels von B nach A synchronisieren etc.


Wie seht ihr das? Macht das Sinn? Wird es so technisch auch funktionieren?

Ich habe das noch nicht testen können, das ist nur meine erste Idee auf Papier.


Ich weiß man könnte das auch mit PVE-zsync realisieren. Aber mich schreckt ab, dass eine große Anzahl von Jobs gebaut werden müsste. Zudem weiß ich nicht, wie es sich verhält, wenn z.B. durch HA oder balancing die VMs zwischen den Hosts migriert werden müssen.

Ich habe auch folgenden Thread gesehen und nun am evaluieren, welche Option mehr Sinn macht:

[TUTORIAL] What Replaces SRM and vSphere Replication on Proxmox?


Schonmal vielen Dank für eure Rückmeldungen!

 

[Supaman]

Dazu folgende Gedanken:

Ein solches Setup würdevorausetzen, das der Datenstand annährend in Echtzeit syncronisiert werden kann - gibt die Datenanbindung das her ? Läuft das über das Intenet, oder ist es das Nebengebäude das mit 10GB+ angebunden ist ?

Insbesondere bei Datenbanken z.B. für das ERP System ist je nach Anzahl der User / Transaktionen ein Datenstand, der 1 Stunde hinterher ist, vielfach keine Option.

Weiterhin: Wenn die VMs an Standort B hochgefahren würden, könnten diese dann auch tatsächlich verwendet werden? Damit meine ich sowohl die benötigte Bandbreite als auch das Netzwerk Setup.

Bevor man ein solche Split Setup in Angriff nimmt, würde ich zu allererst alle Möglichkeiten ausschöpfen, den Betrieb an Standort A so robust wie möglich zu machen, z.B. Cluster mit Ceph, und dann die Server räumlich verteilen, zusammen mit den anderen Maßnahmen.

 

[TErxleben]

Ich finde das Setup ist recht gruselig.
Um eine DB im laufenden Betrieb nahtlos zu übernehmen, taugt es nicht für 5 Pfennig.
Entweder du hast einen entsprechenden Speicher, der das zulässt oder du hast Zeitintervalle, die zu deinen nicht kritischen Maschinen passt.
Eine DB mit PVE, Cluster hin oder her, nahtlos betreiben zu können, ist einfach Irrglaube/Wunschdenken.
Sonst halte ich 1h Synchronisationsfrequenz für komisch. Entweder fehlen 1h wichtige Daten in einer DB oder Tagesfrequenz reicht auch.

 

[ThoSo]

KO Kriterien :

1. Die Standorte ->
- Anbindung (Bandbreite für die Produktive Arbeit und den Sync-Aufwand!) und räumliche Entfernung
- über welches Volumen an VMs und Datenspeicher reden wir hierbei?

Wenn es jetzt auf Seite A zum totalen Ausfall kommt, sollte ich doch in der Lage sein, die VMs an Standort B zu starten.

Was wäre denn der totale Ausfall - die Hütte ist abgebrannt?

2. In der Regel haben die Standorte auch unterschiedliche IP Bereiche. -> Routing?

3. VM-Disks sind auf einem TrueNAS Storage und werden über die Leitung "kopiert" - die sind aktiv in Benutzung? Gesperrt? Und falls es dann doch klappt, sind die nach dem kopieren noch konsistent?

4. Wie oft ändert sich den etwas an den config-Files der VM, das man die stündlich synchronisiert?

5. Wie lange darf den der Ausfall sein?
- Brauche ich jetzt wirklich alles 1:1 am Standort B oder kann man das auf eine Anzahl für den Notfall reduzieren.
- Wenn du am Standort "B" bis alles wieder läuft mehr Zeit bindest als du für den Recovery am Standort "A" brauchst, wäre das auch schlecht.

Teste dein Vorhaben doch einmal mit 2 kleinen Testmaschinen an den jeweiligen Standorten

 

[TErxleben]

@ThoSo hat das schon schön weiter aufgedröselt. Lediglich der "Test" mit kleinen Testmaschinen ist m.E. irreführend, wenn man sich nicht so richtig sicher ist, wohin die Reise gehen soll.