To increase the availability of the Orchestrator services, start multiple Orchestrator server instances in a cluster with a shared database. vRealize Orchestrator works as a single instance until it is configured to work as part of a cluster.

Orchestrator Cluster

Multiple Orchestrator server instances with identical server and plug-ins configurations work together in a cluster and share one database.

All Orchestrator server instances communicate with each other by exchanging heartbeats. Each heartbeat is a timestamp that the node writes to the shared database of the cluster at a certain time interval. Network problems, an unresponsive database server, or overload might cause an Orchestrator cluster node to stop responding. If an active Orchestrator server instance fails to send heartbeats within the failover timeout period, it is considered non-responsive. The failover timeout is equal to the value of the heartbeat interval multiplied by the number of the failover heartbeats. It serves as a definition for an unreliable node and can be customized according to the available resources and the production load.

An Orchestrator node enters standby mode when it loses connection to the database, and remains in this mode until the database connection is restored. The other nodes in the cluster take control of the active work, by resuming all interrupted workflows from their last unfinished items, such as scriptable tasks or workflow invocations.

Orchestrator does not provide a built-in tool for monitoring the cluster status and sending failover notifications. You can monitor the cluster state by using an external component such as a load balancer. To check whether a node is running, you can use the health status REST API service at https://your_orchestrator_server_IP_or_DNS_name:8281/vco/api/healthstatus and check the status of the node.


Workflow development does not support having more than one active Orchestrator server in a cluster. If you have more than one active Orchestrator node in a cluster, when different users use the different Orchestrator nodes to modify the same resource, concurrency problems occur. To have more than one active Orchestrator server node in a cluster, you must first develop the workflows that you need. After that you can set up Orchestrator to work in a cluster.