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)
Volume Replicator at the Secondary
Volume Replicator sends data to the Secondary RVG as a message, based on the application write size. Each write (update) is divided into one or multiple packets based on the predefined packet size that is specified for a Secondary. These packets are later assembled at the Secondary. When the Secondary receives the message, the Secondary immediately sends an initial acknowledgment of receipt. This is known as the network acknowledgment.
The network acknowledgment allows the Primary to immediately continue processing, as required. The data is not yet written to disk on the Secondary RVG, but it is still safe because it is stored in the Primary Replicator Log volume. After the Secondary writes to the local disk, it sends the second acknowledgment, the data acknowledgment. When the Primary receives the data acknowledgement, this write is discarded from the Replicator Log volume.
The reason for the two-phase acknowledgment is performance. In synchronous mode, the Primary waits for the network acknowledgment from the Secondary before it completes the write for the application. If Volume Replicator were to wait for the write to complete on the Primary and the Secondary, it would increase latency considerably. By using the two-phase acknowledgment, Volume Replicator maintains application performance. Because data is persistently queued in the Primary Replicator Log volume, safety of the data for the Secondary is maintained.
At the Secondary host, Volume Replicator holds the packets until all the previous packets have been received. It then writes to the disks in the correct sequence to maintain consistency at the Secondary. Holding the packets in memory enables Volume Replicator to reassemble out-of-order network traffic before writing, and discover and handle missing packets. To maintain consistency at the Secondary RVG, Volume Replicator never writes an I/O out of order with the Primary RVG. Incoming data from the Primary RVG is serialized and checksummed to support accurate replay to the Secondary volumes.
The Secondary Replicator Log volume is only used in specific conditions which are as follows:
During recovery, after a Primary or Secondary crash
To store state of actual underlying volume plexes
During IBC messaging to a Secondary