Implemente la recuperación ante desastres con la base de datos en espera de varias regiones en Oracle Database@Azure

Garantizar una continuidad empresarial ininterrumpida es fundamental para el éxito a la hora de diseñar aplicaciones. Para lograrlo, se requiere una estrategia sólida de recuperación ante desastres diseñada para restaurar rápidamente la funcionalidad en caso de interrupciones.

Durante años, las organizaciones han confiado en Oracle Exadata Database Service, que es la principal tecnología de recuperación ante desastres de Oracle para admitir aplicaciones esenciales, ya sea en entornos locales o dentro de Oracle Cloud Infrastructure (OCI). Oracle Exadata Database Service on Dedicated Infrastructure en Oracle Database@Azure ofrece el mismo rendimiento, juego de funciones y paridad de precios líderes en la industria que Exadata en OCI. Aprovecha las zonas y regiones de disponibilidad (AZ) de Microsoft Azure para proporcionar baja latencia a las aplicaciones de Azure, además de capacidades de alta disponibilidad y recuperación ante desastres sin igual, lo que garantiza operaciones fluidas durante el mantenimiento y en caso de interrupción.

Arquitectura

Esta arquitectura muestra Oracle Exadata Database Service on Dedicated Infrastructure en Oracle Database@Azure en una topología de recuperación ante desastres de varias regiones mediante dos bases de datos en espera remotas.

El siguiente diagrama ilustra esta arquitectura de referencia.

Descripción de la ilustración multi-region-standby-dr-db-azure-arch.png

multi-region-standby-dr-db-azure-arch-oracle.zip

Oracle Database se ejecuta en un cluster de máquina virtual (VM) de Exadata en la región principal. Para la protección de datos y la recuperación ante desastres, Oracle Active Data Guard replica los datos en dos bases de datos en espera que se ejecutan en clusters de VM de Exadata en dos regiones en espera diferentes. La configuración de una base de datos en espera remota garantiza la protección de los datos frente a fallos regionales y también se puede utilizar para descargar el procesamiento de consultas de solo lectura. Replicación de la aplicación entre regiones para evitar una mayor latencia después del switchover a una base de datos en espera.

Puede enrutar el tráfico de Active Data Guard a través de la red de Azure. Sin embargo, esta arquitectura se centra en el tráfico de red de Active Data Guard a través de la red OCI para optimizar el rendimiento y la latencia de la red.

La red de Oracle Exadata Database Service on Dedicated Infrastructure en Oracle Database@Azure está conectada a la subred de cliente de Exadata mediante un gateway de direccionamiento dinámico (DRG) gestionado por Oracle. También se necesita un DRG para crear una conexión peer entre redes virtuales en la nube (VCNs) en diferentes regiones. Puesto que solo se permite un DRG por VCN en OCI, se necesita una segunda VCN que actúe como una VCN de hub con su propio DRG para conectar las VCN principal y en espera de cada región. En esta arquitectura:

• El cluster de VM de Exadata principal se despliega en Region 1 en VCN1 con CIDR 10.10.0.0/16.
• La VCN de hub en la Region 1 principal es HubVCN1 con CIDR 10.11.0.0/16.
• El primer cluster de VM de Exadata en espera se despliega en Region 2 en VCN2 con CIDR 10.20.0.0/16.
• La VCN de hub de la primera región en espera es HubVCN2 con CIDR 10.22.0.0/16.
• El segundo cluster de VM de Exadata en espera se despliega en Region 3 en VCN3 con CIDR 10.30.0.0/16.
• La VCN de hub de la segunda región en espera es HubVCN3 con CIDR 10.33.0.0/16.

No se necesita ninguna subred para que las VCN del hub activen el enrutamiento en tránsito; por lo tanto, estas VCN pueden usar rangos de CIDR de IP muy pequeños. Las VCN del sitio secundario de OCI se crean después de crear los clusters de VM de Oracle Exadata Database Service on Dedicated Infrastructure en Oracle Database@Azure para las bases de datos principal y en espera.

Microsoft Azure proporciona 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 entre sí y pueden separarse grandes distancias (entre países o 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. Se seleccionan los pares de regiones de Azure y OCI para minimizar la distancia y la latencia.

• Zona de disponibilidad de Azure

  Las zonas de disponibilidad de Azure son ubicaciones físicamente separadas dentro de una región de Azure, diseñadas para garantizar una alta disponibilidad y resiliencia al proporcionar energía, refrigeración y redes independientes.

• Red virtual de Azure (VNet)

  Azure Virtual Network (VNet) es el componente fundamental de su red privada en Azure. VNet permite que muchos tipos de recursos de Azure, como máquinas virtuales (VM) de Azure, se comuniquen de forma segura entre sí, Internet y redes locales.

• Subred delegada de Azure

  Una subred delegada permite insertar un servicio gestionado, específicamente un servicio de plataforma como servicio (PaaS), directamente en la red virtual como recurso. Tiene una gestión de integración completa de los servicios PaaS externos en sus redes virtuales.

• Tarjeta de interfaz de red virtual (VNIC) de Azure

  Los servicios de 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 ciclo de vida de la instancia.

OCI 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).

• Dominios 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 demás dominios de disponibilidad de la región.

• Red y subredes virtuales en la nube (VCN)

  Una VCN es una red personalizable 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.

• 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.

• Gateway de enrutamiento dinámico (DRG)

  El DRG es un enrutador virtual que proporciona una ruta para el tráfico de red privada entre las redes virtuales en la misma región, entre una VCN y una red fuera de la región, como una VCN en otra región de Oracle Cloud Infrastructure, una red local o una red en otro proveedor en la nube.

• Almacenamiento de objetos

  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 Database Service on Dedicated Infrastructure

  Oracle Exadata Database Service on Dedicated Infrastructure 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

Utilice las siguientes recomendaciones como punto de partida al realizar la recuperación ante desastres para Oracle Exadata Database Service on Dedicated Infrastructure en Oracle Database@Azure. Sus requisitos pueden diferir de la arquitectura descrita aquí.

• Utilice Active Data Guard para la prevención completa de daños en los datos con reparación automática de bloques, actualizaciones y migraciones en línea, y descargue la carga de trabajo en espera con escalabilidad horizontal de lectura.
• Active la continuidad de aplicaciones para enmascarar las interrupciones de la base de datos durante los eventos planificados y no planificados de los usuarios finales y garantizar aplicaciones ininterrumpidas.
• Configure la copia de seguridad automática en Oracle Database Autonomous Recovery Service (en Azure u OCI) aunque los datos estén protegidos por Oracle Data Guard para minimizar la carga de trabajo de copia de seguridad en la base de datos mediante la implantación de la estrategia de copia de seguridad incremental permanente que elimina las copias de seguridad completas semanales. Como alternativa, los clientes pueden utilizar OCI Object Storage para copias de seguridad automáticas.
• Active las copias de seguridad de la base de datos en espera para lograr la replicación de copias de seguridad entre regiones.
• Utilice OCI Full Stack DR para orquestar operaciones de switchover y failover de base de datos.
• Utilice OCI Vault para almacenar las claves de Transparent Data Encryption (TDE) de la base de datos mediante claves gestionadas por el cliente.

Consideraciones

Al realizar una recuperación ante desastres multirregional para Oracle Exadata Database Service on Dedicated Infrastructure en Oracle Database@Azure, tenga en cuenta lo siguiente.

• Cuando se crean clusters de VM de Exadata en el sitio secundario de Oracle Database@Azure, cada cluster de VM se crea dentro de su propia VCN de OCI. Oracle Data Guard necesita que las bases de datos se comuniquen entre sí para enviar datos redo. Conecte las VCN para activar esta comunicación. Por lo tanto, las redes virtuales en la nube del cluster de VM de Exadata no deben compartir rangos de CIDR de IP superpuestos.
• La preparación para un escenario de desastre requiere un enfoque integral que tenga en cuenta los diferentes requisitos de negocio y arquitecturas de disponibilidad y que abarque esas consideraciones en un plan procesable, de alta disponibilidad y de recuperación ante desastres. El escenario descrito 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 OCI y Microsoft Azure.
• OCI es la red preferida para lograr un mejor rendimiento, medido por la latencia y el rendimiento, y para lograr un costo reducido, incluida la primera salida de 10 TB/mes de forma gratuita.
• Puede crear hasta seis bases de datos en espera para una base de datos primaria a través de Cloud Tooling.
• La creación de una base de datos en espera asociada a otra base de datos en espera (en cascada en espera) no está soportada mediante las herramientas en la nube.

Despliegue

Siga estos pasos para configurar la comunicación de red entre regiones que se muestran en el diagrama de arquitectura:

Siga estos pasos para configurar la región Principal:

1. Agregue las siguientes reglas de entrada a la lista de seguridad de la subred de cliente de VCN1 para permitir el tráfico entrante de VCN2 y VCN3.

   Sin Estado	Origen	Protocolo IP	Rango de puertos de origen	Rango de puertos de destino	Permite	Descripción
   N.º	10.20.0.0/16	TCP	1521	1521	Tráfico TCP para puertos: 1521	Permitir entrada desde VCN2
   N.º	10.30.0.0/16	TCP	1521	1521	Tráfico TCP para puertos: 1521	Permitir entrada desde VCN3

2. Cree la red virtual en la nube HubVCN1 con CIDR 10.11.0.0/16.
3. Cree el gateway de intercambio de tráfico local HubLPG1 en la red virtual en la nube HubVCN1.
4. Cree el gateway de intercambio de tráfico local LPG1R en la red virtual en la nube VCN1.
5. Establezca la conexión de intercambio de tráfico local entre LPG1R y HubLPG1.
6. Agregue reglas de ruta a la tabla de rutas de la subred de cliente de VCN1 para reenviar el tráfico de destino para VCN2 y VCN3 a LPG1R.

   Destino	Tipo de Destino	Objetivo	Tipo de ruta	Descripción
   10.20.0.0/16	Gateway de intercambio de tráfico local	LPG1R	Estático	Tráfico a VCN2
   10.30.0.0/16	Gateway de intercambio de tráfico local	LPG1R	Estático	Tráfico a VCN3

7. Cree la tabla de rutas HubLPG1rt en HubVCN1.
8. Asocie la tabla de rutas HubLPG1rt al gateway de intercambio de tráfico local HubLPG1.
9. Cree el gateway de enrutamiento dinámico DRG1.
10. Cree la tabla de rutas DRG1rt en HubVCN1.
11. Agregue una regla de ruta a la tabla de rutas DRG1rt para reenviar el tráfico de destino para VCN1 a HubLPG1.

    Destino	Tipo de Destino	Objetivo	Tipo de ruta	Descripción
    10.10.0.0/16	Gateway de intercambio de tráfico local	HubLPG1	Estático	Tráfico a VCN1

12. Para adjuntar DRG1 a HubVCN1:
    1. Seleccione Tabla de rutas de Drg generada automáticamente para asociaciones de VCN.
    2. Seleccione la tabla de rutas existente DRG1rt.
    3. Seleccione Bloques de CIDR de VCN.
13. Cree dos conexiones de intercambio de tráfico remotas en DRG1, denominadas RPC1a y RPC1b.
14. Agregue dos reglas de ruta a HubLPG1rt para reenviar el tráfico de destino para VCN2 y VCN3 a DRG1.

    Destino	Tipo de Destino	Objetivo	Tipo de ruta	Descripción
    10.20.0.0/16	Gateway de direccionamiento dinámico	DRG1	Estático	Tráfico a VCN2
    10.30.0.0/16	Gateway de direccionamiento dinámico	DRG1	Estático	Tráfico a VCN3

Siga estos pasos para crear la primera región en espera (Región 2):

1. Agregue las siguientes reglas de entrada a la lista de seguridad de la subred de cliente de VCN2 para permitir el tráfico entrante de VCN1 y VCN3.

   Sin Estado	Origen	Protocolo IP	Rango de puertos de origen	Rango de puertos de destino	Permite	Descripción
   N.º	10.10.0.0/16	TCP	1521	1521	Tráfico TCP para puertos: 1521	Permitir entrada desde VCN1
   N.º	10.30.0.0/16	TCP	1521	1521	Tráfico TCP para puertos: 1521	Permitir entrada desde VCN3

2. Cree la red virtual en la nube HubVCN2 con CIDR 10.22.0.0/16.
3. Cree el gateway de intercambio de tráfico local HubLPG2 en la red virtual en la nube HubVCN2.
4. Cree el gateway de intercambio de tráfico local LPG2R en la red virtual en la nube VCN2.
5. Establezca la conexión de intercambio de tráfico local entre LPG2R y HubLPG2.
6. Agregue reglas de ruta a la tabla de rutas de la subred de cliente de VCN2 para reenviar el tráfico de destino para VCN1 y VCN3 a LPG2R.

   Destino	Tipo de Destino	Objetivo	Tipo de ruta	Descripción
   10.10.0.0/16	Gateway de intercambio de tráfico local	LPG2R	Estático	Tráfico a VCN1
   10.30.0.0/16	Gateway de intercambio de tráfico local	LPG2R	Estático	Tráfico a VCN3

7. Cree la tabla de rutas HubLPG2rt en HubVCN2.
8. Asocie la tabla de rutas HubLPG2rt al gateway de intercambio de tráfico local HubLPG2.
9. Cree el gateway de enrutamiento dinámico DRG2.
10. Cree la tabla de rutas DRG2rt en HubVCN2.
11. Agregue una regla de ruta a DRG2rt para reenviar el tráfico de destino para VCN2 a HubLPG2.

    Destino	Tipo de Destino	Objetivo	Tipo de ruta	Descripción
    10.20.0.0/16	Gateway de intercambio de tráfico local	HubLPG2	Estático	Tráfico a VCN2

12. Para adjuntar DRG1 a HubVCN2:
    1. Seleccione Tabla de rutas de Drg generada automáticamente para asociaciones de VCN.
    2. Seleccione la tabla de rutas existente DRG2rt.
    3. Seleccione Bloques de CIDR de VCN.
13. Cree dos conexiones de intercambio de tráfico remotas en DRG2, denominadas RPC2a y RPC2c.
14. Establezca una conexión de intercambio de tráfico remoto entre RPC1a (región 1) y RPC2a (región 2).
15. Agregue dos reglas de ruta a HubLPG2rt para reenviar el tráfico de destino para VCN1 y VCN3 a DRG2.

    Destino	Tipo de Destino	Objetivo	Tipo de ruta	Descripción
    10.10.0.0/16	Gateway de direccionamiento dinámico	DRG2	Estático	Tráfico a VCN1
    10.30.0.0/16	Gateway de direccionamiento dinámico	DRG2	Estático	Tráfico a VCN3

Siga estos pasos para crear la segunda región en espera (Región 3):

1. Agregue las siguientes reglas de entrada a la lista de seguridad de la subred de cliente de VCN3 para permitir el tráfico entrante de VCN1 y VCN2.

   Sin Estado	Origen	Protocolo IP	Rango de puertos de origen	Rango de puertos de destino	Permite	Descripción
   N.º	10.10.0.0/16	TCP	1521	1521	Tráfico TCP para puertos: 1521	Permitir entrada desde VCN1
   N.º	10.20.0.0/16	TCP	1521	1521	Tráfico TCP para puertos: 1521	Permitir entrada desde VCN2

2. Cree la red virtual en la nube HubVCN3 con CIDR 10.33.0.0/16.
3. Cree el gateway de intercambio de tráfico local HubLPG3 en la red virtual en la nube HubVCN3.
4. Cree el gateway de intercambio de tráfico local LPG3R en la red virtual en la nube VCN3.
5. Establezca la conexión de intercambio de tráfico local entre LPG3R y HubLPG3.
6. Agregue reglas de ruta a la tabla de rutas de la subred de cliente de VCN3 para reenviar el tráfico de destino para VCN1 y VCN2 a LPG3R.

   Destino	Tipo de Destino	Objetivo	Tipo de ruta	Descripción
   10.10.0.0/16	Gateway de intercambio de tráfico local	LPG3R	Estático	Tráfico a VCN1
   10.20.0.0/16	Gateway de intercambio de tráfico local	LPG3R	Estático	Tráfico a VCN2

7. Cree la tabla de rutas HubLPG3rt en HubVCN3.
8. Asocie la tabla de rutas HubLPG3rt al gateway de intercambio de tráfico local HubLPG3.
9. Cree el gateway de enrutamiento dinámico DRG3.
10. Cree la tabla de rutas DRG3rt en HubVCN3.
11. Agregue una regla de ruta a DRG3rt para reenviar el tráfico de destino para VCN3 a HubLPG3.

    Destino	Tipo de Destino	Objetivo	Tipo de ruta	Descripción
    10.30.0.0/16	Gateway de intercambio de tráfico local	HubLPG3	Estático	Tráfico a VCN3

12. Para adjuntar DRG1 a HubVCN3:
    1. Seleccione Tabla de rutas de Drg generada automáticamente para asociaciones de VCN.
    2. Seleccione la tabla de rutas existente DRG3rt.
    3. Seleccione Bloques de CIDR de VCN.
13. Cree dos conexiones de intercambio de tráfico remotas en DRG3, denominadas RPC3b y RPC3c.
14. Establezca una conexión de intercambio de tráfico remoto entre RPC1b (región 1) y RPC3b (región 3).
15. Establezca una conexión de intercambio de tráfico remoto entre RPC2c (región 2) y RPC3c (región 3).
16. Agregue dos reglas de ruta a HubLPG3rt para reenviar el tráfico de destino para VCN1 y VCN2 a DRG3.

    Destino	Tipo de Destino	Objetivo	Tipo de ruta	Descripción
    10.10.0.0/16	Gateway de direccionamiento dinámico	DRG3	Estático	Tráfico a VCN1
    10.20.0.0/16	Gateway de direccionamiento dinámico	DRG3	Estático	Tráfico a VCN2

Explorar más

Obtenga más información sobre Oracle Database@Azure y Oracle Data Guard.

• Obtén más información sobre Oracle Maximum Availability Architecture for Oracle Database@Azure

• Documentación de Visión general de alta disponibilidad y mejores prácticas

• Mejores prácticas de MAA para la documentación de Oracle Data Guard

• Sitio de Oracle Database@Azure

• Primeros principios: potenciación de aplicaciones esenciales con el sitio de Oracle Database@Azure

• Oracle Exadata Database Service on Dedicated Infrastructure

• Ubicación de Oracle Data Guard

Revise estos recursos adicionales:

• Profesionales de Oracle Cloud Infrastructure for Microsoft Azure
• Marco bien diseñado para Oracle Cloud Infrastructure
• Documentación de Oracle Cloud Infrastructure
• Estimador de costos de Oracle Cloud

Confirmaciones

• Autores: Sinan Petrus Toma, Sebastian Solbach, Julien Silverston
• Contribuyente: Sreya Dutta