Network topology and connectivity for Oracle Database@Azure
This article builds on several considerations and recommendations that are defined in the Azure landing zone design area for network topology and connectivity. It provides key design considerations and recommendations for Oracle Database@Azure networking and connectivity.
Design considerations
Consider the following guidance when you design your network topology for Oracle Database@Azure:
You can physically place the Oracle Database@Azure service in Azure datacenters or in an Azure availability zone. Availability zones are subscription-specific, which affects network latency and resiliency. For instance, an availability zone doesn't necessarily have the same physical datacenter from one subscription to another subscription. For more information, see What are availability zones?.
Every Oracle Database@Azure SKU can have up to eight virtual machine (VM) clusters. You must have a virtual network before you create a VM cluster. You can connect VM clusters to either the same virtual network or to different virtual networks.
The Oracle Database@Azure service deploys to private subnets in Azure and isn't immediately accessible from the internet.
The minimum size subnet that you need for the Oracle Database@Azure service depends on the SKU that you use. For more information, see Network setup for Exadata Cloud Infrastructure instances.
Unlike regular subnets, subnets that you delegate to the Oracle Database@Azure solution have constraints. For more information, see Network planning for Oracle Database@Azure.
Database nodes don't have a default name registration or resolution because Oracle Database@Azure runs only in private subnets.
Design recommendations
Consider the following recommendations when you design your network topology for Oracle Database@Azure:
Don't route traffic between the application and database subnets by using Azure network virtual appliances (NVAs), firewalls (such as Azure Firewall), Azure Virtual WAN hub, or partner NVAs. This configuration adds network latency. Instead, you can use direct communication between subnets within the same virtual network for efficient traffic flow. If the application and database subnets are in different virtual networks, use direct virtual network peering instead of transitive routing through the hub.
Colocate the application portfolio and database services in the same virtual network if you have a limited number of databases that service a limited application portfolio that's managed by a single team. Colocation reduces latency and simplifies the network design.
Treat the Oracle Database@Azure solution as a dedicated service if you have multiple databases that service different applications that are managed by different teams. Deploy the Oracle Database@Azure solution in one or more dedicated subscriptions. Deploy the application solutions in separate subscriptions and use virtual network peering to connect the application networks to the database networks. Use this configuration to manage the application and database subnets independently.
Ensure that you place application and database components in the same region and availability zone to reduce latency between your application and database. If your application components are in different subscriptions from your database components, see Physical and logical availability zones. Use the
AvailabilityZoneMappingsproperty to identify the specific physical availability zone for colocating the services.Oracle Database@Azure subnets don't support Azure network security groups (NSGs). Instead, use the Oracle Cloud NSG that gets created in the Oracle Database@Azure OCI Virtual Cloud Network (VCN) to control traffic to and from the Exadata/ADBS system.
Use Azure private DNS zones for name resolution between application and database subnets. For more information, see Private DNS.
The following example network topology is for a complex application portfolio that's served by a single or multiple databases.
