Volume Replicator 7.4.1 Administrator's Guide - Windows
- Understanding Volume Replicator
- About Volume Replicator
- Basic Volume Replicator terms
- Building blocks of Volume Replicator
- Understanding replication in the Volume Replicator environment
- Modes of replication
- Understanding data flow in Volume Replicator asynchronous mode
- Managing data during failure and recovery
- Replication concepts
- About using Volume Replicator as a disaster recovery tool
- Understanding how Volume Replicator logs writes to the Replicator Log
- Understanding replication settings for a Secondary
- Measures to protect log overflow and replication latency
- Pausing the replication
- Synchronizing the Secondary
- Understanding Volume Replicator support for FlashSnap
- About Synchronized Snapshots
- Understanding Bunker replication
- Understanding Volume Replicator Support for TCP Multi-Connection
- About Volume Replicator memory monitoring and control support
- About Volume Replicator Graphs
- Setting up replication
- Security considerations for Volume Replicator
- Setting up replication using the Setup Replicated Data Set wizard
- Setting up the Bunker RVG for replication
- Using the VEA Console for Volume Replication Operations
- Monitoring replication
- Interpreting the information in the Volume Replicator views
- Monitoring replication using the VEA console
- Checking replication performance using vxrlink stats
- Administering Volume Replicator
- Adding volumes
- Administering the RVG
- Administering replication
- Managing checkpoints
- Pausing replication using Volume Replicator
- Creating snapshots for the data volumes
- Creating synchronized snapshots using the VSS Snapshot wizard
- Administering Bunker replication
- Performing disaster recovery operation
- Deleting Volume Replicator objects
- Accessing data on Secondary host
- Performing automated system recovery (ASR)
- Alternative methods to synchronize the Secondary faster
- Obtaining statistical information through Volume Replicator Graphs
- Using the command line interface
- Administering the RDS using the vxrds command
- Resizing the data volumes
- Displaying the network statistics for the RLINK
- Administering the RVGs using the vxrvg command
- Displaying information using the vxprint command
- Creating snapshots using the vxsnap command
- Administering replicated volumes using the vxvol command
- Displaying and changing replication ports using the vrport command
- Administering the RVG using the vxedit
- Administering the RVG using the vxassist command
- Tuning Volume Replicator
- Examples: Using the command line
- Example 1: Setting up replication using the command line interface
- Example 3: Using Bunker node for disaster recovery
- Example 4: Using synchronized snapshots to restore data
- Configuring Volume Replicator in a VCS environment
- Components of a VCS cluster
- Illustrating a highly available Volume Replicator setup
- How the agents work
- Configuring the agents
- Working with existing replication service groups
- Configuring Volume Replicator with Hyper-V
- Advanced settings in Volume Replicator
- Troubleshooting Volume Replicator
- Recommendations and checks
- Recovering from problems in a firewall or NAT setup
- Recovering from problems during replication
- Error when configuring the VxSAS Service
- Operation time-out errors
- Problems when configuring Volume Replicator in a VCS environment
- Problems when setting performance counters
- Appendix A. Services and ports
- Appendix B. Using the vxrsync utility
- Appendix C. VR Advisor (VRAdvisor)
Troubleshooting Volume Replicator performance
To troubleshoot Volume Replicator performance and improve replication, you can perform certain checks which are explained below.
To calculate, check, and improve the replication performance
- When the replication is active run the following command at the command prompt. Make sure that you run this command only on the Primary.
vxrlink -i 5 stats <rlink_name>
Note the values in the Blocks column. This value indicates the number of blocks that have been successfully sent to the remote node.
- Compute replication throughput using the following formula:
((# of blocks sent successfully * block size) / stats interval) / 1024) KB.
where block size is 512 bytes.
Stats interval is the value of the time interval that is specified for the -i parameter with the vxrlink stats command. In the command example the time interval is 5 seconds.
- If the throughput computed in step 2 above is not equivalent to the expected throughput, then do the following:
Check if the DCM is active by checking the flags field in the output of the following command:
vxprint -lPV
If DCM is active, run the following command to resume replication:
vxrvg -g <diskgroup> resync <rvg>
You can also perform the Resync operation from VEA by selecting the Resynchronize Secondaries option from the Primary RVG right-click menu. Note that the Secondary becomes inconsistent during the DCM replay.
Check if there are any pending writes using the following command:
vxrlink -i 5 status <rlink_name>
If the application is not write intensive it is possible that the RLINK is mostly up-to-date, and there are not many pending updates to be sent to Secondary.
To determine the number of writes that are happening to the data volumes run the Performance Monitor tool. This tool is generally installed when the operating system is installed.
To launch the tool run perfmon from the command prompt. This launches the performance monitor. Select the (+) button to launch the Add Counters dialog. Select Dynamic Volume from the Performance Object drop-down list and select the Write Block/Sec from the Select counters from list pane.
If there are pending writes in the Replicator Log, and replication is not using the expected bandwidth, check the Timeout, Stream, and Memory error columns in the output of the vxrlink stats command.
If the number of time-out errors are high and the UDP protocol is used for replication, perform the following:
If the network has a time relay component, change the replication packet size using the following command, to reduce the number of time-out errors and improve the replication throughput:
vxrlink set packet_size=1400 <rlink_name>
Some components in the network drop UDP packets larger than the MTU size, suspecting a denial of service (DoS) attack. Changing replication packet size to 1K should improve the performance in this case.
If there are a number of memory errors, perform the following:
Run the vxtune command. The output of the command displays the default values that are set for the following tunables:
C:\Documents and Settings\administrator.INDSSMG>vxtune vol_max_nmpool_sz = 16384 kilobytes vol_max_rdback_sz = 8192 kilobytes vol_min_lowmem_sz = 1024 kilobytes vol_rvio_maxpool_sz = 32768 kilobytes compression_window = 0 kilobytes max_tcp_conn_count = 64 nmcom_max_msgs = 512 max_rcvgap = 5 rlink_rdbklimit = 16384 kilobytes compression_speed = 7 compression_threads = 10 msgq_sequence = 1 vol_maxkiocount = 1048576 force_max_conn = False tcp_src_port_restrict = False nat_support = False
Change the value of the NMCOM_POOL_SIZE (vol_max_nmpool_sz) tunable appropriately. The default (and minimum) value is 4192 (4MB) and maximum is 524288 (512MB).
After changing this value, restart the system so that the changes take effect.
Note that the value that is specified for the NMCOM_POOL_SIZE tunable is global to the system. Thus, if the node is a Secondary for two RLINKs (Primary hosts) then the value of the tunable must be set accordingly.