In today’s 24×7 data centers, one copy of a critical application volume is not enough. To run backup operations, load data warehouses, or test new versions of applications without disrupting the flow of information to users and applications, IT administrators need to create multiple copies of volumes that are used as the data sources for these operations.
Copies can be created manually, but doing so wastes resources—people and time—and is prone to data loss as a result of human error. To circumvent these problems, vendors have developed automated products that create copies more easily. However, while all copies of data look the same, the methods used to create them can vary widely. A major difference between implementations stems from the fact that volume copies can be either actual physical copies of the data or logical copies, and these two approaches differ greatly.
One method creates new physical copies while the other gives the appearance of creating a new volume without allocating any additional space. Physical copies—often called “clones”—are created when a new volume equal in size to the original is allocated to a disk array and the copy operation copies every byte on the original volume to its clone. The result is a clone that takes up exactly the same amount of disk space as the source volume. In contrast, logical copies are created without initially moving (actually copying) data from one location to another. Logical volume copies require little additional disk capacity. Both methods have advantages and disadvantages.
Enter the clones
Many vendors create physical copies, or clones, of volumes. With this implementation, a clone equal in capacity to the original is allocated, and the software copies the bytes from the original to the clone. When the physical operation is completed, the clone can be split from the original volume and mounted on another server to run a backup operation, for example.
While many vendors support volume cloning, not all vendors deliver the same level of functionality. For example, some vendors allow users to create more than one clone or to access the clone before the copy operation is complete; others allow you to create a clone of a clone. When evaluating the different versions of cloning software, IT administrators should ask questions to determine the suitability of the solution to the application:
- How long does the cloning process take? For example, assume that 50GB of data has to be copied from one volume to another. Completion times for the same 50GB will differ from one vendor’s implementation to another.
- Can the clone be used before the copy operation has completed? Some implementations allow the clone to be mounted to another application before the copy operation is completed. The copying operation continues in the background until it completes, which can be a big time-saver when large volumes are cloned.
- How many clones can be created of a specific volume? Some implementations are restricted to one clone per volume; others allow multiple clones per initial volume.
- After the relationship is broken between the original volume and the clone, how long will it take to re-establish the relationship? Does the software copy all the data over again or only the data that has changed since the relationship was severed?
- Can the software restore from the clone? Does the software copy all the data or only the changes that have occurred since the relationship was severed?
Getting the right answers to these questions can help you understand the capabilities and limitations of the cloning function.
The primary alternative process to physical volume cloning is the creation of logical copies. Unlike clones, logical copies do not require the initial allocation of additional storage capacity when the first logical image of a volume is created.
However, logical copying techniques—sometimes called copy-on-write, copy-on-first-write, or copy-out—require additional capacity as updates occur to the original volume. Consider a production data volume (Volume ABC) that consists of only 10 data blocks. The software maintains an index for ABC that “points” to each of ABC’s 10 data blocks. When a logical volume copy is “created,” no additional capacity is required and no data is copied because only the index of ABC, not ABC’s data, is created.
The index copy—call it Volume abc—behaves just like the original index of volume ABC and contains exactly the same pointers to each of the original 10 data blocks for Volume ABC (see Figure 1). Both indexes—Volume ABC and Volume abc—point to the same 10 data blocks. As a result, the logical copying process requires no additional capacity, and a volume copy is made available to other applications in a matter of milliseconds.
The logical copy, Volume abc, never needs additional capacity as long as original Volume ABC remains static. However, in transaction-oriented production environments, data volumes are constantly updated. If Volume ABC is updated, some way must be found to preserve the view of data represented by the index Volume abc as of the point in time when Volume abc was created (i.e., prior to the update of Volume ABC).
Point-in-time consistency of Volume abc is preserved using the copy-on-write process. When a block of data on Volume ABC is updated, the following sequence of events occurs:
- The software determines that block 3 of Volume ABC, for example, will be updated by an application.
- It copies the existing block 3 to a save area for use by index Volume abc.
- 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.
- Block 3 is updated and volume ABC now points to the updated block 3 rather than the original block 3 that was copied and is now essentially “owned” by index Volume abc.
Copy-on-write will not be repeated with subsequent updates of block 3 to preserve the point-in-time consistency of Volume abc. However, if a different block of ABC, say block 7, is updated, then the copy-on-write process will again copy block 7 to Volume abc’s save area before it is updated. This process of copying blocks on first write will continue until the logical copy is deleted or all of the original blocks have been copied.
Using copy-on-first-write technology, Volume ABC (the original production volume) will always contain the latest updated data, while index Volume abc continues to point to the data as it existed at the point in time that Volume abc was created.
The save area shown in Figure 2 is only as large as the number of Volume ABC’s updated blocks. If only 10% of ABC’s blocks get updated, then the save area only needs to be 1/10 the size of Volume ABC. But if all blocks get updated then the save area is the same size as the original volume.
While this implementation may seem complicated, software can create logical copies of volumes in milliseconds. No data is moved and only additional pointers are created for the new volumes within an array. Therefore, an important attribute of the logical copying process is speed.
Another important attribute is capacity savings. Most volumes, with the exception of volumes that contain transactional logs, exhibit update activity of less than 30%. Therefore, creating logical copies of these volumes will require, at most, an additional 30% of capacity. That savings, when multiplied across many volumes, can result in significant savings while still providing applications with online access to additional copies of data.
Since each vendor implements copy-on-first-write differently, there are some questions we recommend that should be directed to the vendors:
- How many logical copies can I make of one volume?
- Do I have to allocate the save area initially? If so, what are the recommendations for how large it should be?
- If the save area is allocated dynamically, will it continue to expand as updates occur? Will it expand to hold a volume equal in size to the original volume? If not, will the copy operation fail when the upper threshold is reached?
- Can I restore from a logical copy to the original volume? How does it restore the volume? Are blocks copied from the save area back to the original location or are indices rebuilt? How long will the restore take?
Understanding how the copy-on-write function works will help IT administrators make better use of this capability.
It can be a difficult task to determine which copying technology—physical or logical—is best. A physical or clone copy requires a capacity equal to that of the original volume. So, a 25GB primary volume will yield a 25GB clone volume. Creating second and third clones boosts the total storage requirement to 100GB. Continue cloning in this manner and you will get the attention of your storage vendor’s sales rep—guaranteed!
Logical copying functions that use copy-on-first-write techniques, on the other hand, require little additional capacity for volumes—particularly those with low update activity. However, there are issues involved with the logical copying process that IT administrators may wish to avoid, depending on the application.
For example, consider what happens when using a logical copy as the source for backup operations for a very active database. While the database application is reading, and at times updating, blocks on the original volume, the backup operation is also reading each block on the volume. During periods of high activity, the database and backup operations can contend for access to the same data blocks—in effect, getting in each other’s way—which can impact performance. IT administrators can get around this situation by scheduling backups during periods of low activity (if periods of low activity exist).
Cloning, on the other hand, avoids this kind of contention altogether, provided that the clone has been completely copied. Copying data to clones can also cause performance headaches.
In short, if you need to set up and pre-sent data volume copies quickly to an application or need to create copies with limited available storage capacity, implementing logical copies may be the answer. But if either the original or the copy exhibit high read-or-write activity, then cloning will avoid contention and performance issues. However, both will adequately provide copies for concurrent processing.