In the previous series I showed how to create the datasource and 2 discoveries. This part will cover the more complex discoveries.
First I will start by creating a new datasource for extracting the Index number.
This part is from Kristopher Bash his solution on creating SNMP management packs for network devices as I explained I used his approach as a baseline for this Management Pack.
Let’s take the last part of the Aggregate Discovery
Besides the OID and AggrName there are more properties which I will cover each in this series. As stated we start with the Index Property.
Why is this index number so handy?
Well the example for the Aggregate isn’t that great but let’s assume we want to discover more properties for the aggregate we add one for aggrRaidType.
How would we discover the aggrRaidType property for each aggregate?
We know we need to query OID .184.108.40.206.4.1.7220.127.116.11.1.11 for the aggrRaidType but we also need to know the index number from the aggregate to query the correct one.
|.18.104.22.168.4.1.722.214.171.124.1.2.1||Aggregate Name 1|
|.126.96.36.199.4.1.7188.8.131.52.1.2.2||Aggregate Name 2|
|.184.108.40.206.4.1.7220.127.116.11.1.2.3||Aggregate Name 3|
Above are the properties for each aggregate we discovered. We did a walk on the aggrName OID .18.104.22.168.4.1.722.214.171.124.1.2 for the discovery and the last number of the OID of each aggregate instance is the index number.
We are going to create a datasource for extracting (discovering) the Index number for each Aggregate class instance by using a script based discovery on the OID property of each aggregate.
Create a datasource named NetApp.Management.Pack.Datasource.Discovery.ObjectIndex Create 3 Modules:
The scheduler is the same as in our previous discoveries.
The script uses 1 parameter $Config/OID$ which we are going to declare in the actual discovery. This parameter will be the OID property of the aggregate.
It passes the OID to the script which extracts the index number and put it in a property bag named “Index”
This one is different then our previous one. The XML will look like below:
Be aware though that you cannot add these settings in the Authoring console. You will receive the error below:
A work around this issue is don’t change the default Mapper settings.
Fill in the Configuration SchemaTab:
Add Schema References:
Add Simple Configuration Schema:
Save your MP and open it in XML editor and change the values.
Now save it again and open it in the Authoring console again and add the following in your Simple Configuration Schema:
The reason for designing the mapper this way is we can use this datasource now universal in all of our discoveries for the NetApp Management Pack. I will show you the actual discovery to explain.
Create a new custom discovery rule NetApp.Management.Pack.Discovery.NetApp.Aggregate.Index target it at the NetApp Aggregate Class
As a Datasource use your newly created datasource NetApp.Management.Pack.Datasource.Discovery.ObjectIndex
We can now fill in the appropriate settings according to the Configuration Schema:
Simply add the appropriate values and notice we are actually not discovering anything except the index number!
All Settings are derived from already discovered components and because we designed the mapper in a universal way the datasource can remain the same only the parameters are changing.
The reason for first designing the datasource and discovery for the index number is we are going to use this one in our next discovery which is more challenging the NetApp Volume which is hosted by the NetApp Aggregate which is hosted by a NetApp Filer!
Discovery of NetApp Volume
Now this is where the fun starts. Because we want to discover a volume which is hosted by an Aggregate we need to design something which is more challenging.
When you browse over the MIB by SNMP and look for the volume property it looks pretty simple at first besides the aggrtable we used in our previous discovery there is also a volTable!
Just use the same approach as the aggregate one would say!
Well in fact not…….. let’s think about it for a while. We want the volume to be hosted by the aggregate and not by the filer. There is our first difference…… well just add another key property of the aggregate which hosts the volume in our discovery then… nope although this will get the volumes discovered correctly there is a big downside.
Since the discovery will be targeted at the Aggregate Class the discovery will run on each aggregate class and start discovering volumes. When testing this with one aggregate this looks ok. But when you add another aggregate (or more) you will notice the error. On each aggregate all volumes will be discovered! So each aggregate will host all volumes on the filer and this is simply not the case…..
Back to the drawing board then.
In our Volume discovery we need to actually discover the Aggregate as well. We will need to find a way to discover a NetApp volume and on which aggregate the volume is hosted in 1 discovery!
Well let’s browse some more the NetApp MIB and finding some value which will cover both the Volume as well as the aggregate. This way we can discover both in one discovery.
hmm remember our earlier Aggregate discovery, let’s go to the aggrtable again:
Now there is a very interesting OID when you look at it’s description “List of all the flexible volumes within this aggregate”
When you do a get on this OID you will receive a list of all volumes hosted by the aggregate!
Because we created a discovery to discover the index number property of an aggregate we are able to target this OID directly in 1 SNMP get! This is the first part of the solution.
Let’s start designing the Datasource for this one:
the same as previous datasources
Notice we are going to use a parameter index which we are going to fill with the aggregate class property named “index”.
Now for the script Discovery which is the second part of the solution!
First we need to pass the following parameters to the script:
$Target/Property[Type=’NetApp.Management.Pack.Class.NetApp.Aggregate’]/AggrName$ <———————-keyproperty of Aggregate class
$Target/Host/Property[Type=’MicrosoftSystemCenterNetworkDeviceLibrary!Microsoft.SystemCenter.NetworkDevice’]/IPAddress$ <—-key property of a network device
“$Data/SnmpVarBinds/SnmpVarBind/Value$” <——collected SNMP get Value of aggFlexvollist
We are now using our datasource to do a SNMP get and retrieve a value and after retrieving the value pass it together with more parameters to the scriptdiscovery. This is one of the real benefits of using datasources you can manipulate data to the wanted output.
Now for the configuration schema tab:
Now the datasource is finished for discovering volumes. Now you can again create a discovery rule target it at the aggregate class and fill in the correct parameters.
The Datasource to discover a volume works as follows. We know the aggregate index number which is unique to each aggregate hosted on one filer.
Because we know the index number we can query the oid we are interested in expanded by the index number parameter of the aggregate which for aggregatename 1 would be .126.96.36.199.4.1.7188.8.131.52.1.9.1
This SNMP get with OID number .184.108.40.206.4.1.7220.127.116.11.1.9.1 will retrieve a value: a list of volumes divided by spaces belonging to aggregatename 1
This list of volumes residing on this aggregate (Aggregate 1) is now passed to a discovery script where the list is divided by spaces and for each volume a new volume class is created with it’s key property Volname!!
Because each aggregate queries the oid attached with it’s own index number we are sure we are collecting the correct volumes for the effected aggregate!
Discovery NetApp Lun
Okay now for the last one in the chain. Again our previous approaches are not sufficient for this one so I needed to take another approach to discover the NetApp Luns.
Although as stated before it is possible to discover the NetApp Luns if they are hosted directly by the NetApp filer it is more challenging and fun to let them be hosted by the actual part which is the volume! 😉
First let’s take a look at the class we want to discover.
Remember as with our previous discoveries, discovering the key property of the class and it’s hosted classes are essential! Discovering other properties can be done in a second discovery.
Again we use our SNMP browsing tool to look for the appropriate value that will deliver us both the Volume key property as well as the Lun key Property
After browsing you will notice the lun table is beneath blocks instead of filesys as our previous OID’s.
Now when we do a SNMP walk on the Lunindex we notice a value called LunName. The description sounds interesting “The name of the lun. This is also the path to the LUN on the Filer.”.
When we do a get on this OID you will notice the path saying something similar to /vol/vol1/lun
This path or lunName value includes the hosted volume name!
Now let’s build the datasource NetApp.Management.Pack.DataSource.Discovery.Lun
Same as previous datasources
The SNMP probe is the same as doing an aggregate discovery only we are now querying another OID.
Now this one is different and this is the part what makes the solution work correctly!
Notice the high lighted part! The filter is a regex expression which filters the Value collected.
let’s take the earlier example of /vol/vol1/lun1
The filter looks at the collected value and searches if the value contains substring /vol1/ if it does the value is passed to the mapper if not the data is discarded.
(The reason for adding “/” is if there are volumes named the same as the lun the filter will not correctly work)
Since we target the discovery at the netapp volume class for each volume the discovery will run but will only retrieve discovery data if the value is passed the filter!
The mapper looks the same as the one we used in our previous discoveries.
As for the configuration schema:
Now the datasource is finished for discovering Luns. Now you can again create a discovery rule target it at the Volume class use the new datasource and fill in the correct parameters.
The discovery of the netapp Luns works as follows we do a SNMP walk on the LunName OID .18.104.22.168.4.1.722.214.171.124.2.1.2 and retrieve all LunName Values.
We pass these values through the Filter and only the ones which have the correct volume name in the LunName value are passed to the mapper to be discovered!
Wrap Up Part 3 of the series
We are now able to discover all our classes. If we look at a diagram view for one filler the results should be something like below.
The next series part 4 will cover the next steps in the MP which are discovering and explaining other class properties and creating performance counters.
Also there will be a example MP in it which have all the components as explained in the series….