Oracle Database@Azure

Oracle Database@Azure is an Oracle database service that runs on Oracle Cloud Infrastructure (OCI), co-located in Microsoft data centers. This provides the fastest access to Azure resources and applications for Oracle Database@Azure services. The solution is designed to help you migrate Oracle database workloads to Azure, and allows you to integrate and innovate with a wide range of Microsoft Cloud services.

For more information and better understanding of Oracle Database@Azure, visit: Overview – Oracle Database@Azure | Microsoft Learn

Currently, the Oracle Database@Azure service has a network limitation that prevents it from responding to network connections outside of an Azure Virtual Network (VNet). This limitation limits the ability to extend integration to Azure services that are not within the same VNet. This issue also impacts network communications on-premises that need to connect to Oracle. Database@Azure.

The solution is to deploy a Network Virtual Appliance (NVA) within the Oracle Database@Azure VNet to overcome this network limitation. Microsoft and Oracle have collaborated to develop a design pattern to remove this network limitation, but customers deploying in Azure regions where this pattern is not yet available will need to deploy an NVA.

NVA deployment

NVAs are comprised of Linux virtual machines (VMs) and can be any distribution supported by Azure. The NVAs referenced in this document are VMs that act as routers with IP forwarding enabled, not traditional firewalls, and are not intended to be enterprise-scale firewall NVAs. This solution is expected to help customers bridge the gap until co-engineered design patterns are available in all Azure regions.

Deploying NVAs can help address specific scenarios described below.

1. If you need to inspect traffic between your Oracle Database and other resources in Azure
2. If basic network support is not provided
3. Using resources with private endpoints
4. Resources in another Azure virtual network (VNet)
5. Services with delegated subnets
6. Connectivity with On-Premises

Additional details on supported network topologies can be found in the following articles: Network Planning for Oracle Database@Azure | Microsoft Learn

range

The scope of this article reviews network scenarios within the Azure Landing Zone that require NVAs. It includes the deployment steps for NVAs and other auxiliary steps required to complete an end-to-end implementation. The deployment steps for NVAs and other auxiliary steps required to complete an end-to-end implementation. This article does not cover hybrid connectivity from on-premises to Azure. That scenario will be covered in a later article, but both share the same approach of using User Defined Routes (UDRs).

Scenario Review

Azure Landing Zone is configured with a Hub and Spoke architecture, where the application tier is hosted in a Vnet dedicated to application front-end services such as web servers. Oracle Database@Azure is deployed in a separate, dedicated Vnet for data. Oracle Database@Azure is deployed in a separate, dedicated Vnet for data. The goal is to provide bidirectional network connectivity between the application tier and the data tier.

The following diagram outlines the scenario before implementation. The intention is to facilitate communication between the application layer and the data layer.

before

deployment

The steps provided in this document must be followed in the order specified to ensure the expected results. The steps provided in this document must be followed in the order specified to ensure the expected results. If you have specific questions regarding your environment, please contact your Microsoft or Oracle representative.

Environment Overview

• Hub VNet (10.0.0.0/16)
• Spoke 1 VNet – Application Tier (10.1.0.0/16)
• Application Server: 10.1.0.4
• Spoke 2 VNet – Oracle Database (10.2.0.0/16)
• Oracle DB Subnet: 10.2.0.0/24
• Oracle Database: 10.2.0.4
• Local NVA subnet: 10.2.1.0/24
• Local NVA: 10.2.1.4

memo: At the time of this publication, Azure Firewall currently supports only this scenario using NVAs. Third-party NVAs also require a custom NVA solution to support network communication.

Create a Linux VM with an NVA in Azure

Setting up a Linux VM Choose a deployment method for Oracle Database@Azure in your desired resource group and region (using any supported deployment on Azure, such as Azure Portal, Azure PowerShell, or Azure CLI). As a security recommendation, you should leverage Secure Shell (SSH) public/private keys to ensure secure communication.

Make sure the VMs are in the same Vnet. But it is on a separate subnet The same applies to the Oracle Database@Azure delegated subnet and, if deployed, the dedicated Oracle backup subnet.

memo: Sizing is largely determined by your actual traffic patterns. Consider the number of packets per second (volume) of traffic you need to support your implementation. Start with a 2-core general-purpose VM (D2s_v5 ​​with 2 vCPUs) and 8GiB (gibibytes) of memory with accelerated networking that you can use to measure initial performance. This use case does not require high storage/IOPS performance SKUs.

As part of your deployment and monitoring strategy, see: Welcome | Azure Monitor Baseline Alerts Learn about the appropriate Azure Monitor counters to enable for your NVAs to ensure performance and availability.

Enable IP forwarding on the VM’s NIC (Network Interface Card)

• Go to Networking NVA VM section in the Azure Portal
• Please select Network interface
• Below settingChoose IP configuration
• make possible IP forwarding
  

Enabling IP forwarding at the operating system level

• Run SSH into the VM.
• To enable IP forwarding, edit the sysctl configuration file. sudo nano /etc/sysctl.conf
• Uncomment the following lines: net.ipv4.ip_forward = 1
• Save and exit nano to apply the changes.
• To reset the network state to allow network traffic to pass without rebooting the VM, run the following command: Type sudo sysctl -p and press Enter. You will see the following line net.ipv4.ip_forward = 1 A message appears on the screen indicating that the changes have been applied successfully.

Make sure the local firewall on the NVA is not enabled or set to block traffic. You can simply check the firewall by running the following command: sudo iptables -L And hit Enter. This will list all possible firewall rules.

memo: If there is a rule, disable it with the following command. sudo iptables -F And hit Enter. To prevent the firewall from being accidentally activated, run the following command: sudo systemctl iptables disable And hit Enter.

Make sure the NVA has a Network Security Group (NSG). Allow all traffic from application Vnet and Oracle Database@Azure Delegated subnet.

Configuring the route table

Oracle Database@Azure Vnet (Spoke)

• Create a route table Specify a meaningful name in the Azure Portal in the same region and appropriate resource group (RG) where your Oracle Database@Azure is located.
• Add a route To the route table:
• Oracle Database Subnet: Associate this subnet with a route table.
• In the Oracle Database subnet: Set the next hop. 0.0.0.0/0 on local NVA VM.

important: Ensures that all route propagation is performed in the route table configuration. Disabled. This setting forces all traffic to and from the Oracle Database to run through the local NVA.

Configuring Route Tables for NVAs in Oracle Database @azure Vnet

• Create another route table Specify a meaningful name in the Azure Portal in the same region and appropriate resource group (RG) where your Oracle Database@Azure is located.
• Add a route To the route table:
• NVA Subnet: Associate this subnet with a route table.
• In the NVA subnet: Set the next hop. 0.0.0.0/0 on HUB NVA (10.0.0.4).

important: Ensures that all route propagation is performed in the route table configuration. Disabled. This setting forces all traffic to and from the Oracle Database to run through the local NVA.

Path Configuration Application Layer

On the way to Hub NVA

• Create another route table Specify a meaningful name in the Azure Portal in the same region and appropriate resource group (RG) where your Oracle Database@Azure is located.
• Application Subnet: Associate a route table to the application subnet in the application Vnet.
• Route in Application Vnet: Target: 10.2.0.0/24 (Oracle Database Subnet) Next Hop: 10.0.0.4 (Hub NVA)

important: Ensures that all route propagation is performed in the route table configuration. Disabled. This setting forces all traffic to and from the Oracle Database to run through the local NVA.

Route Configuration Hub VNet

Path to local NVA:

• Create another route table Specify a meaningful name in the Azure Portal in the same region and appropriate resource group (RG) where your Oracle Database@Azure is located.
• Firewall Subnet: Associate a route table to the firewall subnet in the hub Vnet.
• In the firewall subnet: Set the next hop 10.2.0.0/24 (Oracle subnet) to 10.2.1.4 (local NVA).
• If you have Cisco, Palo Alto, or other third-party NVAs, make sure they don’t have internal static routes that could conflict with your custom route tables in Azure.

important: Ensures that all route propagation is performed in the route table configuration. Disabled. This setting forces all traffic to and from the Oracle Database to run through the local NVA.

When complete, your implementation network flow and environment should match the following diagram.

test

The next step is to start testing by initiating a connection to the application server via the command line. If the application server is Linux, use MTR (My tracer route) A binary that traces traffic to a destination port without using Internet Control Message Protocol (ICMP) and name resolution, or tests connectivity by deploying a test VM on the application subnet.

An example of such a command is: sudo mtr -T -n -P 1521 102.0.4If the test is successful, you have implemented this solution correctly.

The second test is to install Oracle components on the application server to communicate with the database. Review the Oracle Instant Client content. Oracle Instant Client – Free tools and libraries for connecting to Oracle Database. Initiate a connection to the database from the application server. Verify that the application can connect to the database and read and write.

Next Steps

Visit the Microsoft Cloud Adoption Framework (CAF). Introduction to Oracle Adoption Scenarios on Azure – Cloud Adoption Framework | Microsoft Learn

author
Moises Gomez Cortez

Technical Editor and Content Contributor
Anthony de Lagarde, Eric Munson