Re: SMI-S Vs Vendor specific API's for monitoring SAN

229 views
Skip to first unread message

Jeffery Kuhn

unread,
Jan 20, 2013, 6:48:18 PM1/20/13
to smi-s-devel...@googlegroups.com
From my experience, which is limited to the 'block server performance' subprofile, is the way to find out if its supported is by looking in the interop namespace. (Needs to be provided by user usually) looking in the registered_profile class looking for instances with specific 'registeredName' properties. This detail is usually in the text of the spec doc, for the block profile. I can email you the like tomorrow if I remember. 
The diagrams should show you a starting point, then you just follow associations. What kind of information are you looking for?
But even then, there's no substitute for experience with each vendor array type. If you can get your hands on the smis programmers guide from each vendor, that is usually the best. 

Sent from my iPhone

On Jan 20, 2013, at 5:49 PM, Rajesh Prabhu <rprab...@gmail.com> wrote:

Hi Jeffery,
 
You have mentioned that the information collected varies by vendor. Its because vendors have a discretion to implement the optional things defined in the spec. I want to know how to determine if a vendor has supported the optional items that is optional profile and optional elements defined by the profile. If a vendor's product is SMI-S compliant at least I can identify all the component profiles supported mandatory or optional over SNIA link since the profiles supported are published. But how to confirm if the optional elements within a given profile is implemented or not. FYI I don't have the vendor storage system with me but I just want to figure it out just by looking at the vendo information published under the CTP test section on SNIA site.
 
Thanks
 
Rajesh

On Wednesday, January 2, 2013 10:29:59 PM UTC+5:30, Jeffery K. wrote:
Well, having written a SMI-S performance based monitoring solution over the past 2 years, I can tell you that you can definitely gather and monitor statistics using SMI-S. What you can collect varies by Vendor, but there are a few metrics in each of the various categories that are mandatory. By categories, I'm referring to the different ElementTypes that are available via the Block Server Performance Subprofile, in the BlockStorageStatisticalData class instances. I.E, top level Array metrics, Volume, Disk, Fiber Channel ports, Front-end Adapters, Back end Adaptors, composite extents, etc.
If you'd like to learn more about performance monitoring in SMI-S, I'd recommend downloading the latest SNIA specification for 1.5, for the Block Profile. In there is documentation on the Block Server Performance Subprofile. That is where all the performance metrics are stored.

If you'd like more information about our Performance Monitoring and Capacity Planning Solutions, feel free to e-mail me directly, or check out our website. http://www.sightlinesystems.com

sup...@sightlinesystems.com


On Wednesday, January 2, 2013 4:01:54 AM UTC-5, Anmol Rastogi wrote:

Hello SMI-S Gurus,

 

I got the requirement about the SAN monitoring from one of my client and i found over the net that SMI-S is the one which provides the heterogeneous solution of monitoring SAN environment. My client told me that SMI-S is mostly monitors the configuration metrics and not to the extent of performance metrics. Can someone please let me know his/her experience about the SMI-S development? Also it would be great if some can suggest me the good references to start with SMI-S programing and SAN technology.

 

Do I need to leave the scope for further developing the monitoring solution using the vendor specific API or SMI-S is enough for monitoring SAN?

--
You received this message because you are subscribed to the Google Groups "SMI-S Developers Group" group.
To view this discussion on the web visit https://groups.google.com/d/msg/smi-s-developers-group/-/_-FUFkWnMTsJ.
To post to this group, send email to smi-s-devel...@googlegroups.com.
To unsubscribe from this group, send email to smi-s-developers-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/smi-s-developers-group?hl=en.

Paul Robert Marino

unread,
Jan 22, 2013, 6:53:49 PM1/22/13
to smi-s-devel...@googlegroups.com
Rajesh and MrBean

There is an easy way to do this if you understand how the underlying
CIM base API works.
SMI-S is simply a set class profiles that sit ontop of the CIM base
class profiles so to do any thing advanced like detect what specific
capabilities of a profile or provider

to truly understand this you need to read DSP0153 ,DSP0200, and a few others


The easiest way to find a vendors specific implementation of a class
is to do an enumerate class names with deep inheritance set to True
From DSP0200
"
EnumerateClassNames <className>*EnumerateClassNames (
[IN,OPTIONAL,NULL] <className> ClassName = NULL,
[IN,OPTIONAL] boolean DeepInheritance = false
)
"
This will return the list of classes that inherit from the class you
specify in the ClassName field so if you set ClassName to the names of
the SMI-S class it will return its own class name and the vendor
specific class names that were built on top of it.


to find out whats actually supported do a get class on the vendor
specific version of the class
the result of the get class on the vendor specific version of the
class will tell you whats supported.
From DSP0200
"
GetClass <class>GetClass (
[IN] <className> ClassName,
[IN,OPTIONAL] boolean LocalOnly = true,
[IN,OPTIONAL] boolean IncludeQualifiers = true,
[IN,OPTIONAL] boolean IncludeClassOrigin = false,
[IN,OPTIONAL,NULL] string PropertyList [] = NULL
"
warning this will tell you more than you ever wanted to know about the
class unless you chop it down by specifying the list of properties you
want to know about.



To find out a list of the namespaces in your WBEM server, first find
out what the interop namespace is for your WBEM server its usually
root/interop however there are some exceptions like older versions of
openpagasus use root/PG_Interop but the newer versions partially
support root/interop

next do an enumerate instances of the of the CIM_Namespace class from
the interop namespace






On Mon, Jan 21, 2013 at 12:40 AM, Rajesh Prabhu <rprab...@gmail.com> wrote:
> Hi Jeffery,
>
> Thanks for the prompt reply and the guidance. Based on your response it
> seems that if you don't have access to vendor's system nor the smi-s
> programmers guide from the vendor, then there is no way to determine which
> optional items/elements have been implemented. Even the information
> published for the vendor's product on the SNIA site under CTP test
> compliance link wouldn't help. Looking forward to your response and any more
> details you can provide as help.
>
> Regards
> Rajesh
> https://groups.google.com/d/msg/smi-s-developers-group/-/jf0sJoyT_GUJ.

Paul Robert Marino

unread,
Jan 22, 2013, 7:23:39 PM1/22/13
to smi-s-devel...@googlegroups.com
Oh by the way as far as block statistics capabilities read
http://www.snia.org/sites/default/files/SMI-Sv1.3r6_Block.book_.pdf

an other quick read to get you started is here
http://snia.org/sites/default/files/SMI-S_Data_Collection.pdf


specifically you want to look at the BlockStatisticsCapabilities class
each vendor has their own version for example LSI mid range sans call
it LSISSI_BlockStatisticsCapabilities but you can discover it by the
method I mentioned below. most but not all vendors just name their
classes as <MANUFACUREANDPRODUCTLINEAPI>_<ORIGINALCLASSNAME>

Paul Robert Marino

unread,
Jan 23, 2013, 1:31:11 PM1/23/13
to smi-s-devel...@googlegroups.com
the vendor profiles inherit from the common profiles think of the
common profiles as a boilerplate they are required to use to build
their own vendor specific profiles.

Most of the base profiles that underlying SMI-S and all the vendor
implementations can be found here

http://dmtf.org/standards/profiles

vendors may create custom profiles that inherit from these and any of
the SMI-S standard profiles and have additional vendor specific
features, but they can only create a completely custom profile if no
existing profile from the standards applies to a portion of their
product which is extremely rare to the point where I haven't heard of
any vendors actually needing to do it.

On Wed, Jan 23, 2013 at 4:05 AM, Rajesh Prabhu <rprab...@gmail.com> wrote:
> Hi Paul,
>
> Thanks for the clarification and detailed explanantion. This will really
> help. I have found that there are common profiles defined under
> http://snia.org/sites/default/files/SMI-Sv1.5r6_CommonProfiles.book_.pdf
> I have seen storage array vendors have implemented common profiles such as
> fan, power supply etc. Can vendors implement the common profiles at their
> discretion as appilcable to them. This is over and above what is actually
> defined as optional subprofiles and packages under the autonomous Array
> profile. I believe common profiles need not be dictated by Array profile or
> its subprofiles.Also common profiles are not certified as free-standing
> entities, only as a dependency of a storage profile. I would appreciate if
> you can clarify this point.
>
> Regards
> Rajesh
>
> On Wednesday, January 23, 2013 5:23:49 AM UTC+5:30, Paul Robert Marino
> https://groups.google.com/d/msg/smi-s-developers-group/-/BPNRrT1VSLsJ.
Reply all
Reply to author
Forward
0 new messages