HP StorageWorks Storage Mirroring scripting guide (T2558-96074, February 2008)

7 - 9
Inserting tasks during replication
Task command processing is a Storage Mirroring feature that allows you to insert and run tasks at various points during the
replication of data. Because the tasks are user-defined, you can achieve a wide variety of goals with this feature. For example,
you might insert a task to create a snapshot or run a backup on the target after a certain segment of data from the source has
been applied on the target. This allows you to coordinate a point-in-time backup with real-time replication.
Task command processing can be enabled from the Management Console, but it can only be initiated through the Storage
Mirroring text clients or a DTCL script.
If you disable this option on a source server, you can still submit tasks to be processed on a target, although task command
processing must be enabled on the target.
Because Storage Mirroring replication follows the same write sequence within and across multiple files, it provides complete
data integrity at all times. At any given moment, the target represents a single point in time from the source, which makes the
target crash consistent. But for some applications, crash consistency may not be adequate. You may require that the source
data be in a quiescent (latent) state, similar to an application checkpoint. You need to be able to identify when the application
is stable, which is usually when all of the data has been written to disk. This can be triggered by stopping the service. With
task command processing, you can stop the source service just long enough to identify that stopped point in time as a stable
state, insert a task at that point into the Storage Mirroring replication queue to trigger a backup or snapshot on the target,
and then restart the service. Here is how the process would work.
1. Storage Mirroring and an application are both running on the source. Only Storage Mirroring is running on the target.
2. The application data is changing on the source and Storage Mirroring is capturing those data changes and transmitting
them to the target.
3. A script is launched (either manually or perhaps scheduled by the Windows Scheduler) that stops the application service
on the source, pauses to give the service time to shutdown and write the data to disk, initiates a Storage Mirroring task
command, and then restarts the application service on the source.
4. The Storage Mirroring task command is transmitted, inline with the source replication data, to the target.
5. The data is applied on the target as it is received. Since the task command was inserted inline, the replication data from
the source is applied to the target first. When the target gets to the Storage Mirroring task command, the target data
will be in the exact same state as the source data when the source application service was stopped. Since this was a
stable point on the source, it is also a stable point on the target.
6. The target processes the Storage Mirroring task command and completes whatever task is defined, perhaps a snapshot
or backup. Since the Storage Mirroring task command is user-defined, you can insert any valid executable or batch file.
Storage Mirroring task command processing must be enabled, and there must be an active Storage Mirroring connection for
task command processing to function properly. To insert a task command, you would use the
queuetask command. The
syntax of the queuetask command is provided on the following pages. Also, see Creating a backup or snapshot of the target by
inserting a task command during replication
on page 14-4 for a sample script which can be used as a basis for creating a script
for your own environment.
Command
QUEUETASK
Description Queues tasks inline with replication data.
Syntax
QUEUETASK <job_name> TO <target> ONQUEUE = <task> [args] | ONTRANSMIT = <task> [args]
|
ONRECEIVE = <task> [args] | ONEXECUTE = <task> [args] [TIMEOUT = <timeout>]
[
INTERACT | NOINTERACT]