[cisco-voip] Questions regarding migration of CUCM 7.1.5.31900-3 to a UCS platform

Matthew Saskin msaskin at gmail.com
Thu Mar 31 15:26:15 EDT 2011


Edit, step 6 *should* read
6 - DRS restore of 8x backup to *UCS* server

Matthew Saskin
msaskin at gmail.com
203-253-9571



On Thu, Mar 31, 2011 at 3:25 PM, Matthew Saskin <msaskin at gmail.com> wrote:

> Fastest way to do it (per cluster) in my opinion:
>
> 1 - Acquire spare MCS server
> 2 - Implement change freeze on CUCM cluster in question, start cataloging
> "emergency changes" that are made
> 3 - Perform DRS backup of Publisher, DRS restore to spare MCS server
> 4 - Upgrade spare MCS server 7x to 8x
> 5 - DRS backup of spare MCS server
> 6 - DRS restore of 8x backup to MCS server
> 7 - Rebuild subscribers from scratch on UCS
> 8 - Migrate IP phones from 7x cluster to 8x cluster on UCS
> 9 - remove change freeze, re-implement any emergency changes that were
> required
>
> There's some significant effort involved, in particular on the subscriber
> rebuilds, ensuring any custom TFTP files (wallpapers, etc.) are in place.
> That said, it's less work overall than doing a double upgrade.
>
> Matthew Saskin
> msaskin at gmail.com
> 203-253-9571
>
>
>
>
> On Thu, Mar 31, 2011 at 2:01 PM, Peter Slow <peter.slow at gmail.com> wrote:
>
>> Hello Everyone,
>>
>> I'd like your input on a project I'm working on. I have five clusters,
>> all of which are currently running 7.1.5.31900-3. My goal is to
>> upgrade each of them to 8.5 running in/on UCS.
>>
>> My _understanding_ is that I need to get a cluster to at least 8.0(2c)
>> (which is what actual version, btw?), do a DRS backup, install the
>> same version in UCS and then restore the backup into the VM.
>>
>> I was under the impression (until i read all of
>> http://tinyurl.com/5nuf25 ) that on most I2 servers a Bridged upgrade
>> is required and this would present an issue, because of time
>> constraints - The smallest cluster is 9 servers, the largest is 17 or
>> so and it can take upwards of 10 hours to upgrade a cluster, and about
>> that long  to actually get everything switched over _after_ upgrading
>> is complete. (I realize this doesn't need to be a serial process, but
>> it mostly is at the moment, aside from subs having their versions
>> switched in pairs.)
>>
>> The main goal here is to get to UCS, and the team I'm working with
>> REALLY doesn't want to upgrade the MCS servers one weekend, then move
>> to UCS servers a week later. (Thus far, I've been telling them that
>> this is going to be necessary AND that there is NO way to install
>> 7.1(5) in VMWare and _then_ upgrade to 8.x) Right now my only
>> alternative _seems_ to be getting a CUCM in the lab running 7.1(5),
>> doing a DRS export to that form the production cluster, upgrading
>> that, then doing a DRS backup from _that_ to the UCS cluster in order
>> to get the pre-staged environment up.
>>
>> There's some additional background below.
>>
>> Constraints:
>> The first cluster to be upgraded is composed exclusively of 7845-I2
>> IBM servers.
>> In some cases clusters might have  7845-I1's functioning as TFTP or
>> MoH servers, I am allowed to replace these with I2's prior to the
>> upgrade if I need to.
>> 76 GB drives and 4 GB RAM in the I2s
>> The upgrades / reboots etc need to take place during a weekend outage
>> window that provides me with enough time to roll back if something
>> awful happens. (I'd like to get everything done in a day, so that I
>> can spend Sunday troubleshooting if I need to.)
>>
>> Questions:
>> * If a bridged upgrade is required, do _all_ servers in the cluster
>> need to be upgraded, or can I just upgrade the publisher, export with
>> DRS and proceed from there?
>> * Can I run 8.5 on my existing cluster of 7845-I2's w/ 76 gig drives
>> and 4 gigs of RAM? http://tinyurl.com/5nuf25 seems to indicate that I
>> can, but if it's wrong, I get fired.
>> * Am I correct about an upgrade from 7.1(5) to 8.x within VMWare not
>> being supported / possible?
>>
>> -Pete
>>
>> Peter I. Slow
>> AIM: humboldtbgp
>> Email: peter.slow at gmail.com
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20110331/6198ce20/attachment.html>


More information about the cisco-voip mailing list