When it comes to virtualized infrastructures, it’s great that today we have a lot of flexibility. We are flexible in that we do not have the burden of designing mostly around traditional, physical server-based workloads. Virtualization is quite flexible in that we can design around any virtualization platform, any price point, and any performance level.
The notion of a pod, or containerized architecture, became popular with vSphere and Hyper-V technologies gaining ground in data centers everywhere. Many of the large hardware and software vendors have made “pre-configured” systems that accomplish this notion of a pod architecture, using a single (or small) stack of components. In my own virtualization experience, I’ve felt more comfortable and in control of the situation by designing my virtualized infrastructures by my own selection for each component. This allows me to make very specific decisions each step of the way, and also change it depending on other situations (like tiers, specific location requirements, or different application considerations). Figure A below is a single pod design that one may apply to a VMware vSphere environment:
The important thing to note in this arrangement is that there are many levels of flexibility. First of all, there is a rough assumption of the total number of VMs in this pool — I offered 100. This depends on too many factors to make specific recommendations, but the fact is that you, as an IT administrator, know more about your profile. But that may change. That is where the flexibility of the pod design comes in. You can make decisions around this pod, and then as your environment grows you could even add another pod. This pod could also be a three-host design, and maybe you don’t need Tier 2 storage. That’s the point — that you can design a pod to your budgetary constraints and to your application performance profiles. Take this design down the road a bit, where a few more pods have been added. This is shown in Figure B :
Click image to enlarge.
In this example, we have five dissimilar pods and one virtual pod designated to management and data protection. This can also include things like Active Directory, file servers, and remote access infrastructure. The core of the pod architecture is to deliver applications to the infrastructure. This could also include a designated pod for services like VDI, pools of development systems, and “anything else that comes down the road”. A side note of this design, going with the pod design allows you to easily align infrastructure resources to provisioning frameworks such as VMware vCloud Director.
I’ve personally really enjoyed designing pods and seeing pods deployed in virtual environments, precisely to individual needs. How have you designed pods for virtualization? Share your comments below.