vSphere Archives

In this blog post I will cover detailed step-by-step deployment of vRealize Suite Lifecycle Manager (vRSLCM) on VMware Cloud Foundation (VCF) management domain (learn more about management and workload domains here). This is the first post in the multi blog post series covering the vRealize Suite deployment on VCF.

vRealize Suite Lifecycle Manager (vRSLCM) is a tool that automates the lifecycle management of the vRealize suite components. vRSLCM is currently available for the customers who have purchased any of the vRealize suite bundles (Standard, Advanced or Enterprise). Starting from VCF 3.7, we can now leverage the vRSLCM capabilities inside the SDDC Manager to deploy and manage the vRealize Suite components such as vRealize Automation, vRealize Operations and vRealize Log Insight. The SDDC Manager calls the vRSLCM APIs to deploy the vRealize suite of products and to perform day 2 lifecycle management tasks such as patching and up-gradation. The vRSLCM and SDDC Manager together cut down the deployment time of the SDDC and vRealize products substantially and this results in faster time to value. Customers can start deploying workloads on the infra on day 1 as the SDDC Manager automates most of the deployment tasks.

To start the deployment of the vRealize components, we first need to deploy the vRSLCM component. This can be downloaded from the “Bundles” section in the SDDC Manager UI. The download components will only show up if an account with the license entitlement is added under the “Repository Settings”.

We can find the install bundle that contains the OVA for vRSLCM. The size of this bundle is around 5GB. We need to make sure we have downloaded the install version that related to the VCF deployment. For instance, there are two files for vRSLCM. One with vRA, vROPS and vRSLCM packed into a single bundle and is of 13GB size. This is only compatible with version 3.5 of VCF.

Once the bundle is downloaded, we move to the deployment process of vRSLCM. The tab to deploy vRSLCM can be found under Administration>vRealize Suite

Click the Deploy button to kick off the deploy process. The UI presents us with a list of pre-requisite checklist that needs to be in place before the actual deployment begins. One of the pre-requisite is to pre-download the OVA which we did in the previous step.

Once we have made sure that we have all the pre-requisites covered, we click “Begin”. We enter the network details in the first page and proceed.

The next set of info we need to provide is the appliance details. Note that we need to only provide the FQDN and the DNS details, it then resolves the FQDN and automatically assigns that IP to the VM.

We review the details we have provided and click “Finish”. This kicks off the vRSLCM deployment process.

This takes anywhere between 30-45 mins to complete. Once complete, the link for the vRSLCM components is shown on the SDDC manager UI.

One thing to notice here is that once vRSLCM is deployed and is up and running, the vRLI which was earlier deployed as part of VCF bring up process and management domain deployment will now be moved under vRSLCM.

We have successfully deployed vRSLCM on VMware Cloud Foundation and we will look at deploying vRA and vROPS using vRSLCM through SDDC Manager UI in the upcoming posts.

VMware Cloud Foundation (VCF) is an integrated platform that bundles the compute, storage and network virtualization products from VMware into a validated, automated deployment solution that customers can use to build a cloud-ready infrastructure. It combines the power of vSphere, vSAN, and NSX along with the automation engine (SDDC Manager) to create a powerful stack that can cater to many enterprise use cases.

VCF is going to be the layer that brings consistency on the infrastructure layer whether you are deploying it for on-premises private cloud or you are opting for a managed service offering like VMC on AWS from AWS. It solves the challenges and complexities of the current hybrid cloud models (a combination of private cloud and native public cloud). With VCF forming the consistent layer across different clouds, the movement of workloads becomes seamless and takes away the need for re-architecting and refactoring applications for native public clouds.

VMware Cloud Foundation is built as per VMware Validated Design (VVD) standards and inherits the concept of differentiating management and workload VMs using different clusters (different VCs in the case of VCF). This has been a standard architecture for enterprise deployments. VCF has a similar concept of Management and Workload domains. Management domain holds all the VMs (shown below) that are required for managing the workload and workload domains.

The Workload Domain (WD) holds all the customer workloads. Every workload domain comes with its own vCenter server and an NSX manager dedicated for that WD (shown below). The workload domains can either be general clusters that hold customer VMs or they can be built for specific use cases like Horizon View, PKS, Machine learning, etc.

A VCF deployment is called a “Standard Architecture” if there is a dedicated management domain and at least one workload domain.

VMware Cloud Foundation also has an option of “Consolidated architecture” for smaller deployments that have 6 or fewer nodes. This is because a standard architecture needs 4 nodes for the management domain and 3 nodes for the first workload domain, 7 in total. The consolidated architecture allows the management and customer workloads VMs to sit in the same cluster and leverages vSphere resource pools provide isolation between management and user workloads.

Now, this is clear from the deployment guide. The grey area is Where do you choose the deployment type while deploying VCF?

And the answer to the question is: you don’t get to choose the type. Every deployment of VCF starts with a consolidated architecture. When you deploy VCF, the management domain deploys with a default resource pool “<user-def>-user-vm” (shown below) that can be used for deploying customer workloads.

Customers can either the consolidated architecture deployment (or) use the SDDC manager UI to create a new workload domain. That makes it a standard architecture. This move doesn’t have to be during the bring up. If a customer wants to start with lesser than 6 hosts and then scale up depending on the workload growth, that too can be an option. I will cover this in the next topic. How to move workloads from the management domain to workload domain when you switch from consolidated to standard architecture.

So to summarize, there is no option to choose the type of deployment when you are deploying VCF and you can start with a small footprint and scale up when the workload demands it. This provides a flexible option for customers rather than creating separate architectures and making it hard to switch between the two.

vSphere

VMTN Profile