| ETERNUS SF AdvancedCopy Manager Operator's Guide 13.0 -AIX- |
|
Contents
Index
|
This chapter explains AdvancedCopy Manager replication in an AIX system.
AIX version AdvancedCopy Manager's Agent enables the replication operation described in this chapter by linking with AdvancedCopy Manager's Manager running under Windows, Solaris or Linux. The actual unit for backup and restoration in an AIX system is a physical disk (LU: Logical Unit), but the unit for management and operation is a volume group.
This chapter explains the AdvancedCopy Manager replication function.
Using the advanced copy (OPC/EC or ROPC/REC) function of a disk array unit, the AdvancedCopy Manager replication function performs high-speed replication between volumes, regardless of the volume capacities.
Snapshot replication is replication that uses the One Point Copy (OPC) or Remote One Point Copy (ROPC) function of a ETERNUS storage system disk array unit. Replication that uses the Equivalent Copy (EC) or Remote Equivalent Copy (REC) function is called synchronized replication.
The replication function creates copies so that the information at a certain point of time can be used for different purposes. It can be used independently of or combined with the backup function.
Replicas are created by copying from an original volume to a replica volume using the OPC or ROPC function of a ETERNUS storage system disk array unit.
The snapshot replication performs the following two types of processing:
When a copy is created, the snapshot processing (OPC or ROPC) from the original volume to the replica volume is executed with the replication creation command (swsrpmake). The replication creation command dismounts or mounts the original volume. This processing determines the original data (for details, refer to "Preprocessing and Postprocessing of Replication"). ((1) to (4) in Figure 7.1)
If the user wants to re-create a replica, only the replication creation command is required. If the previous snapshot processing is in progress, it is stopped and new snapshot processing is started.
Snapshot replication is completed when the replication creation command is issued. The actual data is internally copied by the OPC or ROPC function of the ETERNUS storage system disk array unit.
Disk array devices must support the ROPC function in order to use it in the Advanced Copy function snapshot replication.
If the disk array supports the QuickOPC function, differential snapshot replication can be performed.
The QuickOPC function copies only the data generated after the previous physical copy. Snapshot high-speed backup using the differential function is called differential snapshot replication.
Ordinary snapshot replication performs a physical copy of the entire source volume to the destination volume every time replication (OPC) is activated. However, differential snapshot replication performs the copies only the data generated after the previous physical copy, which can greatly reduce physical copy time.
The comparison between ordinary snapshot replication and differential snapshot replication is shown below.
To execute differential snapshot replication using the QuickOPC function, hardware that supports the QuickOPC function is required.
The QuickOPC function can be used only for copying within a cabinet (OPC). The function cannot be used for copying between cabinets (ROPC).
The QuickOPC function also cannot be used for replicating SDX objects in the units of logical volumes.
Hardware using the QuickOPC function records the updates made to the copy source or destination after the completion of OPC logical copying. The status in which the hardware records updates is referred to as the "tracking status."
SnapOPC is a function that enables only data that has been updated to the copy source disk area since a certain point in time (logical copy) to be copied to the copy destination disk area.
Comparison of the ordinary snapshot replication (Normal OPC), the QuickOPC snapshot replication (QuickOPC), and the SnapOPC snapshot replication (SnapOPC) is shown below.
With normal OPCs, all data for a certain point in time(logical copy) is copied to the copy destination disk area.
The copy destination disk must have (at least) the same capacity as the copy source disk area.
The copy time is the time needed to copy all data.
With QuickOPCs, for the first copy, all data for a certain point in time (logical copy) is copied to the copy destination disk area.
For second and subsequent copies, only data that has been updated since the last copy is copied.
The copy destination disk must have (at least) the same capacity as the copy source disk area.
The copy time for second and subsequent copies is the time needed to copy differential data.
With SnapOPCs, only data that has been updated from the data at a certain point in time (logical copy) is copied to the copy destination disk area.
The copy destination disk area can be smaller than the copy source disk area.
The copy time is the time needed to copy data that has been updated.
Snapshot type replications that use SnapOPC are referred to as "SnapOPC snapshot type replications".
In some ways, SnapOPC is superior to conventional OPCs, since copy times are shorter and copy destination volumes have a smaller capacity. However, there are problems in terms of access performance and the reliability of copy data.
These points suggest that SnapOPC should be used as temporary areas for tape backups for systems where access performance is not an important consideration.
SnapOPC can only be used for replications (OPC) within a single cabinet. SnapOPC cannot be used for inter-cabinet replications (ROPC).
The disk at the copy destination of SnapOPC is called Snap Data Disk
Replicas are created by copying from the original volume to the replica volume using the EC or REC function of an ETERNUS storage system disk array unit.
Synchronized replication uses two methods to create a copy: full copying and incremental copying. In full copying, all of the original volume is completely copied. In incremental copying, only the data from the previous copy that has been updated is copied.
Creating replicas with full copying
Use this method to create the first copy in a replication.
Creating copies with incremental copying
Use this method to create later copies once a previous replica already exists.
Copies are created by copying the data that has been updated after an initial copy has been made (full copying and incremental copying).
The following steps comprise the procedure for synchronized replication:
When synchronized processing using the synchronous processing start command (swsrpstartsync) starts from the original volume to the replica volume full copying also starts. ((1) in Figure 7.2)
Full copying is complete. The original volume and replica volume both enter the equivalence status. From this point on, updates in the original volume are sequentially reflected in the replica volume so that data equivalence is always maintained (equivalency holding state). (States in (2) and (3) in Figure 7.2)
Synchronized processing is temporarily stopped with the replication creation command (swsrpmake) to create a copy of the original volume. The replication creation command dismounts or mounts the original volume. This processing determines the original data (for details, refer to "Preprocessing and Postprocessing of Replication"). After execution of the replication creation command, the replica volume can be accessed (copy established status). (States in (3) and (4) in Figure 7.2)
To create another copy, the synchronized processing that has been temporarily stopped is restarted with the synchronous processing start command. For this copy, the only data copied to the replica volume is the (incremental) data on the original volume that has been updated since the previous copy was made until the restart of synchronized processing ((4) in Figure 7.2).
When the replica volume has been updated after the previous copy is made, the content of the update of the replica volume is cleared.
When the incremental data has been copied, the status returns to the equivalency holding state again. (States in (5) and (6) in Figure 7.2)
When this status has been set, the copy is re-created with the replication creation command. ((6) in Figure 7.2)
To use the EC or REC function in synchronized replication, disk array devices must support the EC or REC function.
The replication creation command cannot be executed unless both the original volume and replica volume are in the equivalence status.
This chapter explains the operation of AdvancedCopy Manager replication.
Design replication using the following procedure:
Refer to "Notes of the design in SnapOPC replication", when the SnapOPC snapshot replication is used.
Determine the server that performs replication.
The following servers are used to perform replication:
Storage management server
Multiple storage servers are unified and operated centrally. The storage management server can also be used as a storage server.
However, a Storage management server is of the Windows, Solaris or Linux AdvancedCopy Manager.
Storage server
AdvancedCopy Manager operations are performed.
The AIX AdvancedCopy Manager corresponds to this employment form.
The following requirements apply when box-to-box replication is performed using the remote copying function (ROPC or REC) of an ETERNUS storage system disk array unit:
The ROPC or REC function must be installed in both boxes.
Both boxes must already be connected using an FC remote adapter (FCRA). In a connection that uses an FCRA, data flows only from the INIT side to the TARG side. For bi-directional copying, at least two FCRA connections are required.
Determine the original volume and replica volume to be used in the replication.
The original volume is the volume on which the data to be copied is stored.
The replica volume is the volume on which a copy of the data on the original volume is stored.
In addition, determine the following attributes to be assigned to the original volume and replica volume:
Copy direction
Determine the direction of copying used in replication. Specify one of the following directions:
bi-direction: Copying is bidirectional between the original volume and replica volume.
uni-direction: Data is copied only from the original volume to the replica volume. During this operation, copying from the replica to the original volume is to be disabled.
Operation servers (used only for server-to-server replication)
In replication between servers, you can specify whether to allow replication to be performed on only the copy source server or copy destination server, or on both servers:
"Original server": Sets the storage server with the original volume connected as the operation server.
"Replica server": Sets the storage server with the replica volume connected as the operation server.
"Both servers": Sets both the copy source server and copy destination server as operation servers.
It is possible to create a group by arranging multiple copy source volumes and copy destination volumes. In addition, the operation for multiple copy source volumes and copy destination volumes can be performed in a unit of group. For details, refer to "Creating groups".
In this manual, a storage server used to perform replication is called the operation server. An original server or replica server is specified as the operation server.
An operation server can use all of the replication functions. In contrast, any other type of server can use only the information display function and operation release function.
Replication is not supported for the system disk or the disk where AdvancedCopy Manager is installed.
Refer to "General notes", for notes on determining a replication target.
Exclusion from Backup or replication Targets
There are points which it is careful of for every combination of the original volume and replica volume used for replication operation.
When the size of physical disk (which constructs the logical disk in case of it) of an original volume differs from that of a replica volume, a physical copy is carried out according to the one where size is smaller. Since lack of data occurs in this case, the physical disk size of replica volume is the same as that of original volume, or to use a large thing.
When the original volume is a volume group, for using the replica volume after replication, the replica volume needs to be the volume group of the same logical volume composition as the original volume, and the same physical disk size (Figure 7.5).
In addition, when a composition of the volume group cannot be supported by AdvancedCopy Manager, it cannot register with a replication management function. For detail about the logical disk composition which cannot be supported, see "Managing a Device on AdvancedCopy Manager".
Only one session can be set up for each Snap Data Disk.
Accordingly, multiple sessions cannot be set up for a single Snap Data Disk, as shown in the following figure:
It is not possible to copy from the Snap Data Disk to a disk other than the copy source disk.
Create a Snap Data Disk by performing the following steps:
Calculate the physical capacity for the Snap Data Disk.
Define and initialize the Snap Data Disk.
Connect to the host.
Create physical disk, and file systems.
The formula for estimating the physical capacity of Snap Data Disks is as follows:
Physical capacity = (number of updated blocks for the copy source volume) x (safety factor) |
To be precise, both the number of blocks that have been updated on the Snap Data Disk before the SnapOPC is taken and the management area used by the hardware (about 0.1% of the logical capacity) should also be taken into account, however this can be covered by increasing the safety factor.
The number of blocks that have been updated on the copy source volume can be estimated using the update amount measurement command (swstestupdate).
Make this measurement using the following procedure:
Start measuring the update amount by setting up a pseudo SnapOPC session on the copy source volume.
# /opt/FJSVswsts/bin/swstestupdate start /dev/hdisk10 /dev/hdisk10 swstestupdate completed # |
Start transactions. Blocks that are updated by transactions will be recorded on the hardware.
After the measurement period has elapsed, check the number of blocks that have been updated.
# /opt/FJSVswsts/bin/swstestupdate status /dev/hdisk10 Volume-Name Update /dev/hdisk10 644333 # |
After the measurements are complete, cancel the pseudo SnapOPC session.
# /opt/FJSVswsts/bin/swstestupdate stop /dev/hdisk10 /dev/hdisk10 swstestupdate completed # |
Define and initialize the Snap Data Disk using ETERNUSmgr. At this point, set the logical capacity to that of the copy source disk (in order to use the same partition configuration for both the copy source disk and the copy destination disk).
Connect the created Snap Data Disk to the host. Refer to the manual for the disk array system (the Server Connection Guide) for information on this procedure.
Create physical disk, and file systems so that a copy source volume can be created on the Snap Data Disk.
Once file systems have been created, limit updates to the copy destination volume as much as possible, to avoid unnecessarily using up the physical capacity of the Snap Data Disk.
Do not use Snap Data Disks as shared disks for cluster systems. This is to avoid the danger of the cluster system failing over when the physical capacity of the Snap Data Disk is exceeded.
For cluster operations, use one of the following methods to prevent the Snap Data Disk from being used as a shared disk.
Permit the Snap Data Disk to be referenced from all the nodes in the cluster system.
Use inter-server replication between the cluster system and a non-cluster system.
The following figure shows the flow of the replication operations.
The following preparations are required before replication can start.
Before replication is started, the AdvancedCopy Manager daemon must be started on the storage management server and storage server. In general, the daemon is automatically started at system startup.
When starting goes wrong for a certain reason, and when a demon is stopped at once, it is necessary to start a demon by each server. For information about starting the Daemons, refer to "Starting and Stopping Daemons".
Use the following URL to start the AdvancedCopy Manager initial screen. In cluster operation, the URL is different. For details, please refer to "Initial Window," in the ETERNUS SF AdvancedCopy Manager User's Guide."
|
http:// storage-management-server-address(:port-number)/swstorage/index.html |
The following GUI (server list screen) will display.
When using the command line only, without using the GUI, it is not necessary to perform this step.
All AdvancedCopy Manager GUI operations are available on a Storage management server. For more about GUI operation, refer to "ETERNUS SF AdvancedCopy Manager User's Guide".
When the storage management server is in cluster operation
When the storage management server is in cluster operation, you must configure an authentication-related file (refer to "Configuring the authentication-related file" in the ETERNUS SF AdvancedCopy Manager User's Guide) to use Web screens.
The Storage management server registers the Storage server to be managed. When the Storage server is operated as a Storage management server does not need to add a server.
Select the [Operation] menu, and then select [Addition of Server]. The following window displays.
To add a storage server, specify a server name, IP address, and the port number required for communications. The port number was specified as the "communications service port number", when the Agent of AdvancedCopy Manager was installed.
In cluster operation, specify the logical IP address of the Storage server as the IP address. Also specify the port number of Storage server transactions registered at the time the cluster was setup.
Click [OK] after entering the information. The Storage server processing is then performed.
This processing can also be carried out by the server information addition command (stgxfwcmaddsrv). Please refer to the employment guide to OS of a Storage management server.
Before the backup management can be performed, device information on a storage server must be temporarily stored to the repository. To acquire information on a device on the storage manager server, from the [Operation] menu, select [Acquisition and reflection of Information on all devices]. The following window displays:
After checking the server from which device information should be acquired, click the [OK] button.
After the device information has been obtained from each server, the following dialog box displays:
The new devices detected will be displayed in the 'Detected device' list box at the top of the dialog. Select a device to be managed and click the < button to move it to the 'Additional instruction device' list box on the left. The 'Device not detected list box' displays devices currently under management but not detected. Select any device that you no longer want to manage and click the > button to move it to the 'Device in deletion instruction' list box. The list box at the bottom of the dialog displays devices whose device information has been updated (e.g. the mount point name has been changed).
After completing the above taks, click the [OK] button to accept the configuration information.
This processing can also be carried out by the device information collection/reflection command (stgxfwcmsetdev). Please refer to the employment guide to OS of a Storage management server.
The time required for this operation depends on the total number of devices defined on the Storage server. If the number of devices is large, perform this operation while the CPU load and I/O load are low. As a guideline for reference, each operation takes about 0.5 s per device (partition) under no-load conditions.
About a device of LVM, only a volume group and a logical device are fetched, but the physical device which constitutes a logical device is not.
Information on the volume group which was non-revitalization when the operation is executed is not taken. Because the volume group which registers as a backup volume becomes non-revitalization when the backup operation begins, it is not detected by this operation. Do not issue an instruction to delete a volume in use.
Use the replication volume information setting command (swsrpsetvol) to set the original volume and replica volume that will be used in the replication. The information on the registered original volume and replica volume can be checked with the replication volume information display command (swsrpvolinfo).
When specifying the volume of another storage server in server-to-server replication, specify the volume in the format "volume-name@storage-server-name."
In AdvancedCopy Manager, replication processing must be performed while volumes are unmounted. Therefore, when replication is executed, processing to mount and unmount the volume is performed by the preprocessing and postprocessing script.
AIX AdvancedCopy Manager implements the transaction volume unmount/mount operation by customizing pre-processing and post-processing scripts. If a pre-processing script ends with an error during execution of backup/restoration, backup/restore processing is not performed.
For details of the preprocessing and postprocessing script, refer to "Preprocessing and Postprocessing of Replication."
When the operation corresponds to following either, it is necessary to customize the script used for preprocessing and postprocessing of replication.
Replication target is a volume group.
Describe special processing in a script of preprocessing and postprocessing.
About customize method, see "Preprocessing and Postprocessing of Replication".
When AdvancedCopy Manager is upgraded
The script may be updated after the upgrade.
Therefore, customize the script after upgrade rather than reusing the script which was being used by the previous version.
When the replication about is done in each group, preprocessing and postprocessing is not done. Therefore, all volumes in the group are unmounted, done before the reproduction is made, and it is necessary to do the mount after the reproduction is made.
Moreover, the volume group the reproduction ahead is activated before the reproduction is made when volume group (LVM) is made a replication object, and it is necessary to compose the volume group again after the reproduction is made. Refer to "The re-composition of the volume group" of 'Replication operation of each physical disk' of this manual for the re-composition of the volume group.
Moreover, the disk group the reproduction ahead is composed before , reproduction is made at the time of it is time when makes the VxVM volume a replication object and it is necessary to compose the disk group again after the reproduction is made of the deport doing. Refer to "The re-composition of the disk group" of 'VxVM Volume Operation' of this manual for deport and the re-composition of the disk group.
The replication volume information that makes up the group (the copy source volume and the copy destination volume pairs) must meet the following conditions:
The copy source servers and copy destination servers respectively must all match.
The operation servers and the copy directions respectively must all match. (The values for the operation servers and the copy directions can be checked using the "Op-Server" and "Copy" columns of the execution results of the replication volume information display command (swsrpvolinfo).
The replication volume information being registered must not be registered in any other group.
Copy source volumes and copy destination volumes must not be duplicated within the group.
[Condition 1]
[Condition 3]
[Condition 4]
Groups are created using the replication volume information setting command (swsrpsetvol).
Information for created groups can be displayed using the replication volume information display command(swsrpvolinfo).
[Execution example]
Two groups (GRP1) composed of an original volume and the replica volume are made.
# swsrpsetvol -Xgroup GRP1 /dev/hdisk10@SRC /dev/hdisk20@TARG-1 swsrpsetvol completed # swsrpsetvol -Xgroup GRP1 /dev/hdisk11@SRC /dev/hdisk21@TARG-1 swsrpsetvol completed # swsrpvolinfo -L Server Original-Volume Size Replica-Volume Size Copy Op-Server Group SRC /dev/hdisk10@SRC 4.0Gbyte /dev/hdisk20@TARG-1 4.0Gbyte bi-direction both GRP1 SRC /dev/hdisk11@SRC 4.0Gbyte /dev/hdisk21@TARG-1 4.0Gbyte bi-direction both GRP1 # |
This chapter explains AdvancedCopy Manager replication.
Before performing backup, see "Preparations," to set up the environment required for replication.
This section describes the operation by the command.Refer to "Replication Management Operations" of a "ETERNUS SF AdvancedCopy Manager User's Guide" about operation by the Web screen.
Use the replication creation command (swsrpmake) to perform snapshot replication.( Refer to "Snapshot replication processing" about explanation of snapshot replication.)
The operation status of a physical copy can be checked by executing the operation status display command (swsrpstat).
Execute QuickOPC snapshot replication by specifying the -T option in the replication creation command (swsrpmake).
If no OPC session exists when the replication creation command is executed, the command starts snapshot processing (OPC physical copying), and tracks processing from the source volume to the destination volume.
To check the execution status of physical copying, use the operation status display command (swsrpstat) in the same way as for an ordinary snapshot replication.
After snapshot processing (OPC physical copy) is complete, only tracking processing is active.
To check the tracking status, use the operation status display command (swsrpstat) with the -L option specified.
Entering the replication creation command (swsrpmake) with the -T option specified during tracking processing performs the physical copying of only the data that has been generated since the previous snapshot processing. This means that physical copying can be accomplished in a short period of time.
When you try to perform a restoration with a tracking processing being executed, you need to perform a restoration by OPC (you need to execute swsrpmake without -T option).The replication operation using QuickOPC is done as follows:
[backup] swsrpmake -T <original volume name> <replica volume name> [restore] swsrpmake <replica volume name> <original volume name> |
Though a restoration is executed with OPC, not all the data but only the data that has been updated after the previous replication (it can be referred at 'Update' column of swsrpstat) is copied. Therefore, in replication operation using QuickOPC, not only a physical copy for backup but also that for restoration is completed in a short period of time.
Execute SnapOPC type replications with the -C option specified in the replication creation command (swsrpmake).
When the replication creation command is executed, a SnapOPC session will be set up between the copy source volume and the copy destination volume.
[Execution example]
# /opt/FJSVswsrp/bin/swsrpmake -C /dev/hdisk10 /dev/hdisk20 FROM=/dev/hdisk10@SV1,TO=/dev/hdisk20@SV1 swsrpmake completed # |
Unlike normal OPCs and QuickOPCs, SnapOPCs do not copy all of the data from the copy source volume, but instead copy only the data that has been updated on the copy source or copy destination since the SnapOPC started. This kind of copy processing is referred to as "Copy-on-Write".
Note: The units for host I/O and storage device copies are different (512 bytes for host I/O and 8 kilobytes for storage device copies), and therefore data copies also occur when the copy destination is updated.
The status of SnapOPC sessions can be checked using the operation status display command (swsrpstat).
The following example shows the execution of the operation status display command immediately after a SnapOPC snapshot has started. While SnapOPC is being performed, "copy-on-write" is displayed in the Status field, and the amount of data updated since the last copy was created is displayed in the Update field as a percentage.
[Execution example ]
# /opt/FJSVswsrp/bin/swsrpstat -L /dev/hdisk10 Server Original-Volume Replica-Volume Direction Status Execute Trk Update Rcv Split Xfer SV1 /dev/hdisk10@SV1 /dev/hdisk20@SV1 regular copy-on-write ---- off 0% ---- ---- ---- # |
If the replication creation command is executed again during SnapOPC processing the SnapOPC session that has already been set up will be canceled, and a new SnapOPC session will be set up.
If the physical capacity of the Snap Data Disk is exceeded, the SnapOPC session will become error-suspended. This can be confirmed if "failed" is displayed in the Status field of the operation status display command.
[Execution example ]
If the physical capacity of the Snap Data Disk is exceeded, the SnapOPC session must be canceled using the replication cancellation command (swsrpcancel), and extra physical capacity must be added to the Snap Data Disk.
Perform restorations from Snap Data Volumes by running an OPC using the replication creation command (swsrpmake).
# /opt/FJSVswsrp/bin/swsrpmake /dev/hdisk10 /dev/hdisk20 FROM=/dev/hdisk10@SV1,TO=/dev/hdisk20@SV1 swsrpmake completed # |
When restorations are executed, the SnapOPC session from the copy source volume to the copy destination volume is maintained as is, and a normal OPC from the backup volume to the transaction volume is started. At this point, the time taken to restore the physical copy is reduced, because only data that has been updated since the last copy is copied.
The execution status of restorations can be checked by specifying the -E option with the operation status display command (swsrpstat).
# /opt/FJSVswsrp/bin/swsrpstat -E /dev/hdisk10 Server Original-Volume Replica-Volume Direction Status Execute SV1 /dev/hdisk10@SV1 /dev/hdisk20@SV1 reverse snap 80% # |
If a SnapOPC is being performed between the copy source volume and the copy destination volume, restorations to volumes other than the copy source volume cannot be executed. To restore to a volume other than the copy source volume, operating system copy functions (such as the cp command or the copy command) must be used.
Additionally, if SnapOPCs are being performed to multiple copy destination volumes, restoration cannot be performed.
In this case, restoration using an OPC can be performed by canceling the other SnapOPCs. However, the backup data on the copy destination volumes whose SnapOPC sessions were canceled will be lost.
To perform a restoration while still maintaining all SnapOPC sessions, operating system copy functions (such as the cp command or the copy command) must be used for the restoration. However, if restoration is performed using operating system functions, the amount of updated data on the copy source volume will increase, and there is a risk that the capacity of the SnapOPC volume will be exceeded.
To perform synchronized replication, use the following procedure:
Start synchronized processing using the synchronous processing start command (swsrpstartsync). Use the replication cancellation command (swsrpcancel) to cancel synchronized processing that has already started.
After making sure that equivalency holding state has been established with the operation status display command (swsrpstat), temporarily stop synchronized processing with the replication creation command (swsrpmake) to create a replica of the original volume.
To copy the updated (incremental) data, restart synchronized processing with the synchronous processing start command (swsrpstartsync).
Intra-box synchronous replication creates a replication from a source volume to a destination volume by using the EC function of the disk array.
The EC function operates in a mode in which a copy is made to a destination volume in synchronization through a write to a source volume (in synchronous write mode).
Inter-box synchronous replication creates a replication from a source volume to a destination volume by using the REC function of the disk array.
The REC function provides three copy operation modes that can be selected for operation:
Transfer mode
Recovery mode
Split mode
In addition, the REC function enables the copy direction to be reversed in suspended status.
The transfer mode provides the REC data transmission modes described below.
|
Mode |
Description |
|---|---|
|
Synchronous |
When a write operation to a source volume occurs, this transfer mode returns the completion of write operation to the host after copying is completed. In synchronous transfer mode, the performance of a write response depends on the performance of the circuit between the boxes. Thus, any deterioration in circuit performance adversely affects the performance of a write response. |
|
Asynchronous |
This transfer mode starts sending data to a destination volume immediately after a response is made to a write operation to the source volume. The order of write operations is thus secured. If the volume of updates made to the source volume is excessive compared with transmission performance between the boxes, data to be copied remains stored, and write operations to the host are queued until the data is copied to some extent. To use asynchronous mode, the circuit must have at least the same performance as the update speed to source volumes. |
|
Stack |
This mode stores (stacks) data in the source box to be transferred and copies the data at irregular intervals to lower the speed of data transferred to the destination box. Update data on the source volume is transferred to the destination volume at irregular intervals, thus the order of write operations is not guaranteed. |
|
Consistency |
This transfer mode guarantees the order in which multiple synchronous processes reflect data. Data updates in multiple synchronous processes are copied periodically and collectively, thus the order of write operations can be secured among multiple synchronous processes. |
To perform a synchronous replication operation in Stack mode or Consistency mode, use the replication start command (swsrpstartsync), replication execution command (swsrpmake), and synchronization mode change command (swsrpchsync). The figures below show how synchronous replication operation is done in Stack mode or Consistency mode.
Recovery mode includes two modes to restart copying after recovery from an inter-box path error (halt status).
|
Mode |
Description |
|---|---|
|
Automatic Recovery |
In this mode, the REC session automatically switches from HALT status to regular status, and copy processing resumes when the inter-box FCRA path is recovered. |
|
Manual Recovery |
In this mode, the REC session remains in HALT status and copy processing does not resume even if the inter-box FCRA path is recovered. Manually resume copying. This mode is used, for example, when operating a standby database. |
Split mode includes two modes for write operation to the source volume when REC is used for synchronous transfer mode and for recovery from an inter-box path error (halt status).
|
Mode |
Description |
|---|---|
|
Automatic Split |
This split mode forcibly executes successful write operations to source volumes even if the inter-box FCRA path is fully blocked and HALT status occurs. This mode enables write operations to source volumes even if the inter-box FCRA path is fully blocked, thus this mode does not affect transactions. When the inter-box FCRA path is recovered, copy processing resumes according to the recovery mode settings. |
|
Manual Split |
This split mode rejects write operations to source volumes (returns an error) if the inter-box FCRA path is fully blocked and HALT status occurs. This mode enables source volumes and destination volumes to be fully synchronized even if the FCRA path is fully blocked. When the inter-box FCRA path is recovered, copy processing resumes according to the recovery mode settings. |
The copy direction reverser allows you to smoothly switch among center sites.
The following figures show an example of how to switch the copy direction:
Assume that Site A is operating and REC is operating from Site A to Site B.
To switch the sites, execute the replication execution command to make a replication to Site B. Then, stop operating Site A.
Execute the synchronization reverse command to reverse the copy direction.
Put Site B into operation. At this stage, synchronization is still suspended, thus any update to the volume at Site B is not reflected at Site A.
Start (resume) synchronization from Site B to Site A. Updates made to the volume in Site B while synchronization is suspended are reflected into Site A with differential copies.
The initial copy skip function is used when the initial copy cannot be executed because of the insufficient line capacity.
Suppose that operations at Site A have stopped.
Next, synchronous processing begins, using the initial copy skip function. At this point, an REC session is set up, and the status is Replication Established. Data is not copied to the copy destination volume.
Next, the data on the copy source volume is backed up to tape.
The tape medium is sent to Site B, and jobs at Site A restart.
The data on the tape medium is restored to the copy destination volume. At this point, the data on the copy destination volume is the same as the data on the copy source volume that existed before operations restarted.
Synchronous processing restarts in Remain mode. Restarting synchronous processing in Remain mode means that only data that has been updated on the copy source volume is reflected on the copy destination volume. (If Remain mode is not used, all data on the copy source volume is copied.)
The concurrent suspension function simultaneously suspends multiple EC/REC sessions for disk array systems.
By using this function, the copy with consistency can be easily taken.
For example, it is useful for a database composed of multiple volumes.
The behavior that takes places within the disk array system is shown below.
Replication using the concurrent suspension function is performed by specifying the -Xconcur option for the replication creation command (swsrpmake ).
Additionally, if concurrent suspension is performed using the Consistency transfer mode, it is no longer necessary to make temporary mode changes during multiple creation processes. (Refer to the figure below.) Accordingly, the operating procedure used when concurrent suspension is executed in Consistency mode is the same as the procedure for asynchronous mode and synchronous mode.
Data can be restored from the replica volume to the original volume if a volume pair has been defined bi-direction copying with the replication volume information setting command (swsrpsetvol).
Restoration can be executed according to the following procedures.
Execute the replication cancellation command (swsrpcancel) when the target volume for restoration has a EC session.
Execute the replication creation command (swsrpmake). The specification of an original volume and the replica volume is reversed at time when the replication was executed.
The reproduction making command is executed specifying neither -T option nor -C option at the backup operation that uses QuickOPC/SnapOPC.
When a storage server or device required in the replication operation has been changed, the information set in AdvancedCopy Manager must be changed. This chapter explains how to change the information set in AdvancedCopy Manager.
To change the attributes (copy direction, operation servers of server-to-server replication) of the otihinsl volume and replica volume that are set, delete the information with the replication volume information deletion command (swsrpdelvol) and then reexecute the replication volume information setting command (swsrpsetvol).
To delete the original volume or replica volume that are set, use the replication volume information deletion command (swsrpdelvol).
When making the size of device information and composition change which are used for an original / replica volume, a device composition is changed after deletion processing of the original / replica volume, and setting processing of the volume is performed.
Be sure to do the following work before making the size of an original / replica volume or a composition change. When not doing this work, deletion of the original / replica volume after device composition change may not be able to be performed.
Perform deletion processing to the original / replica volume for device change. For details, see "Deleting an original volume or replica volume".
Change the device composition.
Perform the additional processing of a device. For more information, see "Fetching device information from a storage server".
Perform setting of the original / replica volume.
To stop the replication processing, that is in progress, or to change the snapshot replication into the synchronized replication, use the replication cancellation command (swsrpcancel).
When stopping replication operation, the demon on a Storage server is stopped. Usually, it stops automatically at the time of a stop of a system.
It is possible to also make it stop individually to stop a demon by a certain reason. For Details, Please Refer to "Starting and Stopping Daemons" of this Manual of Service.
When the daemon stops, all functions of AdvancedCopy Manager running on the storage server stop.
Before stopping the storage management server daemon, make sure that operations on all storage servers under management have stopped.
The replication operation of LVM volumes can be classified into the following two modes depending on the volume group configuration:
Replication operation in units of volume groups
Replication operation in units of physical disks (LU: Logical Unit)
Before starting this operation, be sure to understand the basic operation of ordinary volumes.
Provided that all volume group configurations satisfy the following conditions, the replication operation can be performed in units of volume groups.
One volume group has only one physical disk, and logical volumes are configured so that one physical disk includes n logical volumes.
If the above conditions are not satisfied, replication operation must be performed in units of physical disks.
Observe the following conditions when designing volume groups for the use as original or replica volume groups:
All physical disks must have the same size.
The configurations of all logical volumes must be the same.
When setting the original volume and replica volume, specify their volume groups.
Example:
# /opt/FJSVswsrp/bin/swsrpsetvol /dev/vg01 /dev/vg02 swsrpsetvol completed # |
If a volume group is to be replicated, the preprocessing and postprocessing scripts must be customized.
See "Processing and Postprocessing for Replication" for information on the customization procedure.
If replication is attempted without customization of the scripts, preprocessing for the original volume causes an error during replication and replication cannot be achieved.
Execute replication with a volume group specified.
Example of snapshot replication
# /opt/FJSVswsrp/bin/swsrpmake /dev/vg01 /dev/vg02 FROM=/dev/vg01@SV1, TO=/dev/vg02@SV1 swsrpmake completed # |
Example of synchronous replication
# /opt/FJSVswsrp/bin/swsrpstartsync /dev/vg01 /dev/vg02 FROM=/dev/vg01@SV1, TO=/dev/vg02@SV1 swsrpstartsync completed (After state of equivalency upkeep) # /opt/FJSVswsrp/bin/swsrpmake /dev/vg01 /dev/vg02 FROM=/dev/vg01@SV1, TO=/dev/vg02@SV1 swsrpmake completed # |
When the volume group configuration does not satisfy the conditions for operation in units of volume groups, replication can be performed by operation in units of physical disks.
When backup operation is performed in units of physical disks, volume group integrity must be maintained and, therefore, all physical disks in the volume group must be operated synchronously.
To use the replica volume after replication in case that an original volume is a volume group, the replica volume must have the same logical volume configuration as the original volume and must be a volume group of the same physical size.
When setting the original and replica volumes, specify all physical disks in the volume group.
Example:
# /opt/FJSVswsrp/bin/swsrpsetvol /dev/hdisk10 /dev/hdisk20 swsrpsetvol completed # /opt/FJSVswsrp/bin/swsrpsetvol /dev/hdisk11 /dev/hdisk21 swsrpsetvol completed # |
Perform operation by synchronizing all physical disks in the volume group.
Perform the required preprocessing or postprocessing work for each volume group before respectively after the replication operation. Disable preprocessing and postprocessing when operating individual physical disks.
Example of snapshot replication
(Perform preprocessing for the source and target volumes.) # /opt/FJSVswsrp/bin/swsrpmake -f -t /dev/hdisk10 /dev/hdisk20 FROM=/dev/hdisk10@SV1, TO=/dev/hdisk20@SV1 swsrpmake completed # /opt/FJSVswsrp/bin/swsrpmake -f -t /dev/hdisk11 /dev/hdisk21 FROM=/dev/hdisk11@SV1, TO=/dev/hdisk21@SV1 swsrpmake completed # (Perform postprocessing for the source and target volumes.) |
Example of synchronous replication
(Perform preprocessing for the target volume.) # /opt/FJSVswsrp/bin/swsrpstartsync -t /dev/hdisk10 /dev/hdisk20 FROM=/dev/hdisk10@SV1, TO=/dev/hdisk20@SV1 swsrpstartsync completed # /opt/FJSVswsrp/bin/swsrpstartsync -t /dev/hdisk11 /dev/hdisk21 FROM=/dev/hdisk11@SV1, TO=/dev/hdisk21@SV1 swsrpstartsync completed (After state of equivalency upkeep) (Perform preprocessing for the source volume.) # /opt/FJSVswsrp/bin/swsrpmake -f -t /dev/hdisk10 /dev/hdisk20 FROM=/dev/hdisk10@SV1, TO=/dev/hdisk20@SV1 swsrpmake completed # /opt/FJSVswsrp/bin/swsrpmake -f -t /dev/hdisk11 /dev/hdisk21 FROM=/dev/hdisk11@SV1, TO=/dev/hdisk21@SV1 swsrpmake completed # (Perform postprocessing for the source and target volumes.) |
The table below summarizes the preprocessing and postprocessing work to be performed before and after replication.
|
Preprocessing |
Postprocessing |
|
|---|---|---|
|
Source volume |
|
|
|
Target volume |
|
|
Deactivate the volume group as follows:
# /usr/sbin/varyoffvg vg02 # |
Reconfigure the volume group as follows:
Use the chdev command to temporarily remove the target volume from LVM.
# /usr/sbin/chdev -l hdisk20 -a pv=clear # /usr/sbin/chdev -l hdisk21 -a pv=clear |
Use the exportvg command to export the target volume.
# /usr/sbin/exportvg vg02 |
Create the logical volume list file in the form of the following.
lvol11:lvol21 loglv11:loglv21 lvol12:lvol22 loglv12:loglv22 |
Use the recreatevg command to rewrite the LVM management information in the target volume.
# /usr/sbin/recreatevg -l <logical volume list file> -L /fs -y vg02 hdisk20 hdisk21 |
Use the chfs command to change the mount point.
# /usr/sbin/chfs -m /mnt21 /fs/mnt11 # /usr/sbin/chfs -m /mnt22 /fs/mnt12 |
VxVM volumes are replicated in units of physical disks that constitute each VxVM volume.
When the replication operation is performed in units of physical disks, disk group integrity must be maintained and, therefore, all the physical disks in the disk group must be operated synchronously.
Refer to "Device information display command (stgxfwcmdispdev)" of this manual, or the "Confirmation of devices in the save logical group" of a ETERNUS SF AdvancedCopy Manager User's Guide for the method of checking the physical volume which should take a synchronization.
Before starting this operation, be sure to understand the basic operation of ordinary volumes.
Snapshot backup is recommended in operation in units of physical disks. In the case of synchronized backup, the command (VxVM command etc.) which disk access produces to a copy destination disk during a copy cannot be executed.
Design the disk groups of the original and replica volumes. Observe the following conditions when designing the disk groups:
The number, sizes, and types of VM disks must be the same.
The configurations of logical volumes must be the same.
The disk group must be reconfigured in replication postprocessing. Confirm that a volume group configuration information file has been saved.
/etc/vx/cbr/bk/<disk group name>.<disk group ID>
When setting the original and replica volumes, specify all disks in the volume group.
Example:
# /opt/FJSVswsrp/bin/swsrpsetvol /dev/vm/dmp/hdisk10 /dev/vm/dmp/hdisk20 swsrpsetvol completed # /opt/FJSVswsrp/bin/swsrpsetvol /dev/vm/dmp/hdisk11 /dev/vm/dmp/hdisk21 swsrpsetvol completed # |
Perform operation by synchronizing all physical disks in the disk group.
Perform the required preprocessing or postprocessing work for each volume group before respectively after the replication operation. Disable preprocessing and postprocessing when operating individual physical disks.
Example of snapshot backup
(Perform preprocessing for the source and target volumes.) # /opt/FJSVswsrp/bin/swsrpmake -f -t /dev/vm/dmp/hdisk10 /dev/vm/dmp/hdisk20 FROM=/dev/vm/dmp/hdisk10@SV1, TO=/dev/vm/dmp/hdisk20@SV1 swsrpmake completed # /opt/FJSVswsrp/bin/swsrpmake -f -t /dev/vm/dmp/hdisk11 /dev/vm/dmp/hdisk21 FROM=/dev/vm/dmp/hdisk11@SV1, TO=/dev/vm/dmp/hdisk21@SV1 swsrpmake completed # (Perform postprocessing for the source and target volumes.) |
Example of synchronous replication
(Perform preprocessing for the target volume.) # /opt/FJSVswsrp/bin/swsrpstartsync -t /dev/vm/dmp/hdisk10 /dev/vm/dmp/hdisk20 FROM=/dev/vm/dmp/hdisk10@SV1, TO=/dev/vm/dmp/hdisk20@SV1 swsrpstartsync completed # /opt/FJSVswsrp/bin/swsrpstartsync -t /dev/vm/dmp/hdisk11 /dev/vm/dmp/hdisk21 FROM=/dev/vm/dmp/hdisk11@SV1, TO=/dev/vm/dmp/hdisk21@SV1 swsrpstartsync completed (After state of equivalency upkeep) (Perform preprocessing for the source volume.) # /opt/FJSVswsrp/bin/swsrpmake -f -t /dev/vm/dmp/hdisk10 /dev/vm/dmp/hdisk20 FROM=/dev/vm/dmp/hdisk10@SV1, TO=/dev/vm/dmp/hdisk20@SV1 swsrpmake completed # /opt/FJSVswsrp/bin/swsrpmake -f -t /dev/vm/dmp/hdisk11 /dev/vm/dmp/hdisk21 FROM=/dev/vm/dmp/hdisk11@SV1, TO=/dev/vm/dmp/hdisk21@SV1 swsrpmake completed # (Perform postprocessing for the source and target volumes.) |
The table below summarizes the preprocessing and postprocessing work to be performed before and after replication.
|
Preprocessing |
Postprocessing |
|
|---|---|---|
|
Source volume |
|
|
|
Target volume |
|
|
Reconfigure the disk group as follows:
Pre-commit analysis for restoration
# /etc/vx/bin/vxconfigrestore -p dstdg Diskgroup dstdg configuration restoration started ...... Installing volume manager disk header for hdisk20 ... Installing volume manager disk header for hdisk21 ... - dstdg's diskgroup configuration is restored (in precommit state). Diskgroup can be accessed in read only and can be examined using vxprint in this state. Run: vxconfigrestore -c dstdg ==> to commit the restoration. vxconfigrestore -d dstdg ==> to abort the restoration. # |
Commit the change required for restoring the configuration of the copy destination disk group.
# /etc/vx/bin/vxconfigrestore -c dstdg Committing configuration restoration for diskgroup dstdg .... dstdg's diskgroup configuration restoration is committed. # |
Import the disk group srcdg on the master server as disk group dstdg on the target server.
# /usr/sbin/vxdg -C -n dstdg import srcdg # |
When the disk group name is the same in the server of the source and the server of the destination, -n option is not specified.
Execute recovery processing for the volume in the disk group dstdg on the target server.
# vxrecover -g dstdg -sb # |
In case of a cluster system, when a disk group or a mount resource has been defined, instead of using the import/deport command for the disk group use the online/offline process, and instead of using the file system mount/unmount commands use the online/offline processing.
When performing a system disk exchange, there are cases when conflicting backup configuration information may exist.
In such cases, the disk group ID after executing the above command needs to be set instead of the disk group.
After this operation, in case the volumes within a disk group are needed to be run in synchronous mode in the background, then depending on the volume configuration it may take some time for synchronous processing.
It is also possible to use the volumes during this time.
|
Contents
Index
|
