Unity Connection HA Across 40 ms Metro Links: Rejecting the Proposal and Resizing Ports and Storage
HealthAlliance has 2,400 Cisco Unity Connection subscribers on a single physical server in Rotterdam. Voicemail is sized at 24 ports at HQ and 6 ports at a satellite clinic that reaches the cluster over a 12 Mbps link. Average message length is 45 seconds, users keep messages for 30 days, and the busy hour produces about 8 messages per subscriber with roughly three calls per message. The board now requires voicemail to survive the loss of either data center. The primary site is Rotterdam; a secondary site in Utrecht is 40 ms round-trip away over a Layer 2 metro link. The proposed design places the Unity Connection publisher in Rotterdam and the subscriber in Utrecht as an active/active high-availability pair. Legal also requires that clinic users cannot dial national numbers from the voicemail TUI after a toll-fraud incident last year, and HR wants Jabber visual voicemail for all staff. Each node has 600 GB of usable storage. You must approve or reject the HA design and validate the sizing.
1. Approve or reject the proposed active/active pair spanning Rotterdam and Utrecht. Give the reasoning and the alternatives.
Read the worked answer
Reject it. A Unity Connection cluster is a high-availability pair, not a stretched disaster-recovery topology: the two servers must sit on the same LAN with very low, consistent latency (single-digit milliseconds), because the pair shares state continuously. A 40 ms round-trip metro link is outside that envelope even when the Layer 2 circuit looks stable, and the failure mode is ugly: instead of clean failover you get split behavior, intermittent message-store access, and a recovery that requires restoring from backup anyway. The L2 metro link also becomes a shared failure domain that silently converts a circuit blip into a voicemail outage.
Three credible alternatives, in order of preference. First, keep the HA pair in Rotterdam on separate hosts and separate storage, and treat Utrecht as a DR target using scheduled Digital Networking? No, use DRF backups replicated to Utrecht with a written, tested restore procedure, and be honest about the recovery time for a 400+ GB store. Second, if the business truly needs site-independent voicemail, deploy two independent Unity Connection clusters, one per data center, and join them with digital networking over SMTP so users can address each other across clusters; accept that some cross-cluster conveniences are reduced and verify the specific limitations against the release you are running. Third, ask the network team whether the metro link can be delivered at under about 5 ms with a dedicated circuit or dark fibre; if it can, the stretched pair becomes supportable, but only then.
Do not present the stretched pair as a cheap DR win. It is the option most likely to fail during the exact event it was bought for.
2. Validate the port count and the 600 GB storage budget. Show your assumptions and state what you would change.
Read the worked answer
Ports first. Thirty ports for 2,400 subscribers is about 80 users per port. Typical voicemail-only planning runs nearer 20 to 30 users per port, and this site's traffic is heavier than typical: 8 messages per subscriber per day with roughly three calls per message means most of those calls touch the voicemail system. A defensible busy-hour estimate is 2,400 users times 24 voicemail-relevant calls per day, with perhaps 15% landing in the busy hour and a portion hitting the system rather than a human. Even with conservative assumptions that lands well above 30 ports. Pull the actual port-usage reports from the existing server before you design anything; if the data confirms the estimate, plan for 80 to 120 ports at HQ rather than 24, and note that port count also governs the SIP trunk capacity you need from CUCM.
Storage second. Message minutes: 2,400 users times 8 messages times 0.75 minutes equals 14,400 minutes per day; over 30 days that is 432,000 minutes. At Cisco's rough planning figure of about 1 MB per minute for G.711, the message store alone is roughly 432 GB. Add greetings (a few hundred MB), deleted-message retention, and 20% headroom, and 600 GB is marginal at best. Each node of an HA pair holds a full copy of the store, so both nodes must fit it.
Two levers: record in G.729a to halve the store to roughly 216 GB, or cut retention to 21 days. I would do both, then re-check against real message statistics rather than the busiest-hour estimate. Capacity planning on assumptions is how voicemail clusters fill up in month nine.
3. Address the toll-fraud restriction and the Jabber visual voicemail requirement without breaking either.
Read the worked answer
Treat these as two separate controls that happen to share a server. For toll fraud, the mistake is blocking dialing in the TUI only. Build it in layers: remove the PSTN partition from the voicemail port CSS so the ports themselves cannot dial out, create a restriction table that blocks 9, 0, and international patterns, and apply it to the clinic's Class of Service. Then remove the user-facing escape hatches: clear 'allow transfers to numbers not associated with users or callers' and restrict any transfer or callback to outside numbers in the Class of Service. Verify by calling in from an external phone, attempting a transfer to a national number, and confirming the attempt is denied and logged.
For visual voicemail, Jabber uses the Unity Connection REST interface over HTTPS, which means three things must line up: the REST server must be enabled and reachable from wherever Jabber runs, the Unity Connection server certificate must be trusted by the client device, and the clients must be able to resolve and reach the server through whatever path they use. On-network users are straightforward; remote users need the traffic proxied through Expressway-C and Expressway-E, and personal devices that trust only public roots will reject an internally issued certificate. Plan for publicly trusted certificates on the client-facing chain, or distribute the internal root through MDM on managed devices only and accept that BYOD users lose the feature.
Test the restriction first and the visual voicemail second, because a restriction table change can break message-notification features silently while visual voicemail failures are loud and easy to spot.