(This post is the second of a series of posts I will be publishing over the next few weeks on storage paradigm shifts, focusing on NetApp’s new DataONTAP 8.1 Cluster-Mode. You can read the first post here.)
Picking right back up where we left off… Cluster-Mode. If we want to be official, let’s call it DataONTAP 8.1 Operating in Cluster-Mode.
How did we get here? At NetApp, we treat metal as simply a commoditized platform for scale.
You’ve all seen this before. It’s simply the lineup of NetApp storage arrays.
Remember how I was drawing comparisons to VMware and making points about DataONTAP being a centralized operating system? If we expand on the picture above, it would look something like this…
I’d like to give this a name. Let’s call DataONTAP the Storage Hypervisor.
DataONTAP has enabled the ability to centralize on a platform. Standardize across your entire storage infrastructure on one skillset, commandset, and if you’re using our OnCommand Unified Manager and accompanying suite of tools, all arrays can be managed from a single extensible interface, similar, again, to VMware’s vSphere Client.
I promise you, if you haven’t spent any time with NetApp, these concepts alone will revolutionize the way you manage your datacenter, even without all the fancy stuff that I’m getting ready to talk about. If you need some proof, you can check out the NetApp Customer Story library and read for yourself, first-hand.
So, this is where it starts getting interesting.
Let’s take what we know so far about this unified operating system, and apply some virtualization techniques to it.
“What do you mean by ‘virtualization techniques,’ Nick?”
Glad you asked. Think about constructs within a virtual datacenter. Think about Virtual Machines. Think about vNetworks. Think about vMotion, HA, and DRS. Cool stuff, right?
What if we could do the same thing in storage? If we continue to expand on the previous images, it would look something like this…
But this isn’t even a fair representation, as it’s not complete. We haven’t completely commoditized the arrays themselves yet, so let’s take the hardware platforms out of there, and do it like this…
Now we’re talkin. A true imagery of the storage hypervisor. In the image, the hardware platforms are technically represented by the yellow rectangle in the background. Why all the different color disks? Well, it’s a correlation of two things:
1) Differing drive types & speeds
2) The apps being housed on those drives
The reality is, this is how customers will see it. That’s what is important to the customer.
“Where is my data?”
“What volumes are they on?”
“What arrays are those volumes on?”
With that said, let’s keep building out this big picture…
There’s those colors we were looking at before. Now it all starts to come together and make sense, doesn’t it?
What you end up with is one giant logical pool of “cloud storage,” that is only segregated by drive type. This logical pool (or pools) is used to carve out volumes that will be used to serve data to your apps/infrastructure, and those volumes can seamlessly be moved around between the drive types, or between hardware controllers. Live! Hot! On-the-fly!
Sound familiar, VMware admins? [HINT: vMotion]
We call it DataMotion. I tried to get them to change it to “nMotion” at the last minute, but it didn’t take. :)
So let’s talk about these vServers for a minute. vServers are the theoretical equivalent of a virtual machine. Each is running what is a semblance of DataONTAP code, but it’s not a full install. It’s simply a construct that lives in memory of all controllers in the cluster, and it has logical network interfaces (“LIFs”) that connect to the underlying hardware on the backend, up to the app/infrastructure on the front end, and can even have their own mgmt interfaces for delegated control. It is safe to think of them as logical storage controllers. Commands can be either executed directly on them, or from the cluster context itself. It’s all about RBAC and delegation. If you’re a one-man wrecking crew, you’ll likely spend most of your time at the cluster interface. But for you storage admins that delegate control to storage resources to other departments, you can now delegate control of an entire vServer (with pre-appropriated storage) to an individual or group.
The difference between a traditional virtual machine and a vServer mostly has to do with the fact that a traditional virtual machine is a set of files. vServers in DataONTAP live in memory, and have a 20MB “root” volume on the storage controller they were created on. This basically holds core configuration information, such as metadata, network/LIFs, etc. That’s why it’s only 20MB.
So, we’ve now got our vServer’s, commoditized storage clusters, LIF’s or logical networking.
The stage is now set.
In the next post, we’ll dig a little deeper into the clustering architecture, the cluster network/backbone itself, and differences between 7-mode HA pairs, and what HA pairs will become in Cluster-Mode.
Thanks for reading!
As always, comments are below for a reason! If you have comments/questions, don’t hesitate to ask!
CREDIT: All images used in this post were created by Scott Baker at NetApp, Inc, and may not be reused without express written consent.