Home > Articles > Networking > Storage

Managing Data Centers With Sun Management Center Change Manager

  • Print
  • + Share This
Deploying and updating software are two of the most challenging and time consuming tasks facing datacenter managers. The Sun Management Center Change Manager software provides a framework and tools for quickly and efficiently deploying, replicating, updating, and managing software over a large number of systems. This article presents techniques and best practices for using Sun Management Center Change Manager software.
Like this article? We recommend

Deploying and updating software are two of the most challenging and time consuming tasks facing data center managers. The Sun™ Management Center (SunMC) Change Manager provides a framework and tools for data center personnel to quickly and efficiently deploy, replicate, update, and manage software over a large number of systems.

This paper presents techniques and best practices for using SunMC Change Manager. The software utilizes Solaris™ Flash archives and Solaris™ Live Upgrade (LU) technology to manage software stacks. This paper details the following topics:

  • Overview of Solaris Flash archives and LU technology

  • Creation of software stacks

  • Uses of the SunMC Change Manager deployment engine

  • Provisioning and reprovisioning of systems

  • Installation and management of software patches

Overview of Solaris Flash Archives and Live Upgrade Technology

LU 2.0 software and later versions allow you to use a Solaris Flash archive to install an alternate boot environment (ABE). The following sections provide a high-level overview of the Solaris Flash technology and detail the LU flash installation procedures.

Overview of Solaris Flash Technology

Solaris Flash technology provides a mechanism by which you can archive a specific or reference installation of the Solaris™ Operating Environment (Solaris OE). You can then use that archive to install the Solaris OE. The reference installation is created from the on-disk Solaris OE, which includes all installed software. This system is designated as the master machine. The reference installation can be a Solaris OE installed by any means, for example, with JumpStart™ software, from CD, or by an interactive installation.

After you identify the master machine, capture the reference installation in a Solaris Flash archive. A central feature of Solaris Flash software, this archive is essentially a point-in-time snapshot of the Solaris OE, software patches, and applications on the master machine. To create an archive, execute the flarcreate(1m) command on the master machine.

Solaris Flash extensions enable you to install an archive from a Network File System (NFS) server, a Hypertext Transfer Protocol (HTTP) server, or a traditional JumpStart server. Additionally, you can access the archive from a disk device (including CD-ROM) or from tape device that is local to the installation client. When you install an archive, it is transmitted over the network to the installation client and is written to the disk. After the archive is written to the installation client's disk, any necessary archive modifications are performed. For example, configuration files on the installation client, such as the /etc/nsswitch.conf file, might need to vary from the file on the master machine. The Solaris Flash mechanism enables you to automate modifications and allows for differences in kernel architecture or device differences between the master machine and the installation client.

Additionally, Solaris Flash software enables the automatic resolution of partitioning differences between the master machine and the installation client. For example, if an archive was created on a system with a single root (/) partition, and the installation client has separate / and /var partitions, the archive automatically customizes itself to the installation client. Remember, the installation client partitioning must be correctly specified in the JumpStart software profile.

A flash archive is a snapshot of a system and, as such, includes all specified files on a system. If an archive is created from a system that is in use, you will need to clean up or zero out some files after the flash archive is installed. Examples of these types of files include log files, such as those found in /var/adm, and any files in the /var/tmp directory.

Modify the finish script to zero out log files after installation of the Solaris Flash archive. To exclude temporary directories, such as the /var/tmp directory, exclude the directory when you create the flash archive. See "Inducing System Amnesia" on page 8 for additional details.

Create the flash archive after installing all software, but before placing the system into production. Depending on the software installed and the intended use for the system, you might need to create the flash archive after installing the software, but before configuring it. For example, you should create archives for database servers or Lightweight Directory Access Protocol (LDAP) servers after installing the database management software, but before creating and populating the databases.

Installing the Solaris OE with a flash archive can be dramatically faster than with other mechanisms, depending on network traffic and disk speeds.

You can find further details on the use of Solaris Flash software in the Solaris 9 OE Advanced Installation Guide and the Sun BluePrints™ book, JumpStart Technology: Effective Use in the Solaris Operating Environment by John S. Howard and Alex Noordergraaf (ISBN 0-13-062154-4).

Overview of Live Upgrade Software

LU 2.0 software was introduced with the Solaris 8 10/01 OE (Update 6). On the Solaris 8 10/01 OE media, LU 2.0 packages are located in the Easy Access (EA) directory of the Solaris media CD marked "Software 2 of 2." With the Solaris 8 01/02 OE (Update 7), LU 2.0 software was moved from the EA area to the product area, and is bundled with the OE packages.

LU 2.0 software was also released as a web release (08/01) that is available at http://www.sun.com/solaris/liveupgrade. LU 2.0 software works with, and can be installed on, all releases of the Solaris OE versions 2.6, 7, 8, and 9. LU 2.0 software is the first general-availability release of the software. It is recommended over the use of LU 1.0 software, which must never be used in a production environment or on a production server.

Creating and Managing Boot Environments

The concept of a boot environment (BE) is central to the operation and implementation of LU software. A BE is a group of file systems and their associated mount points. LU software uses the term "boot environment" instead of "boot disk" because a BE can be contained on one disk, or can be spread over several disks. LU provides a command-line interface and a character-based user interface (CUI) to create, populate, manipulate, and activate BEs.

NOTE

The CUI has a few restrictions: it is neither localized, nor internationalized. Also, the existing CUI does not provide access to the full functionality of the LU software.

You can create BEs on separate disks, or you can create them on the same disk; however, a single root (/) file system is recommended for the Solaris OE.

The active BE is the one that is currently booted and active; all other defined BEs are considered inactive. Inactive BEs, are referred to as ABEs (alternate BEs).

BEs can be completely self-contained, or they can share file systems. Only file systems that do not contain any OE-specific data and that must be available in any OE should be shared among BEs. For example, users' home directories on the /export/home file system are good candidates to share among several BEs.

If you used multiple file systems for the Solaris OE, such as separate file systems for /kernel, /usr, /etc, /, and so forth, do not share OE-specific file systems among BEs. In addition, do not split certain file systems (such as /kernel, /etc, /dev, or /devices) from /. If you split them onto a separate file system from /, the BE that is created might not be bootable.

Additionally, LU provides a mechanism to synchronize individual files among several BEs. This feature is especially useful for maintaining files such as /etc/passwd in one BE and then propagating changes to all BEs.

To back up BEs created with LU, use the ufsdump or fssnap commands. Consult the man pages for information about the uses of these commands.

Upgrading Systems

To appreciate the value of using LU software to upgrade a system, consider the common situation of having to upgrade a production server from the Solaris 8 OE to the Solaris 9 OE. Most likely, you could not take the server down to do the upgrade. Additionally, site change control procedures likely require that you provide a back-out plan to restore the initial Solaris 8 OE in the case of any unforeseen upgrade failures or software incompatibilities. Using LU, you can complete this upgrade while the Solaris 8 OE is up and live. The LU framework also provides for the retention of the Solaris 8 OE as a fallback in case of a failure during the upgrade procedure.

To Upgrade a System Using LU Software

  1. Create and populate a new BE by cloning the current OE.

  2. Upgrade the new BE.

  3. Install (or upgrade) unbundled software, patching as necessary, in the new BE.

  4. When you are ready to cut over to the new version of the OE, activate the new BE and reboot into the new BE.

Rather than using slice 7 of the boot disk for the /export file system, use this slice for the clone OE or as an ABE.

Installing Flash Archives With LU 2.0 and Solaris Flash Software

When using Solaris Flash with LU 2.0 software, the specified ABE is not upgraded; instead the contents of the flash archive are extracted and installed in the specified ABE.

To Install a Flash Archive Using LU and Solaris Flash Software

  1. Create and populate a new BE by cloning the current OE.

  2. Upgrade the new BE to Solaris 8 OE 10/01 using a flash archive.

  3. Activate the new BE.

  • + Share This
  • 🔖 Save To Your Account