The following is a summary of how Volume Replicator works:

• Through the Volume Replicator software, the volumes to be replicated on the primary site are identified as part of an RVG, which consists of one or more volumes in a SFW disk group. If you have multiple disk groups with volumes to be replicated, each disk group must have a separate RVG. It is possible to have more than one RVG per disk group.

• With each RVG, a Replicator Log volume is also set up.

  The Replicator Log volume at the primary site holds the writes that are to be sent to the secondary site.

• A corresponding RVG and Replicator Log volume at the secondary site are also set up.

  An identical disk group and volume setup is created on the secondary site. The disk groups and volumes must be of the same size and have the same names as those on the primary site. The volumes do not have to be the same volume type.

  The Replicator Log volume on the secondary site must have the same name as on the primary site, but its size can differ. However, Veritas recommends that the two log volumes be the same size.

  The secondary site Replicator Log is held in reserve so that it can be used if the primary site goes down or has to be migrated and the secondary site needs to become the new primary site.

• The RVG at the primary site and the corresponding RVG at the secondary site are called a Replicated Data Set (RDS). Most Volume Replicator commands operate on an RDS. Normally, you can perform Volume Replicator operations from any host in an RDS.

• Once the Volume Replicator components are properly installed and configured, replication starts.

  Volume Replicator uses the Replicator Log volume on the primary site to track all the writes to the application or file system in the order that they were received and then transmits the writes to the secondary site. Each write to a data volume under an RVG on the primary site generates two writes: The first one is sent to the Replicator Log, and when that is complete, the other is sent to the application data volumes and to the secondary site at the same time.

  When the secondary system receives a write, it sends an initial acknowledgment of the receipt back to the primary site, even before the write is committed to disk. This is called the "Network Acknowledgment." Once the secondary commits the write to disk, a second acknowledgment, called the "Data Acknowledgment," is sent to the primary system. The Replicator Log volume on the primary system discards the write when it receives the Data Acknowledgment.

  Replication is a unidirectional process. The updates on the primary host are sent to the secondary host, but access to the data at the secondary host or hosts is read-only on the replication volumes.

• The three modes of replication - synchronous, asynchronous, and synchronous override - work as follows:

  • The synchronous mode waits until the Network Acknowledgment has been received from the secondary host before it completes the write to the application. Thus, the primary and the secondary have the same data.

  • The asynchronous mode completes the application write after it has been written to the primary Replicator Log volume.

    If the primary site goes down, there may still be some writes that were not yet received at the secondary site. This mode has better performance but with a risk of some data loss.

  • The synchronous override is a mode of replication that is synchronous as long as the network is available, but when the network becomes unavailable, the replication is continued in the asynchronous mode.

• If a disaster occurs on the primary site and its data is destroyed, a secondary host can take over the role of the primary host to make the data accessible. You can then restart the application on that host.

• You can also manually migrate the role of a healthy primary host to a secondary host when the application that is involved in replication is inactive. You may want to do this for maintenance purposes.