1. Using Oracle Cloud Infrastructure Globally Distributed Autonomous Database
  2. Getting Started With Globally Distributed Autonomous Database
  3. Configuring a Tenancy for Globally Distributed Autonomous Database

Configuring a Tenancy for Globally Distributed Autonomous Database

Before you can use the Globally Distributed Autonomous Database service to create and manage a sharded database, you must perform these preparatory tasks to organize your tenancy, create policies for the various resources, and then procure and configure the network, security, and infrastructure resources.

Task 1. Subscribe to Ashburn Region

As the tenant administrator, subscribe to Ashburn (IAD) region and all of the regions required to run your Globally Distributed Autonomous Database implementation.

  1. Subscribe to the Ashburn (IAD) region.
    • To use the service, you must subscribe to the Ashburn region.

    • Your tenancy Home Region does not have to be the Ashburn region, but you must subscribe to the Ashburn region to use Globally Distributed Autonomous Database.

  2. Subscribe to any other region where you will be placing a database.
    • Subscribe to any regions where you plan to place databases for your Globally Distributed Autonomous Database implementation; this includes databases for the catalog, shards, and Oracle Data Guard standby databases.

For more information, see Managing Regions.

Task 2. Create Compartments

As the tenant administrator, create compartments in your tenancy for all of the resources required by Globally Distributed Autonomous Database.

Oracle recommends the following structure, and these compartments are referenced throughout the setup tasks:

  • A "parent" compartment for the entire deployment. This is gdad in the examples.
  • "Child" compartments for each of the various kinds of resources:
    • gdad_certs_vaults_keys for certificate authorities, certificates, certificate bundles, vaults, and keys
    • gdad_clusters for Cloud Autonomous VM Clusters
    • gdad_databases for databases, VCNs, subnets, private endpoints, and Globally Distributed Autonomous Database resources.
    • gdad_exadata for Exadata Infrastructures
    • gdad_instances for compute instances for application servers (edge node/jump host to act as bastion to connect to the database)

The resulting compartment structure will resemble the following:

tenant /
     gdad /       
          gdad_certs_vaults_keys 
          gdad_clusters       
          gdad_databases  
          gdad_exadata             
          gdad_instances

For more information, see Working with Compartments.

Task 3. Create User Access Constraints

Formulate an access control plan, and then institute it by creating appropriate IAM (Identity and Access Management) resources. Accordingly, access control within a Globally Distributed Autonomous Database is implemented at various levels, which are defined by the groups and policies here.

The user groups, dynamic groups, and policies described in the following tables should guide the creation of your own user access control plan for your Globally Distributed Autonomous Database implementation.

As the tenant administrator, create the following recommended groups, dynamic groups, and policies to grant permissions to the previously defined roles. The examples and documentation links assume that your tenancy uses identity domains.

Dynamic Groups

Create the following dynamic groups to control access to resources created in the Globally Distributed Autonomous Database compartments.

See Creating a Dynamic Group for instructions.

Dynamic Group Name Description Rules
gdad-cas-dg Certificate authority resources

All

resource.type='certificateauthority'

resource.compartment.id = 'OCID of compartment tenant root / gdad / gdad_certs_vaults_keys'
gdad-clusters-dg Autonomous VM cluster resources

All

resource.compartment.id = 'OCID of compartment tenant root / gdad / gdad_clusters'
gdad-instances-dg Compute instance resources

All

resource.compartment.id = 'OCID of compartment tenant root / gdad / gdad_instances'

User Groups

Create the following groups to give users permissions to use resources in the Globally Distributed Autonomous Database compartments.

See Creating a Group for instructions.

User Group Name Description
gdad-certificate-admins Certificate administrators that create and manage keys, vaults, CAs, and certificates
gdad-infrastructure-admins Infrastructure administrators that create and manage cloud network and infrastructure resources
gdad-users Users that create and manage Globally Distributed Autonomous Database resources using the APIs and UI

Policies

Create IAM policies to grant the groups access to resources created in the Globally Distributed Autonomous Database compartments.

The following example policies, which are based on the compartment structure and groups created previously, should guide the creation of your own IAM policies for your Globally Distributed Autonomous Database implementation.

The identity domain (for example, Default) should be the identity domain you created the groups in.

See Creating a Policy for instructions.

gdad-certificate-admins-tenant-level

  • Description: Tenant-level privileges for group gdad-certificate-admins
  • Compartment: tenant
  • Statements: 
    Allow group 'Default' / 'gdad-certificate-admins' to INSPECT tenancies in tenancy
Allow group 'Default' / 'gdad-certificate-admins' to INSPECT work-requests in tenancy

gdad-infrastructure-admins-tenant-level

  • Description: Tenant-level privileges for group gdad-infrastructure-admins
  • Compartment: tenant
  • Statements: 
    Allow group 'Default' / 'gdad-infrastructure-admins' to INSPECT tenancies in tenancy
Allow group 'Default' / 'gdad-infrastructure-admins' to INSPECT work-requests in tenancy
Allow group 'Default' / 'gdad-infrastructure-admins' to READ limits in tenancy
Allow group 'Default' / 'gdad-infrastructure-admins' to READ tag-namespaces in tenancy

gdad-users-tenant-level

  • Description: Tenant-level privileges for group gdad-users

  • Compartment: tenant
  • Statements: 
    Allow group 'Default' / 'gdad-users' to INSPECT tenancies in tenancy
Allow group 'Default' / 'gdad-users' to INSPECT work-requests in tenancy
Allow group 'Default' / 'gdad-users' to READ limits in tenancy
Allow group 'Default' / 'gdad-users' to READ Sharded-database in tenancy
Allow group 'Default' / 'gdad-users' to READ tag-namespaces in tenancy

gdad-certificate-admins

  • Description: Compartment-level privileges for group gdad-certificate-admins
  • Compartment: tenant/gdad
  • Statements: 
    Allow group 'Default' / 'gdad-certificate-admins' to MANAGE certificate-authority-family in compartment gdad
Allow group 'Default' / 'gdad-certificate-admins' to MANAGE keys in compartment gdad
Allow group 'Default' / 'gdad-certificate-admins' to MANAGE Sharded-database in compartment gdad
Allow group 'Default' / 'gdad-certificate-admins' to MANAGE vaults in compartment gdad
Allow group 'Default' / 'gdad-certificate-admins' to READ buckets in compartment gdad
Allow group 'Default' / 'gdad-certificate-admins' to READ instances in compartment gdad
Allow group 'Default' / 'gdad-certificate-admins' to READ Sharded-database-work-requests in compartment gdad
Allow group 'Default' / 'gdad-certificate-admins' to USE key-delegate in compartment gdad
Allow group 'Default' / 'gdad-certificate-admins' to USE subnets in compartment gdad

gdad-infrastructure-admins

  • Description: Compartment-level privileges for group gdad-infrastructure-admins
  • Compartment: tenant/gdad
  • Statements: 
    Allow group 'Default' / 'gdad-infrastructure-admins' to MANAGE autonomous-exadata-infrastructures in compartment gdad
Allow group 'Default' / 'gdad-infrastructure-admins' to MANAGE cloud-autonomous-vmclusters in compartment gdad
Allow group 'Default' / 'gdad-infrastructure-admins' to MANAGE instance-family in compartment gdad
Allow group 'Default' / 'gdad-infrastructure-admins' to MANAGE Sharded-database in compartment gdad
Allow group 'Default' / 'gdad-infrastructure-admins' to MANAGE tags in compartment gdad
Allow group 'Default' / 'gdad-infrastructure-admins' to MANAGE virtual-network-family in compartment gdad
Allow group 'Default' / 'gdad-infrastructure-admins' to READ autonomous-container-databases in compartment gdad
Allow group 'Default' / 'gdad-infrastructure-admins' to READ autonomous-virtual-machines in compartment gdad
Allow group 'Default' / 'gdad-infrastructure-admins' to READ leaf-certificate-family in compartment gdad
Allow group 'Default' / 'gdad-infrastructure-admins" to READ Sharded-database-work-requests in compartment gdad

gdad-users

  • Description: Compartment-level privileges for group gdad-users
  • Compartment: tenant/gdad
  • Statements: 
    Allow group 'Default' / 'gdad-users' to MANAGE autonomous-backups in compartment gdad
Allow group 'Default' / 'gdad-users' to MANAGE autonomous-container-databases in compartment gdad
Allow group 'Default' / 'gdad-users' to MANAGE autonomous-databases in compartment gdad
Allow group 'Default' / 'gdad-users' to MANAGE instance-family in compartment gdad
Allow group 'Default' / 'gdad-users' to MANAGE Sharded-database in compartment gdad
Allow group 'Default' / 'gdad-users' to MANAGE tags in compartment gdad
Allow group 'Default' / 'gdad-users' to READ dns-records in compartment gdad
Allow group 'Default' / 'gdad-users' to READ dns-zone in compartment gdad
Allow group 'Default' / 'gdad-users' to READ keys in compartment gdad
Allow group 'Default' / 'gdad-users' to READ Sharded-database-work-requests in compartment gdad
Allow group 'Default' / 'gdad-users' to READ vaults in compartment gdad
Allow group 'Default' / 'gdad-users' to READ vcns in compartment gdad
Allow group 'Default' / 'gdad-users' to USE autonomous-exadata-infrastructures in compartment gdad
Allow group 'Default' / 'gdad-users' to USE cloud-autonomous-vmclusters in compartment gdad
Allow group 'Default' / 'gdad-users' to USE network-security-groups in compartment gdad
Allow group 'Default' / 'gdad-users' to USE private-ips in compartment gdad
Allow group 'Default' / 'gdad-users' to USE subnets in compartment gdad
Allow group 'Default' / 'gdad-users' to USE vnics in compartment gdad
Allow group 'Default' / 'gdad-users' to USE volumes in compartment gdad

gdad-dg-cas

  • Description: Compartment-level privileges for dynamic group gdad-cas-dg
  • Compartment: tenant/gdad
  • Statements: 
    Allow dynamic-group 'Default' / 'gdad-cas-dg' to MANAGE objects in compartment gdad
Allow dynamic-group 'Default' / 'gdad-cas-dg' to USE keys in compartment gdad

gdad-dg-clusters

  • Description: Compartment-level privileges for dynamic group gdad-clusters-dg
  • Compartment: tenant/gdad
  • Statements: 
    Allow dynamic-group 'Default' / 'gdad-clusters-dg' to MANAGE keys in compartment gdad_certs_vaults_keys
Allow dynamic-group 'Default' / 'gdad-clusters-dg' to READ vaults in compartment gdad_certs_vaults_keys

gdad-kms

  • Description: Compartment-level privileges for Key Management Service
  • Compartment: tenant/gdad
  • Statements: 
    Allow service keymanagementservice to MANAGE vaults in compartment gdad_certs_vaults_keys

Task 4. Configure Network Resources

As the infrastructure administrator, create the network resources and enable the connectivity needed by the Globally Distributed Autonomous Database implementation.

Example resources are named throughout these instructions to simplify tracking and relationships. For example, the name "gdad_iad" refers to the VCN created in the Ashburn (IAD) region.

Instructions for creating the resources are available at:

Common Network Resources

All Globally Distributed Autonomous Database implementations require a VCN, subnet, and a private endpoint in the Ashburn (IAD) region.

As the infrastructure administrator, create the resources as described in the following table.

Resource Instructions
Virtual Cloud Network (VCN)+ subnet

In Ashburn (IAD), create VCN gdad_iad and subnet osd-gsm-proxy-subnet.

This VCN and subnet are required to enable connectivity between the Globally Distributed Autonomous Database service and databases in the Globally Distributed Autonomous Database topology.

Use the following values:

  • Compartment = gdad / gdad_databases
  • Region = Ashburn (IAD)

  • Subnet name = osd-gsm-proxy-subnet

    Note:

    the subnet name must be named osd-gsm-proxy-subnet or Globally Distributed Autonomous Database will not work properly.

  • Subnet Type = Regional

    The subnet must be regional, spanning all availability domains

Private Endpoint

Create a private endpoint in the Ashburn (IAD) region to enable connectivity between the Globally Distributed Autonomous Database service and the databases in the Globally Distributed Autonomous Database topology.

  1. Open the navigation menu, clickOracle Database, then click Globally Distributed Autonomous Database.
  2. Click Private Endpoints in the navigation pane.
  3. Click Create private endpoint.

  4. Enter the following information.

    • Name: For example gdad_pe
    • Compartment: gdad/gdad_databases

      This should be the compartment you chose when creating the subnet named osd-gsm-proxy-subnet in the previous step.

    • Subnet: osd-gsm-proxy-subnet

      If you don't see the subnet listed, verify that it was created as a Regional subnet.

    • Virtual cloud network: gdad_iad
    • Add tags (optional): you can select tags for this resource by clicking Show Tagging Options.

Additional Network Resources Based on Your Topology

Depending on your Globally Distributed Autonomous Database topology, create additional network resources as described below.

Note that databases for the Globally Distributed Autonomous Database topology include the catalog, shards, and Oracle Data Guard standby databases.

All network resources should be created in the gdad/gdad_databases compartment.

Use Case Network Resources Peering and Connectivity

All databases are placed in the Ashburn (IAD) region

Create a subnet and service gateway in Ashburn (IAD) region for your Cloud Autonomous VM Clusters.

  • In region Ashburn (IAD), create subnet osd-databases-subnet-iad in VCN gdad_iad.
  • In region Ashburn (IAD), create service gateway gdad_sgw_iad

Required Peering

None

Required Connectivity

Unrestricted connectivity with subnet osd-gsm-proxy-subnet
All databases are placed in a single region, R1, that is not Ashburn (IAD)*

Create a subnet and service gateway in the region for your Cloud Autonomous VM Clusters.

  • In region R1, create VCN gdad_R1 with subnet osd-database-subnet-R1
  • In region R1, create service gateway gdad_sgw_R1

Required Peering

gdad_iad ↔ gdad_R1

Required Connectivity

Unrestricted between gdad_iad.osd-gsm-proxy-subnet and gdad_R1.osd-database-subnet-R1
Databases are placed in multiple regions R1, R2, ..., RN

Create subnets and service gateways in each region for your Cloud Autonomous VM Clusters.

Subnet:

  • In region R1, create VCN gdad_R1 with subnet osd-database-subnet-R1
  • In region R2, create VCN gdad_R2 with subnet osd-database-subnet-R2

    ...

  • In region Rn, create VCN gdad_Rn with subnet osd-database-subnet-Rn

Service gateways:

  • In region R1, create service Gateway gdad_sgw_R1
  • In region R2, create Service gateway gdad_sgw_R2

    ...

  • In region Rn, create service Gateway gdad_sgw_Rn

Required Peering

gdad_iad ↔ gdad_R1

gdad_iad ↔ gdad_R2

gdad_iad ↔ gdad_Rn

gdad_R1 ↔ gdad_R2

gdad_R1 ↔ gdad_Rn

gdad_R2 ↔ gdad_Rn

Required Connectivity

Unrestricted and bi-directional between gdad_iad.osd-gsm-proxy-subnet and

gdad_R1.osd-database-subnet-R1

gdad_R2.osd-database-subnet-R2

gdad_Rn.osd-database-subnet-Rn

Unrestricted and bi-directional between gdad_R1.osd-database-subnet-R1 and

gdad_R2.osd-database-subnet-R2

gdad_Rn.osd-database-subnet-Rn

Unrestricted and bi-directional between gdad_R2.osd-database-subnet-R2 and

gdad_Rn.osd-database-subnet-Rn

*The Globally Distributed Autonomous Database service control plane exists only in the Ashburn (IAD) region. The private endpoint your created in a previous step in the Ashburn (IAD) region is used to communicate with the Globally Distributed Autonomous Database resources in their respective regions.

Task 5. Configure Security Resources

As the Globally Distributed Autonomous Database certificate administrator, create the vault, key, certificate authority, certificate, and CA bundle resources.

All security resources are created in the gdad/gdad_certs_vaults_keys compartment.

Caution:

After creating a Globally Distributed Autonomous Database that references a key, you cannot move the vault or keys to a new compartment without also restarting the autonomous container databases that reference the moved vault or key.

Depending on your Globally Distributed Autonomous Database topology, create security resources as described in the following tables.

The example resource names used in the following tables should guide the creation of your own security resources for your Globally Distributed Autonomous Database implementation.

Instructions for creating the resources are available at:

Automatic Data Distribution, Single Region

In this Globally Distributed Autonomous Database use case, security resources are created in a singe region.

In the examples below, all resources are created in region R1.
Resource Instructions and Examples
Vault

Create a vault for the Certificate Authority (CA) and the Transparent Data Encryption (TDE) master encryption keys.

  • In region R1, create vault gdad_vault_R1
Certificate Authority Key
  • In region R1, create master encryption key gdad_ca_key_R1, in vault gdad_vault_R1

Required attribute values:

  • Protection Mode = HSM

  • Key Shape: Algorithm = RSA

  • Length = 2048
TDE Key
  • In region R1, create master encryption key gdad_TDE_key-oraspace in vault gdad_vault_R1

Required attribute values:

  • Protection Mode = Software

  • Key Shape: Algorithm = AES

  • Length = 256
Certificate Authority

Create a CA for issuing certificates for Cloud Autonomous VM Clusters and GSM compute instances.

  • In region R1, using key gdad_ca_key_R1, create CA gdad_ca_R1

You can use a third party CA to create a certificate, but you must import the certificate issued by 3rd Party CA to OCI Certificate Service.
Certificate

Create a Certificate for upload to Cloud Autonomous VM Clusters.

  • In region R1, using CA gdad_ca_R1, create Certificate gdad_cert
CA Bundle

Create a CA Bundle for upload to Cloud Autonomous VM Clusters.

  • In region R1, create a CA Bundle gdad_cert_bundle containing the certificate chain for Certificate gdad_cert

Automatic Data Distribution, Primary and Standby Regions

This topology results when primary and standby databases are placed in different regions. In this Globally Distributed Autonomous Database use case, security resources are created in a the primary database and standby database regions.

In the examples below, resources are created in regions Rp (primary) and Rs (standby).
Resource Instructions and Examples
Vaults

Create the vaults for the Certificate Authority (CA) master encryption keys.

  • In region Rp, create vault gdad_vault_Rp

  • In region Rs, create vault gdad_vault_Rs
Replicated Virtual Vault

Create a replicated virtual vault for the Transparent Data Encryption (TDE) master encryption key.

  • In region Rp, create virtual vault gdad_vault_Rp_Rs that is replicated to region Rs
Certificate Authority Keys
  • In region Rp, create master encryption key gdad_ca_key_Rp in vault gdad_vault_Rp
  • In region Rs, create master encryption key gdad_ca_key_Rs in vault gdad_vault_Rs

Required attribute values:

  • Protection Mode = HSM

  • Key Shape: Algorithm = RSA

  • Length = 2048
TDE Key
  • In region Rp, create master encryption key gdad_TDE_key-oraspace in replicated virtual vault gdad_vault_Rp_Rs

Required attribute values:

  • Protection Mode = Software

  • Key Shape: Algorithm = AES

  • Length = 256
Certificate Authorities

Create CAs for issuing certificates for Cloud Autonomous VM Clusters and GSM compute instances.

  • In region Rp, using key gdad_ca_key_Rp, create CA gdad_ca_Rp

  • In region Rs, using key gdad_ca_key_Rs, create CA gdad_ca_Rs

You can use a third party CA to create a certificate, but you must import the certificate issued by 3rd Party CA to OCI Certificate Service.
Certificates

Create the Certificates for upload to Cloud Autonomous VM Clusters.

Note: You must use the same common name for the certificates in regions Rp and Rs.

  • In region Rp, using CA gdad_ca_Rp, create Certificate gdad_cert
  • In region Rs, using CA gdad_ca_Rs, create Certificate gdad_cert
CA Bundles

Create the CA Bundles for upload to Cloud Autonomous VM Clusters.

  • In region Rp, create CA Bundle gdad_cert_bundle containing the certificate chain for Certificates gdad_cert in regions Rp and Rs

  • In region Rs, create CA Bundle gdad_cert_bundle containing he certificate chain for Certificates gdad_cert in regions Rp and Rs

User-Managed Data Distribution, Single Region

In this Globally Distributed Autonomous Database use case, security resources are created in a singe region

In the examples below, all resources are created in region R1.
Resource Instructions and Examples
Vault

Create a vault for the Certificate Authority (CA) and the Transparent Data Encryption (TDE) master encryption keys.

  • In region R1, create vault gdad_vault_R1
Certificate Authority Key
  • In region R1, create key gdad_ca_key_R1 in vault gdad_vault_R1

Required attribute values:

  • Protection Mode = HSM

  • Key Shape: Algorithm = RSA

  • Length = 2048
TDE Keys

  • In region R1, create key gdad_TDE_key-catalog in vault gdad_vault_R1 for encrypting the catalog

  • In region R1, create key gdad_TDE_key-spaceN in vault gdad_vault_R1 for encrypting the shards in shard space N

Required attribute values:

  • Protection Mode = Software

  • Key Shape: Algorithm = AES

  • Length = 256
Certificate Authority

Create a CA for issuing certificates for Cloud Autonomous VM Clusters and GSM compute instances.

  • In region R1, using key gdad_ca_key_R1, create CA gdad_ca_R1

You can use a third party CA to create a certificate, but you must import the certificate issued by 3rd Party CA to OCI Certificate Service.
Certificate

Create a Certificate for upload to Cloud Autonomous VM Clusters.

  • In region R1, using CA key gdad_ca_R1, create Certificate gdad_cert
CA Bundle

Create a CA Bundle for upload to Cloud Autonomous VM Clusters.

  • In region R1, create a CA Bundle gdad_cert_bundle containing the certificate chain for Certificate gdad_cert

User-Managed Data Distribution, Multiple Regions

In this Globally Distributed Autonomous Database use case, security resources are created in every region where a database will be placed.

This topology can result when either, or both, of the following are true:

  • The primary catalog and shard databases are placed in different regions

  • The databases within a shard space are placed in different regions

Security resources are created in each region, R1, ..., Rn, where a database will be placed.

Resource Instructions and Examples
Vaults

Create a vault in each region for the Certificate Authority (CA) master encryption keys.

  • In region R1, create vault gdad_vault_R1

  • In region R2, create vault gdad_vault_R2

    ...

  • In region Rn, create vault gdad_vault_Rn
Replicated Virtual Vaults

Create replicated virtual vaults for the Transparent Data Encryption (TDE) master encryption keys.

For each database, catalog or shard, with a primary region, Rp, that is different from its standby region, Rs:

  • Create a virtual vault, gdad_vault_Rp_Rs, in the database's primary region, Rp, that is replicated to the database's standby region, Rs.
Certificate Authority Keys

  • In region R1, create key gdad_ca_key_R1 in vault gdad_vault_R1

  • In region R2, create key gdad_ca_key_R2 in vault gdad_vault_R2

    ...

  • In region Rn, create key gdad_ca_key_Rn in vault gdad_vault_Rn

Required attribute values:

  • Protection Mode = HSM

  • Key Shape: Algorithm = RSA

  • Length = 2048
TDE Keys For each database, catalog, or shard, that either has no standby database, or has a standby region that is the same as its primary region:
  • Create key gdad_TDE_key-catalog for the catalog database in the vault in the region where the catalog's database is placed
  • Create key gdad_TDE_key-spaceN for a shard space database in the vault in the region where the shard's database is placed
For each database, catalog or shard, with a primary region that is different from its stand by region:
  • Create key gdad_TDE_key-catalog in the replicated virtual vault in the region where the catalog's primary database is placed
  • Create key gdad_TDE_key-spaceN in the replicated virtual vault in the region where the shard's primary database is placed

Required attribute values:

  • Protection Mode = Software

  • Key Shape: Algorithm = AES

  • Length = 256
Certificate Authorities

Create a Certificate Authority (CA) in each region for issuing certificates for Cloud Autonomous VM Clusters and GSM compute instances.

  • In region R1, using key gdad_ca_key_R1, create CA gdad_ca_R1
  • In region R2, using key gdad_ca_key_R2, create CA gdad_ca_R2

    ...

  • In region Rn, using key gdad_ca_key_Rn, create CA gdad_ca_Rn

You can use a third party CA to create a certificate, but you must import the certificate issued by 3rd Party CA to OCI Certificate Service.
Certificates

Create Certificates in each region for upload to Cloud Autonomous VM Clusters.

Note: You must use the same common name for the certificates in all regions.

  • In region R1, using CA gdad_ca_R1, create Certificate gdad_cert
  • In region R2, using CA gdad_ca_R2, create Certificate gdad_cert

    ...

  • In region Rn, using CA gdad_ca_Rn, create Certificate gdad_cert
CA Bundles

Create the CA Bundles for upload to Cloud Autonomous VM Clusters.

  • In region R1, create CA Bundle gdad_cert_bundle containing the certificate chain for Certificates gdad_cert in regions R1, R2, ..., Rn
  • In region R2, create CA Bundle gdad_cert_bundle containing the certificate chain for Certificates gdad_cert in regions R1, R2, ..., Rn

    ...

  • In region Rn, create CA Bundle gdad_cert_bundle containing the certificate chain for Certificates gdad_cert in regions R1, R2, ..., Rn

Task 6. Create Exadata Resources

As the infrastructure administrator, configure the Globally Distributed Autonomous Database topology.

Keep the following in mind:

  • The Globally Distributed Autonomous Database service supports only two node, quarter rack Exadata.
  • An Exadata Infrastructure is region specific. This means that each region in which you plan to place a catalog or shard database will require an Exadata Infrastructure.
  • You must create a Cloud Autonomous VM Cluster for each catalog and shard database you plan to deploy in the Globally Distributed Autonomous Database.
  • Shards and catalog databases can be co-located on a given Cloud Autonomous VM Cluster. However, using a common Cloud Autonomous VM Cluster for catalog and shard database has the potential to cause a processing bottleneck.

Create Exadata Infrastructure Instances

Create Exadata Infrastructure resources in the gdad/gdad_exadata compartment.

Follow the instructions in Create an Exadata Infrastructure Resource.

Import Oracle-ApplicationName Tag Namespace

Import the Oracle-ApplicationName tag namespace in the root compartment of your tenancy.

  1. From the Cloud console navigation menu, select Governance & Administration, then Tag Namespaces (under the Tenancy Management category).

  2. In the Tag Namespaces panel, check if the Oracle-ApplicationName namespace exists in the root compartment of your tenancy.

    Make sure the root compartment of your tenancy is selected under List Scope.

  3. If you don't see Oracle-ApplicationName in the list, do the following:

    1. Click Import Standard Tags (located above the list).

    2. Select the checkbox next to the Oracle-ApplicationName namespace and click Import.

Create Cloud Autonomous VM Clusters

Create clusters in gdad/gdad_clusters compartment.

It is required that you define the following tag as you create each cluster:

Oracle-ApplicationName.Other_Oracle_Application: Sharding

Note:

Before you can add the tag to an Autonomous Exadata VM Cluster, you must import the tag’s namespace as described in the previous step.

See Create an Autonomous Exadata VM Cluster for steps to create the clusters.

Task 7. Upload the Cloud Autonomous VM Cluster Certificates

As the certificate administrator, you created the certificate authority, certificates, and CA bundle in the gdad/gdad_certs_vaults_keys compartment. Now you upload the CA Bundle to each Autonomous Exadata VM Cluster.

Important:

  • The CA bundle you upload should be identical for all Autonomous Exadata VM Clusters.

  • The certificate common name should be identical for all Autonomous Exadata VM Clusters.

For more information, see Manage Security Certificates for an Autonomous Exadata VM Cluster Resource.

Task 8. (Optional) Create API Key and User Constraints

Create an OCI API key pair if you intend to directly use the Globally Distributed Autonomous Database REST API, OCI Software Development Kits, and Command Line Interface.

Follow the instructions in Required Keys and OCIDs.

If you want to set user controls on the APIs see Permissions for Globally Distributed Autonomous Database APIs.