Before you use the point-in-time copy and remote mirror
and copy features of Copy Services, review the guidelines and requirements
for managing a Copy Services environment.
You must obtain the
activation keys that you need to activate the Copy Services licenses
from the IBM® Disk Storage Feature Activation (DSFA) website
at: Data storage feature activation.
After you obtain the activation keys,
add them in the DS Storage Manager.
To add activation keys, select, in the navigation, .
You can use the
DS CLI or
DS Storage Manager to
complete Copy Services tasks.
Note: For
a list of Copy Services commands, see the Command-line interface section
of the
IBM DS8000® series online product
documentation. For a list of Copy Services tasks that
are available in the
DS Storage Manager,
see the Managing section.
The following rules apply when
you are using Copy Services functions:
- One or more storage units must be assigned. Ensure that
one or more storage units are configured, assigned, and operating
in a normal state. The number
of required storage units depends on the function. For example, FlashCopy® operations require one storage
unit, but Metro Mirror and Global Mirror require two.
Note: If you
plan to use Remote FlashCopy (known as Inband FlashCopy commands on the ESS 2105), two
storage units are required for this configuration.
- Physical connection must be established between two storage
units. If you plan to use remote mirror and copy functions, such
as Metro Mirror, Global Copy, or Global Mirror), ensure that a physical
connection is established between two storage units. Two (or more)
storage units can be connected through a Fibre Channel direct connection
or through a switch. To connect the storage units, ensure that you
have one cable from c0 to c0 and one from c1 to c1, for example, and
that you have the correct port topology configuration for those connections.
To configure I/O ports, select, in the navigation, .
- Logical configuration must be created. Consider the following
requirements:
- Volume capacity: Ensure that the capacity of your target
volumes is equal to or greater than your source volumes. When you
select target volumes from the DS Storage Manager,
it verifies that the capacities of the target volumes are at least
as big as the source volumes. It does not allow you to select smaller-sized
target volumes.
Note: Be aware that for failover and failback operations
to complete successfully, the volumes must be the same size and type.
- Volume quantity: Ensure that you have at least one target
volume for each source volume that is of equal or greater capacity
than the source volume.
- Volume sizes: Capacities of the volume are configured
based on the following conventions:
- Decimal
- 1 GB (10 9) = 1,000,000,000 bytes (ESS 2105 volumes
are configured in decimal format.)
- Binary
- 1 GiB (2 30) = 1,073,741,824 bytes (DS volumes are
configured in binary format.)
This method provides volumes that
fully use the capacity in every extent.
- Block
- 1 GiB = (2 30) = 1,073,741,824 (IBM i volumes
are configured in this format.)
This method supports volume capacity
in bytes (512-byte logical blocks). Supported storage sizes range
1- 4 GiB blocks (the actual number of gigabytes is the number of blocks
times 512).
Note: You must consider the gigabyte definitions. In
many applications, the source and target of a remote mirror and copy
relationship must be the same size. For example, if you plan to use
volumes from different storage systems (DS8000 and ESS 2105) for remote mirror
and copy functions, the volumes on the DS8000 storage system must be created
in decimal format to be compatible with ESS volumes.
- Logical subsystem: You can configure up
to 256 volumes per LSS. Each LSS is made up of either CKD or FB volumes.
An LSS that consists of CKD addresses requires that other LSSs also
consist of CKD addresses. You can have both CKD and FB LSSs on the
same storage unit.
Note: CKD LSSs are referred to as LCUs in the DS Storage Manager.
- Mirroring connectivity must be created: You
must define mirroring connectivity for Metro Mirror, Global Copy,
and Global Mirror functions. Fibre Channel is used as the communications
link between source and target volumes. To create mirroring connectivity,
select, in the navigation, . From
the Action menu, select Create....
- Create volume pairs: Determine which
source and target volumes you want to pair for Copy Services relationships.
To create volume pairs, select, in the navigation, . From the Action menu, select Create.
Metro/Global Mirror If you
plan to implement a Metro/Global Mirror configuration, the three-site
disaster recovery solution, you can set up and manage your configuration
with the DS CLI,
Time Sharing Option/Extended (TSO/E), or ANTRQST API commands.
Global
Mirror limitation:
If you plan to use Global
Mirror (previously known as Extended Remote Copy or XRC), be aware
that a Global
Mirror environment that includes a primary DS8000 storage
system and a secondary DS6000™ should not be used for
failover and failback operations because of the following limitations:
- Performance mismatch (mirroring)
- If the secondary DS6000 storage system and its
connection to the System Data Mover (SDM) that runs on Global Mirror is less
capable (lower performing) than the primary storage system and its
connection to the application systems, the overall Global Mirror performance
might suffer degraded performance. That is, if applications can write
faster to primary storage units than the SDM can write to the secondary
storage units, then implementation problems result. (The SDM is the
function that copies data from the primary storage unit to the auxiliary
storage unit in a Global
Mirror environment.)
- Performance mismatch (running applications)
- Suppose that a disaster or failure occurs and applications failover
to the secondary (or recovery) site and are running on the secondary
storage units. If the secondary storage unit (the DS6000)
is less capable (performance-wise) than the primary storage unit,
it is likely that primary business applications will not complete
in the required or expected time frame.
- z/OS® Global Mirror-capable local (or primary)
storage units
- Suppose that a disaster or failure occurs in a z/OS Global
Mirror environment and applications failover to the secondary site
and are running at the secondary site on the secondary storage units.
Later, after the primary site was repaired and is ready to resume
as the primary site, the secondary storage unit can then use z/OS Global
Mirror to failback to the primary site. However, for the failover
and failback operations to work successfully, the secondary storage
unit must be a z/OS Global Mirror-capable primary storage unit,
which means it must be able to serve as a z/OS Global
Mirror primary storage unit. The DS6000 does
not have the appropriate microcode functionality to serve as a z/OS Global
Mirror-capable primary storage unit, and therefore cannot be used
to failback to the primary site.
General considerations: - If you plan to issue DS8000 commands, you must have
the DS CLI prompt
and be connected to a storage system that is used for open systems
or System z® host
system storage. The DS CLI helps
enable open systems hosts to start and manage FlashCopy and
remote mirror and copy operations through batch processes and scripts.
For more information, see the Command-line interface section of the IBM DS8000 series online documentation.
Note: For
more complex Copy Services environments, you might find managing Copy
Services functions is easier with the DS CLI than
with the DS Storage Manager.
With the DS CLI,
you can save commands as scripts, which significantly reduce the time
to create, edit, and verify their content.
- When you start a FlashCopy with the Initiate
background copy option enabled, the FlashCopy relationship
is established, but put in a queue for background copying. The time
that the background copying starts for the specific relationship depends
on the number of FlashCopy volumes that are already background
copying or are waiting to begin. When the copy starts, the status
displays as "background copy running" for that FlashCopy volume
pair.
How long the actual physical copy takes can depend on the
amount of data that is copied and other activity that is occurring
on the storage unit. For more details on monitoring when the copy
completes, see information about viewing FlashCopy relationships.
- Be aware of some FlashCopy data consistency
considerations. For example, there are environments where data is
stored in server memory cache and written to disk at some later time.
Buffers for a database management subsystem (DBMS) or metadata for
a journaled file system are two examples of these environments. If
a FlashCopy operation copies a source volume
to a target volume, but buffers from the DBMS or metadata from the
journaled file system are not flushed first, you might have to run
an incremental update. For a DBMS, you might have to back out of current
transactions. For a journaled file system, you might have to run the fsck utility
on the target volume.
To avoid these types of restart actions,
ensure that all data that is related to the FlashCopy source
volume is written to disk before you run the FlashCopy operation.
For a DBMS, you can quiesce the subsystem or use a DBMS command such
as LOG SUSPEND for DB2. For a journaled file system, you can unmount
the source volume before you run a FlashCopy operation.
- For FlashCopy operations: If you are going
to automate your FlashCopy procedures, consider verifying
the data consistency on your target volumes frequently. On some systems,
such as AIX®, Windows,
and Linux, before you run FlashCopy operations,
you must quiesce your applications that access FlashCopy source
volumes. The source volumes must then be unmounted during the FlashCopy establishment. This step will
ensure that there is no data in the buffers that might be flushed
to the target volumes and potentially corrupt them.
- You can use Global Mirror to
create consistent copies of your data at a secondary site, with minimal
impact to the local (or primary) site. Global Mirror uses
the concept of sessions to internally manage data consistency
across storage units. You can also use Metro Mirror, Global Copy,
and FlashCopy (without Global Mirror)
to create data consistency. However, this requires that you use either
external automated software or manually suspend your applications
at the local site to create consistency at your recovery (or secondary)
site.
- The DS Storage Manager can
be used for most Copy Services functions. However, you cannot complete
the following functions in the DS Storage Manager (they
are available only through the DS CLI):
- FlashCopy consistency groups
- Consistency group commands allow the storage unit to freeze I/O
activity to a LUN or volume until you issue the FlashCopy consistency
group command. Consistency groups help create a consistent point-in-time
copy across multiple LUNs or volumes, and even across multiple storage
units.
- Remote FlashCopy (known as Inband FlashCopy commands
on the ESS 2105)
- Remote FlashCopy commands are issued to a source
volume of a remote mirror and copy volume pair on a local storage
unit and sent across paths (acting as a conduit) to a remote storage
unit to enable a FlashCopy pair to be established at the
remote site. This eliminates the need for a network connection to
the remote site solely for the management of FlashCopy.
- If you pursue scenarios that call for freeze and run operations
for remote mirror and copy operations, you must issue these requests
from the command-line interface, together with external automated
software. These requests are not supported by the DS Storage Manager.
(Automation software is not provided with the storage unit; it must
be supplied by the user. However, IBM has
offerings to assist with this automation. For more information, contact
your IBM storage representative.)