Omnissa Access unterstützt die Notfallwiederherstellung unter Verwendung eines Sicherungs-und-Wiederherstellungsmodells mit einer freigegebenen NFS-Bereitstellung. In diesem Modell hat ein sekundärer Cluster Zugriff auf die vom primären Cluster erstellten Sicherungsdaten. Nach Eintritt eines deklarierten DR-Ereignisses wird der sekundäre Cluster manuell zum primären Cluster heraufgestuft und übernimmt den Lese-/Schreibdatenverkehr. Das Failback auf die ursprüngliche Site ist ein geplanter manueller Vorgang. Dies geschieht nicht automatisch. Wenn der ursprüngliche primäre Cluster wieder verfügbar ist, verbleibt er in der sekundären Rolle, bis ein geplantes Failback ausgeführt wird.
Dieses Thema beschreibt, wie Sie den NFS-Sicherungsspeicher konfigurieren, Sicherungszeitpläne verwalten, erforderliche Daten des Bootstrap-Knotens sichern und Omnissa Access während eines Failovers aus einer Sicherung wiederherstellen.
Voraussetzungen
Stellen Sie vor dem Konfigurieren der Notfallwiederherstellung sicher, dass die folgenden Bedingungen erfüllt sind:
- Eine replizierte NFS-Freigabe wird konfiguriert und ist sowohl für die Knoten des primären Clusters als auch für die Knoten des sekundären Clusters über das Netzwerk zugänglich.
- Der sekundäre Cluster wird mit derselben Asset-Paketversion wie der Quellcluster bereitgestellt.
- Sie verfügen über Administratorzugriff auf den Bootstrap-Knoten des primären Clusters, um geheime Schlüssel und Konfigurationsdateien zu sichern.
Konfigurieren von NFS-Exporten auf dem NFS-Server
Da Sicherungsdienste als Root ausgeführt werden, muss der NFS-Export die Option no_root_squash enthalten. Überprüfen Sie auf dem NFS-Server die Exportkonfiguration in /etc/exports:
cat /etc/exports
Die Ausgabe sollte einen Eintrag im folgenden Format enthalten:
<NFS-MOUNT-POINT> <NFS-CLIENT-IP>(rw,sync,no_subtree_check,no_root_squash)
<NFS-CLIENT-IP> steht für den IP-Bereich oder die Gruppe von IP-Adressen, die alle Clusterknoten abdeckt, die für den Zugriff auf die Bereitstellung zugelassen sind. Wenn beispielsweise die Quellclusterknoten Adressen im Bereich 10.48.34.100–10.48.34.105 verwenden, legen Sie <NFS-CLIENT-IP> auf 10.48.34.0/24 fest, um das vollständige Subnetz abzudecken. Wenn der sekundäre Cluster während eines Failovers zum primären Cluster heraufgestuft wird, müssen dessen Knotenadressen ebenfalls innerhalb des zulässigen IP-Bereichs liegen.
Konfigurieren der Datei „profile.yml“ für die NFS-Sicherung
Der Quellcluster muss so konfiguriert sein, dass Sicherungen auf eine freigegebene NFS-Bereitstellung geschrieben werden, bevor Dienste bereitgestellt werden. Diese Sicherungen werden verwendet, um den sekundären Cluster während eines Failovers wiederherzustellen.
-
Öffnen Sie auf dem Bootstrap-Knoten des Quellclusters
/root/<cluster_name>/profile.yml. -
Suchen Sie die folgenden Zeilen, geben Sie Ihre NFS-Serverdetails ein und heben Sie die Kommentierung auf:
nfs_host: <NFS-HOST-IP> nfs_path: <NFS-MOUNT-POINT> nfs_version: 4 -
Speichern Sie die Datei und fahren Sie dann mit der Dienstbereitstellung fort, wie in Phase 4 und Phase 5 dieses Handbuchs beschrieben.
Hinweis: Falls die NFS-Details vor der ersten Dienstbereitstellung nicht in
profile.ymlenthalten waren, fügen Sie diese nachträglich hinzu und stellen Sie die sicherungsabhängigen Dienste erneut bereit:> ```bash > wso services deploy -s postgres > wso services deploy -s control-plane-backup > wso services deploy -s opensearch > ``` -
Um zu bestätigen, dass die NFS-Bereitstellung von einem anderen Computer im sekundären Cluster aus erreichbar ist, führen Sie die folgenden Befehle von einer separaten virtuellen Maschine aus:
# Mount the NFS share manually to test connectivity mount -t nfs <NFS-IP>:<NFS-MOUNT-POINT> /mnt # List the NFS exports visible to the client showmount -e <NFS-IP>Die Ausgabe
showmount -esollte einen Eintrag für den konfigurierten Bereitstellungspunkt enthalten:<NFS-MOUNT-POINT> <NFS-IP>
Sichern von Bootstrap-Knotendaten
Die folgenden Elemente des primären Bootstrap-Knotens müssen auf dem sekundären Bootstrap-Knoten verfügbar sein, bevor eine Wiederherstellung fortgesetzt werden kann. Sichern Sie diese Elemente an einem sicheren Ort, bevor ein DR-Ereignis eintritt.
Omnissa empfiehlt, diese Daten auf demselben NFS-Server zu speichern, der für Dienstsicherungen verwendet wird, jedoch auf einer separaten NFS-Bereitstellung, um Beeinträchtigungen der automatisierten Sicherungsvorgänge zu vermeiden.
| Element | Pfad auf primärem Bootstrap-Knoten |
|---|---|
| TLS-Zertifikate | /root/<cluster_name>/cp-cluster/secrets/cp-cluster/tls |
| Vault-Entsiegelungsschlüssel und Root-Schlüssel | /root/<cluster_name>/cp-cluster/secrets/cp-cluster/vault |
| Umgebungsvariablen der Dienstbereitstellung | /root/<cluster_name>/additional_env_vars.env |
| Access-Dienstprofil | /root/<cluster_name>/access/access-profile.yml |
Konfigurieren der Sicherungshäufigkeit und der Aufbewahrungsdauer
Sie können steuern, wie häufig Sicherungen erstellt werden und wie lange sie aufbewahrt werden, indem Sie Umgebungsvariablen in der additional_env_vars.env-Datei auf dem Bootstrap-Knoten festlegen. Diese Einstellungen bestimmen Ihr Wiederherstellungspunktziel (Recovery Point Objective, RPO) – die maximale Datenmenge, die im Falle eines Ausfalls verloren gehen könnte.
| Variable | Beschreibung |
|---|---|
POSTGRESQL_FULL_BACKUP_CRON_SCHEDULE | Cron-Zeitplan für vollständige Datenbanksicherungen |
POSTGRESQL_DIFF_BACKUP_CRON_SCHEDULE | Cron-Zeitplan für Datenbank-Delta-Sicherungen |
CONTROL_PLANE_BACKUP_CRON_SCHEDULE | Cron-Zeitplan für Sicherungen von Steuerungsebenenkomponenten (Nomad, Consul, Vault) |
KEEP_DAYS_CP | Aufbewahrungszeitraum in Tagen für Sicherungen der Steuerungsebene |
WALG_RETENTION_DAYS | Aufbewahrungsdauer in Tagen für Datenbanksicherungen |
KEEP_DAYS_POSTGRES_BACKUP_LOGS | Aufbewahrungsdauer in Tagen für Protokolldateien der Datenbanksicherung |
Datenbanksicherungstypen
Omnissa Access verwendet zwei ergänzende Sicherungstypen für die PostgreSQL-Datenbank.
Vollsicherung
Eine Vollsicherung erstellt einen vollständigen Snapshot des gesamten PostgreSQL-Datenverzeichnisses zu einem bestimmten Zeitpunkt. Vollständige Sicherungen sind eigenständig und können ohne zusätzliche Sicherungsdateien wiederhergestellt werden. Standardmäßig wird einmal täglich um 5:00 Uhr UTC eine vollständige Datenbanksicherung ausgeführt, die als Baseline für Delta-Sicherungen dient.
Delta-Sicherung
Ein Delta-Backup erfasst nur die Datenseiten, die sich seit der letzten Vollsicherung geändert haben. Delta-Sicherungen sind kleiner und schneller abzuschließen als Vollsicherungen, sind jedoch nicht eigenständig – für die Wiederherstellung aus einer Delta-Sicherung sind sowohl die aktuellste Vollsicherung als auch die Delta-Sicherung erforderlich. Standardmäßig wird eine Delta-Sicherung einmal täglich um 17:00 Uhr UTC ausgeführt.
Zusammen bieten die Voll- und Delta-Sicherungsaufträge eine lückenlose tägliche Abdeckung. Tritt zwischen geplanten Sicherungen ein Fehler auf, wird bei der Wiederherstellung die letzte Vollsicherung verwendet, auf die das aktuellste Delta angewendet wird, wodurch der potenzielle Datenverlust auf etwa 12 Stunden begrenzt wird.
Tiefe der Delta-Sicherungskette
Die maximale Anzahl von Delta-Sicherungsebenen, die auf eine einzelne Vollsicherung aufgesetzt werden können, ist auf 2 festgelegt. Dieser Grenzwert wird intern von WALG_DELTA_MAX_STEPS erzwungen und ist nicht konfigurierbar.
Full Backup (base)
└── Delta 1 (changes since Full Backup)
└── Delta 2 (changes since Delta 1) ← maximum chain depth
Wenn die Kette das konfigurierte Maximum erreicht, stuft WAL-G die nächste geplante Delta-Sicherung automatisch zu einer neuen Vollsicherung herauf.
Sie können den Zeitplan für Voll- und Deltasicherungen anpassen, müssen jedoch sicherstellen, dass zwischen aufeinanderfolgenden Vollsicherungen nicht mehr als zwei Deltasicherungen ausgeführt werden. Das Überschreiten dieses Grenzwerts wird nicht unterstützt.
FQDN- und Netzwerkanforderungen
Um ein Failover zu unterstützen, ohne dass Änderungen an der Endbenutzer- oder Connector-Konfiguration erforderlich sind, muss der sekundäre Cluster vor dem Eintreten eines DR-Ereignisses die folgenden Anforderungen erfüllen:
- TLS-Zertifikate auf sekundären Cluster-Endpoints müssen für denselben vollqualifizierten Domänennamen (FQDN) wie der primäre Cluster gültig sein. Zertifikatsrotationsprozesse müssen sowohl die primäre als auch die sekundäre Site konsistent abdecken.
- Firewallregeln müssen ausgehenden Datenverkehr zu primären und sekundären Cluster-Endpoints zulassen. Veröffentlichte IP-Adressbereiche müssen für beide Sites aktiv verwaltet werden.
- Der Sitzungsstatus des Connectors muss auf dem sekundären Gateway vollständig wiederherstellbar sein, ohne feste Abhängigkeit von Sitzungsspeicher, der nur auf dem primären Cluster vorhanden ist.
Wiederherstellen von Omnissa Access aus einer Sicherung
Diese Vorgehensweise beschreibt, wie der sekundäre Cluster während eines Failovers als neuer Primärcluster aktiviert wird. Nach Abschluss der Wiederherstellung übernimmt der sekundäre Cluster den gesamten Lese- und Schreibdatenverkehr. Der ursprüngliche primäre Cluster wird, sobald er wieder verfügbar ist, bis zur Durchführung eines geplanten Failbacks als neuer sekundärer Cluster behandelt.
Wichtig: Stellen Sie vor Beginn dieses Vorgangs sicher, dass der ursprüngliche primäre Cluster vom sekundären Cluster aus nicht erreichbar ist. Wenn der ursprüngliche Cluster während der Wiederherstellung weiterhin erreichbar ist, versuchen OpenSearch und PostgreSQL möglicherweise, Knoten aus dem ursprünglichen Cluster zum wiederhergestellten Cluster hinzuzufügen.
Hinweis: Omnissa empfiehlt die Durchführung zeitgesteuerter Wiederherstellungstests in einer Nicht-Produktionsumgebung, bevor die Notfallwiederherstellung in der Produktion bereitgestellt wird. Dadurch lassen sich realistische Schätzungen für das Wiederherstellungspunktziel (Recovery Time Objective, RTO) basierend auf Ihren tatsächlichen Datenmengen ermitteln.
Voraussetzungen
Überprüfen Sie vor Beginn des Wiederherstellungsvorgangs Folgendes:
- Der sekundäre Cluster wird mit derselben Asset-Paketversion wie der Quellcluster bereitgestellt, um sicherzustellen, dass alle Omnissa Access-Dienst-Images übereinstimmen.
- Die unter Sichern der Bootstrap-Knotendaten aufgeführten Bootstrap-Knotendaten sind auf dem sekundären Bootstrap-Knoten zugänglich.
Vorgehensweise
Schritt 1: Bereitstellen des sekundären Clusters
Stellen Sie neue virtuelle Maschinen bereit und stellen Sie das Asset-Paket der Steuerungsebene auf ihnen bereit, indem Sie dieselbe Asset-Paketversion wie der Quellcluster verwenden. Der sekundäre Cluster muss dieselbe Konfiguration wie der Quellcluster aufweisen.
Wichtig: Stellen Sie in diesem Schritt nur die CP-Plattformdienste bereit – Vault, Consul und Nomad. Stellen Sie in dieser Phase keine Omnissa Access-Dienste bereit. Access-Dienste werden im weiteren Verlauf des Vorgangs wiederhergestellt.
Bevor Sie fortfahren, sichern Sie das Verzeichnis /root/<cluster_name>/cp-cluster/secrets/cp-cluster auf dem sekundären Bootstrap-Knoten.
Geschätzte Zeit: 30 Minuten
Schritt 2: Erstellen eines Snapshots der sekundären Clusterknoten
Nachdem die Steuerungsebene erfolgreich bereitgestellt wurde, erstellen Sie Snapshots der virtuellen Maschine von allen sekundären Clusterknoten. Diese Snapshots dienen als bekannter, fehlerfreier Wiederherstellungspunkt, falls der Notfallwiederherstellungsvorgang neu gestartet werden muss.
Hinweis: Wenn Sie diese Snapshots während des Wiederherstellungsvorgangs wiederherstellen, bestätigen Sie, dass Vault auf dem sekundären Cluster nicht versiegelt ist, bevor Sie fortfahren. Melden Sie sich mit den entsprechenden Anmeldedaten bei der Vault-Benutzeroberfläche an, um zu überprüfen, ob der Vault-Status auf „Entsiegelt“ gesetzt ist.
Schritt 3: Kopieren von geheimen Schlüsseln in den sekundären Cluster
Kopieren Sie die Ordner tls und vault von Ihrem Sicherungsspeicherort in das Verzeichnis backup_secrets des sekundären Clusters:
- Gesicherten
tls-Ordner kopieren →/root/<cluster_name>/cp-cluster/backup_secrets/tls - Gesicherten
vault-Ordner kopieren →/root/<cluster_name>/cp-cluster/backup_secrets/vault
Stellen Sie nach dem Kopieren sicher, dass das backup_secrets-Verzeichnis auf dem sekundären Bootstrap-Knoten beide Ordner enthält:
ls -lrt backup_secrets/
total 0
drwxr-x---. 2 root root 64 May 7 07:46 tls
drwxr-x---. 4 root root 30 May 7 07:46 vault
Schritt 4: Planen der Sicherungswiederherstellung
Führen Sie im sekundären Clusterverzeichnis den folgenden Befehl aus, um die Sicherung zu überprüfen und den Wiederherstellungspunkt zu bestätigen:
wso cp plan-restore-backup
Um den Zustand zu einem bestimmten Zeitpunkt wiederherzustellen, verwenden Sie das Flag -a mit einer Zeitangabe. Beispiel:
| Kennzeichnen | Bedeutung |
|---|---|
-a 1d | Letzte Sicherung bis zu einem Tag zuvor |
-a 2h | Letzte Sicherung bis zu zwei Stunden zuvor |
-a 30m | Letzte Sicherung bis zu 30 Minuten zuvor |
Dieses Flag legt das RPO für den Wiederherstellungsvorgang fest.
Schritt 5: Wiederherstellen von Steuerungsebenenkomponenten
Dieser Schritt stellt die Consul-Schlüssel-Wert-Daten und die geheimen Vault-Schlüssel auf dem sekundären Cluster wieder her.
-
Stellen Sie sicher, dass Vault auf dem sekundären Cluster entsiegelt ist.
-
Bestätigen Sie vor dem Ausführen des Wiederherstellungsbefehls, dass die Ordner
tlsundvaultinbackup_secretsauf dem sekundären Bootstrap-Knoten vorhanden sind:ls -lrt /root/<cluster_name>/cp-cluster/backup_secrets/In der Ausgabe sollten sowohl die
tls-Verzeichnisse als auch dievault-Verzeichnisse angezeigt werden:drwxr-x---. 2 root root 64 <date> tls drwxr-x---. 4 root root 30 <date> vault -
Führen Sie im Clusterverzeichnis Folgendes aus:
wso cp restore-backupDieser Befehl stellt die Consul-Schlüssel-Wert-Daten und die geheimen Vault-Schlüssel auf dem sekundären Cluster wieder her. Erwartete Ausgabe:
Imports KV in case of disaster recovery Backing up control plane credentials Restoring vault Restoring control plane credentials Resetting vault integration tokens Resetting vault integration token in nomad Resetting vault PKI integration token Updated vault with secrets after restore during Disaster recovery Adding PKI root and intermediate CA to truststore Deploying vault Restarting vault servers Unsealing Vault Enabling consul and nomad integration with vault Deploying consul Configuring consul connect CA provider Restarting the consul leader Restarting nomad scheduler agent Cleaning up Generating environment file with cluster details and secret tokensHinweis: Sollte bei diesem Schritt ein Fehler auftreten, setzen Sie alle virtuellen Maschinen des sekundären Clusters auf die in Schritt 2 erstellten Snapshots zurück, vergewissern Sie sich, dass Vault auf dem sekundären Cluster entsiegelt ist, und beginnen Sie den Vorgang ab Schritt 3 erneut.
Geschätzte Zeit: 15 Minuten
Schritt 6: Wiederherstellen von Diensten
Dieser Schritt stellt die Datenbank und alle Dienste wieder her. Während dieses Schritts werden keine Sicherungen erstellt.
-
Kopieren Sie die Umgebungsvariablendatei vom Sicherungsspeicherort in den sekundären Bootstrap-Knoten:
/root/<cluster_name>/additional_env_vars.env -
Kopieren Sie das Access-Dienstprofil auf den sekundären Bootstrap-Knoten:
/root/<cluster_name>/access/access-profile.yml -
Führen Sie in der
access-profile.yml-Datei die folgenden Schritte aus:- Aktualisieren Sie die Felder
ip_ignore_list_for_xff_headerundfqdn.ip, um die IP-Adressen und die Konfiguration des sekundären Clusters widerzuspiegeln. - Fügen Sie das Nomad-Subnetz zur
ip_ignore_list_for_xff_header-Liste hinzu.- Hinweis: Der Standardwert lautet
172.26.64.0/20. Wenn Sie sich für die Bereitstellung mit einem benutzerdefinierten Subnetz entschieden haben, aktualisieren Sie den Subnetzwert im Feldip_ignore_list_for_xff_headerentsprechend.
- Hinweis: Der Standardwert lautet
- Aktualisieren Sie die Felder
-
Aktualisieren Sie den DNS-Server, um den FQDN an den sekundären Cluster umzuleiten.
-
Vergewissern Sie sich, dass der ursprüngliche primäre Cluster offline oder nicht erreichbar ist.
-
Führen Sie den folgenden Befehl aus, um alle Dienste wiederherzustellen:
wso services restore --cps_image <cps-image>Hinweis: Sollte bei diesem Schritt ein Auftrag fehlschlagen, löschen Sie ihn und führen Sie denselben Befehl erneut aus.
Um nur einen bestimmten Dienst wiederherzustellen, fügen Sie das Flag
-sein:wso services restore -s <service-name> --cps_image <cps-image>Dabei ist
<cps-image>das Image-Tag der Steuerungsebenendienste, das der Bereitstellung des Quellclusters entspricht.Hinweis: Sollte bei diesem Schritt ein Fehler auftreten, setzen Sie alle virtuellen Maschinen des sekundären Clusters auf die in Schritt 2 erstellten Snapshots zurück, vergewissern Sie sich, dass Vault auf dem sekundären Cluster entsiegelt ist, und beginnen Sie den Vorgang ab Schritt 3 erneut.
Geschätzte Zeit: Mindestens 75 Minuten. Die tatsächliche Zeit skaliert linear mit dem Datenvolumen in PostgreSQL und OpenSearch.
Schritt 7: Abschließen der Wiederherstellung und Fortsetzen der Sicherungsvorgänge
Führen Sie den folgenden Befehl aus, um die wiederhergestellten Daten zu überprüfen und Sicherungsvorgänge auf dem neu zum primären Cluster heraufgestuften Cluster zu aktivieren:
wso services restore-complete --cps_image <cps-image>
Geschätzte Zeit: 10 Minuten
Angestrebte Wiederherstellungszeit
Die angestrebte Wiederherstellungszeit (Recovery Time Objective, RTO) hängt vom Datenvolumen in PostgreSQL und OpenSearch ab. Die erwartete Mindest-RTO beträgt etwa zwei Stunden, wobei die tatsächliche Zeit proportional zum Datenvolumen zunimmt. Omnissa empfiehlt die Durchführung regelmäßiger Wiederherstellungstests, um RTO-Werte zu ermitteln, die spezifisch für Ihre Bereitstellung gelten, bevor Sie sich im Rahmen eines produktiven Failovers auf dieses Verfahren verlassen.
War diese Seite hilfreich?