Configuración para la recuperación ante desastres

Puede utilizar los scripts proporcionados con este manual de soluciones para crear una instantánea de YAML en un cluster de Kubernetes principal y restaurarlo en otro cluster de Kubernetes (secundario). Es importante planificar la configuración y comprender los requisitos antes de descargar y utilizar los scripts para configurar la instantánea de YAML.

Tenga en cuenta que:

Esta solución asume que ya existen ambos clusters de Kubernetes, incluidos el plan de control y los nodos de trabajador.

Planificación de la Configuración

Planifique los recursos y la configuración en el sistema secundario según el sistema principal. Los scripts requieren que ambos clusters de Kubernetes ya existan. Debe poder acceder a ambos clusters con la herramienta de línea de comandos Kubernetes, kubectl, para ejecutar comandos en ellos.

Tenga en cuenta que:

Esta solución asume que ya existen ambos clusters de Kubernetes, incluidos el plan de control y los nodos de trabajador. Las recomendaciones y los scripts proporcionados en este manual no comprueban la configuración de recursos, plano de control o nodo de trabajador.

En el siguiente diagrama se muestra que, cuando se configura, puede restaurar la instantánea de artefacto en clusters de Kubernetes completamente diferentes.

A continuación se muestra la descripción de kube-api-dr.png

Descripción de la ilustración kube-api-dr.png

Complete los siguientes requisitos para Restore al planificar la configuración:

Confirme que los nodos de trabajador y los recursos necesarios del principal estén disponibles en el secundario.
Esto incluye los montajes de almacenamiento compartido, los equilibradores de carga y las bases de datos del pod. También incluye cualquier sistema externo utilizado por los espacios de nombres que se están restaurando.
Cree manualmente los volúmenes persistentes necesarios que utilizan los espacios de nombres implicados antes de ejecutar las secuencias de comandos.

Ésta es la acción predeterminada. Los scripts crearán las reclamaciones de volúmenes persistentes utilizadas en la base de datos primaria. Sin embargo, debido a que diferentes reclamaciones pueden compartir volúmenes persistentes en diferentes espacios de nombres, los scripts de automatización esperan que cree manualmente volúmenes persistentes en el cluster secundario antes de ejecutar los scripts extract-apply.

También puede agregar pv a la variable nons_artifacts_types en el archivo maak8DR-apply.env (es decir, utilizar export nons_artifacts_types="crd clusterrole clusterrolebinding pv"). De esta forma, se indica a los scripts que SIEMPRE creen los volúmenes persistentes en el secundario. En este segundo caso, depende de usted determinar si pueden surgir conflictos con otras reclamaciones de volumen persistentes.
Confirme que el cluster secundario tiene el acceso adecuado a las imágenes de contenedor utilizadas por los espacios de nombres que se replican:
- Los secretos utilizados para acceder a los registros de contenedor que existen en los espacios de nombres que se van a replicar los copian los scripts proporcionados con este manual. Si las credenciales de los registros se almacenan en otros espacios de nombres, debe crearlas manualmente en secundario. También puede etiquetar las credenciales con maak8sapply: my_ns (donde my_ns es el espacio de nombres que se está restaurando) para que el secreto también se incluya en la instantánea YAML. Por ejemplo:
```
kubectl label secret regcredfra -n other_namespace 
maak8sapply=namespace_being_backedup
```
- Si utiliza imágenes cargadas manualmente en los nodos de trabajador principales, también debe cargarlas manualmente en los nodos de trabajador secundarios.
  
  Nota:
  Los scripts proporcionados informarán las imágenes utilizadas en los espacios de nombres que se replican.
Proporcione acceso a los clusters primario y secundario mediante nodos bastion capaces de ejecutar operaciones kubectl en los puntos finales de la API de Kube de cada cluster.
Es posible utilizar un tercer nodo que puede ejecutar ssh o scp para ambos (principal y en espera) y coordinar la sincronización de DR. Sin embargo, para evitar saltos innecesarios y sobrecarga de sesión, Oracle recomienda utilizar el bastión principal como coordinador de DR. Otras opciones requieren la personalización de los scripts proporcionados.
Utilice la etiqueta maak8sapply: my_ns si desea que los recursos sin nombre incluidos en la copia de seguridad se apliquen en el secundario al restaurar my_ns namespace.

Para los artefactos que residan en la raíz del cluster (es decir, no forman parte de un espacio de nombres preciso), los scripts buscan referencias de campo namespace: y group: que contienen los nombres de los espacios de nombres. Si necesita otros recursos no relacionados con el nombre incluidos en la copia de seguridad, puede etiquetarlos para que se agreguen.

Por ejemplo, la definición de recurso personalizado domains.weblogic.oracle no forma parte de ningún espacio de nombres, pero puede utilizar lo siguiente para incluirla en el etiquetado de la operación apply: kubectl label crd domains.weblogic.oracle maak8sapply=opns.

Configuración

Configurar la recuperación ante desastres de instantáneas YAML.

Descargue todos los scripts de recuperación ante desastres de instantánea YAML de "Download Code".

Nota:
Todos los scripts deben estar en la misma ruta porque los scripts principales utilizan otros scripts auxiliares.
Edite el script maak8DR-apply.env y actualice las direcciones y la clave ssh necesarias para acceder al sistema secundario.
Por ejemplo:
```
export user_sec=opc
export ssh_key_sec=/home/opc/Key.ppk
#Secondary bastion node
export sechost=10.10.0.23
```
Personalice los valores para exclude_list y nons_artifacts_types, según sea necesario.
- exclude_list: lista separada por espacios de los espacios de nombres que se deben excluir de la copia de seguridad incluso al intentar realizar una copia de seguridad de TODOS los espacios de nombres personalizados. Esto evita copiar espacios de nombres relacionados con el plano de control que no se aplicarán en el secundario.
- nons_artifacts_types: lista o artefactos que pertenecen al árbol raíz (es decir, no forman parte de un espacio de nombres preciso), pero que también se deben incluir en la instantánea. El marco buscará referencias en este campo a los espacios de nombres de los que se está realizando la copia de seguridad.
Por lo general, puede utilizar los valores por defecto proporcionados en el archivo:
```
#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"
```
Ejecute el script maak8DR-apply.sh proporcionando como argumentos los espacios de nombres seleccionados para replicar.
- Si no proporciona argumentos, los scripts replicarán TODOS los espacios de nombres, excluyendo los espacios de nombres proporcionados en la variable exclude_list.
- Si utiliza una lista precisa de espacios de nombres, debe ordenarlos en función de las dependencias con otros espacios de nombres.
  
  Es decir, si el espacio de nombres soans depende de los servicios del espacio de nombres opns o los utiliza, opns debe aparecer primero en la lista. Por ejemplo, en lugar de ./maak8DR-apply.sh soans opns, ejecute lo siguiente:
```
./maak8DR-apply.sh opns soans
```

Verificar

Después de ejecutar el script maak8DR-apply.sh, verifique que todos los artefactos que existían en el cluster primario se hayan replicado en el cluster secundario. Observe el cluster secundario y verifique que los pods del sitio secundario se están ejecutando sin errores.

Al ejecutar el script maak8DR-apply.sh, el marco crea el directorio working_dir como /tmp/backup.date. Al ejecutar las secuencias de comandos maak8-get-all-artifacts.sh y maak8-push-all-artifacts.sh de forma individual, el directorio de trabajo se proporciona en cada caso como argumento en la línea de comandos.

Compruebe el estado del secundario hasta que los pods necesarios coincidan con el estado del principal.
Por defecto, los pods y los despliegues se inician en la región secundaria. Al final de la restauración, se muestra el estado del cluster secundario. Algunos pods pueden tardar más tiempo en alcanzar el estado RUNNING.
Compruebe el archivo $working_dir/date/backup-operations.log en la base de datos primaria para detectar posibles errores en las operaciones de extracción y aplicación.
Compruebe los archivos $working_dir/restore.log y $working_dir/date/restore-operations.log en el secundario para detectar posibles errores en las operaciones de extracción y aplicación.
El archivo restore-operations.log contiene las operaciones de restauración detalladas.