The community will be in read-only from Tuesday 11:59pm (PST) to Wednesday 7:30am (PST)
The community will be in read-only from Tuesday 11:59pm (PST) to Wednesday 7:30am (PST)
Storage Essentials Practitioners Forum
Showing results for 
Search instead for 
Did you mean: 

(SOM) Support Tip: Discovery/Data Collection differences between SOM and SE

Regular Collector

(SOM) Support Tip: Discovery/Data Collection differences between SOM and SE

Hello Storage Operations Manager (SOM) and Storage Essentials (SE) Users ,


I’d like to take the opportunity to explain some major differences with regards to Discovery and Data Collection between Storage Essentials (SE) and Storage Operations Manager (SOM). For those of you who are familiar with SE and recently started using SOM, it will be important to understand these differences as the concept changed a bit, which has an impact on updating information when an Access Point manages multiple Nodes in SOM.

In Storage Essentials a Data Collection is called GAED (Get All Element Details). When you successfully discover an Access Point managing multiple Elements in SE, the Access Point gets passed into Discovery Step3 as a single entry with multiple Elements behind.

For example if you have a host running the BNA (Brocade Network Advisor), SE captures the information about the switches managed by BNA through BNA’s SMI-s provider. In this case the BNA would be the Access Point and the multiple Elements behind are the SAN Switches. 

Some more examples of Access Points managing multiple Elements are:

VC                VMware Virtual Center managing multiple ESX Servers

ECOM/ECIM  EMC’s SMI-s provider managing multiple EMC Arrays (Clariions, VNXs, Symmetrix etc.)

CV-EVA        CommandView EVA managing multiple HP EVA Arrays

In SE a GAED can only be performed against the whole Access Point, so if you do have 40 SAN Switches managed by BNA, SE captures information about all the SAN Switches.

Getting an update on a single SAN Switch managed by BNA is not possible. Similar to this is the concept of Discovery Groups in SE. A GAED on Elements using SE’s ‘internal’ provider can only be performed against the whole Discovery Group. Let me quickly try to explain what an ‘internal’ provider means in SE.

SE uses different mechanisms (protocols) in order to capture information from an element. SE’s core engine is JBOSS - if JBOSS can talk directly to an element, the provider is considered as ‘external’ provider, since the information comes directly from the Element. Basically each SMI-s provider and the SE Agent (which is also a kind of SMI-s provider) are external providers. These Elements represent their own ‘Discovery Group’ in SE.

For some Elements it is required to have a kind of ‘translator’ in between. The CIMOM (Common Information Model Object Manager) module of SE can be considered as such a translator. The CIMOM loads provider specific code in order to talk to an element. For example a HP P4000 Array gets discovered by using SSH queries (LHN Provider),

CISCO Switches get discovered by using SNMP (CISCOSNMP Provider), Virtual Center/ ESX Servers get discovered through API calls to the SDK of VC/ESX Server (VCProvider) etc.

The CIMOM also transforms the received data into a SE compatible Data Format (Data Model) so that it can be populated into the SE Database.

Since JBOSS first talks to its internal CIMOM in order to get Data from these specific Elements, the provider is considered as ‘internal’.

Elements requiring the CIMOM in order to be discovered are always members of a pre-defined Discovery Group. Each of these Discovery Groups (if used) run their own CIMOM process. (e.g. StorCimomDefault for Default Discovery Group, StorCimom1 for Discovery Group1 etc.).

When you run a GAED against a Discovery Group, all Elements being member of the Discovery Group get queried.


-Changes in the provider like adding a SAN Switch or ESX Server get reflected automatically in SE

 Main Disadvantages:

-All Elements behind a provider get queried, querying data from only one Element behind a provider is not possible

-All Elements of a Discovery Group get queried when a GAED is performed

-Discovery and GAED process are exclusive and cannot run at the same time. Report Cache Refresh (RCR) doesn’t start if a GAED is in progress.

-Multiple GAEDs cannot run at the same time

-Collectors get rejected when a GAED is in progress (leads e.g. to gaps in the performance data collection)


Let’s have a look at SOM.

Where in SE the term ‘Element’ was used, in SOM the same is called Node(s). So a Node can be a SAN Switch, a Storage Array, Host etc.

If a successful Discovery against an Access Point, with multiple Nodes behind, is performed, each of the Nodes get a separate entry in the SOM Inventory.

The Access Point itself will not be added to the inventory, even if still be used in order to capture information about the Nodes behind.

This allows you to run a Data Collection (in SE called GAED) on a single Node behind an Access Point.

Since the Access Point itself is not as a Node in the Inventory of SOM, it will be required to manually run another Discovery in case additional Nodes were added to the Access Point.

For Example if you do have a Virtual Center managing 4 ESX Servers, after the Discovery each of the ESX Servers will be presented as a single Node in the SOM Inventory.

If you add a 5th ESX Server to the Virtual Center, it will be required to perform a manual Discovery against the VC in order to have the 5th ESX Server showing up in SOM.

Changes within a Node get covered by the Data Collection. E.g. if a VM gets created or deleted this gets reflected in SOM after a Data Collection was done. So in this case no Discovery of the VC is required.

Advantages in SOM:

-no Discovery Group Concept - if a kind of internal provider is used, Data Collection can be performed on single Nodes

-Discovery and Data Collection(s) can run in parallel (prevent the same on the same Node)

-Collectors continue to run even if a Data Collection is in progress

-much better scaling with regards to Data Collection process

-Report Cache has been converted to .csv file transfer to SOM Reporter Server (SHR/OBR)

-Data Collection is done on single Node behind an Access Point managing multiple Nodes

-Deletion of ‘unwanted’ Nodes will not bring them back until a Discovery is performed. In SE a customProperty was required (if available) to e.g. exclude ESX Servers in order to save MAP licenses otherwise they came back after the next GAED against the Provider.

 Current Disadvantage:

-Changes on the Provider side (e.g. adding a SAN Switch to BNA or adding a ESC Server to VCenter) get not automatically reflected in SOM and a manual Discovery is required to achieve the same.

 Currently we investigate in methods how to ‘Scheduled’ Discoveries in case required.

 A word about decommissioning Elements/Nodes behind an Access Point.

There is only a slight difference between SOM and SE.

I you e.g. decommission a SAN Switch or take it offline for maintenance, the SAN Switch gets reported as ‘missing’ in SE.

It will automatically come back with ‘normal’ status in SE, if the SAN switch is operational again. In case the SAN Switch was really decommissioned it had to be deleted manually in SE’s System Manager. In SOM the SAN Switch will go into status ‘quarantine’ if multiple attempts to contact the SAN Switch will fail in a row. So you will have to manually ‘un-quarantine’ the SAN Switch in SOM UI in case it came back to operation. Deletion is similar like in SE. If the SAN Switch was decommissioned you will have to delete it manually from SOM’s Inventory.


Hope that helps


//Add this to "OnDomLoad" event