Chris Colotti's Blog Thoughts and Theories About… 
Last week I spent the day at the New England VMUG in Maine, and I was asked to be one of the keynote presenters. However, I was also asked to come up with a brand new shiny out of the box presentation that was not the usual vCloud Director stuff. What I came up with was a deck from scratch that was intended to help folks looking at vCloud Director think about Service Levels. Not Service Level Agreements per say, but the levels of service they would be offering to their consumers as the providers. What came out of it was some interesting thoughts on the topic that I wanted to share before the recording was available for me to post. What we I learned as well as the attendees is that this is not a topic of a single dimension, but of multiple ones.
As always it goes without saying this is all only my opinion and is in no way meant to be best practice or something taken as any directives. It is simply some things I thought of that came out of a new presentation I built from scratch.
Melt The vCloud Precious Metals
All too often we in the vCloud side of things gravitate to the “Precious Metal Tiers” of Provider vDC. Well what do those really even mean anyhow? What defines them to be different classes of service? Well, in my mind I look at this layer of service to be the hardware capabilities. Meaning if I have a provider of a certain configuration, what can or do I want it to support for my consumer virtual machines? Also how does that translate to the consumer’s PERCEPTION of service once we layer on one or two organization Virtual Datacenters? Below is a diagram showing one example of how I explained this.
What we see is what separates the metal tiers is varying degree of hardware configuration at the cluster level. Also each tier is specifically designated to host only certain sizes of virtual machines. This is by design to try to keep things equal as much as possible within that service tier.
Bronze Tier:
- Low Memory, Cheap SATA Storage
- 1-2 CPU Physical hosts
- Small Clusters (4-8)
- Fast Provisioning Enabled
- Small VMs of up to 8GB with 1 vCPU
- PAYG only maybe
Silver Tier:
- Medium Memory per host, FC Storage
- 2-4 CPU Physical Hosts
- Medium Clusters (8-16)
- Fast Provisioning Optional
- Medium VMs of up to 16GB with 2 vCPU
- Mixed Allocation Models
Gold Tier:
- Moderate Memory per host, FC/SSD Storage
- Medium to Large Clusters 16 plus hosts
- 4-8 CPU Physical Hosts
- Fast Provisioning Disabled
- VMs Larger than 24GB and 4 CPU
- Mixed Allocation Models
- DR on the Provider Level based on current solutions.
By dictating at this level the varying degrees of hardware configuration we can truly define the level of service between the three precious metal tiers in vCloud Director. I think in the past we have used these names but until even I sat down to think about them, I have not really put a definition to them. Now what about the next layer up and the organization vDC level of service?
Defining the Organization’s Service Level
This is much more straight forward. vCloud Director already include the mechanism to do so in the form of the three allocation models. What I don’t want to do is explain how the three work, we have done that a number of times in various places. There is also a pending White Paper coming from myself and Frank Denneman on this topic in-depth. What I will say is that you can and should as a provider consider a few things.
Not all consumer’s functional requirements are the same! Talk to your potential users and tailor their organization resources to their needs. Many times I have seen template based allocation models being issued to all users with the same configuration. For example, a Provider may decide that everything for their public cloud with vCloud Director will be Pay as You Go. That’s cool for sure, but then they make every customer the same configuration who signs up at 0% CPU Guarantee, 0% Memory Guarantee, and 1Ghz of CPU.
What if Customer A and Customer B what to run, and pay for, different settings? There is no reason why they cannot have polar opposites for settings in the same model if they have different application requirements. The point of vCloud Director is that it is flexible to do so. Customer A may want guaranteed performance, but still may only want to pay as they grow. They could have 100% memory reservation set while Customer B has 0%. The technical details of what happens when you do this is cover in the pending White Paper, so stay tuned.
The point here is that although template based allocation is EASY, it’s not flexible or customizable. In my opinion if I were I provider I would interview my consumers and ask what they think they need. In some cases it could lead to selling them a completely different allocation model type. Below is an expanded diagram showing how the Provider vDC levels are compared to the consumer’s perception of service level.
What we see is although the consumer is on the Silver Tier, the consumer is considering that to be “Gold” for them because they have 100% reservations set. That could mean the virtual machines in that vDC might perform better even though they are smaller and not on SSD storage. This is simply because those virtual machines in vCloud Director will have all their physical resources reserved. The reason the Reservation pool is considered silver is that they are not setting per virtual machine level reservations, but they do have a capped pool of resources to use. This is also showing you how the provider Precious Metal Tier, may in fact have nothing to do with the overall level of service to the consumer.
Availability As a Service Level
Is it safe to say that consumer’s expect SOME level of availability in their service level? I would say that the answer is yes, but what availability is defined? It’s safe to say that in most vSphere designs behind vCloud Director, there is network, storage, and host redundancy. Every vCloud provider I would assume has redundancy on those areas, and is running vSphere HA at the least. Also hopefully the vCloud Ecosystem of components is set up in such a way that things are redundant, backed up, and available. So where else do we need to be concerned with availability?
The consumers in most cases are responsible for Application level availability. For example if your provider has two cloud instances in two cities, yet you deploy your application only to one site…that’s not going to be very available should something happen. That, in my opinion, is on my shoulders as the consumer of the vCloud Provider’s resources to maintain some application level availability. It may also be my responsibility to back up my data. This blog for example live on a vCloud Provider, but I back it up, and I have another copy of the entire server on the vCloud Provider’s other site.
Catalog Service Offerings
As the vCloud provider you also need to decide what, if anything, you are going to provide for published catalog services. For example will you offer just base operating systems, preconfigured applications, ISO images, etc. Most consumer’s will expect some level of services to be available in the public catalog for them to get started. Others will simply want to load their own items into their organization catalog. Either way offering the public catalog or even the availability of the local organization vCloud Director catalog is in itself a service you are offering.
How often these get patched, updated, and refreshed is up to the provider of course. The consumer will expect over time that these do get updated, or new offerings become available. What about having other appliances in the catalog like load balancers, and other cool things? Those all become part of the catalog service offerings to each consumer of the vCloud Provider.
Peel Back the Onion
My recorded session at the VMUG will go much deeper into some of these topics, but I wanted to hopefully get people thinking. In my opinion when someone starts talking about ‘Service Levels’ I now start peeling back the layers. Which level of service at what layer, and how can you put a single definition on that. If people ask me I think you don’t I think you define each one individually at the different layers. By doing so you remain the most flexible to the consumers and each consumer gets a customized level of service that suits their needs.
Let’s not end up like 1984 with every consumer being treated the exact same. We all have different requirements and vCloud Director is awesome at making sure that we can provide the resources to all those consumers differently and with proper control. That’s what it was designed to do in fact and it does a great job doing it. Now it goes without saying some of this cannot be done without orchestration, customization, or other means of scripting, but maybe that is what it takes. If want it to be easy, then it will be inflexible. Life in general is not easy because it changes and we need to adapt to it. Why shouldn’t your cloud built on vSphere and vCloud Director be any different? Be flexible to be successful I say!
