Previous  |  Next  >  
Product: Volume Replicator Guides   
Manual: Volume Replicator 4.1 Administrator's Guide   

Examples for Setting Up a Simple Volume Replicator Configuration

The examples in this section explain how to use VERITAS Volume Replicator (VVR) to set up a simple VVR configuration under different situations. The examples explain how to set up a VVR configuration with one Secondary and hence one RLINK; however, VVR enables you to configure and set up configurations with multiple Secondaries. The examples give the steps to replicate from the Primary host seattle to the Secondary host london.

Assumptions:

  • These examples assume that the Primary seattle and Secondary london have a disk group named hrdg with enough free space to create the VVR objects mentioned in the example.
  • Examples 1, 2, 3, 4, and 5 assume that the Primary data volumes have been set up and contain data.
  • The examples assume that the /etc/vx/vras/.rdg file on the Secondary host contains the Primary diskgroup ID. Ensure that each disk group ID entry in the .rdg file appears on a separate line. A Secondary can be added to an RDS only if the /etc/vx/vras/.rdg file on the Secondary host contains the Primary disk group ID. Use the vxprint -l diskgroup command to display the disk group ID of the disk group hrdg, which is being used.

Configuration Considerations:

Consider the following in each example:

    Checkmark  The data volumes on the Secondary must have the same names and sizes as the data volumes on the Primary.

    Checkmark  The name of the Storage Replicator Log (SRL) on the Secondary must be the same as the name of the SRL on the Primary.

    Checkmark  The SRL must be created on disks that do not have other volumes on them.

    Checkmark  The data volumes and SRL must be mirrored.

In the examples, each data volume is 4 GB; the Primary and Secondary SRL are 4 GB each.

The examples in this chapter use the following names:

Primary Hostname: seattle

hrdg

Disk group

hr_rvg

Primary RVG

rlk_london_hr_rvg

Primary RLINK to Secondary london

hr_dv01

Primary data volume #1

hr_dv02

Primary data volume #2

hr_srl

Primary SRL volume

Secondary Hostnamelondon 

hrdg

Disk group

hr_rvg

Secondary RVG

rlk_seattle_hr_rvg

Secondary RLINK to Primary seattle

hr_dv01

Secondary data volume #1

hr_dv02

Secondary data volume #2

hr_srl

Secondary SRL volume

Creating a Replicated Data Set for the Examples

Perform the following steps to create a Replicated Data Set (RDS) for all the examples in this section, except Example 4---Setting Up Replication Using Disk Group Split and Join.


Note   Note    This example assumes that the disks available on the system have labels such as disk01, disk02, disk03 and so on.
  1. Create the data volumes on the Secondary host london. Use different disks for the data volumes and SRL.
    # vxassist -g hrdg make hr_dv01 4G \
    layout=mirror logtype=dcm mirror=2 disk01 disk02

    # vxassist -g hrdg make hr_dv02 4G \
    layout=mirror logtype=dcm mirror=2 disk03 disk04
  2. Create the SRL on disks that do not have other volumes on them by typing the following command on the Primary seattle and the Secondary london:
      # vxassist -g hrdg make hr_srl 4G mirror=2 disk05 disk06
    Note   Note    You must create the SRL on disks that do not contain any other volume.
  3. Create the Primary RVG of the RDS by typing the following command on the Primary seattle:
      # vradmin -g hrdg createpri hr_rvg hr_dv01,hr_dv02 hr_srl
  4. Make sure the /etc/vx/vras/.rdg file on the Secondary host london contains the Primary disk group ID of hrdg; then add the Secondary london to the RDS by typing the following command on the Primary seattle:
      # vradmin -g hrdg addsec hr_rvg seattle london

Example 1---Setting Up Replication Using Automatic Synchronization

This example assumes that the RDS has been created using the procedure Creating a Replicated Data Set for the Examples. You can synchronize the Secondary using automatic synchronization when the application is active or inactive.

  • Start Secondary synchronization and replication using automatic synchronization by issuing the following command from any host in the RDS:

  •   # vradmin -g hrdg -a startrep hr_rvg london

Example 2---Setting Up Replication Using Full Synchronization

This example assumes that the RDS has been created using the procedure Creating a Replicated Data Set for the Examples. You can synchronize the Secondary using full synchronization with checkpoint when the application is active or inactive.

  1. Synchronize the Secondary RVG hr_rvg on london with its Primary RVG on seattle using full synchronization with checkpoint:
      # vradmin -g hrdg -full -c chkpt_presync syncrvg hr_rvg london
  2. Start replication with checkpoint by issuing the following command on any host in the RDS:
      # vradmin -g hrdg -c chkpt_presync startrep hr_rvg london

Example 3---Setting Up Replication Using Block-level Backup and Checkpointing

This example assumes that the RDS has been created using the procedure Creating a Replicated Data Set for the Examples. You can synchronize the Secondary using block-level backup and checkpointing when the application is active or inactive.

  1. Start a checkpoint on the Primary:
      # vxrvg -g hrdg -c checkpt_presync checkstart hr_rvg

    Note down the checkpoint name you use, that is, checkpt_presync.

  2. Perform a block-level backup of the data volumes in the Primary RVG.
  3. End the Primary checkpoint when the backup is complete:
      # vxrvg -g hrdg checkend hr_rvg
  4. Restore the backup to the Secondary data volumes.
  5. Use the vxrvg cplist command on the Primary to check whether the checkpoint you created is still valid. If the checkpoint has overflowed, repeat step 1 to step 4.

    The output resembles:


    Name              MBytes     % Log   Started/Completed
    checkpt_presync             10       9     Completed
  6. Start replication using the checkpoint:
      # vradmin -g hrdg -c checkpt_presync startrep hr_rvg london
  7. On the Primary, check whether the consistent flag is set on the Primary RLINK using the vxprint command. The RLINK becomes consistent only after the data contained in the checkpoint is sent to the Secondary. Wait and then issue the following command on the Primary:
      # vxprint -g hrdg -l rlk_london_hr_rvg

    If the Secondary is consistent, the synchronization was successful.

    If the checkpoint overflows before the Secondary becomes consistent, the synchronization process has failed. Increase the size of the SRL, and then restart the procedure beginning at step 1. To resize the SRL, see Resizing the SRL.

It is likely that there might be writes beyond the checkpoint that are yet to be sent to the Secondary after consistent flag is set on the RLINK. Use the vxrlink status command to check whether the RLINK is up-to-date:


  # vxrlink -g hrdg status rlk_london_hr_rvg

The same backup and the corresponding checkpoint can be used to set up additional Secondary hosts while the checkpoint is still valid. If a checkpoint has overflowed, its corresponding backup cannot be used to resynchronize the Secondary. Eventually, any checkpoint that becomes STALE is unusable. There is no warning to indicate that this has occurred. However, the vxrvg cplist command indicates that the checkpoint has overflowed and hence is unusable. For more information, see the section Displaying a List of Checkpoints.

Example 4---Setting Up Replication Using Disk Group Split and Join

Do not perform the steps listed in Creating a Replicated Data Set for the Examples.

  1. Create the SRL on disks that do not have other volumes on them by typing the following command on the Primary seattle:
      # vxassist -g hrdg make hr_srl 4G mirror=2
    Note   Note    You must create the SRL on disks that do not contain any other volume.
  2. Create the Primary RVG of the RDS by typing the following command on the Primary seattle:
      # vradmin -g hrdg createpri hr_rvg hr_dv01,hr_dv02 hr_srl
  3. Create a snapshot plex for each data volume in the Primary RVG by issuing the following commands on the Primary seattle:
      # vxassist -g hrdg snapstart hr_dv01
      # vxassist -g hrdg snapstart hr_dv02

    You can use the -b option with the vxassist snapstart command to run the command in the background. Note that if you use the -b option of the vxassist snapstart command, you must wait for the snapshot plexes for all the data volumes in the RVG to be created and synchronized completely before you proceed to the next step. When the plex synchronization completes, the output of the vxprint command displays the state of the new snapshot plex as snapdone.

  4. Start a Primary checkpoint by issuing the following command on the Primary seattle:
      # vxrvg -g hrdg -c checkpt_presync checkstart hr_rvg
  5. Take snapshot of each data volume in the Primary RVG by issuing the following command on the Primary seattle:
      # vxrvg -g hrdg snapshot hr_rvg
  6. End the checkpoint by issuing the following command on the Primary seattle:
      # vxrvg -g hrdg checkend hr_rvg
  7. Split the snapshot volumes into a new disk group by issuing the following command on the Primary seattle:
      # vxdg split hrdg new_hrdg SNAP-hr_dv01 SNAP-hr_dv02
  8. Rename each snapshot volume in the new disk group with the same name as the corresponding data volume in the Primary RVG by issuing the following commands on the Primary seattle:
      # vxedit -g new_hrdg rename SNAP-hr_dv01 hr_dv01
      # vxedit -g new_hrdg rename SNAP-hr_dv02 hr_dv02
  9. Deport the split-off disk group, rename it to the same name as the disk group of the Primary RVG and change the ownership of the split-off disk group to be the Secondary host so that it may be automatically imported on the Secondary on reboot. To do this, issue the following command on the Primary seattle:
      # vxdg -n hrdg -h london deport new_hrdg 
  10. Physically remove the disks contained in the deported disk group by following the procedures recommended by the disk manufacturer; then attach the disks to the Secondary host.
  11. On the Secondary london, import the disks that were moved over from the Primary if not already imported.
      # vxdg import hrdg
  12. Create the SRL on disks that do not have other volumes on them by typing the following command on the Secondary london:
      # vxassist -g hrdg make hr_srl 4G mirror=2
    Note   Note    You must create the SRL on disks that do not contain any other volume.
  13. Make sure the /etc/vx/vras/.rdg file on the Secondary host london contains the Primary disk group ID of hrdg; then add the Secondary to the RDS by issuing the following command on the Primary seattle:
      # vradmin -g hrdg addsec hr_rvg seattle london
  14. Start replication by issuing the following command on any host in the RDS:
      # vradmin -g hrdg -c checkpt_presync startrep hr_rvg  london

Example 5---Setting Up Replication Using Differences-Based Synchronization

This example assumes that the RDS has been created using the procedure Creating a Replicated Data Set for the Examples. You can synchronize the Secondary using difference-based synchronization with checkpoint when the application is active or inactive.

  1. Synchronize the Secondary RVG hr_rvg on london with its Primary RVG on seattle using difference-based synchronization with checkpoint:
      # vradmin -g hrdg -c chkpt_presync syncrvg hr_rvg london
  2. Start replication with checkpoint by issuing the following command on any host in the RDS:
      # vradmin -g hrdg -c chkpt_presync startrep hr_rvg london

Example 6---Setting Up Replication When Data Volumes are Initialized with Zeroes

Because the Primary data volumes are initialized with zeroes, the data on the Secondary node need not be synchronized with the Primary. However, we recommend that you zero initialize the Secondary data volumes.

  1. Create the data volumes by typing the following commands on the Primary seattle and Secondary london. Use different disks for the data volumes and SRL.
    # vxassist -g hrdg make hr_dv01 4G \
    layout=mirror logtype=dcm mirror=2 init=zero disk01 disk02

    # vxassist -g hrdg make hr_dv02 4G \
    layout=mirror logtype=dcm mirror=2 init=zero disk03 disk04
  2. Create the SRL on disks that do not have other volumes on them by typing the following command on the Primary seattle and Secondary london:
      # vxassist -g hrdg make hr_srl 4G mirror=2 disk05 disk06
  3. Create the Primary RVG of the RDS by typing the following command on the Primary seattle:
      # vradmin -g hrdg createpri hr_rvg hr_dv01,hr_dv02 hr_srl
  4. Make sure the /etc/vx/vras/.rdg file on the Secondary host london contains the Primary disk group ID of hrdg; then add the Secondary london to the RDS by typing the following command on the Primary seattle:
      # vradmin -g hrdg addsec hr_rvg seattle london
    Note   Note    Do not start the application or mount the file system before completing step 5.
  5. Start replication using the option -f with the vradmin startrep command by typing the following command on any host in the RDS:
      # vradmin -g hrdg -f startrep hr_rvg london

After completing this step, start the application.

 ^ Return to Top Previous  |  Next  >  
Product: Volume Replicator Guides  
Manual: Volume Replicator 4.1 Administrator's Guide  
VERITAS Software Corporation
www.veritas.com