This blog post is cowritten by Vinay Rao and Samir Shah.

Oracle and Microsoft recently announced a cloud partnership that enables cross-cloud networking, unified identity and access management, and a collaborative and integrated support model across Microsoft Azure and Oracle Cloud Infrastructure. The cross-cloud networking is a secure, dedicated link that provides high bandwidth and low latency between the two cloud providers. Customers don’t have to work with third-party network providers to set up the cross-cloud connectivity.

In part 1, Vinay Rao and I talked about building multicloud applications on Oracle and Microsoft, and how you can access Oracle Autonomous Database-Serverless from an application deployed on Microsoft Azure. In this post, we continue the story, but instead of Autonomous Database-Serverless, we are connecting to Autonomous Transaction Processing-Dedicated.

Differences Between Autonomous Database Serverless and Dedicated Deployment

Serverless is a simple and elastic deployment. Oracle autonomously operates all aspects of the database lifecycle, from database placement to backup and updates.

Dedicated is a private database cloud in a public cloud deployment. This type of deployment has completely dedicated compute, storage, network, and database services for only a single tenant. Dedicated deployment provides for the highest levels of security isolation and governance. The customer has customizable operational policies to guide autonomous operations for workload placement, workload optimization, update scheduling, availability level, overprovisioning, and peak usage.

ADB Dedicated is deployed in a private subnet within a Virtual Cloud Network(VCN), but unlike Serverless, ADB Dedicated does not require you to use wallets, although it is offered.

Roles and Responsibilities

A fleet administrator is responsible for the creation and the management of Autonomous Exadata Infrastructure (AEI) and Autonomous Container Database (ACD) resources for dedicated deployments.

A developer or a database administrator is responsible for creating Autonomous Database. Typically, AEI and ACD reside in a compartment managed by the fleet administrator, and the autonomous database resides in the user’s assigned compartment.

Reference Architecture

The following figure shows the high-level architecture for connecting applications running on Microsoft Azure to Oracle Autonomous Transaction Processing-Dedicated (ATP-D).

Figure 1. Architecture Diagram

Prerequisites

Before you deploy your application, follow the steps in the How to setup the interconnect between Oracle Cloud Infrastructure and Microsoft Azure post.

Before autonomous dedicated databases can be provisioned, Autonomous Exadata Infrastructure (AEI) and Autonomous Container Database (ACD) must be made available in the Oracle Cloud Infrastructure Console for your tenancy. If this is not yet configured, work with your fleet administrator.

Setup and Configuration on Oracle Cloud Infrastructure

This section outlines that steps that you perform in Oracle Cloud Infrastructure.

Oracle Step 1: Create the Database

  1. In the Oracle Cloud Infrastructure Console Quick Actions menu, click Autonomous Transaction Processing: Create a database.

  2. In the Create Autonomous Database dialog box, select Dedicated Infrastructure.

    Figure 2. Create the Database

  3. Enter all the required parameters and select the assigned ACD.

  4. Click Create Autonomous Database.

    Figure 3. Create the Database, Continued

Oracle Step 2: Save Database Connection Information

After the database is provisioned, the Autonomous Database Details page is displayed.

Figure 4. Oracle Database Details Page

  1. Click DB Connection to download the wallet and copy the database connection strings to the client host, virtual machine, or a container. The applications running on ATP-D need that information to connect to the database.

    Figure 5. Oracle Connection Page

    The connection strings that end with _tls use secure TCP and require you to download the wallet. The other strings don’t require the wallet. You can test the connectivity with or without a wallet.

  2. After you save the database connection information, close the dialog box.

Oracle Step 3: Configure Security Lists and Route Tables

The Autonomous Database Details page provides information about the VCN and private subnet where the ATP-D database is running. You need that information to configure security lists and route tables.

  1. Click the Autonomous Container Database name to view the details of the Autonomous Container Database (ACD) that this database instance was created on. The ACD was created by a fleet admin as part of the prerequisites.

    Figure 6. Autonomous Database Details Page

    The Autonomous Container Database Details page provides further information about the container database, the compartment it was created in, and the Autonomous Exadata Infrastructure (AEI).

    Figure 7. Autonomous Container Database Details Page

  2. To learn more about the AEI, click Autonomous Exadata Infrastructure. The AEI provides information about the VCN and subnet the container database is running on. Note the subnet for the AEI.

    Figure 8. Autonomous Exadata Infrastructure Page

  3. Click the VCN name to learn more about the VCN. Note the CIDR block for the VCN. You will use this CIDR when configuring the route table on Microsoft Azure (in Azure Step 2).

    Figure 9. Virtual Cloud Network Page

  4. Select the subnet that you noted earlier on the AEI page. Note the CIDR block of the subnet, which you will use later when configuring the Azure Network Security Group.

    Figure 10. Subnet Details Page

  5. Your subnet might have a default security list already created. To create a new list, click Add Security List. Click the Security List link to view the ingress and egress rules. The following screenshots show common rules that you can add to the security list. Be sure to follow security best practices and open only the ports that are required. For example, 1521 for SQL*Net TCP, 2484 for SQL*Net TCPS, and 443 for HTTPS.

    The source CIDR block is the same as the CIDR block of the VNet you’re using on Azure. You can further restrict the security rules to include only the subnet that you want to communicate with on Azure.

    Figure 11. Security List Ingress (top) and Egress (bottom) Rules

  6. After the appropriate security rules are updated, configure the route table. For the same VCN, under Resources, click Route Tables.

    Figure 12. Route Tables Page

  7. Similar to security list, you might already have a default route table. To create a new one, click Create Route Table. Add the second route rule as shown in the following screenshot. Note that the destination has the CIDR address of the VNet you are using on Azure.

    Figure 13. Route Table Details Page

Oracle Step 4: Configure Hybrid DNS

The applications running on Azure can connect to the ATP-D over the interconnect IP addresses are used in the tnsnames.ora file. The SCAN hostnames shown in the database connection strings (Oracle Step 2) can’t be resolved in Azure. You must substitute the host names with AEI IP addresses. You can determine the IP addresses by using nslookup commands on an Oracle Cloud Infrastructure VM.

Figure 14. ATP-D IP Addresses

To use the host names, configure hybrid DNS in Oracle Cloud Infrastructure.

Setup and Configuration on Microsoft Azure

This section outlines that steps that you perform in Azure.

Azure Step 1: Configure Network Security Group

You can create a new Network Security Group (NSG) or use an existing one in your Resource Group. For applications running on Azure, inbound and outbound security rules are necessary to allow the traffic to flow from Azure subnets to Oracle Cloud Infrastructure subnets.

In the following screenshot, the allow_atpd rule allows TCP traffic on ports 1521, 2484, and 443 between subnets 172.16.0.0/24 on Azure and 10.0.11.0/24 (which you noted in Oracle Step 3 from the Oracle subnet).

Figure 15. Configure Network Security Group

Azure Step 2: Configure Route Tables

You can use an existing route table or create a new one. There are two main tasks:

  • Ensure that you have assigned the appropriate subnet with the route table. This is the same subnet you opened to allow traffic in Azure Step 1.
  • Add a new route that sends the traffic to the Oracle VCN CIDR (Oracle Step 3).

Figure 16. Configure the Route Table

Testing Connectivity

You can test connectivity with SQL*Plus Client. On the Microsoft Azure VM or container, ensure that Oracle Instant Client is installed. You can also compare the entries in your client tnsnames.ora file to match the connection strings shown in the Oracle Step 2. If you are using wallets, download and unzip the wallet on the Azure VM or container. The wallet already has a tnsnames.ora file with correct entries.

Figure 17. Sample tnsnames.ora File Entry

Figure 18. Connecting the SQL*Plus Tool to ATP-D

To see the traffic flowing over the interconnect, you can use tcpdump or Wireshark/TShark. The following figure shows the output of TShark running on the Azure VM when connecting to the ATP-D database.

Figure 19. Output of TShark

Conclusion

Oracle Autonomous Database brings self-driving, self-securing, and self-repairing capabilities to data management in the cloud. In parts 1 and 2, we covered the entire lineup of Oracle Autonomous Databases that you can use with Microsoft Azure for different use cases. In addition to Autonomous Databases, you can interoperate Oracle Database Cloud Service and Exadata Cloud Service with the cross-cloud networking.

Thank you for reading the blog!