Configuring the Tenancy

Before you can use Oracle's Globally Distributed Database services to create and manage a distributed 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.

Parent topic: Getting Started With Globally Distributed Autonomous Database

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 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 Oracle's Globally Distributed Database services.

  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 implementation; this includes databases for the catalog, shards, and Oracle Data Guard standby databases.

For more information, see Managing Regions.

Parent topic: Configuring the Tenancy

Task 2. Create Compartments

As the tenant administrator, create compartments in your tenancy for all of the resources required by the 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 gdd in the examples.
  • "Child" compartments for each of the various kinds of resources:
    • gdd_certs_vaults_keys for certificate authorities, certificates, certificate bundles, vaults, and keys
    • gdd_clusters for Cloud Autonomous VM Clusters
    • gdd_databases for databases, VCNs, subnets, private endpoints, and Globally Distributed Database resources.
    • gdd_exadata for Exadata Infrastructures
    • gdd_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 /
     gdd /       
          gdd_certs_vaults_keys 
          gdd_clusters       
          gdd_databases  
          gdd_exadata             
          gdd_instances

For more information, see Working with Compartments.

Parent topic: Configuring the Tenancy

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 distributed 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 distributed 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.

Parent topic: Configuring the Tenancy

Understanding Role Separation

You need to ensure that your cloud users have access to use and create only the appropriate kinds of cloud resources to perform their job duties. A best practice for Globally Distributed Database is to define roles for the purposes of role separation.

The roles and responsibilities described in the following table should guide your understanding of how to define user groups, dynamic groups, and policies for your Globally Distributed Autonomous Database implementation. The example roles presented here are used throughout the environment setup, resource creation, and management instructions.

Roles Responsibilities
Tenant administrator

Subscribe to regions

Create compartments

Create dynamic groups, user groups, and policies
Infrastructure administrator

Create/Update/Delete virtual-network-family

Create/Update/Delete Autonomous Exadata Infrastructure

Create/Update/Delete Autonomous Exadata VM Clusters

Tag Autonomous Exadata VM Clusters

Create/Update/Delete Globally Distributed Autonomous Database Private Endpoints
Certificate administrator

Create/Update/Delete Vault

Create/Update/Delete Keys

Create/Update/Delete Certificate Authority

Create/Update/Delete Certificate

Create/Update/Delete CA Bundle

Upload Certificate and Certificate Bundles to Autonomous Exadata VM Clusters

Download GSM Certificate Signing Request (CSR)

Create a GSM Certificate based on GSM CSR

Upload GSM Certificate
User Create and manage Globally Distributed Databases using UI and APIs

Parent topic: Task 3. Create User Access Constraints

Dynamic Groups

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

See Creating a Dynamic Group for instructions.

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

All

resource.type='certificateauthority'

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

All

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

All

resource.compartment.id = 'OCID of compartment tenant root / gdd / gdd_instances'

Parent topic: Task 3. Create User Access Constraints

User Groups

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

See Creating a Group for instructions.

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

Parent topic: Task 3. Create User Access Constraints

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.

gdd-certificate-admins-tenant-level

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

gdd-infrastructure-admins-tenant-level

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

gdd-users-tenant-level

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

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

gdd-certificate-admins

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

gdd-infrastructure-admins

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

gdd-users

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

gdd-dg-cas

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

gdd-dg-clusters

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

gdd-kms

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

Parent topic: Task 3. Create User Access Constraints

Task 4. Configure Network Resources

As the infrastructure administrator, create the network resources and enable the connectivity needed by the distributed database.

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

Parent topic: Configuring the Tenancy

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 gdd_iad and subnet gdd_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 = gdd / gdd_databases
  • Region = Ashburn (IAD)

  • Subnet name = gdd_subnet

  • 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 gdd_pe
    • Compartment: gdd/gdd_databases

      This should be the compartment containing the Ashburn region subnet you created above.

    • Subnet: gdd_subnet

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

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

Parent topic: Task 4. Configure Network Resources

Additional Network Resources Based on Your Topology

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

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

All network resources should be created in the gdd/gdd_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 gdd_iad.
  • In region Ashburn (IAD), create service gateway gdd_sgw_iad

Required Peering

None

Required Connectivity

Unrestricted connectivity with subnet gdd_subnet (created for private endpoint)
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 gdd_R1 with subnet osd-database-subnet-R1
  • In region R1, create service gateway gdd_sgw_R1

Required Peering

gdd_iad ↔ gdd_R1

Required Connectivity

Unrestricted between gdd_iad.gdd_subnet (created for private endpoint) and gdd_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 gdd_R1 with subnet osd-database-subnet-R1
  • In region R2, create VCN gdd_R2 with subnet osd-database-subnet-R2

    ...

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

Service gateways:

  • In region R1, create service Gateway gdd_sgw_R1
  • In region R2, create Service gateway gdd_sgw_R2

    ...

  • In region Rn, create service Gateway gdd_sgw_Rn

Required Peering

gdd_iad ↔ gdd_R1

gdd_iad ↔ gdd_R2

gdd_iad ↔ gdd_Rn

gdd_R1 ↔ gdd_R2

gdd_R1 ↔ gdd_Rn

gdd_R2 ↔ gdd_Rn

Required Connectivity

Unrestricted and bi-directional between gdd_iad.gdd_subnet (created for private endpoint) and

gdd_R1.osd-database-subnet-R1

gdd_R2.osd-database-subnet-R2

gdd_Rn.osd-database-subnet-Rn

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

gdd_R2.osd-database-subnet-R2

gdd_Rn.osd-database-subnet-Rn

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

gdd_Rn.osd-database-subnet-Rn

*The Globally Distributed 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 Database resources in their respective regions.

Parent topic: Task 4. Configure Network Resources

Task 5. Configure Security Resources

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

All security resources are created in the gdd/gdd_certs_vaults_keys compartment.

Caution:

After creating a Globally Distributed 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 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 Database implementation.

Parent topic: Configuring the Tenancy

Automatic Data Distribution, Single Region

In this 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 gdd_vault_R1

Instructions: Creating a Vault
Certificate Authority Key
  • In region R1, create master encryption key gdd_ca_key_R1, in vault gdd_vault_R1

Required attribute values:

  • Protection Mode = HSM

  • Key Shape: Algorithm = RSA

  • Length = 2048

Instructions: Create a Master Encryption Key
TDE Key
  • In region R1, create master encryption key gdd_TDE_key-oraspace in vault gdd_vault_R1

Required attribute values:

  • Protection Mode = Software

  • Key Shape: Algorithm = AES

  • Length = 256

Instructions: Create a Master Encryption Key
Certificate Authority

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

  • In region R1, using key gdd_ca_key_R1, create CA gdd_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.

Instructions: Creating a Certificate Authority
Certificate

Create a Certificate for upload to Cloud Autonomous VM Clusters.

  • In region R1, using CA gdd_ca_R1, create Certificate gdd_cert

Instructions: Creating a Certificate
CA Bundle

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

  • In region R1, create a CA Bundle gdd_cert_bundle containing the certificate chain for Certificate gdd_cert

Instructions: Creating a CA Bundle

Parent topic: Task 5. Configure Security Resources

Automatic Data Distribution, Primary and Standby Regions

This topology results when primary and standby databases are placed in different regions. In this 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 gdd_vault_Rp

  • In region Rs, create vault gdd_vault_Rs

Instructions: Creating a Vault
Replicated Virtual Vault

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

  • In region Rp, create virtual vault gdd_vault_Rp_Rs that is replicated to region Rs

Instructions: Replicating a Vault and Keys
Certificate Authority Keys
  • In region Rp, create master encryption key gdd_ca_key_Rp in vault gdd_vault_Rp
  • In region Rs, create master encryption key gdd_ca_key_Rs in vault gdd_vault_Rs

Required attribute values:

  • Protection Mode = HSM

  • Key Shape: Algorithm = RSA

  • Length = 2048

Instructions: Create a Master Encryption Key
TDE Key
  • In region Rp, create master encryption key gdd_TDE_key-oraspace in replicated virtual vault gdd_vault_Rp_Rs

Required attribute values:

  • Protection Mode = Software

  • Key Shape: Algorithm = AES

  • Length = 256

Instructions: Create a Master Encryption Key
Certificate Authorities

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

  • In region Rp, using key gdd_ca_key_Rp, create CA gdd_ca_Rp

  • In region Rs, using key gdd_ca_key_Rs, create CA gdd_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.

Instructions: Creating a Certificate Authority
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 gdd_ca_Rp, create Certificate gdd_cert
  • In region Rs, using CA gdd_ca_Rs, create Certificate gdd_cert

Instructions: Creating a Certificate
CA Bundles

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

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

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

Instructions: Creating a CA Bundle

Parent topic: Task 5. Configure Security Resources

User-Managed Data Distribution, Single Region

In this 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 gdd_vault_R1

Instructions: Creating a Vault
Certificate Authority Key
  • In region R1, create key gdd_ca_key_R1 in vault gdd_vault_R1

Required attribute values:

  • Protection Mode = HSM

  • Key Shape: Algorithm = RSA

  • Length = 2048

Instructions: Create a Master Encryption Key
TDE Keys

  • In region R1, create key gdd_TDE_key-catalog in vault gdd_vault_R1 for encrypting the catalog

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

Required attribute values:

  • Protection Mode = Software

  • Key Shape: Algorithm = AES

  • Length = 256

Instructions: Create a Master Encryption Key
Certificate Authority

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

  • In region R1, using key gdd_ca_key_R1, create CA gdd_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.

Instructions: Creating a Certificate Authority
Certificate

Create a Certificate for upload to Cloud Autonomous VM Clusters.

  • In region R1, using CA key gdd_ca_R1, create Certificate gdd_cert

Instructions: Creating a Certificate
CA Bundle

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

  • In region R1, create a CA Bundle gdd_cert_bundle containing the certificate chain for Certificate gdd_cert

Instructions: Creating a CA Bundle

Parent topic: Task 5. Configure Security Resources

User-Managed Data Distribution, Multiple Regions

In this 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 gdd_vault_R1

  • In region R2, create vault gdd_vault_R2

    ...

  • In region Rn, create vault gdd_vault_Rn

Instructions: Creating a Vault
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, gdd_vault_Rp_Rs, in the database's primary region, Rp, that is replicated to the database's standby region, Rs.
Replicating a Vault and Keys
Certificate Authority Keys

  • In region R1, create key gdd_ca_key_R1 in vault gdd_vault_R1

  • In region R2, create key gdd_ca_key_R2 in vault gdd_vault_R2

    ...

  • In region Rn, create key gdd_ca_key_Rn in vault gdd_vault_Rn

Required attribute values:

  • Protection Mode = HSM

  • Key Shape: Algorithm = RSA

  • Length = 2048

Instructions: Create a Master Encryption Key
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 gdd_TDE_key-catalog for the catalog database in the vault in the region where the catalog's database is placed
  • Create key gdd_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 gdd_TDE_key-catalog in the replicated virtual vault in the region where the catalog's primary database is placed
  • Create key gdd_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

Instructions: Create a Master Encryption Key
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 gdd_ca_key_R1, create CA gdd_ca_R1
  • In region R2, using key gdd_ca_key_R2, create CA gdd_ca_R2

    ...

  • In region Rn, using key gdd_ca_key_Rn, create CA gdd_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.

Instructions: Creating a Certificate Authority
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 gdd_ca_R1, create Certificate gdd_cert
  • In region R2, using CA gdd_ca_R2, create Certificate gdd_cert

    ...

  • In region Rn, using CA gdd_ca_Rn, create Certificate gdd_cert

Instructions: Creating a Certificate
CA Bundles

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

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

    ...

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

Instructions: Creating a CA Bundle

Parent topic: Task 5. Configure Security Resources

Task 6. Create Exadata Resources

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

Parent topic: Configuring the Tenancy

Exadata Resource Considerations

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.

Parent topic: Task 6. Create Exadata Resources

Create Exadata Infrastructure Instances

Create Exadata Infrastructure resources in the gdd/gdd_exadata compartment.

Follow the instructions in Create an Exadata Infrastructure Resource.

Parent topic: Task 6. Create Exadata Resources

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.

Parent topic: Task 6. Create Exadata Resources

Create Cloud Autonomous VM Clusters

Create a cluster for each database in the Globally Distributed Database topology.

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

While creating the clusters make sure to do the following:

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

    Oracle-ApplicationName.Other_Oracle_Application: Sharding

    Before you can add the tag to an Autonomous Exadata VM Cluster, you must import the tag’s namespace.

    Note:

    Once you tag a cluster for use in a Globally Distributed Database, it will continue to bill for the Globally Distributed Database SKU until the cluster is deleted.

  • Create clusters in gdd/gdd_clusters compartment.

  • For release 23ai: If you plan to use 23ai databases, check the prerequisites section in Create an Autonomous Exadata VM Cluster for 23ai database software version requirements.

  • When the clusters are set up they need to be set to the same time zone.

  • It is recommended that you use one VM cluster per database (shard or catalog).

Parent topic: Task 6. Create Exadata Resources

Task 7. Upload the Cloud Autonomous VM Cluster Certificates

As the certificate administrator, you created the certificate authority, certificates, and CA bundle in the gdd/gdd_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.

Parent topic: Configuring the Tenancy

(Optional) Create API Key and User Constraints

Create an OCI API key pair if you intend to directly use the Globally Distributed 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.

Parent topic: Configuring the Tenancy