Oracle Database@Azure Network Highlights

As you know, Oracle Database@Azure has been available now for few years and Microsoft has made awesome advantages in the solution during this time. Some of the things might not be so “hot” but if you work with any of the offerings they have, you know these improvements/new features have been really welcomed for critical workloads that are going to Azure.

This post is just about how easy the network setup nowadays is but I do want to highlight one integration which has been crucial, support for Azure Key Vault is available as well. This is trend with other DB@X providers as well, since you will see everyone offering more integration with their cloud services as that’s what people want.

Shortened version for folks not wanting to read whole story: I think the new advanced networking features are great and they bring support to many of the enterprise scale security, compliance and access pattern requirements there are!

Azure Networking with Advanced Networking Features

In this post I’ll highlight some key features Azure/Microsoft has for the DB@Azure solution and how seamless it is (nowadays) to do the necessary setup. I’ll focus on Exadata in this post also, Autonomous Database is somewhat similar if you use private endpoint/connectivity to it (with some differences of course!).

Some of these features are part of what Microsoft calls “Advanced Network Features” and they provide you commands on how to enable them (see below).

PS /home/simo> Register-AzProviderFeature -FeatureName "EnableRotterdamSdnApplianceForOracle" -ProviderNamespace "Microsoft.Baremetal"

FeatureName                          ProviderName        RegistrationState
-----------                          ------------        -----------------
EnableRotterdamSdnApplianceForOracle Microsoft.Baremetal Registered

PS /home/simo> Register-AzProviderFeature -FeatureName "EnableRotterdamSdnApplianceForOracle" -ProviderNamespace "Microsoft.Network"  

FeatureName                          ProviderName      RegistrationState
-----------                          ------------      -----------------
EnableRotterdamSdnApplianceForOracle Microsoft.Network Registered

When you create your VNet where you will place your Exadata VM Cluster, you can have “standard” subnets where your applications go, but for VM cluster client subnet, you will create just another subnet in the same VNet and just assign it to be delegated subnet.

For subnet delegation, you choose the type Oracle.Database/networkAttachments and that’s it! This way once you create the VM cluster, you will have it in same VNet as your app servers(if you choose to design your Azure network that way). For me, this is super simple as I don’t need to think on app<>database peering and any additional latency that comes with it.

Now that’s not to say that in some cases you place app and database in different VNets but you have the option to use same VNet which is great.

Each VNet can have a single delegated subnet for your Oracle DB@Azure cluster(s) and you can design your approach then accordingly.

Some of the key things with advanced networking are listed below – I’ve circled the main ones but it’s really around couple things normally – security, connectivity support and monitoring.

People want to control things on Azure side (NSGs) and not rely on OCI (which totally works as well). You want to be able to connect from VM Clusters towards Azure services (as you can see many supported connectivity patterns now), and finally be able to see traffic (flow logs).

Using Delegated Subnet for Exadata VM Cluster

No rocket science here, you just provision the Exadata VM cluster and pick the delegated subnet for your client subnet, Oracle will then use it when it creates the cluster and create matching subnet on the OCI control plane as well.

Backup subnet doesn’t need to get created on Azure side, you will define it during provisioning though and it gets created on OCI side.

I won’t go into details on Exadata provisioning which could be topic for another post though..

Finally, as you can see I’m using the standard oraclevcn.com domain for my VM clusters. So, SCAN and node names will be having the oraclevcn.com domain similar to OCI. To be able to resolve these across your org, you will need to configure your DNS to be able to resolve these, or use additional DNS for your scan for example.. But if you use the default ones, and connect from the VNet which has your delegated subnet, you will be able to connect right away!

Why is that? What Oracle and Microsoft have done, is to configure Private DNS so these oraclevcn.com addresses are resolvable from the VNet. If I look from the VNet DNS configuration I see the following:

I have two clusters and each cluster has gotten it’s own Private DNS zone. When I drill down to Private DNS Zone, I see it has records set for SCAN, nodes and node VIPs.

This is common across DB@X solutions though, the implementation might be slightly different on each but you would see similar configurations on all.

One additional thing on DNS – if you need to configure Exadata to be able to resolve your hosts on Azure or on-prem side. You would need to configure the OCI private DNS resolver what Exadata uses and most likely configure DNS forwarders for specific domains.

Summary

This post was just touch on the surface how much effort folks have put into DB@Azure solution to seamlessly integrate it with Azure networking/solutions.

There are always going to be some new requirements and things you would need, but in my opinion the solution is reaching a stage that there should not be any alarm bells going off if you want to move your enterprise Exadata/large Oracle DB workloads to Azure to get the performance and security you need.

As with everything though, make sure you know your requirements and test the solution inside and out before migrating!