Obtener más información sobre el failover de inicio rápido de Oracle Data Guard

Oracle AI Database@Azure permite cargas de trabajo esenciales de Oracle AI Database en centros de datos de Azure mediante el uso de Oracle Exadata Database Service on Exascale Infrastructure y Oracle Exadata Database Service on Dedicated Infrastructure.

Obtienes alta disponibilidad, rendimiento y escalabilidad integrados de Oracle Exadata Database Machine y Oracle Real Application Clusters (Oracle RAC), con baja latencia para aplicaciones basadas en Azure.

La ampliación de la solución con una base de datos en espera en otra zona o región de disponibilidad proporciona protección de datos y recuperación ante desastres para interrupciones del centro de datos y regionales.

Data Guard transporta datos de forma síncrona a la base de datos en espera para garantizar que no se pierdan datos. El failover de inicio rápido permite al broker realizar automáticamente un failover de la base de datos en espera de destino al rol principal sin realizar pasos de failover manuales.

Los sitios de observador supervisan el entorno de failover de inicio rápido. Un observador es un componente independiente del cliente que se ejecuta en una máquina virtual informática diferente de las bases de datos primaria y en espera y supervisa la disponibilidad de la base de datos primaria.

El failover de inicio rápido proporciona un failover más rápido con un objetivo de tiempo de recuperación (RTO) configurable, sin pérdida de datos en modo síncrono o con un objetivo de punto de recuperación (RPO) enlazado en modo asíncrono.

En este manual de soluciones, aprenderá a configurar y desplegar Data Guard y a activar el failover de inicio rápido en las zonas de disponibilidad de Oracle AI Database@Azure mediante Oracle Exadata Database Service on Exascale Infrastructure. La misma solución se aplica a Oracle Exadata Database Service on Dedicated Infrastructure.

Antes de empezar

Confirme los requisitos previos y revise las referencias antes de configurar Data Guard y el failover de inicio rápido.

Antes de comenzar, debe asegurarse de que:

  • Los clusters de VM de Exascale se despliegan en diferentes zonas de disponibilidad de Azure.
  • Oracle AI Database 26ai se crea en la zona de disponibilidad principal.
  • Los rangos de CIDR de IP de red para los clusters de VM de Exascale principal y en espera no se superponen.

Revise las siguientes soluciones:

A continuación, debe aprovisionar una máquina virtual informática en Azure para alojar el observador, preferiblemente en una zona de disponibilidad diferente a la de las bases de datos principal y en espera. El observador se puede ejecutar en una máquina virtual ligera, ya que funciona como cliente de Oracle que se conecta a las bases de datos principal y en espera.

Arquitectura

Oracle AI Database se ejecuta en un cluster de VM de Exascale en la zona de disponibilidad principal. Para la protección de datos, Data Guard replica los datos en una zona de disponibilidad diferente (local en espera) en la misma región.

La siguiente arquitectura muestra un Data Guard entre zonas con el observador en ejecución en una zona de disponibilidad diferente:



cross-zones-dg-oracledb-azure-oracle.zip

Puede enrutar el tráfico de Data Guard a través de la red de Oracle Cloud Infrastructure (OCI) o Azure. Esta arquitectura dirige el tráfico de red de Data Guard a través de la red de Azure para mantener todos los datos dentro de la plataforma de Azure. Las redes virtuales en la nube del sitio de OCI se crean después de que se creen los clusters de VM de Oracle Exadata Database Service on Exascale Infrastructure en Oracle AI Database@Azure para las bases de datos principal y en espera.

En esta arquitectura:

  • El cluster de VM de Exascale principal se despliega en la zona de disponibilidad principal en VNet1 con el CIDR 10.10.0.0/16 y el CIDR de subred delegada 10.10.1.0/24.
  • El cluster de VM de Exascale en espera se despliega en la zona de disponibilidad en espera en VNet2 con el CIDR 10.20.0.0/16 y la subred delegada CIDR 10.20.1.0/24.
  • El observador se despliega en VNet3 con CIDR 10.30.0.0/16 y CIDR de subred 10.30.1.0/24.
  • VNet1 se conecta con VNet2 para permitir que el tráfico de Data Guard fluya entre las bases de datos principal y en espera.
  • VNet3 se conecta con VNet1 y VNet2 para permitir que el observador se conecte a ambas bases de datos.

Esta arquitectura tiene los siguientes componentes:

  • Región de Azure

    Una región de Azure es un área geográfica en la que residen uno o más centros de datos físicos de Azure, denominados zonas de disponibilidad. Las regiones son independientes de otras regiones y pueden haber grandes distancias que las separan (entre países o incluso continentes).

    Las regiones de Azure y OCI son áreas geográficas localizadas. Para Oracle AI Database@Azure, una región de Azure está conectada a una región de OCI, con zonas de disponibilidad (AZ) en Azure conectadas a dominios de disponibilidad (AD) en OCI. Los pares de regiones de Azure y OCI se seleccionan para minimizar la distancia y la latencia.

  • Dominio de disponibilidad de Azure

    El dominio de disponibilidad de Azure, o conjunto de disponibilidad, es una agrupación lógica de máquinas virtuales.

  • Red virtual de Azure y subred

    La red virtual de Azure (VNet) permite desplegar recursos de Azure en una red privada y aislada de forma lógica que defina. Esta red se asemeja a una red local tradicional, al tiempo que se beneficia de la infraestructura en la nube escalable y de alta disponibilidad de Azure. Después de crear una VNet, puede segmentarla en una o más subredes para organizar y controlar el tráfico de red para las cargas de trabajo.

  • Subred delegada de Azure

    Una subred delegada es una subred de VNet reservada y delegada al servicio Oracle AI Database@Azure, lo que permite a Oracle desplegar y gestionar los recursos de base de datos necesarios dentro de su espacio IP de red privada.

  • Tarjeta de interfaz de red virtual Azure (VNIC)

    Los servicios en los centros de datos de Azure tienen tarjetas de interfaz de red (NIC) físicas. Las instancias de máquina virtual se comunican mediante NIC virtuales (VNIC) asociadas con las NIC físicas. Cada instancia tiene una VNIC primaria que se crea y asocia automáticamente durante el inicio y que está disponible durante el tiempo de vida de la instancia.

  • Máquina virtual de Microsoft Azure Compute

    Las máquinas virtuales (VM) de Azure proporcionan recursos informáticos a demanda y escalables que puede utilizar, como un servidor físico o un escritorio. Utilice máquinas virtuales cuando necesite un control total sobre el sistema operativo y el entorno de software.

    Las máquinas virtuales eliminan la necesidad de gestionar el hardware físico, pero aún así se configura, aplica parches y gestiona el software que se ejecuta en ellas. Soportan cargas de trabajo personalizadas y heredadas.

  • Región OCI

    Una región de OCI es un área geográfica localizada que contiene uno o más centros, denominados dominios de disponibilidad. Las regiones son independientes de otras regiones y pueden haber grandes distancias que las separan (entre países o incluso continentes).

  • Dominio de disponibilidad

    Los dominios de disponibilidad son centros de datos independientes dentro de una región. Los recursos físicos de cada dominio de disponibilidad están aislados de los recursos de los otros dominios de disponibilidad, lo que proporciona tolerancia a fallos. Los dominios de disponibilidad no comparten infraestructura, como la alimentación o la refrigeración, ni la red interna del dominio de disponibilidad. Por lo tanto, un fallo en un dominio de disponibilidad no debería afectar a los demás dominios de disponibilidad de la región.

  • Red virtual en la nube y subred de OCI

    Una red virtual en la nube (VCN) es una red personalizable y definida por software que se configura en una región de OCI. Al igual que las Redes de los Centros de Datos Tradicionales, las Redes Virtuales le proporcionan el control sobre su entorno de red. Una VCN puede tener varios bloques de CIDR no superpuestos que puede cambiar después de crear la VCN. Puede segmentar una VCN en subredes, las cuales se pueden acotar a una región o a un dominio de disponibilidad. Cada subred está formada por un rango contiguo de direcciones que no se solapan con las demás subredes de la VCN. Puede cambiar el tamaño de una subred después de la creación. Una subred puede ser pública o privada.

  • Grupo de seguridad de red (NSG)

    Los NSG actúan como firewalls virtuales para sus recursos en la nube. Con el modelo de seguridad de confianza cero de OCI, puede controlar el tráfico de red dentro de una VCN. Un NSG está formado por un conjunto de reglas para la entrada y salida que se aplican sólo a los conjuntos especificados de tarjetas de interfaz de red virtual (VNIC) en una única VCN.

  • Oracle Data Guard

    Oracle Data Guard y Active Data Guard proporcionan un completo juego de servicios que permiten crear, mantener, gestionar y controlar una o más bases de datos en espera para que las bases de datos Oracle de producción puedan sobrevivir ante desastres y corrupciones de datos de producción. Oracle Data Guard mantiene estas bases de datos en espera como copias de la base de datos de producción mediante la replicación en memoria. Si la base de datos de producción deja de estar disponible debido a una interrupción planificada o no planificada, Oracle Data Guard puede cambiar cualquier base de datos en espera al rol de producción, lo que minimiza el tiempo de inactividad asociado a la interrupción. Oracle Active Data Guard proporciona la capacidad adicional de descargar cargas de trabajo de lectura en su mayoría en bases de datos en espera y también proporciona funciones avanzadas de protección de datos.

  • Oracle AI Database@Azure

    Oracle AI Database@Azure es el servicio de Oracle Database (Oracle Exadata Database Service on Dedicated Infrastructure y Oracle Autonomous AI Database Serverless) que se ejecuta en OCI, desplegado en los centros de datos de Microsoft Azure. El servicio ofrece funciones y paridad de precios con OCI. Adquiera el servicio en Azure Marketplace.

    Oracle AI Database@Azure integra las tecnologías de Oracle Exadata Database Service, Oracle Real Application Clusters (Oracle RAC) y Oracle Data Guard en la plataforma Azure. Los usuarios gestionan el servicio en la consola de Azure y con las herramientas de automatización de Azure. El servicio se implementa en Azure Virtual Network (VNet) e integra con el sistema de gestión de identidad y acceso de Azure. Las métricas genéricas y los logs de auditoría de OCI y Oracle AI Database están disponibles de forma nativa en Azure. El servicio requiere que los usuarios tengan una suscripción a Azure y un arrendamiento de OCI.

    Autonomous AI Database se basa en la infraestructura de Oracle Exadata, es autogestionable, autoprotegida y autorreparable, lo que ayuda a eliminar la gestión manual de bases de datos y los errores humanos. Autonomous AI Database permite el desarrollo de aplicaciones escalables basadas en IA con cualquier dato utilizando capacidades de IA integradas utilizando tu elección de modelo de lenguaje grande (LLM) y ubicación de despliegue.

    Tanto Oracle Exadata Database Service como Oracle Autonomous AI Database Serverless se aprovisionan fácilmente a través del portal nativo de Azure, lo que permite el acceso al ecosistema más amplio de Azure.

Recomendaciones

Utilice las siguientes recomendaciones como punto de partida al activar el failover de inicio rápido para Oracle Exadata Database Service on Exascale Infrastructure en Oracle AI Database@Azure.

Sus requisitos pueden diferir de la arquitectura que se describe aquí.

  • Colocar al observador en un host en un tercer sitio separado. Esto garantiza que si la ubicación principal o en espera falla por completo, el observador permanece activo para coordinar el failover o supervisar la ubicación restante.
  • En caso de que no haya un tercer sitio disponible, coloque al observador en el sitio principal.
  • Configure varios observadores en diferentes servidores para una alta disponibilidad. Si bien solo un observador puede ser el observador principal, los observadores adicionales sirven como observadores de respaldo.
  • Siga la documentación de Oracle para definir los valores de las propiedades de configuración de failover de inicio rápido, como las propiedades de failover de inicio rápido, como FastStartFailoverThreshold, FastStartFailoverLagLimit y FastStartFailoverAutoReinstate.
  • Ejecute siempre el observador del agente de Data Guard con la misma versión principal y el mismo nivel de parche (incluida la actualización de versión [RU]) que los directorios raíz de Oracle AI Database en la configuración de Data Guard. Esta combinación recibe las pruebas más exhaustivas y minimiza los riesgos operativos. También garantiza que las correcciones que afectan al código del lado del cliente (observador) y del lado del servidor (base de datos) estén en su lugar en cualquier momento. Se permite una diferencia de hasta una versión de soporte a largo plazo (LTS) importante entre el observador y la base de datos, principalmente para facilitar las actualizaciones sucesivas y minimizar el tiempo de inactividad. Por ejemplo, el observador en 26ai con la base de datos en 19c durante los procedimientos de actualización o viceversa.

Consideraciones

Al activar el failover de inicio rápido para Oracle Exadata Database Service on Exascale Infrastructure en Oracle AI Database@Azure, tenga en cuenta lo siguiente:
  • Nunca coloque el observador en la misma ubicación que la base de datos en espera. Si la ubicación en espera se apaga, la principal también se apaga porque no se puede comunicar con el observador, lo que provoca una interrupción completa
  • El observador se puede ejecutar en una máquina virtual ligera. Sin embargo, la estabilidad de la conexión de red a la base de datos primaria y en espera es fundamental para garantizar operaciones adecuadas y evitar failovers innecesarios.
  • Configure el modo de máxima disponibilidad de Data Guard para garantizar que no se pierdan datos. Si le preocupa más el rendimiento de la base de datos primaria que una pérdida mínima de datos, considere activar el failover de inicio rápido cuando el modo de protección de configuración esté definido en el máximo rendimiento.
  • El tiempo de failover depende de si la base de datos en espera de destino ha aplicado todos los datos de redo que ha recibido de la base de datos primaria. El failover de inicio rápido es más rápido cuando se toman medidas para optimizar la recuperación, de modo que la aplicación de datos de redo a la base de datos en espera se mantenga actualizada con el ratio de aplicación de redo de la base de datos primaria. Consulte la sección Performance Considerations for Fast-Start Failover en la documentación de Data Guard, Broker Concepts.

  • El tiempo de failover depende del estado de aplicación de redo en la base de datos en espera.

Acerca de los servicios y los roles necesarios

Revise los servicios y roles necesarios para crear una base de datos en espera y gestionar las redes para el failover de inicio rápido.

Esta solución requiere los siguientes servicios y roles:

  • Oracle Exadata Database Service on Exascale Infrastructure
  • Oracle Cloud Infrastructure Networking

Estos son los roles necesarios para cada servicio.

Nombre de servicio: Rol Necesario para...
Base de datos de OCI: manage database-family Crear una base de datos en espera de Data Guard
Redes de OCI: manage vcn-family Gestión del grupo de seguridad de red en OCI

Consulte Productos, soluciones y servicios de Oracle para obtener lo que necesita.