Oracle Cloud Infrastructure Documentation

Network Setup for DB Systems

Note

This topic is not applicable to Exadata DB systems. For information on the network setup for an Exadata DB system, see Network Setup for Exadata DB Systems.

Before you set up a bare metal or virtual machine DB system, you must set up a virtual cloud network (VCN) and other Networking service components. This topic describes the recommended configuration for the VCN.

VCN and Subnets

To launch a DB system, you must have:

  • A VCN in the region where you want the DB system
  • At least one subnet in the VCN (either a A subnet in which instances are allowed to have public IP addresses. When you launch an instance in a public subnet, you specify whether the instance should have a public IP address. or a A subnet in which instances are not allowed to have public IP addresses)

In general, Oracle recommends using A subnet that spans all availability domains (ADs) in the region. Oracle recommends using regional subnets because they are more flexible and make it easier to implement failover across ADs. Compare with AD-specific subnets., which span all One or more isolated, fault-tolerant Oracle data centers that host cloud resources such as instances, volumes, and subnets. A region contains one or more availability domains. in the region. For a bare metal or virtual machine DB system, either a regional subnet or A subnet that is specific to a particular availability domain (AD). Historically all subnets were AD-specific. Compare with regional subnets, which Oracle recommends over AD-specific subnets. works. For more information, see About Regional Subnets.

You will create a custom Virtual route table for your VCN that provides mapping for the traffic from subnets via gateways to external destinations. and A list of virtual firewall rules for your VCN. Security lists consist of security rules that apply to traffic coming in and out of a VNIC. Security lists are configured at the subnet level, which means all VNICs in a given subnet are subject to the same security rules. for the subnet. More information follows about that.

Option 1: Public Subnet with Internet Gateway

This option can be useful when doing a proof-of-concept or development work. You can use this setup in production if you want to use an An optional virtual router that you can add to your VCN. It provides a path for network traffic between your VCN and the internet. with the VCN, or if you have services that run only on a public network and need access to the database. See the following diagram and description.

This image shows the network setup with a public subnet.

You set up:

Important

See this known issue for information about configuring route rules with service gateway as the target on route tables associated with public subnets.

Option 2: Private Subnet

This option is recommended for a production system. The subnet is private and cannot be reached from the internet. See the following diagram and description.

This image shows the network setup with a private subnet.

You set up:

Requirements for IP Address Space

If you're setting up DB systems (and thus VCNs) in more than one region, make sure the IP address space of the VCNs does not overlap.

The subnet you create for a bare metal or virtual machine DB system cannot overlap with 192.168.16.16/28, which is used by the Oracle Clusterware private interconnect on the database instance.

The following table lists the minimum required subnet size.

Tip

The Networking service reserves three IP addresses in each subnet. Allocating a larger space for the subnet than the minimum required (for example, at least /25 instead of /28) can reduce the relative impact of those reserved addresses on the subnet's available space.

DB System Type # Required IP Addresses Minimum Subnet Size
1-node bare metal or virtual machine

1 + 3 reserved in subnet = 4

/30 (4 IP addresses)
2-node RAC virtual machine (2 addresses * 2 nodes) + 3 for SCANs + 3 reserved in subnet = 10 /28 (16 IP addresses)

VCN Creation Wizard: Not for Production

The Networking section of the Console includes a handy wizard that creates a VCN along with related resources. It can be useful if you just want to try launching an instance. However, the wizard automatically chooses the address ranges and creates public subnets and an internet gateway. You may not want this for your production network, so Oracle recommends you create the VCN and other resources individually yourself instead of using the wizard.

DNS for a Bare Metal DB System

For a bare metal DB system, you must ensure that the system can resolve the Swift endpoints (for backing up databases, patching, and updating the DB system's cloud tooling) and Oracle YUM repo endpoints. Resolution of these endpoints is automatically covered by the Internet and VCN Resolver, which is the VCN's default choice for DNS in the VCN. For more information, see DNS in Your Virtual Cloud Network and also DHCP Options.

DNS for a Virtual Machine DB System

This information is applicable to 1-node or 2-node virtual machine DB systems.

For the node or nodes to communicate, the VCN must use the Internet and VCN Resolver. It enables hostname assignment to the nodes, and DNS resolution of those hostnames by resources in the VCN. It also enables resolution of the database's Single Client Access Names (SCANs). Lastly, it also enables resolution of the Swift endpoints and Oracle YUM repo endpoints. The Internet and VCN Resolver is the VCN's default choice for DNS in the VCN. For more information, see DNS in Your Virtual Cloud Network and also DHCP Options.

When you create the VCN, subnet, and DB system, you must carefully set the following identifiers, which are related to DNS in the VCN:

  • VCN domain label
  • Subnet domain label
  • Hostname prefix for the DB system

These values make up the node's fully qualified domain name (FQDN):

<hostname_prefix><RAC_node_#>.<subnet_domain_label>.<vcn_domain_label>.oraclevcn.com

For RAC systems only, the Database service automatically appends a node number after the hostname prefix.

For example:

  • Node 1: dbsys1.ad1.acmevcniad.oraclevcn.com
  • Node 2: dbsys2.ad1.acmevcniad.oraclevcn.com

Requirement for the hostname prefix:

  • Maximum 16 characters
  • Cannot be the string localhost

Requirements for the VCN and subnet domain labels:

  • Recommended maximum: 15 characters
  • No hyphens
  • Recommended: include the region name in the VCN's name, and include the availability domain name in the subnet's name

The FQDN has a maximum total limit of 63 characters, so make sure you set the VCN and subnet domain labels short enough to meet that requirement. Here is a safe general rule:

<16_chars_max>#.<15_chars_max>.<15_chars_max>.oraclevcn.com

The preceding maximums are not enforced when you create the VCN and subnets. However, the DB system deployment fails if the hostname prefix is greater than 16 characters or if the FQDN has more than 63 characters.

DNS: Between On-Premises Network and VCN

To enable the use of hostnames when on-premises hosts and VCN resources communicate with each other, you have two options:

  • Set up an instance in the VCN to be a custom DNS server. For an example of an implementation of this scenario with the Oracle Terraform provider, see Hybrid DNS Configuration.
  • Manage hostname resolution yourself manually.

Service Gateway for the VCN

Your VCN needs access to both Object Storage (for backing up databases, patching, and updating the cloud tooling on a DB system) and Oracle YUM repos for OS updates.

Depending on whether you use option 1 or option 2 described previously, you use the service gateway in different ways. See the next two sections.

Option 1: Service Gateway Access Only to Object Storage
Option 2: Service Gateway Access to Both Object Storage and YUM Repos

Security Lists for the Subnet

Oracle recommends that you use at least two security lists with the subnet:

  • VCN's default security list (with all its default rules). This security list contains several basic rules that are necessary for the DB system (such as ingress SSH access to the DB system, and general egress from the DB system).
  • Custom security list with the rules in the next section.

You must create the custom security list yourself. The VCN's default security list is automatically created when you create the VCN. When you create a subnet, you can choose which security lists the subnets will use, or you can choose the security lists after the subnet is created.

Warning

Do not remove the default egress rule from the default security list. If you do, make sure to instead include a replacement egress rule in the subnet's custom security list, like so:

  • Stateless: No (all rules must be stateful)
  • Destination Type: CIDR
  • Destination CIDR: 0.0.0.0/0
  • IP Protocol: All

Rules for the Custom Security List

Create the following security list rules in the subnet's custom security list and associate the security list with the subnet.

Ingress rule 1: Allows inbound SSH access
Ingress rule 2: Allows ONS and FAN traffic from within the VCN
Ingress rule 3: Allows SQL*NET traffic from within the VCN

Important

The preceding ingress rules 2 and 3 only cover connections initiated from within the VCN. If you have a client that resides outside the VCN, Oracle recommends setting up two additional similar rules that instead have the Source CIDR set to the public IP address of the client.

Egress rule 1: Allows outbound SSH access
Egress rule 2: Allows access to Object Storage and YUM repos