Accepted Solutions
Hi Todd,
I'll just add this reference to the good tips from "Z" (+5)
You have many options here for ELM......if you do decide to install on a separate server the OVA can be based on the smallest CUCM OVA as shown below from the 9.x SRND;
Deployment Scenarios
ELM is installed automatically on the same dedicated server or virtual machine as the Unified CM, SME, and Unity Connection installations. You may choose to use the ELM on one of these servers in a co-resident configuration, as the active managing ELM, or you may opt to run ELM in a standalone configuration where ELM is installed on a dedicated server or virtual machine.
In the co-resident configuration, ELM consumes only a very small amount of resources and hence is considered to have no impact to server or virtual machine sizing. For example, no additional vCPUs would need to be added to the virtual machine configuration because of the ELM service. In the co-resident configuration, ELM resides on the same dedicated server or virtual machine that is sized appropriately for that application.
In a standalone configuration the ELM resides on a separate server or virtual machine created and managed specifically for, or dedicated to, the ELM application. In the standalone configuration, the ELM is sized to the equivalent minimum-sized resource for that application.
The main considerations for choosing between co-resident and standalone deployments center around administration and management. The main benefits of deploying ELM in a standalone configuration are as follows:
- Upgrading a standalone ELM can be done independently from upgrading the applications (Unified CM or Unity Connection). Whereas, in a co-resident configuration, upgrading ELM requires an upgrade to ELM and the co-resident application at the same time.
- Platform changes to Unified Communications applications (Unified CM or Unity Connection) might require changes to a co-resident ELM application. For example, a change in the MAC address would require transferring the registration of the license file(s) for a co-resident ELM; however, such changes for a standalone ELM would not require transferring the registration of the license file(s).
- Administrative changes required on a standalone ELM will not impact the application servers. For example, on a co-resident configuration, having to upgrade or reboot the ELM would require an upgrade or reboot of the application.
The trade-off, however, with a standalone configuration is that it requires a separate server or virtual machine to be created and managed.
Deployment Recommendations:
- If you are installing only a single application on a single server or cluster, run ELM co-resident.
- If you are installing a very small number of application instances, you may:
–
Run ELM on a separate virtual machine or server. This approach provides more administration and management flexibility but requires a separate virtual machine or server for ELM.
– Run a different ELM on each application server if you do not need license pooling and do not desire centralized license management.
– Run a single ELM co-resident with one application server if you want license pooling and/or centralized management, but you are unwilling to dedicate a virtual machine or server for running the ELM.
- With Cisco Business Edition 6000, ELM would typically be co-resident with one of the application servers. However, if desired, it is possible to run ELM as a standalone virtual machine, but it would need to be counted against the maximum number of applications allowed on a Cisco Business Edition 6000 server.
- If you have a medium to large deployment, run ELM on a separate server or virtual machine. The incremental impact on the number of required virtual machines or servers i