NetApp and Multi-path Management - Feedback Request

[andrewh]

Looking for your input on the following topic...You can reply here or directly to me at andrewh@netapp.com

Would you or your customers find value in a NetApp interface that provides a common CLI for multi-path management ? The idea is that this CLI would be layered over native vendor provided multi-path management - so things such as DM-MP in Linux, MPxIO in SUN, etc.. but have a uniform interface across those platforms.

This concept of a NetApp "multi-path wrapper" would leverage the vendor OS drivers / stack for multi-path management, but would be a thin management layer (CLI/ API) for common management, extractiing the benefits of OS provided M/P services but enabling common management through a common CLI.

If you would find value in such an offering, would you see it as an extension of existing products

- such as SNAPDrive, so through one tool, a user could provision storage to the host AND manage pathing configuration

Or as an extension of existing multi-path management products

- such as the ONTAP DSM, which is an extension for path management that NetApp provides for Fibre Channel and iSCSI SAN configurations.

Appreciate your time and thoughts on this matter.

Andy

[BrendonHiggins]

I like how multi path is shown on the snapdrive MMC for FCP but the iSCSI is not great or easy to read. I understand that it is an MS feature now but it is still poor when compared to FCP.

If both were in the same interface it would make training easier but if you are just acting as a broker, would it just add more complexity if the service failed?

[andrewh]

Brendon,

Thanks for the feedback. UI implementation is important and is part of our value add w/ the MSFT DSM (which support both FC and iSCSI management today )

In terms of the complexity question, I think the answer is no. In this case, NetApp will be providing an API / CLI layer that leverages the underlying OS provided native M/P solution - so DM-MP, MPIO, etc.. We leverage the OS provided SCSI stack interfaces, but provide a consistent user experience for administration. For messaging, we would use standard log and error files ( so event logs for Windows as an example )

At the end of the day, we would provide a consistent interface to M/P management for both end-customers via the CLI as well for any applications that are SNIA compliant (NetApp or otherwise). This effort would provide a common management interface while helping to accelerate the adoption of the newly approved standard API interface ( SNIA Multipath Management API v1.0, also known as INCITS 412:2006, was published as ISO/IEC 11002:2008 last month )

Best,

Andy

[rkaramchedu1]

Absolutely!

Now - Having gotten that out of the way, wouldn't the cost of developing a wrapper (albeit, thin) to work with all the various MPxIO systems be very close or be only incrementally less than the cost of developing a MPxIO package itself ? With both the efforts, one has to keep up with the driver changes, certifications etc...A unified UI kit that provides NTAP MPxIO s/w and third-party s/w would be cool indeed.

This may be slighly off-topic, but wanted to throw it out there that it could be funny, cool and downright kicka$$ if we can build PowerPath into the support matrix. Not only then NetApp can de-dup EMC/third party storage, migrations from EMC to NetApp will be a breeze. I do understand that this may not be possible cause powermt may have some proprietary code (CLARiiON and SYMM specific)..

[andrewh]

Thanks for the feedback. We have spoken to a number of large customers / accounts who also share your enthusiasm for having unified UI over native, vendor provided multi-path drivers. These customers are looking to get out of the lock-in that storage array provided solutions of today have them cornered with but want to have a mechanism to help simplify the management across different OS platforms.

In terms of efforts, the work required to provide a common CLI / API (SNIA compliant* ) over the Operating Systems M/P driver is quite a bit less than actually developing an 'in the stack / I/O path Multi-path module' There is certainly a fair bit of effort and work here, but the wrapper s in the user space not the kernel space and leverages the work done by the operating system vendor for I/O management, but provides a consistent interface for scripting and or application integration

All of this will help our customers find more cost effective solutions for HA and help drive the adoption of the SNIA compliant standard over their native multi-path solutions.

-Andy

*The SNIA Multipath Management API v1.0, also known as INCITS 412:2006, was published as ISO/IEC 11002:2008 last month