Query about vRealize Suite Lifecycle Manager appliance placement in second site VCF deployment

[NFerrar]

We're about to deploy a second VCF site (to federate with an existing site) and the placement of the vRSLCM appliance confuses me. VMware docs state: 

In each VMware Cloud Foundation instance, a vRealize Suite Lifecycle Manager appliance deployed on the cross-instance NSX segment

But I don't understand why, surely it would be better to have it in the Reg_B AVN as it will never move between sites? Has anyone deployed it in the Reg_B AVN instead of the X-Reg AVN - is it supported that way? I'm not sure if the VMware docs are a statement or recommendation. https://docs.vmware.com/en/VMware-Cloud-Foundation/4.4/vcf-vrslcm-wsa-design/GUID-D59D9A51-F829-4472... (last text box section under "Multiple VMware Cloud Foundation Instances" column

[GaryJBlake · Accepted solution]

Hi@NFerrar 

This is a statement and not a recommendation. If you're deploying vRSLCM via SDDC Manager the only place where SDDC Manager knows to place the appliance is the cross-instance NSX Segment.

Update: 11 May 2023

Adding some additional clarity to this original response as there seems to be some misunderstanding which is causing further confusion as it relates to VMware Validated Solutions and vRealize Log Insight.

Each SDDC Manager instance configures its own local set of Application Virtual Networks a local-instance and a cross-instance NSX segment. Based on this configuration the SDDC Manager instance will deploy the vRealize Suite of products to specific NSX Segments as documented here within the same location. When deploying vRealize Log Insight in two instances (Site A and Site B) you end up with the following configuration:

Site A

• vRSLCM deployed to the cross-instance NSX segment created by the Site A SDDC Manager instance (192.168.11.x)
• SDDC Manager configures a Load Balancer during deployment of vRSLCM on the Site A NSX Manager
• vRealize Log Insight deployed to the local-instance NSX segment created by the Site A SDDC Manager Instance (19.168.31.x)
• vRealize Operations, vRealize Automation and Standard/Clustered Workspace ONE Access are also deployed via vRSLCM to the cross-instance NSX segment

Site B

• vRSLCM deployed to the cross-instance NSX segment created by the Site B SDDC Manager instance (192.168.12.x)
• SDDC Manager configures a Load Balancer during deployment of vRSLCM on the Site B NSX Manager
• vRealize Log Insight deployed to the local-instance NSX segment created by the Site B SDDC Manager Instance (19.168.32.x)

Regards

Gary

[mannharry]

The primary justification for that is that vRSLCM is gonna manage all your vRealize suite of Products, which includes Workspace one, vRealize Automation, and vRealize Operations.

If these products are residing on cross nsx segments x-region, then we must deploy vrslcm too in the xRegion, so that in case of site failures these products are accessible and also their manageability remains .

[NFerrar]

That's not the case for a second site though (that will be federated with another site), the cross-region vRS products are all managed via vRSLCM in the primary site, it's just vRLI (on a local site AVN) that would be in vRSLCM. It basically comes down to SDDC Manager not being multi-site aware so assumes you're always just doing a standard vRSLCM

In the end for our deployment, on the advice of VMware, we didn't deploy a vRSLCM in the second site (apparently they're going to update their design guidance to reflect this), for the the second site you just create a new environment in the primary site's vRSLCM and install vRLI from there.

(this updated advice from VMware was off the back of me querying how I allow for AD authentication to the second site vRSLCM as unless you add the second site standalone/local WOA/vIDM into it there's no way of doing it and the design guidance only covers adding the cross-region WOA/vIDM into vRSLCM but that's already been added into the primary site's vRSLCM)