Extensible NetApp: Thinking outside of the box

How to Operationalize FlexClone

Joe Bloggs, a data center architect, was recently assigned the task of figuring out how to use FlexClones.

The value of FlexClones around speed, simplicity and cost savings was so obvious that Joe was really motivated to make this work.

Joe looked at the problem and broke it down into four pieces:

1. Create a consistent image of the database on the production system
2. Copy the consistent image to test and development system
3. Enable DBA's to use clones to do their development.
4. Move final image back into production.

Now it turns out that Joe had tools and processes that he was comfortable with for solving steps 1, 2 and 4. After all he had been supporting database administrators (DBA's) for a while. So his plan was to continue to use those tools and processes. The challenge was step 3.

The naive and impractical solution would have been to give the DBA' s the root password on the FAS system and pray that they did not make a mess of things. Since Joe was not into faith based storage administration, he decided that he needed a more regimented process.

His requirements were:

1. Multiple distinct business groups must be able to use the same FAS system.
2. Each distinct business group must be prevented from impacting other business groups.
3. The DBA' s must able to perform the following operations without involving the storage group:
   1. Create a clone
   2. Destroy a clone
   3. Mount a clone

 

The first and second requirement were reasonably easy to satisfy. Joe's plan was to give each business group an storage pool (an aggregate)  within a FAS. The DBA's would share the controller, but would get their own private storage sandbox. The amount of capacity for each sandbox would depend on how much the line of business wanted to spend for their DBA's.

But the third requirement was problematic. The challenge was that the FAS system does not provide the fine level of role-based access control that he wanted. But even if it did, he was not sure that he wanted to expose DBA's to the full richness of the ONTAP command set.

What Joe wanted was a tool that the DBA's could use to manage clones, and that was integrated with some form of role based access control so that DBAs never accidentally managed someone else's clone.

Joe then asked NetApp for a solution to his problem. Ryan Cox, an engineer that is part of NetApp's Rapid Response Engineering (RRE) Team came up with a tool that leveraged the Manage ONTAP API's.  The tool used the FAS APIs for manipulating storage objects and the APIs that are part of the Operations Manager product to manage Role Base Access Control. In a follow on post I'll talk about this tool in more detail.

Manage ONTAP

One of least well known aspects of NetApp  is our SDK program called Manage ONTAP.

And it's so poorly known, that I'll be devoting some of my time over the next couple of months to talking about them. Mostly because I believe using these APIs are the easiest way for administrators to operationalize the capabilities found within Data ONTAP. And since making their lives easier is part of my mission at NetApp, this seemed like a good fit.

So what is Manage ONTAP?

Manage ONTAP is an SDK that NetApp makes available to partners and to our customers. The SDK provides documentation, sample code, and a library that makes using APIs that are available on our storage system, easy.

The APIs themselves are a flavor XML/HTTP RPC's that are similar to but not exactly like SOAP.

NetApp products like Protection Manager, SnapDrive for Windows, SnapManager for Exchange were all built using the APIs made available through the SDK.

Over the next set of posts I intend to describe the core construct of the APIs, what you can do with them, and some of the ways we've used them inside our own products.

If there are specific topics you'd like to learn about, just add your comments to this blog entry, and I'll try and cover them as time and energy permit.