Thick Clouds

I have seen a lot of talk about adopting the cloud lately. A fair amount of it has been based around “high-governance”. To be more specific; one use case is a large financial that requires physical separation of tiers. Security mandates that are more cumbersome than a business that may not have to deal with the compliance constraints you may see in health care, finance, government, etc. A high-governance cloud differs from a low-governance cloud, such as Amazon’s EC2, in that a set of enterprise policies must be applied to any virtual machine instance created and deployed before being connected to the rest of the corporate network.  As a result, in a high-governance cloud design there is an increase in attention on post-provisioning and virtual machine lifecycle management that doesn’t exist in the low-governance counterpart architecture.

The design we have been working with consists of stretched clusters, NetApp metro clusters, with Overlay Transport Virtualization (OTV) for site failure. With all of this in place, the site failures should be seamless, but security constraints mentioned before coupled with all of these technologies presents some challenges as well as benefits:

-  The multi tier design mandated by the security group gives physical separation to each tier, along with limited communication. The communication is also done on an IP to IP basis; as opposed to a range being allowed.

-  There is no common management network between the tiers giving a constraint on host communication.

Once we understood the design limitations and constraints of the customer environment, attention was focused on the primary customer requirement: the self- and post-provisioning of virtual machines to all tiers in a single request.  Additionally, the customer wanted a simple user interface that did not require advanced knowledge of the customer’s multi-tier cloud architecture.

One of the proposed solutions we have designed is a vCO (VMware Orchestrator) and vCD implementation using the new Notifications (callouts) feature of vCD 1.5. In this solution, we leveraged some of the existing scripts that had been written for post provisioning tasks at the client. The process design on a high level:

            – The first problem we had with this approach was that a single request could not comprise multiple-tiers in vCD.  We were going to use a VCO front end to actually make 3 vApp requests from a single interface.  

This addressed the design issue we were faced with, but added some complexities to the environment as well. Since we cannot layer post provisioning tasks onto the service catalogue entries, we needed to have a small script call on other scripts in order to complete the tasks. To meet all of the different types of deployment tasks, we need to have some sort of custom attribute or description for each vApp request in a CMDB which VCD could consume, growing it exponentially. Having those attributes in vCO causes a need for a different service catalogue entry for each type of deployment as well. In a nutshell, a single template may need dozens of different service catalogue entries. based on this logic we would be looking at: 4 Source VMs * number of deployments.  Even if you use the same base images for 8 more SCatalog entries, before deployment, you’ll have 9 catalog entries * 4 VMs ( 9 * 4 = 36 VM templates in the catalog).  Now imagine you have to apply critical patches to your 4 source VMs….you’ll have to patch every one, or recreate the service catalog. 

I think vCD is the approach we would like to take, but to get there I think there might be some obstacles to overcome and make it much easier to adopt:

1. A more customizable UI, perhaps with hooks for vCO into the service catalogue, instead of the individual VM’s. There can be a custom UI for the users (not in this client….), but I think being able to modify the current UI to meet the requirements may be a better option.

2. A way to link multiple physically separate tiers with a single vCD cell. Perhaps unifying the provider vDC’s, (very challenging considering the compute resources defined by provider vDC’s). vShield is not an option for the client currently.

3. I would also like to see a way to choose the data store/provider vDC/Org vDC we go to during deployment for certain cases. During the deployment process, I if I could make these selections; I could potentially place two VM’s in a vApp in tier 2, and 3 in tier 3, for example. This would allow for one vApp request spanning all of the tiers.

In a future post, I will discuss some other options we have been looking at, vSM, vCM, etc… ; along with further defining the requirements we have had to meet.