Published Aug 19th 2019
This post is a result of me wanting to understand the various install-tools, steps, and processes involved in deploying VCF on VxRail.
I heard names of various tools and products that are required to build it out, some mentioned more than others depending upon who was describing the process. Included were the likes of VxRail Manager, Cloud Builder, SDDC Manager, and Lifecycle Manager, with various bundles, packages, plugins and more. And that’s all before we even get to individual product names.
Now this isn’t to be negative, the process is very easy, and getting smoother all the time. This is purely for me to put down on paper what my understanding of the overall process is. What installs what. What doesn’t get installed until you install what. What gets configured by what. And what doesn’t get configured by what.
I promise this post gets more specific than multiple ‘What Whats’.
Taking a Single Site deployment as my example in the lab, at least 2 VxRails get deployed: 1 for the VCF Management Domain and one for the VCF Workload Domain.
VxRail Manager is used to deploy the VxRails, requiring details of DNS, NTP, SSO, hostnames, networks, vlans, etc. These details can be inputted manually or uploaded via xml file when using the VxRail Manager Deployment UI.
VxRail v4.7.211 was deployed.
VxRail Manager in this scenario deploys and configures the VxRail itself including vCenter Server, and the first Platform Services Controller (PSC). Where the VxRail is intended for a VCF solution, the Log Insight solution should not be deployed during the VxRail first run.
The VxRail plugin for vCenter Server is configured during this VxRail installation process, and is used to manage the VxRail natively as required. All standard VxRail installation so far.
This first VxRail is deployed with its own internal vCenter Server. Shortly after deployment, this vCenter Server is ‘externalised’, which means that the vCenter is converted to an External vCenter. This is for the purposes of VCF. This first VxRail will host the VCF Management Domain.
The VMware CloudBuilder ova, specifically for a VxRail, is deployed onto the VxRail and takes the SDDC configuration details from an input file, containing all required IP, hostname, DNS, NTP, SSO details.
Similar to how VxRail Mgr automated the tasks required to deploy VxRail, the Cloud Builder tool automates a myriad of tasks to complete the deployment of the VMware SDDC.
VCF v3.7.2 was deployed.
This automated SDDC deployment includes additional VMs such as the second PSC, SDDC Manager, NSX(-v) Manager, 3 x NSX Controllers, and a 3-node Log Insight cluster, as well as creating VCF-specific Resource Pools, and a bunch of required integrations and certificates.
SDDC Manager also allows the user to deploy, expand and life-cycle additional Virtual Infrastructure (VI) or Horizon Workload Domains. Refer to the end of this post for links exploring these tasks in more detail.
These additional VI/Horizon WLDs are 1:1 with VxRail systems, where the additional VxRails are managed by their respective external vCenter Servers which reside in the Mgmt WLD.
From here on, VMware SDDC Manager is responsible for all Lifecycle operations for the VCF on VxRail solution, top to bottom, all VMware components and all VxRail components. SDDC Manager has it’s own Repository of VMware and VxRail software update bundles, as shown below.
From this Repository, connected to both the DellEMC and VMware Support sites, SDDC Manager schedules and coordinates the life-cycle management of all VCF on VxRail components, as depicted in the following screenshot (taken from VCF on VxRail Whitepaper)
Make sure to also take a look at this VCF on VxRail Full Stack LifeCycle Management Lightboard session with @WhipperSnapper
The full VCF stack is not yet complete though, as, if we want to deploy components such as vRealize Operations Manager (vROps) and vRealize Automation (vRA), then we need to first deploy vRealize Suite Lifecycle Manager (vRSLCM).
vRSLCM can be deployed from SDDC Manager using the relevant software bundle in the Repository. Once deployed, SDDC Manager leverages vRSLCM to deploy vROps and vRA. The vRSLCM UI etc is not accessed though, as everything is driven from within the SDDC Mgr UI.
vROps and vRA can both be deployed directly from SDDC Manager, via vRSLCM, as shown below. In SDDC Manager, browse to Administration > vRealize Suite and select each at a time.
In our lab, vROps was deployed before vRA, which meant that the vROps deployment also included the relevant Load Balancers that vRA would also require.
The vROps deployment was very quick and straightforward, while the vRA deployment required a bit more pre-requisite work before vRA could be deployed.
As you can see from the image above, displayed when the user chooses to deploy vRA from SDDC Manager, some pre-work is required outside of SDDC Mgr to create the SQL Server as well as the Windows Template for the vRA IaaS machines and some certificate work. Nothing too heavy, but just want to call out that pre-work.
Be aware also that while SDDC Manager deploys and life-cycles components such as vRA, vROps, NSX etc, each will still need to be configured specific to the environment and customer requirements.
And obviously no vRA login experience is complete without some VCF on VxRail branding!
So basically that’s that. I got the whole What does What stuff clear in my head, and hopefully this post will help others also. It’s not intended to be technically detailed, it’s more of an overview and to provide an understanding of the major milestones in the VCF on VxRail deployment process. As always, the official documentation and procedures should be referenced for a deployment.
- Deploying VCF on VxRail Mgmt Domain
- Deploying VI Workload Domain on VCF on VxRail
- Deploying Horizon WLD with VCF v3.7 on VxRail
- VCF on VxRail – Expand a Cluster
- VCF on VxRail – Remove Node from Cluster