Understanding the Planning & Preparation Workbook for VMware Cloud Foundation and VMware Validated Solutions (v4.3)

If you’ve checked out the Planning & Preparation (P&P) Workbook for VMware Cloud Foundation (VCF) or VMware Validated Design (VVD) in the past, then you are in for some change with this latest release. We introduced this workbook back in the VCF 4.0/VVD 6.0 days in an attempt to evolve the planning experience from a static webpage to something that was more interactive and dynamic. Since then, its become one of the most downloaded documents that my team produces. While that doesn’t indicate how well it has been received, it does indicate that its a subject that a lot of people are interested in, and therefore something that we should continue to invest effort and innovation in.

This latest release covers the VCF platform itself (both Management and VI Workload Domains) and also the recently announced VMware Validated Solutions that I posted briefly about a couple of days ago. In this post I am going to try and take you through the changes in this release as its a big shift forward (I hope) in:

  • The Deployment Options it presents.
  • The manner in which it present the Workflow Tabs (where required values are presented for consumption while you are deploying the VCF platform and/or the individual VVSs)
  • We don’t really refer to Regions any more but rather instances. Ultimately, you can deploy any of the solutions we offer across instances, and those instances could be the same or different geographic locations, so this just makes it feel a bit more inclusive.
  • The number of files. Now there is just one dynamic file, and the options you choose define the profile of what you are deploying (for those with a VVD background, you’ll see the file flip between the familiar SFO or LAX based values based on the options you choose). So instead of using a bespoke Region A or Region B file as before, you now just use different copies of the same file – one for each instance of VCF you want to deploy.

Deployment Options

So let’s start with the most obvious visual changes. The options. To see how much they have changed, lets take a quick look at how the Deployment Options tab looked in the VCF 4.2/VVD 6.2 release.

A total of 15 options on the Deployment Options tab (Management Domain deployment is assumed), each of which was a simple ‘Include/Exclude’ and the file then used that information to inform you what was possible/not possible to combine and where dependencies existed.

Now take a look at the same tab in the latest release:

There are now 25 options (again Management Domain deployment is assumed) but now many of these options are more complex than simply ‘Include’ or ‘Exclude’. Each drop down is more context dependent, giving you options where they exist rather than a simple ‘Include’ based on a VVD prescriptive design. In this part of the blog post I’m going to go through each drop down to help folks fully grasp how everything works.

Some small things to note before we get into the weeds:

  1. ‘Using this Document’ section on the left. Designed to give you a start point on the significant choices. Hopefully this blog and other material I create will extend that information.
  2. ‘Useful Links’ which are pretty much what they say on the tin.
  3. Hyperlinks to each of the Validated Solutions.
  4. No VVD Version listed any more. Now everything is tied to the VCF version.

In general the file flows from top to bottom, in both the logical order of deployment and also the dependencies. So start with enabling what you want and work down. If, however, you are interested in understanding the dependencies I suggest you have a go at working from the bottom up, starting with the VVSs, reading the resulting red messages where it tells you which required dependencies have not been met and working your way back up resolving as you go.

Management Domain Deployment Options

Multi-Instance Integration Model

This option indicates how this management domain will be deployed, and it has three options in the drop down:

  • First Domain: Use this when this is the very first VCF management domain or where no integration with other VCF instances is required. It maps to the original VVD Region A deployment, and the reference values throughout the file will be as they were in the SFO VVD model for Region A (now the first instance).
  • Join Domain: Use this to merge the management domain of the new VCF instance into the SSO domain of an existing VCF instance. Using this will flip the reference values throughout the file to align with how they were for the LAX VVD model for Region B (now the second or additional instance)
  • Additional Domain: Similar to the Join Domain, also shows LAX values, but allows for an independent SSO domain, but ultimately you still intend to integrate the new VCF instance with management components deployed in an another VCF instance.

Considerations:

  • If you are deploying completely independent VCF instances, where none of the management components will interact at any level at all, then you can keep using the First Domain option over and over again.
  • If you use Join Domain, remember that there is a 15 vCenter instance limit per SSO domain, so that limit becomes the sum total of vCenter instance you can have across the combined instances. You do get the single-pane of glass of ELM from this if you want it.
  • Additional Domain gives you the best scalability, but you lose the ELM view.

Snippet of some Reference Values with ‘First Domain’ chosen

Snippet of some Reference Values with ‘Join Domain’ or ‘Additional Domain’ chosen

Host Overlay Network IP Addressing Model

Two options here. DHCP and Static. This controls how the Host TEPs are configured. If you chose DHCP, then you need to have DHCP available on the VLAN you choose. If you choose Static, then bringup will create an IP pool in NSX-T Data Center to be used by the Host TEPs.

Consolidated Management Domain

Simple Include/Exclude option here. Including it will disable VI Workload Domain Deployment. Like this:

Considerations:

All of the VMware Validated Solutions are designed and optimised for the Standard Architecture (i.e. a dedicated Management Domain, plus one or more VI Workload Domains). Therefore each of the documents are written prescriptively in that context. This doesn’t mean that you can’t do them in Consolidated Management domains, it just means YMMV a bit as we don’t expressly test VVS solutions in that model. If you choose to include Consolidated Management Domain, the Planning & Preparation Workbook will advise you of this:

However, in the Workflow tabs it will conveniently (and dynamically) switch from showing you VI Workload Domain values to showing you Management Domain values in all the right places πŸ˜€

Deploy Management Domain using ESXi Hosts with External Certificates

Another simple Include/Exclude option. Use this if you want to do management domain bringup with hosts that already have signed-certificates installed on them.

Management Domain Post-Deployment Options

Apply Signed Certificates

Three options here:

  • Exclude: If you don’t want to use certificates from an external CA, and instead continue with the VMCA signed certificates. Choosing this will have some implications for creating VI Workload Domains in cases where multiple management domains have been joined using the ‘Join Domain’ model. In that case when you create a VI Workload Domain with SDDC Manager B, SDDC Manager A will not be aware of it, and not be able to work with it when attempting to create further VI Workload Domains itself (and vice versa for when B goes to do the same after A has created a new domain). The workaround is to import the VMCA-signed certs for the new VI Workload Domain created by A into the trusted store on B immediately after creating it (and into any other SDDC managers in the same SSO domain if you have more than two)
  • Microsoft CA: Used when you want to configure SDDC Manager with a Microsoft certificate authority to deploy signed certs to the workload domain components.
  • OpenSSL CA: Used when you want to configure SDDC Manager with an OpenSSL certificate authority to deploy signed certs to the workload domain components.

NSX-T Data Center Routing for Management Domain

Three options here too:

  • Exclude: Where you don’t intend to deploy an NSX-T Edge Cluster for any reason.
  • Overlay-Backed: Use this option if you want to deploy an NSX-T Edge Cluster, with BGP routing and overlay backed NSX-T Segments to support the Application Virtual Networks (AVNs) that are used by several of the VMWare Validated Solutions.
  • VLAN-Backed: Use this option if you would rather use an NSX-T Edge Cluster, with Static routing and VLAN backed NSX-T Segments to support the AVNs.

Considerations:

  • Overlay-backed segments are required for items such as Management Domain Federation or Developer Ready Infrastructure in Consolidated mode.

Management Domain Federation

Four options this time:

  • Exclude: No inter-instance NSX-T Federation is required.
  • Active Global Manager: Where you want this management domain to host an Active Global Manager cluster to support NSX-T Federation across instances. This is the minimum requirement for configuring said federation, though it is highly advisable to deploy a standby Global Manager in one of your other instances to ensure Global Manager availability. Typically chosen in the ‘First Domain’ context.
  • Standby Global Manager: when you want to deploy the aforementioned standby Global Manager cluster to this management domain. Typically used in the ‘Join Domain’ or ‘Additional Domain’ contexts.
  • Connect Instance: when you already have your Active and Standby Global Managers deployed, but you are deploying another instance of VCF and want to federate its NSX-T Local Managers into the existing Global Manager deployments. Typically used in the ‘Join Domain’ or ‘Additional Domain’ contexts.

Here you can see the ‘dependencies not met’ in action in the workbook when attempting to enable Management Domain Federation:

Changing the ‘NSX-T Data Center Routing for Management Domain’ to ‘Overlay-backed’ as requested and everything goes green:

Stretched Cluster

If you were a fan of VVD Multi-AZ, this is the option you want. Simple Include/Exclude here based on whether you want to deploy a stretched cluster for the Management Domain

vRealize Suite Lifecycle Management and Clustered Workspace ONE Access

vRealize Suite Lifecycle Manager

Simple Include/Exclude option here. But vRealize Suite Lifecycle Manager (vRSLCM) is required for the deployment of many of the VVS solutions, and also for Clustered Workspace ONE Access

Clustered Workspace ONE Access

Simple Include/Exclude option. Required by the Private Cloud Automation VVS as vRealize Automation has a hard requirement on it for User Authentication. Its also used by the Intelligent Operations Management VVS for user authentication by way of the prescriptive nature of the VVS documentation.

Virtual Infrastructure (VI) Workload Domain: Deployment

Deploy Virtual Infrastructure (VI) Workload Domain

Included by default. Disabled automatically if you enable Consolidated Management Domain

Host Overlay Network IP Addressing Model

Same as for management domain. Two options here. DHCP and Static. This controls how the Host TEPs are configured. If you chose DHCP, then you need to have DHCP available on the VLAN you choose. If you choose Static, then bringup will create an IP pool in NSX-T Data Center to be used by the Host TEPs.

Principal Storage Model

Six choices here. Choose your poison, and the relevant inputs/outputs will be requested/displayed later on in the file. If you used Planning & Preparation in previous releases, you will recall being asked for details for the vSAN network. That same network input is now dynamic requested only if you use vSAN, NFS, vVOLs on iSCSI or vVols on NFS

  • vSAN
  • NFS
  • VMFS on FC
  • vVols on FC
  • vVols on iSCSI
  • vVols on NFS

vSphere Lifecycle Manager Management Model

Simple enough choice here between Baseline and Image based models

Deploy Management Domain using ESXi Hosts with External Certificates

As with the management domain, use this if you want to perform VI Workload domain creation with hosts that already have signed-certificates installed on them.

Prepare Workload Domain for Secondary NFS Storage

If included, this guides the user through the inputs and process required to have the workload domain prepared to mount secondary NFS based storage.

Virtual Infrastructure (VI) Workload Domain: Post-Deployment

Apply Signed Certificates

Simpler than the management domain equivalent. Its just an Include/Exclude option. Thats because its dependent on the choice made for Management. If you have done it for management then you have set out your stall regarding how you want SDDC manager configured with respect to CA integration. If you Include this here, this enables the processes in the VI Workload Domain workflow tab to guide you through applying signed-certs to the newly deployed VI Workload Domain.

NSX-T Data Center Routing for VI Workload Domain

Three options here:

  • Exclude: Where you don’t intend to deploy NSX-T Edge Cluster for any reason.
  • Overlay-Backed: Use this option if you want to deploy an NSX-T Edge Cluster, with BGP routing
  • VLAN-Backed: Use this option if you would rather use an NSX-T Edge Cluster, with Static routing

Note its slightly different to the management domain because what you do with the Edge Cluster in terms of NSX-T segments is largely dependent on the workload requirements you have. The exception to that is the Developer Ready Infrastructure which goes on to prescribe how to create the relevant NSX-T Segments for Workload Management (Kubernetes).

VI Workload Domain Federation

Four options as before:

  • Exclude: No inter-instance NSX-T Federation is required.
  • Active Global Manager: Where you want this workload domain to have an Active Global Manager cluster to support NSX-T Federation across instances. This is the minimum requirement for configuring said federation, though it is highly advisable to deploy a standby Global Manager in one of your other instances to ensure Global Manager availability.
  • Standby Global Manager: when you want to deploy the aforementioned standby Global Manager cluster. .
  • Connect Instance: when you already have your Active and Standby Global Managers deployed, but you are deploying another instance of VCF and want to federates its NSX-T Local Managers into the existing Global Manager deployments.

Considerations:

  • The vRealize Suite is not fully Global Manager aware / capable. Something that will be enhanced in future releases. So what does that mean? It means you can deploy the vRealize Suite, and you can deploy a federated VI workload domain, but at that point you should either a) not integrate the two, or b) accept that there are limitations on what can be done in the federated VI workload domain with the vRealize Suite for now.
  • The Developer Ready Solution is not supported in Federated VI Workload Domains.

So for now, you may see this in P&P when you enable this option along with some of the VVSs.

Stretched Cluster

Again a simple Include/Exclude here based on whether you want to deploy a stretched cluster for the VI Workload Domain.

Considerations:

  • Its dependent on the equivalent Management Domain option being enabled, because the vCenter/NSX-T Manager instances for the VI Workload Domain reside in the Management Domain cluster.
  • The Developer Ready Solution is not supported in on stretched clusters.

Validated Solutions: Deployment

Identity and Access Management for VMware Cloud Foundation

Options are Exclude and Deploy. How often you choose to Deploy will depend on the geographical sprawl of your VCF instances and your preferences around modularity and inter-dependencies between instances. Its perfectly fine to use a single deployment of this solution to handle multiple co-located instances.

Developer Ready Infrastructure using VMware Cloud Foundation

Again the options are Exclude and Deploy with no real caveats other than those referenced above in relation to supportability in connection with other options.

Private Cloud Automation for VMware Cloud Foundation

Three options:

  • Exclude: When you don’t want to deploy the solution, or don’t want to connect this instance to an existing deployment of the solution.
  • Initial Deployment: allows the initial deployment of the Private Cloud Automation (vRealize Automation), performing the initial configuration of cloud accounts etc in vRA and any related configuration of integrations between this and other VVS solutions.
  • Connect Instance: when you have already performed the Initial Deployment in another instance, and now want to plumb this instance into that deployment by creating additional cloud accounts etc.

Intelligent Logging and Analytics for VMware Cloud Foundation

Exclude and Deploy. Its quite normal to deploy independent instances of this solution per VCF instance.

Intelligent Operations Management for VMware Cloud Foundation

Three options here too:

  • Exclude: When you don’t want to deploy the solution, or don’t want to connect this instance to an existing deployment of the solution.
  • Initial Deployment: allows the initial deployment of the Intelligent Operations Management (vRealize Operations Manager) performing the initial configuration of vROPS and any related configuration of integrations between this and other VVS solutions.
  • Connect Instance: when you have already performed the Initial Deployment in another instance, and now want to plumb this instance into that deployment by deploying additional remote collectors etc.

Workflow Tab Presentation

In this second part of the post I’d like to show you the difference in how we now present the values required during a deployment. As before, lets peek at how it used to be:

As you can see they were structured very similarly to the input tabs i.e. by value type

What this meant in practice was that during a deployment, one ended up spending a lot of time repeatedly scrolling up down looking for requested values. Also, because there can be different labels for the same value across different use cases and UIs, you also had to mentally map what you saw on screen to what was being presented in the P&P output tabs.

So we reimagined that this time around too.

Now when you access any of the Workflow tabs, you see a series of tables. Each of which maps directly by name to the corresponding process you will see in the deployment documentation as you follow those processes.

Here is an example from the Private Cloud Automation Workflow tab

Now compare the headings of these tables to the first four headings of the implementation section of the solution

Some things to note:

  • Each line item maps to an input were you need to provide a value or make a choice.
  • They appear exactly as they appear in the UI or CLI, in exactly the order they are requested of you.
  • There are sections for UI and also for our new deployment automation sections. In the case of the automation sections (PowerShell or Terraform) you will see the parameters that you are asked to set before running the relevant PowerShell Cmdlet or Terraform plan.
  • Where there are configuration elements that are ‘prescribed’ i.e. there is no user choice required, just a particular setting that needs to be implemented, theses will still be listed in the documentation. Why? Because there are already a lot of decision points required to plan accurately for a full SDDC deployment and we don’t want to bloat the planning experience by listing items that don’t actually require user forethought.

Cool right? I think so!

Conclusion

The Planning & Preparation Workbook is far more comprehensive than before, and hopefully a significant enhancement to the overall user experience too. I hope this blog post has helped you digest how to navigate its use.

We’d really appreciate your feedback on (but not limited to):

  • Anything I’ve said above that isn’t clear enough.
  • Anything you’ve come across that I haven’t expressly discussed.
  • Typos or other glaring errors (I’ve just re-read it and removed a lot of these I hope!)

Your feedback will go both towards enhancing this blog post and toward any training material that comes out in relation to using the workbook.

Enjoy!

4 thoughts on “Understanding the Planning & Preparation Workbook for VMware Cloud Foundation and VMware Validated Solutions (v4.3)

Add yours

  1. This seems to be the Dell Workbook not the VCF software workbook? πŸ€”

    Looks like to me the Dell inital setup workbook. VxRail Mgr, nodes, NSX, mgmt WLD, WLD1…, edges, BGP, etc….

    Like

    1. Hi Ron. Not sure what you mean. This is all based on the VCF Planning & Preparation workbook. No mention of VxRail manager in it at all. I didn’t link the file directly so what file are you looking at?

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at WordPress.com.

Up ↑

%d bloggers like this: