| Sun StorageTek Availability Suite 4.0 Point-in-Time Copy Software Administration Guide |    
|
| Sun StorageTek Availability Suite 4.0 Point-in-Time Copy Software Administration Guide |
|
| C H A P T E R 2 |
|
Operation Considerations |
This chapter consists of the following main topics:
This section discusses the operation of the Point-in-Time Copy software from a system administrator's viewpoint. Typical tasks are described in detail, with examples. The examples use these volume names:
All commands are accessed on the following path:
Point-in-Time Copy software operations include, but are not limited to, these tasks:
Point-in-Time Copy makes use of the Service Management Facility (SMF) for the startup and shutdown of its software. SMF provides an infrastructure that augments the traditional Unix startup scripts, init run levels, and configuration files. The traditional run-level control script, which started and stopped Point-in-Time Copy software, has been replaced with an SMF service that is enabled during system startup and disabled at system shutdown.
When the Point-in-Time service is brought online during system startup, the volumes of previously configured shadow volume sets are resumed. During shutdown, the Point-in-Time service is brought offline, suspending the volumes of previously configured shadow volume sets.
Unlike the run-control scripts, which were started sequentially, many SMF services may start concurrently during system startup, resulting in decreased boot times. To ensure that the Point-in-Time Copy SMF service is started at the appropriate time in the boot process, its service description specifies formalized dependency relationships with other services.
The Availability Suite services under SMF control and the current state is shown below. See man dscfgadm for additional information.
In Solaris operating systems, a disk block is the smallest atomic unit of I/O. Disk blocks are 512 bytes. An I/O operation is atomic if it is guaranteed either to be fully complete (all of the data is confirmed to have been written) or to fail (none of the data is written because some part of the data was confirmed to be unwritable).
Most file systems, databases, and applications create or update an item on a disk in an I/O operation that involves more than a single disk block. For example, if you create a file, you need to populate the file, plus enter its existence in a directory. Or, if you create a record in a database, you need to write the record, plus update the index.
Because systems might experience hardware or software failure, and might crash or lose power, most file systems, volume managers, and databases support a facility or mechanism to repair inconsistencies detected at initial access time. Deterministic repair of the data in these situations is possible, but it might cause partial data to be rolled back or intentionally discarded.
If a point-in-time copy is established against a non-quiesced volume, the point-in-time copy could span non-atomic I/O operations. If this occurs, at initial access time, deterministic repair might be invoked, yielding unpredictable results.
Therefore, a point-in-time copy or update should not be performed against a source volume (master or shadow) without quiescing or stopping all application I/O and flushing any file system caches, such as lockfs(1M), associated with the volume. This quiesced or stopped state is required only for the duration of the copy or update operation, which typically takes milliseconds or seconds to complete. As always, the destination volume (master or shadow) must be in the unmounted or unaccessed state.
A notable exception to this rule is encountered in systems using a logging file system, or in Oracle®, that support hot backup. There is no reason to quiesce a volume set prior to a point-in-time copy if the database is in hot-backup mode. Refer to the specific application's documentation for detailed information, and see any applicable Sun documents available at: http://docs.sun.com.
Sun StorageTek Availability Suite 4.0 Point-in-Time Copy software provides an attractive complement to a hot-backup facility. Instead of putting the database in hot backup mode for the minutes or hours needed to perform disk or tape replication, the Point-in-Time Copy software requires this mode for only milliseconds or seconds.
When the Point-in-Time Copy software makes a copy or update, the source, which is usually the master volume, can be mounted and should be in the quiesced or in a stopped state. Instantly after the copy or update, the target, which is usually the unmounted shadow volume, contains on-disk metadata that states that the volume is currently mounted, but the shadow volume, by design, is not.
When a point-in-time copy is established in this way, when the target volume is first mounted, the software detects that a currently dismounted volume has mounted metadata. The software usually forces fsck to run under these conditions because the assumption is that the only time a volume contains mounted metadata, but is not currently mounted, is after a system crash. Point-in-Time Copy software breaks this assumption: fsck or the database recovery mechanism should return no errors, unless the master was not quiesced when the point-in-time copy was initiated (see Quiescing a Master Volume).
The target of a point-in-time copy operation, which is usually the shadow volume, must not be mounted. If the target is mounted, the application accessing the target volume will read inconsistent and changing data.
During an enable, copy, or update operation, a background process is started to synchronize the contents of the master and the shadow volumes. Dependent shadow volume sets do not require this background process (see Dependent Copy Operations). This background processing is driven by the bitmap and traverses from the start of the bitmap to the end, performing the I/O operations and bitmap processing to clear every set bit.
This background synchronization is done in a loop and is mediated by two types of variables: the units variables and the delay variables. Copy units are expressed in 32 Kbyte chunks (for example: 50 Mbyte = 1600); delay units are expressed in milliseconds. The loop performs the specified copy units worth of I/O, and then sleeps for copy delay milliseconds, until the synchronization is complete.
By adjusting the copy units and copy delay values, a system administrator can tune the impact that background synchronization imposes on the system. Once a shadow volume set has been enabled, the system administrator can tune individual or grouped shadow volume sets as desired.
An independent shadow volume that resides on a dual-ported storage array that is attached to two hosts can be utilized by both hosts using the export, import, and join facilities.
The export, import, and join facilities enable retention of point-in-time copy information across the entire process of moving the shadow volume from the original host to the partner host and back again. The independent shadow volume can be exported from the original host, imported by a second host, and later rejoined to its original shadow volume set with no loss of Point-in-Time continuity.
The export command removes an independent shadow volume from its shadow volume set, leaving the master volume and the bitmap volume in place to track changes to the master volume. Any attempt to process I/O to the shadow volume during this process will fail, since the volume is no longer an active member of its original shadow volume set.
The import command enables a new shadow volume set on the importing host. The new set includes the exported shadow volume as its shadow volume. A new bitmap volume is on the partner host. While enabled, any write operations from the partner host are tracked on the bitmap volume. After partner host processing is complete, the shadow volume set is disabled and the exported shadow volume with its new bitmap volume must be made available for the join command on the original host.
The join command reassociates the exported shadow volume with its original shadow volume set by using an OR operation to compare the contents of the bitmap volume from the partner host with the contents of the original bitmap. If no writes occurred to the shadow volume while it was on the secondary host, the bitmap contains only zeros, and this OR operation leaves the bitmap on the original host unchanged. The bitmap volume from the partner host is no longer needed after the join command is complete, and the volume can be reused.
If a write did occur on the partner host, the OR operation sets the bitmap for the associated block to 1 (or changed). Using the bitmap volume, you can now create a point-in-time copy using the update copy.
See Exporting, Importing, and Joining Shadows in a Standalone Environment and Exporting, Importing, and Joining Shadows in a Sun Cluster OE for details.
The Point-in-Time Copy software enables you to place shadow volume sets into I/O groups.
Groups are helpful in administering multiple volume sets in much the same way that a script would be. With an I/O group, a single CLI command can be executed on every member of the group.
I/O groups enable shadow volume sets to be controlled as a single unit for point-in-time copy or update operations. This facility is especially useful for making consistent point-in-time copies among a group of shadow volume sets. Group point-in-time copy or update operations are atomic, which means that an operation performed on a group is guaranteed to occur on every volume set in the group or to fail on all the volume sets if it fails on a single volume set.
You can specify I/O groups for the update, full volume copy, wait, list, display, abort, reset, disable, and export operations. I/O groups can be used to create consistent point-in-time copies among a group of master volumes (often required by DBMS that span multiple volumes).
TABLE 2-1 is a usage summary for options that support grouping (-g g). The legend for the usage summary is as follows:
v - shadow volume (reference name)
The Sun StorageTek Availability Suite 4.0 Point-in-Time Copy software, like all data services software, generates entries in the data services log file, /var/adm/ds.log.
This file serves as a running history of commands that have been executed and includes any related warnings or error messages. This file is maintained by default.
You can rename the logging file if you want to keep dated versions of it, or you can delete the file if it becomes too large. In either case, a new logging file is automatically created by the software.
A sample section of a logging file with Point-in-Time Copy software messages is shown here.
Following are some operational notes.
Keep the following cautionary items in mind when performing an enable, copy, or update operation:
Always specify the shadow volume name of the shadow volume group when using the copy or update commands.
Master, shadow, and bitmap volume names (absolute path names) are currently limited to a maximum of 64 characters, consisting of any legal characters that can be part of a file name.
You cannot make a shadow volume copy of the root device /.
The Point-in-Time Copy software does not support encapsulated volumes. You cannot create a shadow volume of an encapsulated volume.
Using the command option iiadm -e to enable a volume set automatically adds the volumes to the sv layer. Using the iiadm -d command option to disable a volume set automatically removes volumes from the sv layer.
There is no checking in the sv layer to prevent you from deleting volumes with svadm that are actively being used by the Point-in-Time Copy software or other data services. If you remove volumes from the sv layer that are still in use by Point-in-Time Copy software or Remote Mirror software, you will be able to continue operations on these volumes with no error messages, but the data in the volume set will become inconsistent.
The operations that access the configuration include, but are not limited to:
|
Caution - When creating shadow volume sets, do not create shadow or bitmap volumes using partitions that include cylinder 0. Data loss might occur. See VTOC Information. |
When configuring a volume set, do not use the same volume set as a point-in-time copy shadow volume and as a remote mirror secondary volume. If you attempt to configure a volume set for two purposes, the data contained on the volume might not be valid for the application that accesses the volume.
| Sun StorageTek Availability Suite 4.0 Point-in-Time Copy Software Administration Guide | 819-6149-10 |
|
Copyright © 2006, Sun Microsystems, Inc. All Rights Reserved.