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.
- 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.
- 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 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.
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 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 |
Parent topic: Task 3. Create User Access Constraints
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' |
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 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
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 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:
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.
See Create and Manage Private Endpoints For more information about this resource. |
Parent topic: Task 4. Configure Network Resources
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.
|
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.
|
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:
Service gateways:
|
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:
Parent topic: Task 4. Configure Network Resources
Task 5. Configure Security Resources
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.Parent topic: Configuring the Tenancy
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.
Parent topic: Task 5. Configure Security Resources
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.
Parent topic: Task 5. Configure Security Resources
Task 6. Create Exadata Resources
As the infrastructure administrator, configure the Oracle Globally Distributed Exadata Database on Exascale Infrastructure topology in the following steps.
Parent topic: Configuring the Tenancy
Import Oracle-ApplicationName Tag Namespace
Import the Oracle-ApplicationName tag namespace in the root compartment of your tenancy.
-
From the Cloud console navigation menu, select Governance & Administration, then Tag Namespaces (under the Tenancy Management category).
-
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.
-
If you don't see Oracle-ApplicationName in the list, do the following:
-
Click Import Standard Tags (located above the list).
-
Select the checkbox next to the Oracle-ApplicationName namespace and click Import.
-
Parent topic: Task 6. Create Exadata Resources
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 configurationBefore 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.
Parent topic: Task 6. Create Exadata Resources
(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.
Parent topic: Configuring the Tenancy