There are two types of DEMs that are used within vCAC. Those are:
- Orchestrator DEM
- Worker DEM
DEMs in General
You have to have at least one Orchestrator DEM and Worker DEM, but depending on the size of your environment you may have more than one of each. You may have more than one of each for redundancy purposes as well. DEMs can be installed in active-active pairs providing full resiliency for each other. DEM’s communicate with the vCAC Model Manager to receive work items that need processing. The really nice part is they pull from the Model Manager, the Model manager doesn’t push items to them. This is very helpful if you need ti utilize a DEM in a fire-walled environment.
The basic principal of how a DEM works is they place a call to the Model Manager to see if there is any work for them to do. If there is they pull the work item (an xml instruction set) down and process the work. If you have more than one DEM then which ever calls in first will get the next work item. So having one of ten DEM allows them all to work together to handle the load and provide redundancy.
The Orchestrator DEM is exactly as it sounds. It is responsible for monitoring the Worker DEMs pre-processing workflows, and scheduling workflows for execution. You have to have at least one Orchestrator DEM, but depending on the size of your environment you may have more than one.
The worker DEMs are the ones that actually perform the work needed. When they receive a work item they not only pull down the xml instruction set, but they also pull down anything else needed to perform the work. For example if a work item required a specific workflow that talks to your CMDB as well as a script the DEM would first check it’s local cache to see if it has the require version of the workflow and script, if it does great it will go ahead and process the work item. If it doesn’t have the workflow, or the proper version of the workflow it will pull it down to it’s local cache from the Model Manager.