Chapter 11 Copy Services Flash

IBM System Storage SAN Volume Controller
by Jon Tate et al. IBM Corporation. (c) 2007. Copying Prohibited.
Reprinted for Deepak Sibal, IBM deesibal@in.ibm.com
All rights reserved. Reproduction and/or distribution in whole or in part in electronic,paper or other forms without written permission is prohibited.
IBMSystemStorageSANVolumeController
Chapter 11: Copy Services: FlashCopy

Overview The FlashCopy function of the IBM System Storage SAN Volume Controller (SVC) provides the capability to perform a point-in-time (PiT) copy of one or more VDisks. In this chapter we describe how FlashCopy works on the SVC, and we present examples on how to configure and utilize FlashCopy. 11.1 FlashCopy FlashCopy is also known as point-in-time copy (PiT). This technique is used to help solve the problem that it is difficult to make a consistent copy of a data set which is being constantly updated. The FlashCopy source is frozen for several seconds during the PiT copy process. It will be able to accept I/O when the PiT copy bitmap is set up and the FlashCopy function is ready to intercept read/write requests in the IO path. Although the background copy operation takes some time, the resulting data at the target appears as if the copy were made instantaneously. SVC's FlashCopy service provides the capability to perform a PiT copy of one or more VDisks. Since it is performed at the block level, it is necessary to flush the cache and OS buffers prior to executing the FlashCopy in order to ensure consistency at the application level.
Business Requirement
The business applications for FlashCopy are many and various. An important use is facilitating consistent backups of constantly changing data, and in these instances a FlashCopy is created to capture a PiT copy. The resulting image is backed up to tertiary storage such as tape. After the copied data is on tape, the FlashCopy target is redundant. Different tasks can benefit from the use of FlashCopy. In the following sections, we describe the most common situations.
Moving and Migrating Data
When you need to move a consistent data set from one host to another, FlashCopy can facilitate this action with a minimum of downtime for the host application dependent on the source VDisk. It is very important to quiesce the application on the host and flush the application and OS buffers, so that the new VDisk contains data that is "clean" to the application. Failing to do this might result in the newly created VDisk being a mirrored copy of inconsistent data, and thus it might not be usable by the application. The cache on the SVC is also flushed using the FlashCopy prepare command; see "Preparing" on page 444 prior to performing the FlashCopy. The created data set on the FlashCopy target is immediately available as well as the source VDisk.
Backup
FlashCopy does not impact your backup time, but it allows you to create a PiT consistent data set (across VDisks), with a minimum of downtime for your source host. The FlashCopy target can then be mounted on a different host (or the backup server) and backed up. Using this procedure, the backup speed becomes less important, since the backup time does not require downtime for the host dependent on the source VDisks.
Restore
You can keep periodically created FlashCopy targets online, to provide very fast restore of specific files from the PiT consistent data set revealed on the FlashCopy targets, which simply can be copied to the source VDisk in case a restore is needed. When a background copy process has completed (that is, it has entered the copied state; see "Idling_or_copied" on page 444), and a complete data set restore is needed, it is possible to delete the FlashCopy mappings and create corresponding FlashCopy mappings in the opposite direction. This is often referred to as a FlashBack procedure. This procedure can be used to restore to the PiT consistent data set obtained from the preceding FlashCopy very quickly.
Page 2 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited
Application Testing
You can test new applications and new operating system releases against a FlashCopy of your production data. The risk of data corruption is eliminated, and your application does not need to be taken offline for an extended period of time to perform the copy of the data. Data mining is a good example of an area where FlashCopy can help you. Data mining can now extract data without affecting your application. 11.2 SVC FlashCopy Features The FlashCopy function in SVC supports these features:
n
The target is the time-zero copy of the source (known as FlashCopy mapping targets). The source VDisk and target VDisk are available (almost) immediately. One source VDisk can have up to 16 target VDisks at the same or different PiTs. Consistency groups are supported to enable FlashCopy across multiple VDisks. The target VDisk can be updated independently of the source VDisk. Bitmaps governing I/O redirection (I/O indirection layer) are maintained in both nodes of the SVC I/O group to prevent a single point of failure. FlashCopy mapping can be automatically withdrawn after the completion of background copy.
What's New
SVC 4.2 has several enhancement to the FlashCopy functions.

n
Multi-Target FlashCopy: Multi-Target FlashCopy (MTFC) allows the same source VDisk to be replicated at different PiTs to different target VDisks. At the same time, it reduces the performance impact on the source VDisk by using a dependency relationship between multiple FlashCopy targets.
Delete FlashCopy relationship after finish: This feature can also be described as automatic withdrawal of the FlashCopy mapping when the background copy has completed. In the command line interface, there is a new option, which is -autodelete in creating the FlashCopy mapping; see Example 11-1 for more detail. Example 11-1: autodelete options add to command line
svctask mkfcmap -source App_Source -target App_Target1 -name App_Map1 -autodelete
In the GUI interface, when you create the FlashCopy mapping, you can check the box marked in Figure 11-1.
Figure 11-1: Automatically delete mapping when background copy complete 11.3 How it Works FlashCopy works by defining a FlashCopy mapping that consists of one source VDisk together with one target VDisk. Multiple FlashCopy mappings can be defined and PiT consistency can be observed across multiple FlashCopy mappings using consistency groups; see "Consistency group with MTFC" on page 432. When FlashCopy is started, it makes a copy of a source VDisk to a target VDisk, and the original contents of the target VDisk are overwritten. When the FlashCopy operation is started, the target VDisk presents the contents of the source VDisk as they existed at the single PiT of FlashCopy starting. This is also referred to as a Time-Zero copy(T0). When a FlashCopy is started, the source and target VDisks are instantaneously available. This is so, because when started, bitmaps are created to govern and redirect I/O to the source or target VDisk, respectively, depending on where the requested block is present, while the blocks are copied in the background from the source to the target VDisk. For more details on background copy, see "Grains and the FlashCopy bitmap" on page 434. Both the source and target VDisks are available for read and write operations, although the background copy process has not yet completed copying across the data from the source to target volumes. In Figure 11-2, the re-direction of the host I/O towards source and target VDisk is explained.
Figure 11-2: Implementation of SVC FlashCopy 11.3.1 FlashCopy Mappings In the SVC, FlashCopy occurs between a source VDisk and a target VDisk. The source and target VDisks must be the same size. The minimum granularity that SVC supports for FlashCopy is an entire VDisk; this means it is not possible to FlashCopy only part of a VDisk. The source and target VDisks must both belong to the same SVC Cluster, but can be in different I/O groups within that Cluster. SVC FlashCopy associates a source VDisk and a target VDisk together in a FlashCopy mapping. VDisks, which are members of a FlashCopy mapping, cannot have their size increased or decreased while they are members of the FlashCopy mapping. The SVC supports the creation of enough FlashCopy mappings to allow every VDisk to be a member of a FlashCopy mapping. A FlashCopy mapping is the act of creating a relationship between a source VDisk and a target VDisk. FlashCopy mappings can be either stand-alone or a member of a consistency group. You can perform the act of preparing, starting, or stopping on either the stand-alone mapping or the consistency group. NoteOnce a mapping is in a consistency group, you can only operate on the group and can no longer prepare, start, or stop the individual mapping. Figure 11-3 illustrates the concept of FlashCopy mapping.
Figure 11-3: FlashCopy mapping 11.3.2 Multi-Target FlashCopy From SVC release 4.2.0 onwards, SVC supports up to 16 target VDisks to be copied from a single source VDisk. Each copy is managed by a unique mapping. In general, each mapping acts independently and is not affected by the fact that other mappings share the same source VDisk. Figure 11-4 illustrates how these can be viewed.
Figure 11-4: Multiple Target FlashCopy Implementation The diagram shows four targets and mappings taken from a single source. It also shows that there is an ordering to the targets: Target 1 is the oldest (as measured from the time it was started), through to Target 4 that is the newest. The ordering is important because of the way in which data is copied when multiple target VDisks are defined and because of the dependency chain which results. A write to source VDisk does not cause its data to be copied to all the targets. Instead, it is copied to the newest target VDisk only (Target 4 above). The older targets will refer to new targets first before referring to the source. From the point of view of an intermediate target disk (neither the oldest or the newest), it treats the set of newer target VDisks and the true source VDisk as a form of composite source. It treats all older VDisks as a kind of target (and behaves like a source to them). If the mapping for an intermediate target VDisk shows 100% progress, then its target VDisk contains a complete set of data. In this case, mappings treat the set of newer target VDisks, up to and including the 100% progress target, as a form of composite source. A dependency relationship exists between a particular target and all newer targets (up to and including a target that shows 100% progress) which share the same source until all data has been copied to this target and all older targets. More information on MTFC can be find in "Interaction and dependency between MTFC" on page 436. 11.3.3 Consistency Groups Consistency groups address the issue where the objective is to preserve data consistency across multiple VDisks, because the applications have related data which spans multiple VDisks. A requirement for preserving the integrity of data being written is to ensure that "dependent writes" are executed in the application's intended sequence. Because the SVC provides PiT semantics, a self consistent data set is obtained. FlashCopy mappings must be part of a consistency group, although if no FlashCopy consistency group is specified, upon creation the FlashCopy mapping will belong to the default group zero. The default consistency group 0 is a pseudo consistency group, and this means that no commands can be directed at FlashCopy consistency group 0, since it is intended for FlashCopy mappings which are to be handled as a single instance. FlashCopy commands can be issued to a FlashCopy consistency group, which affects all FlashCopy mappings in the consistency group, or to a single FlashCopy mapping if not part of a defined FlashCopy consistency group. Figure 11-5 illustrates a consistency group consisting of two FlashCopy mappings.
Figure 11-5: FlashCopy consistency group

Dependent Writes
To illustrate why it is crucial to use consistency groups when a data set spans multiple VDisks, consider the following typical sequence of writes for a database update transaction: 1. A write is executed to update the database log, indicating that a database update is to be performed. 2. A second write is executed to update the database. 3. A third write is executed to update the database log, indicating that the database update has completed successfully. The database ensures the correct ordering of these writes by waiting for each step to complete before starting the next. However if the database log (updates 1 and 3) and the database itself (update 2) are on different VDisks and a FlashCopy mapping is started during this update, then you need to exclude the possibility that the database itself is copied slightly before the database log resulting in the target VDisks seeing writes (1) and (3) but not (2), since the database was copied before the write was completed. In this case, if the database was restarted using the backup made from the FlashCopy target disks, the database log would indicate that the transaction had completed successfully when, in fact, that is not the case. Because the FlashCopy of the VDisk with the database file was started (bitmap was created) before the write was on the disk. Therefore, the transaction is lost and the integrity of the database is in question. To overcome the issue of dependent writes across VDisks, to create a consistent image of the client data, it is necessary to perform a FlashCopy operation on multiple VDisks as an atomic operation. To achieve this condition, the SVC supports the concept of consistency groups. A FlashCopy consistency group can contain an arbitrary number of FlashCopy mappings up to the maximum number of FlashCopy mappings supported by the SVC Cluster. FlashCopy commands can then be issued to the FlashCopy consistency group and thereby simultaneously for all FlashCopy mappings defined in the consistency group. For example, when issuing a FlashCopy start command to the consistency group, all of the FlashCopy mappings in the consistency group are started at the same time, resulting in a PiT copy which is consistent across all of the FlashCopy mappings which are contained in the consistency group.
Consistency Group with MTFC
It is important to note that a consistency group aggregates FlashCopy mappings not VDisks. Thus, where a source VDisk has multiple FlashCopy mappings they can be in the same or different consistency groups. If a particular VDisk is the source VDisk for multiple FlashCopy mappings, you need to create separate consistency groups to separate each mapping of the same source VDisk. If the source VDisk with multiple target VDisks are in the same consistency group, then the result will be that when the consistency group is started, multiple identical copies of the VDisk will be created. However,
this might be what the user wants, for example they may want to run multiple simulations on the same set of source data, and this would be one way of obtaining the identical sets of source data.
Consistency Group Zero
For FlashCopy mappings where there is no need for the complexity of consistency groups, SVC allows a FlashCopy mapping to be treated as an independent entity. In this case, the FlashCopy mapping will become a member of the pseudo consistency group zero. For FlashCopy mappings that are configured in this way, the prepare and start commands are directed at the FlashCopy mapping name or FlashCopy mapping ID rather than the consistency group ID. A prepare or start command directed toward a FlashCopy mapping, which is a member of any other consistency group, is illegal and fails, and at the same time all operations to the pseudo consistency group will fail. For more information, see "Preparing (pre-triggering) the FlashCopy mapping" on page 453.
Maximum Configurations
Table 11-1 shows the FlashCopy properties and maximum configurations. Table 11-1: FlashCopy properties, maximum configuration.
FlashCopy property FC mappings per SVC cluster FC consistency groups per SVC cluster FC VDisk per I/O group FC mappings per consistency group Maximum 3855 128 40TB 512 Comment The maximum number of FC mappings is calculated by noticing that 240 source vdisks with 16 FC mappings plus one more with 15 mappings uses up all 4096 vdisks per cluster. This is an arbitrary limit policed by the SVC software. There is a per I/O group limit of 40 TB on the quantity of source VDisk capacity that can participate in FC mappings. This is due to the time taken to prepare a consistency group with a large number of mappings.
11.3.4 FlashCopy Indirection Layer The FlashCopy indirection layer governs the I/O to both the source and target VDisks when a FlashCopy mapping is started, this is done using a FlashCopy bitmap. The purpose of the FlashCopy indirection layer is to enable both the source and target VDisks for read and write I/O immediately after the FlashCopy has been started. To illustrate how the FlashCopy indirection layer works, we look at what happens when a FlashCopy mapping is prepared and subsequently started. When a FlashCopy mapping is prepared and started, the following sequence is applied: 1. Flush write data in cache onto source VDisk or VDisks if part of a consistency group. 2. Put cache into write-through on the source VDisk(s). 3. Discard cache for the target VDisk(s). 4. Establish a sync point on all source VDisks in the consistency group (creating the FlashCopy bitmap). 5. Ensure that the indirection layer governs all I/O to source and target VDisks. 6. Enable cache on both the source and target VDisks. FlashCopy provides the semantics of a PiT copy, using the indirection layer which intercepts I/Os targeted at either the source or target VDisks. The act of starting a FlashCopy mapping causes this indirection layer to become active in the I/O path. This occurs as an atomic command across all FlashCopy mappings in the consistency group. The indirection layer makes a decision about each I/O. This decision is based upon:
n
The VDisk and logical block number (LBA) to which the I/O is addressed Its direction (read or write)
The state of an internal data structure, the FlashCopy bitmap
The indirection layer either allows the I/O through to the underlying storage, redirects the I/O from the target VDisk to the source VDisk, or stalls the I/O while it arranges for data to be copied from the source VDisk to the target VDisk. To explain in more detail which action is applied for each I/O, we first look at the FlashCopy bitmap.
Grains and the FlashCopy Bitmap
When data is copied from the source VDisk to the target VDisk or from target to target, it is copied in units of address space known as grains. In the SVC, the grain size is 256 KB. The FlashCopy bitmap contains one bit for each grain. The bit records whether the associated grain has yet been split or not.
n
Grain is split: The grain is already copied from the source to the target, or from the target to its dependency target.
Grain is not split: The grain has not been copied from source to target, or from the target to its dependency target.
The rate at which the grains are copied across from the source VDisk to the target VDisk is called the copy rate. By default, the copy rate is 50%, though this can be altered. For more information about copy rates, see "Background copy rate" on page 446.
The FlashCopy Indirection Layer Algorithm
Imagine the FlashCopy indirection layer as the I/O traffic cop when a FlashCopy mapping is active. The I/O is intercepted and handled according to whether it is directed at the source VDisk or the target VDisk, depending on the nature of the I/O (read or write) and the state of the grain (has it already been copied or not). In Figure 11-6, we illustrate how the background copy is running while I/Os are handled according to the indirection layer algorithm.
Figure 11-6: I/O processing with FlashCopy In the following topics, we describe how the FlashCopy indirection layer handles read and write I/O respectively to the source and target vdisks.
Source Reads
Reads of the source are always passed through to the underlying source disk.
Target Reads
In order for FlashCopy to process a read from the target disk, it must consult its bitmap:
n
If the data being read is already copied to the target (grain is split), then the read is sent to the target disk. If the data being read has not yet been copied (grain is unsplit), then the read is sent to the source disk or possibly to another target VDisk if multiple FlashCopy mappings exist for the source VDisk.
Clearly, this algorithm requires that while this read is outstanding, no writes are allowed to execute that would change the data being read from the source. The SVC satisfies this requirement by a cluster-wide locking scheme.
Writes to the Source or Target
Where writes occur to source or target to an area (grain) which has not yet been copied, these will usually be held while a copy operation is performed to copy data from the source to the target (step 1 of Figure 11-6), to maintain the illusion that the target contains its own copy. After step 1 is finished, the write I/O will be performed, shown as step 2 in Figure 11-6. A specific optimization is performed where an entire grain is written to the target VDisk. In this case the new grain contents are written to the target VDisk, and if this succeeds, then the grain is marked as split in the FlashCopy bitmap without a copy from the source to the target having been performed. If the write fails, then the grain is not marked as split. This is described further in "Write to target VDisk" on page 437. 11.3.5 Interaction and Dependency between MTFC Figure 11-7 represents a set of five FlashCopy mappings that share a common source. The FlashCopy mappings are to target VDisks T0, T1, T2, T3, T4. These mappings were started at times t0, t1, t2, t3, t4 where t4>=t3>=t2>=t1>=t0. The VDisks involved are very small and have only five grains numbered 0 to 4.
Figure 11-7: Interactions between MTFC mappings T0 is not dependent on any source or target because it has completed copying all of its grains and it has no dependent mappings. T1 is dependent upon T2 and T3. It will remain dependent until all grains in T1 have been copied. It has no targets that are
dependent on it since T0 is 100% copy complete. Once all grains in T1 have been copied, it can move to the idle_copied state. Similarly, T2 is dependent upon T3 and will remain dependent until all grains in T2 have been copied. T1 is dependent on T2, so even when all grains have be copied to T2 it cannot move to the idle_copied state. T3 has actually completed copying all of its grains, so it is not dependent on any other maps. T1 and T2 are still dependent on it, so it remains in the copying state with progress = 100%. T4 has actually completed copying all of its grains, so it is not dependent on any other targets or the source. In addition it has no maps that are dependent on it. These two conditions mean that it is in the idle_copied state.
Write to Target VDisk
A write to an intermediate or newest target VDisk must consider the state of the grain within its own mapping as well as that of the grain of the next oldest mapping:
n
If the grain of the next oldest mapping has not yet been copied, then it must be copied before the write is allowed to proceed in order to preserve the contents of the next oldest mapping. The data written to the next oldest mapping comes from a target or source. If the grain in the target being written has not yet been copied, then the grain is copied from the oldest already copied grain in the mappings that are newer than it, or the source if none are already copied. Once this copy has been done, the write can be applied to the Target.
Read to Target VDisk
If the grain being read has been split, then the read simply returns data from the target being read. If the read is to an uncopied grain on an intermediate target VDisk, then each of the newer mappings is examined in turn to see if the grain has been split. The read is surfaced from the first split grain found or from the source VDisk if none of the newer mappings has a split grain.
Stopping Copy Process
An important scenario arises when a stop command is delivered to a mapping for a target which has dependent mappings. Once a mapping is in the stopped state, it can be deleted or restarted, and this must not be allowed if there are still grains which hold data that other mappings depend upon. To avoid this, when a mapping receives a stop command, rather than immediately moving to the stopped state, it enters the "stopping" state. An automatic copy process is driven that will find and copy all data uniquely held on the target VDisk of the mapping that is being stopped, to the next oldest mapping that is in the copying state. NoteThis stopping copy process can be ongoing for several mappings sharing the same source at the same time. At the completion of this process, the mapping will automatically make an asynchronous state transition to the stopped state or the idle_copied state if the mapping was in the copying state with progress = 100%. For example, if the mapping associated with target T2 was issued a stop command, then T2 would enter the stopping state while a process copied the data in grain 4 of T2 into grain 4 of T1. No other grains would need to be copied because grains 0 and 2 are already copied to T1, and grains 1 and 3 of T1 depend upon T3 and not upon T2. Once grain 4 has been copied, T2 would enter the stopped state and T1 would no longer be dependent upon T2, but would remain dependent upon T3. 11.3.6 Summary of the FlashCopy Indirection Layer Algorithm In Table 11-2 the indirection layer algorithm is summarized. Table 11-2: Summary table of the FlashCopy indirection layer algorithm.
VDisk being accessed Source Has the grain been split (copied) No Host I/O operation Read Read from source VDisk. Write Copy grain to most recently started target for this source, then write source.
Yes Target No
Read from source VDisk If any newer targets exist for this source in which this grain has already been copied, then read from the oldest of these. Otherwise, read from the source. Read from target VDisk.
Write to source VDisk. Hold the write. Check dependency target VDisks to see if the grain is split. If the grain is not already copied to the next oldest target for this source, then copy the grain to the next oldest target. Then, write target. Write to target VDisk.
Yes
11.3.7 Interaction with the Cache Normally, the copy-on-write process can introduce some latency into write operations. But in the SVC design there is a FlashCopy indirection layer, which is placed logically below the cache. It isolates the host application that issued the write I/O from this latency. This means that the copy latency is typically only seen on destage from the cache, rather than for write operations from a using application, which otherwise may be blocked waiting for the write to complete. In Figure 11-8, we illustrate the logical placement of the FlashCopy indirection layer.
Figure 11-8: Logical placement of the FlashCopy indirection layer 11.3.8 FlashCopy Rules For SVC 4.2 the maximum number of supported FlashCopy mappings are 3855 per SVC cluster. This is larger than half of the number of supported VDisks, which is 4096/2=2048 per SVC cluster. This means that the maximum configuration supports the fact that all VDisks can be part of a FlashCopy mapping, whether as a source or target VDisk, if all the following rules are met:
n
There is a one-to-one mapping of the source VDisk to the target VDisk. One source VDisk can have 16 target VDisks. The source and target VDisks can be in different I/O groups of the same cluster. Minimum FlashCopy granularity is the entire VDisk. The source and target must be exactly equal in size. The size of a source and target VDisk cannot be altered (increased or decreased) after the FlashCopy mapping is created. There is a per I/O group limit of 40 TB on the quantity of the source and target VDisk capacity that can participate in
Page 12 / 48
Reprintedforibm\deesibal@in.ibm.com,IBM
IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited
FlashCopy mappings. 11.3.9 FlashCopy and Image Mode Disks You can use FlashCopy with an image mode VDisk. Since the source and target VDisks must be exactly the same size when creating a FlashCopy mapping, a VDisk must be created with the exact same size as the image mode VDisk. To accomplish this, use the command svcinfo lsvdisk -bytes VDiskName. The size in bytes is then used to create the VDisk to be used in the FlashCopy mapping. In Example 11-2 we list the size of the image mode VDisk VDISK1, in bytes. Subsequently the VDisk VDISK1T is created specifying the same size. Example 11-2: Listing the size of a VDisk in bytes and creating a VDisk of equal size.
IBM_2145:ITSOSVC42A:admin>svcinfo lsvdisk -bytes imagevdisk1 id 31 name imagevdisk1 IO_group_id 0 IO_group_name io_grp0 status online mdisk_grp_id 7 mdisk_grp_name MDG6 capacity 1073741824 type image formatted no mdisk_id 10 mdisk_name mdisk10 FC_id FC_name RC_id RC_name vdisk_UID 60050768018201BEE000000000000033 throttling 0 preferred_node_id 1 fast_write_state empty cache readwrite udid fc_map_count 0 IBM_2145:ITSOSVC42A:admin>svctask mkvdisk -size 1073741824 -unit b -name imageT -mdiskgrp MDG0 -vtype striped -iogrp 0 Virtual Disk, id [36], successfully created
TipAlternatively, the expand and shrink VDisk commands can be used to modify the size as the commands support specification of the size in bytes. See "Expanding a VDisk" on page 277 and "Shrinking a VDisk" on page 282 for more information. An image mode VDisk can be used as either a FlashCopy source or target VDisk. 11.3.10 FlashCopy Mapping Events In this section we explain the series of events that modify the states of a FlashCopy. In Figure 11-9, the FlashCopy mapping state diagram shows an overview of the states that apply to a FlashCopy mapping.
Figure 11-9: FlashCopy mapping state diagram Here is an Overview of a FlashCopy Sequence of Events 1. Associate the source data set with a target location (one or more source and target VDisks). 2. Create FlashCopy mapping for each source VDisk to the corresponding target VDisk. The target VDisk must be equal in size to the source VDisk. 3. Discontinue access to the target (application dependent). 4. Prepare (pre-trigger) the FlashCopy: a. Flush cache for the source. b. Discard cache for the target. 5. Start (trigger) the FlashCopy: a. Pause I/O (briefly) on the source. b. Resume I/O on the source. c. Start I/O on the target. Below each event (numbered in the diagram) that transitions a FlashCopy mapping from one state to another, we provide an explanation of that event.
n
1. Create: A new FlashCopy Mapping is created between the specified source VDisk and the specified target VDisk. The operation fails if the proposed target or source is already a target in a FlashCopy Mapping or the proposed source is already a source in the maximum number of FlashCopy mappings. The operation also fails if the source and target VDisks are a different size. 2. Prepare: The prepare command is directed to either a consistency group of FlashCopy mappings or to a standalone FlashCopy mapping. The prepare command places the FlashCopy mappings in the preparing state. ImportantThe act of preparing for start might corrupt any data that previously resided on the target VDisk, because cached writes are discarded. Even if the FlashCopy mapping is never started, the data from the target might be logically changed by the act of preparing for start.
Page 14 / 48
3. Flush done: The FlashCopy relationship moves from the preparing state to the prepared state automatically after all cached data for the source is flushed and all cached data for the target is invalidated. NoteIf the flush of data from the cache cannot be completed, then the FlashCopy mapping enters the stopped state.
4. Start: After all of the FlashCopy mapping or mappings in a consistency group are in the prepared state, the FlashCopy mappings can be started. This is often referred to as triggering the FlashCopy. When started, this is the T0 of the PiT copy. During the processing of the start command, the following actions occur in sequence: a. New reads and writes to all source VDisks in the consistency group are paused in the cache layer until all ongoing reads and writes below the cache layer have been completed. b. After all FlashCopy mappings in the consistency group are paused, internal metadata is set to allow FlashCopy operation, creating the FlashCopy bitmap. c. After all FlashCopy mappings in the consistency group have their metadata set, the read and write operations are unpaused on the source VDisks. d. The target VDisks are brought online. As part of the start command, read and write caching are enabled for both the source and target VDisks.
5. Copy completed: Once every grain of the source and target has been copied and there are no dependent mappings, the source and target are independent and the state machine enters the copied state. If the "autodelete" option has been used when creating the FlashCopy mapping, or has been applied when changing it, the mapping will be automatically deleted when the copy completes. Without the "autodelete" option, the mapping will remain and can be re-activated by preparing and starting again. NoteThe copy complete event will not occur while there are still dependent mappings in the copying state.
6. Stop complete: This event causes a transition from stopping to stopped when the automated copy completes the task of breaking the dependency of older FlashCopy mappings upon the target of the stopping mapping. This will be raised on a transition from prepared or stopping into the stopped state and even if the mapping has no downstream dependents.
Special FlashCopy Events
Here we describe some special FlashCopy events:

n
4a/4b Bitmap offline/online: If access to both SVC nodes in the I/O group which the source VDisk belongs to is lost while in the copying or stopping state, then the FlashCopy mapping will enter the suspended state, and access to both the source and target VDisks in the FlashCopy mapping will be suspended. This happens if the FlashCopy bitmap, which the background copy depends upon, becomes inaccessible. Further information on this is discussed in "Error handling" on page 447. 6b Forced Delete: If a FlashCopy mapping in the stopped state is to be deleted, the -force flag must be used. When a mapping is stopped, all data in the cache for the target vdisk is discarded, thus when it comes back online there will be nothing to destage. The force flag is still required because the target vdisk contains an incomplete image of the source and the user will be bringing this incomplete image online.
Modify: A FlashCopy mapping has two parameters that can be modified (apart from renaming it and the autodelete flag). These are the background copy rate and the consistency group. The background copy rate can be modified in any state, but attempting to modify a consistency group in any state other than idle_or_copied or stopped will fail.
Copy Complete: Once every grain of the source and target has been copied and there are no dependent mappings, the source and target are independent and the state machine enters the copied state. If the "autodelete" option has
Page 15 / 48
been used when creating the FlashCopy Mapping, or has been applied when changing it, the mapping will be automatically deleted when the copy completes. Without the "autodelete" option, the mapping will remain and may be re-activated by preparing and starting again. NoteThe copy complete event will not occur while there are still dependent mappings in the copying state.
n
Stop: There are two mechanisms by which a FlashCopy mapping can be stopped. It can be stopped by a user command or by an I/O error. When a FlashCopy mapping enters the stopped state the target VDisk is taken offline. If the mapping is in the idle_copied state when a user stop request is received, the request is completed with good status, but the mapping does not change state. If the mapping is in the copying state, then it will move to the stopping state. If there are dependent maps, then a stopping copy process is started, the mapping will be in the idle_copied state if the background copy process had completed for this mapping, otherwise it will be in the stopped state. Before the mapping is moved to the stopped state, all cache data is discarded for the target to prevent data for the offline target being pinned in cache. Stop Complete: This asynchronous event causes a transition from stopping to stopped when the automated copy completes the task of breaking the dependency of older FlashCopy mappings upon the target of the stopping mapping. This will be raised on a transition from prepared or stopping into the stopped state and even if the mapping has no downstream dependents.
11.3.11 FlashCopy Mapping States In this section, we explain the states of a FlashCopy mapping in more detail.
Idling_or_copied
Read and write caching is enabled for both the source and the target. A FlashCopy mapping exists between the source and target, but they behave as independent VDisks in this state.
Copying
The FlashCopy indirection layer governs all I/O to the source and target VDisks while the background copy is running. Reads and writes are executed on the target as though the contents of the source were instantaneously copied to the target during the start command. The source and target can be independently updated. Internally, the target depends on the source for some tracks. Read and write caching is enabled on the source and the target.
Stopped
The FlashCopy was stopped either by user command or by an I/O error. When a FlashCopy mapping is stopped, any useful data in the target VDisk is lost. Because of this, while the FlashCopy mapping is in this state, the target VDisk is in the offline state. In order to regain access to the target, the mapping must be started again (the previous PiT will be lost) or the FlashCopy mapping must be deleted. The source VDisk is accessible and read/write caching is enabled for the source. In stopped state, a mapping can be prepared again or it can be deleted.
Stopping
The mapping is in the process of transferring data to an dependency mapping. The behavior of the target VDisk depends on whether the background copy process had completed while the mapping was in the copying state. If the copy process had completed, then the target VDisk remains online while the stopping copy process completes. If the copy process had not completed, then data in the cache is discarded for the target VDisk. The target VDisk is taken offline and the stopping copy process runs. When the data has been copied, then a stop complete asynchronous event is notified. The mapping will move to idle/copied state if the background copy has completed or to stopped if it has not. The source VDisk remains accessible for I/O.
Suspended
The target has been 'flashed' from the source, and was in the copying or stopping state. Access to the metadata has been lost, and as a consequence, both source and target VDisks are offline. The background copy process has been halted.
When the metadata becomes available again, the FlashCopy mapping will return to the copying or stopping state, access to the source and target VDisks will be restored, and the background copy or stopping process resumed. Unflushed data which was written to the source or target before the FlashCopy was suspended is pinned in the cache, consuming resources, until the FlashCopy mapping leaves the suspended state.
Preparing
Since the FlashCopy function is placed logically below the cache to anticipate any write latency problem, it demands no read or write data for the target and no write data for the source in the cache at the time that the FlashCopy operation is started. This ensures that the resulting copy is consistent. Performing the necessary cache flush as part of the start command unnecessarily delays the I/Os received after the start command is executed, since these I/Os must wait for the cache flush to complete. To overcome this problem, SVC FlashCopy supports the prepare command, which prepares for a FlashCopy start while still allowing I/Os to continue to the source VDisk. In the preparing state, the FlashCopy mapping is prepared by the following steps: 1. Flushing any modified write data associated with the source VDisk from the cache. Read data for the source will be left in the cache. 2. Placing the cache for the source VDisk into write through mode, so that subsequent writes wait until data has been written to disk before completing the write command received from the using host. 3. Discarding any read or write data associated with the target VDisk from the cache. While in this state, writes to the source VDisk will experience additional latency because the cache is operating in write through mode. While the FlashCopy mapping is in this state, the target VDisk is reported as online but will not perform reads or writes. These are failed by the SCSI front end. Before starting the FlashCopy mapping, it is important that any cache at the host level, for example buffers in host OS's or applications, are also instructed to flush any outstanding writes to the source VDisk.
Prepared
When in the prepared state, the FlashCopy mapping is ready to perform a start. While the FlashCopy mapping is in this state, the target VDisk is in the offline state. In the prepared state, writes to the source VDisk experience additional latency because the cache is operating in write through mode.
Summary of FlashCopy Mapping States
In Table 11-3, the various FlashCopy mapping states and the corresponding state of the source and target VDisks are listed. Table 11-3: FlashCopy mapping state summary due to FlashCopy
State Source Online/offline Idling/Copied Copying Stopped Stopping Suspended Preparing Prepared Online Online Online Online Offline Online Online Cache state Write-back Write-back Write-back Write-back Write-back Write-through Write-through Online/offline Online Online Offline Online if copy complete Offline if copy not complete Offline Online but not accessible Online but not accessible Target Cache state Write-back Write-back -
11.3.12 Background Copy Rate A FlashCopy mapping has a property Background Copy Rate. This is expressed as a percentage and can take values between 0 and 100. The background copy rate can be changed when the FlashCopy mapping is in any state. If a value of 0 is specified, then background copy is disabled. This is equivalent to a NOCOPY option. This option is suitable for short lived FlashCopy mappings, which are to be used for backup purposes only. Since the source data set is not expected to change much during the lifetime of the FlashCopy mapping, it is more efficient in terms of managed disk I/Os not to perform a background copy. The relationship of the background copy rate value to the attempted number of grains to be split (copied) per second is shown in Table 11-4. Table 11-4: Background copy rate
Percentage 110 1120 2130 3140 4150 5160 6170 7180 8190 91100 Data copied per second 128KB 256KB 512KB 1MB 2MB 4MB 8MB 16MB 32MB 64 MB Grains per second 0.5 1 2 4 8 16 32 64 128 256
The grains per second numbers represent the maximum number of grains the SVC will copy per second, assuming that the bandwidth to the MDisks can accommodate this. The SVC is unable to achieve these copy rates if insufficient bandwidth is available from the SVC nodes to the physical disks making up the managed disks, after taking into account the requirements of foreground I/O. If this situation arises, then background copy I/O contends for resources on an equal basis with I/O arriving from hosts. Both tend to see an increase in latency, and a consequential reduction in throughput with respect to the situation had the bandwidth not been limited. Degradation is graceful. Both background copy and foreground I/O continue to make forward progress, and do not stop, hang, or cause the node to fail. The background copy is performed by both nodes of the I/O group in which the source VDisk resides. Prior to SVC 3.1 the background copy was performed by only one node in the IO group. 11.3.13 Synthesis The FlashCopy functionality in SVC simply creates copy VDisks. All the data in the source VDisk is copied to the destination VDisk. This includes operating system control information as well as application data and metadata. Some operating systems are unable to use FlashCopy without an additional step, which is termed synthesis. In general, synthesis performs some transformation on the operating system metadata in the target VDisk so that the operating system can use the disk. Operating system specifics are discussed in Appendix A, "Copy services and open systems" on page 705. 11.3.14 Serialization of I/O by FlashCopy In general, the FlashCopy function in the SVC introduces no explicit serialization into the I/O path. Therefore, many concurrent I/Os are allowed to the source and target VDisks. However, there is a lock for each grain. The lock can be taken shared or exclusive. For multiple targets, a common lock is
shared the mappings derived from a particular source VDisk.The lock is taken in the following modes under the following conditions:
n
The lock is taken shared for the duration of a read from the target VDisk which touches a grain which is not split. The lock is taken exclusive during a grain split. This happens prior to FlashCopy actioning any destage (or write through) from the cache to a grain which is going to be split (the destage waits for the grain to be split). The lock is held during the grain split and released before the destage is processed.
If the lock is held shared, and another process wants to take the lock shared, then this request is granted unless a process is already waiting to take the lock exclusive. If the lock is held shared and it is requested exclusive, then the requesting process must wait until all holders of the shared lock free it. Similarly, if the lock is held exclusive, then a process wanting to take the lock in either shared or exclusive mode must wait for it to be freed. 11.3.15 Error Handling When a FlashCopy mapping is not copying, the FlashCopy function does not affect the error handling or reporting of errors in the I/O path. Only when a FlashCopy mapping is copying, are error handling and reporting are affected by FlashCopy. We describe these scenarios in the following sections.
Node Failure
Normally two copies of the FlashCopy bitmaps are maintained, one on each of the two nodes making up the I/O group of the source VDisk. When a node fails, one copy of the bitmaps for all FlashCopy mappings whose source VDisk is a member of the failing node's I/O group will become inaccessible. FlashCopy will continue with a single copy of the FlashCopy bitmap being stored as non-volatile in the remaining node in the source I/O group. The cluster metadata is updated to indicate that the missing node no longer holds up-to-date bitmap information. When the failing node recovers, or a replacement node is added to the I/O group, up-to-date bitmaps will be re-established on the new node, and it will once again provide a redundant location for the bitmaps.
n
When the FlashCopy bitmap becomes available again (at least one of the SVC nodes in the I/O group is accessible), the FlashCopy mapping will return to the copying state, access to the source and target VDisks will be restored, and the background copy process resumed. Unflushed data which was written to the source or target before the FlashCopy was suspended is pinned in the cache until the FlashCopy mapping leaves the suspended state. Normally two copies of the FlashCopy bitmaps are maintained (in non-volatile memory), one on each of the two SVC nodes making up the I/O group of the source VDisk. If only one of the SVC nodes in the I/O group which the source VDisk belongs to goes offline, then the FlashCopy mapping will continue in the copying state, with a single copy of the FlashCopy bitmap. When the failed SVC node recovers, or a replacement SVC node is added to the I/O group, up-todate FlashCopy bitmaps will be re-established on the resuming SVC node, and again provide a redundant location for the FlashCopy bitmaps. NoteIf both nodes in the I/O group to which the target VDisk belongs become unavailable, then host can not access the target VDisk.
Path Failure (Path Offline State)
In a fully functioning cluster, all nodes have a software representation of every VDisk in the cluster within their application hierarchy. Since the SAN which links the SVC nodes to each other, and to the managed disks, is made up of many independent links, it is possible for some subset of the nodes to be temporarily isolated from some of the managed disks. When this happens, the managed disks are said to be path offline on some nodes. NoteOther nodes might see the managed disks as online, because their connection to the managed disks is still functioning.
When a managed disk enters the path offline state on an SVC node, all the VDisks which have any extent on the managed disk, also become path offline. Again, this happens only on the affected nodes. When a VDisk is path offline on a particular SVC node, this means that host access to that VDisk through the node will fail with the SCSI sense indicating offline.
Path Offline for the Source VDisk
If a FlashCopy mapping is in the copying state and the source VDisk goes path offline, then this path offline state is propagated to all target VDisks up to but not including the target VDisk for the newest mapping that is 100% copied but remains in the copying state. If no mappings are 100% copied, then all target VDisks will be taken offline. Again note that path offline is a state which exists on a per-node basis. Other nodes may not be affected. If the source VDisk comes online, then the target and source VDisks are brought back online.
Path Offline for the Target VDisk
If a target VDisk goes path offline but the source VDisk is still online, and if there are any dependent mappings, then those target VDisks will also go path offline. The source VDisk will remain online. 11.3.16 Asynchronous Notifications FlashCopy raises informational error logs when mappings or consistency groups make certain state transitions as detailed below. These state transitions occur as a result of configuration events that complete asynchronously, and the informational errors can be used to generate Simple Network Management Protocol (SNMP) traps to notify the user. Other configuration events complete synchronously, and no informational errors are logged as a result of these events:
n
PREPARE_COMPLETED: This is logged when the FlashCopy mapping or consistency group enters the prepared state as a result of a user request to prepare. The user can now start (or stop) the mapping or consistency group. COPY_COMPLETED: This is logged when the FlashCopy mapping or consistency group enters the idle_or_copied state when it was previously in the copying or stopping state. This indicates that the target disk now contains a complete copy and no longer depends on the source. STOP_COMPLETED: This is logged when the FlashCopy mapping or consistency group has entered the stopped state as a result of a user request to stop. It will be logged once the automatic copy process has completed. This includes mappings where no copying needed to be performed. It is different from the error that is logged when a mapping or group enters the stopped state as a result of an IO error.
11.3.17 Interoperation with Metro Mirror and Global Mirror FlashCopy can work together with Metro Mirror and Global Mirror to provide better protection of data. For example, we can perform a Metro Mirror to duplicate data from Site_A to Site_B, then, do a daily FlashCopy and copy it to tape. Table 11-5 details which combinations of FlashCopy and remote copy are supported. In the table, Remote Copy refers to Metro Mirror and Global Mirror. Table 11-5: FlashCopy Remote Copy interaction
Remote Copy Primary Supported Remote Copy Secondary Supported Note:WhentheFlashCopyrelationshipisinthepreparingandpreparedstate,thecacheat the Remote Copy secondary site will be operating in write through mode. This will add additional latency to the already latent Remote Copy Relationship. FlashCopy Destination Not Supported Not Supported
FlashCopy Source
11.3.18 Recovering Data from FlashCopy FlashCopy PiT can be used to recover the data if some form of corruption has happened. For example, if a user deletes some data by mistake, you can map the FlashCopy target VDisks to the application server, and import all the logical volume level configurations, start the application, and restore the data back to a given point in time.
TipIt is better to map a FlashCopy target VDisk to a backup machine with the same application installed. We do not recommend that you map a FlashCopy target VDisk to the same application server that the FlashCopy source VDisk is mapped. The reason is that the FlashCopy target and source VDisk have same signature, pvid, vgda, and so on. Special steps will be necessary to handle the conflict at OS level. For example, you can use the command recreatevg in AIX to generate different vg, lv, filesystem, and so on, names in order to avoid a naming conflict. FlashCopy backup is a disk-based backup copy, which can be used to restore service more quickly than other backup techniques. This application is further enhanced by the ability to maintain multiple backup targets, spread over a range of time, allowing the user to choose a backup from before the time of corruption. 11.4 Using Command Line to do FlashCopy In this section we use a scenario to illustrate how to use commands with PuTTY to perform FlashCopy. The IBM TotalStorage Virtualization Family SAN Volume Controller: Command-Line Interface User's Guide for more commands, which is available at: http://www-304.ibm.com/jct01004c/systems/support/supportsite. wss/supportresources? taskind=3&brandind=5000033&familyind=5329743 11.4.1 Scenario Description We use the following scenario in both the command line section and the GUI section. In the following scenario, we want to FlashCopy the following VDisks: DB_Source: Database files Log_Source: Database log files App_Source: Application files Since data integrity must be kept on DB_Source and Log_Source, we create consistency groups to handle the FlashCopy of DB_Source and Log_Source. In our scenario the application files are independent of the database, so we create a single FlashCopy mapping for App_Source. We will make two FlashCopy targets for DB_Source and Log_Source, and thereby two consistency groups. The scenario is shown in Figure 11-10.
Figure 11-10: FlashCopy scenario using the CLI

Setting Up FlashCopy
We have already created the source and target VDisks, and the source and target VDisks are identical in size, which is a requirement of the FlashCopy function:
n
DB_Source, DB_Target1, DB_Target2 Log_Source, Log_Target1, Log_Target2 App_Source, App_Target1
To set up the FlashCopy, we performed the following steps: 1. Create a FlashCopy consistency group:
n
Named FCCG1 Named FCCG2
2. Create FlashCopy mapping for Source VDisks:

n
DB_Source FlashCopy to DB_Target1, the mapping name is DB_Map1 DB_Source FlashCopy to DB_Target2, the mapping name is DB_Map2 Log_Source FlashCopy to Log_Target1, the mapping name is Log_Map1 Log_Source FlashCopy to Log_Target2, the mapping name is Log_Map2 App_Source FlashCopy to App_Target1, the mapping name is App_Map1 Copyrate 50%
11.4.2 Creating a FlashCopy Consistency Group To create a FlashCopy consistency group, we use the command svctask mkfcconsistgrp to create a new consistency group. The ID of the new group is returned. If you have created several FlashCopy mappings for a group of VDisks that contain elements of data for the same application, you may find it convenient to assign these mappings to a single FlashCopy consistency group. Then you can issue a single prepare or start command for the whole group, so that, for example, all the files for a particular database are copied at the same time. In Example 11-3, the consistency group FCCG1 and FCCG2 are created, which will hold the FlashCopy maps of DB and Log together. This is a very important step in doing FlashCopy on database applications. It helps to keep data integrity during FlashCopy. Example 11-3: Creating two FlashCopy consistency groups
IBM_2145:ITSOSVC42A:admin>svctask mkfcconsistgrp -name FCCG1 FlashCopy Consistency Group, id [1], successfully created IBM_2145:ITSOSVC42A:admin>svctask mkfcconsistgrp -name FCCG2 FlashCopy Consistency Group, id [2], successfully created
In Example 11-4, we checked the status of consistency groups. Each has a status of Idle_or_copied. Example 11-4: Check FlashCopy consistency group
IBM_2145:ITSOSVC42A:admin>svcinfo lsfcconsistgrp id name status 1 FCCG1 idle_or_copied 2 FCCG2 idle_or_copied
If you would like to change the name of a consistency group, you can use the svctask chfcconsistgrp command. Type svctask chfcconsistgrp -h to get help. 11.4.3 Creating a FlashCopy Mapping To create a FlashCopy mapping, we use the command svctask mkfcmap. This command creates a new FlashCopy mapping, which maps a source virtual disk to a target virtual disk to prepare for subsequent copying. When executed, this command creates a new FlashCopy mapping logical object. This mapping persists until it is deleted. The mapping specifies the source and destination virtual disks. The destination must be identical in size to the source, or the mapping will fail. Issue the command svcinfo lsvdisk -bytes to find the exact size of the source VDisk that you want to create a target disk of the same size. The source and destination cannot be in an existing mapping. That is, a virtual disk can be either a source or a destination disk in only one mapping. A mapping is triggered at the point in time when the copy is required. The mapping can optionally be given a name and assigned to a consistency group. These are groups of mappings that can be triggered at the same time. This enables multiple virtual disks to be copied at the same time, which creates a consistent copy of multiple disks. This is required by some database products in which the database and log files reside on different disks. If no consistency group is defined, the mapping is assigned into the default group 0. This is a special group that cannot be started as a whole. Mappings in this group can only be started on an individual basis. The background copy rate specifies the priority that should be given to completing the copy. If 0 is specified, the copy will not proceed in the background. The default is 50. TipThere is a parameter to delete FlashCopy mappings automatically after completion of background copy (when mapping gets to "idle_or_copied" state). Use the command: svctask mkfcmap -autodelete This command does not delete mappings in cascade with dependent mappings because it would not get to the "idle_or_copied" state. In Example 11-5, the first FlashCopy mapping for DB_Source and Log_Source is created. Example 11-5: Create the first FlashCopy mapping for DB_Source, Log_Source and App_Source
IBM_2145:ITSOSVC42A:admin>svctask mkfcmap -source DB_Source -target DB_Target1 -name DB_Map1 -consis FCCG1 FlashCopy Mapping, id [0], successfully created IBM_2145:ITSOSVC42A:admin>svctask mkfcmap -source Log_Source -target Log_Target1 -name Log_Map1 -con FCCG1 FlashCopy Mapping, id [1], successfully created IBM_2145:ITSOSVC42A:admin>svctask mkfcmap -source App_Source -target App_Target1 -name App_Map1 FlashCopy Mapping, id [4], successfully created
By using SVC 4.2.0, we can create multiple FlashCopy mappings for a single source VDisk. Here in Example 11-6, we create the second FlashCopy on DB_Source and Log_Source. Example 11-6: Create the second FlashCopy mapping for DB_Source and Log_Source
IBM_2145:ITSOSVC42A:admin>svctask mkfcmap -source DB_Source -target DB_Target2 -name DB_Map2 -consis FCCG2 FlashCopy Mapping, id [2], successfully created IBM_2145:ITSOSVC42A:admin>svctask mkfcmap -source Log_Source -target Log_Target2 -name Log_Map2 -con FCCG2 FlashCopy Mapping, id [3], successfully created
Example 11-7 shows the result of these FlashCopy mappings. The status of the mapping is idle_or_copied. Example 11-7: Check the result of Multi-Target FlashCopy mappings
IBM_2145:ITSOSVC42A:admin>svcinfo lsfcmap -delim : id:name:source_vdisk_id:source_vdisk_name:target_vdisk_id:target_vdisk_name:group_id:group_name:stat ress:copy_rate 0:DB_Map1:2:DB_Source:5:DB_Target1:1:FCCG1:idle_or_copied:0:50 1:Log_Map1:1:Log_Source:7:Log_Target1:1:FCCG1:idle_or_copied:0:50 2:DB_Map2:2:DB_Source:6:DB_Target2:2:FCCG2:idle_or_copied:0:50 3:Log_Map2:1:Log_Source:8:Log_Target2:2:FCCG2:idle_or_copied:0:50 4:App_Map1:0:App_Source:9:App_Target1:::idle_or_copied:0:50
If you would like to change the FlashCopy mapping, you can use the svctask chfcmap command. Type svctask chfcmap -h to get help. 11.4.4 Preparing (Pre-Triggering) the FlashCopy Mapping At this point the mapping has been created, but the cache is still accepting data for the source VDisks. You can only trigger the mapping when the cache does not contain any data for FlashCopy source VDisks. You must issue an svctask prestartfcmap command to prepare a FlashCopy mapping to start. This command tells SVC to flush the cache of any content for the source VDisk and to pass through any further write data for this VDisk. When svctask prestartfcmap is executed, the mapping enters the preparing state. After the preparation is complete, it changes to the prepared state. At this point, the mapping is ready for triggering. Preparing and the subsequent triggering is usually performed on a consistency group basis. Only mappings belonging to consistency group 0 can be prepared on their own, since consistency group 0 is a special group, which contains the FlashCopy mappings that do not belong to any consistency group. A FlashCopy must be prepared before it can be triggered. In our scenario, App_Map1 is not in a consistency group. In Example 11-8, we show how we initialize the preparation for App_Map1. Another option is that you add -prep parameter in svctask startfcmap command, which will first prepare the mapping, then start the FlashCopy. In the example we also show how to check the status of the current FlashCopy mapping. App_Map1's status is prepared. Example 11-8: Prepare a FlashCopy without consistency group
IBM_2145:ITSOSVC42A:admin>svctask prestartfcmap App_Map1 IBM_2145:ITSOSVC42A:admin>svcinfo lsfcmap -delim : id:name:source_vdisk_id:source_vdisk_name:target_vdisk_id:target_vdisk_name:group_id:group_ name:status:progress:copy_rate 0:DB_Map1:2:DB_Source:5:DB_Target1:1:FCCG1:idle_or_copied:0:50 1:Log_Map1:1:Log_Source:7:Log_Target1:1:FCCG1:idle_or_copied:0:50 2:DB_Map2:2:DB_Source:6:DB_Target2:2:FCCG2:idle_or_copied:0:50 3:Log_Map2:1:Log_Source:8:Log_Target2:2:FCCG2:idle_or_copied:0:50 4:App_Map1:0:App_Source:9:App_Target1:::prepared:0:50
11.4.5 Preparing (Pre-Triggering) the FlashCopy Consistency Group We use the command svctask prestartfcconsistsgrp to prepare a FlashCopy consistency group. As with 11.4.4, "Preparing (pre-triggering) the FlashCopy mapping" on page 453, this command flushes the cache of any data destined for the source VDisks and forces the cache into the write-through mode until the mapping is started. The difference is that this command prepares a group of mappings (at a consistency group level) instead of one mapping. When you have assigned several mappings to a FlashCopy consistency group, you only have to issue a single prepare command for the whole group to prepare all the mappings at once. Example 11-9 shows how we prepare the consistency groups for DB and Log and check the result. After the command has executed all the FlashCopy maps we have are all in prepared status, and all the consistency groups are in prepared status too. Now we are ready to start the FlashCopy. Example 11-9: Prepare a FlashCopy with consistency group
IBM_2145:ITSOSVC42A:admin>svctask prestartfcconsistgrp FCCG1 IBM_2145:ITSOSVC42A:admin>svctask prestartfcconsistgrp FCCG2
IBM_2145:ITSOSVC42A:admin>svcinfo lsfcmap -delim : id:name:source_vdisk_id:source_vdisk_name:target_vdisk_id:target_vdisk_name:group_id:group_ name:status:progress:copy_rate 0:DB_Map1:2:DB_Source:5:DB_Target1:1:FCCG1:prepared:0:50 1:Log_Map1:1:Log_Source:7:Log_Target1:1:FCCG1:prepared:0:50 2:DB_Map2:2:DB_Source:6:DB_Target2:2:FCCG2:prepared:0:50 3:Log_Map2:1:Log_Source:8:Log_Target2:2:FCCG2:prepared:0:50 4:App_Map1:0:App_Source:9:App_Target1:::prepared:0:50 IBM_2145:ITSOSVC42A:admin>svcinfo lsfcconsistgrp id name status 1 FCCG1 prepared 2 FCCG2 prepared
11.4.6 Starting (Triggering) FlashCopy Mappings The command svctask startfcmap is used to start a single FlashCopy mapping. When invoked, a PiT copy of the source VDisk is created on the target VDisk. When the FlashCopy mapping is triggered it enters the copying state. The way the copy proceeds depends on the background copy rate attribute of the mapping. If the mapping is set to 0 (NOCOPY), only data that is subsequently updated on the source will be copied to the destination. This operation means that the destination can only be used as a backup copy while the mapping exist in the copying state. If the copy is stopped, the destination will not be usable. If you want to end up with a duplicate copy of the source at the destination, you should set the background copy rate greater than 0. This means that the system copies all the data (even unchanged data) to the destination and eventually reaches the idle or copied state. After this data is copied, you can delete the mapping and have a usable point-in-time copy of the source at the destination. Immediately after the quiesce, we execute the command svctask startfcmap as shown in Example 11-10. After the FlashCopy is started, App_Map1 changes to copying status. Example 11-10: Start App_Map1
IBM_2145:ITSOSVC42A:admin>svctask startfcmap App_Map1 IBM_2145:ITSOSVC42A:admin>svcinfo lsfcmap -delim : id:name:source_vdisk_id:source_vdisk_name:target_vdisk_id:target_vdisk_name:group_id:group_ name:status:progress:copy_rate 0:DB_Map1:2:DB_Source:5:DB_Target1:1:FCCG1:prepared:0:50 1:Log_Map1:1:Log_Source:7:Log_Target1:1:FCCG1:prepared:0:50 2:DB_Map2:2:DB_Source:6:DB_Target2:2:FCCG2:prepared:0:50 3:Log_Map2:1:Log_Source:8:Log_Target2:2:FCCG2:prepared:0:50 4:App_Map1:0:App_Source:9:App_Target1:::copying:0:50
11.4.7 Starting (Triggering) FlashCopy Consistency Group We execute the command svctask startfcconsistgrp as shown in Example 11-11, and afterwards the database can be resumed. We have created two PiT consistent copies of the DB and Log VDisks. After execution, the status of consistency group and FlashCopy maps are all in copying status. Example 11-11: Start FlashCopy consistency group
IBM_2145:ITSOSVC42A:admin>svctask startfcconsistgrp FCCG1 IBM_2145:ITSOSVC42A:admin>svctask startfcconsistgrp FCCG2 IBM_2145:ITSOSVC42A:admin>svcinfo lsfcconsistgrp id name status 1 FCCG1 copying 2 FCCG2 copying IBM_2145:ITSOSVC42A:admin>svcinfo lsfcmap -delim :
id:name:source_vdisk_id:source_vdisk_name:target_vdisk_id:target_vdisk_name:group_id:group_ name:status:progress:copy_rate 0:DB_Map1:2:DB_Source:5:DB_Target1:1:FCCG1:copying:6:50 1:Log_Map1:1:Log_Source:7:Log_Target1:1:FCCG1:copying:6:50 2:DB_Map2:2:DB_Source:6:DB_Target2:2:FCCG2:copying:6:50 3:Log_Map2:1:Log_Source:8:Log_Target2:2:FCCG2:copying:6:50 4:App_Map1:0:App_Source:9:App_Target1:::copying:19:50
11.4.8 Monitoring the FlashCopy Progress To monitor the background copy progress of the FlashCopy mappings, we issue the command svcinfo lsfcmapprogress for each FlashCopy mapping. Alternatively, the copy progress can also be queried using the command svcinfo lsfcmap. As shown in Example 1112, both DB_Map1 and Log_Map1 return that the background copy has completed 21%, both DB_Map2 and Log_Map2 return that the background copy has completed 18%. Example 11-12: Monitoring background copy progress
IBM_2145:ITSOSVC42A:admin>svcinfo id progress 0 21 IBM_2145:ITSOSVC42A:admin>svcinfo id progress 1 21 IBM_2145:ITSOSVC42A:admin>svcinfo id progress 2 18 IBM_2145:ITSOSVC42A:admin>svcinfo id progress 3 18 IBM_2145:ITSOSVC42A:admin>svcinfo id progress 4 50 lsfcmapprogress DB_Map1
lsfcmapprogress Log_Map1
lsfcmapprogress DB_Map2
lsfcmapprogress Log_Map2
lsfcmapprogress App_Map1
When the background copy has completed, the FlashCopy mapping enters the idle_or_copied state, and when all FlashCopy mappings in a consistency group enter this status, the consistency group will be at idle_or_copied status. When in this state the FlashCopy mapping can be deleted, and the target disk can be used independently, if, for example, another target disk is to be used for the next FlashCopy of the particular source VDisk. 11.4.9 Deleting the FlashCopy Mapping To delete a FlashCopy mapping, we use the command svctask rmfcmap. When the command is executed, it attempts to delete the FlashCopy mapping specified. If the FlashCopy mapping is stopped, the command fails unless the -force flag is specified. If the mapping is active (copying), then it must first be stopped before it can be deleted. Deleting a mapping only deletes the logical relationship between the two VDisks. However, when issued on an active FlashCopy mapping applying the -force flag, the delete renders the data on the FlashCopy mapping target VDisk as inconsistent. TipIf you want to use the target VDisk as normal VDisks. You can monitor the background copy progress until it is complete (100% copied), and then delete the FlashCopy mapping. Another option is to set -autodelete option when create the FlashCopy mapping. As shown in Example 11-13, we delete App_Map1. Example 11-13: Delete App_Map1
IBM_2145:ITSOSVC42A:admin>svctask rmfcmap App_Map1
IBM_2145:ITSOSVC42A:admin>svcinfo lsfcmap -delim : id:name:source_vdisk_id:source_vdisk_name:target_vdisk_id:target_vdisk_name:group_id:group_ name:status:progress:copy_rate 0:DB_Map1:2:DB_Source:5:DB_Target1:1:FCCG1:idle_or_copied:100:50 1:Log_Map1:1:Log_Source:7:Log_Target1:1:FCCG1:idle_or_copied:100:50 2:DB_Map2:2:DB_Source:6:DB_Target2:2:FCCG2:idle_or_copied:100:50 3:Log_Map2:1:Log_Source:8:Log_Target2:2:FCCG2:idle_or_copied:100:50
11.4.10 Deleting the FlashCopy Consistency Group The command svctask rmfcconsistgrp is used to delete a FlashCopy consistency group. When executed, this command deletes the consistency group specified. If there are mappings that are members of the group, the command fails unless the -force flag is specified. If you want to delete all the mappings in the consistency group as well, you must first delete the mappings, and then delete the consistency group. As shown in Example 11-14, we delete all the maps and consistency groups., and then we check the result. Example 11-14: Delete FCCG1 and FCCG2
IBM_2145:ITSOSVC42A:admin>svctask rmfcmap DB_Map1 IBM_2145:ITSOSVC42A:admin>svctask rmfcmap DB_Map2 IBM_2145:ITSOSVC42A:admin>svctask rmfcmap Log_Map1 IBM_2145:ITSOSVC42A:admin>svctask rmfcmap Log_Map2 IBM_2145:ITSOSVC42A:admin>svctask rmfcconsistgrp FCCG1 IBM_2145:ITSOSVC42A:admin>svctask rmfcconsistgrp FCCG2 IBM_2145:ITSOSVC42A:admin>svcinfo lsfcconsistgrp IBM_2145:ITSOSVC42A:admin>svcinfo lsfcmap
11.4.11 Stopping the FlashCopy Mapping The command svctask stopfcmap is used to stop a FlashCopy mapping. This command allows you to stop an active (copying) or suspended mapping. When executed, this command stops a single FlashCopy mapping. When a FlashCopy mapping is stopped, the target VDisk becomes invalid and is set offline by the SVC. The FlashCopy mapping needs to be prepared again, or re-triggered to bring the target VDisk online again. TipIn a multi-target FlashCopy environment if you want to stop a mapping or group, consider whether you want to keep any of the dependent mappings. If not you should issue the stop command with the force parameter, this will stop all of the dependent maps too and negate the need for the stopping copy process to run. NoteStopping a FlashCopy mapping should only be done when the data on the target VDisk is of no use, or you want to modify the FlashCopy mapping. When a FlashCopy mapping is stopped, the target VDisk becomes invalid and is set offline by the SVC, if the mapping is in the copying state and progress !=100. As shown in Example 11-15, we stop App_Map1 FlashCopy. The status of App_Map1 has changed to idle_or_copied. Example 11-15: Stop APP_Map1 FlashCopy
IBM_2145:ITSOSVC42A:admin>svctask stopfcmap App_Map1 IBM_2145:ITSOSVC42A:admin>svcinfo lsfcmap -delim : id:name:source_vdisk_id:source_vdisk_name:target_vdisk_id:target_vdisk_name:group_id:group_ name:status:progress:copy_rate 0:DB_Map1:2:DB_Source:5:DB_Target1:1:FCCG1:idle_or_copied:100:50
1:Log_Map1:1:Log_Source:7:Log_Target1:1:FCCG1:idle_or_copied:100:50 2:DB_Map2:2:DB_Source:6:DB_Target2:2:FCCG2:idle_or_copied:100:50 3:Log_Map2:1:Log_Source:8:Log_Target2:2:FCCG2:idle_or_copied:100:50 4:App_Map1:0:App_Source:9:App_Target1:::idle_or_copied:100:50
11.4.12 Stopping the FlashCopy Consistency Group The command svctask stopfcconsistgrp is used to stop any active FlashCopy consistency group. It stops all mappings in a consistency group. When a FlashCopy consistency group is stopped for all mappings that are not 100% copied, the target VDisks become invalid and are set offline by the SVC. The FlashCopy consistency group needs to be prepared again and restarted to bring the target VDisks online again. NoteStopping a FlashCopy mapping should only be done when the data on the target VDisk is of no use, or you want to modify the FlashCopy consistency group. When a consistency group is stopped, the target VDisk might become invalid and set offline by the SVC depending on the state of the mapping. As shown in Example 11-16, we stop FCCG1 and FCCG2 consistency groups. The status of the two consistency groups has changed to stopped. All mapping relations now show as idle_or_copied. Example 11-16: Stop FCCG1 and FCCG2 consistency group
IBM_2145:ITSOSVC42A:admin>svctask stopfcconsistgrp FCCG1 IBM_2145:ITSOSVC42A:admin>svctask stopfcconsistgrp FCCG2 IBM_2145:ITSOSVC42A:admin>svcinfo lsfcconsistgrp id name status 1 FCCG1 stopped 2 FCCG2 stopped IBM_2145:ITSOSVC42A:admin>svcinfo lsfcmap -delim : id:name:source_vdisk_id:source_vdisk_name:target_vdisk_id:target_vdisk_name:group_id:group_ name:status:progress:copy_rate 0:DB_Map1:2:DB_Source:5:DB_Target1:1:FCCG1:idle_or_copied:100:50 1:Log_Map1:1:Log_Source:7:Log_Target1:1:FCCG1:idle_or_copied:100:50 2:DB_Map2:2:DB_Source:6:DB_Target2:2:FCCG2:idle_or_copied:100:50 3:Log_Map2:1:Log_Source:8:Log_Target2:2:FCCG2:idle_or_copied:100:50 4:App_Map1:0:App_Source:9:App_Target1:::idle_or_copied:100:50
11.5 Using the GUI to Perform FlashCopy In the following example we will use the same scenario as described in 11.4.1, "Scenario description" on page 450. We will follow the same procedures to perform the task using the GUI. 11.5.1 Creating a FlashCopy Consistency Group The first step is to create our FlashCopy consistency group for our VDisk1 and VDisk2 disks. In the SVC GUI expand Manage Copy Services in the Task pane and select FlashCopy Consistency Groups. When prompted for filtering, we select Bypass Filter. (This will then show us all the defined consistency groups, if there were any created previously.) Then, from the drop down list, we select Create a Consistency Group and Go; this can be seen in Figure 11-11.
Figure 11-11: Create consistency group Enter the desired name, then click OK (Figure 11-12).
Figure 11-12: Create consistency group Click Close when finished (Figure 11-13).
Figure 11-13: Create consistency group Check the result (Figure 11-14).
Figure 11-14: View consistency group Repeat the previous steps to create another FC consistency group (Figure 11-15). The FlashCopy consistency groups are now ready to use.
Figure 11-15: View consistency group 11.5.2 Creating a FlashCopy Mapping We will create the FlashCopy mappings for each of our VDisks to their respective targets. In the SVC GUI, we expand Manage Copy Services in the Task panel and select FlashCopy mappings. When prompted for filtering, we select Bypass Filter. (This will then show us all the defined FlashCopy mappings, if there were any created previously.) As shown in Figure 11-16, we select Create a Mapping from the scroll menu and click Go to start the creation process of a FlashCopy mapping.
Figure 11-16: Create FC mapping We are then presented with the FlashCopy creation wizard overview of the creation process for a FlashCopy mapping, as shown in Figure 11-17, and click Next to proceed.
Figure 11-17: Create FC mapping As shown in Figure 11-18, we name the first FlashCopy mapping DB_Map1, we select the previously created consistency group FCCG1, we set the background copy priority to 50%, and click Next to proceed.
Figure 11-18: Create FC mapping The next step is to select the source VDisk. If there were many source VDisks (that weren't already defined in a FlashCopy mapping), then we can filter that list here. In Figure 11-19, we define the filer * (which will show us all our VDisks) for the source VDisk and click Next to proceed.
Figure 11-19: Create FC mapping We select DB_Source as the source disk and click Next to proceed (Figure 11-20).
Figure 11-20: Create FC mapping The next step is to select our target VDisk. The FlashCopy mapping wizard will only present a list of VDisks that are the same size as the source VDisks and not already in a FlashCopy mapping, nor defined in a Metro Mirror relationship. In Figure 11-21, we select the target DB_Target1 and click Next to proceed.
Figure 11-21: Create FC mapping Finally, we verify our FlashCopy mapping (Figure 11-22) and click Finish to create it.
Figure 11-22: Create FC mapping We check the result of this creation, as shown in Figure 11-23.
Figure 11-23: View FC mapping We repeat the procedure to create other FC mappings on the second FlashCopy target VDisk of DB_Source. We would give it a different FC mapping name and choose a different FC consistency group as shown in Figure 11-24. In this example, we did not check the option, Automatically delete mapping when the background copy completes.
Figure 11-24: Create FC mapping In Figure 11-25, you can see that DB_Source is still available to choose.
Figure 11-25: Create FC mapping We select DB_Target2 as the destination VDisk as shown in Figure 11-26.
Figure 11-26: Create FC mapping At the last page of the wizard as shown in Figure 11-27, we click Finish after verifying all the parameters.
Figure 11-27: Create FC mapping We repeat the previous steps to create an FC mapping for Log_Source and Log_Target1, and also create an FC mapping for Log_Source and Log_Target2. We check the result in Figure 11-29.
Figure 11-28: View FC mapping When creating the FC mapping for App_Source, we mark the check box, Automatically delete mappings when the background copy completes. This is shown in Figure 11-29.
Figure 11-29: Create FC mapping We confirm the parameter settings by clicking Finish as seen in Figure 11-30.
Figure 11-30: Create FC mapping After the FlashCopy mapping is successfully created, we are returned to the FlashCopy mapping list (Figure 11-31) and we are presented with all the currently defined FlashCopy mappings.
Figure 11-31: View FC mapping Click each mapping's name to check the parameters as seen in Figure 11-32.
Figure 11-32: Check FC mapping properties If no consistency group is defined, the mapping is assigned into the default consistency group 0. This is a special group that cannot be started as a whole. Mappings in this group can only be started on an individual basis. The background copy rate specifies the priority that should be given to complete the copy. If 0 is specified, the copy will not proceed in the background. The default is 50. TipFlashCopy can be invoked from the SVC graphical user interface (GUI), but this might not make much sense if you plan to handle a large number of FlashCopy mappings or consistency groups periodically, or at varying times. In this case, creating a script by using the CLI may be more convenient. 11.5.3 Preparing (Pre-Triggering) the FlashCopy Mapping At this point the mapping has been created but the cache is still accepting data for the source VDisks. To ensure a
consistent data set is created, it is crucial to flush application and OS buffers, and quiesce the application. To do this, we need to integrate our SVC commands into host scripts. NoteA FlashCopy must be prepared before it can be triggered. In Figure 11-33, we select the FlashCopy mapping which is not in consistency group, select Prepare a mapping from the action list and click Go. The status will go to Preparing, and then finally to Prepared. Press the Refresh button several times until it is in the Prepared state.
Figure 11-33: Prepare a FC mapping Check the mapping status. As shown in Figure 11-34, App_Map1 status is changed from Idle_or_Copied to Prepared.
Figure 11-34: Check the status of FC mapping 11.5.4 Preparing (Pre-Triggering) the FlashCopy Consistency Group When performing the FlashCopy on the VDisks with the database, we want to be able to control the PiT when the FlashCopy is triggered, in order to keep our quiesce time at a minimum and keep the data integrity. We put the VDisks in a consistency group, then we will prepare the consistency group in order to flush the cache for all source VDisks. When you have assigned several mappings to a FlashCopy consistency group, you only have to issue a single prepare command for the whole group, to prepare all the mappings at once. In Figure 11-35, we select the FlashCopy consistency group and Prepare a consistency group from the action list and
click Go. The status will go to Preparing, and then finally to Prepared. Press the Refresh button several times until it is in the Prepared state.
Figure 11-35: Prepare FC consistency group. Figure 11-36 shows how we check the result. The status of the consistency group has changed to Prepared.
Figure 11-36: Check the status of a consistency group 11.5.5 Starting (Triggering) FlashCopy Mappings When the FlashCopy mapping enters the Prepared state, we can start FlashCopy. As shown in Figure 11-37, we select the FlashCopy mapping App_Map1, select Start a Mapping from the scroll menu, and click Go to proceed.
Figure 11-37: Selecting a single mapping to be started Because we have already prepared the FlashCopy mapping, the prepare box is grayed out, as shown in Figure 11-38, and we click OK to start the FlashCopy mapping.
Figure 11-38: Starting FlashCopy Mapping App_Map1 11.5.6 Starting (Triggering) FlashCopy Consistency Group As shown in Figure 11-39, the FlashCopy consistency group enters the prepared state. To start the FlashCopy consistency group, we select the consistency group and select Start a Consistency Group from the scroll menu and click Go.
Figure 11-39 In Figure 11-40, we are prompted to confirm starting the FlashCopy consistency group. We now flush the database and OS
buffers and quiesce the database, then click OK to start the FlashCopy consistency group.
Figure 11-40: Starting a FC consistency group NoteSince we have already prepared the FlashCopy consistency group, this option is grayed out when prompted to confirm starting the FlashCopy consistency group. As shown in Figure 11-41, we verified that the consistency group is in the Copying state, and subsequently, we resume the database I/O.
Figure 11-41: Consistency group status 11.5.7 Monitoring the FlashCopy Progress To monitor the copy progress, you can click the Refresh button (Figure 11-42).
Figure 11-42: Check the background copy progress of consistency group TipsEven if you click the Refresh button several times, the SVC only updates the progress of the background copy once a minute. Another option is to select Manage Progress, then FlashCopy, then you can monitor the progress. This is shown in Figure 11-43.
Figure 11-43: Monitor background copy progress When the background copy is completed for all FlashCopy mappings in the consistency group, the status is changed to Idle or Copied. 11.5.8 Deleting the FlashCopy Mapping As we have already enabled the function of automatically delete the FC mapping when background copy process finished, shown in Figure 11-44, App_Map1 has already been deleted.
Figure 11-44: Autodelete result 11.5.9 Deleting the FlashCopy Consistency Group If you want to delete all the mappings in the consistency group as well, you first delete the mappings, then delete the consistency group. TipIf you want to use the target VDisks in a consistency group as normal VDisks, you can monitor the background copy progress until it is complete (100% copied), and then delete the FlashCopy mapping. As shown in Figure 11-45, we delete all the maps and consistency groups and then check the result.
Figure 11-45: Deleted a map Confirm the delete by clicking OK.(Figure 11-46).
Figure 11-46: confirm the deletion of map

We repeat the above two steps to delete all FC mappings in the FCCG1 consistency group. Then, we can delete the consistency group as shown in Figure 11-47.
Figure 11-47: delete a consistency group If you delete the consistency group before deleting all the FC mappings in it, you will be prompted for a forced deletion. As shown in Figure 11-48, we chose to delete FCCG2 directly.
Figure 11-48: delete a consistency group directly There is a prompt for you to confirm. Once you click Force Delete (Figure 11-49) the consistency group will be deleted.
Figure 11-49: Force delete 11.5.10 Stopping the FlashCopy/Consistency Group When a FlashCopy consistency group is stopped, the target VDisks become invalid and are set offline by the SVC. The
FlashCopy mapping or consistency group needs to be prepared again or re-triggered to bring the target VDisks online again. TipIn a multi-target FlashCopy environment if you want to stop a mapping or group, consider whether you want to keep any of the dependent mappings. If not, you should issue the stop command with the force parameter; this will stop all of the dependent maps too and negate the need for the stopping copy process to run. NoteStopping a FlashCopy mapping should only be done when the data on the target VDisk is of no use, or you want to modify the FlashCopy mapping. When a FlashCopy mapping is stopped, the target VDisk becomes invalid and is set offline by the SVC, if the mapping is in the copying state and progress !=100. As shown in Figure 11-50, we stop FCCG1 and FCCG2 consistency groups. All mapping relations now show as idle_or_copied.
Figure 11-50: Stop a consistency group We click the Force Stop button to proceed as shown in Figure 11-51.
Figure 11-51: Stop FlashCopy consistency group The status of the FlashCopy consistency groups is Stopped, as shown in Figure 11-52.
Figure 11-52: FlashCopy consistency group status We have now completed the task with the FlashCopy GUI.

Chapter 11 Copy Services Flash

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 11 Copy Services Flash

Uploaded by

Copyright:

Available Formats

IBM System Storage SAN Volume Controller

by Jon Tate et al. IBM Corporation. (c) 2007. Copying Prohibited.

Reprinted for Deepak Sibal, IBM deesibal@in.ibm.com

Chapter 11: Copy Services: FlashCopy

Page 2 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

SVC 4.2 has several enhancement to the FlashCopy functions.

svctask mkfcmap -source App_Source -target App_Target1 -name App_Map1 -autodelete

Page 3 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Page 4 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Page 5 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Page 6 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Figure 11-5: FlashCopy consistency group

Page 8 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

The state of an internal data structure, the FlashCopy bitmap

Page 9 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Read to Target VDisk

Page 13 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Special FlashCopy Events

Here we describe some special FlashCopy events:

Page 17 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Path Failure (Path Offline State)

Page 19 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Page 21 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Figure 11-10: FlashCopy scenario using the CLI

DB_Source, DB_Target1, DB_Target2 Log_Source, Log_Target1, Log_Target2 App_Source, App_Target1

Named FCCG1 Named FCCG2

2. Create FlashCopy mapping for Source VDisks:

Page 22 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Page 23 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Page 25 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Page 26 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Page 27 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

1:Log_Map1:1:Log_Source:7:Log_Target1:1:FCCG1:idle_or_copied:100:50 2:DB_Map2:2:DB_Source:6:DB_Target2:2:FCCG2:idle_or_copied:100:50 3:Log_Map2:1:Log_Source:8:Log_Target2:2:FCCG2:idle_or_copied:100:50 4:App_Map1:0:App_Source:9:App_Target1:::idle_or_copied:100:50

Page 28 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Page 29 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Page 30 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Page 31 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Page 32 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Page 33 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Page 34 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Page 35 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Page 36 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Page 37 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Page 38 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Page 40 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Page 41 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Page 42 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Page 43 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Page 44 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Figure 11-46: confirm the deletion of map

Page 47 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

Page 48 / 48 Reprintedforibm\deesibal@in.ibm.com,IBM IBMCorporation,InternationalBusinessMachinesCorporation(c)2007,CopyingProhibited

You might also like