0% found this document useful (0 votes)
121 views7 pages

Enterprise Installation Standards (EIS) : EIS Standard Using Live Upgrade in The EIS Environment

sdasfd

Uploaded by

jimalif
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
121 views7 pages

Enterprise Installation Standards (EIS) : EIS Standard Using Live Upgrade in The EIS Environment

sdasfd

Uploaded by

jimalif
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

Enterprise Installation Standards

(EIS)

EIS Standard Using Live Upgrade in the EIS Environment

1 Introduction
In June 2007 the EIS Standard “Boot Disk Layout and Mirroring” was updated to include
the recommendation that a Live Upgrade partition be included as slice 3 on the boot disk
(same size as the root slice). This EIS standard “Using Live Upgrade in the EIS
Environment” is intended to help those who are preparing to carry out patch updates or a
Solaris upgrade and intend to use the Live Upgrade partition in conjunction with the EIS-
DVD.
The first released version of this document was published in the EIS web July 2007.
The recommended disk layout for a server's boot disk (without software mirroring) is:

Slice Name Start Cyl Size

0 / 15Gb1

1 swap 4Gb

2 backup 0 Whole Disk

3 liveupgrade 15Gb

4 /app Customer data

If required, and the disk has a higher capacity the size of root and/or swap may be larger;
however slices 0 and 3 should be identical in size.
Note: Live Upgrade does not mandate that the slices be identical in size, nor does it insist
that the slices match – a boot environment on a server may have separate slices for / and
/var, while the Alternative Boot Environment (ABE) may only have a single slice for both /
and /var. However, having different layouts makes use of Live Upgrade more complex,
and if the sizes are different, you may be unable to move from a larger BE to a smaller BE
if your filesystem is relatively full.

1 15Gb is recommended for a 36Gb disc – for larger disks at least 18Gb is recommended.

Sun Internal and Approved Partners Only -1- Vn 2.7 Created: 14 Dec 2009
1.1 Scope
When a server/desktop is installed according to the EIS Methodology and a Live Upgrade
partition is included, this partition is created but not populated in any way.
The FIRST time Live Upgrade is used, the existing boot environment has to be converted
to a Live Upgrade boot environment and an Alternative Boot Environment (ABE) is created
as well. Once this has been done, the process is slightly different.
There is little point in performing this first step until you actually wish to use Live Upgrade
for the first time.
This document will outline how to do the initial setup, as well as how to use Live Upgrade
subsequently.

1.2 How Live Upgrade works (in a nutshell)


Live Upgrade allows you to maintain multiple boot environments simultaneously, and
allows you to set any of them active for the subsequent reboot.
The process of using Live Upgrade consists of:
1. Creating an ABE, usually by replicating the current boot environment.
2. Performing any system changes such as an upgrade or patching, or even configuration
changes to the newly created ABE.
3. Setting the ABE to be active on the next reboot.
4. Reboot the server.
5. Check if OK.
6. If not revert to original environment by making it active and rebooting again.

1.3 When to Use Live Upgrade:

1.3.1 For Solaris Upgrades


The primary function of Live Upgrade is to allow the Solaris Operating System to be
upgraded with minimal interruption and the ability to safely revert to the previous
environment. Once the Live Upgrade facility is in place, it should be the default
mechanism for performing a Solaris Upgrade.
There are instances where you may NOT wish to use Live Upgrade to upgrade the Solaris
operating environment. This is primarily in situations where the integrity of the existing
running O/S is in doubt.

1.3.2 For Solaris Patching


Given the non disruptive nature of the Live Upgrade process, it is a natural mechanism for
patching as it requires no downtime to apply the patches, and a system reboot is all that is
required to get the system running the newly patched O/S.
The question arises whether to use Live Upgrade for every patch action. Our
recommendation is, certainly one would use Live Upgrade for applying a large number of
patches – when applying a single patch that does not involve a reboot it may be worth
applying the patch directly rather than going via Live Upgrade. This obviously requires a

Sun Internal and Approved Partners Only -2- Vn 2.7 Created: 14 Dec 2009
clear understanding of the nature of the patch and it's ease of backout.

1.3.3 For any other System Changes


Live Upgrade isn't limited to simply patches and upgrades. One could use the Live
Upgrade mechanism for applying ANY kind of change to the system. It allows the ability
for the changes to be applied at leisure with no downtime, and at the point of switching
from the current to the updated configuration, there is a clear and bulletproof regression
plan.
It should be evident that Live Upgrade isn't appropriate for changes that DON'T affect the
Solaris configuration, such as Firmware and BIOS updates.

Sun Internal and Approved Partners Only -3- Vn 2.7 Created: 14 Dec 2009
2 Initialising Live Upgrade
2.1 Running Live Upgrade for the FIRST time
To use Live Upgrade an ABE needs to be created. This is done using the lucreate
command. The first time lucreate is run and the current environment as well as the new
ABE needs to be named, and the slices the ABE will use defined.
The boot environments are given labels, and it is recommended to create a meaningful
naming policy for the boot environments.
The lucreate command is used to create the ABE and name the current:
# lucreate -c "<current boot environment name>" -m /:<root slice>:ufs -n
"<alternate boot environment name>"

2.1.1 Unmirrored Disk, single / slice


In the case of the EIS standard for a non-mirrored disk, where our current O/S is Solaris 9,
and we wish to upgrade to Solaris 10, the lucreate command would look like this:
# lucreate -c "Solaris9" -m /:/dev/dsk/c0t0d0s3:ufs -n "Solaris10"

2.1.2 Mirrored Disk, single / slice


If we had a mirrored root disk as per the EIS bootdisk standard, the command would like
this:
# lucreate -c "Solaris9" -m /:/dev/md/dsk/d30:ufs -n "Solaris10"

(where /dev/md/dsk/d30 was your mirrored lu partition)

2.1.3 Mirrored Disk, separate / and /var


If you chose to have a separate / and /var partition, you should provide 2 equivalent slices
for your alternate / and /var slices as well:
# lucreate -c "Solaris9" -m /:/dev/md/dsk/d30:ufs -m /var:/dev/md/dsk/d60:ufs -n
"Solaris10"

(where /dev/md/dsk/d30 was your mirrored lu partition).

Sun Internal and Approved Partners Only -4- Vn 2.7 Created: 14 Dec 2009
3 Performing Updates
3.1 Upgrades
Once the ABE has been created as per Section 2 above, performing an upgrade is trivial.
1. Mount the Solaris media of the O/S to be upgraded to.
2. Update the Live Upgrade packages on your current boot environment:
# <solaris-media-location>/Solaris_x/Tools/Installers/liveupgrade20
-nodisplay -noconsole
3. Run Live Upgrade:
# luupgrade -u -n Solaris10 -s <solaris-media-location>
4. Observe the output and follow the instructions for anything that needs checking.
5. Activate the new boot environment and reboot:
# luactivate Solaris10
# init 6

3.2 Patching
Please note that it is not possible to patch a Solaris 10 ABE from Solaris 8 or 9 – see
http://blogs.sun.com/patch/date/20090218 for background information. You must activate
and boot into the Solaris 10 boot environment before patching it.
To apply patches, you simply need to mount the ABE and apply patches using the -R
option to patchadd which allows patching to be applied to a relocated root. Once the
patching is done, unmount, luactivate and reboot:
# lumount <ABE-name>
The command returns the mountpoint used, typically /.alt.<ABE-name>
# patchadd -R /.alt.<ABE-name> <patchlist>
# luumount <ABE-name>
# luactivate <boot-env>
# init 6

3.3 Patching using the EIS-DVD


This process is a combination of the standard EIS-DVD patching process and the Live
Upgrade patching process outlined above. Please note that EIS-DVD 31JUL07 is the
minimum version required to function correctly. Ensure that the current environment has
the latest EIS scripts by running setup-standard there first:
Mount or install the EIS-DVD. Commands assume DVD:
# cd /media/eis-dvd/sun/install
# ./setup-standard.sh
Now mount the ABE
# lumount <ABE-name>
The command returns the mountpoint used, typically /.alt.<ABE-name>
# ./setup-standard.sh -R /.alt.<ABE-name>
# cd /media/eis-dvd/sun
# patch-EIS -R /.alt.<ABE-name> /var/tmp
# luumount /.alt.<ABE-name>
# luactivate <boot-env>
# init 6

Sun Internal and Approved Partners Only -5- Vn 2.7 Created: 14 Dec 2009
4 Additional Live Upgrade Maintenance
Once the boot environments have been created using the lucreate command, most work
simply involves manipulating your boot environments using some simple lu commands:
lustatus: Display the status of the boot environments.
lumake: Used to make the inactive BE a copy of the current BE:
# lumake -n <inactive BE>

lurename: Change the name of a Boot Environment.

4.1 Examples
Assume we currently have 2 BEs. The active one is called Sol9, and the inactive one is
called Sol8 (because we upgraded from 8 to 9 a few months ago). We now wish to apply
a patchset to the Solaris 9 partition. Lets call this patch set P1.
First we make Sol8 a copy of Sol9
# lumake -n Sol8

Then we give it a sensible name:


# lurename -e Sol8 -n Sol9P1

We mount, apply the patches and unmount.


Finally we activate and boot off it:
# luactivate Sol9P1
# init 6

A few months later, we decide to make the big jump to Solaris 10. We now have an active
BE called Sol9P1 and an inactive one call Sol9.
First give it a sensible name:
# lurename -e Sol9 -n Sol10

Then copy the current environment to it:


# lumake -n Sol10

(as you can see order of the lurename and lumake commands is unimportant).
Update to the Solaris 10 lu packages:
# <solaris-media-location>/Solaris_10/Tools/Installers/liveupgrade20
-nodisplay -noconsole

Perform the upgrade:


# luupgrade -u -n Sol10 -s <solaris-media-location>

Sun Internal and Approved Partners Only -6- Vn 2.7 Created: 14 Dec 2009
5 References
Additional information about Live Ugrade is available in the form of the official
documentation on docs.sun.com, Blueprint Articles, BigAdmin articles and Sunsolve
InfoDocs.
Given that Live Upgrade has been improved from it's initial inception on Solaris 8, some of
the information MAY be slightly dated. Always refer to the official docs.sun.com
documentation as definitive.
• docs.sun.com: http://docs.sun.com/app/docs/doc/806-7933/6jgp914av
• BigAdmin: http://www.sun.com/bigadmin/features/articles/live_upgrade.html
• Technical Instruction 206844: Solaris[TM] Live Upgrade Software: Minimum Patch
Requirements
• Technical Instruction 204332: Configuring Solaris[TM] Live Upgrade 2.0, Command
Line (Note: this document is a little out of date, but conceptually correct).
• Excellent Live Upgrade BluePrint: (does not use EIS-DVD as patch base as is
customer facing. Later versions will incorporate the EIS Standards where appropriate):
http://www.sun.com/blueprints/0607/820-2188.html

6 Acknowledgements, Feedback
Thanks are due to many colleagues for their contributions to this document. Copies are
available on the EIS-websites and on the EIS-DVD.

Comments & RFEs are welcome. Please use ServiceDesk (Search Tasktype & enter "EIS") or mail to EIS-
[email protected] if no SWAN access available – typically for a partner.
© 2003-2009 Sun Services

Sun Internal and Approved Partners Only -7- Vn 2.7 Created: 14 Dec 2009

You might also like