Configuración para Disaster Recovery

Puede utilizar los scripts proporcionados con este manual de soluciones para crear una instantánea de YAML en un cluster de Kubernetes principal y restaurarla 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.

Note:

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 necesitan que ya existan ambos clusters de Kubernetes. Debe poder acceder a ambos clusters con la herramienta de línea de comandos de Kubernetes, kubectl, para ejecutar comandos en ellos.

Note:

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 ni nodo de trabajador.

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

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 en el principal estén disponibles en el secundario.
Esto incluye los montajes de almacenamiento compartido del pod, los equilibradores de carga y las bases de datos. También incluye cualquier sistema externo utilizado por los espacios de nombres que se restauran.
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. Las secuencias de comandos crearán las reclamaciones de volúmenes persistentes utilizadas en la base de datos principal. Sin embargo, debido a que los volúmenes persistentes pueden ser compartidos por diferentes reclamaciones 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). Esto indica a los scripts que TAMBIÉN creen los volúmenes persistentes en secundario. En este segundo caso, le corresponde a usted determinar si pueden surgir conflictos con otras reclamaciones de volúmenes 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 scripts proporcionados con este manual copian los secretos utilizados para acceder a los registros de contenedor que existen en los espacios de nombres que se replicarán. Si las credenciales de los registros se almacenan en otros espacios de nombres, debe crearlas manualmente en el 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 de 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.
  
  Note:
  Los scripts proporcionados informarán sobre las imágenes utilizadas en los espacios de nombres que se replican.
Proporcione acceso a los clusters primario y secundario mediante nodos de bastión 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 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 no asignados incluidos en la copia de seguridad se apliquen en el secundario al restaurar my_ns namespace.

Para los artefactos que residen 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 contengan los nombres de los espacios de nombres. Si necesita otros recursos no asociados incluidos en la copia de seguridad, puede etiquetarlos para agregarlos.

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.

Configurar

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

Descargue todos los scripts de recuperación ante desastres de instantáneas de YAML desde "Descargar código".

Note:
Todas las secuencias de comandos deben estar en la misma ruta porque las secuencias de comandos principales utilizan otras secuencias de comandos 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. Se trata de evitar la copia de espacios de nombres relacionados con el plano de control que no serán aplicables 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 caso a los espacios de nombres de los que se está realizando una 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, excepto 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 principal 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, la estructura crea el directorio working_dir como /tmp/backup.date. Al ejecutar los scripts 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 en el principal.
Por defecto, los pods y 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 principal 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.