Migrating a Large Cisco UCM Cluster to Cisco UCS over the Weekend
To serve our headquarters campus in San Jose, California, Cisco IT deployed one of the world’s largest Cisco Unified Communications Manager (Cisco UCM) clusters, with 9 pairs of subscribers and a publisher supporting this one campus. Together with these main 19-servers the campus cluster also includes Unity node servers, presence servers and management servers, for a total of 48 Cisco MCS 7845s. In June 2012, we migrated these legacy servers to virtualized machines running on Cisco Unified Computing System (UCS) servers over a single weekend.
This campus UCM cluster in San Jose serves 39,000 registered devices and 350 primary and backup voice gateways. Yet we were able to make this migration in such a short timeframe because we made a critical planning decision. Instead of migrating the servers individually, we fully installed and configured the new server infrastructure in advance, then made a complete cutover from the old servers to the new ones on the first night of the migration weekend.
One drawback of this approach was that we weren’t able to make changes in the production database that tracks phones for about two weeks before the switch. This was because we needed a snapshot of that database to load onto the new cluster for testing and the cutover itself. This restriction meant that if phone moves, adds, or changes (MAC) were entered into the old database during that two weeks, we needed to manually enter that information into the new database when the new clusters went online. We had implemented a MAC freeze during this time, but there were a few changes that were so important that we allowed the changes to the old cluster during the freeze, and then re-entered them manually into the new database.
After the cutover, we pointed the gateways to the new cluster and tested them to verify correct dialing for each call type. In addition, all phones needed to reregister on the new clusters, which for the most part they handled automatically. One minor issue, about four percent of phones had configuration issues that prevented automatic reregistration, which meant we needed to make a remote or on-site fix over the next few days.
Although we did not reduce the number of network nodes in this migration, we are using fewer physical servers in San Jose because we can use virtualization to mix and match multiple hosts on the Cisco UCS B-Series blades – about 4 virtual servers per physical blade.
The San Jose migration follows our earlier success in migrating the Cisco UCM cluster in Johannesburg, South Africa and in other company locations, as well as migrating our voicemail, and Exchange platform to UCS. Looking forward, we will apply this approach to migrations of our remaining Cisco UCM clusters and the call processing clusters that handle our WebEx calls in multiple hubs around the world.Tags: