Implementación de la recuperación ante desastres entre regiones para Oracle Exadata Database Service en Oracle Database@Azure
Al diseñar aplicaciones, es esencial garantizar la continuidad del negocio mediante el establecimiento de un sólido mecanismo de recuperación ante desastres para restaurar las operaciones en caso de interrupción.
Durante muchos años, los clientes han confiado en Oracle Exadata Database Service mediante Oracle Maximum Availability Architecture (MAA) para impulsar aplicaciones esenciales tanto locales como en Oracle Cloud Infrastructure (OCI). Oracle Exadata Database Service en Oracle Database@Azure ofrece una paridad de funciones y precios con Exadata en OCI y se puede desplegar en varias zonas de disponibilidad (AZ) y regiones de Microsoft Azure para garantizar una alta disponibilidad y recuperación ante desastres.
Arquitectura
Esta arquitectura muestra una aplicación de Azure Kubernetes Service (AKS) en contenedores de alta disponibilidad con Oracle Exadata Database Service en Oracle Database@Azure en una topología de recuperación ante desastres entre regiones.
Se despliega una aplicación de servicio de Azure Kubernetes (AKS) en contenedores de alta disponibilidad en dos regiones de Azure: una región principal y una región en espera. Las imágenes de contenedor se almacenan en el registro de contenedores de Azure y se replican entre las regiones principal y en espera. Los usuarios acceden a la aplicación externamente a través de un equilibrador de carga público.
Para la protección de datos, Oracle Database se está ejecutando en un cluster de máquina virtual (VM) de Exadata en la región principal, con Oracle Data Guard u Oracle Active Data Guard replicando los datos en la base de datos en espera que se ejecuta en un cluster de VM de Exadata en la región en espera.
Las claves de cifrado de datos transparente (TDE) de la base de datos se almacenan en Oracle Cloud Infrastructure Vault y se replican entre las regiones de Azure y OCI. Las copias de seguridad automáticas están en OCI para las regiones principal y en espera. Los clientes pueden utilizar Oracle Cloud Infrastructure Object Storage u Oracle Database Autonomous Recovery Service como solución de almacenamiento preferida.
La red de Oracle Exadata Database Service en Oracle Database@Azure está conectada a la subred de cliente de Exadata mediante un gateway de enrutamiento dinámico (DRG) gestionado por Oracle. También es necesario un DRG para crear una conexión de peer entre VCN en diferentes regiones. Puesto que solo se permite un DRG por VCN en OCI, se necesita una segunda VCN con su propio DRG para conectar las VCN principal y en espera de cada región. En este ejemplo:
- El cluster de VM de Exadata principal se despliega en la subred de cliente de VCN principal de VCN (10.5.0.0/24).
- La VCN primaria de VCN del hub para la red de tránsito es 10.15.0.0/29.
- El cluster de VM de Exadata en espera se despliega en la subred de cliente de VCN de VCN en espera (10.6.0.0/24).
- La VCN de VCN de hub en espera para la red de tránsito es 10.16.0.0/29.
No se necesita ninguna subred para que las VCN del hub activen el enrutamiento en tránsito; por lo tanto, estas VCN pueden utilizar una red muy pequeña. Las redes virtuales en la ubicación secundaria de OCI se crean después de que se hayan creado los clusters de VM de Oracle Exadata Database Service en Oracle Database@Azure para las bases de datos principal y en espera.
En el siguiente diagrama se ilustra la arquitectura:
Microsoft Azure proporciona los siguientes componentes:
- Región de Microsoft 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 grandes distancias pueden separarlos (entre países e incluso continentes).
Las regiones de Azure y OCI son áreas geográficas localizadas. Para Oracle 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.
- Zona de disponibilidad de Microsoft Azure
Una zona de disponibilidad es un centro de datos físicamente separado dentro de una región diseñada para ofrecer alta disponibilidad y tolerar fallos. Las zonas de disponibilidad están lo suficientemente cerca como para tener conexiones de baja latencia a otras zonas de disponibilidad.
- Netwok virtual de Microsoft Azure
La red virtual de Microsoft Azure (VNet) es el componente fundamental de una red privada en Azure. VNet permite que muchos tipos de recursos de Azure, como las máquinas virtuales (VM) de Azure, se comuniquen de forma segura entre sí, Internet y con redes locales.
- Subred delegada de Microsoft Azure
La delegación de subred le permite inyectar un servicio gestionado, específicamente un servicio de plataforma como servicio (PaaS), directamente en la red virtual. Una subred delegada puede ser un directorio raíz de un servicio gestionado externamente dentro de la red virtual para que el servicio externo actúe como recurso de red virtual, aunque sea un servicio PaaS externo.
- VNIC de Microsoft Azure
Los servicios de los centros de datos de Azure tienen tarjetas de interfaz de red (NIC) física. Las instancias de máquina virtual se comunican mediante NIC virtuales (VNIC) asociadas con las NIC físicas. Cada instancia tiene una VNIC principal que se crea y se asocia automáticamente durante el inicio y que está disponible durante toda la vida de la instancia.
- Tabla de rutas de Microsoft Azure
Las tablas de rutas virtuales contienen reglas para enrutar el tráfico de subredes a destinos fuera de VNet, normalmente a través de gateways. Las tablas de rutas se asocian a subredes en VNet.
- Gateway de red virtual de Azure
El servicio de gateway de red virtual de Azure establece una conectividad segura y entre entornos locales entre una red virtual de Azure y una red local. Te permite crear una red híbrida que abarque tu centro de datos y Azure.
Oracle Cloud Infrastructure proporciona los siguientes componentes:
- Región
Una región de Oracle Cloud Infrastructure es un área geográfica localizada que contiene uno o más centros de datos, que alojan dominios de disponibilidad. Las regiones son independientes entre sí y pueden separarse grandes distancias (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 tanto, un fallo en un dominio de disponibilidad no debería afectar a los otros dominios de disponibilidad de la región.
- Subredes y red virtual en la nube (VCN)
Una VCN es una red personalizable y definida por software que se configura en una región de Oracle Cloud Infrastructure. Al igual que las redes de los centros de datos tradicionales, las redes virtuales le proporcionan el control de 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.
- Tabla de rutas
Las tablas de rutas virtuales contienen reglas para enrutar el tráfico de subredes a destinos fuera de una VCN, normalmente a través de gateways.
- Lista de seguridad
Para cada subred, puede crear reglas de seguridad que especifiquen el origen, el destino y el tipo de tráfico que se permite dentro y fuera de la subred.
- Gateway de enrutamiento dinámico (DRG)
El DRG es un enrutador virtual que proporciona una ruta de acceso para el tráfico de red privada entre las VCN de la misma región, entre una VCN y una red fuera de la región, como una VCN de otra región de Oracle Cloud Infrastructure, una red local o una red de otro proveedor de nube.
- Gateway de servicio
Un gateway de servicios proporciona acceso desde una VCN a otros servicios, como Oracle Cloud Infrastructure Object Storage. El tráfico desde la VCN al servicio Oracle recorre el tejido de red de Oracle y no atraviesa Internet.
- Intercambio de tráfico local
El intercambio de tráfico local permite intercambiar tráfico entre una VCN y otra VCN de la misma región. El intercambio de tráfico significa que las redes virtuales en la nube se comunican mediante direcciones IP privadas, sin que el tráfico recorra Internet ni se enrute a través de su red local.
- 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 Oracle Cloud Infrastructure, puede controlar el tráfico de red dentro de una VCN. Un NSG consta de un juego de reglas de seguridad de entrada y salida que se aplican solo a un juego especificado de VNIC en una única VCN.
- Object Storage
OCI Object Storage proporciona acceso a grandes cantidades de datos estructurados y no estructurados de cualquier tipo de contenido, incluidas copias de seguridad de base de datos, datos analíticos y contenido enriquecido, como imágenes y vídeos. Puede almacenar datos de forma segura directamente desde Internet o desde la plataforma en la nube. Puede ampliar el almacenamiento sin experimentar ninguna degradación del rendimiento ni de la fiabilidad del servicio.
Utilice el almacenamiento estándar para el almacenamiento al que debe acceder de forma rápida, inmediata y frecuente. Utilice el almacenamiento de archivo para el almacenamiento "frío" al que conserva durante largos períodos de tiempo y al que rara vez accede.
- Data Guard
Oracle Data Guard y Oracle Active Data Guard proporcionan un juego completo de servicios que crean, mantienen, gestionan y supervisan una o más bases de datos en espera y que permiten que las bases de datos Oracle de producción permanezcan disponibles sin interrupció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, minimizando el tiempo de inactividad asociado a la interrupción. Oracle Active Data Guard proporciona la capacidad adicional de descargar cargas de trabajo de lectura principalmente en bases de datos en espera y también proporciona funciones avanzadas de protección de datos.
- Oracle Database Autonomous Recovery Service
Oracle Database Autonomous Recovery Service es un servicio de Oracle Cloud que protege las bases de datos de Oracle. La automatización de copias de seguridad y las capacidades mejoradas de protección de datos para bases de datos OCI le permiten descargar todos los requisitos de procesamiento y almacenamiento de copias de seguridad en Oracle Database Autonomous Recovery Service, lo que reduce los costos de infraestructura de copia de seguridad y la sobrecarga de administración manual.
- Exadata - Servicio de base de datos
Oracle Exadata es una plataforma de base de datos empresarial que ejecuta cargas de trabajo de Oracle Database de cualquier escala y criticidad con alto rendimiento, disponibilidad y seguridad. El diseño de escala horizontal de Exadata emplea optimizaciones únicas que permiten que el procesamiento de transacciones, los análisis, el aprendizaje automático y las cargas de trabajo mixtas se ejecuten de forma más rápida y eficiente. La consolidación de diversas cargas de trabajo de Oracle Database en plataformas de Exadata en centros de datos empresariales, en Oracle Cloud Infrastructure (OCI) y en entornos multinube ayuda a las organizaciones a aumentar la eficiencia operativa, reducir la administración de TI y reducir los costos.
le permite aprovechar la potencia de Exadata en la nube. Oracle Exadata Database Service ofrece capacidades probadas de Oracle Database en una infraestructura de Oracle Exadata optimizada y específica en la nube pública. La automatización incorporada en la nube, la ampliación flexible de recursos, la seguridad y el rendimiento rápido para todas las cargas de trabajo de Oracle Database le ayudan a simplificar la gestión y reducir los costos.
- Oracle Database@Azure
Oracle Database@Azure es el servicio de Oracle Database (Oracle Exadata Database Service on Dedicated Infrastructure y Oracle Autonomous Database Serverless) que se ejecuta en Oracle Cloud Infrastructure (OCI), desplegado en centros de datos de Microsoft Azure. El servicio ofrece funciones y paridad de precios con OCI. Adquiera el servicio en Azure Marketplace.
Oracle Database@Azure integra 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 despliega en Azure Virtual Network (VNet) e integrado con el sistema de gestión de identidad y acceso de Azure. Las métricas genéricas de OCI y Oracle Database y los logs de auditoría 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 Database se basa en la infraestructura de Oracle Exadata, es autogestionada, autoprotegida y autorreparable, lo que ayuda a eliminar la gestión manual de bases de datos y los errores humanos. Autonomous Database permite el desarrollo de aplicaciones escalables basadas en IA con cualquier dato mediante capacidades de IA integradas utilizando su elección de modelo de lenguaje grande (LLM) y ubicación de despliegue.
Tanto Oracle Exadata Database Service como Oracle Autonomous 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
- Despliegue la infraestructura de Exadata necesaria en las regiones principal y en espera. Para cada instancia de Exadata, despliegue un cluster de VM de Exadata en la subred delegada de una red virtual de Microsoft Azure (VNet). La base de datos Oracle Real Application Clusters (RAC) se puede instanciar en el cluster. En el mismo VNet, despliegue el servicio de Azure Kubernetes (AKS) en una subred independiente. Configure Oracle Data Guard para replicar datos de una instancia de Oracle Database a la otra, entre regiones.
- Cuando se crean clusters de VM de Exadata en el sitio secundario de Oracle Database@Azure, cada uno se crea dentro de su propia red virtual en la nube (VCN) de Oracle Cloud Infrastructure. Oracle Data Guard necesita que las bases de datos se comuniquen entre sí para enviar datos de redo. Las redes virtuales en la nube deben estar conectadas para activar esta comunicación.
Consideraciones
Al realizar una recuperación ante desastres entre regiones para Oracle Exadata Database Service en Oracle Database@Azure, tenga en cuenta lo siguiente.
- La preparación para un escenario de desastre requiere un enfoque integral que considere diferentes requisitos de negocio y arquitecturas de disponibilidad y que abarque esas consideraciones en un plan accionable, de alta disponibilidad (HA), de recuperación de desastres (DR). El escenario que se describe aquí proporciona directrices para ayudar a seleccionar el enfoque que mejor se adapte al despliegue de la aplicación mediante un failover simple pero eficaz para la configuración de recuperación ante desastres en los entornos de Oracle Cloud Infrastructure (OCI) y Microsoft Azure.
- Utilice Oracle Data Guard entre regiones para las bases de datos aprovisionadas en el cluster de VM de Exadata en Oracle Database@Azure mediante una red gestionada por OCI.
- Oracle Cloud Infrastructure es la red preferida para lograr un mejor rendimiento, medido por latencia y rendimiento, y para lograr costos reducidos, ya que los primeros 10 TB/mes son gratuitos.
Despliegue
Para configurar la comunicación de red entre regiones que se muestra en el diagrama de arquitectura anterior, complete los siguientes pasos generales.
Región Primaria
- Cree una red virtual en la nube (VCN), VCN principal de HUB, en la región principal de Oracle Cloud Infrastructure (OCI).
- Despliegue dos gateways de intercambio de tráfico local (LPG), Primary-LPG y HUB-Primary-LPG, en VCN principal y HUB VCN principal, respectivamente.
- Establezca una conexión LPG de peer entre los LPG para VCN principal de HUB y VCN principal.
- Cree un gateway de enrutamiento dinámico (DRG), DRG principal en la VCN principal de Hub.
- En la VCN primaria de VCN de HUB, cree la tabla de rutas, primary_hub_transit_drg, y asigne el destino de la subred de cliente principal de VCN, un tipo de destino de LPG y el destino HUB-Primary-LPG. Por ejemplo:
10.5.0.0/24 target type: LPG, Target: Hub-Primary-LPG - En la VCN principal de HUB VCN, cree una segunda tabla de rutas, primary_hub_transit_lpg, y asigne el destino de la subred de cliente de VCN en espera, un tipo de destino DRG y un DRG principal de destino. Por ejemplo:
10.6.0.0/24 target type: DRG, Target: Primary-DRG - Desde la VCN principal de VCN de hub, asocie la principal de VCN de hub al DRG. Edite las asociaciones de VCN de DRG y, en opciones avanzadas, edite la tabla de rutas de VCN del separador para asociarla a la tabla de rutas primary_hub_transit_drg. Esta configuración permite el enrutamiento en tránsito.
- En la VCN principal de Hub VCN, asocie la tabla de rutas primary_hub_transit_lpg al gateway Hub-Primary-LPG.
- En la tabla de rutas por defecto VCN principal de hub, agregue una regla de ruta para el rango de direcciones IP de subred de cliente principal de VCN para utilizar el LPG. Agregue otra regla de ruta para el rango de direcciones IP de subred de cliente de VCN en espera para utilizar el DRG. Por ejemplo:
10.5.0.0/24 LPG Hub-Primary-LPG 10.6.0.0/24 DRG Primary-DRG - En DRG principal, seleccione la tabla de rutas de DRG, Tabla de rutas de DRG generada automáticamente para asociaciones de RPC, VC y IPSec. Agregue una ruta estática al rango de direcciones IP de cliente de subred Principal de VCN que utilice la VCN principal de Hub con un tipo de asociación de siguiente salto de VCN y el nombre de asociación de siguiente salto Asociación de hub principal. Por ejemplo:
10.5.0.0/24 VCN Primary Hub attachment - Utilice el menú de asociaciones de conexión con intercambio de tráfico remoto de DRG principal para crear una conexión con intercambio de tráfico remoto, RPC.
- En la subred de cliente primaria de VCN, actualice el grupo de seguridad de red (NSG) para crear una regla de seguridad que permita la entrada para el puerto TCP 1521. Opcionalmente, puede agregar el puerto SSH 22 para el acceso SSH directo a los servidores de base de datos.
Note:
Para obtener una configuración más precisa, desactive la distribución de rutas de importación de la tabla de rutas de DRG generado automáticamente para asociaciones RPC, VC y IPSec. Para Tabla de rutas de DRG generada automáticamente para asociaciones de VCN, cree y asigne una nueva distribución de rutas de importación que incluya solo la asociación de RPC necesaria.
Región en espera
- Cree la VCN, Base de datos en espera de VCN de HUB, en la región en espera de OCI.
- Despliegue dos LPG, Standby-LPG y HUB-Standby-LPG, en las VCN en espera y las VCN de base de datos en espera de VCN de HUB respectivamente.
- Establezca una conexión LPG de peer entre LPG para la base de datos en espera de VCN y la base de datos en espera de VCN de HUB.
- Cree un DRG, Standby-DRG en la VCN de VCN en espera de hub.
- En la VCN en espera de VCN de HUB, cree una tabla de rutas, standby_hub_transit_drg, y asigne el destino de la subred del cliente de VCN en espera, un tipo de destino de LPG y un HUB-Standby-LPG de destino. Por ejemplo:
10.6.0.0/24 target type: LPG, Target: Hub-Standby-LPG - En la VCN en espera de VCN de HUB, cree una segunda tabla de rutas, standby_hub_transit_lpg, y asigne el destino de la subred de cliente VCN principal, un DRG de tipo de destino y un DRG en espera de destino. Por ejemplo:
10.5.0.0/24 target type: DRG, Target: Standby-DRG - Desde la VCN en espera de la VCN de HUB, asocie la VCN en espera de la VCN de HUB al DRG. Edite las asociaciones de VCN de DRG y, en opciones avanzadas, edite la tabla de rutas de VCN para asociarla a la tabla de rutas standby_hub_transit_drg. Esta configuración permite el enrutamiento en tránsito.
- En la VCN en espera de VCN de HUB, en la tabla de rutas por defecto Base de datos en espera de VCN de HUB, agregue reglas de ruta para el rango de direcciones IP de subred de cliente de base de datos en espera de VCN para utilizar el LPG y para el rango de direcciones IP de subred de cliente de VCN principal para utilizar el DRG. Por ejemplo:
10.6.0.0/24 LPG Hub-Standby-LPG 10.5.0.0/24 DRG Standby-DRG - Asocie la tabla de rutas, standby_hub_transit_lpg, al gateway Hub-Standby-LPG.
- En DRG en espera, seleccione la tabla de rutas de DRG Tabla de rutas de Drg generado automáticamente para asociaciones de RPC, VC y IPSec. Agregue una ruta estática al rango de direcciones IP del cliente de subred en espera de VCN que utilice la VCN en espera de VCN de hub con un tipo de asociación de siguiente salto de VCN y el nombre de asociación de siguiente salto asociación de hub en espera. Por ejemplo:
10.6.0.0/24 VCN Standby Hub attachment - Utilice el menú de asociaciones de conexión con intercambio de tráfico remoto de Standby-DRG para crear una conexión con intercambio de tráfico remoto, RPC.
- Seleccione la conexión de intercambio de tráfico remoto, seleccione Establecer conexión y proporcione el OCID de DRG principal. El estado del intercambio de tráfico pasa a ser interconectado. Ambas regiones están conectadas.
- En la subred de cliente de VCN en espera, actualice el NSG para crear una regla de seguridad que permita la entrada para el puerto TCP 1521. Opcionalmente, puede agregar el puerto SSH 22 para el acceso SSH directo a los servidores de base de datos.
Asociación de Data Guard
- Para activar Oracle Data Guard u Oracle Active Data Guard para Oracle Database, en la página de detalles de Oracle Database, haga clic en Asociaciones de Data Guard y, a continuación, haga clic en Activar Data Guard.
- En la página Enable Data Guard:
- Seleccione la región en espera.
- Seleccione el dominio de disponibilidad en espera asignado a Azure AZ.
- Seleccione la infraestructura de Exadata en espera.
- Seleccione el cluster de VM en espera deseado.
- Seleccione Oracle Data Guard u Oracle Active Data Guard. MAA recomienda Oracle Active Data Guard para la reparación automática de bloques de corrupciones de datos y la capacidad de descargar informes.
- Para asociaciones de Oracle Data Guard entre regiones, solo está soportado el modo de protección de máximo rendimiento.
- Seleccione un directorio raíz de base de datos existente o cree uno. Se recomienda utilizar la misma imagen de software de base de datos de la base de datos primaria para el directorio raíz de la base de datos en espera, de modo que ambos tengan los mismos parches disponibles.
- Introduzca la contraseña del usuario SYS y active Oracle Data Guard.
Después de activar Oracle Data Guard, la base de datos en espera se mostrará en la sección Asociaciones de Data Guard.
- (Opcional) Active el failover automático (failover de inicio rápido) para reducir el tiempo de recuperación en caso de fallos instalando Data Guard Observer en una máquina virtual independiente, preferiblemente en una ubicación independiente o en la red de la aplicación.
Explorar más
Obtenga más información sobre las funciones de esta arquitectura y sobre las arquitecturas relacionadas.