![]() |
< Previous | Next > |
Product: Volume Replicator Guides | |
Manual: Volume Replicator 4.1 Administrator's Guide |
Verifying the DR Readiness of a VVR SetupWhen setting up a Disaster Recovery (DR) solution, it is very important to verify the effectiveness of the DR solution. Although VVR guarantees that integrity of data is maintained between the Primary and Secondary data volumes, validating data is necessary to ensure that there has been no data loss due to administrative error, user error, or some other technical reasons. Validation also helps you to be certain that the data that has been replicated to the Secondary (Disaster Recovery site) can be used to bring up the applications in case of a disaster. The way to validate the DR readiness of the DR site is to bring up the application on the DR site. This can be done in two ways. One is to migrate the Primary role to the Secondary and then run the applications on the new Secondary using the replicated data. Another way of performing a firedrill is using the snapshot feature. Using this feature VVR creates snapshots of the data volumes that can be used to bring up the application on the Secondary. Data validation can be used to verify the integrity of the data that has been replicated to the Secondary from the Primary. This is done by comparing the data with the data on the Primary. When the Secondary data volumes are validated after the replication has been stopped, the volumes are dissociated from an RVG. This could be very useful in case you want to validate the data volume before adding it back to the RDS. However, data can also be validated online, that is, when the replication is in progress. This is achieved by using the instant space-optimized snapshot feature to create point in time snapshots of the primary and secondary data volumes. In this case, instead of the actual volumes the snapshot volumes are compared and validated. For information on the methods to create the snapshots, refer to Creating RVG Snapshots. VVR enables you to validate the DR Readiness of the Secondary by using one of the following methods.
Performing a FailoverA disaster like scenario can be tested by using the migrate operation to perform a complete failover testing. This can be done by migrating the role of the Secondary to a Primary and making sure that the application is running on the new Primary. For more information on how we can perform the role transfer refer to the chapter Transferring the Primary Role. Performing a FiredrillFiredrill is a process of bringing up the application on the Secondary using the replicated data. This data is then used to perform some processing in order to validate the consistency and correctness of the data. To test the failover you can use a point-in-time image of the data on the Secondary data volumes. VVR provides you with the option of creating instant full and space-optimized snapshots. For any information on the methods to create snapshots see section Creating RVG Snapshots. You can use the appropriate type of snapshot method to create the snapshots. The instant space-optimized snapshot has much lesser space requirement compared to the instant full or plex-breakoff snapshots. These space-optimized snapshots are used to test the Secondary failover.
Automating the Firedrill Procedure The firedrill procedure is most effective only when it is performed on a regular basis. The above method requires you to test the Secondary failover, manually, at frequent intervals. However, in case VVR is used in a VCS setup where the appropriate agents are installed, then the firedrill procedure can be automated using the RVGSnapshot and RVGPrimary agents that VCS provides. For more information on how you can use these agents to automate the firedrill testing, refer to the VCS Documents. Verifying the Data on the SecondaryVVR enables you to verify that the data on the Secondary is identical to the data on the Primary data volumes, either when the application is active or inactive. VVR provides the following methods to verify the data at the Secondary site: online data verification and offline data verification. Online data verification allows you to validate the data even when replication is in progress. In this method instead of the actual volumes, the point-in-time snapshots are compared. This method is referred to as online data verification. Offline data verification can be performed only when replication is not active. If you have already created the Primary and Secondary volumes and replication is in progress, you need to pause replication and then perform data validation between the corresponding Primary and Secondary volumes to make sure that the data volumes on the Primary and Secondary are the same. To do this, use the vradmin syncrvg command with the -verify option. To use this command for verifying the data, the Secondary must be up-to-date. This command performs a comparison of the checksums on the corresponding Primary and Secondary volumes. You can also validate the data on new data volumes before adding them to an RDS. For information, refer to Verifying the Data on the Primary and Secondary Volumes. Performing Online Data VerificationThe space-optimized snapshots that are created using the vxrvg snapshot command can be used to verify whether the data on the Primary and Secondary RVG volumes is the same. The major advantage of this feature over the vradmin -verify syncrvg command is that you do not need to stop the replication. The verification can be done even while the replication is in progress because the point-in-time snapshots, and not the volumes, are compared. This feature is very useful if you want to check the integrity of the data volumes on the Secondary when replication is in progress. The vradmin verifydata command creates the space-optimized snapshots on the Primary and the Secondary before it proceeds with performing online data verification. The vradmin verifydata command also ensures that the snapshots are taken only after the replication has been paused using the vxibc freeze command. As a result there may be a momentary pause in the replication. It is necessary to freeze the writes so that the snapshots can be taken at an identical point in replication time, on each of the required hosts. The vradmin verifydata then verifies the data between the remote and local hosts by comparing the space-optimized snapshots. To perform online data verification, use the command: vradmin [-g diskgroup] [-k {cache|snap}] verifydata rvg_name \ sechost {cache=cacheobj | cachesize=size} The attribute sechost specifies the name of the Secondary host. The cache attribute specifies a name for the precreated cache object, on which the snapshots for the volumes in the specified RVG will be created. The cachesize attribute specifies a default size for the cache object with respect to the source volume. If the RVG on either the Primary or the Secondary has VxVM ISP volumes, then you cannot use the cachesize attribute. You must specify only one of these attributes at one time for the command to create a cache object for each snapshot. This command performs the following tasks:
By default, the vradmin verifydata command destroys the snapshot volume and the cache object after the data verification has proceeded successfully. However, if you want to preserve the snapshot volumes then you must use the vradmin verifydata command with the -k snap option. If you want to preserve the cache object then use the ![]() VVR also provides you with sample scripts that can be used to freeze the replication and then take instant space-optimized snapshots. For details, refer to Sample Scripts.
Performing Offline Data VerificationVVR enables you to verify whether the data on the Secondary is identical to the data on the Primary data volumes when the application is inactive. The vradmin syncrvg command with the -verify option verifies and reports any differences between the data volumes associated with the Secondary RVG and the corresponding Primary RVG. The vradmin -verify syncrvg command only reports whether the Primary and Secondary volumes are identical or not. It does not make them identical. As the command runs, it reports the progress every 10 seconds. An MD5 checksum is used to calculate the difference between the Primary and the Secondary data volumes. Refer to Using Difference-Based Synchronization. Prerequisite for using the vradmin -verify syncrvg command:
# vradmin -g diskgroup -verify syncrvg local_rvgname sec_hostname... When this command is invoked, you are prompted to confirm that the Primary data volumes are not in use. You can use the -s option to skip this confirmation step. The argument local_rvgname is the name of the RVG on the local host and represents the RDS. The argument sec_hostname is a space-separated list of the names of the Secondary hosts as displayed in the output of the vradmin printrvg command. This command checks the status of the Primary RLINK to each of the Secondary RVGs being verified. If any of the RLINKs are not up-to-date, the vradmin -verify syncrvg command returns with a message to indicate that the RLINKs are not up-to-date. In this scenario, verification is not be performed. Use the vxrlink status command to determine the extent to which the Secondary is behind. To verify the data differences between the Primary RVG hr_rvg on seattle and the Secondary RVG on host london, issue the following command from any host in the RDS: # vradmin -g hrdg -verify syncrvg hr_rvg london
The output resembles the following if the Primary and Secondary data volumes Message from Primary: VxVM VVR vxrsync INFO V-5-52-2210 Starting volume verification to remote VxVM VVR vxrsync INFO V-5-52-2211 Source host: 10.182.136.192 VxVM VVR vxrsync INFO V-5-52-2212 Destination host(s): 10.182.136.193 VxVM VVR vxrsync INFO V-5-52-2213 Total volumes: 1 VxVM VVR vxrsync INFO V-5-52-2214 Total size: 4.000 G Eps_time Dest_host Src_vol Dest_vol F'shed/Tot_sz Diff Done 00:00:00 10.182.136.193 hr_dv hr_dv 0M/4096M 0% 0% 00:00:10 10.182.136.193 hr_dv hr_dv 221M/4096M 0% 5% Message from Primary: 00:00:20 10.182.136.193 hr_dv hr_dv 468M/4096M 0% 11% Message from Primary: 00:00:30 10.182.136.193 hr_dv hr_dv 705M/4096M 0% 17% Message from Primary: 00:00:40 10.182.136.193 hr_dv hr_dv 945M/4096M 0% 23% Message from Primary: 00:00:50 10.182.136.193 hr_dv hr_dv 1184M/4096M 0% 29% Message from Primary: 00:01:00 10.182.136.193 hr_dv hr_dv 1419M/4096M 0% 35% Message from Primary: 00:01:10 10.182.136.193 hr_dv hr_dv 1655M/4096M 0% 40% Message from Primary: 00:01:20 10.182.136.193 hr_dv hr_dv 1886M/4096M 0% 46% Message from Primary: 00:01:30 10.182.136.193 hr_dv hr_dv 2124M/4096M 0% 52% Message from Primary: 00:01:40 10.182.136.193 hr_dv hr_dv 2356M/4096M 0% 58% 00:01:50 10.182.136.193 hr_dv hr_dv 2590M/4096M 0% 63% Message from Primary: 00:02:00 10.182.136.193 hr_dv hr_dv 2838M/4096M 0% 69% Message from Primary: 00:02:10 10.182.136.193 hr_dv hr_dv 3091M/4096M 0% 75% Message from Primary: 00:02:20 10.182.136.193 hr_dv hr_dv 3324M/4096M 0% 81% Message from Primary: 00:02:30 10.182.136.193 hr_dv hr_dv 3564M/4096M 0% 87% Message from Primary: 00:02:40 10.182.136.193 hr_dv hr_dv 3809M/4096M 0% 93% Message from Primary: 00:02:50 10.182.136.193 hr_dv hr_dv 4070M/4096M 0% 99% 00:02:51 10.182.136.193 hr_dv hr_dv 4096M/4096M 0% 100% VxVM VVR vxrsync INFO V-5-52-2217 The volumes are verified as identical. VxVM VVR vxrsync INFO V-5-52-2219 VxRSync operation completed. VxVM VVR vxrsync INFO V-5-52-2220 Total elapsed time: 0:02:51 If there are differences in the data volumes, the output looks similar to the one shown below: Message from Primary: VxVM VVR vxrsync INFO V-5-52-2210 Starting volume verification to remote VxVM VVR vxrsync INFO V-5-52-2211 Source host: 10.182.136.192 VxVM VVR vxrsync INFO V-5-52-2212 Destination host(s): 10.182.136.193 VxVM VVR vxrsync INFO V-5-52-2213 Total volumes: 1 VxVM VVR vxrsync INFO V-5-52-2214 Total size: 4.000 G Eps_time Dest_host Src_vol Dest_vol F'shed/Tot_sz Diff Done 00:00:01 10.182.136.193 hr_dv hr_dv 0M/4096M 0% 0% 00:00:11 10.182.136.193 hr_dv hr_dv 231M/4096M 48% 6% Message from Primary: 00:00:21 10.182.136.193 hr_dv hr_dv 476M/4096M 23% 12% Message from Primary: 00:00:31 10.182.136.193 hr_dv hr_dv 719M/4096M 15% 18% Message from Primary: 00:00:41 10.182.136.193 hr_dv hr_dv 954M/4096M 12% 23% Message from Primary: 00:00:51 10.182.136.193 hr_dv hr_dv 1202M/4096M 9% 29% Message from Primary: 00:01:01 10.182.136.193 hr_dv hr_dv 1438M/4096M 8% 35% Message from Primary: 00:01:11 10.182.136.193 hr_dv hr_dv 1680M/4096M 7% 41% Message from Primary: 00:01:21 10.182.136.193 hr_dv hr_dv 1924M/4096M 6% 47% Message from Primary: 00:01:31 10.182.136.193 hr_dv hr_dv 2165M/4096M 5% 53% Message from Primary: 00:01:41 10.182.136.193 hr_dv hr_dv 2418M/4096M 5% 59% Message from Primary: 00:01:51 10.182.136.193 hr_dv hr_dv 2668M/4096M 4% 65% 00:02:01 10.182.136.193 hr_dv hr_dv 2906M/4096M 4% 71% Message from Primary: 00:02:11 10.182.136.193 hr_dv hr_dv 3140M/4096M 4% 77% Message from Primary: 00:02:21 10.182.136.193 hr_dv hr_dv 3386M/4096M 3% 83% Message from Primary: 00:02:31 10.182.136.193 hr_dv hr_dv 3630M/4096M 3% 89% Message from Primary: 00:02:41 10.182.136.193 hr_dv hr_dv 3881M/4096M 3% 95% Message from Primary: 00:02:49 10.182.136.193 hr_dv hr_dv 4096M/4096M 3% 100% VxVM VVR vxrsync INFO V-5-52-2218 Verification of the remote volumes found differences. VxVM VVR vxrsync INFO V-5-52-2219 VxRSync operation completed. VxVM VVR vxrsync INFO V-5-52-2220 Total elapsed time: 0:02:50 |
^ Return to Top | < Previous | Next > |
Product: Volume Replicator Guides | |
Manual: Volume Replicator 4.1 Administrator's Guide | |
VERITAS Software Corporation
www.veritas.com |