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 Cloud Service Instances.

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 public subnet  or a private subnet )

In general, Oracle recommends using regional subnets , which span all availability domains  in the region. For a bare metal or virtual machine DB system, either a regional subnet or AD-specific subnet  works. For more information, see Overview of VCNs and Subnets.

You will create a custom route table . You will also create security rules  to control traffic to and from the DB system's compute notes. More information follows about that.

Certain details of the VCN and subnet configuration depend on your choice for DNS resolution within the VCN. For more information, see DNS for the DB System.

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 internet gateway  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

Oracle recommends this option 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 are 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 creates a public subnet 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 the DB System

There are two choices for DNS and hostname resolution for the DB system:

  • Recommended: Use the default DNS functionality in the VCN (called the Internet and VCN Resolver)
  • Use a custom DNS resolver of your choice

The following table shows which choices are supported with each type of DB system, and the endpoints that need to be resolved for the DB system to function.

DB System Type Supported DNS Choices Endpoints to Be Resolved
1-node bare metal or virtual machine
  • Recommended: Default (Internet and VCN Resolver)
  • Custom DNS resolver of your choice
  • Object Storage endpoints (includes both the Object Storage endpoints and Swift endpoints)
  • Oracle YUM repo endpoints
2-node RAC virtual machine
  • Default (Internet and VCN Resolver)

The following sections give more details about the DNS choices.

Default (Internet and VCN Resolver)

See the preceding table for the types of DB systems that support the Internet and VCN Resolver.

Oracle recommends using the Internet and VCN Resolver for DNS. It's the default, built-in DNS functionality that comes with each VCN. It enables hosts in a VCN to resolve these items:

  • Hostnames of other hosts in the same VCN
  • Hostnames that are publicly published on the Internet

For general information about the Internet and VCN Resolver, see DNS in Your Virtual Cloud Network.

For a DB system, the Internet and VCN Resolver handles resolution of all necessary endpoints: Object Storage endpoints (includes both the Object Storage endpoints and Swift endpoints), YUM repos, and SCANs (SCANs are used only with 2-node RAC systems).

By default, each VCN is configured to use the Internet and VCN Resolver. If you plan to use a custom DNS resolver, you must configure the VCN in a different way. For more information, see To use a custom DNS resolver with your DB system.

To use the Internet and VCN Resolver with your DB System

As part of the overall network setup, perform these tasks:

  1. Create the VCN with the required DNS settings:

  2. Create each subnet with the required DNS settings:

  3. Use the default set of DHCP options that come with the VCN:

    • When creating each subnet, configure it to use the VCN's default set of DHCP options.
    • By default, the default set of DHCP options is configured to use the Internet and VCN Resolver.
  4. Create the DB system with a hostname prefix:

The resulting DB system has a fully qualified domain name (FQDN) based on the hostname prefix, VCN label, and subnet label you specify.

Hostname restrictions for using the Internet and VCN Resolver

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 DNS label
  • Subnet DNS label
  • Hostname prefix for the DB system

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

<hostname_prefix><RAC_node_#>.<subnet_DNS_label>.<VCN_DNS_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 DB system's hostname prefix:

  • Maximum 16 characters, otherwise the DB system deployment will fail.
  • Cannot be the string localhost.

Requirements for the VCN and subnet DNS labels:

  • Recommended maximum: 15 characters.
  • No hyphens or underscores.
  • 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 set the VCN and subnet DNS 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 recommended maximums are not enforced when you create the VCN and subnets. However, the DB system deployment fails if the FQDN has more than 63 characters.

Custom DNS Resolver

See the preceding table for the types of DB systems that support the use of a custom DNS resolver.

A custom DNS resolver is a DNS server that you set up in your on-premises network and maintain yourself. It must resolve the endpoints required by the DB system.

By default, the VCN is configured to use the Internet and VCN Resolver. Therefore, if you instead want to use a custom DNS resolver, you must configure the VCN and DHCP options in a different way. See the following process.

To use a custom DNS resolver with your DB system

As part of the overall network setup, perform these tasks:

  1. Create the VCN with the recommended DNS settings:

    • When creating the VCN, Oracle recommends that you select the check box for Use DNS Hostnames in this VCN and then specify a DNS label for the VCN. See the restrictions listed in Hostname restrictions when using a custom DNS resolver.
    • Notice that you cannot change the preceding VCN DNS settings after you create the VCN. They are optional for a custom DNS server, but required if you use the Internet and VCN Resolver. Therefore, Oracle recommends that you configure them now in case you later want to use the Internet and VCN Resolver.
  2. Create each subnet with the recommended DNS settings:

    • When creating a subnet in the VCN, Oracle recommends that you select select the check box for Use DNS Hostnames in this Subnet and then specify a DNS label for the subnet. See the restrictions listed in Hostname restrictions when using a custom DNS resolver.
    • Notice that you cannot change the preceding subnet DNS settings after you create the subnet. They are optional for a custom DNS server, but required if you use the Internet and VCN Resolver. Therefore, Oracle recommends that you configure them now in case you later want to use the Internet and VCN Resolver.
  3. Edit the default set of DHCP options to use a custom resolver:

    • When creating each subnet, configure it to use the VCN's default set of DHCP options.
    • Edit the default set of DHCP options so that DNS Type is set to Custom Resolver. Provide the IP address for at least one DNS server (maximum three). Optionally provide a single search domain (which will automatically be added to the host's /etc/resolv.conf file).
  4. Create the DB system with required DNS entries:

    • Later, when creating the DB system, specify a Hostname Prefix.
    • For the Host Domain Name: If you selected the check box for Use DNS Hostnames in the preceding steps, the Host Domain Name is automatically generated from the VCN and subnet DNS labels. Otherwise, you must provide a value for the Host Domain Name. See the restrictions listed in Hostname restrictions when using a custom DNS resolver.
    • Notice that when launching the DB system, the Database service automatically assigns an IP address from the VCN's CIDR block and resolves the address locally based on the host's /etc/hosts file. Your custom DNS resolver does not need to resolve the hostname in advance for the DB system launch to succeed.
Hostname restrictions when using a custom DNS resolver

Requirement for the DB system's hostname prefix:

  • Maximum 16 characters, otherwise the DB system deployment will fail.
  • Cannot be the string localhost.

Requirements for the VCN and subnet DNS labels:

  • You can provide a value for the DNS labels only if you select the check box for Use DNS Hostnames when creating the VCN and subnets. The resulting FQDN for the DB system follows this format:

    <hostname_prefix>.<subnet_DNS_label>.<VCN_DNS_label>.oraclevcn.com

  • Recommended maximum for each DNS label: 15 characters.
  • No hyphens or underscores.
  • 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 set the VCN and subnet DNS 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 recommended maximums are not enforced when you create the VCN and subnets. However, the DB system deployment fails if the FQDN has more than 63 characters.

Requirements for the DB system's host domain name:

  • You can provide a value in the Host Domain Name field only if you did not select the check box for Use DNS Hostnames when creating the VCN and subnets.
  • No hyphens or underscores.
  • Ensure that the value results in an FQDN that is no longer than 63 characters. Otherwise the DB system deployment will fail.

DNS: Between On-Premises Network and VCN

If you are using the Internet and VCN Resolver and want to enable the use of hostnames when on-premises hosts and VCN resources communicate with each other, you can 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.

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

You configure the subnet to use the service gateway for access only to Object Storage. As a reminder, here's the diagram for option 1:

This image shows the network setup with a public client subnet.

In general, you must:

  • Perform the tasks for setting up a service gateway on a VCN, and specifically enable the service CIDR label called OCI <region> Object Storage.
  • In the task for updating routing, add a route rule to the subnet's custom route table. For the destination service, use OCI <region> Object Storage and target = the service gateway.
  • In the task for updating security rules for the subnet, perform the task on the DB system's custom network security group (NSG) or security list. Here you set up a security rule with the destination service set to OCI <region> Object Storage. See Custom Security Rules.
Option 2: Service Gateway Access to Both Object Storage and YUM Repos

You configure the subnet to use the service gateway for access to the Oracle Services Network, which includes both Object Storage and the Oracle YUM repos.

Important

See this known issue for information about accessing Oracle YUM services through the service gateway.

As a reminder, here's the diagram for option 2:

This image shows the network setup with a private client subnet.

In general, you must:

  • Perform the tasks for setting up a service gateway on a VCN, and specifically enable the service CIDR label called All <region> Services in Oracle Services Network.
  • In the task for updating routing in the subnet, add a rule to the subnet's custom route table. For the destination service, use All <region> Services in Oracle Services Network and target = the service gateway.
  • In the task for updating security rules for the subnet, perform the task on the subnet's custom network security group (NSG) or security list. Here you set up a security rule with the destination service set to All <region> Services in Oracle Services Network. See Custom Security Rules.

Security Rules for the DB System

This section lists the security rules to use with your DB system. Security rules control the types of traffic allowed in and out of the DB system's compute nodes. The rules are divided into two sections.

There are different ways to implement these rules. For more information, see Ways to Implement the Security Rules.

Important

Your instances running Oracle-provided DB system images also have firewall rules that control access to the instance. Make sure that both the instance's security rules and firewall rules are set correctly. Also see Opening Ports on the DB System.

General Rules Required for Basic Connectivity

This section has several general rules that enable essential connectivity for hosts in the VCN.

If you use security lists to implement your security rules, be aware that the rules that follow are included by default in the default security list. Update or replace the list to meet your particular security needs. The two ICMP rules (general ingress rules 2 and 3) are required for proper functioning of network traffic within the Oracle Cloud Infrastructure environment. Adjust the general ingress rule 1 (the SSH rule) and the general egress rule 1 to allow traffic only to and from hosts that require communication with resources in your VCN.

General ingress rule 1: Allows SSH traffic from anywhere
  • Stateless: No (all rules must be stateful)
  • Source Type: CIDR
  • Source CIDR: 0.0.0.0/0
  • IP Protocol: TCP
  • Source Port Range: All
  • Destination Port Range: 22
General ingress rule 2: Allows Path MTU Discovery fragmentation messages

This rule enables hosts in the VCN to receive Path MTU Discovery fragmentation messages. Without access to these messages, hosts in the VCN can have problems communicating with hosts outside the VCN.

  • Stateless: No (all rules must be stateful)
  • Source Type: CIDR
  • Source CIDR: 0.0.0.0/0
  • IP Protocol: ICMP
  • Type: 3
  • Code: 4
General ingress rule 3: Allows connectivity error messages within the VCN

This rule enables the hosts in the VCN to receive connectivity error messages from each other.

  • Stateless: No (all rules must be stateful)
  • Source Type: CIDR
  • Source CIDR: Your VCN's CIDR
  • IP Protocol: ICMP
  • Type: 3
  • Code: All
General egress rule 1: Allows all egress traffic
  • Stateless: No (all rules must be stateful)
  • Destination Type: CIDR
  • Destination CIDR: 0.0.0.0/0
  • IP Protocol: All

Custom Security Rules

The following rules are necessary for the DB system's functionality.

Important

Custom ingress rules 1 and 2 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.
Custom ingress rule 1: Allows ONS and FAN traffic from within the VCN

This rule is recommended and enables the Oracle Notification Services (ONS) to communicate about Fast Application Notification (FAN) events.

  • Stateless: No (all rules must be stateful)
  • Source Type: CIDR
  • Source CIDR: VCN's CIDR
  • IP Protocol: TCP
  • Source Port Range: All
  • Destination Port Range: 6200
  • Description: An optional description of the rule.
Custom ingress rule 2: Allows SQL*NET traffic from within the VCN

This rule is for SQL*NET traffic and is required only if you need to enable client connections to the database.

  • Stateless: No (all rules must be stateful)
  • Source Type: CIDR
  • Source CIDR: VCN's CIDR
  • IP Protocol: TCP
  • Source Port Range: All
  • Destination Port Range: 1521
  • Description: An optional description of the rule.
Custom egress rule 1: Allows outbound SSH access

This rule enables SSH access between nodes in a 2-node DB system. It is redundant with the general egress rule in General Rules Required for Basic Connectivity (and in the default security list). It is optional but recommended in case the general rule (or default security list) is inadvertently changed.

  • Stateless: No (all rules must be stateful)
  • Destination Type: CIDR
  • Destination CIDR: 0.0.0.0/0
  • IP Protocol: TCP
  • Source Port Range: All
  • Destination Port Range: 22
  • Description: An optional description of the rule.
Custom egress rule 2: Allows access to Object Storage and YUM repos

This rule enables the DB system to communicate with Object Storage alone (for option 1), or with the Oracle Services Network, which includes both Object Storage and the Oracle YUM repos (for option 2). It is redundant with the general egress rule in General Rules Required for Basic Connectivity (and in the default security list). It is optional but recommended in case the general rule (or default security list) is inadvertently changed.

  • Stateless: No (all rules must be stateful)
  • Destination Type: Service
  • Destination Service:

    • For option 1, use the service CIDR label called OCI <region> Object Storage
    • For option 2, use the service CIDR label called All <region> Services in Oracle Services Network
  • IP Protocol: TCP
  • Source Port Range: All
  • Destination Port Range: 443 (HTTPS)
  • Description: An optional description of the rule.

Ways to Implement the Security Rules

The Networking service offers two ways to implement security rules within your VCN:

For a comparison of the two methods, see Comparison of Security Lists and Network Security Groups.

If you use network security groups

If you choose to use network security groups (NSGs), here is the recommended process:

  1. Create a network security group for DB systems. Add the following security rules to that NSG:

  2. When the database administrator creates the DB system, they must choose several networking components (for example, which VCN and subnet to use). They can also choose which NSG or NSGs to use. Make sure they choose the NSG you created.

You could instead create one NSG for the general rules and a separate NSG for the custom rules. Then when the database administrator chooses which NSGs to use for the DB system, make sure they choose both NSGs.

If you use security lists

If you choose to use security lists, here is the recommended process:

  1. Configure the subnet to use the required security rules:

    1. Create a custom security list for the subnet and add the rules listed in Custom Security Rules.
    2. Associate the following two security lists with the subnet:

      • VCN's default security list with all its default rules. This automatically comes with the VCN.
      • The new custom security list you created for the subnet
  2. Later when the database administrator creates the DB system, they must choose several networking components. When they select the subnet that you have already created and configured, the security rules are automatically enforced for the compute nodes created in the subnet.

Caution

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

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