Creating a Local Network Virtual Appliance in Azure for Oracle Database@Azure

[Guest adelagarde]

Oracle Database@Azure is an Oracle database service running on Oracle Cloud Infrastructure (OCI), collocated in Microsoft data centers. This ensures that the Oracle Database@Azure service has the fastest possible access to Azure resources and applications. The solution is intended to support the migration of Oracle database workloads to Azure, where customers can integrate and innovate with the breadth of Microsoft Cloud services.

 

 

 

For more information and to gain a better understanding of Oracle Database@Azure please visit Overview - Oracle Database@Azure | Microsoft Learn

 

 

 

[HEADING=1]Problem Statement[/HEADING]

 

The current Oracle Database@Azure service has a network limitation where it cannot respond to network connections outside of its Azure virtual network ( VNet ). This limitation places constraints on extending integration to Azure services not located within the same Vnet. This issue also impacts network communication from on-premises that need to connect to the Oracle Database@Azure.

 

 

 

The solution is to leverage the deployment of a Network Virtual Appliance (NVA) within the Oracle Database@Azure VNet to overcome this network limitation. Microsoft and Oracle have collaborated on developing a design pattern to eliminate this network limitation, but for customers who are deploying to Azure regions where this pattern is not yet available, customers will have to deploy an NVA.

 

 

 

[HEADING=1]Deploying an NVA[/HEADING]

 

The NVA consists of a Linux virtual machine (VM) and any supported distribution on Azure can be used. The NVA referenced in this article is not a traditional firewall, but a VM acting as a router with IP forwarding enabled and not intended to be an enterprise-scale Firewall NVA. This solution is only expected to help customers bridge the gap until the jointly engineered design pattern is available in all Azure regions.

 

The deployment of the NVA helps solve the specific scenarios outlined below:

 

 

 

1. where traffic inspection is required between Oracle Database on Azure and other resources
   
2. where native network support is not available
   
3. with resources that have private endpoints
   
4. resources on another Azure virtual network (VNet)
   
5. services with delegated subnets
   
6. connectivity with on-premises
   

 

Additional details on supported network topologies can be found within the following article Network planning for Oracle Database@Azure | Microsoft Learn

 

 

 

[HEADING=1]Scope[/HEADING]

 

This article's scope will review a network scenario within an Azure Landing Zone requiring an NVA. The deployment steps of the NVA and other ancillary steps required to complete the end-to-end implementation are included. The deployment steps of the NVA and other ancillary steps required to complete the end-to-end implementation. This article does not cover the hybrid connectivity from on-premises to Azure. That scenario will be covered in a later article; however, both share the same method of using User Defined Routes (UDR) .

 

 

[HEADING=1]Scenario Review[/HEADING]

 

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

 

 

 

The following diagram is an overview of the scenario prior to implementation. The intent is to facilitate communication between the application layer and the data layer.

 

 

 

[ATTACH type=full" alt="Before]62732[/ATTACH]Before

 

 

 

 

 

[HEADING=1] [/HEADING]

[HEADING=1]Deployment[/HEADING]

 

The steps provided in this article should be followed in the designated order to ensure the expected results. The steps provided in this article should be followed in the designated order to ensure the correct expected results. Please consult with either your Microsoft or Oracle representative if you have specific questions related to your environment.

 

[HEADING=2] [/HEADING]

[HEADING=2]Environment Overview[/HEADING]

• Hub VNet (10.0.0.0/16)
  
  • Hub NVA: 10.0.0.4
    

  [*]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
    

 

Note: At the time this article was published, Azure Firewall is currently only supported by this scenario using an NVA. Third-party NVA’s also require the custom NVA solution to support network communication.

 

 

 

Create a Linux VM in Azure as an NVA

 

Set up a Linux VM (using any supported distributions on Azure) in the desired resource group and region as the Oracle Database@Azure using your deployment method of choice (for example Azure portal, Azure PowerShell, or Azure CLI). As a security recommendation, be sure to leverage Secure Shell (SSH) public/private keys to ensure secure communication.

 

Ensure the VM is in the same Vnet, but on a separate subnet from the Oracle Database@Azure delegated subnet as well as the dedicated Oracle backup subnet if it has been deployed

 

 

 

Note: Sizing is very much driven by the actual traffic pattern. Consider how much traffic (volume) packets per second are required to support the implementation. Starting with a 2-core general-purpose VM (D2s_v5 with 2 vCPUs) and 8 GiB (gibibytes) of memory including accelerated networking which can be used to gauge initial performance. High storage/IOPS performance SKUs are not necessary for this use case.

 

 

 

As part of the deployment and monitoring strategy please consult Welcome | Azure Monitor Baseline Alerts for the proper Azure Monitor counters that should be enabled against the NVA to ensure performance and availability.

 

 

 

Enable IP Forwarding on the VM's NIC (Network Interface Cards)

 

• Go to the Networking section of the NVA VM in the Azure portal
  
• Select the Network Interface
  
• Under Settings, choose IP configurations
  
• Enable IP forwarding
  

 

 

 

Enable IP Forwarding at the Operating System level

 

• SSH into the VM.
  
• Edit the sysctl configuration file to enable IP forwarding: sudo nano /etc/sysctl.conf
  
• Uncomment the following line: net.ipv4.ip_forward = 1
  
• Save and exit out of nano to apply the changes
  
• Run the following command to reset the network status to forward network traffic without a reboot on the VM: sudo sysctl -p and hit enter. You should see the following line net.ipv4.ip_forward = 1 will appear on the screen indicating the changes were made successfully.
  

 

Ensure that the local firewall on the NVA is not enabled or set to block traffic. This can be done with a simple check on the firewall by running the following command sudo iptables -L and hit enter. This will list any possible firewall rules.

 

 

 

Note: If there are rules disable them with the following command sudo iptables -F and hit enter. To ensure that the firewall is not enabled by accident run the following command sudo systemctl disable iptables and hit enter.

 

 

 

Ensure that the Network Security Group (NSG) on the NVA is allowing all traffic from the application Vnet and the Oracle Database@Azure delegated subnet.

 

 

 

 

 

Configure Route Tables

 

 

 

Oracle Database@Azure Vnet (Spoke)

 

• Create a route table in the Azure portal in the same region and proper resource group (RG) where the Oracle Database@Azure is located. Give it a meaningful name.
  
• Add routes to the route table:
  
• Oracle Database Subnet: Associate the route table with this subnet.
  
• From Oracle Database Subnet: Set the next hop for 0.0.0.0/0 to the local NVA VM.
  

 

Important: Ensure in the configuration of the route table that all route propagation is disabled. This setup ensures that all traffic to and from the Oracle Database is forced through your local NVA.

 

 

 

Configure Route Tables for the NVA in the Oracle Database @azure Vnet

 

• Create another route table in the Azure portal in the same region and proper resource group (RG) where the Oracle Database@Azure is located. Give it a meaningful name.
  
• Add routes to the route table:
  
• NVA Subnet: Associate the route table with this subnet.
  
• From NVA Subnet: Set the next hop for 0.0.0.0/0 to the HUB NVA (10.0.0.4).
  

 

Important: Ensure in the configuration of the route table that all route propagation is disabled. This setup ensures that all traffic to and from the Oracle Database is forced through your local NVA.

 

 

 

Route Configuration Application Tier

 

 

 

Route to Hub NVA

 

• Create another route table in the Azure portal in the same region and proper resource group (RG) where the Oracle Database@Azure is located. Give it a meaningful name.
  
• Application Subnet: Attach the route table to the Application Subnet in the application Vnet.
  
• Route from Application Vnet: Destination: 10.2.0.0/24 (Oracle Database Subnet) Next Hop: 10.0.0.4 (Hub NVA)
  

 

Important: Ensure in the configuration of the route table that all route propagation is disabled. This setup ensures that all traffic to and from the Oracle Database is forced through your local NVA.

 

 

 

Route Configuration Hub VNet

 

 

 

Route to Local NVA:

 

• Create another route table in the Azure portal in the same region and proper resource group (RG) where the Oracle Database@Azure is located. Give it a meaningful name.
  
• Firewall Subnet: Attach the route table to the Firewall Subnet in the Hub Vnet.
  
• From Firewall Subnet: Set the next hop 10.2.0.0/24 (Oracle Subnet) to 10.2.1.4 (Local NVA)
  
• Please ensure if you have a Cisco or Palo Alto or other third-party NVA’s that there are no internal static routes that may conflict with the custom route table from Azure.
  

 

Important: Ensure in the configuration of the route table that all route propagation is disabled. This setup ensures that all traffic to and from the Oracle Database is forced through your local NVA.

 

 

 

When finished the implementation network flow and environment should match the following diagram:

 

 

 

[ATTACH type=full" alt="After.png]62733[/ATTACH]

 

 

 

[HEADING=2]Testing[/HEADING]

 

The next step is to start testing by initiating a connection from the application servers via command line. If the application servers are Linux, install the MTR (My traceroute) binary to trace the traffic to the destination port without using Internet Control Message Protocol (ICMP) and name resolution or deploy a test vm on the application subnet to test connectivity.

 

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

 

 

 

The second test is to install the Oracle components on the application servers to communicate with the database. Please review the Oracle Instant Client content Oracle Instant Client - Free tools and libraries for connecting to Oracle Database. Initiate a connection from the application server to the database. Ensure that the application can connect, read, and write to the database.

 

 

[HEADING=2]Next Steps[/HEADING]

 

Please visit the Microsoft Cloud Adoption Framework (CAF ) Introduction to Oracle on Azure adoption scenarios - Cloud Adoption Framework | Microsoft Learn

 

 

 

Authors

Moises Gomez Cortez

 

Technical Editor and Content Contributor

Anthony de Lagarde, Erik Munson

 

Continue reading...