JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Sun ZFS Storage 7x20 Appliance Customer Service Manual
search filter icon
search icon

Document Information

Preface

1.  Introduction

2.  Hardware Maintenance

3.  System Maintenance

System

Introduction

System Disks

Support Bundles

Managing Support Bundles Using the BUI

Managing Support Bundles Using the CLI

Initial Setup

Factory Reset

Updates

System Updates

Procedure

Preconditions

Deferred Updates

Hardware Firmware Updates

Reboot After an Update

Rollback

Fail-safe Rollback

Cluster Upgrade

Updating via the BUI

Unpacking and verifying media

Beginning an upgrade

Rolling back

Removing update media

Applying deferred updates

Updating via the CLI

Unpacking and verifying media

Beginning an upgrade

Rolling back

Removing update media

Applying Deferred updates

ConfigurationBackup

Configuration Backup

Backup Contents

Restore Impact

Security Considerations

Managing Configuration Backups Using the BUI

Create a Configuration Backup

Restore from a Saved Configuration

Delete a Saved Configuration

Export a Saved Configuration

Import a Saved Configuration

Managing Configuration Backups Using the CLI

Listing Configurations

Create a Configuration Backup

Restore from a Saved Configuration

Delete a Saved Configuration

Export a Saved Configuration

Import a Saved Configuration

Problems

Problems

Active problems display

Repairing problems

Related features

Logs

Introduction

Alerts

Faults

System

Audit

Phone Home

BUI

CLI

Listing logs

Viewing a log

Entry details

Glossary

Index

Updates

System Updates

The system update feature provides customers, developers, and field personnel with the ability to update a system's software after the system is installed.

Software updates are delivered as opaque binary downloads that contain some or all of:

In general, the update release notes describe what is in the update, and the update process automates all of the steps of activating the delivered components.

Procedure

The procedure for updating the system is as follows:

Preconditions

Best practices include verifying several preconditions prior to applying an update. Whenever possible, administrators should ensure that these preconditions are satisfied immediately prior to applying an update on the storage controller. In a clustered environment, these should be verified on both storage controllers before applying the update to either one.

Deferred Updates

Each update may come with new firmware or updates to external resources. In general, these updates are backwards-compatible and applied automatically without user intervention. There are exceptions, however, for non-reversible updates. These updates involve updating a resource external to the system software in a way that is incompatible with older software releases. Once the update is applied, rolling back to previous versions will result in undefined behavior. For these updates, you will always be given an explicit option of applying them automatically during upgrade or applying them after the fact. They are therefore referred to as "deferred updates".

When applying an update to a version with incompatible version changes, you will be given an option to apply these version changes as part of the upgrade. For each version change, the benefits of applying the change will be presented to you. The default is to not apply them, requiring you to return to the updates view and apply them once the system has rebooted after the upgrade is applied. This allows you to verify that the rest of the software is functional and a rollback is not required before applying the update.

If you elect to not apply deferred updates during an upgrade, you can return to the updates view at any point to apply the update. If deferred updates are available for the current software version, they will appear as a list below the current set of available updates, with an 'Apply' button to apply the updates. Deferred updates in a cluster take effect on both storage controllers simultaneously, and can only be applied while both controllers are operational. Because deferred updates are listed only for resources present on the local storage controller, in a cluster it may be the case that deferred updates are available only for resources active on the peer controller. In a cluster, it is therefore necessary to check both storage controllers to determine the availability of deferred updates.

Hardware Firmware Updates

Following the application of a software upgrade, any hardware for which the upgrade includes newer versions of firmware will be upgraded. There are several types of devices for which firmware upgrades may be made available; each has distinct characteristics.

Disks, storage enclosures, and certain internal SAS devices will be upgraded in the background. When this is occurring, the firmware upgrade progress will be displayed in the left panel of the Maintenance/System BUI view, or in the maintenance system updates CLI context. These firmware updates are almost always hardware related, though it may briefly show some number of outstanding updates when applying certain deferred updates to components other than hardware.

Applying hardware updates is always done in a completely safe manner. This means that the system may be in a state where hardware updates cannot be applied. This is particularly important in the context of clustered configurations. During takeover and failback operations, any in-progress firmware upgrade will be completed; pending firmware upgrades will be suspended until the takeover or failback has completed, at which time the restrictions described below will be reevaluated in the context of the new cluster state and, if possible, firmware upgrades will resume. Important: Unless absolutely necessary, takeover and failback operations should not be performed while firmware upgrades are in progress. The rolling upgrade procedure documented below meets all of these best practices and addresses the per-device-class restrictions described below. It should always be followed when performing upgrades in a clustered environment. In both clustered and standalone environments, these criteria will also be reevaluated upon any reboot or diagnostic system software restart, which may cause previously suspended or incomplete firmware upgrades to resume.

During the firmware upgrade process, hardware may appear to be removed and inserted, or offlined and onlined. While alerts attributed to these actions are suppressed, if you are viewing the Maintenance/Hardware screen or the Configuration/Storage screen, you may see the effects of these upgrades in the UI in the form of missing or offline devices. This is not a cause for concern; however, if a device remains offline or missing for an extended period of time (several minutes or more) even after refreshing the hardware view, this may be an indication of a problem with the device. Check the Maintenance/Problems view for any relevant faults that may have been identified. Additionally, in some cases, the controllers in the disk shelves may remain offline during firmware upgrade. If this occurs, no other controllers will be updated until this condition is fixed. If an enclosure is listed as only having a single path for an extended period of time, check the physical enclosure to determine ]whether the green link lights on the back of the SIM are active. If not, remove and re-insert the SIM to re-establish the connection. Verify that all enclosures are reachable by two paths.

Reboot After an Update

Following the completion of the update process, the system will reboot automatically. If you have the serial console open, you will notice during this reboot that multiple GRUB menu entries are available, ordered from the newest software (at the top) to the oldest software (at the bottom). The default menu entry will be the top -- the new software to which you just updated. If you do nothing this entry will boot by default, completing the update. The previous entries are rollback targets that can be used to initiate a rollback to previous versions of the system software. Rollback is discussed below.

    GNU GRUB  version 0.95  (613K lower / 3537536K upper memory)

 +-------------------------------------------------------------------------+
 | Sun Storage 7110 2010.02.09,1-0                                         |  
 | Sun Storage 7110 2009.09.01,1-18                                         |
 |                                                                         |
 +-------------------------------------------------------------------------+
      Use the ^ and v keys to select which entry is highlighted.
      Press enter to boot the selected OS, 'e' to edit the
      commands before booting, or 'c' for a command-line.

As the system boots up using the new system software, you will see some special messages on the first boot indicating that an update is completing and noting the previous and new versions of the system software:

SunOS Release 5.11 Version ak/generic@2010.02.09,1-0 64-bit
Copyright 1983-2010 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
System update in progress.
Updating from: ak/nas@2009.09.01,1-18
Updating to: ak/nas@2010.02.09,1-0

Updating system datasets ....... done.
Configuring network devices ... done.
Configuring devices.

Sun Storage 7110 Version ak/nas@2010.02.09,1-0
Copyright 2010 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.

Reading ZFS config: done.
Mounting ZFS filesystems: (27/27)

monk console login:
Rollback

The rollback procedure reverts all of the system software and all of the metadata settings of the system back to their state just prior to applying an update. This feature is implemented by taking a snapshot of various aspects of the system before the new update is applied, and rolling back this snapshot to implement the rollback. The implications of rollback are as follows:

If after applying an update, the system is back up and running, you can use either the BUI or the CLI to initiate a rollback to one of two previously applied updates. If the system is not able to run at all after an update, then use the fail-safe rollback procedure.

Fail-safe Rollback

Administrators can execute a fail-safe rollback of the system software from the serial console by selecting one of the other boot menu entries, if present. Although rollback can also be requested from the BUI or CLI, rollback is offered from the boot menu because it is possible that rollback will be needed in scenarios where the new system software has completely failed, i.e. has failed to even boot. To rollback from the console, access the serial console as usual, and during boot, before the ten second timeout, use the arrow key to move the menu selection down to one of the earlier entries:

    GNU GRUB  version 0.95  (613K lower / 3537536K upper memory)

 +-------------------------------------------------------------------------+
 | Sun Storage 7110 2010.02.09,1-0                                         |  
 | Sun Storage 7110 2009.09.01,1-18                                         |
 |                                                                         |
 +-------------------------------------------------------------------------+
      Use the ^ and v keys to select which entry is highlighted.
      Press enter to boot the selected OS, 'e' to edit the
      commands before booting, or 'c' for a command-line.

After the rollback boot menu entry is selected, the system will boot the old kernel software, but the rollback must be manually confirmed on the console in order to commit the rollback, which will effectively remove all changes to the system that have happened since, as described above. The confirmation step looks like this:

SunOS Release 5.11 Version ak/generic@2009.09.01,1-18 64-bit
Copyright 1983-2009 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
                            
System rollback in progress.
Rollback to: ak/nas@2009.09.01,1-18

Proceed with system rollback [y,n,?] 

Entering "y" proceeds with the rollback, and the system will complete boot using the prior snapshot. Entering "n" cancels the rollback and immediately reboots the system, allowing the administrator to select a different boot image (i.e. the current system software or an older snapshot).

Cluster Upgrade

In a clustered system, a rolling upgrade can be performed, eliminating downtime while the upgrade is performed. This section assumes familiarity with the Sun Storage clustering model: if you are not familiar with the clustering concepts and terminology, please read about clustering concepts in the System Administration Guide first. To describe the rolling upgrade procedure, this document will refer to the two clustered storage controllers as A and B, where A is the controller that will be updated first, and B is the controller that will be updated second. A key best practice in rolling upgrades is that each controller should be upgraded at a time when it is not providing service to clients. The procedure described here meets this requirement. In addition, all general upgrade best practices described above also apply to rolling upgrades.

Important: Do not perform a takeover operation while an upgrade is in progress.

  1. Using either the CLI or the BUI, upload the update software image to both storage controllers.

  2. If the cluster has a single storage pool, the controller to which that pool is assigned will be designated B; the one without a storage pool is designated A. If the cluster has two or more storage pools and each controller is assigned at least one of them, then decide at this time which controller will be designated A and which will be designated B. The choice is arbitrary, but A's storage pool(s) will be taken over first, so clients using those resource will experience a standard takeover-induced availability delay first.

  3. Log in to controller B, go to Configuration/Cluster or the CLI equivalent, and perform a takeover, which will cause controller A to reboot. The software will not prevent you from beginning the upgrade without taking over. However, if you do not perform the takeover, during the upgrade you will be unable to make any changes to the appliance's configuration even though that appliance will continue to provide service, and you will be performing an upgrade on a controller while it is providing service.

  4. Using the serial console, or the CLI or BUI if you have dedicated private network interfaces assigned, log in to controller A. Go to Maintenance/System or the CLI equivalent, select the software update, and apply it. At the end of the upgrade procedure, controller A will reboot again, this time running the new system software.

  5. Log into controller A and perform a takeover as above. This will cause controller B to reboot and controller A to take control of all resources and provide service to clients.

  6. Validate the behavior of the new software and ensure that firmware upgrades complete. Since controller A is now providing service using the new software while B remains on the previous version, this provides an opportunity to ensure that all services are working correctly as seen on client systems. If a serious problem is encountered, roll back the software on controller A, which will cause it to reboot; controller B (still running previous software) will take over, and when controller A recovers it will be running the previous version as well. Important: Allow all firmware upgrades to complete before proceeding to the next step.

  7. Log in to controller B. Go to Maintenance/System or the CLI equivalent, select the desired update, and apply it. At the end of the procedure, storage controller B will reboot again. Controller B will boot up and be running the new system software.

  8. The upgrade procedure is now complete. To restore normal operation, log in to storage controller A, go to Configuration/Cluster, and execute a failback operation, returning the resources to their respective assigned controllers.

The following table describes the state of the cluster at the end of each of the steps above, during an update from version V to version V+1.

Step
Controller A State
Controller A Version
Controller B State
Controller B Version
1,2
CLUSTERED
V
CLUSTERED
V
3
STRIPPED
V
OWNER
V
4
STRIPPED
V+1
OWNER
V
5,6
OWNER
V+1
STRIPPED
V
7
OWNER
V+1
STRIPPED
V+1
8
CLUSTERED
V+1
CLUSTERED
V+1

It is not advisable to make configuration changes to either storage controller while an upgrade is in progress. Most notably, while controllers are running different software versions, configuration changes made to one controller will not be propagated to its peer controller. For instance, suppose a change is made to controller A at step 4 above. That change will not be propagated to controller B until step 7, when both controllers are again running the same software version. Alternatively, if validation of controller A during step 6 uncovered a problem that necessitated controller A be rolled back to version V, then the changes made at step 4 would be also be undone as part of the rollback.



Accordingly, accessing the BUI or logging into the CLI while controllers are running different software versions will display a warning that configuration changes will not be propagated. Similarly, the appliance can be configured to generate alerts when a cluster is comprised of controllers running different software versions (events "Cluster rejoin mismatch" and "Cluster rejoin mismatch on peer").

Updating via the BUI

Click the Add item add icon next to Available Updates and specify the pathname on your desktop or local client of the update media. During the upload, a progress bar is displayed indicating the progress of the upload:

Upgrade: Add Software update

Note that on some older browsers, the progress bar may not be updated continuously during the upload; if you see a "watch" cursor just wait a minute -- in the worst case the upload will proceed all the way to completion and you may not see the progress bar.

Unpacking and verifying media

This step will happen automatically after the media is done uploading:

Upgrade: Unpacking update
Beginning an upgrade

After the update is uploaded, unpacked and verified, it will appear as an update:

Image

Click the Get info information icon to view the Release Notes for the software update.

To begin the upgrade, click on the Apply apply icon. As the upgrade progresses, you will see the most recent message in the status field of the update. To cancel the update at any time (and without ill effect), click on the Disable/Offline cancel icon.

Rolling back

To roll back, locate a previous image and click on the Rollback rollback icon. You will be asked to confirm that you wish to execute a rollback, and then the system will reboot and execute the rollback. Unlike fail-safe rollback, you will not be asked for further confirmation when the system reboots.

Removing update media

To remove update media, highlight the corresponding row and click on the Destroy trash icon.

Applying deferred updates

Any deferred updates will be displayed below the list of available updates. If no deferred updates are available, no list will be displayed. The deferred updates will describe what effects they will have on the system. Clicking the 'Apply' button will apply all available deferred updates. Deferred updates will apply to both nodes in a cluster, and the cluster peer must be up and available to apply any deferred updates.

Updating via the CLI

Because you log into the appliance to use the CLI, the upload as described above is actually a download. To download the media onto the appliance via the CLI, execute the download command in maintenance system updates:

dory:maintenance system updates> download
dory:maintenance system updates download (uncommitted)> get
                          url = (unset)
                         user = (unset)
                     password = (unset)

You must set the "url" property to be a valid URL for the download. This may be either local to your network or over the internet. The URL can be either HTTP (beginning with "http://") or FTP (beginning with "ftp://"). If user authentication is required, it may be a part of the URL (e.g. "ftp://myusername:mypasswd@myserver/export/foo"), or you may leave the username and password out of the URL and instead set the user and password properties.

dory:maintenance system updates download (uncommitted)> set url=
   ftp://foo/update.pkg.gz
                          url = ftp://foo/update.pkg.gz
dory:maintenance system updates download (uncommitted)> set user=bmc
                         user = bmc
dory:maintenance system updates download (uncommitted)> set password
Enter password: 
                     password = ********
dory:maintenance system updates download (uncommitted)> commit
Transferred 157M of 484M (32.3%) ...      
Unpacking and verifying media

After the file has been transferred, it will be automatically unpacked and verified:

dory:maintenance system updates download (uncommitted)> commit
Transferred 484M of 484M (100%) ... done 
Unpacking ... done
dory:maintenance system updates> list
UPDATE                           DATE                      STATUS
ak-nas@2009.10.14,1-0-nd         2009-10-14 08:45          AKUP_WAITING
...
Beginning an upgrade

To begin an upgrade, select the update that constitutes the upgrade. From this context, you can set any properties specific to the update, including applying deferred updates. For more information on the set of properties available for the particular update, run the help properties command. User-controllable properties will begin with the update_ prefix:

clownfish:maintenance system updates ak-nas@2009.04.03,1-0> help properties
Properties that are valid in this context:

   version              => Update media version

   date                 => Update release date

   status               => Update media status

   update_zfs_upgrade   => Apply incompatible storage pool update

clownfish:maintenance system updates ak-nas@2009.04.03,1-0> get
                       version = 2009.04.03,1-0
                          date = 2009-4-3 08:45:01
                        status = AKUP_WAITING
            update_zfs_upgrade = deferred
clownfish:maintenance system updates ak-nas@2009.04.03,1-0> set update_zfs_upgrade=onreboot
            update_zfs_upgrade = onreboot
clownfish:maintenance system updates ak-nas@2009.04.03,1-0> 

After you set any properties, execute the upgrade command. You are prompted for confirmation and (assuming an affirmative) the upgrade begins:

dory:maintenance system updates> select ak-nas@2009.10.14,1-0-nd 
dory:maintenance system updates ak-nas@2009.10.14,1-0-nd> upgrade
The selected software update requires a system reboot in order to take effect.
The system will automatically reboot at the end of the update process. The
update will take several minutes. At any time during this process, you can
cancel the update with [Control-C].

Are you sure? (Y/N) y
Updating from ... ak/nas@2009.10.11,1-0
Backing up smf(5) ... done.
Loading media metadata ... done.
Selecting alternate product ... SUNW,iwashi
Installing Sun Storage 7110 2009.10.14,1-0
pkg://sun.com/ak/SUNW,iwashi@2009.10.14,1-0:20091014T084500Z
Creating system/boot/ak-nas-2009.10.14_1-0 ... done.
Creating system/root/ak-nas-2009.10.14_1-0 ... done.
...

As the upgrade proceeds, the latest message will be printed. You can cancel the upgrade at any time by pressing ^C, at which point you will be prompted for confirmation:

Updating from ... ak/nas@2009.10.11,1-0
Backing up smf(5) ... done.
Loading media metadata ... ^C
This will cancel the current update. Are you sure? (Y/N) y
error: interrupted by user
dory:maintenance system updates ak-nas@2009.10.14,1-0-nd> 
Rolling back

To roll back to an earlier version, select the update that corresponds to that version and execute the rollback command. You will be asked to confirm that you wish to execute a rollback, and then the system will reboot and execute the rollback. Unlike fail-safe rollback, you will not be asked for further confirmation when the system reboots.

Removing update media

To remove update media, use the destroy command, specifying the update to be removed:

dory:maintenance system updates> destroy ak-nas@2009.10.14,1-0-nd
This will destroy the update "ak-nas@2009.10.14,1-0-nd". Are you sure? (Y/N) y 
dory:maintenance system updates>
Applying Deferred updates

To see if there are any available deferred updates, run the show command. If deferred updates are available, you can use the apply command:

clownfish:maintenance system updates> show
Updates:

UPDATE                           DATE                      STATUS
ak-nas@2009.11.20.2.1,1-1.9      2009-4-1 04:18:48         AKUP_PREVIOUS
ak-nas@2009.04.03,1-0            2009-4-3 08:45:01         AKUP_CURRENT

Deferred updates:

The following incompatible updates are available. Applying these updates will
enable new software features as described below, but will prevent older
versions of the software from accessing the underlying resources. You should
apply deferred updates once you have verified that the current software update
is functioning and a rollback is not required. Applying deferred updates in a
cluster will also update any resources on the cluster peer.

1. Support for the "passthrough-x" aclinherit property for shares.
clownfish:maintenance system updates> apply
Applying deferred updates will prevent rolling back to previous versions of
software.

Are you sure? (Y/N) 
clownfish:maintenance system updates> apply