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

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). En este artículo se siguen las instrucciones y se describen 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 de alta disponibilidad y resistentes. En esta guía se describen varias opciones y procedimientos recomendados para ayudarle a diseñar alta disponibilidad y recuperación ante desastres para 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 la solución.

Introducción

Para crear una arquitectura resistente para el entorno de carga de trabajo, determine los requisitos de disponibilidad de la solución según el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO) para distintos niveles de error. El RTO es el tiempo máximo que una aplicación permanece no disponible después de que se produzca un incidente. El 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 usan principalmente Oracle Data Guard, que es una característica integrada de Oracle Database Enterprise Edition que usa la tecnología de replicación. Puede usar Data Guard para satisfacer las necesidades de alta disponibilidad y recuperación ante desastres. Data Guard ofrece tres modos de protección: rendimiento máximo, disponibilidad máxima y máxima protección. Elija el modo de protección en función del diseño de arquitectura y sus requisitos específicos de RPO y RTO.

Configuración de la carga de trabajo para alta disponibilidad

Las instancias de Azure Virtual Machines que ejecutan cargas de trabajo de Oracle se benefician de la arquitectura de Azure Virtual Machine Scale Sets, específicamente el modo de orquestación flexible. Una configuración de alta disponibilidad proporciona replicación de datos casi en tiempo real con funcionalidades de conmutación por error potencialmente rápida. Una configuración de alta disponibilidad no proporciona protección para errores de nivel de centro de datos o de nivel de región de Azure.

Elección de la opción de alta disponibilidad adecuada

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

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

Data Guard en modo de disponibilidad máximo proporciona la mayor disponibilidad con una promesa de pérdida de datos cero (RPO=0) para las operaciones normales. Para 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 Virtual Machine Scale Sets, Azure proporciona una disponibilidad del servicio del 99,95 % para un acuerdo de nivel de servicio (SLA) para instancias que se distribuyen entre dominios de error. Azure proporciona una disponibilidad del servicio del 99,99 % para las instancias que se distribuyen entre zonas de disponibilidad. Para obtener más información, consulte Alta disponibilidad para Virtual Machine Scale Sets.

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.

Uso de Data Guard en modo de protección máxima para alta disponibilidad

Si necesita una copia transaccionalmente coherente de la base de datos, plantéese usar Data Guard en modo de protección máxima. 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 SLA 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 consideraciones especiales para 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, se usan zonas de disponibilidad con fines de recuperación ante desastres, pero puede usarlas para mejorar la alta disponibilidad. Si lo hace, debe asegurarse de que la solución se pueda ejecutar con la cantidad de latencia y el 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 SLA de disponibilidad de la máquina virtual aumenta al 99,99 %.

Uso de la agrupación en clústeres de almacenamiento compartido para alta disponibilidad

Las tecnologías de agrupación en clústeres de almacenamiento compartido proporcionan atributos únicos que pueden ayudar a lograr 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 las instancias del clúster de PCS. Un clúster de PCS no duplica los 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 de PCS no es una solución certificada por Oracle. Tenga en cuenta este factor al elegir la arquitectura de alta disponibilidad.

Uso de grupos de selección de ubicación de proximidad

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

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 región de Azure o ante fallos que dificultan la funcionalidad de la aplicación en toda la región. En este escenario, debe mover toda la carga de trabajo a otro centro de datos o región.

Elija la arquitectura de recuperación ante desastres en función de los requisitos de la solución. Puede determinar sus requisitos en función del RTO y el 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 le permite ahorrar dinero.

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

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

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

Uso de Data Guard para la recuperación ante desastres

Puede usar 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 otra región en función de sus requisitos para la protección de datos. La configuración también depende de la estructura de 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 la base de datos principal.

• Al conmutar por error al sitio de recuperación ante desastres, conmuta por error toda la solución al nuevo sitio. Para evitar los desafíos de latencia, normalmente debe 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ñarlo 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 rendimiento máximo con fines de recuperación ante desastres. Si la posible pérdida de datos en el modo de rendimiento máximo es demasiado alta, puede usar el modo de disponibilidad máximo con el mecanismo Oracle Data Guard Far Sync. Sin embargo, una instancia de Far Sync desencadena licencias de Active Data Guard en los entornos principal y en espera. Para obtener más información, consulte Detalles de la licencia de Oracle.

Además, cuando envía datos a través de las regiones o centros de datos de Azure, debe pagar costes de salida para los datos (por ejemplo: 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, solo puede replicar datos parciales según sea necesario mediante la replicación basada en Golden Gate, lo que le permite ahorrar en costes 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 de Azure Linux basada en Linux.

Uso de Golden Gate para la recuperación ante desastres

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

Puede usar Golden Gate para replicar datos de una base de datos principal a otra secundaria en una configuración de recuperación ante desastres. Golden Gate es especialmente práctico si solo necesita proteger algunos de sus datos. Para evitar la replicación de datos innecesarios, use Golden Gate para replicar de forma selectiva tablas para filtrar 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 la restauración son 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 datos de una base de datos para asegurarse de que el sitio de recuperación ante desastres tiene datos actualizados.

• Asegúrese de que la Implementación está actualizada en el centro de recuperación de 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 usar 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 métodos siguientes para mantener un sitio de recuperación ante desastres:

Enfoque 1: Para evitar el esfuerzo y el coste de mantenimiento adicionales, no mantenga ninguna implementación física en el sitio de recuperación ante desastres. Puede utilizar las prácticas de infraestructura como código y e ingeniería de fiabilidad 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 coste, ya que no usa ningún recurso físico hasta el momento de la conmutación por error.

Importante

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

Enfoque 2: Implementar y mantener una versión escalada del entorno de producción. Tenga 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 la solución en el sitio de recuperación ante desastres para conseguir tiempos de conmutación por error y RTO más rápidos. Este método aumenta el coste 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.

Uso de Far Sync

Far Sync no mejora las funcionalidades de alta disponibilidad, pero puede usarlo para lograr funcionalidades de protección de pérdida de datos cero para las bases de datos de Oracle. La carga de trabajo podría requerir una pérdida de datos cero si se produce un error en la base de datos principal. Para obtener más información, consulte Arquitecturas de referencia de Oracle en Azure.

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

Además de las tecnologías descritas en 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 la solución en todas estas categorías.

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

Ancho de banda: la cantidad y el coste del ancho de banda que necesita para replicar datos en bases de datos secundarias para la alta disponibilidad y la recuperación ante desastres. Azure proporciona una infraestructura de red de alta velocidad entre zonas de disponibilidad. Al considerar la replicación en otras regiones de Azure con fines de recuperación ante desastres, tenga en cuenta la cantidad de ancho de banda que se puede lograr, así como los costes 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 esperada en un error abrupto de la base de datos principal debe cumplir los requisitos de la solución.

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

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

Cuando se usa Data Guard en modo de alta disponibilidad o alta protección, puede configurarlo para una conmutación automática por error, de modo que cuando falle el servidor principal, el secundario se ponga en marcha automáticamente. Al configurar correctamente los servidores de aplicaciones, puede asegurarse de que no tiene casi ningún tiempo de inactividad de la aplicación durante una conmutación por error.

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

Azure proporciona una disponibilidad del 99,9 % para las máquinas virtuales en 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. Al usar 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, otra zona de disponibilidad u otra región, puede optimizar la capacidad secundaria.

Con este enfoque, la base de datos secundaria se configura con la capacidad que necesita para mantenerse al día. Cuando se produce un fallo, la base de datos secundaria se redimensiona para que tenga la misma capacidad que la principal. Esta operación solo se produce si se produce un error. Por lo tanto, durante el funcionamiento normal, solo paga por una fracción del coste 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 utilizar una base de datos secundaria como destino de replicación depende de la tecnología de replicación que use. Básicamente, una carga de trabajo que se encuentra en un sistema de procesamiento de transacciones en línea (OLTP) tiene principalmente solicitudes de lectura. Por ejemplo, un 90 % de operaciones de lectura y un 10 % de escritura o un 95 % de operaciones de lectura y un 5 % de escritura son habituales en las aplicaciones OLTP. La replicación de datos replica básicamente 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 una décima parte (si tiene un ratio de lectura del 90 % y de escritura del 10 %) de la capacidad de la base de datos principal.

Automatice los procedimientos de conmutación por error para garantizar 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 simplifican el proceso de un extremo a otro.

Configuración de la topología de red para la protección del servicio y la protección de datos

Para lograr una alta disponibilidad y recuperación ante desastres, necesita tomar decisiones financieras y empresariales que equilibren el tiempo de recuperación, o RTO, y la posible pérdida de datos, o RPO, frente a las otras licencias de Oracle, el mantenimiento de máquinas virtuales y los costes de transferencia de datos. Al hospedar una carga de trabajo en una sola máquina virtual de Azure, obtendrá protección básica para errores de hardware comunes a un bajo coste. Pero es probable que un error en una sola máquina virtual produzca tiempo de inactividad y pérdida de datos. Por lo tanto, en los entornos de producción, incluya al menos una base de datos secundaria de Oracle hospedada en una máquina virtual independiente con Data Guard. En función de los requisitos, use 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 de Oracle secundaria en una máquina virtual independiente dentro de la misma orquestación flexible de Virtual Machine Scale Sets 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 instancia única.

• Protección de datos frente a un error del centro de datos. Coloque la base de datos de Oracle secundaria en una segunda zona de disponibilidad para proporcionar una configuración de alta disponibilidad y proporcionar protección si se produce un error en toda una zona de disponibilidad. Esta configuración puede tener hasta dos milisegundos de latencia entre la base de datos principal y secundaria, lo que puede afectar al rendimiento, los RTO y los RPO.

• Protección de datos frente a un error regional. Para ayudar a protegerse frente a la posible pérdida de datos debido a un error regional de Azure, puede colocar la base de datos secundaria en otra región. Esta configuración puede tener entre 30 milisegundos y 300 milisegundos de latencia entre regiones, por lo que es posible que no cumpla los objetivos de RTO y RPO. Esta solución es la mejor para la recuperación ante desastres regional en lugar de alta disponibilidad.

La continuidad empresarial 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. La infraestructura de red debe alinearse con la 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 compatibilidad suficiente con errores comunes. Puede colocar máquinas virtuales en una orquestación flexible de Virtual Machine Scale Sets. Para reducir la latencia de red, todos los servicios de una sola solución deben residir dentro de la misma zona de disponibilidad y los servicios deben compartir la misma red virtual.

  Para mayor protección, coloque las máquinas virtuales estratégicamente 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 base de datos principal. Para aplicar actualizaciones continuas, puede usar Data Guard para implementar el emparejamiento de red virtual global. 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 o tránsito a través de la red pública de Internet.

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

Resumen de la resistencia frente a diferentes tipos de errores

Escenario de error	Escenario de alta disponibilidad o recuperación ante desastres de Oracle en Azure	RPO/RTO
Error de componente único, como host, bastidor, refrigeración, redes o 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 instancia única. - Provoca tiempo de inactividad si se produce un error en todo el centro de datos.	Si usa 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 que 2 min.
Error del centro de datos	Data Guard con dos nodos en zonas de disponibilidad independientes: - Protege frente a errores 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 red.	- El RPO es menor o igual que 5 min. - El RTO es menor o igual que 5 min. Si usa el modo MAX_PERFORMANCE y el modo de MAX_AVAILABILITY para Data Guard: - El RPO es cero. - El RTO es menor o igual que 5 min.
Error regional	Data Guard con dos nodos en regiones de Azure independientes: - Protege contra errores regionales. - Requiere más configuración de conmutación por error para que los servidores de aplicaciones administren la latencia de red.	Si usa el modo MAX_PERFORMANCE para Data Guard: - El RPO es mayor o igual a 10 min. - El RTO es mayor o igual a 15 min.
Todos los escenarios: error en un único componente, centro de datos y región	Copias de seguridad que se envían a otra región de Azure: - Protege contra errores de región. - Requiere que todo el entorno de Azure se configure en la región de destino durante la conmutación por error.	- El RPO es mayor o igual a 25 horas. - El RTO es mayor o igual a 4 horas.

Paso siguiente

Obtenga información sobre las consideraciones de diseño para la seguridad del acelerador de zonas de aterrizaje de máquinas virtuales de Oracle en un escenario de escala empresarial.

Guías de seguridad para el acelerador de zonas de aterrizaje de Oracle en Virtual Machines.