Note:
- Este tutorial requiere acceso a Oracle Cloud. Para registrarse en una cuenta gratuita, consulte Introducción a Oracle Cloud Infrastructure Free Tier.
- Utiliza valores de ejemplo para credenciales, arrendamiento y compartimentos de Oracle Cloud Infrastructure. Al finalizar el laboratorio, sustituya estos valores por otros específicos del entorno en la nube.
Automatización de la recuperación para Oracle Integration con OCI Full Stack Disaster Recovery
Parte 1: Introducción
Oracle Cloud Infrastructure Full Stack Disaster Recovery (OCI Full Stack DR) organiza la transición de recursos informáticos, bases de datos y aplicaciones entre regiones de Oracle Cloud Infrastructure (OCI) de todo el mundo con un solo clic. Los clientes pueden automatizar los pasos necesarios para recuperar uno o más sistemas de negocio sin rediseñar ni rediseñar la infraestructura, las bases de datos o las aplicaciones existentes.
Oracle Integration es una plataforma segura y unificada que permite conectar aplicaciones en la nube y locales, automatizar procesos de negocio, obtener estadísticas sobre su negocio mediante análisis de métricas de negocio y desarrollar aplicaciones web y móviles. Oracle Integration está disponible en una región de OCI regida por acuerdos de nivel de servicio (SLA). En este tutorial se detalla el procedimiento para crear una solución de recuperación ante desastres entre regiones gestionada por el cliente para Oracle Integration, específicamente para la función de integraciones de Oracle Integration.
Oracle Integration es una oferta de OCI Platform as a Service (PaaS) gestionada que no es algo que OCI Full Stack DR pueda gestionar de forma nativa, ya que Oracle Integration en sí no expone recursos informáticos, almacenamiento o base de datos a los usuarios de OCI. Sin embargo, OCI Full Stack DR puede automatizar la recuperación de las ofertas PaaS siempre que el equipo de ingeniería de un servicio determinado, como Oracle Integration, haya documentado una forma de aprovisionar, configurar y recuperar su servicio para la recuperación ante desastres entre regiones de OCI. El equipo de ingeniería de Oracle Integration ha documentado la configuración de una solución de recuperación ante desastres para Oracle Integration Generation 2 explicando cómo aprovisionar, configurar y recuperar manualmente Oracle Integration.
OCI Full Stack Disaster Recovery (DR) no se utiliza para aprovisionar ni configurar Oracle Integration. Oracle Integration se debe aprovisionar y configurar para la recuperación ante desastres entre regiones siguiendo las instrucciones paso a paso que se encuentran en Configuración de una solución de recuperación ante desastres para Oracle Integration Generation 2 antes de intentar utilizar OCI Full Stack DR de cualquier forma.
Los pasos de failover manual prescritos por la ingeniería de Oracle Integration en esta documentación: Configuración de una solución de recuperación ante desastres para Oracle Integration Generation 2 también se deben probar correctamente para el switchover y el switchback antes de utilizar OCI Full Stack DR.
Oracle Integration forma parte normalmente de un sistema más grande
En este tutorial se asume que Oracle Integration es la única aplicación que se agrega a los grupos de protección de DR. Esto no es normal.
Este tutorial es inusual en el hecho de que solo se muestra y se analiza Oracle Integration en todo el documento para simplificar las cosas. Normalmente, Oracle Integration será simplemente una pequeña parte de un sistema de negocio mucho más grande y complejo que incluye muchos servicios y aplicaciones diferentes en un único grupo de protección de recuperación ante desastres de pila completa de OCI y un conjunto de planes de recuperación ante desastres. Es muy probable que siga tutoriales similares de Oracle Help Center (OHC) para otras aplicaciones y servicios como PeopleSoft, WebLogic Server, Oracle Analytics Cloud, etc.
Nota: Los pasos de este tutorial se probaron con Oracle Integration Generation 2. En este tutorial solo se muestra cómo implantar la recuperación ante desastres para la capacidad de integración de aplicaciones de Oracle Integration Generation 2, porque no queremos abrumar al lector introduciendo demasiadas partes móviles.
Precaución sobre la implementación incremental
Al agregar más miembros a un grupo de protección de DR después de crear planes de DR, se suprimirán todos los planes de DR existentes en los grupos de protección de ambas regiones.
La recuperación ante desastres de pila completa de OCI está diseñada con la suposición de que toda la pila de aplicaciones para un sistema de negocio determinado ya está desplegada en todas las regiones de OCI y ya se ha demostrado que la recuperación ante desastres manual funciona. Si el sistema de negocio incluye más de Oracle Integration, agregue todos los miembros para el resto de aplicaciones o servicios de OCI a los grupos de protección de DR antes de crear cualquier plan de DR.
Cómo funciona la recuperación
La solución de recuperación para Oracle Integration requiere que OCI Full Stack DR ejecute una serie de scripts bash personalizados durante una operación de recuperación, como un failover o switchover. Los scripts a los que se hace referencia en este tutorial los proporciona el equipo de especialistas en Oracle Integration y están disponibles en un repositorio GitHub específicamente diseñado para esta solución de recuperación ante desastres de Oracle Integration. Los scripts bash se descargan en una instancia informática que forma parte de la pila de aplicaciones que OCI Full Stack DR gestionará durante una operación de recuperación.
Se proporcionan los siguientes scripts como orientación genérica. Puede utilizar sus propios scripts o personalizar los scripts según la política corporativa y los requisitos de seguridad. Debe instalar la CLI de OCI y configurar sus credenciales para utilizar los scripts.
Además, para asegurarse de que la instancia primaria se actualiza con los últimos parámetros programados, asegúrese de que el archivo integrations.json
se actualiza con todos los nombres de integración junto con los detalles de la versión, junto con el archivo integration_parameters.json
, que se debe mantener actualizado con los últimos valores de parámetros programados para todas las integraciones programadas. Para ello, puede emplear el proceso de integración y despliegue continuos preferido.
En este tutorial se explica cómo descargar los scripts y cómo utilizarlos en un paso posterior. Este tutorial utiliza la opción 2 a continuación para alojar los scripts bash solo porque el tutorial no incluye nada más que Oracle Integration.
Opción 1 para alojar scripts
Oracle Integration forma parte con mayor frecuencia de un sistema de negocio más grande y complejo que incluye una aplicación como Oracle E-Business Suite, PeopleSoft o JD Edwards Enterprise, una más otras bases de datos, instancias informáticas y aplicaciones propias. En este caso, simplemente elija cualquiera de las instancias informáticas "movibles" que ya formen parte del sistema de negocio para alojar los scripts. La instancia informática seleccionada puede ser cualquier ubicación en la que esté instalado Oracle Linux y lo más probable es que sea una máquina virtual existente que sirva para otro fin, como un servidor de aplicaciones o un servidor de administración de algún tipo.
En este tutorial se hará referencia a esta instancia informática concreta como Nodo de control o Nodo de DR aunque realmente cumpla otro objetivo en la pila de aplicaciones.
Opción 2 para alojar scripts
Si se trata de una circunstancia inusual en la que Oracle Integration va a ser el único servicio de aplicación que OCI Full Stack DR va a gestionar durante una operación de recuperación, se deberá crear una instancia informática solo para alojar los scripts.
Normalmente, OCI Full Stack DR no necesita ningún servidor de gestión especializado para automatizar las operaciones de recuperación. Sin embargo, creará una instancia informática que actuará como servidor de gestión especializado en este caso, ya que Oracle Integration no es algo que OCI Full Stack DR pueda gestionar de forma nativa. El servidor de gestión especializado se ve en este documento como Nodo de control o Nodo de DR. El objetivo completo del nodo de control es simplemente actuar como un servidor donde los scripts personalizados pueden residir y ser llamados por OCI Full Stack DR durante una operación de recuperación. En este tutorial se explica cómo crear grupos y pasos de planes de DR personalizados y definidos por el usuario como parte de los planes de DR para llamar a los scripts instalados en el nodo de control.
Arquitectura de despliegue de Oracle Integration
Como se muestra en la figura, la arquitectura de DR de Oracle Integration Generation 2 incluye dos instancias de Oracle Integration, que se distinguen como principales y secundarias, que funcionan simultáneamente. Sin embargo, el tráfico se dirige a una sola instancia cada vez. Inicialmente, el tráfico fluye a la instancia principal. Si la instancia principal deja de estar disponible, el registro DNS se ajusta para redirigir el tráfico a la instancia secundaria.
Fig 1: arquitectura de referencia de DR de Oracle Integration
Una vez aprovisionadas las instancias, exporte los metadatos de la instancia primaria a la instancia en espera. Para ello, utilice los API de REST o la interfaz de usuario de Oracle Integration para exportar e importar los metadatos. Después de completar esta migración inicial única de los metadatos, debe mantener los metadatos sincronizados entre las instancias mediante CICD. Puede utilizar Jenkins o una herramienta similar para implantar CICD para las instancias y sincronizar los metadatos. También puede utilizar una instancia de OCI Compute como servidor de CI de Jenkins y hub de CD.
Oracle Integration primero debe aprovisionarse y configurarse para la recuperación ante desastres (DR) en todas las regiones de OCI antes de introducir OCI Full Stack DR. Es extremadamente importante que los pasos manuales para realizar el switchover de Oracle Integration documentados por la ingeniería de Oracle Integration se prueben y funcionen correctamente antes de intentar automatizar el proceso de switchover/failover mediante la recuperación ante desastres de pila completa de OCI.
Familiarizarse con todo el proceso
El equipo de ingeniería de Full Stack Disaster Recovery ha creado una serie de videos complementarios para este tutorial para comprender todo el flujo del proceso. Estos vídeos forman parte de una lista de reproducción de OCI Full Stack DR Oracle Integration en YouTube a la que se puede acceder mediante los siguientes enlaces:
- Vídeo 1: Despliegue de Oracle Integration for Disaster Recovery.
- Vídeo 2: Automatización de operaciones de recuperación ante desastres para Oracle Integration mediante OCI Full Stack DR.
- Vídeo 3: Scripts utilizados para automatizar la recuperación de Oracle Integration.
Parte 2: Instrucciones Paso a Paso
En esta parte se inician las instrucciones paso a paso necesarias para agregar Oracle Integration a OCI Full Stack DR.
Objetivos
En este tutorial se tratarán los siguientes pasos que explican cómo automatizar la recuperación para Oracle Integration mediante la recuperación ante desastres de pila completa de OCI:
- Tarea 1: Despliegue de Oracle Integration for DR en distintas regiones de OCI
- Preparar nodo de control de DR de Oracle Integration
- Descarga de scripts personalizados en el nodo de control de DR
- Instalar y desplegar manualmente Oracle Integration for DR en dos regiones de OCI
- Probar manualmente todos los pasos de recuperación de la región deseada 1 a la región 2
- Probar manualmente todos los pasos de recuperación de la región deseada 2 a la región 1
- Tarea 2: Preparación para la recuperación ante desastres de pila completa de OCI
- Crear políticas de IAM para OCI Full Stack DR
- Crear políticas de IAM para otros servicios de OCI
- Crear cubos de almacenamiento de objetos para logs
- Tarea 3: Creación de grupos de protección de DR (DRPG)
- Tarea 4: Agregar miembros a DRPG de la región 1
- Tarea 5: Creación de planes de DR en la región 2 (Phoenix)
- Crear plan de switchover
- Crear plan de failover
- Tarea 6: Personalización del plan de switchover en la región 2 (Phoenix)
- Tarea 7: Personalización del plan de failover en la región 2 (Phoenix)
- Tarea 8: Ejecución del plan de switchover en la región 2 (Phoenix)
- Tarea 9: Creación de planes de DR básicos en la región 1 (Ashburn)
- Crear plan de switchover
- Crear plan de failover
- Tarea 10: Personalización del plan de switchover en la región 1 (Ashburn)
- Tarea 11: Personalizar el plan de failover en la región 1 (Ashburn)
Definiciones y suposiciones a lo largo del tutorial
Regiones
- La región 1 es Ashburn
- Ashburn comenzará como la región principal.
- Este rol cambiará finalmente a en espera después de que se le indique que realice un switchover en pasos posteriores.
- La región 2 es Phoenix
- Phoenix comenzará como la región en espera.
- Este rol cambiará finalmente a primario después de que se le indique que realice un switchover en pasos posteriores.
Compartimentos
Puede organizar Oracle Integration y OCI Full Stack DR en cualquier esquema de compartimento que funcione según sus estándares de gobernanza de TI. Hemos elegido organizar las aplicaciones en sus propios compartimentos individuales y, a continuación, organizar todos los grupos de protección de DR en un solo compartimento donde se puedan ver todos los sistemas de negocio completamente diferentes de un vistazo.
- La organización de todos los grupos de protección de DR en un solo compartimento, aparte de las aplicaciones, hace que sea mucho más fácil para el personal de TI localizar y ejecutar planes de DR para muchos sistemas empresariales completamente diferentes.
- Tener un único compartimento para todos los grupos de protección de DR ayuda a eliminar los errores humanos y aumenta la velocidad con la que se pueden encontrar y ejecutar planes de DR.
- Compartimento para Oracle Integration: demostración de OCI. El compartimento para la propia OIC, el almacenamiento, los cubos de almacenamiento, los recursos informáticos y la base de datos relacionados con OIC es Demostración de OIC en este tutorial.
- Compartimento para recuperación ante desastres de pila completa de OCI: Demostración de OCI El compartimento para planes y grupos de protección de recuperación ante desastres de pila completa de OCI es Demostración de OCI en este tutorial.
Nodo de control de DR de Oracle Integration
El nodo de control de DR es cualquier instancia informática que designe para alojar scripts bash personalizados que realicen tareas específicas para recuperar Oracle Integration. La recuperación ante desastres de pila completa de OCI llama a los scripts durante una operación de recuperación. En este tutorial se explica cómo agregar los scripts a la recuperación ante desastres de pila completa de OCI en los pasos 6, 7, 10 y 11.
- Para Oracle Integration como aplicación independiente: será una instancia informática especializada que cree para actuar como host de los scripts personalizados.
- Para Oracle Integration como parte de una pila de aplicaciones: se trata de cualquier instancia informática existente que sea miembro de un grupo de protección de DR (DRPG). Por ejemplo, Oracle E-Business Suite o PeopleSoft tendrán servidores de aplicaciones que son miembros de los mismos DRPG que gestionan la recuperación para Oracle Integration; cualquiera de estos puede cumplir el rol de nodo de control de DR en este tutorial.
Requisitos
Oracle Integration debe desplegarse para la recuperación ante desastres en ambas regiones antes de comenzar a trabajar con OCI Full Stack DR. Esto se trata en la tarea 1 a continuación.
Tarea 1: Despliegue de Oracle Integration for Disaster Recovery
La recuperación ante desastres de pila completa de OCI no participa en ninguna parte de este paso.
Tarea 1.1: Preparación del nodo de control de DR para ejecutar la automatización personalizada
Designe una instancia informática para que actúe como nodo de control de DR para OIC. Puede ser una instancia informática existente o puede ser una instancia informática creada solo con este fin. Consulte las siguientes opciones para obtener más información. Asegúrese de que las instancias informáticas que actúan como nodo de control de DR se han configurado para ejecutar comandos con OCI Cloud Agent: Ejecución de comandos en una instancia.
Opción 1: Oracle Integration como aplicación independiente
En este tutorial se asume que Oracle Integration es un servicio independiente, por lo que creará una instancia informática con Oracle Linux en la región 1. Utilice la unidad de menor costo con Oracle Linux, ya que solo se utilizará para alojar los scripts bash personalizados. La necesidad de una instancia informática especializada dedicada a cumplir este rol es inusual; la opción 2 es el escenario más común para la mayoría de las organizaciones.
La instancia informática especializada se agregará como miembro del grupo de protección de DR en la región 1 en un paso posterior.
Opción 2: Oracle Integration como parte de una pila de aplicaciones
Puede utilizar cualquier único recurso informático móvil existente que forme parte de cualquier aplicación de Oracle o no de Oracle gestionada por OCI Full Stack DR en la región 1. Esto cumplirá el rol del nodo de control de DR cada vez que este tutorial haga referencia al nodo de control de DR.
Lo mejor es utilizar una instancia informática móvil, pero también puede designar una instancia informática no móvil en la región 1 y otra en la región 2 si no tiene ningún recurso informático móvil como parte de su solución de DR. Deberá mantener los cambios que realice en las secuencias de comandos o el sistema operativo invitado en ambas regiones si se utilizan recursos informáticos no móviles para este rol.
Opción 3: Oracle Integration como parte de una pila de aplicaciones con varias ofertas PaaS
Tal vez el sistema de negocio también tenga Oracle HTTP Server (OHS), Oracle Integration y Oracle Data Integrator (ODI). En este caso, podría considerar la creación de una instancia informática especializada como lo haría con la opción 1 para alojar scripts de recuperación de DR para todos los distintos servicios PaaS.
Tarea 1.2: Asegúrese de que el grupo de volúmenes se replica en la región 2
Asegúrese de que el volumen de inicio del nodo DR Control sea miembro de un grupo de volúmenes en bloque y de que el grupo de volúmenes en bloque se replique en la región 2.
Asegúrese de que cualquier otro inicio y bloque que pertenezca a cualquier otro recurso informático móvil para este proyecto de recuperación ante desastres de pila completa de OCI también pertenezca a grupos de volúmenes en bloque replicados en la región 2. Si necesita más información, consulte la documentación de OCI Block Storage
Tarea 1.3: Descarga de scripts bash en el nodo de control de DR
Descargue los scripts bash personalizados de github escritos específicamente para esta solución de recuperación ante desastres de Oracle Integration. Los scripts que se muestran a continuación se deben copiar en cualquier subdirectorio de la instancia informática que actúe como nodo de control de DR para Oracle Integration
El enlace anterior se debe resolver en el repositorio GitHub:
- Muestra la ruta del repositorio donde se encuentran los scripts bash en GitHub.
- Muestra el repositorio que contiene los scripts bash.
Figura 2-4: captura de pantalla del repositorio de github que contiene scripts bash para Oracle Integration
Tarea 1.4: Despliegue de Oracle Integration for DR
Despliega Oracle Integration para la recuperación ante desastres en las regiones de OCI mediante las instrucciones paso a paso proporcionadas por el equipo de ingeniería de Oracle Integration.
Tarea 1.5: Prueba Manual de Recuperación de Oracle Integration
Se recomienda garantizar los pasos de recuperación manual. Los pasos manuales para recuperar Oracle Integration documentados en Configuración de recuperación ante desastres para Oracle Integration deben ser correctos antes de trabajar con OCI Full Stack DR.
Tarea 1.6: Pasos siguientes
Vuelva a este documento para empezar a trabajar con OCI Full Stack DR una vez que se hayan completado los siguientes requisitos.
- Despliegue manualmente Oracle Integration for DR en dos regiones de OCI deseadas.
- Pruebe manualmente todos los pasos de recuperación de la región 1 (Ashburn) a la región 2 (Phoenix).
- Pruebe manualmente todos los pasos de recuperación de la región 2 (Phoenix) a la región 1 (Ashburn).
Tarea 2: Preparación para la recuperación ante desastres de pila completa de OCI
La recuperación ante desastres de pila completa de OCI no participa en ninguna parte de este paso. Los siguientes pasos preparan el arrendamiento, el compartimento, los servicios de OCI y Oracle Integration para la recuperación automatizada mediante OCI Full Stack DR.
Tarea 2.1: Creación de políticas de IAM para OCI Full Stack DR
Configure las políticas de OCI IAM necesarias para Full Stack Disaster Recovery como se describe en los siguientes documentos.
- Políticas para Full Stack Disaster Recovery.
- Configuración de políticas de Identity and Access Management (IAM) necesarias para Full Stack Disaster Recovery.
Tarea 2.2: Creación de políticas de OCI IAM para otros servicios gestionados por OCI Full Stack DR
La recuperación ante desastres de pila completa de OCI debe tener la capacidad de controlar y gestionar otros servicios clave de OCI, como recursos informáticos, redes, almacenamiento, almacenes, bases de datos y otros servicios varios. Configure las políticas de OCI IAM necesarias para otros servicios, como se explica en el siguiente documento.
Tarea 2.3: Creación de cubos de OCI Object Storage para logs de DRPG
Nota: Omita la tarea 2.3 por completo si está agregando Oracle Integration a grupos de protección de DR existentes.
Cree cubos de OCI Object Storage en las regiones principal y en espera para almacenar logs generados por la recuperación ante desastres de pila completa de OCI durante las operaciones de recuperación: Object Storage.
Tarea 2.3.1: Navegar a OCI Object Storage
Para empezar, vaya a Object Storage y Archive Storage como se muestra en la figura 2-1 siguiente
- Asegúrese de que el contexto del explorador está definido en la región 1 (Ashburn).
- Seleccionar Almacenamiento.
- Seleccionar cubos.
Figura 2-1: navegue hasta Object Storage
Tarea 2.3.2: Cubo de almacenamiento de OCI en la región 1
Cree un cubo de almacenamiento de objetos en la región 1. El cubo se asignará al grupo de protección de DR en la región 1 en un paso posterior.
- Seleccione el compartimento que contiene los recursos relacionados con OIC.
- Seleccione Create Bucket.
- Asigne al cubo un nombre significativo que identifique fácilmente a qué aplicación y finalidad sirve; no hay ningún motivo para incluir la región como parte del nombre. Por ejemplo, este nombre indica que se utiliza para los logs de DR de pila completa de OCI relacionados con las operaciones de DR para OIC.
- Utilice el valor por defecto para el nivel y el cifrado.
- Seleccione Create para crear el cubo.
Figura 2-2: cree un cubo de almacenamiento de objetos en la región 1
Tarea 2.3.3: Cubo de almacenamiento de OCI en la región 2
Siga el mismo proceso para crear un cubo de almacenamiento de objetos en la región 2 (Phoenix). El cubo se asignará al grupo de protección de DR en la región 2 en un paso posterior.
- Cambie el contexto a la región 2.
- Seleccione el compartimento que contiene los recursos relacionados con OIC en la región 2.
- Utilice el mismo nombre exacto que se ha asignado al cubo en la región 1. Esto facilitará la identificación en un paso posterior.
- Seleccione Create para crear el cubo.
Figura 2-3: cree un cubo de almacenamiento de objetos en la región 2
Tarea 3: Creación de grupos de protección de DR en ambas regiones
Nota: Omita la tarea 3 por completo si Oracle Integration se está agregando a grupos de protección de DR existentes.
Cree grupos de protección de DR en la región 1 y la región 2 si los grupos de protección para esta pila de aplicaciones aún no existen.
Tarea 3.1: Navegación a los grupos de protección de DR
Comience por navegar hasta los grupos de protección de DR (OCI Full Stack DR), como se muestra en la figura 3-1 a continuación.
- Asegúrese de que el contexto de la región de OCI está definido en la región 1 (Ashburn).
- Seleccione Migration & Disaster Recovery.
- Seleccione DR Protection Groups.
Figura 3-1: navegue hasta los grupos de protección de DR
Tarea 3.2: Crear un grupo de protección en la región 1
Cree un grupo de protección de DR básico (DRPG) en la región 1, como se muestra en la figura 3-2 a continuación. El par, el rol y los miembros se asignarán en pasos posteriores.
- Seleccione el compartimento en el que desee crear el DRPG. Puede ser el mismo compartimento en el que existen recursos de Oracle Integration o, como en este caso, un compartimento que actúa como repositorio que contiene DRPG para muchos sistemas de negocio diferentes.
- Seleccione Create DR protection group para abrir el cuadro de diálogo.
Figura 3-2: comience a crear un grupo de protección de DR en la región 1
Agregue un nombre y un cubo de almacenamiento de objetos para los logs, como se muestra en la figura 3-3 siguiente.
- Utilice un nombre sencillo y significativo para el DRPG; en este ejemplo se muestra el nombre del sistema de negocio y la región.
- Seleccione el cubo de almacenamiento de objetos creado en la tarea 2 para la región 1.
Figura 3-3: parámetros necesarios para crear un grupo de protección de DR en la región 1
Tarea 3.3: Crear un grupo de protección en la región 2
Cree un grupo de protección de DR básico (DRPG) en la región 2, como se muestra en la figura 3-4 a continuación. El par, el rol y los miembros se asignarán en pasos posteriores.
- Cambie el contexto de la región de OCI a la región 2.
- Seleccione el compartimento en el que desee crear el DRPG. Puede ser el mismo compartimento en el que existen recursos de Oracle Integration o, como en este caso, un compartimento que actúa como repositorio que contiene DRPG para muchos sistemas de negocio diferentes.
- Seleccione Create DR protection group para abrir el cuadro de diálogo
Figura 3-4: comience a crear un grupo de protección de DR en la región 2
Agregue un nombre y un cubo de almacenamiento de objetos para los logs, como se muestra en la figura 3-5 siguiente.
- Utilice un nombre sencillo y significativo para el DRPG; en este ejemplo se muestra el nombre del sistema de negocio y la región.
- Seleccione el cubo de almacenamiento de objetos creado en la tarea 2 para la región 2
Figura 3-5: parámetros necesarios para crear un grupo de protección de DR en la región 2
Tarea 3.4: Asociación de grupos de protección en la región 1 y la región 2
Asocie los DRPG de cada región como pares entre sí y asigne los roles de iguales de principal y en espera. Así es como OCI Full Stack DR sabrá qué dos regiones trabajan juntas para la recuperación de Oracle Integration. La recuperación ante desastres de pila completa de OCI cambia automáticamente los roles de principal y en espera como parte de cualquier operación de DR/ejecución del plan de DR; no es necesario gestionar los roles manualmente en ningún momento.
Tarea 3.4.1: Iniciar la asociación
- Asegúrese de que el contexto de la región de OCI está definido en la región 1 (Ashburn).
- Seleccione Asociar para iniciar el proceso.
Figura 3-6: inicio de asociación de DRPG
Tarea 3.4.2: Asociación de grupos de protección en la región 1 y región 2
Proporcione los parámetros como se muestra en la figura 3-7 a continuación.
- Seleccione el rol principal. La recuperación ante desastres de pila completa de OCI asignará automáticamente el rol en espera a la región 2.
- Seleccione la región 2 (Phoenix) en la que se creó el otro DRPG.
- Seleccione el DRPG peer en el que se creó.
Figura 3-7: parámetros necesarios para asociar los DRPG
Tarea 3.4.3: Lo que debe ver después de completar la asociación
OCI Full Stack DR mostrará algo como la figura 3-8 a continuación una vez que se complete la asociación.
- El DRPG del peer principal actual es Ashburn (región 1).
- El DRPG del par en espera actual es Phoenix (región 2).
Figura 3-8: visualización de la relación entre pares desde la perspectiva del DRPG individual
La misma información se puede encontrar cuando el contexto/vista es desde una perspectiva global que muestra todos los grupos de protección de DR, como se muestra en la figura 3-9 a continuación.
- El DRPG del peer principal actual es Ashburn (región 1).
- El DRPG del par en espera actual es Phoenix (región 2).
Figura 3-9: visualización de la relación entre pares desde la perspectiva del DRPG global
Tarea 4: Adición de miembros al grupo de protección de DR
Nota: Este paso suprimirá los planes de DR existentes en ambas regiones al agregar miembros a los grupos de protección de DR existentes. La recuperación ante desastres de pila completa de OCI no puede guardar copias ni realizar copias de seguridad de grupos de protección de recuperación ante desastres en el momento de esta escritura. Asegúrese de haber registrado toda la información sobre los grupos y pasos de planes de DR en un archivo de texto u hoja de cálculo para ayudar a volver a crear los grupos y pasos de planes personalizados definidos por el usuario. También puede crear scripts bash que llamen a comandos de la CLI de recuperación ante desastres de pila completa de OCI para volver a crear los grupos de planes y pasos personalizados definidos por el usuario (esto no se aborda en este tutorial).
Agregue el nodo de control de DR como miembros al grupo de protección de DR principal. El nodo de control de DR es una instancia informática que ha creado solo para controlar Oracle Integration o es una instancia informática que forma parte de la pila de aplicaciones que desea gestionar con OCI Full Stack DR.
Agregará los siguientes recursos al DRPG principal en la región 1:
- El nodo de control de DR,
- El grupo de volúmenes que contiene el volumen de inicio del nodo de control de DR.
Tarea 4.1: Comience a agregar miembros al DRPG en la región 1
Comience seleccionando el DRPG en la región 1 como se muestra en la figura 4-1 a continuación.
- Asegúrese de que el contexto de la región de OCI es la región 1 (Ashburn).
- Seleccione el DRPG en la región 1.
- Seleccionar Miembros.
- Haga clic en Agregar Miembro para comenzar el proceso.
Figura 4-1: cómo empezar a agregar miembros al grupo de protección de DR en la región 1
Tarea 4.1.1: Agregar instancia informática para nodo de DR
Agregue una instancia informática para el nodo de control de DR como se muestra en la figura 4-2 a continuación.
- Confirme la advertencia sobre los planes de DR.
- Seleccione Compute como tipo de recurso de miembro.
- Seleccione la instancia informática que desea utilizar el nodo de control de DR.
- Seleccione la instancia en movimiento.
- Indique a OCI Full Stack DR qué VCN y subred asignar a las VNIC en la región 2 durante una recuperación. La figura 4-2 muestra una sola VNIC. A la DR de pila completa de OCI no le importa cuántas VNIC tenga ni cómo estén configuradas en ninguna región; especifique lo que necesite para satisfacer sus necesidades.
Figura 4-2: parámetros necesarios para agregar el nodo de control de DR
Tarea 4.1.2: Adición de un grupo de volúmenes en bloque para el nodo de DR
Agregue el grupo de volúmenes en bloque que contiene el inicio para el nodo de control de DR. El grupo de volúmenes en bloque ya debe tener una replicación entre regiones configurada entre las dos regiones antes de agregarlo al grupo de protección de DR.
- Seleccione el grupo de volúmenes como tipo de recurso de miembro.
- Asegúrese de seleccionar el compartimento correcto que contiene el grupo de volúmenes y, a continuación, seleccione el grupo de volúmenes.
Figura 4-3: parámetros necesarios para agregar un grupo de volúmenes de inicio para el nodo de control de DR
Tarea 4.1.3: Verificación de los recursos miembros para la región 1
El DRPG para la región 1 debe tener dos recursos miembros como mínimo, como se muestra en la figura 4-5 a continuación. Los nombres de los recursos miembros serán diferentes.
- La instancia informática móvil y el grupo de volúmenes en bloque para la instancia informática designada para actuar en el nodo de control de DR de OIC.
Figura 4-5: visualización de miembros de DRPG en la región 1
No es necesario agregar ningún miembro al grupo de protección de DR en espera, ya que estamos utilizando la instancia informática en movimiento como nodo de DR para alojar los scripts de Oracle Integration
Tarea 5: Creación de planes de DR básicos en la región 2 (Phoenix)
Este paso crea planes básicos de switchover y failover asociados al grupo de protección de DR en espera en la región 2 (Phoenix).
El objetivo de cada plan es realizar la transición de la carga de trabajo de la región primaria 1 a la región en espera 2. Los roles de los grupos de protección de DR en ambas regiones se revierten automáticamente como parte de cualquier operación de DR, por lo que el grupo de protección de la región 1 se convertirá en la base de datos en espera y el grupo de protección de la región 2 se convertirá en el principal después de un failover o switchover.
La recuperación ante desastres de pila completa de OCI rellenará previamente ambos planes con pasos incorporados basados en los recursos miembros agregados en el paso anterior. Los planes se personalizarán en pasos posteriores para gestionar todas las tareas relacionadas con Oracle Integration durante una operación de recuperación.
Los planes de switchover siempre se crean en el grupo de protección con el rol en espera; la región 2 es actualmente el grupo de protección en espera, por lo que comenzaremos en Phoenix.
Tarea 5.1: Comenzar a crear planes de DR
Cree planes básicos seleccionando el DRPG en la región 2, como se muestra en la figura 5-1 a continuación.
- Asegúrese de que el contexto de la región de OCI es la región 2 (Phoenix).
- Seleccione el DRPG en espera en la región 2.
- Seleccionar Planes.
- Haga clic en Crear plan para iniciar el proceso.
Figura 5-1: cómo empezar a crear planes de DR básicos en la región 2
Tarea 5.1.1: Creación de un Plan de switchover
Crear un plan de DR es sencillo, como se muestra en la figura 5-2 a continuación.
- Haga que el nombre del plan de switchover sea simple pero significativo. El nombre debe ser lo más corto posible, pero fácil de entender de un vistazo para ayudar a reducir la confusión y el error humano durante una crisis.
- Seleccione el tipo de plan. Solo hay cuatro tipos de plan en el momento de escribir este artículo.
Figura 5-2: parámetros necesarios para crear un plan de switchover de DR
Tarea 5.1.2: Creación de un plan de failover
Siga el mismo proceso para crear un plan de failover básico como se muestra en la figura 5-3 a continuación.
- Haga que el nombre del plan de failover sea simple pero significativo. El nombre debe ser lo más corto posible, pero fácil de entender de un vistazo para ayudar a reducir la confusión y el error humano durante una crisis.
- Seleccione el tipo de plan. Solo hay dos tipos de plan en el momento de escribir este artículo.
Figura 5-3: parámetros necesarios para crear un plan de failover de DR
El grupo de protección de DR en espera de la región 2 ahora debe tener los dos planes de DR, como se muestra a continuación. Gestionarán las cargas de trabajo de transición de la región 1 a la región 2. Creará planes similares en la región 1 para realizar la transición de las cargas de trabajo de la región 2 a la región 1 en un paso posterior.
Figura 5-4: visualización de los dos planes de DR básicos que deben existir en la región 2 antes de continuar
Tarea 6: Personalización del plan de switchover en la región 2 (Phoenix)
Los planes de DR básicos creados en la tarea 5 contienen pasos rellenados previamente para las tareas de recuperación integradas en OCI Full Stack DR y no contienen nada para gestionar tareas de recuperación específicas de Oracle Integration. En este paso se explica cómo agregar grupos de planes de DR personalizados y definidos por el usuario y pasos para gestionar los elementos que se deben realizar durante una operación de switchover para Oracle Integration:
- Sincronizar parámetros programados de la región 1 a la región 2
- Activar integraciones relevantes en la región 2
- Iniciar integraciones programadas en la región 2
- Actualizar registro de DNS en la región 2
- Desactivar integraciones programadas en la región 1
Tarea 6.1: Seleccionar el plan de switchover
Para empezar, vaya al plan de switchover creado en el paso anterior.
Figura 6-1: Cómo empezar a personalizar el plan de switchover en la región 2
Tarea 6.2: Activación de grupos de planes de DR que terminan artefactos (opcional)
Hay dos grupos de planes que están desactivados por defecto en los planes de switchover, como se muestra en la siguiente captura de pantalla. Están desactivados para proporcionar un nivel de comodidad durante las pruebas de que nada se está suprimiendo realmente y todavía tiene una copia viable de los artefactos como copia de seguridad en caso de que algo salga mal durante las pruebas.
Sin embargo, estos dos grupos de planes terminan (suprimen) artefactos que nunca se volverán a utilizar como parte de ninguna operación de DR en el futuro. Los artefactos simplemente seguirán acumulándose a lo largo del tiempo a medida que cambia de una región a otra, lo que genera confusión sobre qué instancias informáticas y grupos de volúmenes son los que realmente deberían estar activos.
Estos grupos de planes se deben activar una vez que OCI Full Stack DR entre en producción. Cualquier artefacto que se haya dejado en su lugar durante la prueba de switchovers y switchbacks mientras estos dos grupos de planes estaban desactivados debe terminarse y limpiarse antes de entrar en producción para reducir la confusión y el riesgo de error humano durante las operaciones normales.
Opcionalmente, estos grupos de planes se pueden activar ahora para evitar tener que limpiar manualmente los artefactos superfluos antes de entrar en producción.
Figura 6-2: grupos de planes desactivados por defecto
Esto es lo que hacen los grupos de planes desactivados cuando están activados:
-
Este grupo de planes termina los artefactos de instancias informáticas que quedan en la región 1 después de que las versiones replicadas de las máquinas virtuales se hayan iniciado en la región 2 durante la operación de almacenamiento de bloques de OCI para revertir la replicación de la región 2 a la región 1 como parte del switchover. Las máquinas virtuales sobrantes no se utilizan durante un switchback porque la operación para revertir la replicación de volúmenes en bloque crea todas las máquinas virtuales nuevas en grupos de volúmenes en bloque completamente nuevos.
-
Este grupo de planes termina los artefactos de los grupos de volúmenes en bloque (VG) que quedan en la región 1 después de que las versiones replicadas de los VG se hayan activado en la región 2 y la replicación del grupo de volúmenes se haya revertido durante el switchover. Los grupos de volúmenes en bloque sobrantes nunca se vuelven a utilizar, ni siquiera como parte de un switchover de la región 2 a la región 1.
Tarea 6.2.1: Activar terminación de grupo de planes de cálculo
Active el grupo de planes.
- Seleccione Activar todos los pasos del menú contextual a la derecha del nombre del grupo de planes.
Figura 6-3: cómo activar la finalización de instancias informáticas
Tarea 6.2.2 Activar terminación de grupo de planes de grupos de volúmenes
Active el grupo de planes.
- Seleccione Activar todos los pasos del menú contextual a la derecha del nombre del grupo de planes.
Figura 6-4: cómo activar la terminación de grupos de volúmenes
Tarea 6.3: Crear grupo de planes para sincronizar parámetros programados de la región 1 a la región 2
Ahora comience a agregar grupos de planes de DR personalizados y definidos por el usuario.
El primer grupo de planes definido por el usuario sincronizará los parámetros programados de la región 1 a la región. Este grupo de planes contendrá un solo paso que llama al script oic-sync-schedule-parameters.sh bash que se descargó en el nodo de control de DR en la tarea 1.4.
Tarea 6.3.1: Seleccionar agregar grupo de planes
Inicie el proceso para agregar un grupo de planes.
- Haga clic en Agregar grupo para comenzar.
Figura 6-5: comience a agregar un grupo de planes para sincronizar los parámetros programados
Tarea 6.3.2: Proporcionar nombre de grupo de planes, ordenar y agregar paso
Un grupo de planes de DR puede contener muchos pasos que se ejecutan en paralelo. Solo estamos agregando un solo paso para ejecutar un script bash para sincronizar los parámetros programados.
- Asigne al grupo de planes un nombre simple pero descriptivo.
- Seleccione una posición en la que se insertará el grupo de planes en el plan de DR. En este caso, insertaremos nuestro grupo de planes definido por el usuario antes del grupo de planes incorporado que detiene las máquinas virtuales en la región 1.
- Seleccione el grupo de planes Parar instancias informáticas (principales) incorporado.
- Haga clic en Agregar paso para abrir el cuadro de diálogo donde especificaremos el script para sincronizar los parámetros programados.
Figura 6-6: parámetros para crear un grupo de planes y agregar un paso para sincronizar los parámetros programados
Tarea 6.3.3: Proporcionar el nombre del paso y los parámetros del script local
El cuadro de diálogo Agregar paso de grupo de planes nos permite especificar parámetros sobre lo que realizará este paso y cómo se comportará durante la recuperación. En este caso, sincronizará los parámetros programados de la región 1 a la región 2.
Explicaremos todos los campos de este cuadro de diálogo, pero dejaremos este detalle en todas las capturas de pantalla restantes en los pasos siguientes, ya que solo estamos realizando el mismo proceso repetidamente.
- Nombre descriptivo que explica la tarea que realiza este paso.
- Seleccione siempre la región en la que se está ejecutando el nodo de control de DR en este momento, no en la que se ejecutará durante un switchover. La recuperación ante desastres de pila completa de OCI realizará un seguimiento de dónde se ejecuta la máquina virtual, por lo que solo tiene que especificar dónde está en este momento. En este caso, el nodo de control de DR se está ejecutando en la región 1 (Ashburn).
- Seleccione Ejecutar script local para informar a OCI Full Stack DR de que el script se encontrará en una instancia informática. Los scripts bash se descargaron en el nodo de control de DR en la tarea 1.3.
- Seleccione el compartimento correcto que contiene el nodo de control de DR: puede ser cualquier compartimento. Seleccione la instancia informática designada como nodo de control de DR (puede ser un servidor de aplicaciones o una máquina virtual que se haya creado solo para este proyecto/tutorial).
- Pegue la ruta absoluta donde instaló la secuencia de comandos oic-sync-schedule-parameters.sh en el nodo de control de DR. Agregue PHX como parámetro. Esta es la región de destino donde queremos sincronizar los parámetros programados. Puede que necesite proporcionar parámetros de región correctos si utiliza diferentes regiones de OCI y actualiza los scripts.
- Especifique opc como usuario para ejecutar la secuencia de comandos.
- El plan de DR debe detenerse si el script no puede sincronizar los parámetros programados. Esto permitirá a cualquiera ver que hay un problema y solucionarlo. La recuperación ante desastres de pila completa de OCI ofrece la oportunidad de seguir ejecutando el plan de switchover después de solucionar el problema.
- El valor por defecto antes de que OCI Full Stack DR declare un fallo es de una hora. Este valor se puede cambiar a 30 minutos o lo que se considere un valor de timeout más realista.
- Haga clic en Agregar Paso para agregar este paso al grupo de planes.
Figura 6-7: parámetros para crear el paso del plan para los parámetros programados de sincronización
Tarea 6.3.4: Finalizar la adición de un grupo de planes y paso
El paso para detener la sincronización de parámetros programados ahora se agrega al grupo de planes de DR, como se muestra en la figura 6-8 a continuación.
- Muestra el paso del plan que se acaba de agregar. Es posible agregar pasos adicionales a un grupo de planes de DR, pero este grupo de planes solo incluirá el paso para sincronizar los parámetros programados.
- Haga clic en Agregar para agregar el grupo y el paso del plan de DR al plan de DR.
Figura 6-8: finalice la adición del grupo de planes y el paso para sincronizar los parámetros programados
Tarea 6.4: Crear un grupo de planes para activar integraciones relevantes en espera
El segundo grupo de planes definido por el usuario activará las integraciones relevantes en espera después de iniciar el nodo de control de DR en la región en espera 2. Este grupo de planes contendrá un solo paso que llama al script oic-integration-switch.sh bash que se descargó en el nodo de control de DR en la tarea 1.3.
Tarea 6.4.1: Seleccionar agregar grupo de planes
Como antes, haga clic en Agregar grupo para comenzar.
Figura 6-9: comience a agregar un grupo de planes para activar las integraciones relevantes en espera
Tarea 6.4.2: Proporcionar nombre de grupo de planes, ordenar y agregar paso
Cree un grupo de planes de DR para iniciar la activación de integraciones relevantes en espera.
- Asigne al grupo de planes un nombre simple pero descriptivo.
- Seleccione una posición en la que se insertará el grupo de planes en el plan de DR. En este caso, vamos a insertar nuestro grupo de planes definido por el usuario después del grupo de planes incorporado que inicia la versión replicada del nodo de control de DR en la región 2
- Seleccione el grupo de planes Iniciar instancias informáticas (en espera) incorporado
- Haga clic en Agregar paso para abrir el cuadro de diálogo donde especificaremos el script para activar las integraciones relevantes en espera.
Figura 6-10: parámetros para crear un grupo de planes y agregar un paso para activar integraciones relevantes en espera
Tarea 6.4.3: Proporcionar el nombre del paso y los parámetros del script local
El cuadro de diálogo Agregar paso de grupo de planes nos permite especificar parámetros sobre lo que realizará este paso y cómo se comportará durante la recuperación. En este caso, activará las integraciones relevantes en la región 2.
Todo en este paso es lo mismo que la Tarea 6.3.3, excepto los elementos que se muestran en la Figura 6-11 a continuación.
- Nombre descriptivo que explica la tarea que realiza este paso.
- Pegue la ruta absoluta donde instaló la secuencia de comandos oic-integration-switch.sh en el nodo de control de DR. Agregue activar como primer parámetro y PHX como second.This es la región de destino donde queremos activar integraciones relevantes. Puede que necesite proporcionar parámetros de región correctos si utiliza diferentes regiones de OCI y actualiza los scripts.
- Haga clic en Agregar Paso para agregar este paso al grupo de planes.
Figura 6-11: parámetros para crear el paso del plan para activar integraciones relevantes en espera
Tarea 6.4.4: Finalizar la adición de grupo de planes y paso
El paso para activar integraciones relevantes en espera ahora se agrega al grupo de planes de DR, como se muestra en la figura 6-12 a continuación.
- Muestra el paso del plan que se acaba de agregar.
- Haga clic en Agregar para agregar el grupo y el paso del plan de DR al plan de DR.
Figura 6-12: finalice la adición del grupo de planes y el paso para activar las integraciones relevantes en espera
Tarea 6.5: Crear un grupo de planes para iniciar integraciones programadas en la región 2
El tercer grupo de planes definido por el usuario iniciará las integraciones programadas en espera después de iniciar el nodo de control de DR en la región en espera 2. Este grupo de planes contendrá un solo paso que llama al script oic-integration-schedule.sh bash que se descargó en el nodo de control de DR en la tarea 1.3.
Tarea 6.5.1: Seleccionar agregar grupo de planes
Como antes, haga clic en Agregar grupo para comenzar.
Figura 6-13: comience a agregar un grupo de planes para iniciar integraciones programadas en espera
Tarea 6.5.2: Proporcionar nombre de grupo de planes, ordenar y agregar paso
Cree un grupo de planes de DR para iniciar integraciones programadas en la región en espera 2.
- Asigne al grupo de planes un nombre simple pero descriptivo.
- Seleccione una posición en la que se insertará el grupo de planes en el plan de DR. En este caso, inserte el grupo de planes definido por el usuario después del grupo de planes definido por el usuario creado en la tarea anterior para activar integraciones relevantes.
- Seleccione el grupo de planes Activar integraciones relevantes en espera incorporado
- Haga clic en Agregar paso para abrir el cuadro de diálogo donde especificaremos el script para iniciar integraciones programadas en espera.
Figura 6-14: parámetros para crear un grupo de planes y agregar un paso para iniciar integraciones programadas en espera
Tarea 6.5.3: Proporcionar el nombre del paso y los parámetros del script local
El cuadro de diálogo Agregar paso de grupo de planes nos permite especificar parámetros sobre lo que realizará este paso y cómo se comportará durante la recuperación. En este caso, iniciará las integraciones programadas en la región en espera 2.
Todo en esta tarea es lo mismo que la Tarea 6.3.3, excepto los elementos que se muestran en la Figura 6-15 a continuación.
- Nombre descriptivo que explica la tarea que realiza este paso.
- Pegue la ruta absoluta donde instaló la secuencia de comandos oic-integration-schedule.sh en el nodo de control de DR. Agregue start como primer parámetro y PHX como segundo.
- Haga clic en Agregar Paso para agregar este paso al grupo de planes.
Figura 6-15: parámetros para crear el paso del plan para iniciar integraciones programadas en espera
Tarea 6.5.4: Finalizar la adición de un grupo de planes y paso
El paso para iniciar integraciones programadas en espera ahora se agrega al grupo de planes de DR, como se muestra en la figura 6-16 a continuación.
- Muestra el paso del plan que se acaba de agregar.
- Haga clic en Agregar para agregar el grupo y el paso del plan de DR al plan de DR.
Figura 6-16: finalice la adición de un grupo de planes y el inicio de integraciones programadas en espera
Tarea 6.6: Crear un grupo de planes para actualizar el registro de DNS en la región 2
El cuarto grupo de planes definido por el usuario actualizará el registro DNS en espera después de iniciar el nodo de control de DR en la región en espera 2. Este grupo de planes contendrá un solo paso que llama al script bash dns_record_update.sh que se descargó en el nodo de control de DR en la tarea 1.3.
Tarea 6.6.1: Seleccionar agregar grupo de planes
Como antes, haga clic en Agregar grupo para comenzar.
Figura 6-17: comience a agregar un grupo de planes para actualizar el registro DNS en espera
Tarea 6.6.2: Proporcionar nombre de grupo de planes, ordenar y agregar paso
Cree un grupo de planes de DR para actualizar el registro DNS a la región 2.
- Asigne al grupo de planes un nombre simple pero descriptivo.
- Seleccione una posición en la que se insertará el grupo de planes en el plan de DR. En este caso, vamos a insertar nuestro grupo de planes definido por el usuario después del grupo de planes incorporado para iniciar integraciones programadas en espera
- Seleccione el grupo de planes Iniciar integraciones programadas en espera incorporado.
- Haga clic en Agregar paso para abrir el cuadro de diálogo donde especificaremos el script para actualizar el registro DNS en espera.
Figura 6-18: parámetros para crear un grupo de planes y agregar un paso para actualizar el registro DNS en espera
Tarea 6.6.3: Proporcionar el nombre del paso y los parámetros del script local
El cuadro de diálogo Agregar paso de grupo de planes nos permite especificar parámetros sobre lo que realizará este paso y cómo se comportará durante la recuperación. En este caso, actualizará el registro DNS en espera.
Todo en esta tarea es lo mismo que la Tarea 6.3.3, excepto los elementos que se muestran en la Figura 6-19 a continuación.
- Nombre descriptivo que explica la tarea que realiza este paso.
- Pegue la ruta absoluta donde instaló el script dns_record_update.sh en el nodo de control de DR. Agregue la clave de región de OCI para la región 2 (PHX en este ejemplo) como parámetro.
- Haga clic en Agregar Paso para agregar este paso al grupo de planes.
Figura 6-19: parámetros para crear el paso del plan para actualizar el registro DNS en espera
Tarea 6.6.4: Finalizar la adición de un grupo de planes y paso
El paso para actualizar el registro DNS en espera se agrega ahora al grupo de planes de DR, como se muestra en la figura 6-20 siguiente.
- Muestra el paso del plan que se acaba de agregar.
- Haga clic en Agregar para agregar el grupo y el paso del plan de DR al plan de DR.
Figura 6-20: finalice la adición del grupo de planes y el paso para actualizar el registro DNS en espera
Tarea 6.7: Crear grupo de planes para desactivar integraciones programadas en la región 1
El grupo de planes definido por el usuario final desactivará las integraciones programadas en la región 1 después de iniciar el nodo de control de DR en la región 2 en espera. Este grupo de planes contendrá un solo paso que llama al script oic-integration-switch.sh que se descargó en el nodo de control de DR en la tarea 1.3.
Tarea 6.7.1: Seleccionar agregar grupo de planes
Como antes, haga clic en Agregar grupo para comenzar.
Figura 6-21: comience a agregar un grupo de planes para desactivar integraciones programadas en la región 1
Tarea 6.7.2: Proporcionar nombre de grupo de planes, ordenar y agregar paso
Crear un grupo de planes de DR para desactivar integraciones programadas en la región 1
- Asigne al grupo de planes un nombre simple pero descriptivo.
- Seleccione una posición en la que se insertará el grupo de planes en el plan de DR. En este caso, vamos a insertar nuestro grupo de planes definido por el usuario después del grupo de planes incorporado para actualizar el registro DNS en espera
- Seleccione el grupo de planes Actualizar registro DNS en espera incorporado.
- Haga clic en Agregar paso para abrir el cuadro de diálogo donde especificaremos el script para desactivar integraciones programadas en la región 1
Figura 6-22: parámetros para crear un grupo de planes y agregar un paso para desactivar integraciones programadas en la región 1
Tarea 6.7.3: Proporcionar el nombre del paso y los parámetros del script local
El cuadro de diálogo Agregar paso de grupo de planes nos permite especificar parámetros sobre lo que realizará este paso y cómo se comportará durante la recuperación. En este caso, se desactivarán las integraciones programadas en la región 1
Todo en esta tarea es lo mismo que la Tarea 6.3.3, excepto los elementos que se muestran en la Figura 6-23 a continuación.
- Nombre descriptivo que explica la tarea que realiza este paso.
- Pegue la ruta absoluta donde instaló la secuencia de comandos oic-integration-switch.sh en el nodo de control de DR. Agregue la clave de región de OCI para la región 1 (IAD en este ejemplo) como parámetro.
- Haga clic en Agregar Paso para agregar este paso al grupo de planes.
Figura 6-23: parámetros para crear el paso del plan para desactivar integraciones programadas en la región 1
Tarea 6.7.4: Finalizar la adición de un grupo de planes y paso
El paso para desactivar integraciones programadas en la región 1 ahora se agrega al grupo de planes de DR, como se muestra en la figura 6-20 a continuación.
- Muestra el paso del plan que se acaba de agregar.
- Haga clic en Agregar para agregar el grupo y el paso del plan de DR al plan de DR.
Figura 6-24: finalice la adición del grupo de planes y el paso para desactivar las integraciones programadas en la región 1
El plan de switchover ahora debe incluir los cinco grupos de planes de DR para Oracle Integration, como se muestra en la siguiente captura de pantalla. Puede tener grupos de planes adicionales si el grupo de protección incluye otras aplicaciones u otros servicios de OCI junto con Oracle Integration
Figura 6-25: visualización de los cinco grupos de planes definidos por el usuario agregados al plan de switchover
Tarea 7: Personalización del plan de failover en la región 2 (Phoenix)
En esta tarea se explica cómo agregar grupos de planes de DR personalizados definidos por el usuario y pasos para gestionar los elementos que se deben realizar durante un failover de Oracle Integration en la región 2 durante una interrupción real o la pérdida de acceso a la región 1. Estos serán un subjuego de los mismos pasos que se acaban de agregar al plan de switchover en la tarea 6 anterior. Sin embargo, solo se agregarán al plan de failover los pasos que se ejecuten en la región en espera 2, ya que se supone que la región 1 es completamente inaccesible durante un failover.
- Activar integraciones relevantes en la región 2
- Actualizar parámetros programados en la región 2
- Iniciar integraciones programadas en la región 2
- Actualizar registro de DNS en la región 2
Tarea 7.1: Seleccionar el plan de failover
Comience por navegar hasta el plan de failover creado en la tarea 5.
- Asegúrese de que la región en espera 2 sigue siendo el contexto de región actual en la consola.
- Seleccione el plan de failover.
Figura 7-1: cómo crear empezar a personalizar el plan de failover en la región 2
Tarea 7.2: Seleccionar agregar grupo de planes
El primer grupo de planes definido por el usuario activará las integraciones relevantes en la región 2. Este grupo de planes contendrá un solo paso que llama al script oic-integration-switch.sh bash que se descargó en el nodo de control de DR en la tarea 1.3.
- Haga clic en Agregar grupo para comenzar.
Figura 7-2: comience a agregar un grupo de planes para activar las integraciones relevantes
Tarea 7.2.1: Proporcionar nombre de grupo de planes, ordenar y agregar paso
Un grupo de planes de DR puede contener muchos pasos que se ejecutan en paralelo. Solo estamos agregando un solo paso para ejecutar un script bash a fin de activar integraciones relevantes.
- Asigne al grupo de planes un nombre simple pero descriptivo.
- Seleccione una posición en la que se insertará el grupo de planes en el plan de DR. En este caso, vamos a insertar nuestro grupo de planes definido por el usuario después del grupo de planes incorporado que inicia las máquinas virtuales replicadas en la región 2
- Seleccione el grupo de planes Iniciar instancias informáticas (en espera) incorporado
- Haga clic en Agregar paso para abrir el cuadro de diálogo donde especificaremos el script para activar las integraciones relevantes.
Figura 7-3: parámetros para crear un grupo de planes y agregar un paso para activar integraciones relevantes en espera
Tarea 7.2.2: Proporcionar el nombre del paso y los parámetros del script local
El cuadro de diálogo Agregar paso de grupo de planes nos permite especificar parámetros sobre lo que realizará este paso y cómo se comportará durante la recuperación. En este caso, activará las integraciones relevantes en la región 2, como se muestra en la Figura 7-4 a continuación.
Explicaremos todos los campos de este cuadro de diálogo, pero dejaremos este detalle en todas las capturas de pantalla restantes en los pasos siguientes, ya que solo estamos realizando el mismo proceso repetidamente.
- Nombre descriptivo que explica la tarea que realiza este paso.
- El plan de DR debe detenerse si el script no activa las integraciones relevantes. Esto permitirá a cualquiera ver que hay un problema y solucionarlo. La recuperación ante desastres de pila completa de OCI ofrece la oportunidad de seguir ejecutando el plan de switchover después de solucionar el problema.
- El valor por defecto antes de que OCI Full Stack DR declare un fallo es de una hora. Este valor se puede cambiar a 30 minutos o lo que se considere un valor de timeout más realista.
- Seleccione siempre la región en la que se está ejecutando el nodo de control de DR en este momento, no en la que se ejecutará durante un switchover. La recuperación ante desastres de pila completa de OCI realizará un seguimiento de dónde se ejecuta la máquina virtual, por lo que solo tiene que especificar dónde está en este momento. En este caso, el nodo de control de DR se está ejecutando en la región 1 (Ashburn).
- Seleccione Ejecutar script local para informar a OCI Full Stack DR de que el script se encontrará en una instancia informática. Los scripts bash se descargaron en el nodo de control de DR en la tarea 1.3.
- Seleccione el compartimento correcto que contiene el nodo de control de DR: puede ser cualquier compartimento. Seleccione la instancia informática designada como nodo de control de DR (puede ser un servidor de aplicaciones o una máquina virtual que se haya creado solo para este proyecto/tutorial).
- Pegue la ruta absoluta donde instaló la secuencia de comandos oic-integration-switch.sh en el nodo de control de DR. Agregue activate como el primer parámetro y PHX como el segundo.
- Especifique opc como usuario para ejecutar la secuencia de comandos.
- Haga clic en Agregar Paso para agregar este paso al grupo de planes.
Figura 7-4: parámetros para crear el paso del plan para activar integraciones relevantes en espera
Tarea 7.2.3: Finalizar la adición de grupo de planes y paso
El paso para activar integraciones relevantes ahora se agrega al grupo de planes de DR, como se muestra en la figura 7-5 a continuación.
- Muestra el paso del plan que se acaba de agregar.
- Haga clic en Agregar para agregar el grupo y el paso del plan de DR al plan de DR.
Figura 7-5: finalice la adición del grupo de planes y el paso para activar las integraciones relevantes
Tarea 7.3: Creación de un grupo de planes para actualizar los parámetros programados en la región 2
El segundo grupo de planes definido por el usuario actualizará los parámetros programados en la región en espera 2. Este grupo de planes contendrá un solo paso que llama al script oic-update-parameters.sh bash que se descargó en el nodo de control de DR en la tarea 1.3.
Tarea 7.3.1: Seleccionar agregar grupo de planes
Como antes, haga clic en Agregar grupo para comenzar.
Figura 7-6: comience a agregar un grupo de planes para actualizar los parámetros programados en espera
Tarea 7.3.2: Proporcionar nombre de grupo de planes, ordenar y agregar paso
Cree un grupo de planes de DR para actualizar los parámetros programados en la región 2.
- Asigne al grupo de planes un nombre simple pero descriptivo.
- Seleccione una posición en la que se insertará el grupo de planes en el plan de DR. En este caso, inserte el grupo de planes definido por el usuario después del grupo de planes definido por el usuario creado en la tarea anterior para activar integraciones relevantes.
- Seleccione Activar integraciones relevantes en el grupo de planes en espera.
- Haga clic en Agregar paso para abrir el cuadro de diálogo donde especificaremos el script para actualizar los parámetros programados en espera.
Figura 7-7: parámetros para crear un grupo de planes y agregar un paso para actualizar los parámetros programados en espera
Tarea 7.3.3: Proporcionar el nombre del paso y los parámetros del script local
El cuadro de diálogo Agregar paso de grupo de planes nos permite especificar parámetros sobre lo que realizará este paso y cómo se comportará durante la recuperación. En este caso, recuperará los parámetros programados de actualización en la región 2.
Todo en esta tarea es lo mismo que la Tarea 7.3.2, excepto los elementos que se muestran en la Figura 7-8 a continuación.
- Nombre descriptivo que explica la tarea que realiza este paso.
- Pegue la ruta absoluta donde instaló la secuencia de comandos oic-update-parameters.sh en el nodo de control de DR. Agregue PHX como único parámetro (PHX en este ejemplo).
- Haga clic en Agregar Paso para agregar este paso al grupo de planes.
Figura 7-8: parámetros para crear el paso del plan para actualizar los parámetros programados en espera
Tarea 7.3.4: Finalizar la adición de un grupo de planes y paso
El paso para actualizar los parámetros programados en espera ahora se agrega al grupo de planes de DR, como se muestra en la figura 7-9 a continuación.
- Muestra el paso del plan que se acaba de agregar.
- Haga clic en Agregar para agregar el grupo y el paso del plan de DR al plan de DR.
Figura 7-9: finalice la adición de parámetros programados de actualización de paso y grupo de planes en espera
Tarea 7.4: Crear un grupo de planes para iniciar integraciones programadas en la región 2
El tercer grupo de planes definido por el usuario iniciará las integraciones programadas en espera después de iniciar el nodo de control de DR en la región en espera 2. Este grupo de planes contendrá un solo paso que llama al script oic-integration-schedule.sh bash que se descargó en el nodo de control de DR en la tarea 1.3.
Tarea 7.4.1: Seleccionar agregar grupo de planes
Como antes, haga clic en Agregar grupo para comenzar.
Figura 7-10: comience a agregar un grupo de planes para iniciar integraciones programadas en espera
Tarea 7.4.2: Proporcionar nombre de grupo de planes, ordenar y agregar paso
Crear un grupo de planes de DR para iniciar integraciones programadas en espera
- Asigne al grupo de planes un nombre simple pero descriptivo.
- Seleccione una posición en la que se insertará el grupo de planes en el plan de DR. En este caso, insertaremos nuestro grupo de planes definido por el usuario después de actualizar los parámetros programados en los grupos de planes en espera
- Seleccione el grupo de planes Actualizar parámetros programados en espera incorporado.
- Haga clic en Agregar paso para abrir el cuadro de diálogo donde especificaremos el script para iniciar integraciones programadas en espera
Figura 7-11: parámetros para crear un grupo de planes y agregar un paso para iniciar integraciones programadas en espera
Tarea 7.4.3: Proporcionar el nombre del paso y los parámetros del script local
El cuadro de diálogo Agregar paso de grupo de planes nos permite especificar parámetros sobre lo que realizará este paso y cómo se comportará durante la recuperación.
Todo en esta tarea es lo mismo que la Tarea 7.2.2, excepto los elementos que se muestran en la Figura 6-19 a continuación.
- Nombre descriptivo que explica la tarea que realiza este paso.
- Pegue la ruta absoluta donde instaló la secuencia de comandos oic-integration-schedule.sh en el nodo de control de DR. Agregue start como primer parámetro y PHX como segundo.
- Haga clic en Agregar Paso para agregar este paso al grupo de planes.
Figura 7-12: parámetros para crear el paso del plan para iniciar integraciones programadas en espera
Tarea 7.4.4: Finalizar la adición de un grupo de planes y paso
El paso para iniciar integraciones programadas en espera ahora se agrega al grupo de planes de DR, como se muestra en la figura 7-13 a continuación.
- Muestra el paso del plan que se acaba de agregar.
- Haga clic en Agregar para agregar el grupo y el paso del plan de DR al plan de DR.
Figura 7-13: finalice la adición del grupo de planes y el paso para iniciar integraciones programadas en espera
Tarea 7.5: Crear grupo de planes para actualizar el registro de DNS en la región 2
El cuarto grupo de planes definido por el usuario actualizará el registro DNS en espera después de iniciar el nodo de control de DR en la región en espera 2. Este grupo de planes contendrá un solo paso que llama al script bash dns_record_update.sh que se descargó en el nodo de control de DR en la tarea 1.3.
Tarea 7.5.1: Seleccionar agregar grupo de planes
Como antes, haga clic en Agregar grupo para comenzar.
Figura 7-14: comience a agregar un grupo de planes para actualizar el registro DNS en espera
Tarea 7.5.2: Proporcionar nombre de grupo de planes, ordenar y agregar paso
Cree un grupo de planes de DR para actualizar el registro DNS a la región 2.
- Asigne al grupo de planes un nombre simple pero descriptivo.
- Seleccione una posición en la que se insertará el grupo de planes en el plan de DR. En este caso, vamos a insertar nuestro grupo de planes definido por el usuario después del grupo de planes incorporado para iniciar integraciones programadas en espera
- Seleccione el grupo de planes Iniciar integraciones programadas en espera incorporado.
- Haga clic en Agregar paso para abrir el cuadro de diálogo donde especificaremos el script para actualizar el registro DNS en espera.
Figura 7-14: parámetros para crear un grupo de planes y agregar un paso para actualizar el registro DNS en espera
Tarea 7.5.3: Proporcionar el nombre del paso y los parámetros del script local
El cuadro de diálogo Agregar paso de grupo de planes nos permite especificar parámetros sobre lo que realizará este paso y cómo se comportará durante la recuperación. En este caso, actualizará el registro DNS en espera.
Todo en esta tarea es lo mismo que la Tarea 6.3.3, excepto los elementos que se muestran en la Figura 7-15 a continuación.
- Nombre descriptivo que explica la tarea que realiza este paso.
- Pegue la ruta absoluta donde instaló el script dns_record_update.sh en el nodo de control de DR. Agregue la clave de región de OCI para la región 2 (PHX en este ejemplo) como parámetro.
- Haga clic en Agregar Paso para agregar este paso al grupo de planes.
Figura 7-15: parámetros para crear el paso del plan para actualizar el registro DNS en espera
Tarea 7.5.4: Finalizar la adición de un grupo de planes y paso
El paso para actualizar el registro DNS en espera ahora se agrega al grupo de planes de DR, como se muestra en la figura 7-16 a continuación.
- Muestra el paso del plan que se acaba de agregar.
- Haga clic en Agregar para agregar el grupo y el paso del plan de DR al plan de DR.
Figura 7-16: finalice la adición del grupo de planes y el paso para actualizar el registro DNS en espera
El plan de failover ahora debe incluir los cuatro grupos de planes de DR para Oracle Integration, como se muestra en la siguiente captura de pantalla. Puede tener grupos de planes adicionales si el grupo de protección incluye otras aplicaciones o servicios de OCI junto con Oracle Integration.
Figura 7-14: visualización de los cuatro grupos de planes definidos por el usuario agregados al plan de failover
Tarea 8: Ejecución del plan de switchover en la región 2 (Phoenix)
Los planes de DR de switchover y failover se han completado en la región en espera 2 (Phoenix). Los planes de DR de la región 2 permiten a OCI Full Stack DR realizar la transición de las cargas de trabajo de la región 1 a la región 2. La siguiente tarea consiste en crear planes de switchover y failover en el grupo de protección para la región 1 (Ashburn) para que OCI Full Stack DR pueda realizar la transición de las cargas de trabajo de la región 2 a la región 1.
Sin embargo, los planes de DR solo se pueden crear y modificar en el grupo de protección con el rol en espera. El grupo de protección de DR de la región 1 es actualmente el principal, lo que significa que los planes de DR no se pueden crear en la región 1.
Por lo tanto, debemos revertir los roles de los grupos de protección para que la región 1 sea la región en espera y la región 2 sea la principal. Ejecute el plan de switchover que acaba de crear para realizar la transición de la carga de trabajo de la región 1 (Ashburn) a la región 2 (Phoenix).
Tarea 8.1: Inicio de la ejecución del plan
Ejecute el plan de DR para iniciar el proceso de transición de la carga de trabajo de Oracle Integration de la región 1 a la región 2.
- Asegúrese de que el contexto de región sigue definido en la región en espera 2 (Phoenix).
- Utilice las rutas de navegación de la parte superior de la consola para asegurarse de que los detalles del grupo de protección de DR sean el contexto del plan actual.
- Asegúrese de seleccionar el grupo de protección de DR correcto en la región 2; debe ser el rol Standby (En espera).
- Asegúrese de que existan los planes de failover y switchover antes de continuar; de lo contrario, vuelva a los pasos anteriores para crear y personalizar ambos planes de DR.
- Haga clic en Ejecutar plan de DR.
Figura 8-1: visualización de cómo ejecutar un switchover a una región en espera
Tarea 8.2: Seleccionar el plan de switchover y ejecutar
Esta tarea ejecuta el plan de switchover en la región 2.
- Seleccione el plan de switchover.
- Asegúrese de que se ha seleccionado Activar comprobaciones previas.
- Haga clic en Ejecutar plan de DR para comenzar.
Figura 8-2: seleccione y ejecute el plan de switchover
Tarea 8.3: Siguientes pasos
Controle el plan de switchover hasta que la carga de trabajo de Oracle Integration se haya realizado la transición completa de la región 1 a la región 2. La recuperación ante desastres de pila completa de OCI se encargará de limpiar los artefactos y cambiar los roles de principal y en espera entre las regiones.
La región 2 (Phoenix) será la región principal y la región 1 (Ashburn) será la región en espera una vez que la recuperación ante desastres de pila completa de OCI haya completado el switchover.
Tarea 9: Creación de planes de DR en la región 1 (Ashburn)
Cree los mismos planes básicos de switchover y failover en el grupo de protección de DR para la región 1 (Ashburn), que ahora es el peer en espera.
El objetivo de cada plan es realizar la transición de la carga de trabajo de la región 2 a la región 1 siempre que la región 2 sea el peer principal. Los roles de los grupos de protección de DR en ambas regiones se revierten automáticamente como parte de cualquier operación de DR, por lo que el grupo de protección de la región 2 se convertirá en la base de datos en espera y el grupo de protección de la región 1 se convertirá en principal después de un failover o switchover.
La recuperación ante desastres de pila completa de OCI rellenará previamente ambos planes con pasos incorporados basados en los recursos miembros agregados en el paso anterior. Los planes se personalizarán en pasos posteriores para gestionar todas las tareas relacionadas con Oracle Integration durante una operación de recuperación.
Los planes de DR siempre se crean en el grupo de protección con el rol en espera; la región 1 es actualmente el grupo de protección en espera después de ejecutar el plan de switchover en la tarea 8.
Tarea 9.1: Comenzar a crear planes de DR
Cree planes básicos seleccionando el DRPG en la región 1, como se muestra en la figura 9-1 a continuación.
- Asegúrese de que el contexto de la región de OCI es la región 1 (Ashburn).
- Seleccione el DRPG en espera en la región 1.
- Seleccionar Planes.
- Haga clic en Crear plan para iniciar el proceso.
Figura 9-1: cómo empezar a crear planes de DR básicos en la región 1
Tarea 9.1.1: Creación de un Plan de switchover
Crear un plan de DR es sencillo, como se muestra en la figura 9-2 a continuación.
-
Haga que el nombre del plan de switchover sea simple pero significativo. El nombre debe ser lo más corto posible, pero fácil de entender de un vistazo para ayudar a reducir la confusión y el error humano durante una crisis.
-
Seleccione el tipo de plan. Solo hay dos tipos de plan en el momento de escribir este artículo.
Figura 9-2: parámetros necesarios para crear un plan de switchover de DR -
Haga clic en Crear para crear un plan de switchover básico rellenado previamente con pasos básicos incorporados.
Tarea 9.2: Creación de un plan de failover
Siga el mismo proceso para crear un plan de failover básico como se muestra en la figura 9-3 a continuación.
-
Haga que el nombre del plan de failover sea simple pero significativo. El nombre debe ser lo más corto posible, pero fácil de entender de un vistazo para ayudar a reducir la confusión y el error humano durante una crisis.
-
Seleccione el tipo de plan. Solo hay dos tipos de plan en el momento de escribir este artículo.
-
Haga clic en Crear para crear un plan de failover básico rellenado previamente con pasos básicos incorporados.
Figura 9-3: parámetros necesarios para crear un plan de failover de DR
El grupo de protección de DR en espera de la región 1 ahora debe tener los dos planes de DR, como se muestra a continuación. Gestionarán las cargas de trabajo de transición de la región 2 a la región 1.
Figura 9-4: visualización de los dos planes de DR básicos que deben existir en la región 2 antes de continuar
Tarea 10: Personalización del plan de switchover en la región 1 (Ashburn)
Todo lo relacionado con esta tarea es casi exactamente igual a lo que hicimos en la Tarea 6 para la región 2, excepto que esto se está haciendo en la región 1.
Los planes de DR básicos creados en la tarea 9 no contienen nada para gestionar tareas de recuperación específicas de Oracle Integration. En esta tarea se explica cómo agregar grupos de planes de DR personalizados y definidos por el usuario y pasos para gestionar los elementos que se deben realizar durante una operación de switchover para Oracle Integration:
- Sincronice los parámetros programados de la región 1 a la región 2.
- Active las integraciones relevantes en la región 2.
- Inicie las integraciones programadas en la región 2.
- Actualice el registro DNS en la región 2.
- Desactivar integraciones programadas en la región 1.
Tarea 10.1: Seleccionar el plan de switchover
Para empezar, vaya al plan de switchover creado en el paso anterior.
Figura 10-1: cómo empezar a personalizar el plan de switchover en la región 1
Tarea 10.2: Activación de grupos de planes de DR que terminan artefactos (opcional)
Estos son los mismos pasos realizados para la región 2 en un paso anterior; se debe seguir el mismo proceso para la región 1.
Dos grupos de planes están desactivados por defecto en los planes de switchover, como se muestra en la siguiente captura de pantalla. Están desactivados para proporcionar un nivel de comodidad durante las pruebas de que no se está suprimiendo nada, y aún tiene una copia viable de los artefactos como copia de seguridad en caso de que algo salga mal durante las pruebas.
Sin embargo, estos dos grupos de planes terminan (suprimen) artefactos que nunca se volverán a utilizar como parte de ninguna operación de DR en el futuro. Los artefactos simplemente continuarán acumulándose a lo largo del tiempo a medida que cambia entre las dos regiones, lo que genera confusión para los humanos sobre qué instancias informáticas y grupos de volúmenes son los que realmente deberían estar activos.
Estos grupos de planes se deben activar una vez que OCI Full Stack DR entre en producción. Cualquier artefacto que se haya dejado en su lugar durante la prueba de switchovers y switchbacks mientras estos dos grupos de planes estaban desactivados debe terminarse y limpiarse antes de entrar en producción para reducir la confusión y el riesgo de error humano durante las operaciones normales.
Opcionalmente, estos grupos de planes se pueden activar ahora para evitar tener que limpiar manualmente los artefactos superfluos antes de entrar en producción.
Figura 10-2: grupos de planes desactivados por defecto
Esto es lo que hacen los grupos de planes desactivados cuando están activados:
-
Este grupo de planes termina los artefactos de instancias informáticas que quedan en la región 2 después de que las versiones replicadas de las máquinas virtuales se hayan iniciado en la región 1 durante la operación de almacenamiento de bloques de OCI para revertir la replicación de la región 1 a la región 2 como parte del switchover. Las máquinas virtuales sobrantes no se utilizan durante un switchback porque la operación para revertir la replicación de volúmenes en bloque crea todas las máquinas virtuales nuevas en grupos de volúmenes en bloque completamente nuevos.
-
Este grupo de planes termina los artefactos de los grupos de volúmenes en bloque (VG) que quedan en la región 2 después de que las versiones replicadas de los VG se hayan activado en la región 1 y la replicación del grupo de volúmenes se haya revertido durante el switchover. Los grupos de volúmenes en bloque sobrantes nunca se vuelven a utilizar, ni siquiera como parte de un switchover de la región 1 a la región 2.
Tarea 10.2.1: Activar terminación de grupo de planes de cálculo
Active el grupo de planes.
- Seleccione Activar todos los pasos del menú contextual situado a la derecha del nombre del grupo de planes.
Figura 10-3: cómo activar la finalización de instancias informáticas
Tarea 10.2.2 Activar terminación de grupo de planes de grupos de volúmenes
Active el grupo de planes.
- Seleccione Activar todos los pasos del menú contextual situado a la derecha del nombre del grupo de planes.
Figura 10-4: cómo activar la terminación de grupos de volúmenes
Tarea 10.3: Creación de varios planes definidos por el usuario para el plan de switchover
Ya hemos mostrado cómo crear los distintos planes definidos por el usuario para el plan de switchover de la tarea 6.3 a la 6.7. Mediante el proceso similar, cree cinco grupos de planes personalizados definidos por el usuario. Debe utilizar la instancia informática que se ejecuta en la región Phoenix para ejecutar scripts.
- Sincronice los parámetros programados del IAD principal al
/home/opc/oic-scripts/oic-sync-schedule-parameters.sh
en espera. - Active las integraciones relevantes en la base de datos en espera
/home/opc/oic-scripts/oic-integration-switch.sh
y active IAD. - Inicie las integraciones programadas en el inicio de IAD
/home/opc/oic-scripts/oic-integration-schedule.sh
en espera. - Actualice el registro DNS en el IAD
/home/opc/oic-scripts/dns-record-update.sh
en espera. - Desactive las integraciones programadas en el
/home/opc/oic-scripts/oic-integration-switch.sh
principal para desactivar IAD.
Una vez creados, el plan de switchover debe incluir ahora los cinco grupos de planes de DR para la integración de Oracle, como se muestra en la siguiente captura de pantalla. Puede tener grupos de planes adicionales si el grupo de protección incluye otras aplicaciones o servicios de OCI junto con la integración de Oracle.
Figura 10-21: visualización de los cinco grupos de planes definidos por el usuario agregados al plan de switchover
Tarea 11: Personalizar el plan de failover en la región 1 (Ashburn)
En esta tarea se explica cómo agregar grupos de planes de DR personalizados definidos por el usuario y pasos para gestionar los elementos que se deben realizar durante un failover de Oracle Integration en la región 1 durante una interrupción real o la pérdida de acceso a la región 2. Estos serán un subjuego de los mismos pasos que se acaban de agregar al plan de switchover en la tarea 10 anterior. Sin embargo, solo se agregarán al plan de failover los pasos que se ejecutan en la región en espera 1, ya que se supone que la región 2 es completamente inaccesible durante un failover.
- Active las integraciones relevantes en la región 1.
- Actualizar parámetros programados en la región 1.
- Inicie integraciones programadas en la región 1.
- Actualice el registro DNS en la región 1.
Tarea 11.1: Seleccionar el plan de switchover
Comience por navegar hasta el plan de failover creado en la tarea 9.
- Asegúrese de que la región en espera 2 sigue siendo el contexto de región actual en la consola.
- Seleccione el plan de failover.
Figura 7-1: cómo crear empezar a personalizar el plan de failover en la región 2
Tarea 11.2: Creación de varios grupos de planes definidos por el usuario en la región 1 (en espera)
Ya hemos mostrado cómo crear el plan definido por el usuario para el plan de failover de la tarea 7.2 a la 7.5. Mediante el proceso similar, cree los siguientes cuatro grupos de planes personalizados definidos por el usuario. Debe utilizar la instancia informática que se ejecuta en la región Phoenix para ejecutar scripts.
-
Active las integraciones relevantes en la base de datos en espera
/home/opc/oic-scripts/oic-integration-switch.sh
y active IAD. -
Actualice los parámetros programados en IAD
/home/opc/oic-scripts/oic-update-parameters.sh
en espera. -
Inicie las integraciones programadas en el inicio de IAD
/home/opc/oic-scripts/oic-integration-schedule.sh
en espera. -
Actualice el registro DNS en el IAD
/home/opc/oic-scripts/dns-record-update.sh
en espera.
Una vez creados, el plan de failover ahora debe incluir los cuatro grupos de planes de DR para la integración de Oracle, como se muestra en la siguiente captura de pantalla. Puede tener grupos de planes adicionales si el grupo de protección incluye otras aplicaciones o servicios de OCI junto con la integración de Oracle.
Figura 11-14: visualización de los cuatro grupos de planes definidos por el usuario agregados al plan de failover
Pasos Siguientes
La recuperación ante desastres de pila completa de OCI para Oracle Integration se debe implantar por completo en este punto. Sin embargo, se debe validar la funcionalidad completa antes de utilizar OCI Full Stack DR para producción. Todos los planes de failover y switchover se deben ejecutar para validar que todo funcione según lo esperado y que el equipo de recuperación entienda completamente todo el proceso.
Prueba de planes de switchover
Los planes de switchover están diseñados para limpiar todos los artefactos y garantizar que todos los roles de los pasos de recuperación incorporados, como el equilibrador de carga, el almacenamiento de bloques, los sistemas de archivos, BaseDB, ExaCS y la base de datos autónoma, estén listos para recuperarse de la región en espera sin intervención humana.
Prueba de Planes de Failover
Los failovers son diferentes. Los failovers por su propia naturaleza no pueden limpiar artefactos ni garantizar que los servicios y las bases de datos de la región con fallos estén listos para realizar la transición de las cargas de trabajo a la región 1. El equipo de recuperación debe comprender y realizar tareas para asegurarse de que Data Guard está en el estado correcto, que los artefactos para el almacenamiento y las instancias informáticas se han terminado, etc. Consulte Restablecimiento de la configuración de DR tras un failover en la documentación de recuperación ante desastres de pila completa de OCI para comprender el proceso.
Valide todos los planes de DR para la aceptación final.
El equipo de recuperación debe realizar una validación final para demostrar la preparación de los grupos de protección de recuperación ante desastres de pila completa de OCI y los planes para las cargas de trabajo de producción. La región 2 (Phoenix) debe ser la región principal en este punto del proceso. Para iniciar la validación final de todos los planes, complete los pasos siguientes:
-
Pruebe el switchover de la región 2 (principal) a la región 1 (en espera).
-
Pruebe el failover de la región 1 (principal) a la región 2 (en espera).
-
Prepare la región 1 (principal) para el failover de la región 2.
-
Pruebe el failover de la región 2 (principal) a la región 1 (en espera).
-
Prepare la región 2 (principal) para un failover o switchover a la región 2.
-
Los grupos de protección de DR y la pila de aplicaciones deben estar en un estado operativo normal y listos para un failover o switchover en este punto.
Nota: Para asegurarse de que se puede utilizar la misma aplicación cliente para autenticar el resto de API para ambas instancias de Oracle Integration, puede agregar el ámbito de ambas instancias (principal y secundaria) a la aplicación cliente OAuth. Para la configuración de la aplicación cliente OAuth, puede consultar la documentación oficial.
Enlaces relacionados
-
Lista de reproducción de OCI Full Stack DR Oracle Integration en YouTube
-
Recuperación ante desastres de pila completa de OCI: scripts de grupo definidos por el usuario
Agradecimientos
-
Autor: Suraj Ramesh (Gestor de productos de Full Stack Disaster Recovery)
-
Contribuyentes: Bonnie Rockey (especialista en ingeniería en la nube, Oracle Integration), Akshay Saxena (especialista en ingeniería en la nube, Oracle Integration)
Video 1: Despliegue de Oracle Integration for Disaster Recovery Video 2: Automatización de operaciones de recuperación ante desastres para Oracle Integration mediante OCI Full Stack DR Video 3: Scripts utilizados para automatizar la recuperación para Oracle Integration
Más recursos de aprendizaje
Explore otros laboratorios en docs.oracle.com/learn o acceda a más contenido de aprendizaje gratuito en el canal YouTube de Oracle Learning. Además, visite education.oracle.com/learning-explorer para convertirse en Oracle Learning Explorer.
Para obtener documentación sobre el producto, visite Oracle Help Center.
Automate Recovery for Oracle Integration using OCI Full Stack Disaster Recovery
F99102-01
May 2024