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.. You will also create Virtual firewall rules for your VCN. Each security rule specifies a type of ingress or egress traffic allowed in or out of a resource or VNIC. Also see network security groups and security lists. 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 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

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 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 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 Custom DNS Resolver.

To use the Internet and VCN Resolver with your DB System
Hostname restrictions for using the Internet and VCN Resolver

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
Hostname restrictions when using a custom DNS resolver

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
Option 2: Service Gateway Access to Both Object Storage and YUM Repos

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: the following rules are included by default in the default security list.

General ingress rule 1: Allows SSH traffic from anywhere
General ingress rule 2: Allows Path MTU Discovery fragmentation messages
General ingress rule 3: Allows connectivity error messages within the VCN
General egress rule 1: Allows all egress traffic

Custom Security Rules

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

Custom ingress rule 1: Allows ONS and FAN traffic from within the VCN
Custom ingress rule 2: Allows SQL*NET traffic from within the VCN

Important

The preceding 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 egress rule 1: Allows outbound SSH access
Custom egress rule 2: Allows access to Object Storage and YUM repos

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 use security lists