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 (KPI) de resistencia en función de sus requisitos empresariales. Use los requisitos del objetivo de tiempo de recuperación (RTO) y del 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 funcionalidades de protección de datos de Azure NetApp Files, como la copia de seguridad de Azure NetApp Files y la replicación entre regiones.
Copias de seguridad de nivel de máquina virtual. Use Azure Backup para este método.
Precaución
Asegúrese de que las máquinas virtuales del entorno de copia de seguridad ejecutan sistemas operativos que tienen compatibilidad. Obtenga información sobre los sistemas operativos admitidos.
Al transmitir copias de seguridad de bases de datos grandes, el tiempo necesario para copiar los datos y, a continuación, 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 se debe 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 en una zona de disponibilidad para obtener protección adicional.
Tenga en cuenta 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 las consideraciones sobre el rendimiento, la replicación y los 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 su 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. Intente 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 de 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 hacer lo siguiente:
- Implemente máquinas virtuales mediante un conjunto de escalado de máquinas virtuales flexible, que distribuye automáticamente las máquinas virtuales entre dominios de error.
- Cree zonas de disponibilidad para protegerse frente a errores del centro de datos.
- Coloque 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 almacenamiento con redundancia local, almacenamiento con redundancia de zona y 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 tiene un escenario de mantenimiento planeado o 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 de 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. 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 al usar 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 el acelerador de zonas de aterrizaje de Azure Virtual Machines y los 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 problemas.
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 satisfacer 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.
Creación de 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 de Oracle críticas para la empresa, como Oracle E-Business Suite, requieren prevención de errores y, por tanto, una arquitectura holística.
Este ejemplo:
Tiene una implementación de zona de dos 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 mayor 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 rehacer depende de la configuración de rehacer.
Tiene Data Guard configurado en un modo de protección de datos, como la disponibilidad máxima, el rendimiento máximo o la protección máxima. Para obtener 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.
Creación de una conmutación por error con espera activa
En esta sección se describe un ejemplo de un escenario de conmutación por error para aplicaciones de Oracle críticas para la empresa en una implementación de dos zonas de disponibilidad con espera activa.
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 activa en espera, pero tiene funcionalidades de solo lectura.
