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 is minimal in this case, and the trade-off between operating expenses and capital expenditures is favorable.
The ELM may be deployed in any of the following ways:
As the description implies, one ELM instance can support an entire enterprise or global deployment. This model provides the most simplicity by utilizing one common centralized license pool for all the Unified Communications applications subscribing to the ELM.
For an enterprise that has multiple Unified Communications deployments across the globe, multiple ELM instances can be configured per region or lines of business (for example, one for North America, a second for EMEA, and a third for APAC). This model enables an enterprise to account more easily for the costs of licenses across differing fiscal boundaries.
For those customers requiring even more granularity, an ELM instance can be configured for each Unified Communications application. For example, if a customer has three Cisco Unified CM clusters, three ELM instances can be configured. This scenario is useful for customers who operate along more granular accounting lines and prefer multiple smaller license pools in order to better manage operating costs and other expenses.
From;
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab09/clb09/callpros.html#pgfId-1347951
Cheers!
Rob
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 is minimal in this case, and the trade-off between operating expenses and capital expenditures is favorable.
The ELM may be deployed in any of the following ways:
As the description implies, one ELM instance can support an entire enterprise or global deployment. This model provides the most simplicity by utilizing one common centralized license pool for all the Unified Communications applications subscribing to the ELM.
For an enterprise that has multiple Unified Communications deployments across the globe, multiple ELM instances can be configured per region or lines of business (for example, one for North America, a second for EMEA, and a third for APAC). This model enables an enterprise to account more easily for the costs of licenses across differing fiscal boundaries.
For those customers requiring even more granularity, an ELM instance can be configured for each Unified Communications application. For example, if a customer has three Cisco Unified CM clusters, three ELM instances can be configured. This scenario is useful for customers who operate along more granular accounting lines and prefer multiple smaller license pools in order to better manage operating costs and other expenses.
From;
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab09/clb09/callpros.html#pgfId-1347951
Cheers!
Rob
