Configuring Multi-Org Tenancy in vRA 8.x - Part 7: Understanding vRealize Orchestrator Options

vRealize Automation vRealize Orchestrator vRA vRO Multi-Tenancy

Published on 3 November 2020 by Christopher Lewis. Words: 1547. Reading Time: 8 mins.

Introduction

In this series of posts, we will be taking a look at how to configure a Multi-Organization Tenancy (aka Multi-Tenancy) in vRealize Automation (vRA) 8.x.

In this post, we will review some of the different options for vRealize Orchestrator (vRO) multi-tenancy within a vRealize Automation (vRA) 8.x multi-organization tenancy environment.

For more information on the rest of the posts in this vRA 8.x series, click here .

vRO Multi-Organizational Tenancy Options

The first thing to point out is that vRO 8.x is not a natively multi-tenant platform. Therefore, when it comes to multi-organizational tenancy support for vRO, there are three main/basic architecture patterns to consider:-

Configure the embedded vRO across all tenants.
Deploy and configure a single external vRO 8.x instance across all tenants.
Deploy and configure a single external vRO 8.x instance per tenant.

Wait… is that it? Couldn’t we combine some of those patterns?

In short, Yes we could also take a hybrid approach to vRO. In this approach, we would configure a combination of the embedded vRO and external vRO with the latter being either per tenant or across all tenants. In this pattern, each tenant would have multiple vRO endpoints that could be used to run workflows. I do not delve too deep into the rabbit hole this creates in this post, but essentially (and for completeness) these options would be:

Configure the embedded vRO across one or all tenants, then deploy and configure a single external vRO 8.x appliance across all tenants.
Configure the embedded vRO across one or all tenants, then deploy and configure a single external vRO 8.x appliance per tenant.

So, is that everything?

No, we could also have (and I have seen customers with) a multi-tiered vRO deployment either per tenant or across all tenants. For everyone’s sanity, I have deemed vRO Multi-Node outside of the scope of this topic/post because, in my view, it would still fall into the high-level architecture patterns detailed above.

Note: I may cover how to configure vRA 8.x to use multiple vRO 8.x endpoints and choose between them in a separate post.

Option 1 - Configure the Embedded vRealize Orchestrator across all Tenants

Overview

In this configuration we would essentially configure the embedded vRO 8.x service that is already deployed along with vRA 8.x to connect to each tenant. This is by far the simplest way to configure vRO for use within a vRA 8.x Multi-Organizational Tenancy environment. But be warned, this does not provide isolated multi-organizational tenancy akin to what we see within vRA 8.x. What does that mean? All entitled users, in all tenants can see everyone all workflows/actions/inventory unless we configure Groups and restrict access to individual items. For some use cases, especially in the service provider use case where customers are creating their own vRO workflows, it may not be suitable. From a configuration and resources perspective, there are a number of advantages and a couple of noteworthy disadvantages as detailed below.

Advantages vs Disadvantages

Table: Advantages & Disadvantages of using the Embedded vRO across ALL tenants
Advantages	Disadvantages
No additional vRO appliances required.	workflows / Actions / Inventory are shared across all tenants in the same vRA deployment.
Access to the Orchestrator Service can be restricted by User/Group membership through vRA/vIDM tenant.	Item-level access (using vRO Groups) is onerous and not recommended unless absolutely required.
Item-level access (using Groups) can be configured to restrict what different users/tenants edit or run.
Only need to configure the Orchestrator integration for those the tenants that need it.
In a clustered deployment, vRO is also clustered.

Why consider this approach?

In my view, the use of the embedded vRO service across all tenants is best used in the following use cases:

A company that has decided to use multi-organizational tenancy but does not need to isolate anything within vRO.
A service provider that only allows customers to consume standard services and not develop their own XaaS components (i.e. have no access to the vRO service which is controlled via the RBAC model)

Option 2 - Deploy a single External vRO 8.x instance across All Tenants

Overview

In this configuration we deploy an external vRO instance (appliance or cluster), configure vRA as the authentication provider and then configure integration endpoints within each customer tenant to connect to the vRO instance. This is very similar to the previous configuration in terms of using a shared vRO, but vRO is just external. Just like the previous configuration, there are a number of advantages and disadvantages to this approach and we’ll cover those next.

Advantages vs Disadvantages

Table: Advantages & Disadvantages of using a single External vRO across ALL tenants
Advantages	Disadvantages
An external vRO for customer tenants will give extra level of separation and resilience from the provider tenant (if this is a requirement).	Additional Appliance(s) are needed and so are additional resources (4 vCPU, 12GB RAM and 200GB Disk per appliance)
Access to the vRO can be restricted by User/Group membership through the vRA/vIDM tenant.	Additional load balancer resources and configurations are required to create a vRO Cluster.
Only need to configure the Orchestrator integration for those the tenants that need to use it.	workflows / Actions / Inventory are shared across all tenants in the same vRA deployment.
Item-level access (using Groups) can be configured to restrict what different users/tenants edit or run.	Item-level access (using vRO Groups) is onerous and not recommended unless absolutely required.
Access to the (external) Orchestrator (vRO) would be through a separate portal (URL).

Why consider this approach?

In my view, the use of the an external vRO across all tenants is best used in the following use cases:

A company that has decided to use multi-organizational tenancy but needs to isolate the all of the customer tenant vRO workflows/actions/inventory items from their provider tenant. They want to use the same vRO workflows across tenants.
A service provider that has XaaS (vRO) heavy Service Catalog and would like to off-load the vRO workflow load so that it doesn’t affect the vRA cluster. Most likely the service provider only allows customers to consume standard services and not develop their own XaaS components (i.e. have no access to the vRO service which is controlled via the RBAC model)

Option 3 - Deploy a single External vRO 8.x instance Per Tenant

In this configuration we deploy an external vRO instance (either an appliance or a cluster) per tenant, configure vRA as the authentication provider and then create integration endpoints within the customer tenant to connect to the single vRO instance. Depending on the specific use case you can also, optionally, configure the first (or provider) tenant to use the embedded vRO service to segregate customer and provider workflows. Again, there are a number of advantages and disadvantages to this approach and we’ll cover those next.

Advantages vs Disadvantages

Table: Advantages & Disadvantages of using a single External vRO instance per tenant
Advantages	Disadvantages
An external vRO per tenant will give full isolated multi-tenancy for vRO and vRA.	Additional resources are required for the vRO Appliance(s) (4 vCPU, 12GB RAM and 200GB Disk per appliance)
Access to the different vRO deployments must be registered to vRA so they can be restricted by User/Group membership through the vRA/vIDM tenant.	Additional load balancer resources and configurations are required to create a vRO Cluster.
Only need to configure the Orchestrator integration for those the tenants that need to use it.	workflows / Actions / Inventory are dedicated to a vRA tenant.
Normally no need for Item-level access configuration.
Access to the (external) Orchestrator (vRO) would be through a separate portal (URL).

When should you consider this approach?

In my view, the use of the an external vRO across all tenants is best used in the following use cases:

A company or service provider that requires full isolated multi-tenancy end to end for both vRA and vRO.

Recommendations

Like all good consultants, my recommendation around which vRO architecture to use is essentially… it depends.

My defacto recommendation for customers is to always keep it simple and use the embedded vRO where possible. To quote the Mandalorian, “This is the way” and for most customers this approach will be more than adequate.

The reasons for this recommendation are:

No additional infrastructure (appliances or load balancers) are required.
Embedded vRO is clustered out of the box (in a clustered deployment)
The User Interface (UI) is integrated into the UI for vRealize Automation as a Service, so its a single portal.
The RBAC model is integrated with vRA RBAC at the Organization, Service and Role levels.

Final Thoughts

It probably comes as no surprise that my defacto recommendation is the same as the VMware Best Practice. The best practice is called that for a reason. That said, there is absolutely nothing wrong with deploying external vRO instances. There will always be reasons for external vRO, even outside the configuration of Multi-Tenancy. These could be technical limitations or just architectural decisions made based on technical or business requirements. If you choose external vRO for the right reasons, it is not “wrong”.

One thing is certain, the only way you can get complete isolated multi-tenancy with vRA/vRO right now is by deploying and configuring dedicated vRO instances per tenant. Will that change in the future? I honestly don’t know.

Published on 3 November 2020 by Christopher Lewis. Words: 1547. Reading Time: 8 mins.

Blog Categories: VMware vRealize Automation