Continuidad del negocio y recuperación ante desastres para Oracle en el acelerador de zonas de aterrizaje de Azure Virtual Machines

2025-06-21

Este artículo se basa en las consideraciones y recomendaciones que se definen en el área de diseño de la zona de aterrizaje de Azure para la continuidad empresarial y la recuperación ante desastres (BCDR). Este artículo sigue esas instrucciones y describe las consideraciones de diseño y los procedimientos recomendados sobre las opciones de BCDR para las implementaciones de cargas de trabajo de Oracle en máquinas virtuales (VM) de infraestructura de Azure.

Azure proporciona servicios que puede usar para diseñar arquitecturas resistentes y de alta disponibilidad. En esta guía se describen varias opciones y procedimientos recomendados para ayudarle a diseñar la alta disponibilidad y la recuperación ante desastres para las bases de datos de Oracle en el acelerador de zonas de aterrizaje de Azure Virtual Machines. También se describe cómo configurar los servicios de Azure complementarios para ayudarle a lograr una alta disponibilidad de un extremo a otro para su solución.

Comienza

Para crear una arquitectura resistente para el entorno de carga de trabajo, determine los requisitos de disponibilidad de la solución en función del objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO) para varios niveles de error. RTO es el tiempo máximo que una aplicación permanece indisponible después de que se produce un incidente. RPO es la cantidad máxima de pérdida de datos durante un desastre. Después de determinar los requisitos de la solución, diseñe la arquitectura para proporcionar los niveles establecidos de resistencia y disponibilidad.

Las cargas de trabajo de Oracle en Azure utilizan principalmente Oracle Data Guard, que es una función integrada de Oracle Database Enterprise Edition que utiliza la tecnología de replicación. Puede utilizar Data Guard para satisfacer las necesidades de alta disponibilidad y recuperación ante desastres. Data Guard ofrece tres modos de protección: máximo rendimiento, máxima disponibilidad y máxima protección. Elija su modo de protección en función de su diseño arquitectónico y sus requisitos específicos de RPO y RTO.

Configuración de la carga de trabajo para la alta disponibilidad

Las instancias de Azure Virtual Machines que ejecutan cargas de trabajo de Oracle se benefician de la arquitectura de conjuntos de escalado de máquinas virtuales de Azure, concretamente del modo de orquestación flexible. Una configuración de alta disponibilidad proporciona replicación de datos casi en tiempo real con capacidades de conmutación por error potencialmente rápidas. Una configuración de alta disponibilidad no proporciona protección para errores de nivel de centro de datos o de región de Azure.

Elija la opción de alta disponibilidad adecuada

Utilice el siguiente diagrama de flujo para elegir la mejor opción de alta disponibilidad para su base de datos de Oracle.

Uso de Data Guard en modo de máxima disponibilidad para una alta disponibilidad

Data Guard en modo de máxima disponibilidad proporciona la máxima disponibilidad con una promesa de cero pérdida de datos (RPO=0) para las operaciones normales. En el caso de una configuración de alta disponibilidad de dos servidores de bases de datos de Oracle que se crean dentro de una orquestación flexible de conjuntos de escalado de máquinas virtuales, Azure proporciona una disponibilidad de servicio del 99,95% para un contrato de nivel de servicio (SLA) para instancias que se distribuyen entre dominios de error. Azure proporciona una disponibilidad del servicio de% del 99,99 para las instancias que se distribuyen entre zonas de disponibilidad. Para obtener más información, consulte Alta disponibilidad para conjuntos de escalado de máquinas virtuales.

Para obtener una configuración paso a paso de Data Guard en Azure, consulte Implementación de Oracle Data Guard en una máquina virtual de Azure basada en Linux.

Utilice Data Guard en el modo de máxima protección para una alta disponibilidad

Si necesita una copia coherente desde el punto de vista transaccional de la base de datos, considere la posibilidad de utilizar Data Guard en el modo de máxima protección. Sin embargo, el modo de protección máxima no permite que las transacciones continúen cuando la base de datos en espera no está disponible. Por lo tanto, a pesar de usar la orquestación flexible de Virtual Machines Scale Sets, el Acuerdo de Nivel de Servicio se reduce a 99,9% x 99,9% = 99,8% cuando se usa el modo de protección máxima. Esta configuración garantiza una copia coherente de los datos, pero no aumenta necesariamente la disponibilidad.

Otros atributos de esta arquitectura son los mismos que el modo de disponibilidad máxima. Por ejemplo, el RPO es cero y el RTO es menor o igual a dos minutos.

Considere otras formas de implementar la alta disponibilidad

En las secciones siguientes se describen las consideraciones especiales para la alta disponibilidad.

Uso de zonas de disponibilidad para mejorar la alta disponibilidad

Las zonas de disponibilidad de Azure son centros de datos de Azure que se encuentran dentro de la misma región de Azure. Las zonas de disponibilidad tienen una latencia de ida y vuelta de menos de dos milisegundos. Normalmente, las zonas de disponibilidad se utilizan con fines de recuperación ante desastres, pero se pueden utilizar para mejorar la alta disponibilidad. Si lo hace, debe asegurarse de que la solución pueda ejecutarse con la cantidad de latencia y rendimiento que proporcionan las zonas de disponibilidad.

Una ventaja de las zonas de disponibilidad con una orquestación flexible de Virtual Machine Scale Sets es que el Acuerdo de Nivel de Servicio de disponibilidad de la máquina virtual aumenta a 99,99%.

Utilice la agrupación en clústeres de almacenamiento compartido para obtener una alta disponibilidad

Las tecnologías de agrupación en clústeres de almacenamiento compartido proporcionan atributos únicos que pueden ayudarle a alcanzar sus objetivos empresariales. Por ejemplo, puede implementar un clúster de Pacemaker y Corosync (PCS) con almacenamiento compartido. Puede usar discos administrados o Azure NetApp Files como almacenamiento compartido para instancias de clúster de PCS. Un clúster PCS no duplica datos. Proporciona un servicio de IP virtual con una dirección IP estática o un nombre de red IP que no cambia entre las conmutaciones por error.

Nota:

Un clúster PCS no es una solución certificada por Oracle. Tenga en cuenta este factor a la hora de elegir su arquitectura de alta disponibilidad.

Usar grupos de ubicación por proximidad

Para proporcionar la latencia más baja posible, coloque las máquinas virtuales lo más cerca posible. Puede implementarlos dentro de un grupo de ubicación por proximidad. Un grupo de selección de ubicación por proximidad es una agrupación lógica que garantiza que los recursos de proceso de Azure se encuentren físicamente cerca unos de otros. Los grupos de ubicación por proximidad son útiles para cargas de trabajo que requieren baja latencia.

Configuración de la carga de trabajo para la recuperación ante desastres

Una arquitectura de recuperación ante desastres proporciona resistencia frente a errores que afectan a los centros de datos o regiones de Azure, o frente a errores que obstaculizan la funcionalidad de la aplicación en toda una región. En este escenario, debe mover toda la carga de trabajo a un centro de datos o región diferente.

Elija su arquitectura de recuperación ante desastres en función de los requisitos de su solución. Usted determina sus requisitos en función de su RTO y RPO. Las arquitecturas de recuperación ante desastres son para casos de error excepcionales, por lo que los procesos de conmutación por error son manuales. En el diseño de alta disponibilidad, los procesos de conmutación por error son automáticos. En una arquitectura de recuperación ante desastres, debe tener requisitos más relajados para RTO y RPO, lo que ahorra dinero.

Este artículo se centra en escenarios en los que el servidor principal y el servidor secundario están en Azure. También puede tener un servidor principal local y un servidor secundario en Azure con fines de recuperación ante desastres. Para más información, consulte Sitio principal local y sitio de recuperación ante desastres en Azure.

Elija la opción de recuperación ante desastres adecuada

Utilice el siguiente diagrama de flujo para elegir la mejor opción de recuperación ante desastres para su base de datos de Oracle.

Uso de Data Guard para la recuperación ante desastres

Puede utilizar Data Guard para replicar datos en el sitio de recuperación ante desastres. Use ese sitio como otra zona de disponibilidad en la misma región o en una región diferente, en función de sus requisitos de protección de datos. La configuración también depende de la estructura de la zona de disponibilidad del sitio de producción. Una implementación de Data Guard en un escenario de recuperación ante desastres es similar al escenario de alta disponibilidad descrito anteriormente, con algunas diferencias importantes. Por ejemplo:

Al conmutar por error a una réplica secundaria en el escenario de alta disponibilidad, se configura Azure Load Balancer para redirigir las solicitudes a la nueva instancia de base de datos principal.
Cuando se conmuta por error al sitio de recuperación ante desastres, se conmuta por error toda la solución al nuevo sitio. Para evitar desafíos de latencia, normalmente es necesario configurar la conmutación por error para los servicios de aplicaciones.

Si el sitio de recuperación ante desastres está en otra región, debe diseñar el sitio para la conmutación por error en función de sus requisitos.

La latencia dentro de un solo centro de datos es menor que la latencia entre centros de datos que están separados entre sí y mucho menor que la latencia entre diferentes regiones. Por lo tanto, la opción menos compleja y menos costosa es usar Data Guard en modo de máximo rendimiento con fines de recuperación ante desastres. Si la posible pérdida de datos en el modo de máximo rendimiento es demasiado alta, puede utilizar el modo de máxima disponibilidad con el mecanismo de sincronización lejana de Oracle Data Guard. Sin embargo, una instancia de Far Sync desencadena las licencias de Active Data Guard en el entorno principal y en el entorno en espera. Para obtener más información, consulte Detalles de la licencia de Oracle.

Además, cuando se envían datos entre regiones o centros de datos de Azure, se pagan costos de salida por los datos, como los registros de puesta al día, que se envían a un sitio de recuperación ante desastres. Si no necesita replicar todos los datos de la base de datos, puede utilizar la replicación basada en Oracle Golden Gate para replicar solo datos parciales según sea necesario, lo que reduce los costos de salida.

Para obtener una configuración paso a paso de Data Guard en Azure, consulte Implementación de Data Guard en una máquina virtual Linux de Azure basada en Linux.

Utilice Golden Gate para la recuperación ante desastres

Golden Gate es un software de replicación lógica que puede utilizar para la replicación, el filtrado y la transformación de datos en tiempo real de una base de datos de origen a una base de datos de destino o entre varias bases de datos primarias. Esta característica garantiza que los cambios en la base de datos de origen se repliquen casi en tiempo real para que la base de datos de destino esté actualizada con los datos más recientes.

Puede utilizar Golden Gate para replicar datos de una base de datos principal a una base de datos secundaria en una configuración de recuperación ante desastres. Golden Gate es especialmente práctico si necesita proteger solo algunos de sus datos. Para evitar la replicación de datos innecesarios, utilice Golden Gate para replicar tablas de forma selectiva y filtrar las filas de la tabla durante la replicación.

Para obtener una guía paso a paso sobre cómo implementar Golden Gate en Azure, consulte Implementación de Golden Gate en una máquina virtual de Azure basada en Linux.

Uso de la copia de seguridad para la recuperación ante desastres

La copia de seguridad y restauración es un método tradicional para una arquitectura de recuperación ante desastres. Hay dos componentes principales para la copia de seguridad como método de recuperación ante desastres para las bases de datos de Oracle en Azure:

Extraiga y mueva la copia de seguridad de los datos de una base de datos para asegurarse de que el sitio de recuperación ante desastres tenga datos up-toactualizados.
Garantice una implementación up-tofecha en el sitio de recuperación ante desastres. Para actualizar el sitio, replique la misma implementación de todos los componentes de red, servidores de aplicaciones y configuraciones en el sitio de recuperación ante desastres.

Hay varias opciones de copia de seguridad que puede utilizar para replicar datos. Para obtener más información, consulte Estrategias de copia de seguridad para Oracle Database en Azure.

Considere la posibilidad de usar uno de los siguientes enfoques para mantener un sitio de recuperación ante desastres:

Enfoque 1: Para evitar el esfuerzo y el costo de mantenimiento adicionales, no mantenga ninguna implementación física en el sitio de recuperación ante desastres. Puede usar la infraestructura como código y las prácticas de ingeniería de confiabilidad del sitio para desarrollar y mantener un repositorio. Este repositorio puede replicar la implementación como configuración en un sitio de recuperación ante desastres en el momento de la conmutación por error. Este método optimiza el costo porque no usa ningún recurso físico hasta que se produce la conmutación por error.

Importante

Si crea una implementación completa desde cero durante una conmutación por error, debe asegurarse de que la implementación pueda cumplir los requisitos de RTO de la solución. Para asegurarse de que el código de implementación no se rompe, debe simular y probar de forma rutinaria el escenario de recuperación ante desastres.

Enfoque 2: Implemente y mantenga una versión a escala de su entorno de producción. Tener una versión que pueda funcionar correctamente para una carga de trabajo pequeña y que pueda escalar verticalmente según sea necesario durante una conmutación por error para servir para la carga de producción. Este método se usa habitualmente, especialmente para implementaciones complejas en las que no se desea arriesgarse a crear un entorno completo o si se desea conmutar por error rápidamente para proporcionar un RTO bajo.

Enfoque 3: Implemente y mantenga toda su solución en el sitio de recuperación ante desastres para obtener los tiempos de RTO y conmutación por error más rápidos. Este método aumenta el costo debido a la ejecución de una infraestructura totalmente redundante.

Considere otras formas de implementar la recuperación ante desastres

En las secciones siguientes se describen consideraciones especiales para la recuperación ante desastres.

Usar la sincronización lejana

Far Sync no mejora las capacidades de alta disponibilidad, pero puede usarlo para lograr capacidades de protección sin pérdida de datos para las bases de datos de Oracle. Es posible que la carga de trabajo no requiera ninguna pérdida de datos si se produce un error en la base de datos principal. Para más información, consulte Arquitecturas de referencia de Oracle en Azure.

Elija la tecnología de replicación de datos adecuada

Además de las tecnologías de este artículo, puede usar cualquier tecnología que facilite la replicación de datos entre dos bases de datos de Oracle para mantener una réplica de alta disponibilidad y una réplica de recuperación ante desastres para las bases de datos de Oracle en Azure. La tecnología que elija debe satisfacer los requisitos de su solución en estas categorías.

Latencia: La cantidad de tiempo que se tarda en replicar una actualización de una base de datos principal en bases de datos secundarias para alta disponibilidad y recuperación ante desastres debe cumplir con los requisitos de la solución.

Ancho de banda: La cantidad y el costo del ancho de banda que necesita para replicar datos en bases de datos secundarias para alta disponibilidad y recuperación ante desastres. Azure proporciona una infraestructura de red de alta velocidad entre zonas de disponibilidad. Cuando considere la replicación en otras regiones de Azure con fines de recuperación ante desastres, tenga en cuenta la cantidad de ancho de banda y los costos de salida de los datos que salen del centro de datos de Azure.

Impacto: El nivel de impacto que tiene la replicación en el procesamiento de transacciones en la base de datos principal debe cumplir con los requisitos de la solución.

Pérdida de datos: La cantidad de pérdida de datos que se espera durante un error abrupto de la base de datos principal debe cumplir con los requisitos de la solución.

Coste total de propiedad: Tenga en cuenta el costo de adquisición de una solución de replicación que no sea de Microsoft y la cantidad de esfuerzo que necesita para configurar y mantener la solución de replicación. Compruebe que estos factores cumplen con los requisitos de la solución.

Optimización de una instancia de conmutación por error

Cuando se utiliza Data Guard en modo de alta disponibilidad o en modo de alta protección, se puede configurar la conmutación automática por error para que, cuando se produzca un error en el servidor principal, el servidor secundario se active automáticamente. Cuando configura correctamente los servidores de aplicaciones, puede asegurarse de que casi no hay tiempo de inactividad de la aplicación durante una conmutación por error.

En esta implementación, una base de datos debe ejecutarse de la misma manera después de una conmutación por error. Por lo tanto, debe configurar un servidor secundario con la misma CPU, memoria y capacidad de entrada/salida (E/S) que el servidor principal. Necesita mantener una alta capacidad con un servidor secundario, lo que aumenta los costos de Azure y los costos de licencia de Oracle Database. Por lo general, el servidor secundario no procesa las solicitudes de los usuarios.

Azure proporciona una disponibilidad del 99,9% para las máquinas virtuales de una zona de disponibilidad. Para obtener más información, consulte Acuerdo de Nivel de Servicio de tiempo de actividad de la máquina virtual. Cuando se utiliza una tecnología de replicación de datos para mantener una réplica secundaria de la base de datos en la misma zona de disponibilidad, en una zona de disponibilidad diferente o en una región diferente, se puede optimizar la capacidad secundaria.

Con este enfoque, la base de datos secundaria se configura con la capacidad que necesita para mantenerse actualizada. Cuando se produce un error, se cambia el tamaño de la base de datos secundaria a la misma capacidad que la base de datos principal. Esta operación solo se produce si se produce un error. Por lo tanto, durante el funcionamiento normal, solo paga una fracción del costo del servidor principal. La base de datos principal no está operativa durante el error, por lo que no necesita otras licencias de base de datos de Oracle.

La capacidad que necesita para operar una base de datos secundaria como destino de replicación depende de la tecnología de replicación que utilice. Básicamente, una carga de trabajo que se encuentra en un sistema de procesamiento de transacciones transaccionales en línea (OLTP) tiene principalmente solicitudes de lectura. Por ejemplo, las operaciones de lectura de 90% y 10% escritura o las operaciones de lectura de 95% y 5% escritura son comunes en las aplicaciones OLTP. Básicamente, la replicación de datos replica el resultado de escribir solicitudes en la base de datos de origen. Con esta configuración, puede esperar que la base de datos secundaria funcione con 1/10 (si tiene una proporción de 90% lectura y 10% escritura) de la capacidad de la base de datos principal.

Automatice los procedimientos de conmutación por error para asegurarse de que cumple con los estándares empresariales durante el proceso de conmutación por error. Puede configurar los procedimientos de conmutación por error para incluir operaciones de cambio de tamaño del servidor que agilicen el proceso de un extremo a otro.

Configure la topología de red para la protección de servicios y la protección de datos

Para lograr una alta disponibilidad y recuperación ante desastres, debe tomar decisiones financieras y empresariales que equilibren el tiempo de recuperación, o RTO, y la posible pérdida de datos, o RPO, con otros costos de licencias, mantenimiento de máquinas virtuales y transferencia de datos de Oracle. Al hospedar una carga de trabajo en una sola máquina virtual de Azure, se obtiene protección básica para errores de hardware comunes a bajo costo. Sin embargo, es probable que un error en una sola máquina virtual provoque tiempo de inactividad y pérdida de datos. Por lo tanto, en sus entornos de producción, incluya al menos una base de datos secundaria de Oracle que esté alojada en una máquina virtual independiente con Data Guard. En función de sus requisitos, utilice una o varias de las siguientes configuraciones de Data Guard para la replicación de datos:

RTO y RPO óptimos. Para minimizar la latencia, incorpore una base de datos secundaria de Oracle en una máquina virtual independiente dentro de la misma orquestación flexible de conjuntos de escalado de máquinas virtuales y en la misma zona de disponibilidad que la base de datos principal. Esta configuración proporciona alta disponibilidad y protección contra un error de una sola instancia.
Protección de datos frente a un fallo del centro de datos. Coloque la base de datos secundaria de Oracle en una segunda zona de disponibilidad para proporcionar una configuración de alta disponibilidad y proporcionar protección si se produce un error en una zona de disponibilidad completa. Esta configuración puede tener hasta dos milisegundos de latencia entre la base de datos principal y la secundaria, lo que puede afectar al rendimiento, los RTO y los RPO.
Protección de datos frente a un fallo regional. Para ayudar a protegerse contra una posible pérdida de datos debido a un error regional de Azure, puede colocar la base de datos secundaria en una región diferente. Esta configuración puede tener entre 30 milisegundos y 300 milisegundos de latencia entre regiones, por lo que es posible que no cumpla sus objetivos de RTO y RPO. Esta solución es la mejor para la recuperación ante desastres regional en lugar de la alta disponibilidad.

La continuidad del negocio requiere un enfoque integrado que incluya todos los componentes de una carga de trabajo. La infraestructura de red es un componente principal para cualquier carga de trabajo en Azure. Su infraestructura de red debe alinearse con su arquitectura de alta disponibilidad o recuperación ante desastres. Tenga en cuenta los siguientes factores de infraestructura de red:

Data Guard proporciona alta disponibilidad y, en la mayoría de los escenarios, proporciona suficiente compatibilidad para errores comunes. Puede colocar máquinas virtuales en una orquestación flexible de conjuntos de escalado de máquinas virtuales. Para reducir la latencia de red, todos los servicios de una única solución deben residir en la misma zona de disponibilidad y los servicios deben compartir la misma red virtual.

Para una mayor protección, puede colocar estratégicamente las máquinas virtuales en zonas de disponibilidad independientes en lugar de en una sola zona de disponibilidad. Este enfoque puede evitar el tiempo de inactividad durante un error del centro de datos.
Para obtener la máxima protección, puede colocar una base de datos secundaria en una región de Azure diferente de la región de la base de datos principal. Para aplicar actualizaciones continuas, puede usar Data Guard para implementar el emparejamiento de redes virtuales globales. Use este enfoque para aplicar actualizaciones de datos a la región secundaria de forma privada a través de la red troncal de Microsoft. Los recursos se comunican directamente sin puertas de enlace, saltos adicionales ni tránsito a través de la red pública de Internet.

Esta opción de red proporciona una conexión de alto ancho de banda y baja latencia a través de redes virtuales emparejadas en diferentes regiones. Puede usar el emparejamiento de red virtual global para conectar el sitio principal a un sitio de recuperación ante desastres en una región diferente a través de una red de alta velocidad.

Resumen de la resistencia frente a varios tipos de errores

Escenario de error	Escenario de alta disponibilidad o recuperación ante desastres de Oracle en Azure	RPO/RTO
Falla de un solo componente, como un host, un bastidor, una refrigeración, una red o una falla de alimentación	Data Guard con dos nodos en la misma orquestación flexible de Virtual Machine Scale Sets en el mismo centro de datos: - Protege contra un error de una sola instancia. - Provoca tiempo de inactividad si falla un centro de datos completo.	Si utiliza Observer para la conmutación por error de inicio rápido y el modo MAX_AVAILABILITY o MAX_PROTECTION para Data Guard: - El RPO es cero. - El RTO es menor o igual a 2 min.
Error del centro de datos	Data Guard con dos nodos en zonas de disponibilidad separadas: - Protege contra un fallo del centro de datos. - Provoca tiempo de inactividad si se produce un error en toda una región. - Requiere más configuración de conmutación por error para que los servidores de aplicaciones administren la latencia de la red.	- El RPO es menor o igual a 5 min. - El RTO es menor o igual a 5 min. Si utiliza el modo MAX_PERFORMANCE y el modo MAX_AVAILABILITY para Data Guard: - El RPO es cero. - El RTO es menor o igual a 5 min.
Error regional	Data Guard con dos nodos en regiones de Azure independientes: - Protege contra fallas regionales. - Requiere más configuración de conmutación por error para que los servidores de aplicaciones administren la latencia de la red.	Si utiliza MAX_PERFORMANCE modo para Data Guard: - El RPO es mayor o igual a 10 min. - El RTO es mayor o igual a 15 min.
Todos los escenarios: un error de un solo componente, centro de datos y región	Copias de seguridad que se envían a otra región de Azure: - Protéjase contra los fracasos regionales. - Requerir que se configure un entorno de Azure completo en la región de destino durante una conmutación por error.	- El RPO es mayor o igual a 24 h. - El RTO es mayor o igual a 4 h.

Paso siguiente

Obtenga información sobre las consideraciones de diseño para la seguridad del acelerador de zonas de aterrizaje de Oracle on Virtual Machines en un escenario a escala empresarial.

Directrices de seguridad para el acelerador de zonas de aterrizaje de Oracle en máquinas virtuales

Compartir a través de