[cisco-voip] Approximate service outage times for a 5.1->6.1 upgrade

Thu Jul 31 10:58:37 EDT 2008

To help in the upgrade process, I believe the SNRD also states that you can
upgrade the firmware on the phones to match the new CM versions firmware to
make the process move quicker when the upgrade time comes.

Scott

On Thu, Jul 31, 2008 at 1:46 AM, Darren <darren at dnsl.com> wrote:

> I think it has to do with TFTP server order and CUCM order,
>
> i.e. if your CUCM's are configured as
>
> sub
> pub
>
> and you upgrade your pub, the phones don't flip over until the sub is
> rebooted. (in my experience).  Even if the pub reboots with new images, etc
>
> Watching the logs for the entries :), its hard enough staying awake when
> the DVD / image is extracting...
>
> D
>
>
>
> On 7/31/08, Kris Seraphine <baryonyx5 at gmail.com> wrote:
>>
>> Luckily 40s/60s upgrade much quicker.
>>
>> My understanding is that after rebooting the Publisher once the CM
>> service comes up (after installing the license) phones that use the
>> Pub for the primary CM will re-register with it and automatically
>> begin the firmware upgrade.  If this is not the case, someone please
>> correct me.
>>
>> Also, according to the 6.1.2 release notes, you don't have to wait
>> until the publisher upgrade finishes to begin the subscriber upgrade.
>> 'You can begin the upgrade of the subscriber nodes after the following
>> information displays in the log:
>>
>> PRODUCT_TARGET is CCM
>> PRODUCT_NAME is Cisco Unified Communications Manager
>> PRODUCT_VERSION is <product version to which you are upgrading, such
>> as 6.1(2)> '
>>
>>
>>
>> On Wed, Jul 30, 2008 at 10:14 AM, Darren <darren at dnsl.com> wrote:
>> > I've done a few of these and here's the way I've done it in the past.
>> >
>> > *) If using DNS make sure reverse DNS is working correctly (sub upgrade
>> uses
>> > this regarding the pub)
>> > *) upgrade Pub, reboot to new partition
>> > *) when this comes backup it doesn't become properly active (depending
>> on
>> > config of cluster) so normally the phones will stay with the existing
>> > cluster (again depending on config of cluster).
>> > *) upgrade subscriber and reboot.
>> >
>> > Phones will reboot, in my scenario this never took more than 20 minutes,
>> > with 7940's and 60's.  From 200 - 400 handsets.
>> >
>> > To do each server takes approximately 2 hours each.  I was under the
>> > impression you had to do it in this order to get the publisher database
>> in a
>> > good condition for the subscriber database to use, but I could be wrong
>> > (anybody able to clarify this).
>> >
>> > D
>> >
>> >
>> >
>> >
>> > On Wed, Jul 30, 2008 at 11:01 PM, <keli at carocomp.ro> wrote:
>> >>
>> >> There are close to 1000 phones, a mix of 7940, 7960 and CIPC
>> soft-phones,
>> >> load-balanced across the two servers (so some have the sub as primary,
>> while
>> >> others have the pub as primary in their CCM group)
>> >>
>> >> Also, since the servers are in a datacenter, and the phones in several
>> >> locations in a metropolitan area, I'm not exactly sure of the
>> "distances" of
>> >> each location ...
>> >>
>> >> Anyway, the good news for me seems to be that the 7940/60 phones have a
>> >> much smaller firmware :)
>> >>
>> >> thanks,
>> >>  Zoltan
>> >>
>> >> Quoting Kris Seraphine <baryonyx5 at gmail.com>:
>> >>
>> >>> Are all the phones registered with the same box?  If so, your downtime
>> >>> should be limited to the time it takes to upgrade the phone firmware.
>> >>> The SRND has a section on how to calculate this.  I just upgraded 25
>> >>> 7941s to 8.3.5 last night over a T1 line and it took 24 minutes (from
>> >>> start until all phone were registered again).  This was with peer
>> >>> firmware sharing enabled.
>> >>>
>> >>> I'd imagine you'd want to install the license after rebooting the
>> >>> publisher but before rebooting the sub.  The CM service won't start
>> >>> until the license is installed.
>> >>>
>> >>> On Wed, Jul 30, 2008 at 8:49 AM, Kelemen Zoltan <keli at carocomp.ro>
>> wrote:
>> >>>>
>> >>>> Hi,
>> >>>>
>> >>>> I'm going to upgrade a cluster of two CUCM 5.1.2 servers (both
>> MCS7845)
>> >>>> from
>> >>>> 5.1.2 to 6.1 release.
>> >>>>
>> >>>> However, the customer is keen on knowing expected service outage
>> times,
>> >>>> and
>> >>>> the duration of the whole operation in itself. Even if they do not
>> >>>> expect
>> >>>> exact timeframes, telling them "it will take a lot" just won't do :-)
>> >>>>
>> >>>> So can anyone give me an idea, of how much time would it take to
>> upgrade
>> >>>> this cluster and of this, approximately how much would they be
>> without
>> >>>> service?
>> >>>>
>> >>>> Especially, since, as far as I understand, upgrading in itself does
>> not
>> >>>> mean
>> >>>> interruption is service, since I'm working on an inactive partition.
>> >>>>
>> >>>> Also, is this planned order correct (basically based off SRND):
>> >>>> - upgrade first node, don't reboot
>> >>>> - upgrade second node (there's only one), don't reboot
>> >>>> - reboot first node with switching versions
>> >>>> - reboot second node with switching the version
>> >>>>
>> >>>> the Feature licenses for the v6 should be uploaded before the upgrade
>> >>>> process, or after the first node reboot?
>> >>>>
>> >>>> thanks,
>> >>>>  Zoltan
>> >>>> _______________________________________________
>> >>>> cisco-voip mailing list
>> >>>> cisco-voip at puck.nether.net
>> >>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> kris seraphine
>> >>>
>> >>
>> >>
>> >>
>> >> ----------------------------------------------------------------
>> >> This message was sent using IMP, the Internet Messaging Program.
>> >>
>> >> _______________________________________________
>> >> cisco-voip mailing list
>> >> cisco-voip at puck.nether.net
>> >> https://puck.nether.net/mailman/listinfo/cisco-voip
>> >
>> >
>>
>>
>>
>> --
>> kris seraphine
>>
>
>
> _______________________________________________
> 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/20080731/4840fdda/attachment-0001.html>