Cómo planificar el disaster recovery de sus sistemas críticos en OCI

Ariel Loría

Cloud Architect de Oracle, Oracle

Ariel Loría

Cloud Architect de Oracle, Oracle

Cuando se interrumpe una base de datos crítica, se detienen las transacciones, junto con todo lo que depende de ellas. La pérdida de datos y el tiempo de recuperación se definen con tres decisiones tomadas con anticipación. Son los objetivos de cada sistema, el nivel de protección de la base de datos y un plan que el equipo ya ensayó. En Oracle Cloud Infrastructure (OCI) esas decisiones se ordenan en cuatro etapas.

Defina el RPO y el RTO de cada sistema crítico

Antes de elegir tecnología, cada sistema crítico necesita dos valores definidos por el negocio. El RPO (Recovery Point Objective) indica cuántos datos puede perder el sistema, medido en tiempo, según la frecuencia de las copias de seguridad o de la replicación en OCI. El RTO (Recovery Time Objective) indica cuánto tiempo puede estar fuera de servicio, según el diseño de la estrategia de recuperación y el despliegue de la pila de aplicaciones.

OCI Full Stack Disaster Recovery no tiene configuración para el RPO ni para el RTO, porque ambos resultan del diseño que la empresa elija. Data Guard fija el RPO de las bases de datos Oracle, mientras que la replicación entre regiones de OCI fija el del cómputo.

Elija el nivel de protección de la base de datos

Oracle agrupa sus prácticas de alta disponibilidad en la arquitectura Maximum Availability Architecture (MAA), con cuatro niveles donde cada uno suma capacidades al anterior.

  • Bronze: cubre desarrollo, pruebas y producción con una base de datos de una sola instancia, con respaldo y restauración.
  • Silver: suma alta disponibilidad con Oracle RAC y Application Continuity para producción departamental.
  • Gold: suma la replicación de la base de datos con Active Data Guard o Data Guard para negocio crítico.
  • Platinum: suma GoldenGate y redefinición basada en ediciones para misión crítica.

Cada sistema recibe el nivel que corresponde a su criticidad, con el RPO y el RTO de la etapa anterior como criterio.

Coordine el cambio de región con OCI Full Stack Disaster Recovery

OCI Full Stack Disaster Recovery es un orquestador. Coordina con un solo clic el cambio de región de las bases de datos, el cómputo y las aplicaciones, sobre la replicación que la empresa configuró por separado. Los recursos de cada aplicación se reúnen en un grupo de protección, y cada grupo necesita como mínimo un plan de switchover y uno de failover.

El switchover cambia los roles entre sitios en eventos planificados, mientras que el failover recupera el servicio tras un evento catastrófico sin acceso al sitio principal. Los simulacros (drills) validan el plan sin afectar la operación, por lo que conviene ejecutarlos antes de necesitarlos.

El cómputo se recupera de dos maneras. Con cómputo movible, las máquinas virtuales existen en una sola región y OCI inicia una versión replicada en la región en espera, lo que reduce costo y mantenimiento, pero implica un RTO más alto. Con cómputo no movible, las máquinas corren en ambas regiones, lo que acelera ligeramente la recuperación a cambio de mayor costo. La elección depende del RTO que exige el negocio y del costo que la empresa acepta pagar.

Revise la ruta si parte de un centro de datos propio

Una base de datos que corre en un centro de datos propio puede protegerse en OCI. Oracle recomienda tres destinos.

  • Hacia Base Database Service: Active Data Guard conecta la base local con su par en OCI.
  • Hacia Exadata Cloud: Active Data Guard conecta Exadata local con Exadata Database Service o Exadata Cloud@Customer.
  • Hacia Autonomous Database: GoldenGate conecta una instancia, RAC o Exadata local con la versión Serverless o Dedicated.

Todas estas configuraciones híbridas son manuales, sin automatización del plano de control. Pasar de una base local que no es Exadata a Exadata Cloud es posible, aunque conviene revisar antes las funciones exclusivas de Exadata.

Por dónde empezar

Definir qué debe recuperarse y en cuánto tiempo es la tarea de la que parten las cuatro etapas. Con el RPO y el RTO de cada sistema, el nivel de MAA, el modelo de cómputo y el plan de recuperación se eligen con datos.

Tres preguntas permiten ubicar el punto de partida. ¿Están definidos el RPO y el RTO de los sistemas críticos? ¿Se hizo una prueba completa de recuperación durante el último año? ¿Existe un plan escrito para el cambio de región, con personas a cargo y pasos definidos?

Ante una respuesta negativa, solicite una revisión de arquitectura con los equipos de Novacomp especializados en infraestructura Oracle, donde se ubican sus sistemas en los niveles de MAA y se define el primer plan de recuperación para ensayar.

Este artículo se basa en la presentación de Ariel Loría, Arquitecto de Tecnología de Oracle, en el webinar de Disaster Recovery de Novacomp y Oracle.

Conozca más sobre nuestras soluciones en crnova.com/servicios.

Últimos artículos

Agende una reunión


Este sitio está protegido por reCAPTCHA y se aplican la Política de privacidad y los Términos de servicio de Google.