Optimización de la continuidad empresarial y la recuperación ante desastres

Al migrar recursos de Oracle a Azure, tenga en cuenta la confiabilidad de la base de datos y también la confiabilidad de los niveles en máquinas virtuales (VM), subredes de red virtual y componentes de almacenamiento.

Oracle en la infraestructura como servicio (IaaS) de Oracle puede cumplir los objetivos de resistencia necesarios de las cargas de trabajo de Oracle más exigentes. Para usar eficazmente las instrucciones de este artículo, defina primero los indicadores clave de rendimiento de resistencia (KPI) en función de los requisitos empresariales. Use los requisitos del objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO) como KPI de línea base para determinar la mejor arquitectura para la carga de trabajo de Oracle en Azure.

El RTO es la cantidad máxima de tiempo que una aplicación sigue sin estar disponible después de un desastre, un error o un evento comparable.

El RPO es la cantidad máxima de pérdida de datos después de un desastre, un error o un evento comparable.

Métodos de copia de seguridad para la protección de datos

Los tres métodos de copia de seguridad de base de datos de Oracle para una carga de trabajo de Oracle en IaaS de Azure incluyen:

• Copias de seguridad de streaming. Use Oracle Recovery Manager (RMAN) para este método. RMAN transmite copias de seguridad a medios de cinta secuenciales.

  Los destinos de copia de seguridad en Azure incluyen:

  • Bibliotecas de cintas virtuales que no son de Microsoft, que puede encontrar en Azure Marketplace.
  • Recursos compartidos de archivos locales y remotos, como Azure Blob Storage con el protocolo Network File System, Azure Files y Azure NetApp Files.

• Instantáneas de nivel de almacenamiento. Use Azure Backup para este método. Este método se basa en el tipo de almacenamiento que se usa para los archivos de base de datos. Por ejemplo, si usa discos administrados de Azure, como SSD Premium de Azure, Azure Backup se integra con la base de datos de Oracle. Si usa Azure NetApp Files, puede usar Azure NetApp Files funcionalidades de protección de datos, como Azure NetApp Files copia de seguridad y replicación entre regiones.

• Copias de seguridad de nivel de máquina virtual. Use Azure Backup para este método.

Al transmitir copias de seguridad de bases de datos de gran tamaño, el tiempo que se tarda en copiar los datos para restaurarlos puede superar los requisitos de RTO. Las instantáneas de nivel de almacenamiento son la mejor opción para ese escenario.

Recomendaciones

• Considere detenidamente si implementar una estrategia de copia de seguridad basada en streaming, en instantáneas de nivel de almacenamiento o en ambas estrategias.

• Evalúe el efecto de la estrategia de copia de seguridad en los requisitos de RTO y RPO.

• Analice los destinos de almacenamiento disponibles para las copias de seguridad de RMAN en función de los límites de rendimiento documentados para cada opción. Elija la opción que cumpla sus requisitos.

• Considere la posibilidad de usar Azure Backup para las instantáneas de nivel de almacenamiento y considere la posibilidad de colocar las instantáneas en una región emparejada o una zona de disponibilidad para una protección adicional.

• Considere varias opciones de almacenamiento para almacenar las copias de seguridad del registro de archivo que necesita para recuperar la base de datos. Tenga en cuenta el rendimiento, la replicación y las consideraciones de costos de cada opción.

• Desarrolle y pruebe periódicamente los planes de copia de seguridad y restauración para evitar sorpresas no deseadas en el entorno de producción.

Protección del servicio y continuidad empresarial

En esta sección se describe cómo mejorar la alta disponibilidad general (HA) y la recuperación ante desastres (DR) de la carga de trabajo de Oracle en IaaS de Azure mediante la implementación de consideraciones sobre la protección del servicio y la continuidad empresarial (BC).

Incorpore las siguientes recomendaciones para mejorar la redundancia arquitectónica y, en última instancia, maximice la cantidad de tiempo que el servicio está disponible. Apunte a minimizar el tiempo de inactividad del servicio debido a interrupciones planeadas, como revisiones, actualizaciones y actualizaciones, y interrupciones no planeadas, como errores. Use las funcionalidades de Azure y Oracle para mejorar la recuperación de errores en toda la geografía.

Azure proporciona muchas opciones para la alta disponibilidad de componentes individuales en una arquitectura de Oracle en IaaS. Por ejemplo, puede:

• Implemente máquinas virtuales en conjuntos de disponibilidad para garantizar dominios de error independientes y dominios de actualización.
• Create zonas de disponibilidad para protegerse frente a errores del centro de datos.
• Coloque las implementaciones en diferentes regiones para protegerse frente a errores de región completa.

Varias funcionalidades de almacenamiento de Azure proporcionan distintos niveles de redundancia de almacenamiento, como el almacenamiento con redundancia local, el almacenamiento con redundancia de zona y el almacenamiento con redundancia geográfica. Tenga en cuenta cada opción al planear la implementación de la carga de trabajo de Oracle en IaaS de Azure.

También puede usar Oracle Data Guard, que es una herramienta para las configuraciones de protección del servicio de base de datos de Oracle. Data Guard reenvía y aplica registros de transacciones a una o varias bases de datos en espera. Este proceso mantiene copias exactas de la base de datos principal a la que puede conmutar por error si ha planeado un mantenimiento o un escenario de error.

Data Guard tiene tres modos de replicación de datos: protección máxima, disponibilidad máxima y rendimiento máximo. Cada modo de replicación ofrece una combinación diferente de modos de transporte de registro y garantías transaccionales diferentes para la aplicación en la base de datos secundaria.

En función de la estrategia, como una estrategia de latencia cero o pérdida de datos cero, puede elegir una configuración sincrónica o asincrónica. También puede implementar la conmutación por error de inicio rápido, en función de los requisitos de tiempo de inactividad máximos. Las arquitecturas de referencia están disponibles que proporcionan una recuperación en menos de un minuto o menos de cinco minutos y hasta cuatro horas. La Enterprise Edition de Oracle Database incluye Data Guard.

Oracle GoldenGate es otra herramienta que puede usar para replicar datos entre dos bases de datos y habilitar escenarios multi-principal. Debe comprar GoldenGate por separado.

Recomendaciones

• Tenga en cuenta las funcionalidades que Azure proporciona para la alta disponibilidad de varios componentes de infraestructura en la implementación de Oracle en IaaS de Azure.

• Seleccione cuidadosamente el modo de protección de la base de datos que cumpla sus requisitos cuando use Data Guard para alta disponibilidad y recuperación ante desastres. Por ejemplo, el modo de rendimiento máximo minimiza el impacto en el origen, pero tiene el mayor potencial de pérdida de datos. Para más información, consulte BCDR para Oracle en Azure Virtual Machines acelerador de zonas de aterrizaje y modos de protección de Oracle Data Guard.

• Considere la posibilidad de automatizar el proceso de conmutación por error. Por ejemplo, puede usar la conmutación por error de inicio rápido.

• Establezca procedimientos de prueba para los procesos de conmutación por error y realice pruebas periódicas para evitar cualquier problema.

• Diseñe la solución de forma holística mediante el uso de funcionalidades nativas de Azure, como zonas de disponibilidad y herramientas nativas de Oracle, como Data Guard, para cumplir los requisitos de alta disponibilidad y recuperación ante desastres. En los dos ejemplos siguientes se usan componentes nativos de Azure y nativos de Oracle.

Create una conmutación por error con espera pasiva

En esta sección se describe un ejemplo de un escenario de conmutación por error para las aplicaciones de Oracle críticas para la empresa en una implementación de dos zonas de disponibilidad con espera pasiva.

Las aplicaciones oracle críticas para la empresa, como Oracle E-Business Suite, requieren prevención de errores y, por tanto, una arquitectura holística.

En este ejemplo:

• Tiene una implementación de dos zonas de disponibilidad. El nivel de aplicación usa Azure Site Recovery con una máquina virtual secundaria pasiva.

• Aprovecha la característica de conmutación por error de inicio rápido de Data Guard. Para obtener la máxima disponibilidad, se recomienda instalar dos observadores. El observador principal está en la zona de disponibilidad uno y el observador secundario está en la zona de disponibilidad dos. Los observadores supervisan y dirigen el tráfico. Cuando la base de datos principal no está disponible, el observador conmuta automáticamente por error a la base de datos secundaria. Data Guard realiza una sincronización de puesta al día. El período de tiempo de la sincronización de puesta al día depende de la configuración de rehacer.

• Tiene Data Guard configurado para un modo de protección de datos, como la disponibilidad máxima, el rendimiento máximo o la protección máxima. Para más información sobre cómo elegir un modo para los requisitos de carga de trabajo, consulte Modos de protección de Oracle Data Guard.

La arquitectura siguiente tiene como objetivo un umbral de tiempo de inactividad inferior a cinco minutos.

Create una conmutación por error con el modo de espera activo

En esta sección se describe un ejemplo de un escenario de conmutación por error para las aplicaciones de Oracle críticas para la empresa en una implementación de dos zonas de disponibilidad con un modo de espera activo.

En este ejemplo:

• El nivel de servidor web, el nivel de aplicación y el nivel de base de datos residen en su propia subred de red virtual.

• La base de datos principal reside en la zona de disponibilidad uno.

• La base de datos que usa Active Data Guard para replicar la base de datos principal en un modo de espera activo reside en la zona de disponibilidad tres.

Nota

Esta configuración requiere una licencia de Active Data Guard.

La arquitectura siguiente tiene como objetivo un umbral de tiempo de inactividad inferior a un minuto. Este escenario de conmutación por error tiene una configuración de espera activa, pero tiene funcionalidades de solo lectura.

Paso siguiente

Optimización de la seguridad