Configure Autonomous Database with Reference Architecture

This use case demonstrates how to configure your Autonomous Database resources on Dedicated Exadata Infrastructure to leverage its capabilities better. This is a comprehensive and recommended configuration that leverages the reference architecture of Autonomous Database on Dedicated Exadata Infrastructure.

Oracle Autonomous Database on Dedicated Exadata Infrastructure is a highly automated, fully managed database environment running in Oracle Cloud Infrastructure (OCI) with committed hardware and software resources. These isolated resources enable organizations to meet stringent security, availability, and performance requirements while reducing cost and complexity.

Tip:

If you are looking for guidance to quickly configure an Autonomous Database POC environment, see Configure Autonomous Database for Proof of Concept (POC).

Prerequisite Knowledge

To fully understand and appreciate this use case, you should have a basic understanding of Autonomous Database on Dedicated Exadata Infrastructure, including its deployment options, key infrastructure components, user roles, and main features. For more detailed information, please refer to About Autonomous Database on Dedicated Exadata Infrastructure.

Related Topics

Use Case

Acme Company has chosen to use Autonomous Database on Dedicated Exadata Infrastructure for its internal project applications. The Acme I.T. department will assume the role of fleet administrator, responsible for creating and managing Exadata Infrastructure (EI) and Autonomous Exadata VM Cluster (AVMC) resources for the company. Within each project team or line of business, designated users will take on the application DBA role, tasked with creating Autonomous Container Database (ACD) and Autonomous Databases for their database users, including application developers, testers, and deployers.

Note:

This example illustrates the application DBA creating and managing the ACD resources. However, your organization may prefer that the fleet administrator undertake this task themselves.

Acme I.T. will allocate resources to the various teams, ensuring the provision of AVMCs that meet the required SLAs. Additionally, to control the allocation of resources fairly, Acme I.T. does not want any project team or line of business to have management access to the underlying dedicated infrastructure. Furthermore, in compliance with regulatory audits, Acme management does not want Acme I.T. to be able to access the data that belongs to different project teams or lines of business; that is, the data they store in their application databases.

AcmeHR, an internal HR application developed and utilized by Acme, operates in two distinct environments: one for development and testing (Dev) and another for production (Prod). Acme I.T. is committed to maintaining strict isolation between these environments to prevent any unauthorized access or interaction between the Dev and Prod teams.

Resources Needed

OCI IAM Components


Description of configure-adb-d-resource-isolation.eps follows
Description of the illustration configure-adb-d-resource-isolation.eps

  • Three compartments to provide resource isolation as described below:
    • FleetComp for the resources Acme I.T. creates, the networking, and the private subnets used by Dev and Prod databases.
    • DevComp for the Dev database.
    • ProdComp for the Prod database.
  • Three groups to which users can be assigned, one each for Acme I.T., Dev users and Prod users. These groups will be named FAGroup, DevGroup, and ProdGroup.
  • Required policies to specify user access to the resources at the compartment and tenancy levels.

Network Resources

  • Oracle Public Cloud deployments:

    • One VCN to provide network connectivity to all dedicated infrastructure resources. This VCN will connect to the Acme Company VPN using an IPSec VPN and have an Internet Gateway resource that blocks all incoming internet traffic. It will be named AcmeHRVCN.
    • Three subnets to provide network access isolation, one each for the Autonomous Database resources of the Dev and Prod environments and one for the application's client and mid-tier resources. These subnets will be named DevVMSubnet, ProdVMSubnet, and AppSubnet, respectively.

    Note:

    For simplicity, we are using a single VCN and leveraging subnets to provide network isolation. However, you can also create multiple VCNs to provide the required network access isolation. In this example, we create all three subnets: DevVMSubnet, ProdVMSubnet, and AppSubnet under FleetComp for simplicity. Depending on your requirements, you can optionally place these subnets in separate compartments.

  • Exadata Cloud@Customer deployments:

    • Set up network rules as listed in Network Requirements for Oracle Exadata Database Service on Cloud@Customer in Preparing for Exadata Database Service on Cloud@Customer.
    • Additionally, open Port 1522 to allow TCP traffic between primary database and standby database in an Autonomous Data Guard setup.

Autonomous Database Resources


Description of configure-adb-d-resources.eps follows
Description of the illustration configure-adb-d-resources.eps

Autonomous Database resources as per the configuration depicted above.
  • One Exadata Infrastructure to host two AVMCs. It is named AcmeInfrastructure.
  • Two AVMCs within AcmeInfrastructure for the Dev and Prod environments. These AVMCs are named DevAVMC and ProdAVMC, respectively.
  • DevAVMC:
    • Hosts the Autonomous Container Database and Autonomous Database, which are named DevACD and DevADB, respectively, for developing and testing the AcmeHR application.
    • Always patched to the latest RU (release update).
    • Retains seven (7) days of backups.
    • For every Release Update (RU) or patch release, AcmeHR deployed on DevADB is tested with the latest RU.
    • In case of any critical issues, a one-off patch is requested. After applying the one-off patch, AcmeHR is again validated to ensure that the code is stable and suitable for promotion to production. See Autonomous Database Service Maintenance to know more about one-off patches.
  • ProdAVMC:
    • Hosts the Autonomous Container Database and Autonomous Database provisioned for production deployment of the AcmeHR application. They are named ProdACD and ProdADB, respectively.
    • Always runs on the N-1 software version.
    • Retains backups for a longer duration. If required, long-term backups are also enabled.
    • Patched alternate quarters to the validated software, that is, the RUs validated in DevAVMC are deployed in this database.

High-Level Steps

Before Acme I.T. begins configuring Autonomous Database resources on Dedicated Exadata Infrastructure, it requests a service limit increase using the OCI console to add Exadata Infrastructure resources - Database Servers and Storage Servers to the tenancy. Refer to Request a Service Limit Increase for more details.

Listed below are the high-level steps to implement this use case:

  1. The security administrator for Acme Company's cloud tenancy creates the following compartments, groups, and compartment policies for resource isolation:
    • The FleetComp, DevComp, and ProdComp compartments.
    • The FAGroup, DevGroup, and ProdGroup groups.
    • The FleetCompPolicy, DevCompPolicy, and ProdCompPolicy policies.
  2. For access isolation:
    • For Oracle Public Cloud deployments, Acme I.T. or the network administrator for Acme creates the following network resources in the FleetComp compartment:
      • VCN: AcmeHRVCN
      • Private subnets: DevVMSubnet and ProdVMSubnet
      • Public subnet: AppSubnet
    • For Exadata Cloud@Customer deployments, Acme I.T. or the network administrator of Acme ensures to:
      • Set up network rules as listed in Network Requirements for Oracle Exadata Database Service on Cloud@Customer in Preparing for Exadata Database Service on Cloud@Customer.
      • Open Port 1522 to allow TCP traffic between primary database and standby database in an Autonomous Data Guard setup.
  3. After creating network resources, the security administrator adds the cloud user of a designated Acme I.T. member to the FAGroup, thus authorizing that user as the fleet administrator.
  4. The newly authorized fleet administrator creates the following dedicated infrastructure resources:
    • An Exadata Infrastructure resource AcmeInfrastructure in the FleetComp compartment.
    • Two Autonomous Exadata VM Clusters (AVMCs) in the FleetComp compartment, specifying the newly created Exadata Infrastructure:
      • DevAVMC.

        For Oracle Public Cloud deployments, specify AcmeHRVCN and DevVMSubnet as its VCN and subnet.

      • ProdAVMC.

        For Oracle Public Cloud deployments, specify AcmeHRVCN and ProdVMSubnet as its VCN and subnet.

  5. The security administrator then adds designated cloud users to the DevGroup and ProdGroup, thus authorizing them as application DBAs for the Dev and Prod environments.
  6. The newly authorized application DBAs create the following resources in their respective work environments, that is Dev and Prod:
    • Two Autonomous Container Databases (ACDs):
      • DevACD in the DevComp compartment, specifying DevAVMC as its underlying resource
      • ProdACD in the ProdComp compartment, specifying Prod AVMC as its underlying resource.
    • Autonomous Database named DevADB in the DevComp compartment.
    • Autonomous Database named ProdADB in the ProdComp compartment.

Step 1. Create Compartments

In this step, the security administrator for Acme Company's cloud tenancy creates the FleetComp, DevComp, and ProdComp compartments.

To perform this step, the security administrator follows the instructions in Managing Compartments in Oracle Cloud Infrastructure Documentation to create a compartment using the Oracle Cloud console. When following these instructions, the security administrator specifies the root compartment of the tenancy as the parent compartment of each of the three compartments.

Step 2. Create Groups

In this step, the security administrator creates the FAGroup, DevGroup, and ProdGroup groups.

To perform this step, the security administrator follows the instructions in Managing Groups in Oracle Cloud Infrastructure Documentation to create a group using the Oracle Cloud console.

Step 3. Create Policies

In this step, the security administrator creates the FleetCompPolicy, DevCompPolicy, and ProdCompPolicy policies.

To perform this step, the security administrator follows the instructions in Managing Policies in Oracle Cloud Infrastructure Documentation to create a policy using the Oracle Cloud console.

Note:

In addition to creating the required policy statements, in this example the security administrator also creates "USE tag-namespaces" policy statements to permit group members to assign existing tags to the resources they create. To permit group members to create tags as well as use existing tags, the security administrator would instead create "MANAGE tag-namespaces" policy statements.

When following these instructions for the FleetCompPolicy policy, the security administrator:

  1. Sets the Compartment in the side menu to FleetComp before clicking Create Policy.

  2. Adds either of the following Policy Statements depending on their deployment platform:

    • Oracle Public Cloud deployments:
      • Allow group FAGroup to MANAGE cloud-exadata-infrastructures in compartment FleetComp
      • Allow group FAGroup to MANAGE cloud-autonomous-vmclusters in compartment FleetComp
      • Allow group FAGroup to USE virtual-network-family in compartment FleetComp
      • Allow group FAGroup to USE tag-namespaces in compartment FleetComp
      • Allow group DevGroup to READ cloud-exadata-infrastructures in compartment FleetComp
      • Allow group DevGroup to READ cloud-autonomous-vmclusters in compartment FleetComp
      • Allow group DevGroup to USE virtual-network-family in compartment FleetComp
      • Allow group ProdGroup to READ cloud-exadata-infrastructures in compartment FleetComp
      • Allow group ProdGroup to READ cloud-autonomous-vmclusters in compartment FleetComp
      • Allow group ProdGroup to USE virtual-network-family in compartment FleetComp
    • Exadata Cloud@Customer deployments:
      • Allow group FAGroup to MANAGE exadata-infrastructures in compartment FleetComp
      • Allow group FAGroup to MANAGE autonomous-vmclusters in compartment FleetComp
      • Allow group FAGroup to USE tag-namespaces in compartment FleetComp
      • Allow group DevGroup to READ exadata-infrastructures in compartment FleetComp
      • Allow group DevGroup to READ autonomous-vmclusters in compartment FleetComp
      • Allow group ProdGroup to READ exadata-infrastructures in compartment FleetComp
      • Allow group ProdGroup to READ autonomous-vmclusters in compartment FleetComp

When following these instructions for the DevCompPolicy policy, the security administrator:

  1. Sets the Compartment in the side menu to DevComp before clicking Create Policy.

  2. Adds these Policy Statements:

    • Allow group DevGroup to MANAGE autonomous-container-databases in compartment DevComp
    • Allow group DevGroup to MANAGE autonomous-databases in compartment DevComp
    • Allow group DevGroup to MANAGE autonomous-backups in compartment DevComp
    • Allow group DevGroup to MANAGE instance-family in compartment DevComp
    • Allow group DevGroup to USE tag-namespaces in compartment DevComp
    • Allow group DevGroup to MANAGE metrics in compartment DevComp
    • Allow group DevGroup to INSPECT work-requests in compartment DevComp

When following these instructions for the ProdCompPolicy policy, the security administrator:

  1. Sets the Compartment in the side menu to ProdComp before clicking Create Policy.

  2. Adds these Policy Statements:

    • Allow group ProdGroup to MANAGE autonomous-container-databases in compartment ProdComp
    • Allow group ProdGroup to MANAGE autonomous-databases in compartment ProdComp
    • Allow group ProdGroup to MANAGE autonomous-backups in compartment ProdComp
    • Allow group ProdGroup to MANAGE instance-family in compartment ProdComp
    • Allow group ProdGroup to USE tag-namespaces in compartment ProdComp
    • Allow group ProdGroup to MANAGE metrics in compartment ProdComp
    • Allow group ProdGroup to INSPECT work-requests in compartment ProdComp

Step 4. Create the VCN and Subnets

APPLIES TO: Applicable Oracle Public Cloud only

In this step, Acme I.T. or the network administrator of Acme creates the AcmeHRVCN VCN and the DevVMSubnet, ProdVMSubnet, and AppSubnet subnets in the FleetComp compartment.

To perform this step, Acme I.T. first confers with the Acme I.T. department's networking to reserve a CIDR IP address range that will not conflict with the company's on-premises network. (Otherwise, the VCN would conflict with the on-premises network and an IPSec VPN could not be set up.) The reserved range is CIDR 10.0.0.0/16.

Then, Acme I.T. adapts the instructions in Scenario B: Private Subnet with a VPN in Oracle Cloud Infrastructure Documentation to create the VCN, the Subnets and other network resources using the Oracle Cloud console.

In this example, the following CIDR blocks will be used for the three (3) subnets in AcmeHRVCN:
  • Two private subnets:
    • 10.0.10.0/24 for DevVMSubnet
    • 10.0.20.0/24 for ProdVMSubnet
  • One public subnet:
    • 10.0.100.0/24 for AppSubnet
When adapting these instructions, Acme I.T. manually creates security lists (instead of using the default security lists) to isolate and separate security rules and thus make network management simpler. These security lists are:
  • DevSeclist: the basic security list for DevVMSubnet. It is used when the DevVMSubnet subnet is created.
  • ProdSeclist: the basic security list for ProdVMSubnet. It is used when the ProdVMSubnet subnet is created.
  • AppSeclist: the basic security list for AppSubnet. It is used when the AppSubnet subnet is created.

For more details on AVMC ingress and egress requirements, see Requirements to Provision an Autonomous Exadata VM Cluster.

Security Rules in DevSeclist

Here are the ingress rules created in DevSeclist:

Stateless Source IP Protocol Source Port Range Destination Port Range Type and Code Allows
No 10.0.10.0/24 ICMP All All All ICMP traffic for : All
No 10.0.10.0/24 TCP All All   TCP traffic for ports: All
No 10.0.100.0/24 TCP All 1521   TCP traffic for port: 1521 Oracle Net
No 10.0.100.0/24 TCP All 2484   TCPS traffic for port: 2484 Oracle Net
No 10.0.100.0/24 TCP All 6200   ONS/FAN for ports: 6200
No 10.0.100.0/24 TCP All 443   HTTPS traffic for port: 443

Here are the egress rules created in DevSeclist:

Stateless Destination IP Protocol Source Port Range Destination Port Range Type and Code Allows
No 10.0.10.0/24 ICMP All All All All ICMP traffic within DevVMSubnet
No 10.0.10.0/24 TCP All All   All TCP traffic within DevVMSubnet

Security Rules in ProdSeclist

Note:

Even though ProdSeclist has the same security rules as DevSeclist, the network administrator has created separate security lists instead of creating a single security list for both project teams to accommodate any additional security rules needed by one of the project teams in the future.

Here are the ingress rules created in ProdSeclist:

Stateless Source IP Protocol Source Port Range Destination Port Range Type and Code Allows
No 10.0.20.0/24 ICMP All All All ICMP traffic for : All
No 10.0.20.0/24 TCP All All   TCP traffic for ports: All
No 10.0.100.0/24 TCP All 1521   TCP traffic for port: 1521 Oracle Net
No 10.0.100.0/24 TCP All 2484   TCPS traffic for port: 2484 Oracle Net
No 10.0.100.0/24 TCP All 6200   ONS/FAN for ports: 6200
No 10.0.100.0/24 TCP All 443   HTTPS traffic for port: 443

Here are the egress rules created in ProdSeclist:

Stateless Destination IP Protocol Source Port Range Destination Port Range Type and Code Allows
No 10.0.20.0/24 ICMP All All All All ICMP traffic within ProdVMSubnet
No 10.0.20.0/24 TCP All All   All TCP traffic within ProdVMSubnet

Security Rules in AppSeclist

Here is the ingress rule created in AppSeclist:

Stateless Source IP Protocol Source Port Range Destination Port Range Type and Code Allows
No 0.0.0.0/0 TCP All 22 All SSH traffic for ports: 22

Note:

It is recommended to change 0.0.0.0/0 in the security rules to your approved list of CIDR range/IP addresses.

Here are the egress rules created in AppSeclist:

Stateless Destination IP Protocol Source Port Range Destination Port Range Type and Code Allows
No 10.0.10.0/24 TCP All 1521    
No 10.0.10.0/24 TCP All 2484  
No 10.0.10.0/24 TCP All 443    
No 10.0.10.0/24 TCP All 6200    
No 10.0.20.0/24 TCP All 1521    
No 10.0.20.0/24 TCP All 2484    
No 10.0.20.0/24 TCP All 443    
No 10.0.20.0/24 TCP All 6200    

Step 5. Assign Fleet Administrator

In this step, the security administrator adds the cloud user of a designated Acme I.T. member to the FAGroup.

To perform this step, the security administrator follows the instructions in Managing Users in Oracle Cloud Infrastructure Documentation to add a user to a group using the Oracle Cloud console.

Step 6. Create the Exadata Infrastructure Resource

In this step, the fleet administrator follows the instructions in Create an Exadata Infrastructure Resource to create an Exadata Infrastructure resource named AcmeInfrastructure in the FleetComp compartment.

Step 7. Create the Autonomous Exadata VM Cluster Resources

In this step, the fleet administrator follows the instructions in Create an Autonomous Exadata VM Cluster to create DevAVMC and ProdAVMC in the FleetComp compartment with the following specifications, leaving all the other attributes at their default settings.

Setting Dev environment Prod environment
AVMC Name DevAVMC ProdAVMC
Underlying Exadata Infrastructure AcmeInfrastructure AcmeInfrastructure
Virtual cloud network (VCN)

APPLIES TO: Applicable Oracle Public Cloud only

 AcmeHRVCN AcmeHRVCN
Subnet

APPLIES TO: Applicable Oracle Public Cloud only

 DevVMSubnet ProdVMSubnet

Step 8. Assign Application DBAs

In this step, the security administrator adds designated cloud users to DevGroup, thus authorizing them as application DBAs for the Dev resources, and then repeats the process for ProdGroup.

To perform this step, for each user the security administrator follows the instructions in Managing Users in Oracle Cloud Infrastructure Documentation to add a user to a group using the Oracle Cloud console.

Step 9. Create Autonomous Container Database Resources

In this step, the respective application DBAs follow the instructions in Create an Autonomous Container Database to create the Autonomous Container Databases (ACDs) for the Dev and Prod environments. These ACDs are created with the following specifications, leaving all other attributes at their default settings.

Setting Dev environment Prod environment
Compartment DevComp ProdComp
ACD Name DevACD ProdACD
Underlying AVMC DevAVMC ProdAVMC
Container Database Software version Latest software version (N) Immediate predecessor of the software version (N-1)
Maintenance version Latest RU (release update) Next RU (release update)
Backup retention period 7 days 30 days

Step 10. Create Autonomous Database Resources

In this step, the respective application DBAs follow the instructions in Create an Autonomous Database to create the Autonomous Databases for the Dev and Prod environments. These databases are created with the following specifications, leaving all other attributes at their default settings.

Setting Dev environment Prod environment
Compartment DevComp ProdComp
Database Name DevADB ProdADB
Underlying ACD DevACD ProdACD
Database instance Can choose to create an Autonomous Database or an Autonomous Database for Developers Autonomous Database

The Autonomous Database on Dedicated Exadata Infrastructure is now configured to develop and test the AcmeHR application, with subsequent deployment in the production environment.