Multicloud Deployment Using Oracle Database Service for Azure (ODSA)

In the realm of Cloud Wars, it's a rarity to witness two rival tech giants collaborate and unveil joint service integrations. On July 20, 2022, Oracle Corp and Microsoft Corp made a significant joint announcement, revealing the official launch of Oracle Database Service for Microsoft Azure (ODSA). This partnership brings substantial advantages to Azure users, offering them the seamless ability to provision, access, and operate enterprise-grade Oracle Database services within Oracle Cloud Infrastructure (OCI), all while enjoying a user experience reminiscent of Azure's interface.With ODSA, users can effortlessly construct new applications or undertake migration to Azure, subsequently connecting to highly performant, highly available, and managed Oracle Databases operating within OCI

 

How does it work?

The foundation of ODSA started in 2019 with the introduction of OCI-Azure Interconnect which offers a secure and private interconnect with sub-millisecond latency in correlated data regions. As of September 2022, there are 11 global regions available. However, connecting any resource in either cloud requires customers to configure and manage the connectivity between cloud environments.

Moving a step further, the ODSA simplifies the configuration, management, and connectivity of application components in Azure to OCI with just a few clicks. ODSA provides an Azure-like user interface and API experience for provisioning and managing Oracle databases in OCI. It also sends metrics, logs, and events for the databases running in OCI using the service to Azure for unified telemetry and monitoring (Azure Synapse Analytics) in Azure.

As you can see from the figure below, ODSA builds a private tunnel between Azure and OCI tenants using OCI-Azure Interconnect. The service also configures DNS on both sides of the tunnel to enable bi-directional communication between applications in your Azure subscription and database resources in OCI.

Source: https://blogs.oracle.com/cloud-infrastructure/post/oracle-database-service-azure-overview

 

How to get started?

To use ODSA, you need an existing Azure account with a ‘subscription’ and administrative privileges as specified below. The following Azure roles have sufficient privileges to sign up:

• Global Administrator
• Application Administrator
• Cloud Application Administrator
• Privileged Role Administrator

A Resource Group must be created in your Azure account and at least one Azure Virtual Network (VNET), which will be paired with a corresponding OCI virtual cloud network (VCN) during ODSA the service onboarding should be available.

You can sign up for an OCI account during the process if you don’t have any. To sign up with an existing OCI tenancy, your tenancy must support identity domains.

To confirm whether your OCI tenancy supports identity domains, do the following:

1. Log in to the OCI console using credentials for the tenancy you used with ODSA sign-up
2. Using the navigation menu (navigation menu icon) navigate to Identity & Security, then click Identity.
3. Look for a menu listing for Domains under Identity:

   

4. If you do not see Domains listed under Identity, your tenancy does not currently support identity domains. To continue with your ODSA sign-up, and create a child tenancy in a region that supports ODSA. Then use your new child tenancy to sign up for ODSA.

 

Once all the above prerequisites are met:

Step 1: Start your Oracle Database Service for Azure sign-up by visiting the sign-up website at https://signup.multicloud.oracle.com/azure

You need to sign in with the Azure account you wish to do the linking with OCI. Consent to the permissions is required to initiate the account linking with Azure.

 Step 2:  After logging in using Azure credentials, you will see the ‘Welcome to Oracle Database for Azure’ page. From this page, choose the deployment path you want to take, automated configuration, or guided account linking. I’ve selected a fully automated configuration.

For a detailed explanation of two onboarding options refer to the documentation at https://docs.oracle.com/en-us/iaas/Content/multicloud/signup.htm

 

Step 3: Select your Azure subscription and click Continue. 

 

Step 4: Enter your OCI tenancy name and click Continue.

 

Step 5: Select the region and continue.

 

The following screen took up to 5~6 minutes to complete. It will be completed once the linking is done.

 

Step 6: Once the above step is complete, you will be redirected to the Oracle multicloud console at https://console.multicloud.oracle.com/azure However, this is not the usual Azure portal. But you can use your Azure credentials to log in.

Only the following three database services are available as of now.

• Oracle Exadata Database
• Autonomous Database on shared Exadata infrastructure
• Base Database

 How to provision databases on ODSA?

The process is similar to your provision of resources in Azure or OCI. You need to enter some mandatory inputs such as database name, credentials, VM Shape, Storage, etc.  These are the steps for creating an Autonomous Database.

 

Step 1: Enter the Resource group and instance Name.

 

 

Step 2: Select workload type, CPU count, Storage, License type, and database version.  

 

Step 3: Select the networking options.

 

Step 4: Enter database credentials.

 

Step 5: Tags are optional. Navigate to Review + Create. Validation should be passed. Click Create to start the deployment.

 

Step 6: Once the deployment is complete, you should get the following pages. Click on the database name to view the options.

 

Login to the OCI console and observe that the ATP resource has been created.

 

Similarly, Oracle Base Database can be created. The following figures illustrate the final stage of the deployment.

 

These are the stages of the deployment. It’s creating the network link resources.

 

Base DB system deployment is in progress.

 

You can log in to the OCI console and see the DB system is provisioning in the OCI itself.  

 

Base database creation is completed. You may see the container and pluggable database are in an Active state. Now it’s the right time to test the connectivity from an application in the Azure cloud.

 

Testing connectivity from Azure VM

What most matters in the multicloud deployment is the latency between two Clouds. Predominantly, applications and databases are running in separate Clouds. To simulate this, I created Windows 11 VM in Azure while ODSA deployed Oracle Base and Autonomous Transaction Processing (ATP) databases in the OCI cloud.

As a standard practice, I used the ping command to check the latency between the Azure Windows VM and the DB host of the Base Database. During the ping test, I got 3ms round trip time for each trip. This is 1ms higher than the ‘promised’ network latency.

However, it is better to check the latency from the database itself by executing some database workload.  Here, I used a script developed by Clemens Bleile to calculate the network latency. As explained in his blog, I’m planning to run a SQL with 5000 network round trips and measure the network latency by using the below equation.

Network Latency   = (“Elapsed Time” – “DB Time”) / “network round trips”

Additionally, I recorded results for two executions per DB to get the average value as the overall latency.

 

 Oracle Base DB (VM.Standard2.1)

Execution 01:

SQL> set serveroutput on feed off

SQL> exec dbms_output.put_line(to_char(:roundtrips_end - :roundtrips_begin)||' network round trips.');

1669 network round trips.

SQL> exec dbms_output.put_line(to_char((:time_end - :time_begin)*10)||' ms elapsed time.');

4830 ms elapsed time.

SQL> exec dbms_output.put_line(to_char((:db_time_end - :db_time_start)/1000)||' ms DB time.');

217.32 ms DB time.

SQL> exec dbms_output.put_line('--> (Elapsed Time - DB Time) / network round trips');

--> (Elapsed Time - DB Time) / network round trips


SQL> exec dbms_output.put_line(to_char(round((((:time_end - :time_begin)*10)-((:db_time_end - :db_time_start)/1000))/(:roundtrips_end - :roundtrips_begin),3))||' ms latency per round trip.');

2.764 ms latency per round trip.

 

Execution 02:

SQL> set serveroutput on feed off

SQL> exec dbms_output.put_line(to_char(:roundtrips_end - :roundtrips_begin)||' network round trips.');

1669 network round trips.

SQL> exec dbms_output.put_line(to_char((:time_end - :time_begin)*10)||' ms elapsed time.');

4630 ms elapsed time.

SQL> exec dbms_output.put_line(to_char((:db_time_end - :db_time_start)/1000)||' ms DB time.');

153.132 ms DB time.

SQL> exec dbms_output.put_line('--> (Elapsed Time - DB Time) / network round trips');

--> (Elapsed Time - DB Time) / network round trips


SQL> exec dbms_output.put_line(to_char(round((((:time_end - :time_begin)*10)-((:db_time_end - :db_time_start)/1000))/(:roundtrips_end - :roundtrips_begin),3))||' ms latency per round trip.');

2.682 ms latency per round trip.

 

ATP (OCPU 1)

Execution 01:

SQL> set serveroutput on feed off

SQL> exec dbms_output.put_line(to_char(:roundtrips_end - :roundtrips_begin)||' network round trips.');

4953 network round trips.

SQL> exec dbms_output.put_line(to_char((:time_end - :time_begin)*10)||' ms elapsed time.');

13940 ms elapsed time.

SQL> exec dbms_output.put_line(to_char((:db_time_end - :db_time_start)/1000)||' ms DB time.');

391.761 ms DB time.

SQL> exec dbms_output.put_line('--> (Elapsed Time - DB Time) / network round trips');

--> (Elapsed Time - DB Time) / network round trips


SQL> exec dbms_output.put_line(to_char(round((((:time_end - :time_begin)*10)-((:db_time_end - :db_time_start)/1000))/(:roundtrips_end - :roundtrips_begin),3))||' ms latency per round trip.');

2.735 ms latency per round trip.

 

Execution 02:

SQL> set serveroutput on feed off

SQL> exec dbms_output.put_line(to_char(:roundtrips_end - :roundtrips_begin)||' network round trips.');

4955 network round trips.

SQL> exec dbms_output.put_line(to_char((:time_end - :time_begin)*10)||' ms elapsed time.');

13420 ms elapsed time.

SQL> exec dbms_output.put_line(to_char((:db_time_end - :db_time_start)/1000)||' ms DB time.');

486.62 ms DB time.

SQL> exec dbms_output.put_line('--> (Elapsed Time - DB Time) / network round trips');

--> (Elapsed Time - DB Time) / network round trips


SQL> exec dbms_output.put_line(to_char(round((((:time_end - :time_begin)*10)-((:db_time_end - :db_time_start)/1000))/(:roundtrips_end - :roundtrips_begin),3))||' ms latency per round trip.');

2.61 ms latency per round trip.

 As per the summary table below, we can see that the average latency for the Oracle Base database is 2.723ms and 2.672ms for the ATP database. Though the expectation is to have the latency below 2ms, this 2. x millisecond latency is quite acceptable for most of the application workloads. We can expect that Oracle-Azure Interconnect would be further optimized in the future.

	Latency in milliseconds for Oracle Base Database	Latency in milliseconds for ATP
Execution 1	2.764	2.735
Execution 2	2.682	2.61
Average	(2.764+2.682)/2 = 2.723	(2.735+2.61)/2 = 2.672

 

ODSA Use Cases

Here we will discuss two widely used scenarios where we can ODSA:

1.) Split-stack Azure & OCI Deployment

Azure customers can move from self-managed Oracle Database products to fully manage services that are appropriate for their workloads, meets availability requirements, and includes built-in backups.

2.) On-premises to multicloud architecture

ODSA delivers low-latency database access and high database-to-application throughput for on-premises workloads migrated to multi-cloud environments built on Azure and OCI, wherein such an architecture Azure applications can take advantage of high availability features and performance optimizations otherwise only available on OCI.

 

Final thoughts

Overall, ODSA is a great choice for customers who looks for multicloud deployment between OCI and Azure. It provides a greater level of agility for Azure applications to have access to the databases running in OCI. However, there are still a few key features that are not available from the ODSA portal. These are the missing options that I’ve noticed.

• Database Cloning
• Dataguard association for Autonomous Database
• Point in time recovery
• Apex
• Service limit increase
• Billing

However, those features can be achieved if the user logs into the OCI console. Hopefully, those will be available via the multi-cloud portal in near future. Personally, I would prefer to have them within the Azure portal itself for more convenience.