2 Prerequisites

This chapter provides the prerequisites for Exadata Database Machine discovery.

The following topics are discussed:

Create a Database Server ILOM Service Processor User

For the Enterprise Manager Agent to communicate with an ILOM service processor, there must be a specific user ID established on the ILOM service processor.

Note:

Adding the specific user ID requires administrator level privilege on the ILOM service processor.

The specific ILOM user ID can be added in the ILOM service processor web interface, ILOM CLI, or with the ipmitool command. This example uses ILOM CLI.

For security reasons, the password to the ILOM service processor root user ID does not appear in the ILOM CLI commands in this example.

  1. Log in to the Service Processor as root:
    # ssh root@[Service Processor IP]
    Password:
    
  2. Change to the users directory:
    # cd /SP/users
    
  3. Create the oemuser user and password:
    # create oemuser
    
    Creating user...
    Enter new password: ********
    Enter new password again: ********
    
    Created /SP/users/oemuser
    
  4. Change to the new user's directory and set the role:
    # cd oemuser
    /SP/users/oemuser
    
    set role='cro'
    Set 'role' to 'cro'
    
  5. Test the ILOM user ID created in step 3 by listing the last 10 system events:
    • For Exadata X2 through X4:

      # ipmitool -I lan -H <ilom_hostname> -U oemuser -P <oemuser password> -L USER sel list last
            10\
      
    • For Exadata X5 and above (requires the -I lanplus command option):

      # ipmitool -I lanplus -H <ilom_hostname> -U oemuser -P <oemuser password> -L USER sel list last 10
      
  6. Repeat steps 1 through 5 for the rest of the compute node ILOM service processors in your Oracle Database Machine.

Create an ExaCLI User

Enterprise Manager can monitor Exadata Storage Servers using cellcli, exacli, or the RESTful API. In order to make use of exacli or the RESTful API, a user must be created. The same user can be used for either exacli or RESTful API. For more information, see Creating Users for Use with ExaCLI in the Oracle Exadata Database Machine Maintenance Guide.

Create SNMPv3 Users

If SNMPv3 will be used for Exadata monitoring, ensure that the necessary SNMPv3 users are created on the components prior to discovering the Exadata to fully leverage monitoring through Enterprise Manager.

Create SNMPv3 Users on Compute Nodes and Storage Servers

The commands required to create SNMPv3 users on compute nodes and storage servers are similar, but make use of different command line interfaces and object names. In the following examples, run cellcli to get to the interactive prompt if on a storage server, and run dbmcli to get to the interactive prompt on a compute node. Specify the appropriate object name, cell for storage server and dbserver for compute node. The instructions differ between Exadata System Software releases. Please see the details for the respective Exadata System Software version in the sections below.

Note:

For additional information on these commands, please see the following references:
  • For information on CellCLI and the alter cell command, see Using the CellCLI Utility in the Oracle Exadata System Software User’s Guide.
  • For information on DBMCLI and the alter dbserver command, see Using the DBMCLI Utility in the Oracle Exadata Database Machine Maintenance Guide.
Create Individual SNMPv3 Users on Exadata 19.3 and Above

Exadata System Software version 19.3 and above supports maintaining SNMPv3 users individually. Use the following command to create an SNMPv3 user.

CLI> alter <cell|dbserver> snmpuser.<username> =(authprotocol=SHA,authpassword=<password>,privprotocol=AES,privpassword=<password>)
Create All SNMPv3 Users on Exadata 19.2. and Below

Exadata System Software versions 19.2 and below require maintenance of SNMPv3 users as a complete set. Use the following command to create an SNMPv3 user.

Note:

Be sure to include the details of all SNMPv3 users as the set will be replaced with this command.
CLI> alter <cell|dbserver> snmpUser=((name=<username>, authProtocol=SHA, authPassword=<password>, privProtocol=AES, privPassword=<password>)[,<repeat_with_details_as_necessary_for_additional_users>]) 

Create SNMPv3 Users on Cisco Ethernet Switches

The below commands configure an SNMP user with authentication and privacy parameters on the Cisco Ethernet switches running NX-OS including the admin switch, and if this is a RoCE Exadata, the RoCE switches.

The passphrase can be any case-sensitive, alphanumeric string up to 64 characters.

switch# configure terminal
switch(config)#
switch(config)# snmp-server user <username> auth sha <passphrase> priv aes-128 passphrase   

The below command displays information about one or more SNMP users.

switch(config)# show snmp user

Once all the configuration changes are done, the below command will save the configuration in persistent memory .

switch(config)# copy running-config startup-config

Create an SNMPv3 User in IB Switches

If the Exadata to be discovered is an IB Exadata, follow the below commands to create an SNMPv3 user on the IB switches.

Log in to the ILOM console of the switch as user ilom-admin.

Create the SNMPv3 user. This is the start of your topic.

> create /SP/services/snmp/users/<username> privacyprotocol=AES authenticationprotocol=SHA privacypassword=<password> authenticationpassword=<password>

Follow the below steps to display information about one or more SNMP users.

> cd /SP/services/snmp/users
> show -d properties <username>   

Enable SNMPv3 on PDUs

Follow the below steps to enable SNMPv3 on the PDUs.

  1. Access the PDU metering unit from a system on the network.
  2. Click on the Net Configuration link and log in as an admin user.
  3. Select the SNMP-Access tab.
  4. Click the SNMP v3 Enable checkbox to enable SNMP v3.
  5. Click Submit.

Create an SNMPv3 user on PDUs

Follow the below steps to create an SNMPv3 user on the PDUs.

  1. Access the PDU metering unit from a system on the network.
  2. Click on the Net Configuration link and log in as an admin user.
  3. Select the SNMP-Access tab.
  4. In the SNMPv3 table, perform the following
    1. Enter the SNMPv3 UserName.
    2. Select the Security Level auth / priv.
    3. Select SHA as the Auth Algorithm.
    4. Enter the Auth Password.
    5. Select AES as the Privacy Algorithm.
    6. Enter the Privacy Password.
    7. Select Enable.
  5. Click Submit.

Verify Software Versions

Verify the following software versions:

Exadata Storage Server Software

See Oracle Exadata Database Machine Supported Hardware and Software for specific supported Exadata Software releases. To verify the cell software version on the Exadata Storage Server, ssh to the Exadata Storage Server as the root, celladmin, or cellmonitor user. Run:

# cellcli -e 'list cell detail'

Look for releaseVersion in the output.

InfiniBand Switch

To verify the version of the InfiniBand switch firmware in your environment:

  1. Log on to the management interface for the InfiniBand Switch (using SSH).
  2. Run the following command:
    # nm2version
    

    The output should be similar to this:

    # nm2version
    Sun DCS 36p version: 2.2.13-2

    This example shows a supported configuration for deploying the plug-in to monitor.

  3. If the nm2version command returns output similar to this:
    # nm2version
    NM2-36p version: 1.0.1-1
    

    Then you must upgrade your InfiniBand switch firmware. Follow the instructions listed in My Oracle Support (MOS) Document 888828,1

PDU Firmware

The PDU firmware version must be 2.10 or later. The current version can be obtained by logging into the web interface of the PDU. On the left side of the screen, click Module Info to view the PDU firmware version.

Software updates for the PDU are available at:

https://updates.oracle.com/Orion/PatchDetails/process_form?patch_num=12871297

Grid Infrastructure/DB Cluster

Grid Infrastructure/DB Cluster is required to be up and running before discovery.

Verify Names Resolution

The Enterprise Manager OMS server(s) require direct network access to each of the compute nodes. If the names of the compute nodes are not registered in the OMS nodes' DNS, then they will have to be manually entered in the /etc/hosts file for each OMS.

Each compute node should be verified to be able to resolve the hostnames of the ILOM servers, PDU's, Exadata Storage Servers, and InfiniBand and Cisco switches. Again, if the names of those components are not registered in DNS, then entries can be added to the /etc/hosts file of each compute node.

To manage the Exadata Database Machine components from Enterprise Manager Cloud Control 13c, it is necessary for your local machine to be able to resolve the host name of Cloud Control 13c.

To access any of the Exadata Database Machine components directly from your local machine, it is also necessary for your local machine to be able to resolve the names of those components.

Verify Firewall Configuration

To verify the firewall configuration:

  1. Enable ping

    In many secure network environments, it is normal for the ping service to be disabled. Enterprise Manager uses ping to establish the basic availability and status of the Exadata Database Machine components.

    • The compute nodes need to have the ping service and port enabled from the OMS Server(s).

    • All other Exadata Database Machine components (ILOM servers, PDU's, Exadata Storage Servers, InfiniBand switches, and Cisco switch) need to have the ping service and port enabled from the compute nodes (where the agents are running).

    Note:

    The ping traffic overhead is minimal. The agent pings the targets every five minutes.

  2. Open Database Ports

    The database listener ports must be opened for the Enterprise Manager OMS server(s). Note that Exadata Database Machine databases will use SCAN listeners; so, ports will need to be opened for the base compute node, the compute node virtual IP, and scan listeners addresses.

    For example, if an Exadata Database Machine quarter rack has been configured with two compute nodes - 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 compute node hostnames - exadbnode1.example.com and exadbnode2.example.com

    • The virtual IPs for each compute node - exadbnode1-vip.example.com and exadbnode1-vip.example.com

    • The scan listener hostname - scan-exadatadb

  3. 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 will need to be opened for each of the compute nodes.

  4. Open Agent Ports

    The OMS server(s) will need to be able to connect to the Enterprise Manager Cloud Control 13c Agent HTTP/HTTPS port on each compute node. 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 compute node 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

  5. Open SSH Ports (port 22)

    The Enterprise Manager Cloud Control 13c Agents require ssh access to the Exadata Database Machine components they monitor. As the Agents will run on the compute nodes the ssh ports, 22, on each of the Exadata Storage Servers, ILOMs, PDUs, InfiniBand switches, and Cisco switch will need to be opened for each of the compute nodes.

  6. Allow UDP Traffic (SNMP Ports) (Port 162)

    All Exadata Database Machine components need to be able to send SNMP traps to the Agents running on the compute nodes. SNMP uses the UDP protocol so the Agent port and port 162 need to be opened for UDP traffic between the Exadata Storage Servers, ILOMs, InfiniBand Switches, Cisco Switch, and the Agent.

Table 2-1 Firewall Ports

Component Ping service and port SNMP* SSH (port 22) Notes

PDU

From remote agent

Yes

Yes

Compute node ILOM

From remote agent

Yes

Yes

  1. Remote agent needs to be able to SSH to dom0.

  2. Need SNMP port open on dom0.

dom0

From EM OMS server

Yes

Yes

Cell

From remote agent

Yes

Yes

InfiniBand Switch

From remote agent

Yes

Yes

Cisco Switch

From remote agent

Yes

Yes

KVM

From remote agent

Yes

May not be required, if X5 does not have KVM

OMS

Yes

Upload http/https port - usually 3872

Agent

The OMS server(s) will need to be able to connect to the Enterprise Manager Cloud Control Agent HTTP/HTTPS port on each compute node. The Agent port defaults to 3872. If port 3872 is not available, the next available port starting from port 1830 is used.

Enable Support for IPv6 Environments

Note:

Internet Protocol version 6 (IPv6) is the most recent version of the Internet Protocol (IP), the communications protocol that provides an identification and location system for computers on networks and routes traffic across the Internet.

To perform an Exadata Database Machine discovery on IPv6-based client or management network, you must deploy agents on a host that supports dual stack (IPV4 and IPV6).

If the compute node hosts are pure IPv6-based hosts, then deploy the agent on a remote host that supports both IPV4 and IPV6 and perform "remote agent" based discovery.

This agent deployment is needed for monitoring those components in Exadata Database Machine that do not yet support IPV6 (for example, Infiniband Switch and PDU. For more details, see IPv6 support status on Exadata Database Machine (Doc ID 2056895.1), available in My Oracle Support.

Oracle SuperCluster Prerequisites

Table 2-2 shows the required versions of OneCommand and Config-O-Matic (COM) supported by the Oracle SuperCluster hardware configurations.

Table 2-2 Oracle SuperCluster Prerequisites

Hardware Configuration OneCommand Version Config-O-Matic Version

M6-32

databasemachine.xml only

14.063 and later

1.6.4 and later

T5-8

databasemachine.xml

14.042 and later

1.5.8 COM and later

T5-8

catalog.xml (non-Java OneCommand)

n/a

1.5.4 COM and earlier

T4-4

catalog.xml only

Note: Because the T4-4 Oracle SuperCluster is at its "end of life," this entry is only for existing systems.

n/a

1.1.6 COM and earlier

User Roles

To manage the Exadata Storage Server, you need to create roles and then assign roles to administrators. Creating these roles restricts the privileges that each user has, for example in deleting the plug-in or accessing reports. See Oracle Exadata Database Machine Administration.

Install Oracle Management Agent

Enterprise Manager Exadata discovery supports the use of either management network hostname or client network hostname for the compute nodes. When installing the Oracle Management Agent on the compute nodes, you should use the same hostname as used in Oracle Clusterware.

You can identify the hostname of the nodes in the cluster by running the olsnodes command on one of the compute nodes. It is recommended that a fully qualified hostname, including the domain name, be used when specifying an Oracle Management Agent hostname.

Oracle Management Agents need to be installed on each compute node and must not be installed on any other Exadata Database Machine components. For physical Exadata, the agents should be installed on each compute node. For virtual Exadata, the agents should be installed on each domU (virtual machine), and not on the dom0 (hypervisor).

For information on installing agents refer to the Oracle Enterprise Manager Cloud Control Online Documentation Library, Release 13.3 (Installing Oracle Management Agents in Cloud Control Basic Installation Guide).

Manually Deploy Exadata and Related Plug-ins

The Exadata and related plug-ins are automatically deployed to the agent as part of discovery.

You may need to manually deploy the Exadata and related plug-ins to the agents on each of the compute nodes when upgrading an existing agent plug-in installation. Deploy the Exadata, Systems Infrastructure, and for virtual Exadata the Virtual Infrastructure plug-ins manually if an older version of the plug-in(s) has been deployed to the agent already and you would like to upgrade to the latest version of the plug-in(s) deployed on the OMS.

To determine if the Exadata, Systems Infrastructure, and Virtual Infrastructure plug-ins are deployed on each compute node and what versions they are, you have two options:

  • From a terminal window, run the following command:

    emctl listplugins agent

    Note:

    The emctl listplugins agent command must be run on the compute node using the emctl in the agent installation directory.

  • From Enterprise Manager Cloud Control, click the Setup menu (upper right corner), Extensibility, and then Plug-ins.

To manually deploy the Exadata and related plug-ins:

  1. From the Enterprise Manager home page, click the Setup menu (upper right corner), Extensibility, and then Plug-ins.
  2. On the Plug-ins page, select the plug-in of choice from the Name list.

    Note:

    Please check Exadata Storage Software Versions Supported by the Oracle Enterprise Manager Exadata Plug-in (Doc ID 1626579.1) on My Oracle Support for the latest supported plug-ins. Oracle recommends that you deploy the latest version of the Exadata and related plug-ins to the agent.

  3. With the plug-in selected, click Deploy On, then Management Agent.
  4. On the Deploy Plug-in on Management Agent pop-up, click Add. A search pop-up will appear to allow you to search for targets to add. In the Target Type drop-down, select Agent, then click Search.

    Select a Target name from the results list and click Select. Repeat for each agent target.

  5. After you have added the agents, click Next on the Deploy Plug-in on Management Agent screen to review and verify the agent information.
  6. Click Deploy to deploy the plug-in to the agents.
  7. Once the plug-in has been deployed to all agents, a confirmation screen will appear. Click OK to dismiss the pop-up or Show Status to display the status of the agent in the Enterprise Manager Deployment Activities screen.