Planificación de su despliegue

Oracle Database@Azure utiliza hardware de cluster de Oracle Exadata, redes RDMA y el último software y Oracle Database, todos instalados directamente en el centro de datos de Microsoft Azure.

Esta arquitectura permite utilizar el mismo servicio de Oracle Database que se ejecuta de forma nativa en Oracle Cloud Infrastructure, pero en Microsoft Azure.

En esta sección, se describen las siguientes implementaciones:

• Oracle Database@Azure Oracle Autonomous Database
• Oracle Database@Azure Oracle Exadata Database Service

Diseño de red para Autonomous Database de Oracle Database@Azure

Esta arquitectura muestra Oracle Autonomous Database desplegado en Microsoft Azure.

Autonomous Database se presenta como una tarjeta de interfaz de red virtual (VNIC) en una subred de Azure delegada a Oracle.Database/networkAttachments. Durante el aprovisionamiento del servicio, se crea una red virtual en la nube (VCN), con el mismo rango de bloques de CIDR que la subred delegada. La VCN es una construcción regional que abarca desde el sitio secundario hasta la región de Oracle Cloud Infrastructure (OCI) más cercana. OCI Object Storage se utiliza para realizar una copia de seguridad de la base de datos.

Descripción de la ilustración network-adb-azure.png

network-adb-azure-oracle.zip

Para desplegar Oracle Autonomous Database en Microsoft Azure, utilice los siguientes pasos de alto nivel:

1. Planifique el bloque CIDR (enrutamiento entre dominios sin clase) para la subred delegada del cliente.

   Reserve el bloque CIDR para la subred en la que se desplegará Autonomous Database. Este bloque de CIDR no se debe solapar con los que ya se utilizan localmente o en el despliegue actual de Azure. Además:

   • 13 direcciones IP están reservadas para servicios de red en la subred del cliente, independientemente de cuántas instancias de Autonomous Database estén presentes en la subred del cliente. Las 13 direcciones son las primeras 4, las del 9 al 16 y la última dirección IP.
   • El tamaño mínimo del bloque CIDR es /27.
   • Las direcciones IP 100.106.0.0/16 y 100.107.0.0/16 están reservadas para la conectividad interna y no se pueden asignar a la subred del cliente.

   Planifique siempre la futura expansión del entorno y considere la posibilidad de asignar un bloque CIDR más grande que el necesario. Una vez aprovisionado el servicio, no se puede cambiar el tamaño del bloque de CIDR.

2. Cree la subred delegada.

   En la red virtual que alojará Autonomous Database, cree una subred y delegue en Oracle.Database/networkAttachments. En la subred delegada, solo se permiten cargas de trabajo de Oracle Database@Azure y no puede aprovisionar otros servicios informáticos o de Azure en esa subred.

   Al aprovisionar Oracle Database@Azure, debe especificar la red virtual y la subred delegada.

3. Comprenda el DNS (servicio de nombres de dominio).

   Autonomous Database tendrá un nombre de dominio completo (FQDN) del dominio oraclecloud.com. Esta zona es una zona de DNS privada que reside en OCI. Los registros de esta zona se replican en una zona de DNS privada correspondiente en Azure. Las aplicaciones de Azure que se conectan a Autonomous Database resuelven el FQDN mediante la zona de DNS privado de Azure.

   Para verificar el FQDN, primero navegue hasta el arrendamiento de OCI y compruebe la zona de DNS allí y, a continuación, verifique el DNS en la consola de Azure:

   1. En la consola de Azure, vaya a la consola de servicio de Oracle Autonomous Database y observe la IP privada de la base de datos que se muestra en Network. Haga clic en Ir a OCI.
   2. Conéctese al arrendamiento de OCI, consulte la página de detalles de Autonomous Database y anote la VCN en la que se despliega la base de datos y el grupo de seguridad de red (NSG) utilizado para aprobar el tráfico de red a Autonomous Database.
   3. Haga clic en el enlace Red virtual en la nube.
   4. Haga clic en el enlace Solucionador de DNS.
   5. Haga clic en el enlace Vista privada por defecto.
   6. Localice la zona de DNS que utiliza Autonomous Database y compruebe la dirección IP del registro A. Observe el nombre de dominio.
   7. En la consola de Azure, vaya al servicio DNS de Azure, busque la zona de DNS privada que ha identificado en la consola de OCI y haga clic en Enlaces de red virtual. Tenga en cuenta que es el mismo que el nombre de dominio de la consola de OCI
4. Apruebe el tráfico de red a Autonomous Database.
   1. Conéctese al arrendamiento de OCI, consulte la página de detalles de Autonomous Database y haga clic en el enlace Grupos de seguridad de red.
   2. Asegúrese de que las aplicaciones que se conectan a Autonomous Database tienen la aprobación necesaria (tcp 1521 o tcp 1522).

Diseño de red para Oracle Database@Azure Oracle Exadata Database Service

Esta arquitectura muestra Oracle Exadata Database Service desplegado en Microsoft Azure.

El servicio se presenta como una serie de tarjetas de interfaz de red virtual (VNIC) en una subred de Azure delegadas a Oracle.Database/networkAttachments. Durante el aprovisionamiento del servicio, se crea una red virtual en la nube (VCN), con el mismo rango de bloques de CIDR que la subred delegada. La VCN es una construcción regional que abarca desde el sitio secundario hasta la región de OCI más cercana.

Aunque Oracle Autonomous Database es un servicio regional y se puede iniciar automáticamente en varias zonas, Oracle Exadata Database Service tiene afinidad para una zona específica.

Descripción de la ilustración network-exadata-azure.png

red-exadata-azure-oracle.zip

Para desplegar Oracle Exadata Database Service en Microsoft Azure, utilice los siguientes pasos de alto nivel:

1. Planifique el bloque CIDR para la subred delegada del cliente.

   Oracle Exadata Database Service necesita dos rangos de bloques de CIDR: un bloque de CIDR para la subred de cliente que se utiliza para aprovisionar una subred delegada en Azure y otro bloque de CIDR opcional para la subred de copia de seguridad. Los bloques CIDR no se deben solapar con los que ya se utilizan localmente o en el despliegue actual de Azure.

   La subred del cliente tiene los siguientes requisitos:

   • Cada máquina virtual (VM) requiere 4 direcciones IP. Los clusters de VM tienen un mínimo de 2 máquinas virtuales. Por lo tanto, un cluster de VM con 2 máquinas virtuales requiere 8 direcciones IP en la subred del cliente. Cada máquina virtual adicional agregada a un cluster de VM aumenta el número de direcciones IP necesarias en la subred del cliente en 4 IP.
   • Cada cluster de VM requiere 3 direcciones IP para nombres de acceso de cliente único (SCAN), independientemente de cuántas máquinas virtuales estén presentes en el cluster de VM.
   • 13 direcciones IP están reservadas para servicios de red en la subred del cliente, independientemente de cuántas instancias de Autonomous Database estén presentes en la subred del cliente. Las 13 direcciones son las primeras 4, las del 9 al 16 y la última dirección IP.
   • El tamaño mínimo del bloque CIDR es /27.
   • Las direcciones IP 100.106.0.0/16 y 100.107.0.0/16 están reservadas para la conectividad interna y no se pueden asignar a la subred del cliente.
   • Una subred de cliente puede alojar clusters de VM de diferentes infraestructuras de Exadata si son de la misma zona de disponibilidad.

   La subred de copia de seguridad tiene los siguientes requisitos:

   • Cada máquina virtual (VM) requiere 3 direcciones IP. Los clusters de VM tienen un mínimo de 2 máquinas virtuales. Por lo tanto, un cluster de VM con 2 máquinas virtuales requiere 6 direcciones IP en la subred de copia de seguridad. Cada máquina virtual adicional agregada a un cluster de VM aumenta el número de direcciones IP necesarias en la subred de copia de seguridad en 3 IP.
   • Los servicios de red requieren 3 direcciones IP para la subred de copia de seguridad, independientemente de cuántos clusters de VM estén presentes en la subred de copia de seguridad.
   • El tamaño mínimo del bloque CIDR es /28.

   Planifique siempre la futura expansión del entorno y considere la posibilidad de asignar un bloque CIDR más grande que el necesario. Una vez aprovisionado el servicio, no se puede cambiar el tamaño del bloque de CIDR.

2. Cree la subred delegada.

   En la red virtual que alojará el cluster de VM de Exadata, cree una subred y delegue en Oracle.Database/networkAttachments. En la subred delegada, solo se permiten cargas de trabajo de Oracle Database@Azure y no puede aprovisionar otros servicios informáticos o de Azure en esa subred.

   Al aprovisionar Oracle Exadata Database Service, debe especificar la subred de cliente delegada y la subred de copia de seguridad.

   Si no se proporciona un bloque CIDR para la subred de copia de seguridad, se utiliza el rango 192.168.252.0/22 por defecto. La subred de copia de seguridad no se utiliza en Azure y el bloque de CIDR no forma parte del bloque de CIDR de red virtual. Si considera un escenario de recuperación ante desastres con varios despliegues de Exadata (entre zonas de disponibilidad o entre regiones), se debe proporcionar el bloque CIDR de la subred de copia de seguridad y no se debe solapar con ningún otro bloque CIDR utilizado.

   Después de crear el cluster de VM, configure la base de datos con la documentación del producto estándar. Consulte Explorar más.

3. Comprenda el DNS.

   Hay tres posibles escenarios para la configuración de DNS al aprovisionar Oracle Exadata Database Service:

   • Servicio totalmente gestionado

     Esta es la opción por defecto en la que Oracle maneja la configuración de DNS durante el proceso de aprovisionamiento. Oracle crea registros A para el cluster de VM y SCAN utilizará el nombre de dominio completo (FQDN) *.oraclevcn.com. Esta integración es esencial porque el plano de control de Exadata funciona en OCI, que utiliza el servicio de DNS privado de OCI para el aprovisionamiento. Además, el proceso de aprovisionamiento sincroniza automáticamente estos registros A con el DNS privado de Azure. Como resultado, si utiliza el DNS privado de Azure, la configuración de DNS está totalmente automatizada y es perfecta desde el primer momento.

     Después de aprovisionar las entradas de DNS en el DNS privado de OCI y Azure tendrán *.oraclevcn.com FQDN

   • FQDN personalizado

     Con el DNS gestionado, el FQDN generado sigue el formato *.oraclevcn.com, que puede no ser ideal para algunos clientes, especialmente aquellos que ya lo utilizan en OCI y no pueden implementarlo en Azure. Como alternativa, Oracle permite a los clientes especificar un FQDN personalizado durante el proceso de aprovisionamiento. Sin embargo, este enfoque carece de la sincronización unidireccional entre OCI y Azure que proporciona el DNS gestionado. Como resultado, los clientes deben replicar manualmente los registros A de su zona personalizada en el DNS privado de OCI en el DNS privado de Azure.

     Debido a que los clusters de VM utilizan el DNS privado de OCI para la resolución, los usuarios deben crear un FQDN personalizado antes de aprovisionar el cluster de VM. Para ello, vaya al solucionador de DNS asociado a la VCN y cree una nueva zona privada junto con una vista privada y asocie este nuevo solucionador privado a DNS.

     Después de completar este paso, la interfaz de usuario de Azure muestra automáticamente la zona personalizada recién creada cuando se selecciona la opción FQDN personalizada durante el proceso de creación del cluster de VM.

     Después del aprovisionamiento, los recursos de Azure pueden acceder a las entradas de DNS de varias formas. El método más sencillo es replicar las entradas de zona privada de OCI en el DNS privado de Azure. También puede crear un punto final de recepción de DNS de OCI para reenviar solicitudes al DNS privado de OCI.

   • DNS personalizado

     También puede configurar un DNS personalizado. Por ejemplo, si desea utilizar un DNS de terceros, como Infoblox, con Oracle Exadata Database Service, pueden seguir el mismo proceso que con un FQDN personalizado. Después, debe duplicar los registros DNS relevantes en el DNS personalizado. Esto garantiza que las aplicaciones y los usuarios puedan resolver la URL de SCAN mediante el DNS personalizado.