Sun Microsystems Logo
Products & Services
 
Support & Training
 
 

Previous Previous     Contents     Index     Next Next
Chapter 33

Solaris Live Upgrade (Overview)

This chapter describes the Solaris Live Upgrade process.


Note - This book uses the term slice, but some Solaris documentation and programs might refer to a slice as a partition.


Solaris Live Upgrade Introduction

Solaris Live Upgrade provides a method of upgrading a system while the system continues to operate. While your current boot environment is running, you can duplicate the boot environment, then upgrade the duplicate. Or, rather than upgrading, you can install a Solaris Flash archive on a boot environment. The original system configuration remains fully functional and unaffected by the upgrade or installation of an archive. When you are ready, you can activate the new boot environment by rebooting the system. If a failure occurs, you can quickly revert to the original boot environment with a simple reboot. This switch eliminates the normal downtime of the test and evaluation process.

Solaris Live Upgrade enables you to duplicate a boot environment without affecting the currently running system. You can then do the following:

  • Upgrade a system.

  • Change the current boot environment's disk configuration to different file system types, sizes, and layouts on the new boot environment.

  • Maintain numerous boot environments with different images. For example, you can create one boot environment that contains current patches and create another boot environment that contains an Update release.

Some understanding of basic system administration is necessary before using Solaris Live Upgrade. For background information on system administration tasks such as managing file systems, mounting, booting, and managing swap, see the System Administration Guide: Basic Administration.

Solaris Live Upgrade Process

The following is an overview of the tasks necessary to create a copy of the current boot environment, upgrade the copy, and switch the upgraded copy to become the active boot environment.

Creating a Boot Environment

The process of creating a boot environment provides a method of copying critical file systems from an active boot environment to a new boot environment. The disk is reorganized if necessary, file systems are customized, and the critical file systems are copied to the new boot environment.

File System Types

Solaris Live Upgrade distinguishes between two file system types: critical file systems and shareable file systems. Critical file systems are required by the Solaris operating environment. These file systems are separate mount points in the vfstab of the active and inactive boot environments. Examples are root (/), /usr, /var, or /opt. These file systems are always copied from the source to the inactive boot environment. Critical file systems are sometimes referred to as non-shareable. Shareable file systems are user-defined files such as /export that contain the same mount point in the vfstab in both the active and inactive boot environments. Therefore, updating shared files in the active boot environment also updates data in the inactive boot environment. When you create a new boot environment, shareable file systems are shared by default. But you can specify a destination slice and then the file systems are copied. For more detailed information about shareable file systems, see Guidelines for Selecting Slices for Shareable File Systems.

Swap is a special shareable file system. Like a shareable file system, all swap slices are shared by default. But, if you specify a destination directory for swap, the swap slice is copied. For procedures on reconfiguring swap, see the following:

Solaris Live Upgrade can create a boot environment with RAID-1 volumes (mirrors) on file systems. For an overview, see Creating a Boot Environment With Mirrored File Systems.

Copying File Systems

The process of creating a new boot environment begins by identifying an unused slice where a critical file system can be copied. If a slice is not available or a slice does not meet the minimum requirements, you need to format a new slice.

After the slice is defined, you can reconfigure the file systems on the new boot environment before the file systems are copied into the directories. You reconfigure file systems by splitting and merging them, which provides a simple way of editing the vfstab to connect and disconnect file system directories. You can merge file systems into their parent directories by specifying the same mount point. You can also split file systems from their parent directories by specifying different mount points.

After file systems are configured on the inactive boot environment, you begin the automatic copy. Critical file systems are copied to the designated directories. Shareable file systems are not copied, but are shared. The exception is that you can designate some shareable file systems to be copied. When the file systems are copied from the active to the inactive boot environment, the files are directed to the new directories. The active boot environment is not changed in any way.

The following figures illustrate various ways of creating new boot environments.

Figure 33-1 shows that critical file system root (/) has been copied to another slice on a disk to create a new boot environment. The active boot environment contains root (/) on one slice. The new boot environment is an exact duplicate with root (/) on a new slice. The file systems /swap and /export/home are shared by the active and inactive boot environments.

Figure 33-1 Creating an Inactive Boot Environment - Copying root (/) to root (/)

The context describes the illustration.

Figure 33-2 shows critical file systems that have been split and have been copied to slices on a disk to create a new boot environment. The active boot environment contains root (/) on one slice. On that slice, root (/) contains the /usr, /var, and /opt directories. In the new boot environment, root (/) is split and /usr and /opt are put on separate slices. The file systems /swap and /export/home are shared by both boot environments.

Figure 33-2 Creating an Inactive Boot Environment - Splitting File Systems

The context describes the illustration.

Figure 33-3 shows critical file systems that have been merged and have been copied to slices on a disk to create a new boot environment. The active boot environment contains root (/), /usr, /var, and /opt with each file system on their own slice. In the new boot environment, /usr and /opt are merged into root (/) on one slice. The file systems /swap and /export/home are shared by both boot environments.

Figure 33-3 Creating an Inactive Boot Environment - Merging File Systems

The context describes the illustration.

Creating a Boot Environment With Mirrored File Systems

Solaris Live Upgrade uses Solaris Volume Manager technology to create a boot environment that can contain mirrored file systems. Solaris Volume Manager provides a powerful way to reliably manage your disks and data by using volumes. Solaris Volume Manager enables concatenations, stripes, and other complex configurations. Solaris Live Upgrade enables a subset of these tasks, such as creating a RAID-1 volume for the root (/) file system.

A volume can group disk slices across several disks to transparently appear as a single disk to the operating environment. Solaris Live Upgrade is limited to creating a boot environment for the root (/) file system that contains single-slice concatenations inside a RAID-1 volume (mirror). This limitation is because the boot PROM is restricted to choosing one slice from which to boot.

When creating a boot environment, you can use Solaris Live Upgrade to manage the following tasks.

  • Detach a single-slice concatenation (submirror) from a RAID-1 volume (mirror). The contents can be preserved to become the content of the new boot environment if necessary. Because the contents are not copied, the new boot environment can be quickly created. After the submirror is detached from the original mirror, the submirror is no longer part of the mirror. Reads and writes on the submirror are no longer performed through the mirror.

  • Create a boot environment that contains a mirror.

  • Attach a maximum of three single-slice concatenations to the newly created mirror.

To use the mirroring capabilities of Solaris Live Upgrade, you must create a least one state database and at least three state database replicas. A state database stores information on disk about the state of your Solaris Volume Manager configuration. The state database is a collection of multiple, replicated database copies. Each copy is referred to as a state database replica. When you copy the state database, you protect against data loss from single points of failure. For procedures about creating a state database, see "State Database (Overview)" in Solaris Volume Manager Administration Guide.

You use the lucreate command with the -m option to create a mirror, detach submirrors, and attach submirrors for the new boot environment.

Table 33-1 Solaris Volume Manager Elements Used by Solaris Live Upgrade

Term

Description

state database

A state database stores information on disk about the state of your Solaris Volume Manager configuration. The state database is a collection of multiple, replicated database copies. Each copy is referred to as a state database replica. The state database tracks the location and status of all known state database replicas.

state database replica

A copy of a state database. The replica ensures that the data in the database is valid.

volume

A group of physical slices or other volumes that appear to the system as a single logical device. A volume is functionally identical to a physical disk in the view of an application or file system. In some command-line utilities, a volume is called a metadevice.

Table 33-2 shows the components that Solaris Live Upgrade can manage.

Table 33-2 Classes of Volumes

Term

Description

RAID-1 volume

A class of volume that replicates data by maintaining multiple copies. A RAID-1 volume is sometimes called a mirror. A RAID-1 volume is composed of one or more RAID-0 volumes that are called submirrors.

RAID-0 volume

A class of volume that can be a stripe or a concatenation. These components are also called submirrors. A stripe or concatenation is the basic building blocks for mirrors.

mirror

A RAID-1 volume. See RAID-1 volume.

concatenation

A RAID-0 volume. If slices are concatenated, the data is written to the first available slice until that slice is full. When that slice is full, the data is written to the next slice, serially. A concatenation provides no data redundancy unless it is contained in a mirror.

submirror

See RAID-0 volume.

Previous Previous     Contents     Index     Next Next
 

Updated: 2003-12-15, 21:26