Strategy for Utilizing Scale Out Storage for Cloud & Virtualization Platforms

Hi folks,

I’m finishing up my week at Red Hat Summit, sitting in a coffee shop in downtown San Francisco. I spent the week in customer meetings, pulling booth duty, showing demos, and presenting a handful of sessions.. And here I am with my laptop, and my coffee, writing about my laptop and coffee.. I’ve officially become a walking (sitting?) cliché.

Anyway, as the title suggests this time, I want to cover a great strategy for taking advantage of scale-out storage for virtualization and/or cloud. It’s certainly not the only way, but it works very well. Don’t let the NetApp visuals scare you away – some of what I’m sharing will apply regardless of the scale-out platform you’re utilizing. I’ll point out the things that are likely unique to NetApp.Lets take a look at the diagram below. If you don’t know NetApp, simply understand that it represents a storage cluster built from different controller types as well as different disk types, with a 10GbE interconnect, a management network, and a Ethernet and/or FC network for client access.

Note: As reader and colleague Cristian Dittamo pointed out my typo, there is no FAS3280.. it should read FAS3270 on the 2nd pair of controllers..

cdotscale

As you look to the left, the storage controllers are good, but not as powerful as those on the far right.  Additionally, the disks on the left are what we refer to as “cheap & deep” or high-density SATA disks. Conversely, if we look at the systems on the right, we have big horsepower, bigger memory footprints, and faster (less density) SSD disks. In the middle, there’s a mix of mid-range controllers with either SATA or SAS drives.

Having a storage foundation laid out like this provides a good mix of capacity and performance, without having to commit to either, or over-compromise by only using 1 controller type and 1 disk type. This really addresses the drivers for purchasing a scale-out storage solution in the first place:

  • fight data sprawl
  • better utilization of resources
  • support project/tenant/customer life-cycles
  • support data life-cycles
  • support multiple SLA’s simultaneously

Lets throw in a few examples that should really help solidify your understanding of this approach. Let’s throw out the following very common storage needs:

  • Boot LUNs for bare-metal hosts (virt/cloud hypervisors, “ironic” cloud servers, highest tier database servers, etc)
  • Boot LUNs for VMs
  • LUNs or NFS exports for dev/test
  • LUNs or NFS for mid-tier production application data
  • LUNs or NFS for tier-one application data
  • LUNs or NFS for application data with highest performance requirements

If you were to buy all high-end storage, then you would most certainly eat up more budget than you need. Not to mention, you would be completely over-serving the low tier services like boot LUNs. The converse is even worse, as the only SLA that would ever be met by purchasing only low end gear would be the bronze and “best effort” SLA’s. On a good day with really fast electrons, your silver SLA’s might be happy in random 5 minute increments. But your gold and platinum SLA’s would be taking their business elsewhere, or force you to go back and purchase additional gear that you weren’t intending to buy. The design above is simple and effective. A good scale-out storage solution will allow you to mix and match disk types and controller types in order to best support your environment.

This allows you to put your boot LUNs on the far left of the cluster above. After all, you don’t really care about how fast an update to /var/log/messages gets written to the boot LUN. Your dev/test volumes deserve some respect, but not in the form of “all flash array”. They will typically be just fine somewhere in the middle of the diagram above, maybe even on the SAS drives.

Your mid-tier application most likely needs to be on a mid-range controller, or even upper mid-range, but definitely SAS drives. In your environment, that might even be the dividing line between “silver” and “gold”, where mid-range plus SAS is silver SLA, and upper mid-range plus SAS is gold SLA. Platinum might be the gold SLA, plus a more comprehensive backup and recovery plan.. Or it might include the ultra-fast (and expensive) SSD arrays. Either way, the platinum is likely on the high-end controllers.

In the NetApp specific scale-out (Clustered Data ONTAP), there are other things that come into play here as well. For example, there is the ability to live migrate storage volumes from one area of the cluster to another. This would allow you to do things live move an application store from dev to test to production, all within the same cluster. Or move that database back and forth between the SAS arrays and the all-flash array, depending on customer need.

The other thing that live migrating volumes allows you to do here is allows you to easily adjust SLA’s. Perhaps the customer that you earned 6 months ago has doubled his business and needs more performance to support the added business. Moving from silver to gold just got easy.

If you want more info on Clustered ONTAP, I wrote an article earlier on this, or you can go to http://netapp.com/us/library where NetApp only has about a 100 different technical documents on Clustered ONTAP and various applications.

Hope this helps,

Captain KVM

One thought on “Strategy for Utilizing Scale Out Storage for Cloud & Virtualization Platforms”

Agree? Disagree? Something to add to the conversation?