Distributed Execution Manager
The Distributed Execution Manager (DEM) is of two types. It can either act as a DEM Worker or a DEM Orchestrator.
DEM Orchestrator (DEO)
One of the main tasks of a DEM Orchestrator is to monitor the status and health of DEM Workers:
- If the Worker service stops or loses its connection to the repository (Model Manager Web), the DEM Orchestrator clears all associated workflow instances to the non-functional DEM Worker, thus allowing the other DEM Workers to pick up the workflows. This explains why we don't need to explicitly create high availability for DEM workers.
- Performs the scheduling of daily recurring workflows, such as inventory data collections, state data collection, and performance collections, by creating new workflow instances at the scheduled time.
- The RunOneOnly feature in the DEM Orchestrator ensures that only one instance of any workflow is executed at a given time by the DEM Worker.
- It pre-processes workflows before they are executed including checking the preconditions that are required for the workflows.
- From an availability standpoint, the DEM Orchestrator works in an active/standby configuration. At least one DEM Orchestrator is necessary every time workflows are run. It's also recommended to install an additional DEM Orchestrator instance on a separate machine to help in providing HA in case of failure. In case of failure in the active DEM Orchestrator, the standby Orchestrator will take over automatically since it monitors the status of the active DEM Orchestrator.
DEM Worker
Distributed Execution Manager (DEM) Worker executes the core business logic of custom models by interacting with the VMware database and with systems such as vRealize Orchestrator (vRO), vCloud Director, and vCloud Air . Multiple DEMs can be deployed for scalability, availability, and distribution. DEMs can also manage physical machine-related life cycle events.
