Plan Your Deployment

Oracle Database@Azure uses Oracle Exadata cluster hardware, RDMA networks, and the latest Oracle Database and software, all directly installed within the Microsoft Azure data center.

This architecture allows you to use the same Oracle Database service that runs natively on Oracle Cloud Infrastructure, but on Microsoft Azure.

The following implementations are described in this section:

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

Network Design for Oracle Database@Azure Autonomous Database

This architecture shows Oracle Autonomous Database deployed on Microsoft Azure.

Autonomous Database is presented as a virtual network interface card (VNIC) in an Azure subnet delegated to Oracle.Database/networkAttachments. During the provisioning of the service, a Virtual Cloud Network (VCN), with the same CIDR block range as the delegated subnet is created. The VCN is a regional construct and spans from the child-site to the closest Oracle Cloud Infrastructure (OCI) region. OCI Object Storage is used to back up the database.


Description of network-adb-azure.png follows
Description of the illustration network-adb-azure.png

network-adb-azure-oracle.zip

To deploy Oracle Autonomous Database on Microsoft Azure, use following high-level steps:

  1. Plan the CIDR (classless inter-domain routing) block for the client delegated subnet.

    Reserve the CIDR block for the subnet where Autonomous Database will be deployed. This CIDR block must not overlap with the ones already used on-premises or in the current Azure deployment. In addition:

    • 13 IP addresses are reserved for networking services in the client subnet, regardless of how many Autonomous Database instances are present in the client subnet. The 13 addresses are the first 4, the 9th to 16th, and the last IP address.
    • The minimum CIDR block size is /27.
    • IP addresses 100.106.0.0/16 and 100.107.0.0/16 are reserved for internal connectivity and can't be allocated to the client subnet.

    Always plan for future expansion of the environment and consider allocating a larger CIDR block than the one needed. After the service is provisioned, the CIDR block cannot be resized.

  2. Create the delegated subnet.

    In the virtual network that will host Autonomous Database, create a subnet and delegate it toOracle.Database/networkAttachments. In the delegated subnet, only Oracle Database@Azure workloads are allowed and you cannot provision other Azure or compute services in that subnet.

    When you provision Oracle Database@Azure, you must specify the virtual network and the delegated subnet.

  3. Understand the DNS (domain name service).

    Autonomous Database will have a fully-qualified domain name (FQDN) from the oraclecloud.com domain. This zone is a private DNS zone that resides in OCI. The records from this zone are replicated to a corresponding private DNS zone in Azure. The applications from Azure that connects to Autonomous Database resolve the FQDN by using the Azure private DNS zone.

    To verify the FQDN, first navigate to the OCI tenancy and check the DNS zone there, then, verify the DNS in the Azure console:

    1. In the Azure console, navigate to the Oracle Autonomous Database service console and note the Database private IP listed under Network. Click Go to OCI.
    2. Log on to the OCI tenancy, view the details page for Autonomous Database, and make note of the VCN where the database is deployed and of the network security group (NSG) used to approve network traffic to Autonomous Database.
    3. Click the Virtual Cloud Network link.
    4. Click the DNS Resolver link.
    5. Click the Default private view link.
    6. Locate the DNS zone used by Autonomous Database and check the IP address of the A-record. Note the domain name.
    7. In the Azure console, navigate to Azure DNS service, locate the private DNS zone you identified in the OCI console, and click Virtual Network Links. Note that it is the same as the domain name from the OCI console
  4. Approve network traffic to Autonomous Database.
    1. Log on to the OCI tenancy, view the details page for Autonomous Database, and click Network Security Groups link.
    2. Make sure that the applications connecting to Autonomous Database have the required approval (either tcp 1521 or tcp 1522).

Network Design for Oracle Database@Azure Oracle Exadata Database Service

This architecture shows Oracle Exadata Database Service deployed on Microsoft Azure.

The service is presented as a series of virtual network interface cards (VNICs) in an Azure subnet delegated to Oracle.Database/networkAttachments. During the provisioning of the service, a Virtual Cloud Network (VCN), with the same CIDR block range as the delegated subnet is created. The VCN is a regional construct and spans from the child-site to the closest OCI region.

While Oracle Autonomous Database is a regional service and can be automatically launched across various zones, Oracle Exadata Database Service has affinity for a specific zone.


Description of network-exadata-azure.png follows
Description of the illustration network-exadata-azure.png

network-exadata-azure-oracle.zip

To deploy Oracle Exadata Database Service on Microsoft Azure, use following high-level steps:

  1. Plan the CIDR block for the client delegated subnet.

    Oracle Exadata Database Service requires two CIDR block ranges: one CIDR block for the client subnet that is used to provision a delegated subnet in Azure and another optional CIDR block for the backup subnet. The CIDR blocks must not overlap with the ones already used on-premises or in the current Azure deployment.

    The client subnet has the following requirements:

    • Each virtual machine (VM) requires 4 IP addresses. VM clusters have a minimum of 2 virtual machines. Therefore, a VM cluster with 2 virtual machines requires 8 IP addresses in the client subnet. Each additional virtual machine added to a VM cluster increases the number of IP addresses needed in the client subnet by 4 IPs.
    • Each VM cluster requires 3 IP addresses for Single Client Access Names (SCANs), regardless of how many virtual machines are present in the VM cluster.
    • 13 IP addresses are reserved for networking services in the client subnet, regardless of how many Autonomous Database instances are present in the client subnet. The 13 addresses are the first 4, the 9th to 16th, and the last IP address.
    • The minimum CIDR block size is /27.
    • IP addresses 100.106.0.0/16 and 100.107.0.0/16 are reserved for the internal connectivity and can't be allocated to client subnet.
    • A client subnet can host VM clusters from different Exadata infrastructures if they are from the same availability zone.

    The backup subnet has the following requirements:

    • Each virtual machine (VM) requires 3 IP addresses. VM clusters have a minimum of 2 virtual machines. Therefore, a VM cluster with 2 virtual machines requires 6 IP addresses in the backup subnet. Each additional virtual machine added to a VM cluster increases the number of IP addresses needed in the backup subnet by 3 IPs.
    • Networking services require 3 IP addresses for the backup subnet, regardless of how many VM clusters are present in the backup subnet.
    • The minimum CIDR block size is /28.

    Always plan for future expansion of the environment and consider allocating a larger CIDR block than the one needed. After the service is provisioned, the CIDR block cannot be resized.

  2. Create the delegated subnet.

    In the virtual network that will host the Exadata VM cluster, create a subnet and delegate it to Oracle.Database/networkAttachments. In the delegated subnet, only Oracle Database@Azure workloads are allowed and you cannot provision other Azure or compute services in that subnet.

    When you provision Oracle Exadata Database Service, you must specify the delegated client subnet and the backup subnet.

    If a CIDR block for the backup subnet is not provided, the default 192.168.252.0/22 range is used. The backup subnet is not used in Azure and the CIDR block is not part of the Virtual Network CIDR block. If you consider a disaster recovery scenario with multiple Exadata deployments (cross-availability zone or cross-region), the backup subnet CIDR block must be provided and must not overlap with any other CIDR block used.

    After creating the VM cluster, set up your database using the standard product documentation. See Explore More.

  3. Understand the DNS.

    There are three possible scenarios for DNS configuration when provisioning Oracle Exadata Database Service:

    • Fully Managed

      This is the default option where Oracle handles the DNS configuration during the provisioning process. Oracle create A records for the VM cluster, and the SCAN will use the *.oraclevcn.com full-qualified domain name (FQDN). This integration is essential because the Exadata control plane operates on OCI, which uses OCI's private DNS service for provisioning. Furthermore, the provisioning process automatically synchronizes these A records with Azure's private DNS. As a result, if you use Azure’s private DNS, the DNS configuration is fully automated and seamless right out of the box.

      After provisioning DNS entries in OCI private DNS and Azure will have *.oraclevcn.com FQDN

    • Custom FQDN

      With managed DNS, the generated FQDN follows the format *.oraclevcn.com, which may not be ideal for some customers, particularly those already using it in OCI and unable to implement it in Azure. As an alternative, Oracle allows customers to specify a custom FQDN during the provisioning process. However, this approach lacks the one-way synchronization between OCI and Azure that managed DNS provides. As a result, customers must manually replicate the A records from their custom zone into OCI private DNS to Azure private DNS.

      Because VM clusters use OCI Private DNS for resolution, users must create a custom FQDN before provisioning the VM cluster. To do this, navigate to the DNS resolver attached to the VCN and create a new private zone along with a private view and attach this new private new to DNS resolver.

      After you complete this step, the Azure UI automatically displays the newly created custom zone when the custom FQDN option is selected during the VM cluster creation process.

      After provisioning, Azure resources can access DNS entries in several ways. The simplest method is to replicate the OCI private zone entries in Azure Private DNS. Alternatively, you can create an OCI DNS listening endpoint to forward requests to the OCI Private DNS.

    • Custom DNS

      You can also configure a custom DNS. For instance, if you wants to use a third-party DNS, such as Infoblox, with Oracle Exadata Database Service, they can follow the same process as with a custom FQDN. Afterward, you should duplicate the relevant DNS records in the custom DNS. This ensures that applications and users can resolve the SCAN URL using the custom DNS.