| Sun StorageTek Availability Suite 4.0 Release Notes |     |
| Sun StorageTek Availability Suite 4.0 Release Notes | |
|
Sun StorageTek Availability Suite 4.0 Release Notes |
This document contains important information aboutthe Sun StorageTek
Availability Suite 4.0 software that was not available at the time the product documentation was published. Read this document so that you are aware of issues or requirements that can affect the installation and operation of the Sun StorageTek Availability Suite 4.0 software.
This release includes the following new and changed features, in addition to the noted material that addresses specific issues.
Availability Suite 4.0 is supported on the Sun Solaris 10 Operating System (OS) on SPARC® platforms, including both sun4u and sun4v. Additional support has been added for Solaris 10 OE on x64 AMD Opteron platforms, Intel EM64T platforms, and x86 platforms from various vendors. Functionality that is supported by the Sun StorageTek Availability Suite 4.0 software on SPARC platforms is also supported on both x64 and x86 platforms, with the exception of x86 and x64 interoperability of Remote Mirror in Availability Suite 3.2 and 3.2.1.
Availability Suite 4.0 now supports a 64-bit data path, allowing for the configuration of Remote Mirror and Point-in-Time Copy sets on volumes with a size of one terabyte or larger. Along with changes to support a 64-bit data path, there is also support for improved Solaris VTOC and Intel EFI Label processing.
Availability Suite 4.0 is now an SMF managed service facility, and once enabled, will be both started and stopped by Solaris at system boot time and shutdown time. Furthermore, a new Availability Suite 4.0 utility, dscfgadm, enables the starting up and shutting down of Remote Mirror and Point-in-Time Copy data services.
Availability Suite 4.0 supports the Solaris 10 least privileges model, which gives a specified process only a subset of the superuser powers and not full access to all privileges.
To improve performance across a wider array of supported volume configurations, Availability Suite 4.0 inquires about and uses the underlying maximum block transfer size across all volume managers and LUNs, consisting of IDE, SCSI, and SATA drives.
Due to the agnostic behavior of Availability Suite 4.0 regarding underlying LUNs and volume managers and upper-level file systems, databases, and applications, the configuration, control, and monitoring of Remote Mirror and Point-in-Time Copy sets is only allowed from a Solaris global zone.
For the Solaris 10 OS, Availability Suite 4.0 software packages can be added (pkgadd) and removed (pkgrm), without rebooting the Solaris OS. Both the installation and removal of the Availability Suite 4.0 product set can utilize an auto-answer file for pkgadd and pkgrm, because the prior interactive steps required to configure the persistent database have been moved to the post-installation utility, dscfgadm.
Availability Suite 4.0 includes a new utility that facilitates the creation of the persistent configuration database in the Solaris OS. As a means to decrease issues with the persistent configuration database, the database location is now fixed at /etc/dscfg_local. The utility also provides the means to start and stop the Remote Mirror and Point-in-Time Copy data services without starting or stopping the Solaris OS. The utility also provides validation of the persistent database and SMF service status.
Rolling upgrade support exists between Availability Suite 3.2 and 3.2.1 on Solaris 8 or Solaris 9 OS, to Solaris 10 OS.
Remote Mirror replication is supported between Availability Suite 3.1 and 3.2 (SPARC) and Availability Suite 4.0 (SPARC).
Remote Mirror replication is supported between Availability Suite 4.0 on SPARC, x86 and x64 platforms.
Availability Suite 4.0 has added support to associate a Solaris timestamp with each Point-in-Time Copy set, thereby offering an administrative means by which to query when the last snapshot was taken.
Rolling upgrade support exists between Availability Suite 3.2.1 on the Solaris 8 or Solaris 9 OS to the Solaris 10 OS, including support for Sun Cluster operating environment (OE) upgrades.
Availability Suite 4.0 can be installed either before or after Sun Cluster, with the only requirement being that dscfgadm be run once before configuring any Sun Cluster-controlled devices under Availability Suite 4.0.
In a Sun Cluster OE, not only does Availability Suite 4.0 have a persistence database located at /etc/dscfg_local, but also the Sun Cluster shared portion of the persistence database is located on a Sun Cluster administrator-specified DID device, accessed through the pointer file /etc/dscfg_cluster.
The ability to configure, control, and monitor Availability Suite 4.0 configuration information can now be done concurrently from any node within a Sun Cluster where Availability Suite 4.0 has been installed. This requires continuous access to the DID device on which the persistence database is located, from all nodes where Availability Suite 4.0 is installed.
The changes to the Availability Suite 4.0 persistence database (described earlier), along with changes in Sun Cluster 3.1, have allowed the supported number of Sun Cluster nodes to increase to the level started by Sun Cluster for failover data services.
The ability to support the Point-in-Time Copy functionality of Export/Import/Join has been extended to include a Sun Cluster OE. A Point-in-Time independent shadow volume is said to be an "exportable" shadow volume, due to its existence in a Sun Cluster device group that differs from that of the master and bitmap volume. Once exported, the device group of the shadow volume can be moved independently of the device group of the master and bitmap volume.
Prior restrictions when using Remote Mirror software in a Sun Cluster OE, regarding the naming and contents of a Sun Cluster resource group, have been removed. Although for Remote Mirror to failover correctly in a Sun Cluster OE there is a requirement that the resource group must contain one SUNW.HAStoragePlus resource type and one SUNW.LogicalHostname resource type, any number of and any other failover (HA) resource type can also be included in the resource group. With improvements in Sun Cluster 3.1, regarding "affinity," there is no longer a requirement to rename the Sun Cluster resource group to the name of the Sun Cluster device group, suffixed with the string -stor-rg.
This section describes the requirements for the Sun StorageTek Availability Suite 4.0 software.
The Sun StorageTek Availability Suite 4.0 software can be installed on a Sun server based on UltraSPARC® technology (sun4u or sun4v), on a server based on AMD Opteron x64 technology, on a server based on Intel EM64T technology, or on a server based on x86 technology from various vendors.
The Sun StorageTek Availability Suite 4.0 software runs in the following operating system environments:
|
To verify the operating system, repeat the following steps for each host on which you want to install the Sun StorageTek Availability Suite 4.0 software:
1. Verify that your system has a CD-ROM / DVD-ROM drive or that it can access the release package at the Sun Download Center.
The Sun Download Center is at the following URL:
http://www.sun.com/software/downloads
2. Log in to your system as root.
You must have superuser access to install the software.
3. Verify your system's Solaris OS level.
The software relies on properly configured Solaris software at the following release level:
This section describes known issues when using the Sun StorageTek Availability Suite 4.0 software.
Issue - The Availability Suite 4.0 software returns the following error message in several situations when the shadow volume of a Point-in-Time Copy volume set is not the same size as the master volume.
Another package would not allow target to be changed at this moment
Whenever a Point-in-Time Copy snapshot is taken, the volume that is used to create the snapshot, the shadow volume, is made to look exactly like the master volume, including matching the number of blocks. If the master volume is larger or smaller than the shadow volume's physical size, the shadow volume appears to be resized at the moment the snapshot is taken. Physically, the shadow volume has not changed size, but the Point-in-Time Copy kernel module always reports its size to be the same size as the master volume. This can present several problems for the Remote Mirror software, which does not expect the size of the volume to change:
Issue - Due to the read-modify-write behavior of Point-in-Time Copy bitmap volumes, placing many of them on a single RAID-5 volume introduces high I/O contention involving the disks associated with the RAID-5 volume. This I/O contention is noticeable at volume unmounting time, as seen when an application suite or system is being shutdown.
Workaround - Place bitmap volumes on RAID-1 sets, multiple RAID-5 sets, or on a cached-array disk controller.
Bug 6326350 - During a reboot, or sometimes a shutdown of the Solaris OS, the Availability Suite 4.0 daemon process nskernd reports that there are some number of kernel threads in use. For example:
nskernd: unable to shutdown: 128 kernel threads in use
Workaround - None. This is only a warning message, in that the nskernd daemon process detects that kernel threads previously allocated have not been deallocated. Because the Solaris OS is about to shut down, reboot, or halt, the failure to delete these threads is not an issue.
Bug 6383124 - Point-in-Time Copy and Remote Mirror software are based on fixed volume size values obtained at enable time (iiadm -e ..., or sndradm -e ...), and record in the associated bitmap volume.
Workaround - None. When growing a volume using format(1m), SVM or VxVM, there is no supportable means by which to grow the master or primary volume, except to disable and then reenable the Point-in-Time Copy or Remote Mirror set with a newly sized bitmap volume.
For Remote Mirror, there is the ability to eliminate the full volume synchronization required at enable time by using sndradm -E ... to perform a fast-enable with bitmap clear.
Care must be taken to only grow the actual Remote Mirror primary and secondary volume, plus associated bitmap volumes, while the Remote Mirror set is disabled, and to defer the growing of the file system, database, or application data until after Remote Mirror is enabled on both hosts. This will allow the grow file system, grow database, or grow application data changes to be replicated to the Remote Mirror secondary volume.
Bug 6400884 - When changing the value max_sets in the file /usr/kernel/drv/rdc.conf, the change might not take effect just by disabling (dscfgadm -d) and reenabling (dscfgadm -e) the Availability Suite 4.0 data services.
Workaround - Ensure that when any driver configuration file (see the following list) changes occur, not only are the Availability Suite data services disabled and associated modules unloaded, but also that the Solaris kernel cache of driver properties is flushed prior to the data services being reenabled (and loaded). It is only during the first load of a device driver by the Solaris OS, that the configuration parameters are read.
Device properties are flushed by the Solaris update_drv(1M) command.
The correct sequence to change a driver configuration parameter is as follows:
System Administrators must be cautious when performing this sequence, as the sequence of commands disables all Availability Suite 4.0 volume processing (replication and snapshot), such that if any file system, database, or application I/O was issued to any Availability Suite 4.0 configured volume, data will not be replicated to the secondary or shadow volume, resulting in inconsistent volume data, a form of data corruption. Quiescing the volumes (dismount, stopping applications, lockfs -f, and so on), are application-specific steps that must be performed.
Although Availability Suite 4.0 no longer requires a reboot of the Solaris OS, performing a reboot and transitioning to single user mode is a guaranteed way to eliminate all concerns regarding Availability Suite 4.0 volume consistency.
The driver names and associated configuration files for the Availability Suite 4.0 data services are as follows:
nskern - /usr/kernel/drv/nskern.conf
nsctl - /usr/kernel/drv/nsctl.conf
ncall - /usr/kernel/drv/ncall.conf
sdbc - /usr/kernel/drv/sdbc.conf
sv - /usr/kernel/drv/sv.conf
ii - /usr/kernel/drv/ii.conf
rdc - /usr/kernel/drv/rdc.conf
Bug 6418503 - Point-in-Time Copy I/O consistency groups with two or more Sun Cluster device groups fail to work correctly, reporting the following error:
iiadm: Point-in-Time Copy volumes, that are not in a device group which has been registered with SunCluster, require usage of "-C": Error 0
Workaround - In a Sun Cluster OE, Point-in-Time volumes are either in a local device group -C local, or a Sun Cluster device group (global device, SVM metaset, VxVM disk group).
When using I/O consistency groups (iiadm -g <group_name>, ...), place only a single device group (local or Sun Cluster) within each I/O consistency group.
Bugs 6425408 and 6425409 - Although support for s = sync, p = purge, and r = redevid was removed from prior versions of Availability Suite, the usage statement (scmadm -h) and man pages (man scmadm), still list these as viable options.
Workaround - None. Although listed, these scmadm options no longer function as documented.
Bug 6426349 - When using the Remote Mirror software under certain conditions when auto-synchronization has been enabled, autosync fails to automatically start (even after waiting two hours) when the Remote Mirror secondary node becomes available.
Solution - Patches to fix this problem are available as follows:
Install the Sun StorageTek Availability Suite 4.0 software on the Solaris host machines.
You can install all Sun StorEdge software or just individual packages (for example, Point-In-Time Copy or Remote Mirror). Each option also installs the core software, which is required for all products. The install.sh installation script on the product CD checks to see if the core software is already installed. If it is not, it is installed.
The install.sh installation script has the following syntax:
-j - Installs the packages where the root installation path is a path other than the standard root slice (/). Use this option when the root is located on a remotely-mounted device and you want to install the packages on a remotely-mounted device.
-a - Installs the core, Remote Mirror, and Point-in-Time Copy software.
-p - Installs the core and Point-in-Time Copy software.
-r - Installs the core and Remote Mirror software.
This section lists all documents in the documentation set, as well as any online information (help, man pages) included in the release.
|
The product documentation is located on the product CD in Adobe® Acrobat (PDF) format.
2. Insert the product CD into the CD-ROM drive that is connected to your system.
3. If the Volume Manager daemon vold(1M) is not started, type one of the following sequences:
a. If the package installation path is the normal root slice (/):
b. If the package installation root path is located on a remotely-mounted device or when older packages might be located on a remote-mounted device:
4. If you typed ./install.sh -j, the script prompts you as follows. Otherwise, skip to Step 5.
Perform one of the following steps:
a. Press <Return> to accept the default root path (/).
b. Type the full path where the root slice is mounted.
5. Change to the Docs directory.
From this location, you can view the documentation using the free Adobe Acrobat Reader software. The software is available from Adobe Systems at:
If you need help installing or using this product, call 1-800-USA-4SUN, or go to:
http://www.sun.com/service/contacting/index.html
| Sun StorageTek Availability Suite 4.0 Release Notes | 819-6152-10 | |
Copyright © 2006, Sun Microsystems, Inc. All Rights Reserved.
To Verify the Operating System