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

[Beck, Andre]

Hi Ryan,

On Tue, Feb 28, 2012 at 12:40:04PM -0500, Ryan Ratliff wrote:
> +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 ).

Sadly I don't have an equivalent class of server to do that, if I had it
would have been my preferred procedure. The point in this installation
is, the hardware was a tad too new when we had to roll out, the DL380G6s
could not run 7.x and 8.x was slow in coming to release, but the customer
insisted on not buying old hardware. So we reactivated a couple of old
G4s and the G6s served as ESX servers meanwhile, until 8.x would become
ready. As usual, the provisorium became entrenched and other things were
more important, so the real transition is happening more than two years
later. Main driver being the end of support of the G4s BTW, the customer
isn't really driven by features.
 
> > 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.

Thanks for spelling that out clearly. I *expected* something like that,
but didn't know how to qualify - except maybe by posting here. I wasn't
left in the cold ;)
 
> > 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.

Ah yep. Thanks for explaining the reasoning, I perfectly understand these
issues. There's a limit to forward compatibility of 6 year old enterprise
Linux distributions, even if hidden in an appliance ;)

Luckily, virtualization is coming to the rescue, snapshots instead of
partitions will do the job better.

> 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.

7825/28 is DL320 style hardware with those pesky BIOS "RAID" things? I
always avoided that device class. I did never understand why they were
supported, while DL360s (with real RAIDs) were not. Probably a "good
enough" decision with lots of Layer 8 (finances) involved.

> 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. 

Second that. It just doesnt help with hardware-specific issues. I'll see
how to deal with that. Maybe a spare G4 can be gotten hold of somehow...

> -Ryan

Thanks a lot for the clarifications,
Andre.
-- 
                    Cool .signatures are so 90s...

-> Andre Beck    +++ ABP-RIPE +++      IBH IT-Service GmbH, Dresden <-