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

[Ryan Ratliff]

+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/738229af/attachment.html>