[cisco-voip] Bridge upgrade vs. sub(s)

Tue Feb 28 18:12:42 EST 2012

I don't understand the question, but to give you a good rule of thumb is to
always upgrade from releases prior to 8x on MCS hardware or equivalents and
then move to VMWARE. 

From: cisco-voip-bounces at puck.nether.net
[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Matthew Ballard
Sent: Tuesday, February 28, 2012 5:54 PM
To: Mike ; Ryan Ratliff; Beck, Andre
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Bridge upgrade vs. sub(s)

What happens if you do a DRS from the upgraded version on VMWare to a fresh
install of 8.x of VMWare?  Will that restore it to a supported state in the
database (trying to think of options to avoid doing the upgrade on my main
production system to minimize downtime and off-hours work)?

Thank You,

Matthew

From: Mike [mailto:mikeeo at msn.com] 
Sent: Tuesday, February 28, 2012 2:50 PM
To: Matthew Ballard; 'Ryan Ratliff'; 'Beck, Andre'
Cc: cisco-voip at puck.nether.net
Subject: RE: [cisco-voip] Bridge upgrade vs. sub(s)

Once you install any release prior 8.x on VMWARE it marks the database as
unsupported even when you upgrade to ver8.x. It's a huge issue in the field
and I wish Cisco would address it.

From: cisco-voip-bounces at puck.nether.net
[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Matthew Ballard
Sent: Tuesday, February 28, 2012 4:07 PM
To: Ryan Ratliff; Beck, Andre
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Bridge upgrade vs. sub(s)

Just had a thought on the whole imaging process - if moving to UCS on
VMWare, while I know 7.1.3 (what I am running now, and I will be doing the
migration soon) doesn't officially support VMWare, is it possible to restore
to a VM (on an isolated network), and do the upgrade on the VM instead of
the original production box, and then just switch from the old hardware
based to the new VM based running on 8.6?

Matthew Ballard

Network Manager

Otis College of Art and Design

mballard at otis.edu

From: cisco-voip-bounces at puck.nether.net
[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Ryan Ratliff
Sent: Tuesday, February 28, 2012 9:40 AM
To: Beck, Andre
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Bridge upgrade vs. sub(s)

+1 for Mike's suggestion of having extra server(s) to use for purposes like
this (and a lab mock up of the cluster, doesn't everyone have one of these?
;P ).

I've read the "not
supported except for bridged upgrade" warning signs as "won't work, except
allowing you to make a DRS backup", not "will probably work quite well,
just don't call TAC when it breaks".

A word on bridge upgrades.  The bridge upgrade means that the only services
that will run are the ones necessary for you to take a backup.  That is it.
You get no phone service, no tftp, only DRF.   There are no licensing
requirements (aside from rehosting for the new hardware) because nothing
that would even read the license files is running.

When I read the release notes correctly, upgrading to 8.6 will involve an
automatic reboot that is not optional. One may return to the original
partition after that, but it will cause an outage.

You are reading correctly.  Basically we can't actually run the files
necessary to upgrade the OS due to incompatibilities between RHEL versions.
That middle reboot is actually doing an entirely fresh install on the
inactive partition and as such there's no web services to monitor the
upgrade, no ssh, etc.   If you were to watch the console of the server you'd
see the same old blue screens as it progresses through.   When it's all said
and done as long as you aren't on the older 7825/28s you can still switch
back to the old version though.

Testing in the lab is highly recommended so you are familiar with the
process.  VMs are cheap and for lab purposes it's a great exercise to mock
up your entire cluster and run through the upgrade just to see what it
involves. 

-Ryan

On Feb 28, 2012, at 7:55 AM, Beck, Andre wrote:

Hi Erick,

On Mon, Feb 27, 2012 at 12:35:05PM -0600, Erick Wellnitz wrote:

Does a reboot for the upgrade to switch from the inactive partition to the

active partion take longer than 15 minutes?

Dunno, but I've not even thought about that so far. I've read the "not
supported except for bridged upgrade" warning signs as "won't work, except
allowing you to make a DRS backup", not "will probably work quite well,
just don't call TAC when it breaks".

What I would do:

1. Run the upgrade without a reboot or switching versions

When I read the release notes correctly, upgrading to 8.6 will involve an
automatic reboot that is not optional. One may return to the original
partition after that, but it will cause an outage. Details are not
documented, and I never did such an upgrade before, thus I wanted to do
things in an isolated network where it's clear the live network could not
be killed by it.

2. During my outage window switch versions and reboot

---at this point your system is functioning on the old hardware

Provided that the bridged upgrade does not prevent any services that are
not essential for DRS from running. Or, in other words, the system working
well except for not being supported when kept running in this state. I
couldn't grok from the release notes what would happen, so I wanted to
play it safe. Also note that this will create a licensing problem: I
would have to aquire licenses to run 8.6 on the old hardware (MAC) and
later move them to the new hardware. I had hopes to avoid that by moving
to the new hardware through DRS before touching the licensing, and be
able to resolve any licensing issues (which I expect to crop up for sure,
knowing my Murphy lessons well) in the isolated setup without time pressure.

3. Take a DRS backup for restore to the new cluster

4. Restore to new cluster

5. Switch TFTP settings

--may need to reduce your DHCP lease time

6. Reset all devices/point gateways to new cluster

---at this point you are usig the new hardware

I'm not planning to have the cluster on other IPs after the upgrade. But
I could instead do all the preps starting with your step (4) in my
isolated network as well, so that's not a problem.

I'd imagine there would be less than 15 minutes downtime with this

procedure but I've not done a bridged upgrade with 8.6 yet

The basic problem with the procedure, from my PoV, is that it's all-or-
nothing with regard to it working correctly. If anything goes wrong in
the first two steps, I'm in a time-pressure situation to fix it ASAP,
while the main motive of my procedure is to play it safe and have the
old cluster run unaffected most of the time while I can freak around with
the new one (maybe for days until all issues are fixed).

Of course, it all hinges on the question whether "unsupported for anything
but DRS" is enforced or not.

Feels like I'm going to do some test scenarios in a virtualized cluster
prior to making decisions here, but that doesn't exactly allow to replicate
the "hardware no longer supported" case forcing me into the bridge upgrade
in the first place...

Thanks,
Andre. 
-- 
                   Cool .signatures are so 90s...

-> Andre Beck    +++ ABP-RIPE +++      IBH IT-Service GmbH, Dresden <-
_______________________________________________
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/20120228/4b272760/attachment.html>