I often get asked during a vCloud Jumpstart or vCloud Accelerator delivery by both customers and other VMware Consultants…..What exactly do we need to stand up for a “Production” ready private cloud? This got me thinking about all the considerations around what actually goes into the deployment beyond just vCenter, ESX, vCloud Director, etc. I started to whiteboard this for a customer and we ended up with a pretty interesting view of the world for something to think about beyond just a jumpstart scenario. I wanted to share some of the findings from an architectural side of the infrastructure so you can think about what you might need. Much of this is in the vCloud Reference Architecture as well, but there are some other things that maybe are not. What you will find is as the provider there is potentially a lot more to your infrastructure that is needed to support your consumers. The primary goal here is to highlight the importance if vCenter to the entire design. As we were drawing this out on the board we saw everything converge at the same place and it just seemed like an interesting thing to write about.
As always let me state the CYA portion of our program…..None of this is meant to be the de-facto standard, it is simply more observations from the field. As we go we will begin building the visual representation of this as I did for the customer on the whiteboard. By the end you will see we are not simply dealing with a few basic apps. Take into account how we handle BCDR for all these components and things can get quite complex.
Of course we already know that the foundation of everything we do is vSphere. However in putting together some considerations around the basic vSphere components we need to understand all the touch points that happen and what the impact is. For example….pretty much everything will talk to vCenter at some point or another, so how do we architect that single component not only for availability, but for performance? Are we going to use Update Manager, Converter, and Orchestrator? If so do we want to run all this on the same Virtual Machine or does it make sense to break them out to allow vCenter to act solely as the “Application Tier” of our configuration? Personally, I am a fan of doing just that, putting all the vCenter components on separate Virtual Machines, including Orchestrator so we can manage, update, patch, troubleshoot, and otherwise deal with those Operating Systems and applications independently. Also the simple fact that pretty much everything we do will talk to the vCenter system for something leads me to “purifying” this application for maximum performance and availability. The diagram below represents what some customers see as the minimum components to support the “Foundation”
The “First Floor”
Like with any good building project after you lay the foundation you can now layer on the next floor of the project. In this case I see the next phase of architecture what I call the “Advanced Management” components of the VMware offerings. These are adding in capabilities for performance management, capacity management, Security, Operations and my virtual machine movement capabilities. This stage represents the additional functionality and technology that moves enterprises to the next stage of the Private Cloud. There is obviously some third party products that can be added to this layer, so you can see where they may fit in. What you will also notice is that many of these are deployed as Virtual Appliances minimizing the installation and configuration aspects of the component. The newly added components are highlighted. The basic foundation itself still remains intact. The reason I am listing these before the final additional of vCloud components is all of these can be used without the addition of vCloud. Once the final stage is set, these simply becomes tools to simply help with visibility to the overall environment.
NOTE: vCenter Operations/CapacityIQ/Alive are currently separate Virtual Appliances from what I have seen on the VMware dowload site and I am not sure if this will eventually change.
The Final Stage
As we have seen once the foundation and “First Floor” are built up it becomes very easy to add the final layers of functionality into the VMware vCloud Architecture. We simply add the few remaining components, most importantly vCloud Director and vCenter Chargeback to the mix. We can then start tying all these things together by establishing the connections between workflow tools such as vCenter Orchestrator’s vCloud Plugin. Eventually more products may come into the mix but these are the ones currently available today. As we can see the vCloud additional and Chargeback pieces are in some ways a small portion of the whole pie. I really wanted to put this together because when you look at this from a logical design perspective we need to understand all the possible components. If there is one thing that becoming a VCDX has taught me it is that all angles of the design need to be examined and considered.
If it has not become clear what I am showing here is that currently vCenter and the “Foundation” components of the design become paramount to support the additional Layers. We can see in the final stage that there is a lot replying on vCenter at some point or another. What I am trying to show is simply that there is lot of interaction with vCenter. We should be considering how we handle both the care and feeding of that application when there is a vCloud Architecture. Some thought needs to be put into all these components around availability such as multiple instances of vCloud Cells and Chargeback Nodes, but let’s not lose sight of the core foundation. I personally believe this is one main reason why the VCDX program focuses so heavily on the vSphere Infrastructure because it is and will always be the foundation to the building.