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

Vous pouvez utiliser les scripts fournis avec ce manuel de solutions pour créer un cliché 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 exigences avant de télécharger et d'utiliser les scripts pour configurer votre cliché YAML.

Remarques :

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

Planification de la configuration

Planifiez les ressources et la configuration sur le système secondaire en fonction du système principal. Les scripts exigent 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, afin d'exécuter des commandes sur ces derniers.

Remarques :

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 les scripts fournis dans ce manuel 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'image kube-api-dr.png

Suivez les exigences suivantes pour Restore lors de la planification de votre configuration :

Vérifiez que les ressources et les noeuds de processus actif requis dans la base principale sont disponibles dans la base 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 impliqués avant d'exécuter les scripts.

Il s'agit de l'action par défaut. Les scripts créent les demandes de volume persistant utilisées dans la base principale. Cependant, comme les volumes persistants peuvent être partagés par différentes demandes 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 AUSSI les volumes persistants dans le secondaire. Dans ce second cas, c'est à vous de déterminer si des conflits peuvent survenir avec d'autres demandes de volume persistant.
Vérifiez que le cluster secondaire dispose de l'accès approprié aux images de conteneur utilisées par les espaces de noms en cours de réplication :
- Les clés secrètes utilisées pour accéder aux registres de conteneur qui existent dans les espaces de noms à répliquer sont copiées par les scripts fournis avec ce manuel. Si les informations d'identification des registres sont stockées dans d'autres espaces de noms, vous devez les créer manuellement dans l'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) afin que la clé secrète soit également incluse dans le cliché YAML. 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.
  
  Remarques :
  Les scripts fournis rapporteront les images utilisées dans les espaces de noms en cours de réplication.
Fournissez l'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 récupération après sinistre. Toutefois, pour éviter les sauts inutiles et la surcharge de session, Oracle recommande d'utiliser le bastion principal comme 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 voulez que les ressources sans espace de noms incluses dans la sauvegarde soient appliquées au niveau 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 les 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 d'instantané YAML.

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

Remarques :
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.
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 séparée par des espaces des espaces de noms qui doivent être exclus de la sauvegarde, même lorsque vous tentez de sauvegarder TOUS les espaces de noms personnalisés. Cela permet d'éviter de copier des espaces de noms liés au plan de contrôle qui ne seront pas applicables sur le secondaire.
- 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é. Dans ce cas, la structure recherche les références aux espaces de noms sauvegardés.
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 fournissant comme arguments les espaces de noms sélectionnés à répliquer.
- Si vous ne fournissez pas d'arguments, les scripts répliquent 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 ordonner 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 sont en cours d'exécution sans erreur.

Lorsque vous exécutez le script maak8DR-apply.sh, la structure 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 pod secondaire jusqu'à ce que les pods requis correspondent à celui 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 est affiché. Certains pods peuvent prendre plus de temps pour atteindre l'état RUNNING.
Recherchez les éventuelles erreurs dans les opérations d'extraction et d'application dans le fichier $working_dir/date/backup-operations.log de la base principale.
Vérifiez que les fichiers $working_dir/restore.log et $working_dir/date/restore-operations.log dans le secondaire ne contiennent pas d'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.