Configura per disaster recovery

È possibile utilizzare gli script forniti con questa guida di soluzione per creare uno snapshot YAML in un cluster Kubernetes primario e ripristinarlo in un altro cluster Kubernetes (secondario). È importante pianificare la configurazione e comprendere i requisiti prima di scaricare e utilizzare gli script per configurare lo snapshot YAML.

Nota

Questa soluzione presuppone che entrambi i cluster Kubernetes, inclusi il piano di controllo e i nodi di lavoro, esistano già.

Pianificare la configurazione

Pianificare le risorse e la configurazione nel sistema secondario in base al sistema primario. Gli script richiedono che entrambi i cluster Kubernetes esistano già. Per eseguire i comandi, è necessario essere in grado di accedere a entrambi i cluster con lo strumento della riga di comando Kubernetes, kubectl.

Nota

Questa soluzione presuppone che entrambi i cluster Kubernetes, inclusi il piano di controllo e i nodi di lavoro, esistano già. I suggerimenti e gli script forniti in questa guida non controllano le risorse, il piano di controllo o la configurazione dei nodi di lavoro.

Il diagramma riportato di seguito mostra che, quando è configurato, è possibile ripristinare lo snapshot dell'artifact in cluster Kubernetes completamente diversi.

Descrizione dell'immagine kube-api-dr.png

Quando si pianifica la configurazione, completare i seguenti requisiti per Restore:

Verificare che i nodi di lavoro e le risorse necessarie nel database primario siano disponibili nel database secondario.
Sono inclusi gli accessi, i load balancer e i database dello storage condiviso del pod. Include anche tutti i sistemi esterni utilizzati dagli spazi dei nomi in fase di ripristino.
Creare manualmente i volumi persistenti richiesti utilizzati dagli spazi dei nomi interessati prima di eseguire gli script.

Questa è l'azione predefinita. Gli script creeranno le richieste di volume persistenti utilizzate nel database primario. Tuttavia, poiché i volumi persistenti possono essere condivisi da richieste diverse in spazi di nomi diversi, gli script di automazione prevedono di creare manualmente volumi persistenti nel cluster secondario prima di eseguire gli script extract-apply.

In alternativa, è possibile aggiungere pv alla variabile nons_artifacts_types nel file maak8DR-apply.env (utilizzare export nons_artifacts_types="crd clusterrole clusterrolebinding pv"). Ciò indica agli script di creare anche i volumi persistenti in secondari. In questo secondo caso, spetta a te determinare se possono sorgere conflitti con altre richieste di volume persistenti.
Verificare che il cluster secondario disponga dell'accesso appropriato alle immagini del contenitore utilizzate dagli spazi dei nomi da replicare:
- I segreti utilizzati per accedere ai registri dei contenitori esistenti negli spazi dei nomi da replicare vengono copiati dagli script forniti con questa guida. Se le credenziali dei registri sono memorizzate in altri spazi di nomi, è necessario crearle manualmente in uno spazio secondario. In alternativa, è possibile assegnare un'etichetta alle credenziali con maak8sapply: my_ns (dove my_ns è lo spazio di nomi che viene ripristinato) in modo che il segreto venga incluso anche nello snapshot YAML. Di seguito sono riportati alcuni esempi.
```
kubectl label secret regcredfra -n other_namespace 
maak8sapply=namespace_being_backedup
```
- Se si utilizzano immagini caricate manualmente nei nodi di lavoro principali, è necessario caricarle anche manualmente nei nodi di lavoro secondari.
  
  Nota
  Gli script forniti riporteranno le immagini utilizzate negli spazi dei nomi da replicare.
Fornire l'accesso ai cluster primari e secondari tramite nodi bastion in grado di eseguire le operazioni kubectl sugli endpoint API Kube di ciascun cluster.
È possibile utilizzare un terzo nodo che può essere ssh o scp per entrambi (primario e in standby) e coordinare la sincronizzazione DR. Tuttavia, per evitare hop e overhead di sessione non necessari, Oracle consiglia di utilizzare il bastion primario come coordinatore DR. Altre opzioni richiedono la personalizzazione degli script forniti.
Utilizzare l'etichetta maak8sapply: my_ns se si desidera che le risorse senza spazio di nomi incluse nel backup vengano applicate in modalità secondaria durante il ripristino di my_ns namespace.

Per gli artifact che risiedono nella radice del cluster (non fanno parte di uno spazio di nomi preciso), gli script cercano i riferimenti di campo namespace: e group: che contengono i nomi degli spazi di nomi. Se hai bisogno di altre risorse senza spazio di nomi incluse nel backup, puoi assegnare loro un'etichetta da aggiungere.

Ad esempio, la definizione di risorsa personalizzata domains.weblogic.oracle non fa parte di alcuno spazio di nomi, ma è possibile utilizzare quanto segue per includerla nell'assegnazione etichette dell'operazione apply: kubectl label crd domains.weblogic.oracle maak8sapply=opns.

Configura

Configurare il disaster recovery dello snapshot YAML.

Scarica tutti gli script di disaster recovery dello snapshot YAML da "Download Code".

Nota
Tutti gli script devono trovarsi nello stesso percorso perché gli script principali utilizzano altri script ausiliari.
Modificare lo script maak8DR-apply.env e aggiornare gli indirizzi e la chiave ssh necessari per accedere al sistema secondario.
Di seguito sono riportati alcuni esempi.
```
export user_sec=opc
export ssh_key_sec=/home/opc/Key.ppk
#Secondary bastion node
export sechost=10.10.0.23
```
Personalizzare i valori per exclude_list e nons_artifacts_types, se necessario.
- exclude_list: questa è una lista separata da spazi di quegli spazi di nomi che devono essere esclusi dal backup anche quando si tenta di eseguire il backup di TUTTI gli spazi di nomi personalizzati. Ciò consente di evitare di copiare gli spazi di nomi correlati al piano di controllo che non saranno applicabili a quelli secondari.
- nons_artifacts_types: questa è la lista o gli artifact che appartengono alla struttura radice, ovvero non fanno parte di uno spazio di nomi preciso, ma che devono essere inclusi nello snapshot. Il framework cercherà riferimenti in questo agli spazi dei nomi di cui viene eseguito il backup.
In genere, è possibile utilizzare i valori predefiniti forniti nel file.
```
#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"
```
Eseguire lo script maak8DR-apply.sh fornendo come argomenti gli spazi di nomi selezionati da replicare.
- Se non si forniscono argomenti, gli script replicheranno TUTTI gli spazi di nomi esclusi gli spazi di nomi forniti nella variabile exclude_list.
- Se si utilizza un elenco preciso di spazi di nomi, è necessario ordinarli in base alle dipendenze con altri spazi di nomi.
  
  In altre parole, se lo spazio di nomi soans dipende dai servizi dello spazio di nomi opns o li utilizza, opns deve essere visualizzato per primo nella lista. Ad esempio, anziché ./maak8DR-apply.sh soans opns, eseguire le operazioni riportate di seguito.
```
./maak8DR-apply.sh opns soans
```

Verifica

Dopo aver eseguito lo script maak8DR-apply.sh, verificare che tutti gli artifact esistenti nel cluster primario siano stati replicati nel cluster secondario. Esaminare il cluster secondario e verificare che i pod nel sito secondario siano in esecuzione senza errori.

Quando si esegue lo script maak8DR-apply.sh, il framework crea la directory working_dir come /tmp/backup.date. Quando si eseguono gli script maak8-get-all-artifacts.sh e maak8-push-all-artifacts.sh singolarmente, la directory di lavoro viene fornita in ogni caso come argomento nella riga di comando.

Controllare lo stato del secondario fino a quando i pod richiesti non corrispondono allo stato in primario.
Per impostazione predefinita, i pod e le distribuzioni vengono avviati nell'area secondaria. Al termine del ripristino, viene visualizzato lo stato del cluster secondario. Alcuni pod potrebbero richiedere più tempo per raggiungere lo stato RUNNING.
Controllare il file $working_dir/date/backup-operations.log nel file primario per individuare eventuali errori nelle operazioni di estrazione e applicazione.
Controllare i file $working_dir/restore.log e $working_dir/date/restore-operations.log nel file secondario per individuare eventuali errori nelle operazioni di estrazione e applicazione.
Il file restore-operations.log contiene le operazioni di ripristino dettagliate.