When the VxVM volume configuration does not satisfy the conditions for replication operation using units in logical volumes, replication operation can be performed using units of physical disks.
When 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 replicated synchronously.
Point
For the physical volume which should be synchronized, confirm it by using either Web Console or stgxfwcmdispdev (Device information display command).
Note
It is only VM disk of the "nopriv" type that a physical slice becomes the unit of management.
Before starting this operation, be sure to understand the basic operation of ordinary volumes.
Snapshot backup is recommended for backing up in units of physical disks. In the case of synchronized backup, commands that access destination volumes, such as VxVM commands, cannot be executed during full copy or differential copy.
For operation in a cluster configuration, the device name (/dev/(r)dsk/c#t#d#) of the physical disks that comprise the disk group must be the same at all servers that comprise the cluster, and the ETERNUS Disk storage system's disk indicated by the device name must be the same.
For operation in a SunCluster environment, the VxVM enclosure name must be the same at all servers that comprise the cluster, and the ETERNUS Disk storage system's disk indicated by the enclosure name must be the same.
When configuring the disk groups of the original and replica volumes, you should note the following:
The number, sizes, and types of VM disks must be the same.
The configurations of logical volumes must be the same.
Figure 6.54 Copy source volume and copy destination volume
The disk group must be reconfigured in replication post-processing. 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.
# /opt/FJSVswsrp/bin/swsrpsetvol /dev/vx/dmp/c1t0d10s2 /dev/vx/dmp/c1t0d20s2 swsrpsetvol completed # /opt/FJSVswsrp/bin/swsrpsetvol /dev/vx/dmp/c1t0d11s2 /dev/vx/dmp/c1t0d21s2 swsrpsetvol completed #
Perform Replication by synchronizing all physical disks in the disk group.
Perform the required pre-processing or post-processing work for each volume group respectively before and after the replication operation. Disable pre-processing and post-processing when replicating individual physical disks.
(Perform pre-processing for the source and target volumes.) # /opt/FJSVswsrp/bin/swsrpmake -f -t /dev/vx/dmp/c1t0d10s2 /dev/vx/dmp/c1t0d20s2 FROM=/dev/vx/dmp/c1t0d10s2@SV1, TO=/dev/vx/dmp/c1t0d20s2@SV1 swsrpmake completed # /opt/FJSVswsrp/bin/swsrpmake -f -t /dev/vx/dmp/c1t0d11s2 /dev/vx/dmp/c1t0d21s2 FROM=/dev/vx/dmp/c1t0d11s2@SV1, TO=/dev/vx/dmp/c1t0d21s2@SV1 swsrpmake completed # (Perform post-processing for the source and target volumes.)
(Perform pre-processing for the target volume.) # /opt/FJSVswsrp/bin/swsrpstartsync -t /dev/vx/dmp/c1t0d10s2 /dev/vx/dmp/c1t0d20s2 FROM=/dev/vx/dmp/c1t0d10s2@SV1, TO=/dev/vx/dmp/c1t0d20s2@SV1 swsrpstartsync completed # /opt/FJSVswsrp/bin/swsrpstartsync -t /dev/vx/dmp/c1t0d11s2 /dev/vx/dmp/c1t0d21s2 FROM=/dev/vx/dmp/c1t0d11s2@SV1, TO=/dev/vx/dmp/c1t0d21s2@SV1 swsrpstartsync completed # (After state of equivalency upkeep) (Perform pre-processing for the source volume.) # /opt/FJSVswsrp/bin/swsrpmake -f -t /dev/vx/dmp/c1t0d10s2 /dev/vx/dmp/c1t0d20s2 FROM=/dev/vx/dmp/c1t0d10s2@SV1, TO=/dev/vx/dmp/c1t0d20s2@SV1 swsrpmake completed # /opt/FJSVswsrp/bin/swsrpmake -f -t /dev/vx/dmp/c1t0d11s2 /dev/vx/dmp/c1t0d21s2 FROM=/dev/vx/dmp/c1t0d11s2@SV1, TO=/dev/vx/dmp/c1t0d21s2@SV1 swsrpmake completed # (Perform post-processing for the source and target volumes.)
The table below summarizes the pre-processing and post-processing work to be performed before and after replication.
Type | Pre-processing | Post-processing |
|---|---|---|
Source volume |
| If file systems are included, remount the volumes that were unmounted by pre-processing. |
Target volume |
|
|
Reconfiguring the disk group (for replication within the server)
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 c1t0d20s2 ... Installing volume manager disk header for c1t0d21s2 ... - 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. #
Reconfiguring the disk group (for replication between servers)
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 # |
Note
When the disk group name is the same in the server of the source and destination, the -n option is not specified.
Execute recovery processing for the volume in the disk group "dstdg" on the target server.
# vxrecover -g dstdg -sb # |
Because udid of the copy destination disk is not an adjustment, this is restored.
# vxdisk updateudid c1t0d20s2 c1t0d21s2 # |
Note
In case of a clustered system, when a disk group resource has been defined, use the online/offline process instead of the disk group import/deport command.
If a mount point is defined as a clustered system resource, use the mount resource online/offline process instead of the file system mount/unmount process.
When performing a system disk exchange, there are cases when multiple conflicting configuration information backups may exist for one disk group.
In such cases, the disk group ID displayed after executing the above command needs to be set and executed instead of the disk group.
When the volumes within a disk group are required to be run in synchronous mode in the background and depending on the volume configuration it may take some time for synchronous processing to complete after this operation.
It is also possible to use the volumes during this time.
