7.4.1 Design Considerations
Depending on the overall architecture and how orchestration is used, orchestrating a vCloud can require one or more vCenter Orchestrator servers. vCenter Orchestrator manages vCloud Director and vCenter using their web services.
vCenter Orchestrator can manage a variable number of hosts per plug-in. Actual limits are subject to a number of determining factors such as bandwidth, number of objects, and concurrent workflows. For example, a single vCenter Orchestrator can manage the following:
Multiple vCloud Director hosts.
Multiple vCenter hosts.
Multiple other host types (UCSM, REST, SOAP, vCenter Update Manager).
NotePlug-ins designed for a given version are designed to work for the same version of the product. If managing a mix of host versions, keep the plug-in version at the earliest common version for backward compatibility (for example, use plug-in 5.1 if managing a mixed vCloud Director 1.5 and vCloud Director 5.1 environment). Avoid mixing host versions where possible—if versions are mixed, the operations need to be thoroughly tested. Using the latest version of a plug-in to support an older version of the product is not supported.
Multiple vCenter Orchestrator servers can manage:
The same vCloud Director host (or load balanced cells).
The same vCenter server.
vCloud Director uses a stateless RESTful web service. There is no session maintained between vCloud Director and vCenter Orchestrator—this minimizes resource usage on both servers. When updates are needed (for example, when starting a workflow using vCloud Director objects), the resources used are proportional to the number of objects updated. This involves sending several HTTP GET/PUT/POST/DELETE requests to the vCloud Director server and, upon reply, creating or updating objects in vCenter Orchestrator. Using multiple sessions (per user mode in the plug-in configuration) multiplies the number of objects. vCloud Director can be load balanced to avoid having a single point of failure and using too many resources on a single cell.
vCenter uses a stateful SOAP web service that supports a large service definition and advanced mechanisms, such as a notification service, that are used extensively by vCenter Orchestrator. Sessions are continually maintained between vCenter and vCenter Orchestrator. This has an important impact on resource consumption on both servers even when there is no workflow activity.
The session activity and associated resource consumption on both servers is proportional to the number of objects loaded in the vCenter Orchestrator vCenter inventory that multiply the number of sessions opened. For this reason, configure the vCenter plug-in using a shared session instead of a session per user, and limit the number of vCenter Orchestrator servers that manage a single vCenter. Workflow activity also consumes resources for objects that are not in the inventory cache.
Additional considerations include the following:
vCenter Orchestrator 5.1 introduced new per-
node maximums
of 20 vCenter
Server instances, 1280
vSphere hosts,
and up to 35000 virtual machines in inventory.
If a vCenter Orchestrator
is overloaded by a large level of objects to
manage, attempt to
tune
the server for higher scalability. Alternatively,
design the solution to use different vCenter Orchestrator instances that manage different vCenter
Servers,
or connect to a large vCenter using different vCenter Orchestrator instances that are configured with accounts to access
different zones of vCenter.