Powering mission critical applications with Oracle Database@Azure
At Oracle Cloud Infrastructure (OCI), we believe that our customers must have access to our best-in-class services where they are and can use cloud services from multiple cloud providers in a seamless fashion. With multicloud strategy, customers always win. OCI and Microsoft Azure have partnered together to make it easier for customers to apply the power of Oracle Database services in the Azure environment with Oracle Database@Azure. You now have a simple way to use high performance Oracle Exadata Database Service and Oracle Autonomous Database directly from your applications all within Azure data centers.
Figure 1: Oracle Database@Azure architecture
Oracle Exadata Database Service is a best-in-class high-performance database service powered by RDMA-enabled ultra-low-latency cluster network connectivity and intelligent storage with unique database-aware software optimizations. Oracle Autonomous Database is built on top of the Exadata Database Service and brings all the benefits of Exadata along with automation that removes mundane database patching and operational activities so that the customers can focus on developing their applications.
Oracle Database@Azure services are essentially OCI services with Azure-native customer experience, physically hosted inside the Azure data centers with direct private network connectivity from Oracle Database Services in Azure datacenter to Azure network. Oracle Database@Azure provides the same high performance, scale, security, availability, and automation as the equivalent OCI database services.
Watch the video for the cloud architecture highlights behind Oracle Database@Azure.
Oracle Database @Azure: customer experience
Azure customers can use their credentials in Microsoft Entra ID (previously known as Azure Active Directory or Azure AD) to deploy and manage Oracle Database@Azure services through their existing Azure portal and Azure developer tools, software developer kits (SDKs), and APIs. You simply pay for the Oracle Database services using the Azure commercial relationship.
Figure 2: Creation of Oracle Exadata on Azure
With Oracle Database@Azure, you can use the Azure console or invoke an API or SDK to create an Exadata database instance. Then create a database cluster inside a subnet in your Azure VNET. Finally, start creating database instances through the Oracle Cloud Console.
The database is then presented in the your designated Azure subnet through private IP addresses. Customer-owned Azure resources, including virtual machines (VMs) and business intelligence (BI) services, can connect to your databases using the assigned private IP addresses.
Oracle Database @Azure high-level architecture
An OCI region contains one or three availability domains. Each availability domain can have one or more data center sites with child DC sites acting as an extension of the OCI availability domain fabric. The child sites of a region are an integral part of OCI. For Oracle Database@Azure, we built child sites inside Azure data centers, and connect them to a specific OCI region that’s closest in terms of physical distance and network distance.
Figure 3: OCI regions and child sites
Oracle Database@Azure stacks and their key dependencies are entirely hosted in the OCI child sites inside the Azure data centers with the same underlying infrastructure as OCI, offering the same physical network stack, Gen 2 Virtual Network service, off-box virtualization, and RDMA cluster network to power Oracle Exadata Database Service and the Oracle Autonomous Database. In fact, all software updates, security patches, and deployments to OCI are performed the same way as any other OCI region, including the security and operational controls. A key highlight of this partnership with Microsoft, is that we create a direct private network link between the OCI child site in the Azure data center and the Azure network in the same data center.
Figure 4: High-level architecture for Oracle Database@Azure
When you create an Oracle Database@Azure database cluster in a subnet in your virtual network (VNET), behind the scenes, a backend OCI virtual cloud network (VCN) is created with an equivalent subnet inside the backend VCN with the same IP CIDR range as the subnet in Azure VNET. The database cluster then launches in the OCI subnet and the required virtual network interface cards (VNICs) within the OCI subnet with necessary private IP assignments are created as part of the database cluster launch. The private IP addresses are also reserved on the subnet in Azure VNET. Finally, a virtual mapping is created between the private IP in the customer VNET and the VNIC in the backend VCN through direct Azure-OCI connectivity within the Azure datacenter.
When an app in Azure VNET connects to a database using the assigned private IP address, the Azure virtual networking service routes the packets through the direct private network connectivity to the edge gateway located inside the child site where OCI virtual networking service routes the packets from the edge gateway to the servers hosting the Oracle Database instance. The direct private network link plays an important role in delivering low network latency between clients inside Azure network and Oracle Database instances in the child site while also ensuring the database network traffic doesn’t leave the Azure data center.
The OCI VCN and subnet are invisible to Azure customers through the Azure console. They’re hidden implementation details that customers don’t have to worry about.
Oracle Database@Azure native integration
Let’s better understand what happens when you provision an Exadata Database instance through the Azure console. You first create an Exadata infrastructure, and then an Exadata VM Cluster in Azure Console. After the VM cluster is created, from OCI, you will then be able to create Exadata database instance.
The Azure console invokes the Azure Resource Manager, which routes the API call to Oracle Database@Azure Resource Provider. The resource provider performs the appropriate translation, AuthZ and AuthN, and invokes the Exadata Database control plane, which is responsible for creating and managing the Exadata Database instance. To make the customer experience seamless, as part of initial setup, OCI can create a federation between the Microsoft Entra ID and OCI Identity and Access Management (IAM) service. This integration allows you to continue using Microsoft Entra ID for identity management. When you invoke API calls on your Oracle Database@Azure resources, the corresponding downstream OCI API calls uses the federated identity for authentication purposes.
Figure 5: High-level Oracle Database@Azure native integration
Conclusion
The OCI-Azure partnership has evolved to provide one of the best multicloud experiences in the industry. Oracle Database@Azure provides Oracle Database services physically hosted in Azure data centers with an Azure-native customer experience and ultra-low latency between the Azure resources and the Oracle Database@Azure.
Oracle Cloud Infrastructure Engineering handles the most demanding workloads for enterprise customers, which has pushed us to think differently about designing our cloud platform. We have more of these engineering deep dives as part of this First Principles series, hosted by Pradeep Vincent and other experienced engineers at Oracle.
For more information, see the following resources:
