Exadata Cloud Discovery Prerequisites

1 Exadata Cloud Discovery Prerequisites

Complete the following prerequisite tasks before you begin the discovery process for Oracle Exadata Database Service on Dedicated Infrastructure or Oracle Exadata Database Service on Cloud@Customer.

Topics:

Configuration Prerequisites

Before starting the discovery procedure, make sure the following prerequisites are met:

Verify Names Resolution

The Enterprise Manager OMS servers require direct network access to each of the VM Guests. If the names of the VM Guests are not registered in the OMS nodes' DNS, then they must be manually entered in the /etc/hosts file for each OMS.

To manage the Exadata Cloud Service components from Enterprise Manager Cloud Control, the agent on the VM guest hosts must be able to resolve the upload URL utilized by Enterprise Manager.

Verify Firewall Configuration

To verify the firewall configuration:

Open Database Ports

The database listener ports must be opened for the Enterprise Manager OMS servers. Note that Exadata Cloud Service databases will use SCAN listeners; so, ports will need to be opened for the base VM Guest, the VM Guest virtual IP, and scan listeners addresses.

For example, if an Exadata Cloud Service quarter rack has been configured with two VM Guests - exadbnode1.example.com and exadbnode2.example.com - and the listeners are using port 1521, then port 1521 will have to be opened to the Enterprise Manager Server for the following addresses:
- The VM Guest hostnames - exadbnode1.example.com and exadbnode2.example.com
- The virtual IPs for each VM Guest - exadbnode1-vip.example.com and exadbnode1-vip.example.com
- The scan listener hostname - scan-exadatadb
Open Enterprise Manager Upload Port

The Enterprise Manager Cloud Control 13c agents require access to the Enterprise Manager Servers upload service, normally configured on port 4889 for HTTP uploads and 4900 for HTTPS. To verify the ports assigned, run the following command on the OMS server command line.
```
$ emctl status oms -details
```
These ports must be opened for each of the VM Guests.
Open Agent Ports

The OMS servers must be able to connect to the Enterprise Manager Cloud Control 13c agent HTTP/HTTPS port on each VM Guest. The agent port defaults to 3872. If port 3872 is not available, the next available port starting from port 1830 is used.

To identify the port used:
- Run the following command on the VM Guest command line:
```
$ emctl status agent
```
- Alternatively, you can look for the value of the EMD_URL property in the emd.properties file the following directory:
```
<AGENT_HOME>/agent_inst/sysman/config
```

Verify SSL Certificate

Verify that the SSL certificate sent by OCI Service and the one received at the EM agent side are from trusted source, that is Oracle Corporation / Digicert. Run the following command on the agent host:

openssl s_client -connect database.us-ashburn-1.oraclecloud.com:443

The example output of the above command where you can check the authenticity of the certificate provider:

CONNECTED(00000003)depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root
      G2verify return:1depth=1 C = US, O = DigiCert Inc, CN = DigiCert Global G2 TLS RSA SHA256 2020 CA1verify return:1depth=0 C = US, ST = California, L = Redwood City, O = Oracle Corporation, CN =
      *.us-ashburn-1.oc-test.comverify return:1---Certificate chain 0 s:/C=US/ST=California/L=Redwood City/O=Oracle
      Corporation/CN=*.us-ashburn-1.oc-test.com   i:/C=US/O=DigiCert Inc/CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1 1 s:/C=US/O=DigiCert Inc/CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1   i:/C=US/O=DigiCert Inc/OU

If the certificate is not from a trusted or known source, then see Troubleshooting.

Table 1-1 Firewall Ports

Component	Notes
OMS	Upload http/https port - usually 3872
Agent	The OMS servers will need to be able to connect to the Enterprise Manager Cloud Control Agent HTTP/HTTPS port on each VM Guest. The agent port defaults to 3872. If port 3872 is not available, the next available port starting from port 1830 is used.

Create Required Named Credentials

The user for whom the named credentials are created, must have Monitoring privileges.

Verify ExaCLI Credentials

Run the following command on VM Guest to verify the exacli credentials:

exacli --xml -c <user>@<ip_address> -e 'list cell attributes all'

Collect the storage server IP address from /etc/oracle/cell/network-config/cellip.ora on the VM Guest.

Create IAM Policies to Support Discovery and Monitoring

In Oracle Cloud Infrastructure (OCI), access is granted to resources in an identity domain by creating policies. To successfully discover and monitor Exadata Database Service and Autonomous Database on Oracle Exadata Database Service on Cloud@Customer and on Oracle Exadata Database Service on Dedicated Infrastructure in OCI for Enterprise Manager Cloud Control, you must manually grant and maintain IAM policies to provide Enterprise Manager Cloud Control with necessary privileges for Exadata Database Service resources in OCI.

There are two approaches to maintain these policies:

The simplest approach involves the definition of policies using predefined OCI aggregate resource types, which provide access to resources that are typically used together.
For organizations with more fine-grained security requirements, a more detailed approach involves the definition of policies created specifically on each individual applicable resource, further supporting the principle of least privilege. There are separate service-specific individual resource types for deployments on Oracle Exadata Database Service on Cloud@Customer and on Oracle Exadata Database Service on Dedicated Infrastructure in OCI.

Each of these approaches can be implemented tenancy-wide or at a compartment level for finer control. Furthermore, the policies can be created for individual users or for a group of users. The examples in this document reference groups. For details on creating groups, see Managing Groups in the Oracle Cloud Infrastructure Documentation.

The following sections provide the required policy statements for each approach including the policies to be granted at aggregate resource level or individual resource level, at the compartment level or tenancy level. In case of granting at the individual resource level, the information is also provided by service type and deployment. Select the approach required by your organization’s security requirements and follow the corresponding section.

Note that all the policy statements are granted at the group level and a suitable group name must be substituted for <Group Name> in the policy statement . If required, all statements can be modified to grant to an individual user instead of a group. Also, insert the right compartment name for <Compartment Name> in the policy statements.

For more information on managing access to OCI resources, see Managing Access to Resources in Oracle Cloud Infrastructure Documentation.

Create Policies for Aggregate Resources

Create and maintain policies at the compartment or tenancy level to support the discovery and monitoring using aggregate resource types. The same aggregate resource types support both Oracle Exadata Database Service on Cloud@Customer and Oracle Exadata Database Service on Dedicated Infrastructure deployments.

Creating at compartment level:

Allow group <Group Name> to inspect database-family in compartment <Compartment Name>
Allow group <Group Name> to inspect autonomous-database-family in compartment <Compartment Name>

Creating at tenancy level:

Allow group <Group Name> to inspect database-family in tenancy
Allow group <Group Name> to inspect autonomous-database-family in tenancy

Create Policies for Individual Resources

Create and maintain policies at the compartment or tenancy level to support the discovery and monitoring using individual resource types. There are separate individual resource types for Oracle Exadata Database Service on Cloud@Customer and Oracle Exadata Database Service on Dedicated Infrastructure deployments.

Oracle Exadata Database Service on Cloud@Customer

Creating at compartment level:

Allow group <Group Name> to inspect exadata-infrastructures in compartment <Compartment Name>
Allow group <Group Name> to inspect vmclusters in compartment <Compartment Name>
Allow group <Group Name> to inspect db-nodes in compartment <Compartment Name>
Allow group <Group Name> to inspect db-homes in compartment <Compartment Name>
Allow group <Group Name> to inspect databases in compartment <Compartment Name>
Allow group <Group Name> to inspect pluggable-databases in compartment <Compartment Name>
Allow group <Group Name> to inspect autonomous-vmclusters in compartment <Compartment Name>
Allow group <Group Name> to inspect autonomous-container-databases in compartment <Compartment Name>
Allow group <Group Name> to inspect autonomous-databases in compartment <Compartment Name>

Creating at tenancy level:

Allow group <Group Name> to inspect exadata-infrastructures in tenancy
Allow group <Group Name> to inspect vmclusters in tenancy
Allow group <Group Name> to inspect db-nodes in tenancy
Allow group <Group Name> to inspect db-homes in tenancy
Allow group <Group Name> to inspect databases in tenancy
Allow group <Group Name> to inspect pluggable-databases in tenancy
Allow group <Group Name> to inspect autonomous-vmclusters in tenancy
Allow group <Group Name> to inspect autonomous-container-databases in tenancy
Allow group <Group Name> to inspect autonomous-databases in tenancy

Oracle Exadata Database Service on Dedicated Infrastructure

Creating at compartment level:

Allow group <Group Name> to inspect cloud-exadata-infrastructures in compartment <Compartment Name>
Allow group <Group Name> to inspect cloud-vmclusters in compartment <Compartment Name>
Allow group <Group Name> to inspect db-nodes in compartment <Compartment Name>
Allow group <Group Name> to inspect db-homes in compartment <Compartment Name>
Allow group <Group Name> to inspect databases in compartment <Compartment Name>
Allow group <Group Name> to inspect pluggable-databases in compartment <Compartment Name>
Allow group <Group Name> to inspect cloud-autonomous-vmclusters in compartment <Compartment Name>
Allow group <Group Name> to inspect autonomous-container-databases in compartment <Compartment Name>
Allow group <Group Name> to inspect autonomous-databases in compartment <Compartment Name>

Creating at tenancy level:

Allow group <Group Name> to inspect cloud-exadata-infrastructures in tenancy
Allow group <Group Name> to inspect cloud-vmclusters in tenancy
Allow group <Group Name> to inspect db-nodes in tenancy
Allow group <Group Name> to inspect db-homes in tenancy
Allow group <Group Name> to inspect databases in tenancy
Allow group <Group Name> to inspect pluggable-databases in tenancy
Allow group <Group Name> to inspect cloud-autonomous-vmclusters in tenancy
Allow group <Group Name> to inspect autonomous-container-databases in tenancy
Allow group <Group Name> to inspect autonomous-databases in tenancy

Create Named Credentials for OCI Monitoring

To enable access to the Oracle Cloud resources, Enterprise Manager requires API key credentials associated with an Oracle Cloud Infrastructure IAM user. This IAM user must be assigned the required permissions using policies.

For details on creating the required policies, see Create IAM Policies to Support Discovery and Monitoring.

Below are the steps for creating the named credential required for monitoring the Exadata Infrastructure and VM Clusters. This uses the API Signing Key for the Oracle IAM user granted the proper policies above. This is an RSA key pair in PEM format (minimum 2048 bits). See How to Generate an API Signing Key.

Additionally, you will need the fingerprint of the public key. See How to Get the Key's Fingerprint.

Click the setup icon , click Security, and select Named Credentials. The Named Credentials page is displayed.
Click Create. The Create Credential page opens.
Provide the following information:
- Credential Name: Provide a suitable name to the credential. For example, OCI_CREDS.
- Credential Description: Describe the purpose of the credential and the intended use.
- Authenticating Target Type: Specify the target type for which this credential set will be used for authentication. Select Oracle Cloud Infrastructure from the menu.
- Credential Type: Specify the type of the credential that you're creating. Select Oracle Cloud Infrastructure Credential from the menu.
- Scope: Select the visibility of the credential in Enterprise Manager. Select Global.
- Tenancy OCID: The OCID of your OCI tenancy.
- User OCID: The OCID of the user to access OCI.
- Public Key Fingerprint: Provide the fingerprint of the public key of your API signing key pair.
- Private Key: Provide the private key of your API signing key pair.
- Private Key Passphrase: Specify the passphrase of your private key, if any.
Click Save.

Create SSH Based Credentials

The VM Guest hosts are accessed through SSH and therefore the agents must be installed using SSH based named credentials. It is recommended that you use one of the two SSH credential methods described below.

Create SSH based named credentials for the opc user that utilizes sudo to oracle and SSH based named credentials for the opc user that utilizes sudo to root. Provide the private and public SSH keys for the opc user.
Create a new SSH key and add it to the authorized_keys file for the oracle user. Create an SSH based named credential for the oracle user using this newly created private and public key.

For steps to create SSH based named credentials and SSH keys, see Setting Up SSH Key-based Host Authentication in Host Authentication Features.

Create Storage Server Credentials

To associate the storage servers of the grid infrastructure with the cloud target, create a named credential for storing the ExaCLI user name and password used for connecting to the Exadata Storage Server.

For the relevant documentation about the user name and password, see:

Exadata Database on Cloud@Customer: Monitoring and Managing Exadata Storage Servers with ExaCLI in Exadata Database Service on Cloud@Customer Administrator's Guide
Exadata Database on Cloud@Customer: Monitoring and Managing Exadata Storage Servers with ExaCLI in Exadata Database Service on Dedicated Infrastructure

During the discovery of the cloud target, you will point to this named credential set for discovering the storage servers. This must be a named credential of the type ExaCLI or RESTful API.

Click the setup icon , click Security, and select Named Credentials. The Named Credentials page is displayed.
Click Create. The Create Credential page opens.
Provide the following information:
- Credential Name: Provide a suitable name to the credential. For example, EXADATA_CRED.
- Credential Description: Describe the purpose of the credential and the intended use.
- Authenticating Target Type: Specify the target type for which this credential set will be used for authentication. Select Oracle Exadata Storage Server from the menu.
- Credential Type: Specify the type of the credential that you're creating. Select Credential for ExaCLI or RESTful API from the menu.
- Scope: Select the visibility of the credential in Enterprise Manager. Select Global.
- Username and Password: Provide the user name and password to access the storage cells. This is the exacli user that was generated as part of the Exadata Cloud Service setup.
- Run Privilege: You can select the level of privilege provided to the user for access.
- Access Control section: You can add grants, and select the grantee in this section.
Click Save.

You can now view the new credential created in the Named Credentials page.

Agent Installation

Overview of the Required Agents

The Enterprise Manager Agent will be installed on the guest hosts of each VM cluster for the purpose of monitoring the resources that reside in that VM Cluster like host, database, listener, ASM, etc

In addition to these agents, one EM Agent outside of the Exadata Cloud is required for discovery and Exadata Cloud target resource monitoring. This agent is installed in a location that is able to communicate with the OCI API rest endpoints as well as the Enterprise Manager OMS servers. This agent can be used to discover and monitor multiple Exadata Cloud targets. Below are the recommendations for this agent:

The agent should be placed on a host within the customer's data center.
The chosen agent should not be one of the central agents on the Oracle Management Servers (OMS) nor should it be an agent that is installed on one of the VM guest hosts of the Exadata Cloud VM Cluster.
The host should meet the requirements for installing an Enterprise Manager Agent. For details on the host requirements for installing an EM Agent, see Meeting the Generic Prerequisites for Installing Standalone Management Agents Using Add Host Targets Wizard or EM CLI.
For HA/DR considerations, there should be both primary and backup agents selected but care should be taken to consider the proper location for the primary and backup agents.
If Enterprise Manager is configured for HA/DR, agents must be located in sites that are accessible from both the primary and DR Enterprise Manager sites. That is, the agent selected for OCI monitoring should be on a host in the same data center or site where the primary EM is running and the backup agent should be located on a host in the data center or site where the EM DR environment is located.
Agents must be able to communicate to the OCI API Rest endpoints, over public network, using a proxy or VPN.

An Enterprise Manager agent should also be installed on each of the guest VM hosts on the Exadata Cloud VM Cluster for the purpose of monitoring each of the resources that reside in that VM Cluster like host, database, ASM, etc.

Install Agents

Install an agent on the hosts selected for discovery and monitoring of the Exadata Cloud Services.

Install an agent onto each of the VM Cluster guest hosts using the SSH based named credential created earlier. Manually deploy the Exadata Plug-in to these agents.

For steps to install agents, see Installing Oracle Management Agents in Cloud Control Basic Installation Guide.

Set Up a Proxy Connection

To configure the EM agent to connect to OCI through a proxy server, use the following steps:

Log in to your agent host.
Edit the file $EMDROOT/work/agentStateDir/sysman/config/s_jvm_options.opt. Add the following line at end of the file and save the file:
```
-Djdk.http.auth.tunneling.disabledSchemes=""
```
Edit the file $EMDROOT/work/agentStateDir/sysman/config/emd.properties. Include the below properties in the file emd.properties:
```
oci_http_proxy_host= <proxy host>
oci_http_proxy_port= <proxy port>
oci_proxy_username= <proxy user>
oci_proxy_password= <proxy password>
```
Restart the agent:
```
emctl stop agent ; emctl start agent ;
```