Für Disaster Recovery konfigurieren

Mit den in diesem Lösungs-Playbook bereitgestellten Skripten können Sie einen YAML-Snapshot in einem primären Kubernetes-Cluster erstellen und in einem anderen (sekundären) Kubernetes-Cluster wiederherstellen. Es ist wichtig, die Konfiguration zu planen und die Anforderungen zu verstehen, bevor Sie den YAML-Snapshot herunterladen und mithilfe der Skripte konfigurieren.

Hinweis:

Bei dieser Lösung wird davon ausgegangen, dass beide Kubernetes-Cluster, einschließlich des Kontrollplans und der Worker-Knoten, bereits vorhanden sind.

Konfiguration planen

Planen Sie die Ressourcen und die Konfiguration auf dem sekundären System basierend auf dem primären System. Die Skripte erfordern, dass beide Kubernetes-Cluster bereits vorhanden sind. Sie müssen mit dem Kubernetes-Befehlszeilentool kubectl auf beide Cluster zugreifen können, um Befehle für sie auszuführen.

Hinweis:

Bei dieser Lösung wird davon ausgegangen, dass beide Kubernetes-Cluster, einschließlich des Kontrollplans und der Worker-Knoten, bereits vorhanden sind. Die in diesem Handbuch bereitgestellten Empfehlungen und Skripte prüfen keine Ressourcen, Control Plane oder Worker-Knotenkonfiguration.

Das folgende Diagramm zeigt, dass Sie den Artefakt-Snapshot bei der Konfiguration in völlig anderen Kubernetes-Clustern wiederherstellen können.

Beschreibung der Abbildung kube-api-dr.png

Befolgen Sie die folgenden Anforderungen für Restore bei der Konfigurationsplanung:

Stellen Sie sicher, dass die erforderlichen Worker-Knoten und Ressourcen im primären Knoten im sekundären Knoten verfügbar sind.
Dazu gehören die Shared Storage-Mounts, Load Balancer und Datenbanken des Pods. Es umfasst auch alle externen Systeme, die von den wiederherzustellenden Namespaces verwendet werden.
Erstellen Sie manuell die erforderlichen persistenten Volumes, die von den beteiligten Namespaces verwendet werden, bevor Sie die Skripte ausführen.

Dies ist die Standardaktion. Die Skripte erstellen die persistenten Volume-Ansprüche, die in der Primärdatenbank verwendet werden. Da persistente Volumes jedoch von verschiedenen Claims in verschiedenen Namespaces gemeinsam verwendet werden können, erwarten die Automatisierungsskripte, dass Sie persistente Volumes im sekundären Cluster manuell erstellen, bevor Sie die extract-apply-Skripte ausführen.

Alternativ können Sie pv zur Variablen nons_artifacts_types in der Datei maak8DR-apply.env hinzufügen (d.h. export nons_artifacts_types="crd clusterrole clusterrolebinding pv verwenden"). Dadurch werden die Skripte angewiesen, auch die persistenten Volumes in sekundären zu erstellen. In diesem zweiten Fall müssen Sie bestimmen, ob Konflikte mit anderen persistenten Volume-Ansprüchen auftreten können.
Vergewissern Sie sich, dass das sekundäre Cluster über den entsprechenden Zugriff auf die Containerimages verfügt, die von den zu replizierenden Namespaces verwendet werden:
- Secrets für den Zugriff auf Container-Registrys, die in den zu replizierenden Namespaces vorhanden sind, werden von den in diesem Playbook bereitgestellten Skripten kopiert. Wenn die Zugangsdaten für die Registrys in anderen Namespaces gespeichert sind, müssen Sie sie manuell sekundär erstellen. Alternativ können Sie die Zugangsdaten mit maak8sapply: my_ns beschriften (wobei my_ns der Namespace ist, der wiederhergestellt wird), sodass das Secret auch im YAML-Snapshot enthalten ist. Beispiel:
```
kubectl label secret regcredfra -n other_namespace 
maak8sapply=namespace_being_backedup
```
- Wenn Sie Bilder verwenden, die manuell in die primären Worker-Knoten geladen wurden, müssen Sie sie auch manuell in die sekundären Worker-Knoten laden.
  
  Hinweis:
  Die bereitgestellten Skripte melden die Images, die in den zu replizierenden Namespaces verwendet werden.
Stellen Sie Zugriff auf die primären und sekundären Cluster über Bastionsknoten bereit, die kubectl-Vorgänge für die Kube-API-Endpunkte jedes Clusters ausführen können.
Es ist möglich, einen dritten Knoten zu verwenden, der sowohl ssh als auch scp (primär und Standby) verwenden und die DR-Synchronisierung koordinieren kann. Um jedoch unnötige Hops und Session-Overhead zu vermeiden, empfiehlt Oracle, die primäre Bastion als DR-Koordinator zu verwenden. Andere Optionen erfordern die Anpassung der bereitgestellten Skripte.
Verwenden Sie das Label maak8sapply: my_ns, wenn im Backup enthaltene Ressourcen ohne Namespace beim Wiederherstellen von my_ns namespace als sekundär angewendet werden sollen.

Bei Artefakten, die sich im Root-Verzeichnis des Clusters befinden (d.h. nicht Teil eines genauen Namespace), suchen die Skripte nach namespace:- und group:-Feldreferenzen, die die Namespaces-Namen enthalten. Wenn Sie andere im Backup enthaltene Ressourcen ohne Namespace benötigen, können Sie sie für das Hinzufügen kennzeichnen.

Beispiel: Die benutzerdefinierte Ressourcendefinition domains.weblogic.oracle ist nicht Teil eines Namespace. Sie können sie jedoch mit dem folgenden Befehl in das apply-Vorgangslabeling aufnehmen: kubectl label crd domains.weblogic.oracle maak8sapply=opns.

Konfigurieren

Konfigurieren Sie das Disaster Recovery von YAML-Snapshots.

Laden Sie alle Disaster Recovery-Skripte für YAML-Snapshots von "Code herunterladen" herunter.

Hinweis:
Alle Skripte müssen sich in demselben Pfad befinden, da die Hauptskripte andere Hilfsskripte verwenden.
Bearbeiten Sie das Skript maak8DR-apply.env, und aktualisieren Sie die Adressen und SSH-Schlüssel, die für den Zugriff auf das sekundäre System erforderlich sind.
Beispiel:
```
export user_sec=opc
export ssh_key_sec=/home/opc/Key.ppk
#Secondary bastion node
export sechost=10.10.0.23
```
Passen Sie die Werte für exclude_list und nons_artifacts_types nach Bedarf an.
- exclude_list: Dies ist eine durch Leerzeichen getrennte Liste der Namespaces, die aus dem Backup ausgeschlossen werden sollen, selbst wenn versucht wird, ALLE benutzerdefinierten Namespaces zu sichern. Dadurch wird vermieden, dass auf der Control Plane zugehörige Namespaces kopiert werden, die auf der sekundären Ebene nicht anwendbar sind.
- nons_artifacts_types: Dies ist die Liste oder Artefakte, die zum Root-Baum gehören (d.h. nicht Teil eines genauen Namespace), aber auch im Snapshot enthalten sein müssen. Das Framework sucht nach Referenzen auf die Namespaces, die gesichert werden.
Im Allgemeinen können Sie die in der Datei angegebenen Standardwerte verwenden:
```
#List of namespaces that will be excluded from the backup
export exclude_list="kube-system kube-flannel kube-node-lease kube-public"
#Root artifacts that will be included
export nons_artifacts_types="crd clusterrole clusterrolebinding"
```
Führen Sie das Skript maak8DR-apply.sh aus, das die ausgewählten Namespaces zur Replikation als Argumente bereitstellt.
- Wenn Sie keine Argumente angeben, replizieren die Skripte ALLE Namespaces ohne die in der Variablen exclude_list angegebenen Namespaces.
- Wenn Sie eine genaue Liste von Namespaces verwenden, müssen Sie diese basierend auf den Abhängigkeiten mit anderen Namespaces sortieren.
  
  Das heißt, wenn der Namespace soans von Services im Namespace opns abhängt oder diese verwendet, muss opns zuerst in der Liste angezeigt werden. Beispiel: Führen Sie anstelle von ./maak8DR-apply.sh soans opns Folgendes aus:
```
./maak8DR-apply.sh opns soans
```

Verifizieren

Nachdem Sie das Skript maak8DR-apply.sh ausgeführt haben, prüfen Sie, ob alle Artefakte, die im primären Cluster vorhanden waren, im sekundären Cluster repliziert wurden. Prüfen Sie das sekundäre Cluster, und prüfen Sie, ob die Pods auf der sekundären Site fehlerfrei ausgeführt werden.

Wenn Sie das Skript maak8DR-apply.sh ausführen, erstellt das Framework das Verzeichnis working_dir als /tmp/backup.date. Wenn Sie die Skripte maak8-get-all-artifacts.sh und maak8-push-all-artifacts.sh einzeln ausführen, wird das Arbeitsverzeichnis jeweils als Argument in der Befehlszeile bereitgestellt.

Prüfen Sie den Status des Sekundärs, bis die erforderlichen Pods mit dem Status des Primärs übereinstimmen.
Standardmäßig werden die Pods und Deployments in der sekundären Region gestartet. Am Ende der Wiederherstellung wird der Status des sekundären Clusters angezeigt. Einige Pods benötigen möglicherweise zusätzliche Zeit, um den Status RUNNING zu erreichen.
Prüfen Sie die Datei $working_dir/date/backup-operations.log in der Primärdatenbank auf mögliche Fehler in den Extract- und Apply-Vorgängen.
Prüfen Sie die Dateien $working_dir/restore.log und $working_dir/date/restore-operations.log im sekundären Verzeichnis auf mögliche Fehler in den Extract- und Apply-Vorgängen.
Die Datei restore-operations.log enthält die detaillierten Wiederherstellungsvorgänge.