Working with vRealize Orchestrator (vRO) in a enterprise environment requires some kind of high availability and redundancy. Even vSphere HA would work for some small environments in a big one, where you expect a high number of operations, needs a clustered solution. Fortunately vRO7 supports that and now I will go through the path of configuring it. A high level schema of what we want to achieve looks like this:
Assumptions:
- You have a functional AD, DNS, NTP
- You have a functional vSphere 5.5/6 environment
- You have at least two vRO7 appliances deployed and configured with valid TCP/IP Settings
- You have credentials to login to the vRO7 Control Center
- You have a external DB Server from the Compatibility Matrix
Database Creation
I will use Microsoft SQL Server 2012 for this demo. You can create the database by executing the following query:
CREATE DATABASE vro_cluster GO ALTER DATABASE vro_cluster SET READ_COMMITTED_SNAPSHOT ON; GO ALTER DATABASE vro_cluster SET ALLOW_SNAPSHOT_ISOLATION ON; GO
If successful you should get result similar to this one:
Assigned DB Owner privileges to the newly created database to a user which we will use during the cluster configuration.
Configuring vRO7 Node1
Login to https://vRO1_FQDN_OR_IP:8283/vco-controlcenter/ and use the root ID and the password you typed during the appliance deployment.
First let’s configure the vRO to use the DB which we just created:
Select SQL Server and fill up the data about you SQL server
Once you click Save, you will be prompted to Update the Database which will apply the schema needed automatically.
Even it can be done after building the cluster, I would recommend to configure the Authentication Provider prior:
You will notice that LDAP authentication will not be supported in future versions, but I would like to keep the vRO cluster independent from vSphere and vRA and that’s why I would prefer to use it.
Once it is done, click Save and we are done with the first instance of vRO.
Configuring vRO7 Node2
Login to https://vRO2_FQDN_OR_IP:8283/vco-controlcenter/ and use the root ID and the password you typed during the appliance deployment. Click on Cluster Management and then on Join Node to Cluster
Fill up the host name of the vRO Node1 as well as user name and password. You can use either root or any other administrator ID which we have configured previously. In enterprise environment usually separate service ID with non-expiring password is being used.
It will take minute or two for the operation to complete after you click Join. If everything is alright you should see similar screen:
You will have to restart both of the vRO instances to apply the changes. After reboots complete you should see both of the vROs in Orcestrator Node Settings and their synchronization status:
By default and general recommendation by VMware is to have one Active Node and the rest as Stand-by. This is mostly because to protect you from losing any data if several people are working on a single workflow. For test/dev environments where lots of people are suppose to create and modify vRO elements it is good to follow the recommendations. However, if your production environment is following some kind stricked change control, it is not suppose anyone to modify anything expect the approved maintenance/change window. With a proper organization and well documented procedures I think Active-Active scenario would also work good for production environment.
Connect vCenter Sever to vRO
As a test of what we have done, I will go and add a vCenter server to the active node and check if it will replicate to the change to the stand-by node.
Login to vRO7-node1 using the java or windows client. You can get them from https://vRO1_FQDN_OR_IP:8281/vco/
Login using a ID entered during the Authentication Provider configuration or root.
Now you should restart the active node in order to point the stand-by as active. This is required because you cannot connect to a stand-by vRO.
Once you login and go to the Inventory view, you can see that the previously created vCenter connection on Node1 is also replicated on Node2.
In order to protect your cluster the chosen database server should also be protected by one way or another. There are detailed guide how to configure your LB to check the status of the vRO7 and balance between them.
I hope that this is useful.
Nikolay Nikolov
Latest posts by Nikolay Nikolov (see all)
- Build a vRealize Orchestrator 7 (vRO) Cluster - February 13, 2017
- VMware vCenter Server Appliance 6.5 – Install and Configure - November 16, 2016
- Nutanix Upgrade fails at 93% - August 18, 2016
Hey Mate! Does it support MSSQL with Always On configuration ?
Officially, not, or at least I nothing like this is mention in the compatibly matrix. You will have to relay on HA for SQL availability.
ouch 🙂
Microsoft AlwaysOn does not need vSphere HA for availability. So called, SQL availability groups take care of that. However, this is tricky, usually but not always, WSFC is way to go. I was wondering about, how Load Balancer fits into this setup? ;and also, what did you use for that ? Or this was just possible scenario ?
AlwaysOn is not supported, that’s why I mentioned HA for a standalone SQL. You put two or more vRO behind LB and then you add the VIP to the vRA for example and if you lose one vRO your automated tasks which leverage vRO resources will not fail. This is how the medium and large vRA environments are being desinged in the reference architecture.
I was more interested in LB it self rather than how it works. However, thanks for enlightening me on vRA architecture and medium and large enterprise solutions