Delegated Subnet Design
Learn about Oracle Database@Azure's Delegate Subnet requirements and find reference information for network design.
A Delegate Subnet is a dedicated, isolated subnet within your Azure Virtual Network (VNet) that hosts the Oracle Exadata VM Clusters and Autonomous VM Clusters within a specified Azure region. The Delegate Subnet consists of a CIDR range of IP addresses that you define. This subnet is delegated to the Oracle Database@Azure service, which allows the service to inject its own resources, like the Exadata Infrastructure, directly into your VNet. This delegation serves as the means of communication between your Azure environment and the co-located Oracle Cloud Infrastructure (OCI). In the Oracle Multicloud architecture, the Delegate Subnet is designed to accommodate and provide network connectivity for the OCI components that are part of Oracle Database@Azure.
The Delegate Subnet exists within your private Azure VNet. By virtue of being part of your VNet, it can leverage Azure's networking capabilities, such as Network Security Groups (NSGs) and routing tables, to control traffic. Communication between your applications in other subnets and the Oracle Database in the Delegate Subnet is routed privately over the Azure backbone network. This ensures that sensitive database traffic between your applications and the database doesn't traverse the public internet.
The Oracle Database@Azure service requires a client subnet CIDR for the creation of Exadata VM Clusters and Autonomous VM Clusters. This client subnet facilitates the application-to-database connections. The service also requires a backup subnet CIDR during Exadata VM Cluster creation. This is used to route traffic for Oracle-managed backups from the Exadata Database Service to the specified backup destination.
The following section describes the CIDR requirements and planning required when creating the Delegated Subnet.
Client Subnet CIDR Requirements
The minimum CIDR size for the client subnet is /27, and the maximum size is /22. The following table shows IP addresses consumed by the Oracle Database@Azure services and the infrastructure components for the client subnet CIDR:
| Number of IP Addresses | Consumed By | Summary |
|---|---|---|
| 13 | Oracle Database@Azure Networking services |
These IP addresses are reserved regardless of how many VM cluster you provision in the Client Subnet. Oracle Database@Azure consumes the following (for example consider 10.0.0.0/24 subnet CIDR):
|
| 3 | Each VM cluster (Exadata or Exascale) | These IP addresses are reserved for Single Client Access Names (SCANs) regardless of how many VMs are present in each VM cluster. |
| 4 | Each VM (Exadata or Exascale) | Each VM created consumes 4 IP addresses. |
| 1 | Each VM for Base Database | Each VM created consumes up to 3 IP addresses 1 IP address for database, 1 IP address for DNS Listening Endpoint and 1. |
| 2 | DNS | If enabled during Network Anchor creation, DNS Listening and DNS Forwarding Endpoints will consume 1 IP address each. |
Backup Subnet CIDR Requirements
The minimum CIDR size for the backup subnet is /27, and the maximum size is /22. The following table shows IP addresses consumed by the Oracle Database@Azure and the infrastructure components for the backup CIDR:
| Number of IP Addresses | Consumed By | Summary |
|---|---|---|
| 3 | Oracle Database@Azure Networking services |
These IP addresses are reserved regardless of how many VM clusters you provision in the Backup Subnet. Oracle Database@Azure consumes the following:
|
| 3 | Each VM (Exadata) | Each VM created consumes 3 IP addresses |
IP Consumption Scenarios
The following table explains how IP addresses are consumed in the Delegated subnet for various VM clusters configurations. Though /27 is the minimum CIDR range for the client subnet CIDR to deploy 1 VM cluster with 2 VMs, we recommend that you use at least a /24 CIDR range for future expansion.
| Configuration | Client subnet IPs Consumed | Client Subnet Minimum CIDR | Backup Subnet IPs consumed | Backup Subnet minimum CIDR |
|---|---|---|---|---|
| 1 VM cluster with 2 VMs | 24 (13 service + 3 cluster + 4*2 VM) | /27 CIDR range, 32 IPs | 9 (3 services + 3*2 VM) | /28 CIDR range, 16 IPs |
| 1 VM cluster with 3 VMs | 28 (13 service + 3 cluster + 4*3 VM) | /27 CIDR range, 32 IPs | 12 (3 services + 3*3 VM) | /28 CIDR range, 16 IPs |
| 1 VM cluster with 4 VMs | 32 (13 service + 3 cluster + 4*4 VM) | /27 CIDR range, 32 IPs | 15 (3 services + 3*4 VM) | /28 CIDR range, 16 IPs |
| 1 VM cluster with 8 VMs | 48 (13 service + 3 cluster + 4*8 VM) | /26 CIDR range, 64 IPs | 27 (3 services + 3*8 VM) | /27 CIDR range, 32 IPs |
| 1 VM for Base Database without enabling DNS | 14 (13 service + 1 VM) | /27 CIDR range, 32 IPs | Not Applicable | Not Applicable |
| 1 VM for Base Database with DNS enabled | 16 (13 service + 1 VM + 1 Listening Endpoint + 1 Forwarding Endpoint) | /27 CIDR range, 32 IPs | Not Applicable | Not Applicable |
VM Cluster Scenarios: Client Subnet CIDR
The following table shows how many instances of each configuration are possible with a particular client subnet CIDR range. This table doesn't show all possible scenarios.
| Scenario (VM Cluster configuration) | Number of VM Clusters with /27 (32 IPs) | Number of VM Clusters with /26 (64 IPs) | Number of VM Clusters with /25 (128 IPs) | Number of VM Clusters with /24 (256 IPs) | Number of VM Clusters with /23 (512 IPs) | Number of VM Clusters with /22 (1024 IPs) |
|---|---|---|---|---|---|---|
| 1 VM cluster with 2 virtual machines (11 IPs + 13 Networking = 24) | 1 | 4 | 10 | 22 | 45 | 91 |
| 1 VM cluster with 3 virtual machines (15 IPs + 13 Networking = 28 | 1 | 3 | 7 | 16 | 33 | 67 |
| 1 VM cluster with 4 virtual machines (19 IPs + 13 Networking = 32) | 1 | 2 | 6 | 12 | 26 | 53 |
| 2 VM clusters with 2 virtual machines each (22 IPs + 13 Networking = 34) | 0 | 2 | 5 | 11 | 22 | 45 |
| 2 VM clusters with 3 virtual machines each (30 IPs + 13 Networking = 43) | 0 | 1 | 3 | 8 | 16 | 33 |
| 2 VM clusters with 4 virtual machines each (38 IPs + 13 Networking = 51) | 0 | 1 | 3 | 6 | 13 | 26 |
| Base Database without enabling DNS | 19 | 51 | 115 | 243 | 499 | 1011 |
| Base Database with both DNS Listening and Forwarding Endpoint enabled | 17 | 49 | 113 | 241 | 497 | 1009 |
VM Cluster Scenarios: Backup Subnet CIDR
The following table shows how many instances of each configuration are possible with a particular backup subnet CIDR range. This table doesn't show all possible scenarios.
| Scenario (VM Cluster configuration) | Number of VM Clusters with /27 (32 IPs) | Number of VM Clusters with /26 (64 IPs) | Number of VM Clusters with /25 (128 IPs) | Number of VM Clusters with /24 (256 IPs) | Number of VM Clusters with /23 (512 IPs) | Number of VM Clusters with /22 (1024 IPs) |
|---|---|---|---|---|---|---|
| 1 VM Cluster with 2 VMs (9 IPs) | 3 | 7 | 14 | 28 | 56 | 113 |
| 1 VM Cluster with 3 VMs (12 IPs) | 2 | 5 | 10 | 21 | 42 | 85 |
| 1 VM Cluster with 4 VMs (15 IPs) | 2 | 4 | 8 | 17 | 34 | 68 |
| 2 VM Cluster with 2 VMs each (15 IPs) | 2 | 4 | 8 | 17 | 34 | 68 |
| 2 VM Cluster with 3 VMs each (21 IPs) | 1 | 3 | 6 | 12 | 24 | 48 |
| 2 VM Cluster with 4 VMs each (27 IPs) | 1 | 2 | 7 | 9 | 18 | 37 |
Restrictions for IP Addresses
The following restrictions apply for the CIDR range of the Delegated subnets:
- Valid private IPv4 CIDR ranges required: The CIDR block must be private and IPv4. For example, 10.0.0.0/16, 172.16.0.0/16, 192.168.1.0/26.
- For Exadata X9M, and X11M, IP addresses 100.64.0.0/10 are reserved, and should not be used for the client or backup VCNs as well as database clients.
- IP address ranges allocated to Autonomous AI Database and Exadata VM clusters must not overlap with other CIDRs in use, as this might cause routing issues. Take cross-region routing into consideration when configuring CIDRs for Oracle Database@Azure.