SUMMARY: Live Upgrade versus Boot Mirrors

From: Ben Rockwood <benr_at_cuddletech.com>
Date: Wed May 19 2004 - 02:15:11 EDT
Thank you to everyone who responded. 

The big debate here was whether or not to abandon traditional boot 
mirrors for LU lock, stock and barrel.  Surprisingly to me this doesn't 
have to be the case.  The bulk of the shops are actually switching back 
and forth between mirror and LU, by breaking the mirrors, then creating 
the boot environment (lucreate) and upgrading it, then rebooting into 
the new BE, and then removing the BE's and re-mirroring.  Done in 
conjunction with Flash Archives (flarcreate) for "holy s***!" recovery 
this seems to be the best method for going about things.  Only 1 person 
responding said that they completely abandoned mirrors for LU because 
they need to maintain an extremely vigorous patching schedual and 
recovery by reboot wasn't a problem. 
Several people responding also noted that they were using LU for 
non-upgrade purposes, namely the ability to change the disk layout on 
their root disks with minimal downtime.   Only 1 respondent had actually 
added disks to their systems in order to mirror and use LU at the same time.

Respondents were: (without email for spam reasons)


Charles J. Giannetto
Darren Dunham (Dr Storage)
Amber Wolfe
Sal Serafino
Les Bemont
Julie Baumler
Rossman
Michelle Scott
Jim Winkle
Jeremy Loukinas
Paul Davies

Original Post was:
 >I've been dragging my heals on Live Upgrade for a long long time and I 
now feel its usable in a production environment.  >However, many Sun 
systems only have 2 disks provisioned for root disks.  Currently I'm 
using 2 disks per system mirrored via >VxVM or SVM.  Because I've 
allocated the full capacity of the disks to root/swap/other I can't 
slide LU in.
 >
 >So here's the question.  Is anyone letting go of their root disk 
mirrors and solely relying on LU to cover them>?  Right now I >have to 
choose, mirrors or LU, and I'm leaning towards LU.  The alternative is 
to try and find a place to start adding UniPak's, >which I'd prefer to 
avoid.   I don't think anyone would want to unmirror their disks, but 
given the constraints there has got to be >at least a couple of you guys 
using LU solely.
 >
 >Any experience/opinions are appreciated.  I'll summarize.

I'm including the reply from Sal Serafino.  Even though I didn't ask for 
an overview of actually doing the procedure he was really nice and 
summed it all up really well.  Seems fitting in the archives:

Hi Ben-

Very easy, but be absolutely sure that you install the LU packages from the OS 
version you are migrating to, i.e. - upgrading from 5.7 to 5.9, install:

application SUNWlur        Live Upgrade 2.0 05/02 (root)
application SUNWluu        Live Upgrade 2.0 05/02 (usr)

from the Solaris-9 installation CDs or DVD, and make sure you read ALL the man 
pages on the LU program and all its subcomponents to understand how it works.  I 
did my first one of these a long time ago, and I will never do an upgrade "the 
old way" again.

What you do is to split the mirrors.  Once you have a mirrored partition free of 
its redundant component, build a *new* mirror with the extra component and leave 
it "broken" with only one slice.  When you do the LU, set up the mirror device 
as the filesystem for /, /var, /usr, etc...  When you activate the new Boot 
Environment and reboot the system, you will mount the new mirror and life goes 
on under the new OS.  When you're sure that everything is OK, you then undo the 
old mirrors and attach the newly liberated components to the new mirrors for 
this BE.  Do this overnight or at a time when the system can afford to be a 
little slower than normal because it has very high I/O during the sync process, 
especially if you are sync'ing multiple mounts.  Then, you can delete the 
original mirrors because they are empty and not needed anymore.


Good luck,
-Sal
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
Received on Wed May 19 02:15:01 2004

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:30 EST