Configurer pour la récupération après sinistre

Vous pouvez utiliser les scripts fournis avec ce livre de jeu de solutions pour créer un instantané YAML dans une grappe Kubernetes principale et le restaurer dans une autre grappe Kubernetes (secondaire). Il est important de planifier la configuration et de comprendre les exigences avant de télécharger et d'utiliser les scripts pour configurer votre instantané YAML.

Note :

Cette solution suppose que les grappes Kubernetes, y compris le plan de contrôle et les noeuds de travail, existent déjà.

Planifier la configuration

Planifiez les ressources et la configuration sur le système secondaire en fonction du système principal. Les scripts nécessitent que les deux grappes Kubernetes existent déjà. Vous devez être en mesure d'accéder aux deux grappes à l'aide de l'outil de ligne de commande de Kubernetes, kubectl, pour exécuter des commandes sur celles-ci.

Note :

Cette solution suppose que les grappes Kubernetes, y compris le plan de contrôle et les noeuds de travail, existent déjà. Les recommandations et les scripts fournis dans ce livre de jeu ne vérifient pas les ressources, le plan de contrôle ou la configuration des noeuds de travail.

Le diagramme suivant montre qu'une fois configuré, vous pouvez restaurer l'instantané d'artefact dans des grappes Kubernetes complètement différentes.

Description de kube-api-dr.png ci-dessous

Description de l'illustration kube-api-dr.png

Répondez aux exigences suivantes pour Restore lors de la planification de votre configuration :

Vérifiez que les noeuds de travail et les ressources requis dans l'instance principale sont disponibles dans l'instance secondaire.
Cela inclut les montages de stockage partagé du pod, les équilibreurs de charge et les bases de données. Il inclut également tous les systèmes externes utilisés par les espaces de noms en cours de restauration.
Créez manuellement les volumes persistants requis utilisés par les espaces de noms avant d'exécuter les scripts.

Il s'agit de l'action par défaut. Les scripts créeront les revendications de volume persistant utilisées dans l'instance principale. Toutefois, comme les volumes persistants peuvent être partagés par différentes revendications dans différents espaces de noms, les scripts d'automatisation s'attendent à ce que vous créiez manuellement des volumes persistants sur la grappe secondaire avant d'exécuter les scripts extract-apply.

Vous pouvez également ajouter pv à la variable nons_artifacts_types dans le fichier maak8DR-apply.env (c'est-à-dire utiliser export nons_artifacts_types="crd clusterrole clusterrolebinding pv). Cela indique aux scripts de créer ALSO les volumes persistants dans le secondaire. Dans ce deuxième cas, il vous appartient de déterminer si des conflits peuvent survenir avec d'autres revendications de volume persistant.
Vérifiez que le cluster secondaire dispose d'un accès approprié aux images de conteneur utilisées par les espaces de noms répliqués :
- Les clés secrètes utilisées pour accéder aux registres de conteneurs qui existent dans les espaces de noms à répliquer sont copiées par les scripts fournis avec ce livre de jeu. Si les données d'identification des registres sont stockées dans d'autres espaces de noms, vous devez les créer manuellement dans des espaces secondaires. Vous pouvez également étiqueter les données d'identification avec maak8sapply: my_ns (où my_ns est l'espace de noms en cours de restauration) afin que la clé secrète soit également incluse dans l'instantané YAML. Par exemple,
```
kubectl label secret regcredfra -n other_namespace 
maak8sapply=namespace_being_backedup
```
- Si vous utilisez des images chargées manuellement dans les noeuds de travail principaux, vous devez également les charger manuellement dans les noeuds de travail secondaires.
  
  Note :
  Les scripts fournis rapporteront les images utilisées dans les espaces de noms répliqués.
Fournissez l'accès aux grappes principale et secondaire au moyen de noeuds d'hôte bastion capables d'exécuter des opérations kubectl sur les points d'extrémité d'API Kube de chaque grappe.
Il est possible d'utiliser un troisième noeud qui peut ssh ou scp à la fois (principal et de secours) et coordonner la synchronisation RS. Toutefois, pour éviter les sauts inutiles et les frais généraux de session, Oracle recommande d'utiliser l'hôte bastion principal comme coordonnateur de reprise après sinistre. D'autres options nécessitent la personnalisation des scripts fournis.
Utilisez l'étiquette maak8sapply: my_ns si vous voulez que les ressources non définies dans l'espace de noms incluses dans la sauvegarde soient appliquées en tant que ressources secondaires lors de la restauration de my_ns namespace.

Pour les artefacts résidant dans la racine de la grappe (c'est-à-dire ne faisant pas partie d'un espace de noms précis), les scripts recherchent les références de champ namespace: et group: qui contiennent les noms des espaces de noms. Si vous avez besoin d'autres ressources sans espace de noms incluses dans la sauvegarde, vous pouvez les étiqueter pour les ajouter.

Par exemple, la définition de ressource personnalisée domains.weblogic.oracle ne fait partie d'aucun espace de noms, mais vous pouvez utiliser les éléments suivants pour l'inclure dans l'étiquetage de l'opération apply : kubectl label crd domains.weblogic.oracle maak8sapply=opns.

Configurer

Configurer la récupération après sinistre d'instantané YAML.

Téléchargez tous les scripts de récupération après sinistre d'instantané YAML à partir de "Download Code".

Note :
Tous les scripts doivent être dans le même chemin car les scripts principaux utilisent d'autres scripts auxiliaires.
Modifiez le script maak8DR-apply.env et mettez à jour les adresses et la clé SSH requises pour accéder au système secondaire.
Par exemple,
```
export user_sec=opc
export ssh_key_sec=/home/opc/Key.ppk
#Secondary bastion node
export sechost=10.10.0.23
```
Personnalisez les valeurs pour exclude_list et nons_artifacts_types, au besoin.
- exclude_list : Liste des espaces de noms qui doivent être exclus de la sauvegarde, même lors de la tentative de sauvegarde de TOUS les espaces de noms personnalisés. Cela permet d'éviter de copier des espaces de noms associés au plan de contrôle qui ne seront pas applicables sur les espaces secondaires.
- nons_artifacts_types : Il s'agit de la liste ou des artefacts qui appartiennent à l'arbre racine (c'est-à-dire qui ne font pas partie d'un espace de noms précis) mais qui doivent également être inclus dans l'instantané. L'environnement recherchera des références aux espaces de noms en cours de sauvegarde.
En règle générale, vous pouvez utiliser les valeurs par défaut fournies dans le fichier :
```
#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"
```
Exécutez le script maak8DR-apply.sh en indiquant comme arguments les espaces de noms sélectionnés à répliquer.
- Si vous ne fournissez pas d'arguments, les scripts répliqueront TOUS les espaces de noms à l'exclusion des espaces de noms fournis dans la variable exclude_list.
- Si vous utilisez une liste précise d'espaces de noms, vous devez les trier en fonction des dépendances avec d'autres espaces de noms.
  
  Autrement dit, si l'espace de noms soans dépend ou utilise des services dans l'espace de noms opns, opns doit apparaître en premier dans la liste. Par exemple, au lieu de ./maak8DR-apply.sh soans opns, exécutez ce qui suit :
```
./maak8DR-apply.sh opns soans
```

Vérifier

Après avoir exécuté le script maak8DR-apply.sh, vérifiez que tous les artefacts qui existaient dans la grappe principale ont été répliqués vers la grappe secondaire. Examinez la grappe secondaire et vérifiez que les pods du site secondaire s'exécutent sans erreur.

Lorsque vous exécutez le script maak8DR-apply.sh, le cadre crée le répertoire working_dir en tant que /tmp/backup.date. Lorsque vous exécutez les scripts maak8-get-all-artifacts.sh et maak8-push-all-artifacts.sh individuellement, le répertoire de travail est fourni dans chaque cas en tant qu'argument dans la ligne de commande.

Vérifiez le statut du module secondaire jusqu'à ce que les modules de réseautage requis correspondent à l'état du module principal.
Par défaut, les pods et les déploiements sont démarrés dans la région secondaire. À la fin de la restauration, le statut du cluster secondaire est affiché. Certains pods peuvent prendre plus de temps pour atteindre l'état RUNNING.
Vérifiez dans le fichier $working_dir/date/backup-operations.log de la base principale les erreurs possibles dans les opérations d'extraction et d'application.
Vérifiez les fichiers $working_dir/restore.log et $working_dir/date/restore-operations.log dans le secondaire pour les erreurs possibles dans les opérations d'extraction et d'application.
Le fichier restore-operations.log contient les opérations de restauration détaillées.