On Feb 13th VMware released the VMware Validated Design for Software-Defined Data Center version 4.2. This latest update to our detailed prescriptive path on how to implement, operate, and maintain a VMware based Software-Defined Data Center (SDDC) includes a few minor changes, such as updates to the software bill of materials and some new naming conventions, along with some pretty significant new capabilities, such as support for availability zones and stretched clusters! In this post I’d like to introduce you to this latest update and point you to the documentation where you can learn more.
Software Bill of Materials
The VMware Validated Designs (VVDs) are a set of prescriptive documents that explain how to plan, deploy, and operate an SDDC. VVDs are based on a collection of individual VMware products (vSphere, vSAN, NSX, vRealize Suite), that are combined into a common consumable package. The collection of individual products, and their respective version numbers, make up the VMware Validated Design Software Bill of Materials, or BOM for short.
The 4.2 release includes several incremental version updates to the software BOM along with detailed steps on how to upgrade each component. A full list of software components and their versions can be found in the release notes .
As is always the case with VVDs, the software BOM and the steps for implementing and updating them have been extensively tested and validated against a standardized architecture to ensure ongoing compatibility and interoperability across the SDDC stack.
Design Updates
Workload Domains
With the 4.2 release we’ve also made some minor changes to the way we name things. Those of you already familiar with VVDs will recall the use of the term “pod” to describe the different types of clusters that are used in the SDDC. For example, there is the “one-pod design”, or what is officially called the consolidated SDDC architecture, where we co-reside the management, compute, and edge workloads on a single vSphere cluster. There is also the “two-pod design”, or what is officially called the standard architecture, where we isolate the management workloads onto a dedicated vSphere cluster and co-reside the compute and edge workloads on a separate vSphere cluster. While the designs fundamentally remain the same, the terms we are using to describe them in the documentation is changing with the 4.2 release. In place of the term “pod” we now refer to the different clusters as “Workload Domains”. Not a big change, but hopefully this change will help align the VVDs naming convention with industry terms that you are more familiar with and perhaps already use in your data center.
Naming Scheme for vRealize Automation Tenants
We’re also introducing a new naming scheme for the vRealize Automation tenant accounts. While the names used in the VVD are intended to be examples, as we anticipate most customers will choose to use their own naming conventions, we do try and maintain consistency throughout the VVD in order to reduce confusion and provide clarity. As such, the vRealize Automation account names have been updated to help provide for improved indication of the account purpose.
Improved Deployment Order
An improved order of deployment is also being added with VVD 4.2. This improved ordering moves the prescriptive path for enabling the monitoring capabilities of the SDDC earlier in the deployment. This helps to ensure that monitoring is enabled as early as possible and as such the SDDC operations and monitoring tools can be more effectively used during later stages of the deployment. With this change, you will find that in the documentation that the operations management layer (provided primarily by vRealize Operations and Log Insight) now comes before the cloud management platform layer (provided by vRealize Automation).
Site Recovery Manager Metrics in vRealize Operations
Another change with VVD 4.2 is that the metrics data related to Site Recovery Manager is now surfaced in vRealize Operations Manager and vRealize Log Insight. This allows you to better utilize the SDDC operations and log aggregation tools to improve disaster recovery capabilities provided by Site Recovery Manager when deploying your SDDC across regions.
Availability Zones and Stretched vSAN Cluster Support
Last, but certainly not least, with VVD 4.2 we are adding steps on how to design and implement a dual-region SDDC that has support for multiple availability zones. Availability zones enhance resiliency of the SDDC and improve SLAs by allowing you to identify separate fault domains within your primary region and to leverage the stretch-clustering capabilities of vSAN in order to distribute your workloads across the availability zones.
Naturally, the separate availability zones should always be physically isolated and have independent power, cooling, network and security. Those details are of course covered in the documentation. The whole idea of availability zones is to ensure that should an outage occur in one zone, the surviving zone would have everything it needs to sustain the business until such time as the outage is resolved, or a disaster declared and operations moved to the recovery region.
With the VVD 4.2, up to two availability zones can be defined in the primary region. The physical distance between these zones can be up to approximately 30 miles (50 kilometers), and must be interconnected using a low, single-digit latency and high bandwidth fiber connection. You can operate workloads across availability zones in an active/active manner using a single vCenter Server instance. I’m sure you have a lot of questions about the new availability zones and stretched cluster support, so rather than try and tackle them all in this blog, I’ll again point you to the VVD documentation link to where you can read all about this new capability.
Summary
So in summary, VMware Validated Designs provide a prescriptive path to not only design and deploy a modern SDDC, but how to operate and maintain your SDDC over time. This latest VVD, the VMware Validated Design for Software-Defined Data Center 4.2, extends these capabilities by introducing support for the latest software versions, adding several usability improvements, and now includes steps for implementing Availability Zones and Stretched Cluster support. Please spend some time getting familiar with the VMware Validated Designs and let us know what you think.
