To add to Bill's comments (+5 for Bill), you should also better understand the point of clustering within Unity Connection. This is often misinterpreted or just not understood. CUC is designed to provide 100% redundancy between the 2 servers in the cluster. So, when you say "split" users across 2 servers in a cluster - this is not accurate. You do not "split" users across servers in a CUC cluster. Likewise, when you can support 20,000 users and 500 ports in a cluster - this does not inherently mean that you have 500 ports actively answering calls. Your setup is more like this:
Publisher - should handle Database and Web Services (IMAP, administration, etc). Ideally, no call processing is done by the Publisher during normal business operations. It is possible to overflow excess call traffic to the Publisher during normal operations but this isn't something most should plan on doing.
Subscriber - call processing, when you call VM you should hit the Subscriber first so all user operations and calls would first go to the Subscriber during normal operations.
Redundancy - Either server can takeover all operations for a period of time during an outage. If the Publisher goes down, the Subscriber can support all end users and provide up to 250 ports for call processing. Likewise, if the Subscriber goes down - it can handle all operations for the Subscriber.
In CUCM, your primary VM ports might be a line group of x number of ports that are pointed to the Subscriber. A good rule of thumb is that you designate about 25% of your ports solely to MWI and notification. So, those ports are not available for calls and they are not included in your line group. You need to replicate this on the line groups for both the Pub and Sub in CUC as well as they are separately configured within CUC as well. You would then have a separate line group in CUCM for the Publisher and in the Hunt List, the priority would be Sub first and then Pub second. This meaning that the Sub will handle all calls unless you absolutely have to rollover to the Pub for excess call flow OR in a failover scenario, all calls would go to the Line Group that has registered ports (so priority doesn't really matter here as the failed device would likely no longer have any ports registered to it).
In short terms, I've seen some pretty large implementations where 96 ports or even 144 ports is considered A LOT of ports. However, as Bill said - if you are doing a lot of outdialing or other operations, this could impact your port usage and cause it go up or down. For the most part, there is no hard rule of thumb that says x number of users requires y number of ports. Instead, you usually base the number of ports on examination of legacy VM system port usage or, in a greenfield environment, you may want to consider overprovisoning ports vs. underprovisioning (i.e., go with 144 or more for very large implementations vs. 24 or 48 so as to make the user experience and technology adoption more smooth for end users).
Hailey
Please rate helpful posts!
