5.8 vRealize Orchestrator

vRealize Orchestrator provides service orchestration. It can automate tasks across VMware products, leveraging vCloud API, VIM API, VMware NSX APIs or the vCenter Chargeback API. Using generic plug-ins (SSH, SOAP, HTTP REST, SQL, PowerShell, Active Directory) or third-party specific plug-ins, it can orchestrate other systems as well. vRealize Orchestrator provides a large library of workflows and actions in its base configuration, and its library grows with each newly installed plug-in. Powerful workflows can be built with little or no knowledge of an API.

• It can act as an extension that is subscribed to RabbitMQ and consumes vCloud Director messages. In this role, vRealize Orchestrator extends vCloud Director by providing additional services (backup, additional controls, CMDB integration, and so on).

• It acts as an orchestrator for common onboarding or tenant lifecycle tasks. The tasks are triggered by an external portal (VMware vRealize Automation Advanced Service Designer, or through the vRealize Orchestrator REST API). By utilizing plug-ins, the tenant service can be configured end-to-end.

• As of vRealize Orchestrator v 7.3 can be installed only as a virtual appliance.

• vRealize Orchestrator requires a database. While external MS SQL and Oracle databases are still supported, they are in deprecated mode, scheduled for removal in future releases. Internal PostgreSQL database is preconfigured on the appliance and is production ready.

• High-load production environments and clustered highly available vRealize Orchestrator deployments still require a shared external database.

• In highly available cluster mode, multiple vRealize Orchestrator server nodes with identical server and plug-in configurations work together as a cluster and share one database. Only the active nodes respond to client requests and run workflows. All server nodes communicate with each other by exchanging heartbeats (by default every 5 seconds, with a 12 heartbeat threshold) through the database. If an active instance fails to send heartbeats, it is considered non-responsive and one of the inactive instances takes control to resume all of the workflows from the point at which they were interrupted. A network load balancer must be used to send the client requests to an active node.

• While it is possible to have more than one active node in a cluster, vRealize Orchestrator Client cannot be used due to concurrency issues. Default number of active nodes is one (recommended maximum of three).

• It is possible to scale out with independent vRealize Orchestrator instances that are each deployed for a specific task (for example, consuming dedicated AMQP queue).

• A multinode plug-in can be used to coordinate workflows between independent vRealize Orchestrator instances.

• LDAP authentication is no longer supported. Instead VMware Identity Manager must be used to integrate with external LDAP Identity Providers.

• The following are recommended external vRealize Orchestrator plug-ins:

• Scalability – A single vRealize Orchestrator instance supports up to 300 concurrent workflow instances in the running state, with 35,000 managed virtual machines in the inventory.