Yellow Bricks

by Duncan Epping

sddc

Why the world needs Software Defined Storage

· ·

Yesterday I was at a Software Defined Datacenter event organized by IBM and VMware. The famous Cormac Hogan presented on Software Defined Storage and I very much enjoyed hearing about the VMware vision and of course Cormac’s take on this. Coincidentally, last week I read this article by long-time community guru Jason Boche on VAAI and number of VMs, and after a discussion with a customer yesterday (at the event) about their operational procedures for provisioning new workloads I figured it was time to write down my thoughts.

I have seen many different definitions so far for Software Defined Storage and I guess there is a source of truth in all of them. Before I explain what it means to me, let me describe commonly faced challenges people have today.

In a lot of environments managing storage and associated workloads is a tedious task. It is not uncommon to see large spreadsheets with a long list of LUNs, IDs, Capabilities, Groupings and whatever more is relevant to them and their workloads. These spreadsheets are typically used to decide where to place a virtual machine or virtual disk. Based on the requirements of the application a specific destination will be selected. On top of that, a selection will need to be made based on currently available disk space of a datastore and of course the current IO load. You do not want to randomly place your virtual machine and find out two days later that you are running out of disk space… Well, that is if you have a relatively mature provisioning process. Of course it is also not uncommon to just pick a random datastore and hope for the best.

To be honest, I can understand many people randomly provision virtual machines. Keeping track of virtual disks, datastores, performance, disk space and other characteristics… it is simply too much and boring. Didn’t we invent computer systems to do these repeatable boring tasks for us? That leads us to the question where and how Software Defined Storage should help you?

A common theme recurring in many “Software Defined” solutions presented by VMware is:

Abstract, Pool, Automate.

This also applies to Software Defined Storage in my opinion. These are three basic requirements that a Software Defined Storage solution should meet. But what does this mean and how does it help you? Let me try to make some sense out of that nice three word marketing slogan:

Software Defined Storage should enable you to provision workloads to a pool of virtualized physical resources based on service level agreements (defined in a policy) in an automated fashion.

I understand that is a mouth full, so lets elaborate a bit more. Think about the challenges I described above… or what Jason described with regards to “VMs per Volume” and how there are various different components that can impact your service level. A Software Defined Storage (SDS) solution should be able to intelligently place virtual disks (virtual machines / vApps) based on selected policy for the object (virtual disk / machine / appliance). These policies typically contain characteristics of the provided service level. On top of that a Software Defined Storage solution should take risks / constraints in to account. Meaning that you don’t want your workload to be deployed to a volume which is running out of disk space for instance.

What about those characteristics, what are those? Characteristics could be anything, just two simple examples to make it a bit more obvious:

  • Does your application require recover-ability after a disaster? –> SDS selects destination which is replicated, or instructs storage system to create replicated object for the VM
  • Does your application require a certain level of performance? –> SDS selects destination that can provide this performance, or instructs storage system to reserve storage resources for the VM

Now this all sounds a bit vague, but I am purposely trying to avoid using product or feature names. Software Defined Storage is not about a particular feature, product or storage system. Although I dropped the word policy, note that enabling Profile Driven Storage within vCenter Server does not provide you a Software Defined Storage solution. It shouldn’t matter either (to a certain extent) if you are using EMC, NetApp, Nimbus, a VMware software solution or any of the other thousands of different storage systems out there. Any of those systems, or even a combination of them, should work in the software defined world. To be clear, in my opinion (today) there isn’t such a thing as a Software Defined Storage product, it is a strategy. It is a way of operating that particular part of your datacenter.

To be fair, there is a huge difference between various solutions. There are products and features out there that will enable you to build a solution like this and transform the way you manage your storage and provision new workloads. Products and features that will allow you to create a flexible offering. VMware has been and is working hard to be a part of this space, vSphere Replication / Storage DRS / Storage IO Control / Virsto / Profile Driven Storage are part of the “now”, but just the beginning… Virtual Volumes, Virtual Flash and Distributed Storage have all been previewed at VMworld and are potentially what is next. Who knows what else is in the pipeline or what other vendors are working on.

If you ask me, there are exciting times ahead. Software Defined Storage is a big part of the Software Defined Data Center story and you can bet this will change datacenter architecture and operations.

** There are two excellent articles on this topic the first by Bill Earl, and the second by Christos Karamanolis, make sure to read their perspective. **

vCloud Suite equals a Software Defined Datacenter

· ·

I was on the VMTN podcast this week with Frank Denneman and Rawlinson Rivera, hosted by John Troyer. One of the discussions we had was around the Software Defined Datacenter and the vCloud Suite. Often people make a direct connection between a Software Defined Datacenter and the vCloud Suite and I can understand why. I have heard some people comment that because some components are not fully integrated yet; the vCloud Suite does not allow you to build a full Software Defined Datacenter.

On the call I mentioned that a Software Defined Datacenter is not just about the vCloud Suite. Using the vCloud Suite does not magically provide you with a Software Defined Datacenter. I guess the same could be said for a cloud, using the vCloud Suite does not magically provide you with a cloud.

What a lot of people tend to forgot is that a cloud or an SDDC is not about the infrastructure or the individual components. (Lets from now on use SDDC instead of the full name or the word cloud) An SDDC is about how you are providing services to your customers. In this case, customers could be external / internal customers of course. An SDDC is about software defined services, about flexibility and agility. What does that mean? There are two points of view, the consumer of the platform and the platform administrator. Lets explain from both views what is means, or at least what I think it means…

  1. The consumer of the platform
    The consumer should be able to select a specific service level for their workload, or select a specific service for their workload. When they they select a service or service level the platform should sort things out for them fully automated, whether it is DR / Backup / Resources / Storage Tiering / Security… it should be automatically applied to the workload when either of those software defined service characteristics are selected and applied.
  2. The platform administrator
    The platform administrator should be able to define services and policies which can be consumed. These services or policies could be as simple as “enabling vSphere Replication” on a virtual machine, or as complex as deploying a 3 tier vApp including a full application stack and security services using vCloud Automation Center in combination with Application Director and vCloud Networking and Security.

In some cases that means you will need to deploy the full vCloud Suite and potentially more, in other cases it might mean you will deploy less but use 3rd party solutions to provide a fully automated solution stack and experience to your consumers . In the end it is about having the ability to define and offer services in a specific way and enabling your customers to consume these in a specific way.

Although the SDDC could be architected and build using the vCloud Suite, using the vCloud Suite does not automagically provide you with an SDDC. An SDDC is about your operating model and service offering, not about the components you are using.

Feel free to chip in,