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

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

Remarque :

Cette solution suppose que les clusters Kubernetes, y compris le plan de contrôle et les noeuds de processus actif, 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 clusters Kubernetes existent déjà. Vous devez pouvoir accéder aux deux clusters à l'aide de l'outil de ligne de commande Kubernetes, kubectl, pour exécuter des commandes.

Remarque :

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

Le diagramme suivant montre qu'une fois configuré, vous pouvez restaurer le cliché d'artefact dans des clusters Kubernetes complètement différents.

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

Complétez les conditions suivantes pour Restore lors de la planification de votre configuration :

Vérifiez que les ressources et les noeuds de processus actifs requis dans le noeud principal sont disponibles dans le noeud 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 concernés avant d'exécuter les scripts.

Action par défaut. Les scripts créent les demandes de volume persistant utilisées dans la base principale. Cependant, étant donné que 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 le cluster 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 second cas, il vous appartient de déterminer si des conflits peuvent survenir avec d'autres demandes 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 jeux. Si les informations d'identification des registres sont stockées dans d'autres espaces de noms, vous devez les créer manuellement dans un espace secondaire. Vous pouvez également étiqueter les informations d'identification avec maak8sapply: my_ns (où my_ns est l'espace de noms en cours de restauration) de sorte que la clé secrète soit également incluse dans le cliché 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 processus actif principaux, vous devez également les charger manuellement dans les noeuds de processus actif secondaires.
  
  Remarque :
  Les scripts fournis signalent les images utilisées dans les espaces de noms en cours de réplication.
Fournir un accès aux clusters principal et secondaire via des noeuds de bastions capables d'exécuter des opérations kubectl sur les adresses d'API Kube de chaque cluster.
Il est possible d'utiliser un troisième noeud qui peut utiliser ssh ou scp à la fois (principal et de secours) et coordonner la synchronisation de la récupération après sinistre. Toutefois, pour éviter les sauts inutiles et la surcharge de session, Oracle recommande d'utiliser le bastion principal en tant que coordinateur de récupération après sinistre. D'autres options nécessitent de personnaliser les scripts fournis.
Utilisez le libellé maak8sapply: my_ns si vous souhaitez que les ressources non espacées de noms incluses dans la sauvegarde soient appliquées dans le répertoire secondaire lors de la restauration de my_ns namespace.

Pour les artefacts résidant dans la racine du cluster (qui ne font pas partie d'un espace de noms précis), les scripts recherchent des références de champ namespace: et group: contenant 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 le libellé d'opération apply : kubectl label crd domains.weblogic.oracle maak8sapply=opns.

Configurer

Configurez la récupération après sinistre de l'instantané YAML.

Téléchargez tous les scripts de récupération après sinistre de l'instantané YAML à partir de "Télécharger le code".

Remarque :
Tous les scripts doivent se trouver 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, si nécessaire.
- exclude_list : liste des espaces de noms, séparés par des espaces, 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 les espaces de noms associés au plan de contrôle qui ne seront pas applicables sur les espaces secondaires.
- nons_artifacts_types : liste ou artefacts appartenant à l'arborescence racine (qui ne fait pas partie d'un espace de noms précis) mais qui doivent également être inclus dans le cliché. La structure recherchera les 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'exception 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 la commande suivante :
```
./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 le cluster principal ont été répliqués vers le cluster secondaire. Examinez le cluster secondaire et vérifiez que les pods du site secondaire s'exécutent sans erreur.

Lorsque vous exécutez le script maak8DR-apply.sh, la structure crée le répertoire working_dir sous la forme /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 pod secondaire jusqu'à ce que les pods requis correspondent à l'état du pod principal.
Par défaut, les pods et les déploiements sont démarrés dans la région secondaire. A la fin de la restauration, le statut du cluster secondaire s'affiche. Certains pods peuvent prendre un temps supplémentaire pour atteindre l'état RUNNING.
Recherchez dans le fichier $working_dir/date/backup-operations.log principal les erreurs éventuelles dans les opérations d'extraction et d'application.
Recherchez les éventuelles erreurs dans les opérations d'extraction et d'application des fichiers $working_dir/restore.log et $working_dir/date/restore-operations.log dans le fichier secondaire.
Le fichier restore-operations.log contient les opérations de restauration détaillées.