Distributed Install over Geo location

[VirExprt]

Hello ,

i am trying to draft a deployment architecture for Distributed vRA across Geo-location Over WAN where my primary location would be holding all vRA management components and remote will have Infrastructure to deploy VMs on to.

I had listed out to have

- DEMs (O & W) with specific Skills

-     VRO to execute local workflows

- vSphere proxy Agent to have deployment done.

- there may be different Domains forests as well.

I am not sure if the Model Manager is also required at the remote location or not. any idea!!!

If anyone can point me to the right document to support this deployment, would be most appriciated.

thanks,

MG

[ealaqqad]

Hi VirExprt,

Model Manager will need to exist only on the main site. By the way, I don't see why you want to spread the DEM Orchestrator/Workers across sites either. I would keep both of these at the main site as well as you want them to be as close as possible to your manager service. The only two components that make sense to spread out is the proxy agent and the vRO, where most of your vROs will still run in the main site but only a secondary sites workflows will execute in the secondary site.

Hope that help.

Regards,

Eiad Al-Aqqad

Consulting Architect @ VMware

B: http://www.VirtualizationTeam.com

T: @VirtualizationT

F: https://www.facebook.com/VirtualizationTeamBlog

[admin · Accepted solution]

Here is a blog recently written by one of our consultants but it talks about multiple instances of vRA stacks. geo-location | VMware Consulting Blog - VMware Blogs

For a single instance, you can still only have on IaaS and vPostgres active database at any one time and also only one active manager service (..\vCAC\Server\ManagerService.exe), so you can split the node but you will always have these constraints. You could place another manager service in another location, but it will be in passive mode. Keep your DEM orchestrator and DEM workers together.

vRA is not regionally distributed like zones in other CMP's. Your best bet, is to keep the vRA mgmt stack together, then distribute your vSphere Proxy agents next to your vCenter servers. The reason for this is the vSphere proxy agents run and gather data during the datacollection process and once it's complete, its a one time hand off back to the Manager Service to commit to the DB - it also handle the requests to the endpoint using SDK. If you disperse your vSphere proxy agents further away from your vCetner endpoints, it's get more latency to deal with.

The other component you could disperse is the vR Orchestrators, depending on what the vRO server is doing. You can leverage multiple tenants and configure different vRealize Orchestrators per tenant when using Advance Services or service blueprints, but you could also leverage the customer property VMware.VCenterOrchestrator.EndpointName when running stub workflows and where you could specify the vRO server to use, but this depends on what your workflows are doing.

Oli

[VirExprt]

What would be Network Latency permissible for the geo-distributed installtion to work well? Is there any prescribed limit which should be considered?

Thanks,

MG