Enterprise Manager for Exadata
 
Exadata X4-2 Full Rack
 

PLA-Support>Eng Systems>Exadata/ODA/SSC>Oracle Exadata>DB: Exadata_EST
 

During discovery of Exadata Database Machine in EM Cloud Control, all properties such as credentials and SNMP Commiunity String values are saved.  But what about changes that took place after discovery?  How do we update EM with the new values?  This document explains each step required to accomplish this goal.

In this Document

Symptoms

Changes

Cause

Solution

Here is how to sync-up EM configurations with the new SNMP Community String changes that were made to each component: For compute nodes:

For storage cells:

For IB switches:

For Cisco switch:

For PDU's:

For KVM:

References

Created from <SR 3-10113596921>

Applies to:

Symptoms

Enterprise Manager Cloud Control no longer collects metrics or triggers alerts for managed targets such as Exadata Infiniband Switch, Cisco Switch and Exadata Storage Cell Servers.

Changes

SNMP Community String was changed on one or more of the Exadata components.

Cause

EM was not updated with the new values for SNMP Community String.

Solution

 It is best to allow EM to configure subscriptions to SNMP services on all components during discovery than to manually configure them after discovery.  But it is possible to manually configure each target after they are discovered. 

Enterprise Manager Cloud Control uses various methods to collect metric telemetry data and alerts from Exadata components.  For example:

Compute nodes:  Local OS calls such as memory, CPU, disk and various device queries.  No SNMP calls are needed.

Storage Cells:  Remote cellcli calls via ssh commands wrapped in PERL scripts.  Each cell is configured to register the compute node agents as snmpSubscribers, which means whenever there is an alert, the cell fires off a trap with the alert details to the EM agen.  No snmp gets are performed.  However, alerts that trigger on the storage cell require a reachable SNMP Subscriber (with a reachable SNMP Community String) to which the alerts must be delivered.

InfiniBand and Cisco switches:  Remote snmp get commands to read various KPI's to report to EM.  This will need SNMP read only access from the compute nodes where the monitoring agents are running.

Compute node ILOMs: Remote ipmitool command queries wrapped in PERL scripts.

Here is how to sync-up EM configurations with the new SNMP Community String changes that were made to each component:


For compute nodes: 

No changes are needed.  EM does not rely on SNMP to monitor compute nodes.  Although any changes to the compute node SNMP daemon must be in sync with SNMP subscribers from other components.  See Storage Cells for example.

For storage cells:

Ensure that snmpSubscribers property lists each monitoring agent for the particular cell.  Usually you have 2 agents per storage cell.  Of course the agents are installed and running on compute nodes, NOT cells. 

See the Post Discovery Configuration And Verification manual here: http://docs.oracle.com/cd/E24628_01/doc.121/e27442/ch4_post_discovery.htm#EMXIG145

Section 4.2

In summary: use cellcli to update snmpSubscriber.  For example:

# cellcli -e list cell attributes snmpSubscriber

# cellcli -e list cell attributes snmpSubscriber
((host=[hostname.mycompany.com],port=3872,community=public),
(host=[hostname2.mycompany.com],port=3872,community=public)) 

For IB switches:

Update EM configuration from the EM console directly by accessing the Administration link from the Infiniband Network target, then select the IB switch hostname and update its snmp community string as described in section 4.3.1 of the Post Discovery Configuration And Verification manual here: http://docs.oracle.com/cd/E24628_01/doc.121/e27442/ch4_post_discovery.htm#EMXIG145

For Cisco switch:

There is no facility to update SNMP community string after the target is discovered.  You can update the property in the monitoring agents' targets.xml files.  This file is located in the monitoring agent's AGENT_BASE/agent_inst/sysman/emd directory.  Update it as follows:

Locate the oracle_exa_cisco_switch target section
Scroll down to the section header:

Edit this line and change both VALUE field and ENCRYPTED.  For example, if the new community string is public123, then the line above should be:

Restart the agent:
$ emctl stop agent
$ emctl start agent

For PDU's: 

There is no facility to update SNMP community string after the target is discovered.  You can update the property in the monitoring agents' targets.xml file the same way as the Cisco switch, except look for oracle_exa_pdu targets.

 For KVM:

No SNMP queries required for monitoring this target.  EM uses host target type PERL collection scripts for Response and Status.

Platinum monitoring uses the same exact setup as any other local EM deployment with the exception of the gateway server, which is configured to connect to Oracle network and log service requests.

References

This solution has no attachment