Mit Disaster-Recovery-Plänen arbeiten
Ein Disaster Recovery-(DR-)Plan beschreibt die Vorgänge, die für die Private Cloud Appliance-Ressourcen ausgeführt werden müssen, die unter dem Schutz des Disaster Recovery-Service stehen.
Ein DR-Plan ist mit einer DR-Konfiguration verknüpft und wird von einem Administrator entweder ausgeführt, wenn ein Vorfall auf Standortebene erkannt wird (Failover), oder wenn einer der Sites offline gesetzt werden muss (Switchover). Wenn das betroffene System nach einem Failover wieder online ist, werden Postfailover-Vorgänge ausgeführt, um sicherzustellen, dass beide Systeme zur Ausführung neuer DR-Vorgänge bereit sind.
In den folgenden Abschnitten wird erläutert, wie DR-Pläne erstellt und ausgeführt werden:
Info über DR-Vorgänge und Standardpläne
Der native DR-Service stellt Pläne mit Standardschritten für jeden Vorgangstyp bereit. DR-Planschritte können angepasst werden. Die integrierten Pläne sind wie folgt konfiguriert:
- Switchover-Plan
-
Wenn ein Switchover ausgeführt wird, tritt kein Ausfall auf, sodass beide Peer-Systeme online sind. Ziel ist es, alle in der DR-Konfiguration abgedeckten Ressourcen vom primären System (A) in das Standby-System (B) zu verschieben. Nach Abschluss wird System B zur Primärdatenbank und System A zur Standbydatenbank für die betreffenden Ressourcen.
Der Plan beginnt mit Vorabprüfungen, um sicherzustellen, dass beide Systeme die Anforderungen erfüllen, damit Compute-Instanzen im Primärsystem gestoppt und im Standbysystem erneut gestartet werden können. Zu den Vorabprüfungen gehören Sitezuordnungen sowie andere kritische Elemente, wie Tags, Sicherheitslisten oder Netzwerksicherheitsgruppen. Die Vorabprüfung zur Rollenumkehr stellt insbesondere sicher, dass sich die ZFS Storage Appliance in jedem Rack im richtigen Status befindet.
Wenn die Vorabprüfungen fehlerfrei abgeschlossen werden, wird die DR-Konfiguration auf dem primären System (A) gesperrt, und die zugehörigen Compute-Instanzen werden gestoppt, sodass die Rollenrückbuchung beginnen kann. Basierend auf den zwischen den Peer-Systemen ausgetauschten Ressourcenmetadaten und den replizierten Daten in der Standby-ZFS Storage Appliance ist das Zielsystem (B) bereit, die primäre Rolle für die Instanzen in der DR-Konfiguration zu übernehmen. Der Replikationsprozess wird rückgängig gemacht und kann das Quellsystem (A) sofort nach Abschluss des Switchovers als Standby verwenden.
Mit den replizierten Volumes werden die Compute-Instanzen in der DR-Konfiguration auf dem Standbysystem (B) gestartet. Im Standby-System wird eine identische DR-Konfiguration erstellt, wobei alle Quell- und Zielressourcen in den Sitezuordnungen invertiert sind. Die Metadaten der neu gestarteten Instanzen werden in der DR-Konfiguration gespeichert. Auf dem primären System (A) wird eine Bereinigung ausgeführt: Die DR-Konfiguration ist deaktiviert, und die zugehörigen Compute-Instanzen werden beendet.
Um den Switchover abzuschließen, wird die Datenreplikation vom neuen Primärsystem (B) auf das Standbysystem (A) gestartet, die DR-Pläne werden in das neue Standby-System (A) verschoben, und das Speicherprojekt und die Metadaten, die mit der ursprünglichen DR-Konfiguration verknüpft sind, werden aus System A gelöscht.
- Failover-Plan
-
Ein Failover wird auf dem Standby-System ausgeführt, wenn eines der Peer-Systeme ausfällt. Ziel ist es, alle Ressourcen wiederherzustellen, die in der DR-Konfiguration auf dem Standby-System (B) abgedeckt sind, sodass der Service fortgesetzt werden kann. Die Failover-Schritte ähneln dem Switchover-Plan, aber keiner der Vorgänge auf dem primären System (A) kann ausgeführt werden. Das primäre System kann nicht bereinigt werden, bis es wieder online ist.
Der Plan beginnt mit Vorabprüfungen, um sicherzustellen, dass das Standby-System und seine ZFS Storage Appliance den richtigen Status aufweisen, um die in der DR-Konfiguration abgedeckten Ressourcen hochzufahren. Wenn die Vorabprüfungen ohne Fehler abgeschlossen sind, beginnt die Rollenrückbuchung.
Mit den replizierten Metadaten und Ressourcen werden die Compute-Instanzen in der DR-Konfiguration auf dem Standby-System (B) gestartet, das die primäre Rolle übernimmt. Auf System B, das zur primären Konfiguration geworden ist, wird eine identische DR-Konfiguration erstellt, wobei invertierte Sitezuordnungen und Metadaten aus den neu gestarteten Instanzen erfasst werden. Bevor das ursprüngliche primäre System (A) wieder online geht, wird der Replikationsprozess rückgängig gemacht und kann das System A als Standby verwenden.
Wenn das ursprüngliche primäre System (A) schließlich online ist, werden die verbleibenden Schritte zum Zurücksetzen der DR-Konfiguration in den korrekten Arbeitszustand ausgeführt, indem der Postfailover-Plan ausgeführt wird.
- Nachrüstungsplan
-
Nach einem Failover wird ein Postfailover-Plan ausgeführt, wenn das System, bei dem ein Ausfall aufgetreten ist, wieder online ist und die Peerverbindung wiederhergestellt wird. Ziel ist es, die DR-Konfiguration auf dem ausgefallenen Primärsystem (A) zu bereinigen und als Standby für das neue Primärsystem (B) einzurichten.
In einem Postfailover-Plan sind keine Vorabprüfungen vorhanden. System A ist nach einem Ausfall wieder online und muss bereinigt werden: Die DR-Konfiguration ist deaktiviert, und die zugehörigen Compute-Instanzen werden beendet. Die Datenreplikation vom neuen Primärsystem (B) auf das Standby-System (A) wird gestartet, die DR-Pläne werden in das neue Standby-System (A) verschoben, und das Speicherprojekt und die Metadaten, die mit der ursprünglichen DR-Konfiguration verknüpft sind, werden aus System A gelöscht.
Um Ressourcen, die ursprünglich auf System A gehostet wurden, von System B zurück zu verschieben, muss der Administrator ein Switchover von B auf A für die entsprechenden DR-Konfigurationen durchführen.