| 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 1 |
|
Introduction to the Point-in-Time Copy Software |
This chapter describes the Sun StorageTek Availability Suite 4.0 Point-in-Time Copy software in functional detail. First, the uses for the software are described, and then the software's architecture is explained. The chapter continues to discuss the allowable volume set configurations in detail, followed by a full explanation of how these volume set configurations are tracked and controlled using bitmap volumes. Finally, additional features of the Point-in-Time Copy software are presented.
This chapter is divided into the following main topics:
The Point-in-Time Copy software, running in the Solaris OS, provides applications with continuous access to volume data and offers secondary applications un-intrusive access to a point-in-time copy of the same volume data. The Point-in-Time Copy software supports both full copy and fast resynchronization to reestablish a new point-in-time shadow copy as needed. The volume's data can be resynchronized from master to shadow or from shadow to master.
The Point-in-Time Copy software supports all Sun-supported storage. It works independently of the underlying data reliability software (for example, RAID-1, RAID-5, or volume manager). Additionally, it can be an integral part of the data migration to and from differing storage types.
Typical Point-in-Time Copy software uses include:
The Sun StorageTek Availability Suite software is cluster aware in the Sun
Cluster 3.1/3.2 environments, and provides high availability (HA).
|
Caution - Do not install the Sun StorageTek Availability Suite software on servers in a Sun Cluster 3.0 environment. |
Sun StorageTek Availability Suite 4.0 Point-in-Time Copy software is a point-in-time snapshot facility that runs on the Solaris OS. A point-in-time snapshot, also called a point-in-time copy, is an instantly available, time-fixed, replicated view of a momentarily quiesced volume. Instantly after a point-in-time copy is created, you have immediate read and write access to both the original master and shadow copy volumes.
Point-in-Time Copy sets consist of a master volume, a shadow volume, a bitmap volume, and an optional overflow volume. A Point-in-Time Copy set can be enabled in several configurations, which are discussed in this chapter.
The Point-in-Time Copy software tracks the differences between the master and shadow volumes caused by write operations from the time when the set is enabled. This capability allows the data on the two volumes to move forward in time independently of each other. Applications can access both volumes and modify the data on them independently.
Because the software tracks differences between the volumes, the volumes can be quickly updated after the first Point-in-Time copy is enabled. A fast resynchronization can occur either from the shadow volume to the master volume or from the master volume to the shadow volume.
Instantly after the point-in-time copy is enabled, copied, or updated on the shadow volume set, the applications using the shadow volume set can immediately resume processing. The point-in-time copy is established or re-established when the command-line interface (CLI) prompt returns or when the next shell script command is read.
Sun StorageTek data services are implemented as layered pseudo-drivers in the Solaris kernel I/O stack. These drivers rely on the nsctl (Network StorageTek Control) framework to support this layering and provide runtime control. Point-in-Time Copy software is implemented as an nsctl I/O filter module, which enables integration with other Sun StorageTek data services (specifically Remote Mirror Copy software). The architecture of the Point-in-Time Copy software in the kernel I/O stack is shown in FIGURE 1-1.
The Point-in-Time Copy software works by being in the Solaris I/O data path. I/O commands and data enter and exit the Point-in-Time Copy software through the Sun StorageTek storage volume (sv) software. Mediated by nsctl, the data optionally flows through the Remote Mirror software and the Point-in-Time Copy software to the storage device block cache (sdbc) drivers and then to its destination either on the storage device (for write operations) or in application or kernel memory (for read operations).
The Point-in-Time Copy software is a Solaris kernel pseudo-device driver. It resides in the nsctl framework above the volume manager or the storage device driver, and below the file system. This architecture makes the Point-in-Time Copy software independent of a volume manager or file system using the volume manager.
The Point-in-Time Copy software enables flexibility in how you configure your volumes locally. The volumes can be protected by any redundant array of independent disks (RAID) level desired. The protection level of the volumes in a shadow volume set does not have to match.
Data flows to the Point-in-Time Copy software driver from user layer applications that access the shadow volume set via the sv layer. Sometimes user layer applications reside above the file system. Other times these applications run in Data Base Management Systems (DBMS), which can read and write directly to raw disk partitions or volumes created with the volume manager. In any case, I/O commands process the data and move it to its destination on the storage device.
The I/O commands targeted to shadow volume sets are intercepted by the sv driver and routed through the Sun StorageTek I/O stack prior to being passed on to the storage device driver or the volume manager. The sv layer is a very thin layer in the Solaris I/O stack and operates by interposing itself onto the DDI entry points to the underlying device driver. I/O commands originating in user space are intercepted at the top of the Sun StorageTek service I/O stack. The sv layer routes them through the Sun StorageTek data services stack and feeds them back to the storage device driver or the volume manager, at the bottom of the stack. Data also flows in the opposite direction, from the storage device back to user space.
The master volume of a shadow volume set is the volume from which you intend to create a point-in-time copy. The master volume is the source of the data that is copied when a shadow volume set is initially enabled. The shadow volume is the volume on which a point-in-time copy is created. At any given time, a master volume can have more than one shadow volume, but a shadow volume can have only one master.
The use of the terms master volume and shadow volume does not dictate the direction of a subsequent point-in-time copy or update. Which volume is configured as the master volume and which volume is configured as the shadow volume is a choice that depends on how a point-in-time copy is being used.
Shadow volumes can be independent, dependent, or compact dependent. An independent shadow volume can be utilized separately from its corresponding master. A complete duplicate of the master volume is started on the independent shadow volume when the point-in-time copy is initiated.
When a shadow volume set is enabled with an independent shadow volume, it automatically starts to synchronize the master and shadow volumes in the shadow volume set. Simply put, the synchronization of an independent shadow volume with its master volume refers to the background process of copying all of the Point-in-Time Copy data on the master volume to the shadow volume. In a shadow volume set configured with an independent shadow volume, the shadow volume is treated as a dependent shadow volume until full synchronization has been completed.
Dependent and compact dependent shadow volumes cannot be utilized separately from their corresponding master volumes. Both types of dependent shadow volume access their master volume to return the contents of the volume in those areas that have not been written since the point-in-time copy was established.
Additional details of how independent and dependent shadow volume sets behave is detailed in Independent Copy Operations and Dependent Copy Operations. For details about compact dependent shadow volumes, see Compact Dependent Shadow Volumes.
|
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. |
Shadow volume sets can be configured with independent shadow volumes when any of the following apply:
In other words, access performance on either the master volume or the shadow volume is a priority. Independent shadow volume sets divide the accesses between the volumes, and accesses to the shadow incur no I/O on the master.
When a shadow volume set is enabled with an independent shadow volume, a full volume copy (or simply, full copy) is started, and proceeds along two distinct routes:
If no writes are sent to the master volume during this synchronization, the process continues to completion as a simple copy.
Writes to a block on the master volume trigger a write of the existing data in the block to the shadow volume. Then the new data is written to the master. This preserves the validity of the point-in-time copy on the shadow volume.
Upon completion of the full copy, the shadow volume is treated as an independent shadow volume.
At the beginning of the full copy, all the bits in the bitmap for the master volume are set. When a bit in the bitmap is set, indicating that the block has not been synchronized, the block is said to be changed. During synchronization, as data is moved from the master volume to the shadow volume, the bits in the bitmap corresponding to the blocks updated are cleared, and the blocks are said to be unchanged.
When a write destined for a master volume block that has not been copied to the shadow volume comes through the I/O stack, the block that is the target of the incoming write is processed along with the ongoing synchronization in the following fashion:
1. The data at the block that is the target of the write is copied to the shadow volume.
2. The block on the master volume is updated with the new data.
3. The corresponding bit in the bitmap is cleared.
Since the Point-in-Time Copy software checks each bit to see if the block is changed prior to copying it, the software skips over this block. In this way an independent copy is established on the shadow volume.
Once the background copy is completed, the shadow volume is fully independent, and it is possible to perform update or fast synchronization point-in-time copies. An update point-in-time copy is created after a full copy has been completed on a shadow volume set by copying only those blocks that have been modified since the full copy. Update copies are described in Resynchronizing the Shadow and Master Volumes.
Independent shadow volumes can be accessed in a variety of ways once established:
No matter which approach is taken, I/O on an independent shadow volume is performed directly on the shadow volume, unlike I/O on a dependent shadow volume.
If the shadow volume set is disabled, the master and the shadow volumes no longer bear any relationship to each other, and will diverge over time.
If one of the first two approaches is taken, bitmap management continues, which allows:
Joins are explained in Export, Import, and Join of Dual-Ported or SAN-Accessible Shadow Volumes. Update point-in-time copies are explained in Resynchronizing the Shadow and Master Volumes.
If an independent shadow volume is accessed by another host with the export and import commands, a secondary bitmap volume is maintained on the accessing host to track which of the blocks in the shadow are modified by the host. Changes to the master volume are still tracked in the bitmap of the originating host.
If an independent shadow volume is not disabled after a full synchronization and remains under Point-in-Time Copy software control, changes to either the master or the shadow volume are tracked in the bitmap of the shadow volume set. Since a single bitmap is used to track which blocks differ between the two volumes, no information about where the modification originated is available.
The term resynchronization is used to describe a synchronization that occurs between volumes in a shadow volume set that were previously synchronized.
Synchronizations can be full synchronizations or update synchronizations. Full synchronization of an independent shadow volume is described in Creating an Independent Shadow Volume.
An update synchronization is a synchronization that copies only those blocks marked as changed in the bitmap to the target of the update. The target can be the master volume or the shadow volume, depending upon the direction of the synchronization.
Shadow volume sets can be configured with dependent shadow volumes when any of the following apply:
When a shadow volume set is enabled with a dependent shadow volume, the bitmap volume begins tracking changes made on the master volume. Enabling a shadow volume set with a dependent shadow volume does not initiate a background synchronization process. All data that has remained unmodified on the master volume since the point-in-time copy was created is accessed on the master volume itself.
1. Data is only written to the shadow volume when writes to the master volume commence, which is after the point-in-time copy has been established.
2. When a write destined for the master volume is processed by the Point-in-Time Copy software, the block on the master volume is first copied to the shadow volume.
3. Then, the new block data is written to the master volume, and the associated bit in the bitmap volume is marked as changed.
Dependent shadow volumes are available for access immediately because the synchronization process inherent in the creation of an independent shadow volume does not apply.
|
Note - A dependent shadow volume cannot be accessed if the master volume and bitmap volume are not available. |
Dependent shadow volumes can be mounted and can be the target of I/O. The shadow volume set of the dependent shadow volume must remain under Point-in-Time Copy software control and the master volume must be available. Dependent shadow volumes are virtual volumes, formed by the union of the unmodified data on the physical master volume and the modified data on the physical shadow volume.
When data is read from a dependent shadow volume, the Point-in-Time Copy software checks the bitmap to determine if the data has been modified. If it hasn't, data from the block that is the target of the read is read from the master volume and returned to the caller. If the data has been modified, data from the block that is the target of the read is read from the physical shadow volume and returned.
When data is written to a dependent shadow volume, the Point-in-Time Copy software updates the corresponding bit in the bitmap to indicate that the target block is changed, and the data is written to the physical shadow volume. It is the responsibility of the accessing client that this is the intended effect. The dependent shadow volume is now no longer an accurate reflection of the master volume at the time the point-in-time copy was established.
Resynchronization of a dependent shadow volume with its master volume is immediate. Resynchronization involves only the bitmap volume. All the bits in the bitmap volume are cleared, or marked as unchanged.
Resynchronization of a master volume with its dependent shadow volume is an update synchronization. In an update synchronization, only the blocks marked as changed (with a bitmap value of 1) are copied to the target of the copy. In the case of a dependent shadow volume, this includes any blocks modified on either the master volume or the shadow volume since the last point-in-time copy was established.
The Point-in-Time Copy software supports the creation of compact dependent shadow volumes, which are dependent shadow volumes that are smaller than their corresponding master volume. The term compact is intended to convey that less storage is allocated, not that the data in the blocks is compacted or compressed in any way.
Compact volumes are useful when all the following statements are true:
Often, applications in user space do not modify the contents of the entire master volume between planned point-in-time copies. For many applications, entire areas of storage are modified rarely relative to their neighbors.
For example, if you know that at most 10 percent of the blocks on the master volume are changed between point-in-time copies, you can allocate a compact dependent shadow volume at 10 percent of the size of the master volume.
1. The Point-in-Time Copy software keeps track of the updated data blocks using an index in the bitmap.
2. Blocks written to the master are first copied to the next available block in the compact dependent shadow volume.
3. An index is assigned in the bitmap corresponding to the block on the shadow that the data was written to.
As the master volume and the shadow volume diverge, the data on the compact volume grows, and indexes are progressively assigned. If the number of blocks that differ between the master volume and the virtual shadow volume exceeds the number of blocks allocated on the physical shadow, the shadow volume fails. To protect against such a failure, you can designate overflow volumes for a compact dependent shadow volume set.
You can designate an overflow volume for one or more compact dependent shadow volumes. If a compact dependent shadow volume exceeds its limits (that is, the number of blocks that differ between the master and the shadow is greater than the number of blocks allocated for the shadow), an attached overflow volume prevents data loss. Overflow volumes can also be exceeded, but careful planning makes the use of compact dependent shadow volumes and overflow volumes attractive and relatively risk-free.
Shadow volume sets configured with both a compact dependent shadow volume and an overflow volume are managed identically to shadow volume sets with a compact dependent shadow volume, except in the case that the shadow exceeds its capacity. When the Point-in-Time Copy software detects that the storage on the compact dependent shadow volume has been exhausted, it starts to write the data on the designated overflow volume. The index in the bitmap volume is augmented to reflect whether the data was written to a block on the shadow volume, or a block on the overflow volume.
When a volume is initialized as an overflow volume, information is written to a header area on the volume that the Point-in-Time Copy software uses to track how the volume is being used. For example, an overflow volume keeps track of the number of dependent shadow volumes that utilize this volume for overflow data.
The information in this header area is updated when an overflow volume is attached or detached from its corresponding compact dependent shadow volume.
The Point-in-Time Copy software uses a bitmap volume to create point-in-time copies. For every 32 Kbyte block of a master volume that is part of a shadow volume set, a bit is maintained that indicates if the data at the block has changed with respect to its associated point-in-time copy. This technique is called scoreboarding, and the shadow volume set's bitmap volume is sometimes referred to as the bitmap, the scoreboard, or the scoreboard log.
FIGURE 1-2 shows what the master, shadow, and bitmap volume of an independent shadow volume set might look like after a point-in-time copy has been established. In the figure, each 32 Kbyte block on the master and shadow volumes is represented by a cell. The contents of the cell (for example, AAA) represents the data in the 32 Kbyte blocks on the volume. For each block that differs from the master since the point-in-time copy was established, a bit in the bitmap volume is set to 1. This indicates that the data on the storage has changed since the point-in-time copy was made.
FIGURE 1-3 shows what the master, physical shadow, virtual shadow, and bitmap volume of a dependent shadow volume set might look like shortly after a point-in-time copy has been established. This figure shows both the virtual shadow and the physical shadow volumes. The virtual shadow is formed by the union of the master volume at all blocks marked as unchanged (0) in the bitmap, and the physical shadow at all blocks marked as changed (1) in the bitmap.
The Point-in-Time Copy software allows the configuration of a compact dependent shadow volume. A compact shadow volume is one that occupies less physical space than the master volume of the shadow volume set. Compact dependent shadow volumes are useful in situations where:
With compact dependent shadow volumes, an index is maintained for every changed block being tracked in the bitmap volume. It is an index to the block in the compact volume of the data as it existed when the point-in-time copy was created.
In this configuration, after a point-in-time copy is made, blocks written to the master are first copied to the compact dependent shadow volume, starting at the first changed block. The index value is set. As the master volume and the shadow volume change, the data on the compact volume fills up, causing indexes to be progressively assigned. If the number of blocks that differ between the master volume and the virtual shadow volume exceeds the number of blocks allocated on the physical shadow, the following occurs:
To prevent this occurrence, you can designate overflow volumes for a compact dependent shadow volume set.
FIGURE 1-4 shows what the master volume, physical shadow volume, virtual shadow volume, and bitmap volume of a compact dependent shadow volume set might look like after a point-in-time copy has been established.
To prevent the problems associated with overrunning the physical bounds of a compact dependent shadow volume, associate the compact dependent shadow volume with a sharable overflow volume. If the number of blocks that differ between the master volume and the virtual shadow volume exceeds the number of blocks allocated on the compact dependent shadow volume, blocks are copied to the overflow volume. Bitmap management is done in the same way as with compact dependent shadow volumes. An additional index is maintained, to indicate whether an index entry is for the compact shadow volume or the overflow volume.
If the overflow volume itself is filled up, the following occurs:
FIGURE 1-5 shows what the master volume, physical shadow volume, virtual shadow volume, and bitmap volume of a compact dependent shadow volume set with an associated overflow volume might look like after a point-in-time copy has been established. In the index, bracketed cells in the example indicate an index to the overflow volume. Note that the first block of an overflow volume contains a header and is not used for overflow data.
|
Caution - Do not create bitmaps on cylinder 0 because the Point-in-Time Copy software does a raw write and destroys the virtual table of contents (VTOC) for that device. |
Sun StorageTek Availability Suite 4.0 Point-in-Time Copy software enables creation of multiple point-in-time copies from a single master volume. For each of the copies, a shadow volume set must be enabled. Each of the shadow volume sets is maintained according to its own unique type: independent, dependent, compact dependent, or compact dependent with an overflow volume.
Multiple shadow volumes of the same master volume enable the user to perform multiple tasks on identical copies of one master volume. In other words, you can perform many separate analyses of the master data by creating multiple shadow volumes of that master volume.
An independent shadow volume can be exported so that another host can import and use the shadow for any purpose. For the shadow to be exported, it must reside on a dual-ported or SAN-accessible device. The importing host is required to maintain a bitmap for tracking changes made to the shadow volume while it is imported. The shadow volume and its associated bitmap can be joined to its original master after the importing host has disabled the volume set that includes the shadow.
An exported shadow volume permits you to perform analysis of a point-in-time copy of your master data with no impact on operations involving the master volume. No matter how intensive the analysis is, it is performed by a host that is separate from the master volume's host.
The Solaris system administrator must be knowledgeable about the virtual table of contents (VTOC) that is created on raw devices by the Solaris operating system.
The creation and updating of a physical disk's VTOC is a standard function of the Solaris operating system. Software applications like the Sun StorageTek Availability Suite, the growth of storage virtualization, and the appearance of SAN-based controllers have made it easy for an uninformed Solaris system administrator to inadvertently allow a VTOC to be altered. Altering the VTOC increases the possibility of data loss.
Remember these points about the VTOC:
This data loss might not be initially detectable, but can be detected later when other utilities are used, like fsck(1M).
When first configuring and validating volume replication, save copies of all affected device's VTOCs using the prtvtoc(1M) utility. The fmthard(1M) utility can be used to restore them later, if necessary.
| Sun StorageTek Availability Suite 4.0 Point-in-Time Copy Software Administration Guide | 819-6149-10 |
|
Copyright © 2006, Sun Microsystems, Inc. All Rights Reserved.