….an Outta the Box Idea
Well, by now there is many of us that have installed and played with vCloud Director and realized it is pretty cool, well at least I think so. We have also seen it has some of its challenges, as we would with any new product. I did want to take a moment, and try to give some ideas, NOT gospel design mind you, on how to possibly get creative with vCloud Director in order to create storage tiers for a specific vApp. What did he say?….Storage Tiering in vCloud Director….NO, not quite, we still have certain constraints. I am merely suggesting based on work done in the storage section by Jeramiah Dooley in the vCloud on VBlock paper we wrote that there is some creative ways to address the problem. Time to think a little outside the box as they say.
vCD Storage Logic Today:
- A vApp and all its Virtual Machines will get deployed to the same Datastore in the vDC when add to “My Cloud”
- vCloud Director will simply examine what datastore has the most free space available of all the ones presented to the provider vDC
- Storage Tiering WITHIN a Provider vDC is currently not supported, or recommended since there is no way to assign a vApp by storage
- FAST Pools and other tiering technology at the array level can be used but is not directly identifiable from within vCD
- With Fast Provisioning in vCloud Director 1.5 child Virtual Machines will end up on the same Datastore as the parent
So knowing the assumptions, constraints, and the customer’s requirement of needing to have a vApp broken up, (Any other VCDX’s seeing the pattern?), what do we do?
Possible Provider vDC Storage Design:
Let’s assume we have FAST Pools in play for argument sake on this customer, and they want to create the following. Again, this is somewhat taken from the VBlock paper. We have also always maintained in the vCloud Director reference architecture that storage tiers should be addressed at the provider vDC, and I am going to do just that so do not worry, I am not changing documented reference architecture.
- Gold FAST Pool
- 75% EFD
- 25% FC
- Silver FAST Pool
- 50% FC
- 50% SATA
- Bronze FAST Pool
- 75% SATA
- 25% FC
From a vCloud Director reference architecture, each of these FAST pools would be assigned to three DIFFERENT and DISTINCT VMware vSphere Clusters, and in turn configured in vCloud Director as the Gold, Silver, Bronze Provider vDC’s. Simple so far, right? There should be nothing new here I hope just some review. Now let’s look at the vApp and how we can place it in the same Organization yet achieve vApp flexibility on service levels based on storage.
Example Web/App/DB vApp
Let’s for a moment say the customer originally wanted a 6 Virtual Machine vApp of the following basic setup. However they have also decided that each component would like separate storage performance, WITHOUT requiring a vCenter Administrator move the machines after deployment with Storage VMotion, which is possible but adds a layer of operational consideration. You may start to see where I am going with this already which means….you are outside the box!
- 2 Web Servers (Bronze)
- 2 App Servers (Silver)
- 1 DB Server (Gold)
- 1 Search/Index Server (Gold)
What we could do is break the original 6 Machine vApp into 3 smaller vApps and put the Virtual Machines together based on required storage performance level. These could be deployed from the catalog and each vApp would be deployed to their required Organization vDC. It goes without saying that we know any single Organization can be mapped to all three available Provider vDC’s, therefore this is not outside the realm of possibility. Assuming that each vApp does not have a vApp network and is connected to the same Organization network, all communication would work the same as if they were in the same vApp. You could of course isolate them further with vApp networking but that is a completely different topic.
vApp Distributed Across Org vDC’s
By creating three vApps instead of one and deploying each vApp to a different vDC, we can meet the customer requirement, while not over extending the intended capabilities of vCloud Director to where it borders supportability questions. This is just one way to meet a complex requirement like this in the field. There are so many others it would take weeks to write them up, but this is just one example of how to use vCloud Director out of the box to meet a particular vApp use case.
Summary
My whole point here the one thing I have learned over the years as well as participating in VCDX is simple. Every design comes with constraints either by the customer or the products itself. What we need to do as architects is get creative in the solutions while not disrupting the supportability or original intent of the design. This is just one real example that came up today that sparked some thought for me and got me thinking which is what we all should do. Instead of saying “X Product does not do Y”, let’s look at it through a different pane of glass what it CAN do and work within that.
Side note for those potential VCDX candidates out there, this is a big part of what a VCDX needs to do. Not just knowing the technology but how to work with all of it and their constraints within the design.