Veritas Access Appliance Administrator's Guide
- Section I. Introducing Access Appliance
- Section II. Configuring Access Appliance
- Managing users
- Configuring the network
- Configuring authentication services
- Configuring user authentication using digital certificates or smart cards
- Section III. Managing Access Appliance storage
- Configuring storage
- Managing disks
- Access Appliance as an iSCSI target
- Configuring storage
- Section IV. Managing Access Appliance file access services
- Configuring the NFS server
- Setting up Kerberos authentication for NFS clients
- Using Access Appliance as a CIFS server
- About configuring CIFS for Active Directory (AD) domain mode
- About setting trusted domains
- About managing home directories
- About CIFS clustering modes
- About migrating CIFS shares and home directories
- About managing local users and groups
- Using Access Appliance as an Object Store server
- Configuring the NFS server
- Section V. Managing Access Appliance security
- Section VI. Monitoring and troubleshooting
- Configuring event notifications and audit logs
- About alert management
- Appliance log files
- Configuring event notifications and audit logs
- Section VII. Provisioning and managing Access Appliance file systems
- Creating and maintaining file systems
- Considerations for creating a file system
- About managing application I/O workloads using maximum IOPS settings
- Modifying a file system
- Managing a file system
- Creating and maintaining file systems
- Section VIII. Provisioning and managing Access Appliance shares
- Creating shares for applications
- Creating and maintaining NFS shares
- About the NFS shares
- Creating and maintaining CIFS shares
- About the CIFS shares
- About managing CIFS shares for Enterprise Vault
- Integrating Access Appliance with Data Insight
- Section IX. Managing Access Appliance storage services
- Configuring episodic replication
- Episodic replication job failover and failback
- Configuring continuous replication
- How Access Appliance continuous replication works
- Continuous replication failover and failback
- Using snapshots
- Using instant rollbacks
- Configuring episodic replication
- Section X. Reference
How Access Appliance continuous replication works
The Access Appliance continuous replication implements Cluster Volume Replication (CVR) method internally. It is based on volume level replication.
It includes the following components:
Replicated Volume Group (RVG)
A Replicated Volume Group (RVG) is a group of volumes or file sets within a given Volume Manager (VxVM) disk group which is configured for replication. The volumes in an RVG are consistent while replicating data. An RVG is always a subset of a VxVM disk group. One or more related volumes in a disk group can be configured as an RVG.
Volumes that are associated with an RVG and contain application data are called data volumes. The data volumes in the RVG are under the control of an application.
During replication, the write-order is strictly maintained within an RVG to ensure that each remote volume is always consistent, both internally and with all other volumes of the group. CVR replicates data from a primary RVG on the host (where the application is running) to the secondary RVG. An RVG also contains the Storage Replicator Log (SRL) and Replication Link (RLINK), which are used internally by CVR.
Storage Replicator Log (SRL)
The Storage Replicator Log (SRL) is a circular buffer of writes for an RVG. Each RVG contains one SRL. Writes to the data volumes in the RVG are first queued in the SRL on the primary host before they are sent to the secondary. CVR uses the SRL to track the order of writes to data volumes in the RVG. The SRL enables continuous replication to maintain write-order fidelity at the secondary RVG.
Replication Link (RLINK)
An RLINK is associated with an RVG and establishes the link between the primary and the secondary RVG. Each RLINK associated with a primary RVG represents one secondary. Each RLINK associated with a secondary RVG represents the primary.
Data Change Map (DCM)
The Data Change Map (DCM) is another important component of CVR that is used to track writes when the SRL overflows. It enables you to avoid complete resynchronization of the data on the secondary. The DCM contains a bitmap. The DCM is active only on the primary side. The DCM becomes active only when the SRL is no longer large enough to hold accumulated updates. While the DCM is active, each bit that has been set in the DCM represents a region whose contents are different between the primary and the secondary.
Replicated Data Set (RDS)
A Replicated Volume Group (RVG) on the primary host and its counterparts on the secondary hosts make up a Replicated Data Set (RDS). An RDS enables grouping of the RVG on the primary and its counterparts on the secondary. The concept of primary host and secondary host is used only in the context of a particular Replicated Data Set (RDS).
If a synchronous operation for a file system is paused, replication stops when the SRL (Storage Replicator Log) overflows and the replication> continuous status command displays the replication status as "logging to DCM (needs dcm resynchronization)
". If the replicator log (SRL) overflows, the RDS (Replicated Data Set) begins to track the writes using the DCM (Data Change Map). If the DCM is in use, replication stops and all the new writes are tracked in the DCM on the primary. To avoid this:
Execute the replication continuous status <fs-name> command on CLISH.
Check the output for the value of Replicated Data Set. This refers to the RVG name.
Resynchronize the DCM by running the vradmin resync <rvg name> command from bash and wait for resync to complete.