InfoScale™ 9.0 Replication Administrator's Guide - AIX
- Section I. Getting started with Volume Replicator
- Introducing Volume Replicator
- Understanding how Volume Replicator works
- How VVR uses kernel buffers for replication
- Replication in a shared disk group environment
- Using SmartTier with VVR
- Understanding the VVR snapshot feature
- About VVR compression
- Planning and configuring replication
- Before you begin configuring
- Choosing the mode of volume replication
- Planning the network
- Sizing the SRL
- Understanding replication settings for a Secondary
- Configuring VVR in a VCS environment
- Using the primary-elect feature to choose the primary site after a site disaster or network disruption
- Requirements for configuring VVR in a VCS environment
- Example setting up VVR in a VCS environment
- Configuring the agents for a bunker replication configuration
- Section II. Setting up and administering VVR
- Setting up replication
- Creating a Replicated Data Set
- Creating a Primary RVG of an RDS
- Adding a Secondary to an RDS
- Changing the replication settings for a Secondary
- Synchronizing the Secondary and starting replication
- Starting replication when the data volumes are zero initialized
- Displaying configuration information
- Displaying RVG and RDS information
- Displaying information about data volumes and volume sets
- Displaying information about Secondaries
- Displaying statistics with the vrstat display commands
- Collecting consolidated statistics of the VVR components
- Displaying network performance data
- Administering Volume Replicator
- Administering data volumes
- Associating a volume to a Replicated Data Set
- Associating a volume set to an RDS
- Associating a Data Change Map to a data volume as a log plex
- Resizing a data volume in a Replicated Data Set
- Administering the SRL
- Incrementally synchronizing the Secondary after SRL overflow
- Administering replication
- Administering the Replicated Data Set
- Administering Storage Checkpoints
- Creating RVG snapshots
- Using the instant snapshot feature
- About instant full snapshots
- Preparing the volumes prior to using the instant snapshot feature
- Creating instant full snapshots
- About instant space-optimized snapshots
- Creating instant space-optimized snapshots
- About instant plex-breakoff snapshots
- Administering snapshots
- Using the traditional snapshot feature
- Using Veritas Volume Manager FastResync
- Verifying the DR readiness of a VVR setup
- Backing up the Secondary
- Administering data volumes
- Using VVR for off-host processing
- Transferring the Primary role
- Migrating the Primary
- About taking over from an original Primary
- Failing back to the original Primary
- Choosing the Primary site after a site disaster or network disruption
- Troubleshooting the primary-elect feature
- Replication using a bunker site
- Introduction to replication using a bunker site
- Setting up replication using a bunker site
- Using a bunker for disaster recovery
- Replication using a bunker site in a VCS environment
- Configuring and administering VVR using System Management Interface Tool
- Accessing Volume Replicator interface in SMIT
- Setting up a simple Volume Replicator configuration using SMIT
- Displaying configuration information using SMIT
- Administering Volume Replicator using SMIT
- Taking instant snapshot of data volumes of an RVG using SMIT
- Associating a volume to a Replicated Data Set using SMIT
- Transferring the Primary role using SMIT
- Troubleshooting VVR
- Recovery from configuration errors
- Errors during an RLINK attach
- Errors during modification of an RVG
- Recovery on the Primary or Secondary
- Recovering from Primary data volume error
- Primary SRL volume error cleanup and restart
- Primary SRL header error cleanup and recovery
- Secondary data volume error cleanup and recovery
- Tuning replication performance
- SRL layout
- Tuning Volume Replicator
- VVR buffer space
- Tuning VVR compression
- VVR buffer space
- Setting up replication
- Section III. Analyzing your environment with Volume Replicator Advisor
- Introducing Volume Replicator Advisor (VRAdvisor)
- Collecting the sample of data
- About collecting the sample of data
- Collecting the sample of data on UNIX
- Collecting the sample of data on Windows
- Analyzing the sample of data
- About analyzing the sample of data
- Analyzing the collected data
- Understanding the results of the analysis
- Viewing the analysis results
- Recalculating the analysis results
- Installing Volume Replicator Advisor (VRAdvisor)
- Section IV. VVR reference
- Appendix A. VVR command reference
- Appendix B. Using the In-band Control Messaging utility vxibc and the IBC programming API
- Using the IBC messaging command-line utility
- Examples - Off-host processing
- In-band Control Messaging API
- Appendix C. Volume Replicator object states
- Appendix D. Alternate methods for synchronizing the Secondary
- Using the full synchronization feature
- Using block-level backup and Storage Checkpoint
- Using difference-based synchronization
- Examples for setting up a simple Volume Replicator configuration
- Appendix E. Migrating VVR from IPv4 to IPv6
- Migrating VVR to support IPv6 or dual stack
- About migrating to IPv6 when VCS global clustering and VVR agents are not configured
- About migrating to IPv6 when VCS global clustering and VVR agents are configured
- About migrating to IPv6 when VCS global clustering and VVR agents are configured in the presence of a bunker
- Migrating to IPv6 when VCS global clustering and VVR agents are configured in the presence of a bunker
- Appendix F. Sample main.cf files
Tunable parameters for the buffer space on the Secondary
The amount of buffer space available for requests coming in to the Secondary over the network is determined by the VVR tunable, vol_max_nmpool_sz, which defaults to 64 megabytes. VVR allocates separate buffer space for each Secondary RVG, the size of which is equal to the value of the tunable vol_max_nmpool_sz. The buffer space on the Secondary must be large enough to prevent slowing the network transfers excessively.
If the buffer is too large, it can cause problems. When a write arrives at the Secondary, the Secondary sends an acknowledgment to the Primary so that the Primary knows the transfer is complete. When the write is written to the data volume on the Secondary, the Secondary sends another acknowledgment, which tells the Primary that the write can be discarded from the SRL. However, if this second acknowledgment is not sent within one minute, the Primary disconnects the RLINK. The RLINK reconnects immediately but this causes disruption of the network flow and potentially other problems. Thus, the buffer space on the Secondary should be sized in such a way that no write can remain in it for one minute. This size depends on the rate at which the data can be written to the disks, which is dependent on the disks themselves, the I/O buses, the load on the system, and the nature of the writes (random or sequential, small or large).
If the write rate is W megabytes/second, the size of the buffer should be no greater than W * 50 megabytes, that is, 50 seconds' worth of writes.
There are various ways to measure W. If the disks and volume layouts on the Secondary are comparable to those on the Primary and you have I/O statistics from the Primary before replication was implemented, these statistics can serve to arrive at the maximum write rate.
Alternatively, if replication has already been implemented, start by sizing the buffer space on the Secondary to be large enough to avoid timeout and memory errors.
While replication is active at the peak rate, run the following command and make sure there are no memory errors and the number of timeout errors is small:
# vxrlink -g diskgroup -i5 stats rlink_name
Then, run the vxstat command to get the lowest write rate:
# vxstat -g diskgroup -i5
The output looks similar to this:
OPERATIONS BLOCKS AVG TIME(ms) TYP NAME READ WRITE READ WRITE READ WRITE Mon 29 Sep 2003 07:33:07 AM PDT vol srl1 0 1245 0 1663 0.0 9.0 vol archive 0 750 0 750 0.0 9.0 vol archive-L01 0 384 0 384 0.0 5.9 vol archive-L02 0 366 0 366 0.0 12.1 vol ora02 0 450 0 900 0.0 11.1 vol ora03 0 0 0 0 0.0 0.0 vol ora04 0 0 0 0 0.0 0.0 Mon 29 Sep 2003 07:33:12 AM PDT vol srl1 0 991 0 1389 0.0 20.1 vol archive 0 495 0 495 0.0 10.1 vol archive-L01 0 256 0 256 0.0 5.9 vol archive-L02 0 239 0 239 0.0 14.4 vol ora02 0 494 0 988 0.0 10.0 vol ora03 0 0 0 0 0.0 0.0 vol ora04 0 0 0 0 0.0 0.0
For each interval, add the numbers in the blocks written column for data volumes, but do not include the SRL. Also, do not include any subvolumes. For example, archive-L01, and archive-L02 are subvolumes of the volume archive. The statistics of the writes to the subvolumes are included in the statistics for the volume archive. You may vary the interval, the total time you run the test, and the number of times you run the test according to your needs. In this example, the interval is 5 seconds and the count is in blocks, hence on a machine with 2 kilobytes of block size, the number of megabytes per interval, M, is (total * 2048)/(1024*1024), where total is the sum for one interval. Hence, for one second the number of megabytes is M/5 and the size of the buffer is (M/5)*50. If there is more than one Primary, do not increase the buffer size beyond this number.
The writes to the SRL should not be considered part of the I/O load of the application. However, in asynchronous mode, the Secondary writes the incoming updates to both the Secondary SRL and the data volumes, so it may be necessary to make the value of vol_max_nmpool_sz slightly larger. However, to avoid the problems discussed at the beginning of this section, the calculated vol_max_nmpool_sz value should still ensure that writes do not remain in the pool for more than one minute.