Since version 7.4, vRealize Orchestrator as well in VRA’s embedded solution or standalone support the multitenancy. Well multitenancy is the capacity to define some “virtual” wall between different organizations.
In production and in real multitenant world, I am still recommend using dedicated orchestrator appliance (clustered or not) than using multitenancy features. This choice is due to the fact that if there are any issues for “customer A” with a failure due to bad formated workflow, I don’t wan’t that “customer B” to be impacted by such a thing. Even with that, to limit the “consumption” of such solutions, well, using multitenancy can be a good choice.
This works pretty simply by the way. In a vRealize Automation world, if you activate multitenancy for vRO, all the tenant admins have access to vRO server. They can develop, code on their own tenants without affecting another one. This solution will be enough comfortable for differents teams for example and minimize the impact that we can imagine.
- Workflow A call Workflow B
- Workflow C call Workflow B
- Workflow C’s dev modify Workflow B and then Workflow A don’t work. 🙂
BE AWARE BE AWARE BE AWARE !!!!!!
The activation of multi tenancy is a non reversibility process ( well – it is “reversible” using snapshots and backup …). But activate it, doing some tests, validate it, using in production and going back to the snapshots is not a good scenario due to the deployed elements that will be lost and a painful work to reintegrate changes in vRA that occurs between the snap and the decision that occurs to leave multi tenancy.
HOW IT WORKS
Don’t be afraid, activate multi tenancy capacity of vRO won’t resume to a lost of all embedded system workflow. It means that users defined package only will not be able for another tenant which is what we want.
In such a dev team environment for example, people can have their own vRA tenants and vRO tenants as well without affected others for example.
For a “production not recommended usage of multi tenancy”, a provider can simply define to allocate functionals workflow “on pay” for customers who wants to use a new endpoint for example.
According to the documentation, which is really straight forward … :
1 – Stopping vRO Services
service vco-server stop && service vco-configurator stop
2 – Go to the bin folder for access to the vro command
3 – Activate multitenancy
4 – Restart Services
service vco-server start && service vco-configurator start
AND NOW WHAT DOES IT CHANGES ….
Well, formerly not a lot of things …. :
So default tenant workflows are available for all tenants : Well it sounds strange but we can imagine than standard workflow can be defined through this tenant for all.
And now what it sounds good : each tenant can easily define its own folder and so on. The other tenant will not have information or anything to use them.
This is the default tenant.
We can see that tenant dev75 and prod75 share the same folder of default tenant. But each of them have their unique folder / workflow.
Of course, tenant can’t modify the flow which are contained in “Tenant Default” as well as actions like delete / add etc … . So it is basically secure.
At the end, this solution can be good to limit the deployment of several instance of vRealize Orchestrator appliances without compromised a security between each tenant but at the end, and due to failure than can impact several tenants due to workflow of the death which could kill all of the people, my choice will definitely to keep VVD recommendations (as well for the version 7.4 which started to support multitenancy) to separate orchestrator per tenant.
For the fan of movies … let’s see this short action in video.