5.5.2

Table Of Contents
Access Rights to Orchestrator Server
The type of vCenter Server license you apply in the Orchestrator configuration interface determines whether
you get read-only or full access to the Orchestrator server capabilities.
Table 54. Orchestrator Server Modes
vCenter Server License Edition vCenter Orchestrator Mode Description
Standard Server You are granted full read and write
privileges to all Orchestrator elements.
You can run and edit workflows.
Foundation Player You are granted read privileges on all
Orchestrator elements. You can run
workflows but you cannot edit them.
Essentials Player You are granted read privileges on all
Orchestrator elements. You can run
workflows but you cannot edit them.
Evaluation Server You are granted full read and write
privileges to all Orchestrator elements.
You can run and edit workflows.
NOTE All predefined workflows are locked as read-only by design. To edit a standard workflow, you must
duplicate the workflow and make changes to the duplicated workflow.
Selecting the Orchestrator Server Mode
By default, the Orchestrator server runs as a single instance in standalone mode. To increase the availability
of the Orchestrator services, you can set up the Orchestrator server to work in cluster mode and start
multiple Orchestrator server instances in a cluster with a shared database.
Orchestrator supports two server modes.
Standalone mode
The Orchestrator server runs as a standalone instance.
Cluster mode
Multiple Orchestrator server instances with identical server and plug-ins'
configurations work together in a cluster and share one database. Only the
active Orchestrator server instances respond to client requests and run
workflows.
All Orchestrator server instances communicate with each other by
exchanging heartbeats. Each heartbeat is a timestamp that the node writes to
the cluster shared database at a certain time interval. Network problems, an
unresponsive database server, or overloading might cause an Orchestrator
cluster node to stop responding. If an active Orchestrator server instance fails
to send heartbeats for the failover timeout, it is considered as 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 must be customized according to the
available resources and the production load.
The non-responsive node is automatically shut down and one of the inactive
instances takes control to resume all interrupted workflows from their last
not completed items, such as scriptable tasks, workflow invocations, and so
on. You can restart the node that was shut down by using an external script
based on the Orchestrator REST API or manually.
Chapter 5 Configuring the Orchestrator Server
VMware, Inc. 63