Wenn der Veeam Recovery Orchestrator (kurz VRO) zum Einsatz kommt, handelt es sich in der Regel um Infrastrukturen mit VDP Premium Lizenz. Alternativ wäre auch der Einsatz der VDP Advanced und zusätzlichen 10er Instance Packs für den Orchestrator möglich.
Im Orchestrator selbst gibt es dann diverse Möglichkeiten Recovery Pläne abzubilden.
In diesem Artikel möchte ich eine Möglichkeit aufzeigen, beim Einsatz von Replication-Jobs vorab die produktiven Workloads herunterzufahren, die Delta-Daten auf die DR-Site zu übertragen und anschließend dort hochzufahren. Dies entspricht somit einem nativen Planned Failover innerhalb Veeam Backup & Replication (mit mehr Optionen und Reporting Funktionalitäten).
Replication Jobs in VBR
In meinem Lab arbeite ich hier mit diversen VMware vSphere Tags, die hier SLAs abbilden (Gold, Silver, Bronze). Meine Replication Jobs innerhalb VBR sind in ähnlichem Schema benannt.
Replication Jobs:
REP_vSphere_Site A_RP_Gold
REP_vSphere_Site A_RP_Silver
REP_vSphere_Site A_RP_Bronze
Innerhalb der jeweiligen Replication Jobs sind meine zu sichernden Ressourcen ebenfalls via Tags ausgewählt:
In dieser Konfiguration sind die Jobs auf einmal täglich (06:00 Uhr) terminiert, was einer RPO von 24 Stunden entspricht.
VRO – Recovery Plans
Der Recovery Plan selbst ist mit einer RPO von 24 Stunden und einer RTO von 1 Stunde definiert.
Innerhalb eines regulärem Recovery Plans, sind per Default keine Pre-plan Steps definiert, siehe hier:
Genau das wollen wir nun ändern und um eine planned Failover Funktion ergänzen! Innerhalb der Gruppe Pre-plan steps wählen wir via Add die Funktionen Veeam Job Action und VM Power Actions aus.
Anschließend wird VM power Actions ausgewählt und via Edit Step angepasst:
Für During Failback and Undo bitte Skip wählen!
Wichtig: in diesem Szenario muss unter During DataLab Tests die Option Skip gewählt werden! Sonst würde beim Testen des isolierten Recovery Plans die produktiven Workloads heruntergefahren werden.
Im Feld vCenter Name wird der FQDN der Quell-Seite hinterlegt, in meinem Lab wäre das der vCenter hu-vcsa-a-20.lab.intern.
Unter VM Names gebe ich die zu verarbeitenden VMs ein. Hinweis: mit den vorhandenen Variablen war ich bisher noch nicht erfolgreich, das steht noch auf meiner Liste, die es zu klären gilt. Es wäre schön, wenn man mit einer Variable wie %alle-VMs-die-im-recovery-plan-verarbeitet-werden% arbeiten könnte. Vielleicht hat Alec King, Emilee Tellez oder jemand hier einen Vorschlag für mich 😊
Und unter Power Action wird der Wert Shutdown Guest OS gewählt.
Anschließend wird mit Apply gespeichert und nun der Step Veeam Job Actions editiert:
Auch hier wähle ich Skip während dem DataLab Test. Denn ich möchte während dem isolierten Recovery Plan Test keine Replication starten.
Unter Job Name wähle ich nun die jeweiligen Replication Jobs aus – diesen Schritt muss ich für jeden einzelnen Replication Job erneut durchführen. Hier exemplarisch für den Job REP_vSphere_Site A_RP_Gold.
im Action Feld wird nun der Wert Start ausgewählt.
Anschließend den Default-Wert Yes im Feld Wait for Completion bestätigen und mit Apply die Option speichern. Denn Ihr wollt erst wenn die Replication abgeschlossen ist, mit dem eigentlichen Failover starten.
In meinem Szenario habe ich drei Replication Jobs (siehe oben), am Ende sieht das Ganze dann also wie folgt aus:
Ich habe also 3 x Veeam Job Actions ausgewählt und die jeweiligen Replication Tasks hinterlegt. Via Save wird der angepasste Plan gespeichert.
Planned Failover
Nun geht’s zum Starten des planned Failovers.
Ausgangsbasis:
- letzte Replication heute Morgen um 06:00 Uhr
| System vro-test-01_AD | System vro-test-02_DB |
 |  |
Ich erzeuge auf beiden System Änderungen und Delta-Daten:
Die Systeme sind leicht modifiziert und sind noch online.
Blick auf die produktive Site A im vCenter:
Auf der DR-Site sind die Systeme noch aus, letzter Restore Point von heute Morgen 06:15 Uhr:
Recovery Plan in VRO
Ich starte nun den Recovery Plan, via Launch und Run:
Der Plan muss via Enable this Plan aktiviert werden:
Zur Ausführung müssen die Credentials noch mal bestätigt werden:
Der letzte Readiness Check wird mit Status angezeigt:
Wir wählen den letzten vorhandenen Restore Point (Default) aus:
Anschließende Zusammenfassung und via Finish wird die Operation gestartet.
Shutdown / Replication / Startup / Check
Die Systeme werden nun sofort über den Orchestrator heruntergefahren:
Anschließend starten in VBR die Replication Jobs:
Innerhalb des VRO sieht das ganze wie folgt aus:
Die Aktionen werden Step-by-Step durchgeführt, innerhalb VBR ist mittlerweile der erste Replication Job abgeschlossen. Auf diesen Screenshots wird nun der Silver Plan verarbeitet:
Sobald die Replikationen abgeschlossen sind, werden die Replica-Systeme auf der DR-Site hochgefahren. Status innerhalb VBR, die ersten Systeme befinden sich im Status Failover:
Und in den Plan Details im Veeam Recovery Orchestrator sieht das ganze so aus:
Die Warnung das die Quelle heruntergefahren ist, ist in diesem Szenario normal. Ohne unseres geplanten Failovers (Shutdown, Delta-Sync) hätte der Orchestrator die Systeme noch heruntergefahren. Also, sofern die Site noch erreichbar ist (nur eben ohne Delta-Sync)…
In vSphere auf der DR-Site sind die replizierten Systeme ebenfalls als gestartet zu sehen:
Alle Systeme sind nun wieder erreichbar, nur eben auf der DR-Site gehostet.
Der Check auf vorhandene Delta-Daten zeigt, diese wurden korrekt übernommen. Jeweils 10 GB Delta Daten, als auch das Layout entsprechen den Anpassungen aus der Quelle.
Innerhalb des Orchestrators ist der Plan durchgelaufen, wie oben erwähnt, beziehen sich die Warnungen auf die bereits ausgeschalteten Systeme:
Identisch zu einem Planned Failover ist die Operation noch nicht abgeschlossen, das System ist auf der DR-Site zwar funktionell, der Vorgang muss aber noch im VRO (via Continue bzw. Undo) abgeschlossen werden.
Continue
Hierbei müssen wir unterscheiden, zwischen einer permanenten Übernahme durch die DR-Site als neue primäre Lokation (Permanent Failover), oder ggfs. steht die produktive Site wieder zur Verfügung, neu erzeugte Delta-Daten in der DR-Site sollen hierbei sicherlich zur Quell/produktiven Site übertragen werden (Failback).
Die Option Permanent Failover sollte gewählt werden, wenn die Quellseite unwiederbringlich verloren ist (ein permanenter Verlust des Standortes). Somit würden die Replicas in der DR-Site zum finalen primären System werden.
Via Option Failback / Prepare to failback werden die erzeugten Delta-Daten aus der DR-Site während des Failovers auf die vorhandene Produktions-Seite migriert bzw. übernommen.
Hinweis: dieses gezeigte Szenario könnte einem temporären Shutdown der produktiven Seite entsprechen (z.B. einer länger andauernden Stromunterbrechung) – In der Regel wird hierfür dann die zweite / DR-Site produktiv geschaltet. Nachdem die Quelle wieder zur Verfügung steht, möchte man auf die ursprüngliche Site zurück wechseln und die zwischenzeitlich erzeugten Daten ebenfalls mit übernehmen. Somit wäre in diesem Beispiel die Wahl Failback zu wählen!
Ich habe für das Failback Szenario auf der DR-Site auch Änderungen durchgeführt – um aufzuzeigen, dass auch diese übernommen werden:
Als Recovery Location kann in diesem Beispiel Original VM Location gewählt werden.
Ich wähle die Quick Rollback Funktion aus, da mein Szenario keinem Hardware-Fehler oder Stromausfall voraus ging, somit spare ich etwas Zeit beim Wiederanlauf.
Die restlichen folgenden Settings, also VM Tags und Switchover (hier Failback now oder Prepare for failback) belasse ich auf Default und erhalte anschließend eine Übersicht der gewählten Aktionen.
Der Vorgang wird anschließend mit Finish gestartet.
Failback im Detail
Sobald der Failback Vorgang gestartet wird, sieht man im Orchestrator innerhalb der Plan Details die jeweiligen Steps.
Da als Ziel die Option Original VM Location gewählt wurde, wird auch hier beim Check ein Skipped (mit gelben Ausrufezeichen) protokolliert – was allerdings so normal ist.
Gleiches gilt für die Steps VM Power Actions und Veeam Job Actions, da diese im Recovery Plan bewusst auf Skip gesetzt wurden:
Innerhalb Veeam Backup & Replication ist die Operation ebenfalls einzusehen und läuft in den Running Task als Restore Session (vom Typ Failback).
Während diesem Step laufen die Systeme noch auf der DR-Site:
Sobald die Berechnung der Original- und Replica-Signaturen abgeschlossen ist, werden die Replica Systeme auf der DR-Site heruntergefahren und die Delta Daten repliziert.
Wie auf den Screenshots zu sehen, ist das erste System bereits abgeschlossen und auf der ursprünglichen produktiven Site wieder online, das zweite System wird noch verarbeitet:
Ebenfalls sind im Orchestrator die jeweiligen Schritte detailliert nachzuvollziehen:
Zwischenzeitlich sind die beiden ersten Systeme aus dem Gold Level bereits abgeschlossen, ein kurzer Blick via RDP zeigt, dass die Änderungen und Delta-Daten, die auf der DR-Site erzeugt wurden, ebenfalls vorhanden sind:
Wenn alle Schritte abgeschlossen sind, können wir via Continue und gefolgter Credentials Eingabe…
…und Bestätigung via Finish, die Operation abschließen.
In VBR ist anschließend kein Replication- oder Failover-Task mehr aktiv. Die vorhanden Replicas sind wieder im Status Ready.
In VRO muss der Recovery Plan (immer noch im Status In-Use) nun zurückgesetzt werden. Hierzu wird der Plan ausgewählt und im Kontext-Menü die Option Reset gewählt.
Es folgt erneut die Eingabe der Credentials, die Option auf einen Quick Check (Default aktiviert) und die Übersicht, die mit Finish bestätigt wird:
Diese Schritte haben nun detailliert ein Step-by-Step Szenario für einen planned Failover Plan via Veeam Recovery Orchestrator beschrieben.
Undo
Die Option Undo wird gewählt, wenn der Failover in der DR-Site beendet werden soll (z.B. der primäre Standort ist wieder erreichbar) und eine Übernahme der neu erzeugten Delta-Daten nicht relevant ist. Dabei werden die VMs auf der DR-Site wieder heruntergefahren (Änderungen auf der DR-Site gehen verloren)!
Zusammenfassung
Obwohl aktuell eine Built-In Planned Failover Funktion kein Bestandteil des Veeam Recovery Orchestrator’s ist, ist es trotzdem möglich, diese über Pre-plan steps zu verwenden.
Verglichen mit einem Failover Plan innerhalb VBR besteht u.a. also die Möglichkeit via Tags die Auswahl der Systeme jederzeit dynamisch zu halten. Ebenfalls unterstützen die entsprechenden DataLab Tests (die mehr Features bieten als ein klassisches SureBackup bzw. SureReplica), euch bei der Überprüfung Eurer DR-Szenarien.
Außerdem noch zu erwähnen die in VRO integrierte und detaillierte Reporting Funktion:
Klar, eigentlich wird der VRO genutzt, um schnellstmöglich Workloads auf einer DR-Site bereit zu stellen und nicht erst vorab von der Quellseite die Delta-Daten zu replizieren – aber es gibt eben auch solche Anforderungen 😉.
Viel Spaß beim Ausprobieren!