Latest issues
Operating Systems
Home >
Operating Systems > Exploring Storage Snapshot, Cloning & Copy Techniques: Is It a Logical or Physical...
 SUB DEPTS
Print this article

< Previous Page 1 2 3 4 5 6 7 Next Page >
subscribe to z/Journal today!

Exploring Storage Snapshot, Cloning & Copy Techniques: Is It a Logical or Physical Copy?



by Dianne McAdam
October 1, 2004

Point-in-time consistency of Volume abc is preserved using the copy-on-firstwrite process. When a block of data on Volume ABC is updated, the following sequence of events occurs:

  1. The array controller determines that block 3 of ABC, for example, will be updated by an application.
  2. It copies the existing block 3 to a “save area” for use by index Volume abc.
  3. The pointers for block 3 of index Volume abc are changed to point to the new location of block 3 now copied to Volume abc’s save area.
  4. Block 3 is updated and Volume ABC is re-pointed to the updated block 3 rather than the original block 3, which was copied and is now essentially “owned” by index Volume abc.
Note that in Figure 4, Block 3 has been copied to Volume abc’s save area before it is updated.

Copy-on-first-write isn’t repeated with subsequent updates of block 3 in order to preserve the point-in-time consistency of Volume abc. However, if a different block of ABC, say block 7, is updated, the copy-on-write process again copies block 7 to Volume abc’s save area before it’s updated. The process of copying blocks on first write continues until the logical copy is deleted or all the original blocks have been copied.

Using copy-on-first-write technology, the original production volume (Volume ABC) always contains the latest updated data, while the index volume (Volume abc) continues to point to the data as it existed when Volume abc was created.

The save area pictured is only as large as the number of ABC blocks to be updated. If only 10 percent of ABC’s blocks are updated, then the save area only needs to be 1/10 of the size of Volume ABC. However, if all blocks are updated, then the save area is the same size as the original volume.

While copy-on-first-write may seem complicated, array controllers can create logical copies of volumes in just milliseconds. No application data is initially moved and only additional pointers are created for the new volumes within the array.

Speed is one of the most important attributes of the logical copying process. Additionally, the process can save critical capacity. Most volumes, with the exception of volumes that contain transaction logs, have an update activity of less than 30 percent. So creating logical copies of these volumes requires no more than 30 percent additional array capacity. When multiplied across many volumes, this can result in significant savings.

NetApp and STK don’t use a copyon- first-write technique. So some of the questions we recommended for evaluating those products that use this technique, there’s often great variation in their implementations. In these situations, we recommend IT administrators ask these questions:

  • How many logical copies can be made of one volume? Additional copies let IT administrators run multiple processes (e.g., backup and testing) concurrently.
  • Does an administrator have to allocate disk capacity to a save area prior to starting the copy process? If so, how large should the save area be? Does the vendor offer sizing to tools to help with these calculations? If IT administrators have to manually allocate the save area initially, they need to know the write activity associated with each volume so that they know how large the save area should be.
  • In cases requiring a preallocated save area, what happens if the area isn’t large enough to hold all the changed blocks? Does a copy operation fail when additional data needs to be stored in the save area? (This isn’t an issue for products that don’t use a save area.)
  • If the save area is allocated dynamically, will it expand as updates occur? Will it expand to hold a volume equal in size to the original? If not, will the copy operation fail when the upper threshold is reached?
  • Can a production volume be restored from a logical copy? If so, are blocks copied from a save area back to the original location or are indices rebuilt? How long will the restore take?
  • What operating systems are supported? The SVA is the only array in this category that supports z/OS and open systems.
  • How can you manage the copies? Are management packages available to determine which volumes are logical copies and their status? Figure 5 shows several vendors that create logical copies.
Do I Really Need All These Copies?
< Previous Page 1 2 3 4 5 6 7 Next Page >
This article has no comments. Be the first to comment!
 COMMENT ENTRY
Name:
Email:
Location:
Website:
Comments:
Remember my personal information
Notify me of follow-up comments?
Please enter the word
you see in the image below:
   
 SPONSORS
 SEARCH DEPTS
 MAINFRAME JOBS
Mainframe Programmer (CACS) Collections
USAA:A/c,IT,Marketing,Other
San Antonio, TX, US
Mainframe Programmer
General Dynamics Information Technology
Towson, MD, US
Mainframe Programmer
TSR Consulting Services, Inc.
New York, NY, US
Mainframe Programmer
HP
Baltimore, MD, US
Mainframe Developer (Cobol, PL1, JCL)
USAA:A/c,IT,Marketing,Other
San Antonio, TX, US
Mainframe System Programmer
General Dynamics - IT
San Mateo, CA, US
Mainframe System Programmer
General Dynamics - IT
Eagan, MN, US
Technical Associate - Mainframe Programmer
Charles Schwab
Phoenix, AZ, US
Mainframe Computer Operator
100-DST Systems, Inc.
Kansas City, MO, US