Direct 7mode and cDOT Script Data Sources

[ktim]

Here are some data sources I put together to make it easier to use WFA to deliver a transition tool I am working on. Not everyone has pre-existing OCUM and installing and configuring OCUM for both 7mode and cDOT is not necessarily a small task. These datasource types populate the standard storage and cm_storage schemas which can then be used as normal with many workflows.

The cDOT direct data source is fairly complete. However it does not populate the following: disk, disk_aggregate, efficiency_policy. There are also some minor gaps in some of the data.

The 7-mode source is less complete. It contains: array, vfiler, aggregate, interface, volume, vsm, qtree, lun. It is missing: array_license, cifs_share, cifs_share_acl, dataset, disk, igroup, igroup_initiator, lunmap, nfs_export, object_comment, quota, snapshot, snapvault, user_quota.

Configuration is simple:

1. Provide credentials for the arrays/clusters in WFA credentials.
2. Add datasource.
3. Set the Hostname of the datasource to a comma separated list of array or cluster admin names or addresses.
4. Configure the interval to something reasonable (say 15 or 30 minutes)
5. Increase the timeout for larger environments (in my testing, collection takes 15-90s per array/cluster - it may take longer when there are large numbers of objects or if there is significant latency between the WFA system and the array/cluster)

There are some flags that can be passed in (comma separated) through the data source's "User name" field:

• strict - fail collection if any error occurs
• debug - log more information
• log=<logpath> - where to log (defaults to ..\..\log\direct_<schema>.log - typically C:\Program Files\NetApp\WFA\jboss\standalone\log\)
• timeout=<timeout_in_milliseconds> - API timeout (defaults to 180000)

The Password, Database and Port fields are unused.

Reservations, etc, should work as normal. This has been developed against WFA 2.2RC1 and will likely require updates to work with future versions.

Update: April 17, 2014:

• Prevent invalid output when offline volumes are present
• Added timeout parameter, increase default API timeout to 180s
• Fixed foreign key reference bug with fcp_adapter
• Improved error logging information with debug not enabled.

Update August 2, 2014:

• Catch and report errors if non-ASCII characters are found in configuration
• Fixes syntax error in above fix that was included in lunMigrate-1.1

Update August 7, 2014:

• Don't fail if a vfiler has no volumes at all (including no root volume)
• Allow import into 2.2RC1* as well as 2.2 (GA)
  

- Tim

[wronald]

Hi Tim,

Thanks about that, it's great for "smaller" customers, makes WFA useful.

I'll play with it in our Lab...

Cheers,

Ronald.

[adaikkap]

Hi Tim,

                This is a wonderful one and really helps, esp when they don't have a OCUM or cant install it due to the deployment mode being OVA only.

But I just have a couple of clarifications. Do these data sources also provide some of the derived metrics like, Day to full, growth rate etc, which one get from OCUM or is this restricted to cDOT inventory ?

Regards

adai

[ktim]

Hi Adai.

The data sources do not currently provide any of the derived metrics - just the basic inventory (with some gaps), which is sufficient for most workflows. It's fairly straightforward to read the code to see which fields are populated and which are not. I have noticed that there is considerable difference in what is populated from the OCUM 5.x data sources for cDOT and the OCUM 6.x data sources - the Direct cDOT data source sits somewhere in the middle.

Regards,

Tim

[adaikkap]

Thanks Tim. Just wanted to understand.

This really helps. It is definitely a great option for customers without OCUM, and still make the best use of WFA.

Regards

adai

[MOSINKHAN]

Unable to snapmirror from 7 mode to Cluster mode. Error " Unable to tranfer data because the source volume is 32bit" but both source destination volumes are 64 bit within 64 bit aggregate ans sis ie  enable. 

Thanks

[MOSINKHAN]

"source filer:source volume" contains 32-bit data. Data transfer from a volume containing 32-bit data is not supported.

[ken_foster]

You probably have 32 bit snapshots.  If the aggr is 64, and the volume is 64, then that pretty much only leaves SnapShots.