¿Qué es la recuperación ante desastres?

La recuperación ante desastres (DR) es una de las facetas de los planes generales de continuidad empresarial diseñados y mantenidos por las distintas líneas de negocio de una organización. Un plan eficaz de recuperación ante desastres mitiga el impacto que suponen las interrupciones no planificadas (o incluso planificadas) de los sistemas esenciales para las misiones y el negocio en la capacidad de una empresa para operar y seguir generando ingresos.

Para ello, el plan de recuperación antes desastres proporciona a las organizaciones una estructura flexible que les permite operar de manera unificada y colaborativa para restaurar, volver a desarrollar y revitalizar sus sistemas, así como construir una infraestructura más resiliente.

¿Por qué es importante la recuperación ante desastres?

¿Cuánto tiempo podría seguir operando una empresa si perdiera su sistema de nóminas justo antes del cálculo de la paga y del envío del dinero a la cuentas? ¿En qué sanciones incurriría una empresa debido al retraso en el pago de impuestos nacionales, regionales o locales? ¿Qué consecuencias tendría para la empresa no pagar a su personal a tiempo y cuánto tiempo seguirían trabajando los empleados?

¿Tener un sistema de recuperación ante desastres o no tenerlo? Esa ya no es la cuestión. La verdadera pregunta es: ¿cuál es el verdadero costo de perder en un instante minutos, días o semanas de datos importantes y la confianza generada a lo largo de años?

La recuperación ante desastres ya no puede seguir improvisándose, o recibir atención tan solo cuando se dispone del presupuesto suficiente. Hoy en día, se espera que las organizaciones reaccionen rápidamente frente a los eventos disruptivos y permanezcan operativas. En lugar de desalentarse ante el costo de implementar un plan de resiliencia, las organizaciones deben ir más allá y analizar el costo real de no contar con ningún plan. Deben pensar, por ejemplo, en los acuerdos de nivel de servicio (SLA) que no se podrían cumplir, o las penalizaciones y la pérdida de ingresos que se derivarían de una interrupción. Si comparamos el costo de implementar un sistema de recuperación ante desastres con las penalizaciones y la pérdida de ingresos y de confianza de los clientes, la decisión es clara.

La imagen se titula "Pérdida de ingresos, productividad y lealtad". En esta imagen se muestran tres estadísticas clave. Estas cifras provienen de un estudio encargado por IBM a Forrester Consulting en 2019. La pregunta planteada a los encuestados fue: "¿A cuál de los siguientes costos se enfrenta tu organización en caso de tiempos de inactividad, ya sean planificados o no?"
La estadística que aparece a la izquierda refleja que el 53 % de los encuestados respondió "Pérdida de ingresos". La estadística central muestra que el 47 % contestó "Pérdida de productividad". La estadística de la derecha indica que el 41 % respondió "Pérdida de confianza o de capital de marca".

Interrupciones no planificadas

Tanto si la interrupción es causada por desastres naturales, errores de los técnicos de TI / proveedores de servicios, corrupción de datos o ataques de ransomware, una organización debe ser capaz de protegerse de disrupciones en sus operaciones comerciales que dan lugar a pérdidas catastróficas, a su reemplazo por competidores oportunistas, y a la degradación de su reputación y su fondo de comercio.

Si bien estas consecuencias potenciales parecen dramáticas, reflejan las experiencias recientes de muchas organizaciones conocidas que no se recuperaron a tiempo, y perdieron por ello grandes cantidades de datos transaccionales críticos, información de sus clientes y la confianza de estos.

Las operaciones de negocio pueden verse interrumpidas por una amplia variedad de escenarios y causas raíz.

Esta imagen se titula "Causas principales de los tiempos de inactividad no planificados". En la imagen aparece un gráfico de barras que muestra las causas de las interrupciones no planificadas. El gráfico de barras se divide en tres categorías: fallos operativos, desastres naturales y eventos causados por humanos. Los fallos operativos se agrupan en la parte del gráfico de barras situada más a la izquierda, los desastres naturales se encuentran en el centro, y los eventos causados por humanos, a la derecha. Este gráfico ha sido elaborado por Forrester Research, Inc.

Interrupciones planificadas

La recuperación ante desastres como servicio (DRaaS) en la nube ofrece a las empresas opciones de flexibilidad operativa sin precedentes. Las organizaciones utilizan las soluciones de recuperación ante desastres para sus interrupciones planificadas con mayor frecuencia que para recuperarse de eventos catastróficos.

Problemas habituales

• Los enfoques tradicionales de la recuperación ante desastres requieren inversiones en automatización.
• Incluso los sistemas de negocio de los centros de datos de nivel 1 pueden verse afectados por interrupciones del suministro eléctrico desgraciadamente habituales. A menudo, un incidente común, como una interrupción del suministro eléctrico, causa un día o dos de pérdida de productividad. El personal de TI termina perdiendo horas o un gran número de días en conferencias telefónica para reactivar los sistemas mediante soluciones provisionales. • Algunas empresas gastan una parte significativa de sus presupuestos de TI en el desarrollo de soluciones de automatización internas para gestionar la recuperación ante desastres pero temen usarlas, o incluso probarlas periódicamente para garantizar que siguen funcionando como se esperaba. • A menudo se tarda un día (o varios) en recuperarse de una ventana de mantenimiento planificada. • Incluso los planes de recuperación ante desastres o runbooks bien documentados pueden suponer días de pérdida de productividad y requerir auténticas proezas por parte del personal de operaciones de TI para que todo vuelva a funcionar.

Objetivos clave de la recuperación ante desastres

Los dos objetivos principales de la recuperación ante desastres son devolver los sistemas afectados a un estado operativo lo más rápido posible, y lograrlo con la menor pérdida de datos posible, tras un evento catastrófico o una interrupción planificada. Las métricas para estos dos objetivos clave se conocen universalmente como el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO) respectivamente.

Cada sistema empresarial tendrá diferentes requisitos para estas dos métricas en función del acuerdo de nivel de servicio entre las operaciones de TI y los propietarios del negocio.

La imagen se titula "Terminología de la protección de datos". La tolerancia a la pérdida de datos y a los tiempos de inactividad se representan en una línea recta que se extiende en direcciones opuestas desde el centro de la imagen. A la izquierda tenemos la "Pérdida de datos" y, a la derecha, los "Tiempos de inactividad".

Objetivo de tiempo de recuperación

El objetivo de tiempo de recuperación es el tiempo que se tarda en restaurar un sistema de negocio a un estado totalmente operativo después de las interrupciones, ya sean planificadas o no.

Objetivo de punto de recuperación

Un objetivo de punto de recuperación (RPO, por sus siglas en inglés) es la cantidad máxima de datos que se pueden perder antes de causar un daño perjudicial a cualquier sistema de negocio determinado. Generalmente, el RPO se mide en el tiempo desde el delta de la última copia de seguridad, replicación o instantánea de datos.

Recuperación ante desastres frente a alta disponibilidad

Tradicionalmente, la alta disponibilidad (HA, por sus siglas en inglés) protege contra puntos únicos de fallo, mientras que la recuperación ante desastres protege contra múltiples puntos de fallo. En informática en la nube, la protección contra puntos únicos de fallo en la capa de infraestructura física, incluidos el suministro eléctrico, la refrigeración, el almacenamiento, las redes y los servidores físicos, se abstrae por completo de la arquitectura general mediante dominios de disponibilidad y de errores.

La alta disponibilidad es escalable y altamente resiliente a la pérdida de datos o de rendimiento de procesamiento. Casi todos los proveedores de nube de clase empresarial incorporan alta disponibilidad a su oferta.

Las soluciones de recuperación ante desastres de alta disponibilidad que ofrecen cero pérdida de datos y protección sin tiempo de inactividad para las bases de datos resultan costosas cuando recurren a tecnologías complejas de replicación y asignación de datos. Estas soluciones no proporcionan protección contra el ransomware, la cual se logra a través copias de seguridad completas con un objetivo de punto de recuperación a un momento dado y almacenamiento inmutable.

Las soluciones de alta disponibilidad tradicionales funcionan bien junto con una solución de recuperación ante desastres en la nube (CDR, por sus siglas en inglés) de bajo costo. Los complementos de tecnología de CDR proporcionan una capa adicional de protección para las bases de datos que requieren cero pérdidas de datos y alta disponibilidad sin tiempo de inactividad, así como protección contra el ransomware con restauración incremental a largo plazo.

La recuperación ante desastres local es una solución rígida y onerosa debido al alto costo que supone duplicar la infraestructura de TI en una ubicación de origen y en un centro de datos de destino fijo. No puede funcionar a través de la WAN ni migrar servidores entre entornos dispares, por lo que requiere un circuito dedicado entre los centros de datos de origen y destino para funcionar como un único entorno LAN interconectado. La recuperación ante desastres tradicional tampoco puede migrar servidores entre entornos heterogéneos dispares, como un entorno local y una plataforma en la nube o entre dos plataformas en la nube diferentes.

La DRaaS utiliza una combinación de soluciones de copia de seguridad suministradas por el proveedor y herramientas de migración de código abierto para crear un entorno muy específico y controlado. El usuario final solo puede recuperar cargas de trabajo en el entorno de alojamiento tradicional del proveedor de DRaaS desde su entorno local de VMware. Estas soluciones ofrecidas por los proveedores pueden ser costosas y el rango de cargas de trabajo que pueden proteger y de entornos informáticos que pueden soportar puede ser limitado.

Flujos de trabajo, runbooks y planes de recuperación ante desastres

Habitualmente, en Oracle denominamos a los flujos de trabajo de recuperación ante desastres "planes de recuperación ante desastres". Un plan de recuperación ante desastres (o runbook) es una lista de pasos o tareas predeterminados que se deben completar para migrar la instancia informática, la plataforma, la base de datos y las aplicaciones a una región de recuperación predeterminada en la nube. Estos planes incluyen todas las tareas o pasos individuales que ejecuta una persona o algún tipo de automatización durante una operación de recuperación ante desastres, como una operación de switchover o failover. Los términos plan de recuperación ante desastres, runbook de recuperación ante desastres y flujo de trabajo de recuperación ante desastres son intercambiables.

Operaciones de recuperación ante desastres (switchover frente a failover)

Una operación de recuperación ante desastres es el proceso de ejecución de cada paso o tarea predeterminados del plan de recuperación ante desastres necesario para restaurar la infraestructura, la base de datos y las aplicaciones a un estado totalmente operativo. Para describir la migración de una pila de aplicaciones a una ubicación diferente se utilizan dos términos: failover y switchover.

Conmutación por error

Un failover implica una interrupción no planificada en la que las aplicaciones, las bases de datos y las máquinas virtuales se han bloqueado y todos los recursos, incluidos el almacenamiento, los datos y los sistemas operativos de invitado, se hallan en un estado incoherente. En este caso, se supone que la región de nube principal está completamente inaccesible y no se encuentra disponible, lo que indica que se debe iniciar una verdadera operación de recuperación ante desastres.

Por lo tanto, el conjunto de las tareas de un plan de recuperación ante desastres solo puede realizarse en la región de nube en espera. Es fundamental que las soluciones de DRaaS de los proveedores de nube estén diseñadas para ofrecer alta disponibilidad en la región en espera, a fin de garantizar que esta esté accesible y funcional cuando se produzca un desastre catastrófico.

Switchover

El switchover implica un tiempo de inactividad planificado que incluye un cierre ordenado de las aplicaciones, bases de datos y máquinas virtuales o servidores. En este caso, la región principal y en espera funcionan normalmente, y el personal de operaciones de TI probablemente se centre en desplazar uno o más sistemas de una región a otra para realizar tareas de mantenimiento o llevar a cabo actualizaciones sucesivas.

Estrategia de despliegue en la nube

Las empresas modernas pueden aprovechar uno o varios de los siguientes modelos de despliegue en la nube por diversos motivos, incluidos requisitos de costos, rendimiento y continuidad del negocio. A medida que las empresas van migrando sus operaciones a la nube, cada vez es más habitual contar con una estrategia sólida de despliegue en la nube.

Soluciones de recuperación ante desastres entre regiones

Las soluciones de recuperación ante desastres entre regiones protegen a las organizaciones de interrupciones totales que afectarían al acceso a los sistemas empresariales alojados en la infraestructura en la nube de un único proveedor en la nube. Como su nombre indica, toda la pila de aplicaciones de un sistema empresarial determinado, incluidas las máquinas virtuales, las bases de datos y las aplicaciones, se puede transferir on-demand a una región de nube totalmente diferente situada en una ubicación geográfica distinta.

Las soluciones de DRaaS deben poder realizar la transición de un sistema empresarial completo, como un portal de recursos humanos o servicios financieros, o una aplicación de gestión de recursos empresariales, a una región de nube totalmente diferente. Los sistemas de DRaaS deben poder cumplir los objetivos de tiempo y punto de recuperación que requieren los acuerdos de nivel de servicio para cada aplicación específica.

Las soluciones de recuperación ante desastres entre regiones, como Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery, protegen aplicaciones empresariales completas de la pérdida catastrófica de acceso a la totalidad de una región de nube, incluida la pérdida de todos los dominios de disponibilidad de esa región.

Soluciones de recuperación ante desastres en la nube híbrida

La recuperación ante desastres en la nube híbrida es una solución muy popular que permite a las empresas migrar cargas de trabajo y máquinas virtuales desde sus propios centros de datos a una infraestructura en la nube. La nube híbrida se utiliza a menudo como solución de recuperación ante desastres para proteger los datos y la viabilidad de los sistemas empresariales críticos de una empresa.

Para los clientes de Oracle, la nube híbrida es una combinación flexible de OCI y servidores físicos, dispositivos en la nube de Oracle u otros sistemas en el centro de datos físico de una empresa. Dispositivos en la nube de Oracle como Oracle Private Cloud Appliance X9-2 y Oracle Exadata Cloud@Customer son excelentes ejemplos de sistemas locales que se integran bien con OCI.

Algunos productos de socios de Oracle, como Rackware, se pueden utilizar para lograr la recuperación ante desastres entre la infraestructura local y OCI. Rackware está disponible en Oracle Cloud Marketplace.

Soluciones de recuperación ante desastres multinube

Las soluciones de recuperación ante desastres multinube protegen aplicaciones y datos mediante la distribución de los distintos componentes de una pila de aplicaciones en las infraestructuras en la nube de dos o más proveedores de nube. La colaboración de Oracle con Microsoft Azure es un buen ejemplo de una relación multinube.

La recuperación ante desastres como servicio debe poder permitir la recuperación ante desastres entre regiones, la recuperación ante desastres en la nube híbrida y la recuperación ante desastres multinube. Actualmente, OCI proporciona DRaaS para la recuperación ante desastres entre regiones y la recuperación ante desastres en la nube híbrida.

Coherencia de datos de las bases de datos

Para ser viables, la soluciones de recuperación ante desastres que se aplican a bases de datos deben proporcionar siempre medios para garantizar la coherencia de los datos. El punto en el que una base de datos se puede recuperar hasta la coherencia total de los datos, incluidas las transacciones en curso, representa el objetivo de punto de recuperación.

La coherencia de datos es un problema menor para las bases de datos de archivos planos o sin servidor. Sin embargo, en el caso de las bases de datos relacionales sofisticadas, como Oracle Database o MySQL, la restauración a un estado coherente de los datos en un momento determinado es muy compleja, pero aún así crucial.

Consideraciones sobre la recuperación ante desastres de las bases de datos MySQL

Cuando se utiliza MySQL Database Service en OCI, un sistema de base de datos MySQL es un contenedor lógico para una o más instancias MySQL. Proporciona una interfaz que permite la gestión de tareas como el aprovisionamiento, las copias de seguridad automáticas y la recuperación a un momento dado.

Las tecnologías de replicación nativa y registro binario de MySQL ofrecen recuperación a un momento dado, alta disponibilidad y recuperación ante desastres. La replicación de grupo de MySQL se suele utilizar con el fin de crear clústeres locales tolerantes a fallos para conseguir alta disponibilidad, mientras que la replicación asíncrona de MySQL sirve habitualmente para la recuperación ante desastres distribuida geográficamente.

Un sistema de base de datos de alta disponibilidad cuenta con tres instancias MySQL ubicadas en diferentes dominios de disponibilidad o dominios de errores. El sistema de base de datos garantiza que si una instancia falla, otra toma el control, sin pérdida de datos y con un tiempo de inactividad mínimo. Para la recuperación ante desastres en diferentes regiones, también se pueden crear canales de replicación entrantes entre dos sistemas de base de datos.

Haz clic en los siguientes enlaces para acceder a más información sobre la recuperación ante desastres en la nube para MySQL.

• Visión general de la continuidad del negocio para MySQL
• Visión general de la alta disponibilidad para MySQL
• Visión general de la replicación entrante para MySQL

Consideraciones sobre la recuperación ante desastres de las bases de datos Oracle

Oracle Maximum Availability Architecture (MAA) ofrece mejores prácticas de arquitectura, configuración y ciclo de vida para las bases de datos Oracle, lo que ofrece niveles de servicio de alta disponibilidad para bases de datos que residen en configuraciones locales, en la nube o híbridas.

Haz clic en los siguientes enlaces para obtener más información sobre Oracle Maximum Availability Architecture para la recuperación ante desastres en la nube.

• Oracle Maximum Availability Architecture: página de inicio
• Oracle Maximum Availability Architecture: arquitecturas de referencia
• Oracle Maximum Availability Architecture: mejores prácticas para Oracle Fusion Middleware
• Oracle Maximum Availability Architecture: mejores prácticas para aplicaciones

Arquitecturas de despliegue basadas en la nube

La arquitectura de despliegue describe cómo se despliegan varios componentes, como recursos informáticos, plataformas / bases de datos y aplicaciones, entre regiones en la nube para crear un medio resiliente de recuperación ante el fallo total de un centro de datos. La arquitectura de despliegue describe dónde se ubica cada componente durante el funcionamiento normal de un conjunto de aplicaciones, y qué se debe recuperar en la región en espera para que todo vuelva a funcionar de nuevo.

Oracle cree que las soluciones de DRaaS deben contar con la flexibilidad de incorporar cualquier combinación de arquitecturas de despliegue de recuperación ante desastres, con el fin cumplir los requisitos de nivel de servicio específicos de cada sistema de negocio. Los proveedores de servicios en la nube deben ofrecer a sus clientes la libertad de elegir cualquier tipo de solución para cumplir los SLA de la amplia variedad de sistemas de negocio que las organizaciones suelen soportar.

Se utilizan varios términos para describir las estrategias de recuperación ante desastres y las arquitecturas de despliegue. Sin embargo, los distintos enfoques y patrones para describir cómo implementar la infraestructura, la plataforma y las aplicaciones para la recuperación ante desastres se dividen en dos amplias categorías estratégicas: recuperación ante desastres activa/activa y recuperación ante desastres activa/en espera.

En la siguiente tabla, se desglosan los términos comunes utilizados para describir las distintas arquitecturas de despliegue incluidas en las dos estrategias generales de recuperación ante desastres.

Estrategia	Arquitectura de despliegue	Objetivo de punto de recuperación	Objetivo de tiempo de recuperación
Activa/en espera	Espera en frío	horas	horas
Activa/en espera	Piloto	minutos	horas
Activa/en espera	Espera activa	segundos	horas
Activa/en espera	Espera en caliente	segundos	minutos
Activa/activa	Activa/activa	casi nulo	casi nulo

Esta sección intenta desmitificar algunas de las variaciones de los enfoques activo/activo y activo/en espera para la recuperación ante desastres. Ambas estrategias de recuperación ante desastres ocupan un lugar en el abanico de medios disponible para lograr la continuidad de las actividades.

Arquitecturas de despliegue activas/en espera

Hay muchas variaciones de las arquitecturas de despliegue activas/en espera. Los despliegues activos/en espera, a veces denominados despliegues activos/pasivos, se suelen caracterizar como despliegues en espera pilotos, en frío, activos y en caliente.

Los escenarios piloto, de espera en frío, espera activa y espera en caliente son de alguna forma similares: el 100 % de una pila de aplicaciones se ejecuta en la región principal, mientras que menos del 100 % del mismo sistema de negocio se ejecuta activamente en la región en espera.

La siguiente serie de diagramas conceptuales generales tiene por objeto ilustrar algunas diferencias fundamentales entre las arquitecturas de despliegue comunes y no pretende ser una arquitectura de referencia, ya que no describe cómo implementar la recuperación ante desastres para una pila de aplicaciones.

Espera en frío

En este escenario, las máquinas virtuales (VM), la base de datos y las aplicaciones existen solo en la región principal actual. Los grupos de volúmenes de almacenamiento de archivos y bloques que contienen el disco de inicio y cualquier otro disco virtual para cada máquina virtual se replican en la región en espera.

Muestra una imagen con la región principal a la izquierda y la región en espera a la derecha. La región principal se divide en tres bloques: aplicación, base de datos e infraestructura, cada uno con sus respectivos iconos. En la parte superior, ambas regiones incluyen un icono que representa un equilibrador de carga. El icono de equilibrador de carga de la región en espera es un tono más claro que el de la región principal. La región en espera cuenta con tres bloques: aplicación, base de datos e infraestructura. En la región en espera, tan solo aparecen iconos en el bloque de infraestructura: uno para el almacenamiento de objetos, uno para el almacenamiento de bloques, y otro para el almacenamiento de archivos. Los bloques de base de datos y aplicación de la región en espera están vacíos. Entre los dos bloques de infraestructura aparecen dos flechas que representan la replicación del almacenamiento de objetos y la replicación del almacenamiento. Estas flechas representan la replicación de la región principal a la región en espera.

Durante una operación de recuperación ante desastres, como una operación de switchover o failover, el almacenamiento replicado, que contiene las mismas máquinas virtuales, se activa en la región en espera, y se vuelven a iniciar exactamente las mismas máquinas virtuales en el punto en que se pararon o bloquearon. Las VM son las mismas máquinas virtuales que se ejecutaban anteriormente en la región activa.

Esta arquitectura de implementación tiene varias ventajas, incluyendo costos menos elevados de implementación, menores gastos generales de mantenimiento y menores costos operativos. Sin embargo, puede que esta no sea la mejor solución para aplicaciones que dependen de bases de datos relacionales para el backend, ya que la única manera de garantizar la coherencia de los datos es realizar copias de seguridad periódicas en frío. Este enfoque funciona bien para aplicaciones que pueden tolerar ocasionalmente interrupciones totales de corta duración.

La mayoría de las operaciones de TI resuelven este problema cerrando periódicamente la base de datos, realizando una instantánea del almacenamiento de bloques y, a continuación, reanudando las operaciones normales. Esto define el objetivo de punto de recuperación, ya que solo se puede restaurar al punto en el tiempo en que se realizó la copia de seguridad.

Esta arquitectura tendrá un tiempo de recuperación un poco más largo y el riesgo de pérdida de datos será mucho mayor, pero se trata de una solución viable para las cargas de trabajo adecuadas. Por ejemplo, puede resultar una solución excelente para aplicaciones que se basan en una base de datos de archivos planos, una base de datos sin servidor o ninguna base de datos, o para clientes que simplemente desean contar con un conjunto de máquinas virtuales que se pueden desplazar entre regiones para disfrutar de mayor flexibilidad.

Ejemplos de flujos de trabajo de recuperación ante desastres para esta arquitectura de despliegue

En los dos escenarios siguientes se describe cómo podría ser la progresión del flujo de proceso de las operaciones de recuperación ante desastres para los despliegues en espera en frío.

En el caso de un switchover, se realizan las siguientes tareas en las regiones principal y en espera:

• Las aplicaciones principales se desactivan.
• Las bases de datos principales se desactivan y sincronizan en la región en espera.
• Las máquinas virtuales primarias se paran correctamente.
• El almacenamiento primario se sincroniza con la región en espera.
• El almacenamiento replicado se conecta, la replicación se revierte, y ahora este almacenamiento es el principal en la región en espera.
• Se inician las copias replicadas de las máquinas virtuales principales, y todas las aplicaciones o herramientas del sistema que requiere la pila de aplicaciones se activan y ahora son las principales de la región en espera.
• Las copias replicadas de las bases de datos primarias se recuperan en la región en espera mediante la última copia de seguridad o transacción en frío y los redo logs del almacenamiento replicado.
• Las copias replicadas de las bases de datos primarias se inician y se montan y se convierten en las principales de la región en espera.
• Las copias replicadas de las aplicaciones principales se inician y validan, y ahora son las principales de la región en espera.
• Se lleva a cabo cualquier cambio necesario en el sistema de nombres de dominio (DNS) y los equilibradores de carga para permitir el acceso a la aplicación a través de la red pública.

En el caso de un failover, se realizan las siguientes tareas únicamente en la región en espera:

• El almacenamiento replicado se conecta, la replicación se revierte, y ahora este almacenamiento es el principal en la región en espera.
• Se inician las copias replicadas de las máquinas virtuales principales, y todas las aplicaciones o herramientas del sistema que requiere la pila de aplicaciones se activan y ahora son las principales de la región en espera.
• Las copias replicadas de las bases de datos primarias se recuperan en la región en espera mediante la última copia de seguridad o transacción en frío y los redo logs del almacenamiento replicado.
• Las copias replicadas de las bases de datos primarias se inician y se montan y se convierten en las principales de la región en espera.
• Las copias replicadas de las aplicaciones principales se inician y validan, y ahora son las principales de la región en espera.
• Se lleva a cabo cualquier cambio necesario en el sistema de nombres de dominio (DNS) y los equilibradores de carga para permitir el acceso a la aplicación a través de la red pública.

Espera activa

En este escenario, las máquinas virtuales existen en las regiones principal y en espera, pero son completamente independientes entre sí y tienen sus propios nombres de host únicos y direcciones IP asignadas previamente. Las máquinas virtuales de la región en espera existen y se pueden detener o ejecutar según las preferencias del cliente.

Muestra una imagen con la región principal a la izquierda y la región en espera a la derecha. La región principal tiene tres bloques: aplicación, base de datos e infraestructura, cada uno con sus respectivos iconos. En la parte superior, ambas regiones incluyen un icono que representa un equilibrador de carga. El icono de equilibrador de carga de la región en espera es un tono más claro que el de la región principal. La región en espera cuenta con tres bloques: aplicación, base de datos e infraestructura. En la región en espera, el bloque de infraestructura contiene iconos: uno para el almacenamiento de objetos, uno para el almacenamiento de bloques y otro para el almacenamiento de archivos. También existe un icono para las máquinas virtuales en el nivel de infraestructura, pero es un tono más claro. Los iconos de base de datos y el icono de aplicaciones de la región en espera también son un tono más claros. Entre los dos bloques de infraestructura aparecen dos flechas que representan la replicación del almacenamiento de objetos y la replicación del almacenamiento. Estas flechas representan la replicación de la región principal a la región en espera.

Las bases de datos se deben estar ejecutando en las regiones principal y en espera.

Para las bases de datos Oracle, recomendamos utilizar Oracle Data Guard a la hora de replicar la base de datos principal y la base de datos en espera. Consulta nuestra arquitectura de referencia Gold MAA para obtener más información.

Para bases de datos que no sean de Oracle, se utilizarán las tecnologías de replicación nativas respectivas para mantener las bases de datos sincronizadas entre las regiones principal y en espera.

Las aplicaciones también existen en la región de nube en espera, pero no se encuentran en ejecución ni se puede acceder a ellas.

Ejemplos de flujos de trabajo de recuperación ante desastres para esta arquitectura de despliegue

En los dos escenarios siguientes se describe cómo podría ser la progresión del flujo de proceso de las operaciones de recuperación ante desastres para los despliegues en espera activa.

En el caso de un switchover, se realizan las siguientes tareas en las regiones principal y en espera:

• Las aplicaciones principales se desactivan.
• Las bases de datos principales se desactivan y sincronizan en la región en espera.
• Las máquinas virtuales primarias se paran correctamente.
• El almacenamiento primario se sincroniza con la región en espera.
• El almacenamiento replicado se conecta, la replicación se revierte, y ahora este almacenamiento es el principal en la región en espera.
• Si no se encuentran ya en ejecución, se inician las máquinas virtuales principales, y todas las aplicaciones o herramientas del sistema que requiere la pila de aplicaciones se activan y ahora son las principales de la región en espera.
• Las bases de datos en espera se cambian a acceso completo de lectura/escritura y ahora son las principales de la región en espera.
• Las aplicaciones en espera se inician y validan y ahora son las principales en la región en espera.
• Se lleva a cabo cualquier cambio necesario en el sistema de nombres de dominio (DNS) y los equilibradores de carga para permitir el acceso a la aplicación a través de la red pública.

En el caso de un failover, se realizan las siguientes tareas únicamente en la región en espera:

• El almacenamiento replicado se conecta, se revierte la replicación a ser posible, y este almacenamiento se convierte en el almacenamiento principal de la región en espera.
• Si no se encuentran ya en ejecución, se inician las máquinas virtuales principales, y todas las aplicaciones o herramientas del sistema que requiere la pila de aplicaciones se activan y ahora son las principales de la región en espera.
• Las bases de datos en espera se recuperan mediante la última transacción y los redo logs del almacenamiento replicado.
• Las bases de datos en espera se cambian a acceso completo de lectura/escritura y ahora son las principales de la región en espera.
• Las aplicaciones en espera se inician y validan y ahora son las principales en la región en espera.
• Se lleva a cabo cualquier cambio necesario en el sistema de nombres de dominio (DNS) y los equilibradores de carga para permitir el acceso a la aplicación a través de la red pública.

Espera en caliente

En este escenario, existen máquinas virtuales que se ejecutan en las regiones principal y en espera con sus propios nombres de host únicos y direcciones IP asignadas previamente.

Muestra una imagen con la región principal a la izquierda y la región en espera a la derecha. La región principal tiene tres bloques: aplicación, base de datos e infraestructura, cada uno con sus respectivos iconos. En la parte superior, ambas regiones incluyen un icono que representa un equilibrador de carga. El icono de equilibrador de carga de la región en espera es un tono más claro que el de la región principal. La región en espera cuenta con tres bloques: aplicación, base de datos e infraestructura. Las regiones principal y en espera muestran iconos en los bloques de aplicación, base de datos e infraestructura. El bloque de infraestructura cuenta con iconos para las máquinas virtuales, el almacenamiento de archivos, el almacenamiento de objetos y el almacenamiento de bloques en las regiones principal y en espera. Únicamente los iconos de base de datos de la región en espera son un tono más claros. Entre los dos bloques de infraestructura aparecen dos flechas que representan la replicación del almacenamiento de objetos y la replicación del almacenamiento. Estas flechas representan la replicación de la región principal a la región en espera.

Las bases de datos se deben estar ejecutando en las regiones principal y en espera.

Para las bases de datos Oracle, recomendamos utilizar Oracle Data Guard a la hora de replicar la base de datos principal y la base de datos en espera. Consulta nuestra arquitectura de referencia Gold MAA para obtener más información.

Para bases de datos que no sean de Oracle, se utilizarán las tecnologías de replicación nativas respectivas para mantener las bases de datos sincronizadas entre las regiones principal y en espera.

Las aplicaciones se ejecutan en la región de nube en espera, pero no se puede acceder a ellas a través de la red pública.

Ejemplos de flujos de trabajo de recuperación ante desastres para esta arquitectura de despliegue

En los dos escenarios siguientes se describe cómo podría ser la progresión del flujo de proceso de las operaciones de recuperación ante desastres para los despliegues en espera en caliente.

En el caso de un switchover, se realizan las siguientes tareas en las regiones principal y en espera:

• Las aplicaciones principales se desactivan.
• Las bases de datos principales se desactivan y sincronizan en la región en espera.
• Las máquinas virtuales primarias se paran correctamente.
• El almacenamiento primario se sincroniza con la región en espera.
• El almacenamiento replicado se conecta, la replicación se revierte, y ahora este almacenamiento es el principal en la región en espera.
• Las máquinas virtuales en espera ya se encuentran en ejecución, y todas las aplicaciones o herramientas del sistema que requiera la pila de aplicaciones se activan y ahora son las principales en la región en espera.
• Las bases de datos en espera se cambian a acceso completo de lectura/escritura y ahora son las principales de la región en espera.
• Las aplicaciones en espera se inician y validan y ahora son las principales en la región en espera.
• Se lleva a cabo cualquier cambio necesario en el sistema de nombres de dominio (DNS) y los equilibradores de carga para permitir el acceso a la aplicación a través de la red pública.

En el caso de un failover, se realizan las siguientes tareas únicamente en la región en espera:

• El almacenamiento replicado se conecta, se revierte la replicación a ser posible, y este almacenamiento se convierte en el almacenamiento principal de la región en espera.
• Si no se encuentran ya en ejecución, se inician las máquinas virtuales principales, y todas las aplicaciones o herramientas del sistema que requiere la pila de aplicaciones se activan y ahora son las principales de la región en espera.
• Las bases de datos en espera se recuperan mediante la última transacción y los redo logs del almacenamiento replicado.
• Las bases de datos en espera se cambian a acceso completo de lectura/escritura y ahora son las principales de la región en espera.
• Las aplicaciones en espera se inician y validan y ahora son las principales en la región en espera.
• Se lleva a cabo cualquier cambio necesario en el sistema de nombres de dominio (DNS) y los equilibradores de carga para permitir el acceso a la aplicación a través de la red pública.

Arquitectura de despliegue activa/activa

En este escenario, toda la pila de aplicaciones es totalmente funcional y maneja una carga de trabajo tanto en la región principal como en la región en espera.

Muestra una imagen con la región principal a la izquierda y la región en espera a la derecha. La región principal y la región en espera tienen tres bloques: aplicación, base de datos e infraestructura, cada uno con sus respectivos iconos. En la parte superior, ambas regiones incluyen un icono que representa un equilibrador de carga. Ninguna de ellos aparece en gris. Los iconos de los bloques de aplicación, base de datos e infraestructura de las regiones principal y en espera se muestran en color. Entre los dos bloques de infraestructura aparece una flecha que representa la replicación del almacenamiento opcional. Esta flecha representa la replicación de la región principal a la región en espera.

Las bases de datos se deben estar ejecutando en las regiones principal y en espera.

Para las bases de datos Oracle, recomendamos utilizar Oracle GoldenGate con el fin de crear una configuración de aplicación activa/activa. Además, aconsejamos disponer de bases de datos locales en espera en cada región utilizando Oracle Data Guard para lograr un RTO y un RPO prácticamente nulos. Consulta nuestra arquitectura de referencia Platinum MAA para obtener más información.

Para bases de datos que no sean de Oracle, se utilizarán las tecnologías de replicación y activas/activas nativas respectivas a fin de mantener las bases de datos sincronizadas entre las regiones principal y en espera.

Las aplicaciones se ejecutan y se puede acceder a ellas a través de la red pública en la región de nube en espera. Además, cuentan con una carga de trabajo en ejecución.

Automatización de tareas de recuperación ante desastres con ayuda de la DRaaS

Los equipos de Oracle se han esforzado mucho por diseñar la alta disponibilidad de sus productos, incluida la gran mayoría de las bases de datos y aplicaciones empresariales de Oracle, y a menudo definen mejores prácticas y arquitecturas de despliegue para lograr la recuperación ante desastres en ajustes locales tradicionales y en la nube. Cada línea de productos establece un enfoque de recuperación ante desastres para cada una de sus aplicaciones que incorpora pasos débilmente acoplados a fin de recuperar cualquier componente necesario para soportar una aplicación.

La recuperación ante desastres como servicio basada en la nube puede vincular todos los pasos débilmente acoplados ideados por desarrolladores, arquitectos en la nube y arquitectos de soluciones de productos a un flujo de trabajo único y fluido que se puede iniciar con un solo clic. OCI ofrece una solución de DRaaS denominada Full Stack Disaster Recovery que es flexible, altamente escalable y muy extensible.

OCI Full Stack Disaster Recovery gestiona la transición de la infraestructura, las bases de datos y las aplicaciones entre regiones de OCI desde cualquier lugar del mundo con un solo clic. Los clientes pueden desplegar entornos de recuperación ante desastres sin rediseñar ni volver a desplegar la infraestructura, las bases de datos o las aplicaciones existentes. Al mismo tiempo, se elimina la necesidad de contar con servidores de conversión o gestión especializados.

• Accede a más información sobre OCI Full Stack Disaster Recovery
• Obtén más información sobre la recuperación ante desastres para OCI