ODB Network Design
Learn about Oracle Database@Google Cloud ODB Network requirements and find reference information for network design.
The ODB network creates a metadata construct for the Google Virtual Private Cloud (VPC), facilitating database provisioning. It supports Standalone VPC and Shared VPC by centralizing network configurations such as subnets and routing, enabling independent management of connectivity. The ODB Network connects Oracle Database@Google Cloud resources in the Oracle Cloud Infrastructure (OCI) to the Google Cloud VPC, mapping OCI network resources back to Google Cloud. Upon creating an ODB Network, essential components such as the Virtual Cloud Network (VCN) and subnets are provisioned automatically, while other elements for private connection are created during deployment. Users can also create up to five ODB Subnets within an ODB Network for better network management.
ODB Networks allows network administrators to manage network activities while database administrators handle database administration tasks.
When creating a new ODB network, a network administrator associates the ODB network with an existing VPC (standalone or shared) in the selected Project and region.
Network administrators can create up to 5 non-overlapping subnets in the ODB Network. The CIDR ranges used for ODB Subnets must not conflict with any existing CIDR ranges used by the selected VPC.
The following sections describe the Client Subnet and the Backup Subnet requirements.
Client Subnet 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@Google Cloud services and the infrastructure components for the client subnet CIDR:
Subnet CIDR requirements
| Number of IP addresses | Consumed by | Summary |
|---|---|---|
| 3 | Oracle Database@Google Cloud Network service |
These IP addresses are reserved regardless of how many VM clusters you provision in the Client Subnet. Oracle Database@Google Cloud consumes the following:
|
| 3 | Each VM cluster | Each VM cluster requires 3 IP addresses for Single Client Access Names (SCANs), regardless of how many virtual machines are present in the VM cluster. |
| 4 | Each VM | 4 IP addresses are needed for each virtual machine. VM clusters have a minimum of 2 virtual machines. Therefore, a VM cluster with 2 virtual machines requires 8 IP addresses in the Client Subnet. Each extra virtual machine added to a VM cluster increases the number of IP addresses needed in the Client Subnet by 4 IPs. |
| 1 | Oracle Autonomous Database | Each Oracle Autonomous Database instance consumes 1 IP address |
| 1 | Each VM for Base Database | Each VM created consumes 1 IP address for database |
Backup Subnet 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@Google Cloud and the infrastructure components for the backup CIDR:
Backup Subnet CIDR Requirements
| Number of IP addresses | Consumed by | Summary |
|---|---|---|
| 3 | Oracle Database@Google Cloud Network service |
These IP addresses are reserved regardless of how many VM clusters you provision in the Backup Subnet. Oracle Database@Google Cloud consumes the following:
|
| 3 | Each VM | VM clusters have a minimum of 2 virtual machines. Therefore, a VM cluster with 2 virtual machines requires 6 IP addresses in the backup subnet. Each additional virtual machine added to a VM cluster increases the number of IP addresses needed in the Backup Subnet by 3 IPs. |
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 | 14 (3 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 | 18 (3 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 | 22 (3 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 | 38 (3 service + 3 cluster + 4*8 VM) | /26 CIDR range, 64 IPs | 27 (3 services + 3*8 VM) | /27 CIDR range, 32 IPs |
| 1 Autonomous Database | 4 (3 service + 1 Instance) | /27 CIDR range, 32 IPs | Not Applicable | Not Applicable |
| 1 VM for Base Database | 4 (3 service + 1 VM) | /27 CIDR range, 32 IPs | Not Applicable | Not Applicable |
VM Cluster Scenarios
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.
Client Subnet CIDR 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 + 3 Networking = 14) | 2 | 5 | 11 | 23 | 46 | 93 |
| 1 VM cluster with 3 virtual machines (15 IPs + 3 Networking = 18) | 2 | 4 | 8 | 17 | 34 | 68 |
| 1 VM cluster with 4 virtual machines (19 IPs + 3 Networking = 22) | 1 | 3 | 6 | 13 | 26 | 53 |
| 2 VM clusters with 2 virtual machines each (22 IPs + 3 Networking = 25) | 1 | 2 | 5 | 11 | 23 | 46 |
| 2 VM clusters with 3 virtual machines each (30 IPs + 3 Networking = 33) | 1 | 2 | 4 | 8 | 17 | 34 |
| 2 VM clusters with 4 virtual machines each (38 IPs + 3 Networking = 41) | 0 | 1 | 3 | 6 | 13 | 26 |
VM Cluster Scenarios: Backup Subnet CIDR
The following table shows scenarios of provisioned VM clusters of differing sizes. The number of each scenario that can fit in a backup subnet depends on the CIDR size used by the subnet. This table doesn't show all possible scenarios.
Backup Subnet CIDR 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 (6 IPs) | 2 | 5 | 10 | 25 | 42 | 85 |
| 1 VM cluster with 3 virtual machines (9 IPs) | 1 | 3 | 7 | 14 | 28 | 56 |
| 1 VM cluster with 4 virtual machines (12 IPs) | 1 | 2 | 5 | 10 | 21 | 42 |
| 2 VM clusters with 2 virtual machines each (12 IPs) | 1 | 2 | 5 | 10 | 21 | 42 |
| 2 VM clusters with 3 virtual machines each (18 IPs) | 1 | 3 | 7 | 14 | 28 | |
| 2 VM clusters with 4 virtual machines each (24 IPs) | 1 | 2 | 5 | 10 | 21 |
Plan for IP Address Space in Oracle Database@Google Cloud
Note the following points when setting up networking:
- IP address ranges allocated to Autonomous 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@Google Cloud.
- For Exadata X9M, and X11M IP addresses 100.64.0.0/10 are reserved for the cluster interconnect by OCI automation, and can't be allocated to client or backup networks.
- CIDR for Client and Backup subnet must be part of the RFC1918 range - 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16.