Storage Foundation 8.0 Administrator's Guide - Windows
- Overview
- Setup and configuration
- Function overview
- About the client console for Storage Foundation
- Recommendations for caching-enabled disks
- Configure basic disks (Optional)
- About creating dynamic disk groups
- About creating dynamic volumes
- Set desired preferences
- Using the GUI to manage your storage
- Working with disks, partitions, and volumes
- Adding storage
- Disk tasks
- Remove a disk from the computer
- Veritas Disk ID (VDID)
- General Partition/Volume tasks
- Mount a volume at an empty folder (Drive path)
- Expand a dynamic volume
- Shrink a dynamic volume
- Basic disk and volume tasks
- Automatic discovery of SSD devices and manual classification as SSD
- Volume Manager space allocation is SSD aware
- Dealing with disk groups
- Disk groups overview
- Delete a dynamic disk group
- Detaching and attaching dynamic disks
- Importing and deporting dynamic disk groups
- Partitioned shared storage with private dynamic disk group protection
- Fast failover in clustered environments
- iSCSI SAN support
- Settings for monitoring objects
- Event monitoring and notification
- Event notification
- Configuring Automatic volume growth
- Standard features for adding fault tolerance
- Performance tuning
- FlashSnap
- FlashSnap components
- FastResync
- Snapshot commands
- Dynamic Disk Group Split and Join
- Dynamic disk group join
- Using Dynamic Disk Group Split and Join with a cluster on shared storage
- Dynamic Disk Group Split and Join troubleshooting tips
- Fast File Resync
- Volume Shadow Copy Service (VSS)
- Using the VSS snapshot wizards with Microsoft Exchange
- Using the VSS snapshot wizards with Enterprise Vault
- Using the VSS snapshot wizards with Microsoft SQL
- Copy on Write (COW)
- Using the VSS COW snapshot wizards with Microsoft Exchange
- Using the VSS COW snapshot wizards with Microsoft SQL
- Configuring data caching with SmartIO
- Typical deployment scenarios
- About cache area
- Configuring SmartIO
- Frequently asked questions about SmartIO
- Dynamic Multi-Pathing
- Configuring Cluster Volume Manager (CVM)
- Configuring a CVM cluster
- Administering CVM
- Access modes for cluster-shared volumes
- Storage disconnectivity and CVM disk detach policy
- Unconfiguring a CVM cluster
- Command shipping
- About I/O Fencing
- Administering site-aware allocation for campus clusters
- SFW for Hyper-V virtual machines
- Introduction to Storage Foundation solutions for Hyper-V environments
- Live migration support for SFW dynamic disk group
- Preparing the host machines
- Configuring the SFW storage
- Administering storage migration for SFW and Hyper-V virtual machine volumes
- Optional Storage Foundation features for Hyper-V environments
- Microsoft Failover Clustering support
- Configuring a quorum in a Microsoft Failover Cluster
- Implementing disaster recovery with Volume Replicator
- Troubleshooting and recovery
- Using disk and volume status information
- Resolving common problem situations
- Commands or procedures used in troubleshooting and recovery
- Rescan command
- Repair volume command for dynamic mirrored volumes
- Additional troubleshooting issues
- Disk issues
- Volume issues
- Disk group issues
- Connection issues
- Issues related to boot or restart
- Cluster issues
- Dynamic Multi-Pathing issues
- vxsnap issues
- Other issues
- CVM issues
- Appendix A. Command line interface
- Overview of the command line interface
- vxclustadm
- vxvol
- vxdg
- vxclus
- vxdisk
- vxassist
- vxassist (Windows-specific)
- vxsd
- vxedit
- vxdmpadm
- vxcbr
- vxsnap
- vxscrub
- sfcache
- Tuning SFW
- Appendix B. VDID details for arrays
How Volume Replicator works
Volume Replicator's purpose is to replicate data from a primary site to one or more secondary sites. It does this by using a replicated volume group (RVG) within an SFW disk group as the unit of replication.
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.