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

Tue Feb 28 16:06:31 EST 2012

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/152a911c/attachment.html>