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.

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.

Task 2. Create Compartments

As the tenant administrator, create compartments in your tenancy for all of the resources required by Oracle Globally Distributed Exadata Database on Exascale Infrastructure service.

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 Exadata Database Clusters
    • gdd_databases for databases, VCNs, subnets, private endpoints, and Globally Distributed Exadata Database on Exascale Infrastructure 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.

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.

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 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 Distributed ExaDB-XS 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 Exadata Infrastructure

Create/Update/Delete Exadata VM Clusters

Tag Exadata VM Clusters

Create/Update/Delete Globally Distributed Database Private Endpoints

Certificate administrator

Create/Update/Delete Vault

Create/Update/Delete Keys

User Create and manage Globally Distributed Databases using UI and APIs

Dynamic Groups

Create the following dynamic groups to control access to resources created in the Oracle Globally Distributed Exadata Database on Exascale Infrastructure 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 Exadata Database 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'

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

Policies

Create IAM policies to grant the groups access to resources created in the compartments for your Oracle Globally Distributed Exadata Database on Exascale Infrastructure tenancy.

Note that there is more than one Globally Distributed Database service on Oracle Cloud. These policies are specific to the Globally Distributed Exadata Database on Exascale Infrastructure service.

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 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-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 keys in compartment gdd
    Allow group 'Default' / 'gdd-certificate-admins' to MANAGE vaults 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 exadb-vm-clusters 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-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 exascale-db-storage-vaults in compartment gdd
    Allow group 'Default' / 'gdd-infrastructure-admins" to READ distributed-database-workrequest in compartment gdd

gdd-users

  • Description: Compartment-level privileges for group gdd-users
  • Compartment: tenant/gdd
  • Statements:
    Allow group 'Default' / 'gdd-users' to MANAGE database-family in compartment gdd
    Allow service database to MANAGE recovery-service-family in compartment gdd 
    Allow service rcs to MANAGE recovery-service-family in compartment gdd
    Allow group 'Default' / 'gdd-users' to MANAGE objects in compartment gdd
    Allow group 'Default' / 'gdd-users' to READ buckets in compartment gdd
    Allow group 'Default' / 'gdd-users' to MANAGE recovery-service-family in compartment gdd
    Allow group 'Default' / 'gdd-users' to USE exadb-vm-clusters in compartment gdd
    Allow group 'Default' / 'gdd-users' to MANAGE instance-family in compartment gdd
    Allow group 'Default' / 'gdd-users' to MANAGE Distributed-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-workrequest 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 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

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.

Common Network Resources

All Globally Distributed Exadata Database on Exascale Infrastructure (Distributed ExaDB-XS) 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 Distributed ExaDB-XS service and databases in the 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

See VCNs and Subnets for steps to create them.

Private Endpoint

Create a private endpoint in the Ashburn (IAD) region to enable connectivity between the Distributed ExaDB-XS service and the databases in the topology.

  1. Open the navigation menu, clickOracle Database, then click Globally Distributed Exadata Database on Exascale Infrastructure.
  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.

See Create and Manage Private Endpoints For more information about this resource.

Additional Network Resources Based on Your Topology

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

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

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 Exadata Database 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

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 Exadata Database 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 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 Exadata Database 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 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 Oracle Globally Distributed Exadata Database on Exascale Infrastructure 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 distributed database resources in their respective regions.

Instructions for creating the resources are available at:

Task 5. Configure Security Resources

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

Caution:

After creating a distributed database that references a key, you cannot move the vault or keys to a new compartment without also restarting the container databases that reference the moved vault or key.

Create a Vault

Create a vault in the gdd/gdd_certs_vaults_keys compartment for the Transparent Data Encryption (TDE) master encryption keys in the region where the shard databases will reside.

For example, in region R1, create vault gdd_vault_R1

For details about creating a vault, see Creating a Vault.

Create a TDE Key

Create the master encryption key to access the database.

For example, create master encryption key gdd_TDE_key-oraspace in vault gdd_vault_R1 with the following attributes.

  • Protection Mode = Software

  • Key Shape: Algorithm = AES

  • Length = 256

For details about creating master encryption keys, see Create a Master Encryption Key.

Task 6. Create Exadata Resources

As the infrastructure administrator, configure the Oracle Globally Distributed Exadata Database on Exascale Infrastructure topology in the following steps.

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 Exadata VM Clusters on Exascale Infrastructure

Create a VM cluster using Exadata Database Service on Exascale Infrastructure service for each catalog and shard database you plan to deploy in the Distributed ExaDB-XS topology.

See Manage VM Clusters for steps to create the clusters.

While creating the VM clusters make sure to do the following:

  • Define the Oracle-ApplicationName.Other_Oracle_Application: Sharding tag in each VM cluster configuration

    Before you can add the tag, you must import the tag’s namespace as described in Import Oracle-ApplicationName Tag Namespace.

    Note:

    Once you tag a cluster for use in a distributed database, it will continue to bill for that SKU until the cluster is deleted.
  • Create the VM clusters in your tenancy's gdd/gdd_clusters compartment.

  • You will create an Exascale Storage Vault during this configuration. Create a separate vault for each VM cluster.

  • When the VM 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).

    A shard and a catalog database can be co-located on a given VM cluster. However, using a common VM cluster for both the catalog and shard database has the potential to cause a processing bottleneck.

(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 Database APIs.