| Sun StorageTek Availability Suite Troubleshooting Guide |    
|
| Sun StorageTek Availability Suite Troubleshooting Guide |
|
| C H A P T E R 3 |
|
Point-in-Time Copy Software |
This chapter discusses Point-in-Time Copy software troubleshooting issues.
The following topics are included:
This section describes some common errors that you may encounter when using Point-in-Time Copy software.
For information on how to safeguard the volume table of contents (VTOC), refer to Safeguarding the Solaris VTOC.
The most common class of user errors when using the Point-in-Time Copy software is accessibility issues in the specification of the Master, Shadow, Bitmap, and optional overflow volumes, which are configured using the iiadm utility. The best means to resolve these types of errors is to use standard Solaris utilities to resolve these issues; specifically, format(1M), prtvtoc(1M), and dd(1M).
A typical iiadm enable command using Solaris RAW devices is as follows:
A failure of this command may be due to incorrect device specifications, incorrect partition sizing, or a failure to access the devices from this Solaris node. Resolving issues with the following ten commands should be the first step towards resolving accessibility problems.
The next class of user errors when using the Point-in-Time Copy software is perceived functionality issues. The functionality of the Point-in-Time Copy software is to instantly copy all the data from the Master volume to the Shadow volume in a fraction of a second. Note the following two commands:
These commands are essentially equivalent for the initial configuration of a Point-in-Time Copy set, except that the second command can take hours or days to complete, instead of a fraction of second. In addition, neither the master nor the shadow volume can be used during the entire duration of the second command, while they both can be used in the first. Therefore if functionality issues are not what they seem, use the second command with very small volumes to assure the functionality that is desired works in the configuration needed.
After an enable, copy, or update command, the contents of the master volume are instantly available on the shadow volume. In all cases, there is no need to wait for a background copy to complete (iiadm -w <shadow-volume>) except when next using Export (iiadm -E) or disable (iiadm -d). What this means is that the "backup window" is no longer than the time it takes to quiesce the volume, take a Point-in-Time Copy, and resume the volume. At this point, the master volume can be used instantly as it was just before the Point-in-Time Copy was taken, and the shadow volume can be used instantly for whatever purpose it was created.
During an enable, copy, or update command, it is highly recommended that the master volume be quiesced and all cached data blocks flushed to disk so that a Point-in-Time Copy that is taken does not capture an I/O operation in progress. Capturing an I/O operation in progress may result in shadow volume data that appears inconsistent, meaning that utilities like fsck(1M), database recovery tools, or similar software may have to make indeterminate decisions about the validity of an incomplete I/O operation. The means by which the Point-in-Time Copy software instantly makes a copy of the master volume to the shadow volume provides the same I/O consistency issues as a Solaris node "panicking" while I/O is in progress.
This section discusses configuration issues.
For a brief status of Point-in-Time sets on the system, use iiadm -e dep:
For a detailed status, use iiadm -i:
This section discusses volume configuration.
The following command creates a Point-in-Time Copy set consisting of raw partitions, where the master is /dev/rdsk/c7t0d0s6, the shadow is /dev/rdsk/c7t1d0s6, and the bitmap is /dev/rdsk/c7t2d0s6.
Since this is an independent (ind) set, the shadow volume must be the same size or greater then the master volume. The bitmap volume must be sized according to the following command:
The following command creates a Point-in-Time Copy set consisting of Solaris Volume Manager volumes, where the master is /dev/md/rdsk/d1, the shadow is /dev/md/rdsk/d2, and the bitmap is /dev/md/rdsk/d3.
Since this is a dependent (dep) set, the shadow volume can be either the same size or greater than the master volume, or, if smaller, the set becomes a compact dependent shadow set.
The bitmap volume must be sized according to the following command, making sure to select the correct sizing for either "Full size dependent shadow" or "Compact dependent shadow".
The following command creates a Point-in-Time Copy set consisting of VxVM volumes, where the master is /dev/vx/rdsk/ii-dg/d21, the shadow is /dev/vx/rdsk/ii-dg/d22, and the bitmap is /dev/vx/rdsk/ii-dg/d23.
This section provides basic information on using Export/Import/Join within a Sun Cluster. For more detailed information, refer to the "Best Practice for using Export, Import, Join in a Sun Cluster OE 3.1" (10/3).
Make sure that the device groups are in a Sun Cluster SUNW.HAStoragePlus resource within a Sun Cluster resource group. See the best practice guide for detailed steps.
When using Export/Import Join within a Sun Cluster, the shadow volume must be on a different global device or volume manager controlled device group than its associated master and bitmap volumes. Doing so will allow the shadow volume's device group to be switched between various nodes in a Sun Cluster and to be used as an exportable shadow volume.
To create such a set, with the master and bitmap in one device group (oracle, in this example), and the shadow in another (backup, in this example), use the -ne flags to iiadm:
Make sure that the Point-in-Time Copy set is fully independent before exporting the shadow volume. This is confirmed by wait (iiadm -w) returning on the shadow volume:
If you would like to import the shadow on another Sun Cluster node, the second bitmap used for the import operation must be in the same global device or volume manager controlled device group as the exported shadow.
It is possible to perform an Export/Join sequence with no Import step. To perform a join operation, there is still the requirement for a secondary bitmap volume, but since this secondary bitmap volume was NOT used during a recent Import operation, it contains stale data or uninitialized data. Prior to performing a join operation, you must copy (using the Solaris dd utility) the current bitmap volume over the contents of the second bitmap volume, so that the second bitmap volume's data is in a known state. The failure to perform this manual initialization step may result in the join operation failing, or when state data is used, it may cause an inconsistency between what is actually on the shadow volume and the current state as recorded in the bitmap.
This section discusses server performance diagnosis issues.
If the Sun StorageTek Availability Suite software is used with a file system, tuning the number of SV threads might produce better performance.
When a file system flushes its cache, it generates many parallel write operations. The SV's default setting of 32 threads could produce a bottleneck. You can increase the number of SV threads. The maximum number of threads allowed is 1024.
The sv_threads value is in the /usr/kernel/drv/sv.conf file. Because the file is read when a module loads, changes to the sv_threads value do not take effect until you reboot the system.
The dsstat(1M) utility is useful for observing real-time read and write performance through volumes under Point-in-Time control. The dsstat tool is similar in usage to iostat, taking as arguments an interval length and iteration count.
The iostat(1M) utility may also be used to monitor Point-in-Time Copy performance. Besides being able to access performance data on the underlying storage volumes under Point-in-Time Copy control, Point-in-Time Copy sets also appear in iostat under the names iib[n], iim[n], and iis[n] for a bitmap, master, and shadow volume, respectively (where n is the set id).
The ptree(1) command shows the parent proc esses for a given process id. It is particularly useful for troubleshooting hung processes, or processes that were invoked through Sun Cluster scripts.
For example, if a ps command shows that the svboot process is running:
run ptree on the process id for svboot to see its parents:
The file /var/adm/ds.log contains a record of Availability Suite configuration and control activity, including which Point-in-Time Copy sets have had the following operations by the iiadm and iiboot utilities:
Below is a tabular summary of the SunSolve InfoDocs written to address common customer issues for Point-in-Time Copy software. If you believe you are experiencing one of these issues, contact your Sun Service Representative for a swift resolution.
| Sun StorageTek Availability Suite Troubleshooting Guide | 819-6151-10 |
|
Copyright © 2006, Sun Microsystems, Inc. All Rights Reserved.