An Introduction to VMware Validated Designs
One of the announcements from the US VMWorld 2015 that I feel hasn’t gotten a lot attention is the VMware Validated Designs. It’s been about a month since the new references were announced on the Office of the CTO blog, but aside from a bit of chatter at VMWorld and a handful of tweets, I haven’t heard much since. The idea behind it intrigues me and I figured what better way to learn about it than write a post about it. So, let’s get started.
What Is It?
VMWare Validated Designs is aiming to be a reference architecture that customers can use to help build out an environment based on given scenarios and requirements. The designs will be put together by various experts and will be available to customers, consultants, and presumably vendors. Customer feedback will also be incorporated into the designs which will hopefully lead to flexibility and lend itself to real-world applications, and not just ones seen in the VMware ecosystem.
Once the validated designs are released, VMware will be continually updating them as new features, products, and software versions are released. The good news (and a key point) is that at any given point the key spec will be a validated design. For example, if there is a design that uses vSphere 6.0, NSX 6.1, and VSAN 6.1, but then VSAN 6.2 is validated, then the new design will reflect that (vSphere 6.0, NSX 6.1, and VSAN 6.2). If the design hasn’t been updated to the newest software version(s), then it isn’t validated.
Since the onus will be on VMware to ensure that these designs remain validated, I wouldn’t necessarily expect quick turnarounds after new releases of various components within the designs. Given that some of these designs will be quite granular in detail and the number of components involved can be quite large, I imagine that it would take a good amount of time to not only test the actual upgrade process, but to also ensure that there are any hidden incompatibilities.
What will it cover?
The four key deployment scenarios that these designs will target are:
- Datacenter Foundation
- Single Region IT Automation & Cloud Self Service
- Dual Region IT Automation & Cloud Self Service
- QE / Demo
Datacenter Foundation: As the name implies, these validated designs will focus on technologies commonly used when building out a datacenter. Things like vSphere, VSAN, NSX, and Operations Management will be the primary players.
Single / Dual Region IT Automation: These would be the components that sit on top of the foundation; once you have your datacenter in place, you’ll want to start automating it. Most if not all of the same technologies from the Datacenter will still be used here, but the focus will be on automation, so you’ll likely see Orchestrator in the mix.
QE / Demo: fairly self-explanatory.
The designs will also contain information with regards to what steps need to be taken on Day 0, Day 1, Day 2, etc. all the way through to continuous operation. Basically it sounds like a handoff guide to say here is what you need to do, in what order, and here is how you keep it running in the future.
What are PODs?
Each of the blueprints are designed around three different Points of Delivery (referred to as PODs): Management, Edge, and Compute. These PODs are the building blocks for blueprints and given that this is aimed at a SDDC you will only see one management POD, one edge POD, and at least one Compute POD.
The Management POD is where all the SDDC stuff will take place such as the vCenter, NSX controllers & managers, and other infrastructure oriented tools. 3rd party applications such as MS Active Directory might be seen in here as well in the event that it is a requirement. A minimum of four ESXi hosts need to be present in this POD and storage is run on VSAN.
The Edge POD will focus on the security side of things; so although NSX will be a part of it, it will be responsible for things like transport traffic and securing access into and out of the SDDC. Three ESXi hosts are needed here and must be configured in a cluster with HA and DRS running. Once again storage is provided by VSAN.
The Compute POD is where the traditional workloads run (e.g. a SQL server or a Domain Controller). This POD is a little different from the other PODs in the sense that storage here is provided by VSAN, NFS, iSCSI, etc. … more of the traditional, non-VMware stuff. A minimum of four ESXi hosts need to be present and configured with HA & DRS, just like in the Management POD.
What’s Next?
VMware Validated Designs are still young, but hopefully we’ll see some growth in the near future. At the moment you can join the early access community (login required), and a slew of information is available on VMware’s site: