Creating a Replicated Data Set

To create a Replicated Data Set (RDS), perform the following tasks in the order presented below:

  Create a Primary Replicated Volume Group (RVG) of the RDS

For information on how to associate volume-set component volumes to an RDS, see Associating the Component Volumes of a Volume Set to an RDS.

  Add a Secondary to the RDS

  Change the Replication Settings for the Secondary

The following sections explain each task in detail.

Creating a Primary RVG of an RDS

The first step in creating an RDS is creating its Primary RVG. VVR enables you to create a Primary RVG of an RDS using the vradmin createpri command.

The vradmin createpri command enables you to associate existing data volumes and the Storage Replicator Log (SRL) to the Primary RVG. The vradmin createpri command performs the following operations:

• Creates the Primary RVG on the host on which the command is issued.
• Enables or starts the Primary RVG.
• Associates DCMs to the data volumes in the RVG.
• Associates the specified data volumes and SRL to the RVG.

VVR does not support RAID-5 volumes, that is, volumes with usage type raid5 are not supported. Data volumes must be of usage type gen or fsgen. However, data volumes can be configured on hardware-based RAID-5 disks.

Dirty Region Logs (DRLs) are not needed with VVR because VVR uses the SRL to recover volumes, not the DRLs. If any of the data volumes or the SRL has a DRL, the vradmin createpri command removes the DRL before the data volume is associated to the RVG.

By default, the vradmin createpri command adds DCMs to the data volumes, if they have not already been added. The vradmin createpri command creates the DCM of an appropriate default size based on the size of the volume and mirrors the DCM by default. To create and add a DCM of a size that is different from the default, see Associating a Data Change Map to a Data Volume. Run the vradmin createpri command after you have associated the DCMs of the required size to the data volumes.

The -nodcm option when used with the vradmin createpri command associates data volumes to the RVG but does not add DCMs to the data volumes.

If you want to associate additional volumes to the RVG after creating the RVG, use the vradmin addvol command. See Associating a Volume to a Replicated Data Set.

Prerequisites for creating a Primary RVG of an RDS

  The data volumes and SRL must exist on the Primary. If the data volumes and SRL do not exist on the Primary, create them. Note that a volume that is to be configured as an SRL cannot be a part of a volume set.

  The data volumes and SRL must be started. If the data volumes and SRL are not started, start them. When a data volume is started, its state is ACTIVE.

  The data volumes used by the application must exist in the same RVG. Include the data volumes used by the application in the same RVG.

  To create a Primary RVG of an RDS

Issue the following command on the host on which you want to create the Primary RVG:

The argument rvgname is the name of the RVG to be created.

The argument dv01_name,dv02_name,... is a comma-separated list of the names of the data volumes to be associated to the RVG. If the volumes are component volumes of a volume set, then specify the names of the component volumes, not the name of the volume set.

The argument srl_name is the name of the SRL to be associated to the RVG.

Use -nodcm option if you do not want DCMs to be added to the data volumes. By default, DCMs are added automatically.

Example:

This example shows how to create a Primary RVG hr_rvg in the disk group hrdg, which contains the data volumes hr_dv01 and hr_dv02, and the volume hr_srl that is to be used as the SRL. This example automatically adds DCMs to the data volumes.

Adding a Secondary

After creating the Primary RVG of the RDS, go on to adding a Secondary. Use the vradmin addsec command to add a Secondary RVG to an RDS. This command can also be used to add additional Secondary RVGs. The vradmin addsec command can be issued from any host that is already in the RDS.

The vradmin addsec command performs the following operations by default:

• Creates and adds a Secondary RVG of the same name as the Primary RVG to the specified RDS on the Secondary host. By default, the Secondary RVG is added to the disk group with the same name as the Primary disk group. Use the option -sdg with the vradmin addsec command to specify a different disk group on the Secondary.
• If any of the data volumes or the SRL on the Secondary has a DRL, the DRL is removed before the data volume is associated to the RVG. DRLs are not needed with VVR because VVR uses the SRL to recover volumes, not the DRLs.
• Automatically adds DCMs to the Primary and Secondary data volumes if they do not have DCMs. Use the -nodcm option to specify that DCMs are not to be added to the data volumes.

The vradmin addsec command creates the DCM of an appropriate default size based on the size of the volume and mirrors the DCM by default. To create and add a DCM of a size that is different from the default, see Associating a Data Change Map to a Data Volume. Run the vradmin addsec command after you have associated the DCMs of the required size to the data volumes.

• Associates to the Secondary RVG, existing data volumes of the same names and sizes as the Primary data volumes; it also associates an existing volume with the same name as the Primary SRL, as the Secondary SRL.
• Creates and associates to the Primary and Secondary RVGs respectively, the Primary and Secondary RLINKs with default RLINK names rlk_remotehost_rvgname. If you choose to use names other than the default, use the prlink and srlink attributes of the vradmin addsec command to specify the Primary and Secondary RLINK names. For an example of how to specify the RLINK names, see Example 2:.

Best practices for adding a Secondary

• Determine the network and IP addresses to use. Add all participating system names and IP addresses to the /etc/hosts files on each system or to the name server database of your name service. Make sure the IP addresses are available (that is, plumbed and up) on the appropriate hosts for your configuration.
• Plan ahead for application clustering by configuring the IP addresses used for replication as virtual IP addresses. For each replicated data set, the Primary and the Secondary cluster should each have one unique virtual IP address to use as the address for the RLINK. If you do this, you can place VVR under cluster control without having to modify the IP address of the RLINK later. Changing the IP address of an RLINK requires pausing replication.
• Plan the bandwidth of the network based on your requirement. You can choose to use either the UDP protocol or TCP protocol for network communication between the Primary and Secondary. Also, plan to operate in a firewall environment. For more information, see the VERITAS Volume Replicator Planning and Tuning Guide.
• We recommend that you use the following naming conventions for RLINKs.By default, VVR follows the following naming conventions for RLINKs:

Primary RLINK: rlk_remotehost_rvgname. For example: rlk_london_hr_rvg

Secondary RLINK: rlk_remotehost_rvgname. For example: rlk_seattle_hr_rvg

• If you plan to have multiple secondaries in your RDS setup, we recommend that you create RLINKs between every pair of secondaries. If you do this, the additional secondaries will be automatically added to the RDS after the migrate operation has completed successfully.
• Associate a DCM to each data volume on the Primary and the Secondary to use the SRL Protection and Failback Logging features.

Prerequisites for adding a Secondary

On the Secondary to be added, do the following:

  Create a disk group with the same name as the Primary disk group.

  Create data volumes of the same names and lengths as the Primary data volumes.

  Create an SRL of the same name as the Primary SRL.

  If any of the volumes in the Primary RVG are component volumes of a volume set, then make sure that the component volumes on the Primary and the Secondary to be added have identical indices.

  Make sure the /etc/vx/vras/.rdg file on the Secondary host to be added to the RDS contains the Primary disk group ID. Ensure that each disk group ID entry in the .rdg file is on a separate line. Refer to the .rdg file for the sample format for the disk group ID entry.

The vradmin addsec command checks whether the Primary RVG is authorized to create a corresponding Secondary RVG on the specified Secondary host. A Primary is determined as authorized if the /etc/vx/vras/.rdg file on the specified Secondary host contains the Primary disk group ID. If the Primary contains multiple RVGs in the same disk group, only one entry is required. A plus (+) sign in the /etc/vx/vras/.rdg file on the Secondary host indicates that all Primary RVGs on all hosts are authorized to create a Secondary RVG on the specified Secondary host.

The /etc/vx/vras/.rdg file on the Secondary host is only used for authorization checking when a Secondary is added, or when remote data volumes are synchronized or verified. To perform these operations after a Secondary takes over from the Primary, the original Primary host should also have an /etc/vx/vras/.rdg file containing the disk group ID for the new Primary host.

To display the Primary disk group ID, issue the following command on the Primary host:


  # vxprint -l diskgroup

For example, to enable host seattle to create an RVG on Secondary host london the .rdg file on the host london must have the following entries, each on a new line.


1083007373.10.seattle

  To add a Secondary to an RDS

The argument local_diskgroup is the name of the disk group on the local host.

The argument local_rvgname is the name of the RVG on the local host.

The arguments pri_hostname and sec_hostname are either resolvable hostnames or IP addresses for the Primary and the Secondary hosts. These names are used as local_host and remote_host attributes while creating RLINKs. The local_host and remote_host specify the network connection to use for the Primary and Secondary RLINKs.

Use the -nodcm option if you do not want to add DCMs to the data volumes. By default, DCMs are automatically added unless the -nodcm option is specified.

Note that the Secondary RVG is added to the disk group with the same name as the Primary disk group, unless specified otherwise using the -sdg option.

Example 1:

This example shows how to add a Secondary host london_priv to the RDS of which hr_rvg is a member. For replication, this example uses a private network with the Primary hostname seattle_priv, Secondary hostname london_priv. On the Secondary, the RVG is added to the same disk group as the Primary, that is, hrdg. This example automatically adds DCMs to the data volumes.

Example 2:

This example shows how to add the Secondary host london_priv to the RDS of which hr_rvg is a member. It creates the Secondary with the specific Primary and Secondary RLINK names to_london and to_seattle. The RLINK connects the Primary host seattle_priv and the Secondary host london_priv. On the Secondary, the RVG is added to the same disk group as the Primary, that is, hrdg.

Changing the Replication Settings for a Secondary

When you add a Secondary to an RDS, the default replication attributes of the Secondary are set to synchronous=off, latencyprot=off, srlprot=autodcm, packet_size=8400 and bandwidth_limit=none. You can set up the replication mode, latency protection, SRL protection, transport protocol, packet size, and the bandwidth used by VVR using the replication attributes, such as synchronous, latencyprot, and srlprot. These attributes are of the form attribute=value. Each attribute setting could affect replication and must be set up with care. The vradmin set command enables you to change the replication settings between the Primary and a Secondary. This command can be issued from any host in the RDS. It enables you to perform the following tasks:

• Setting the Mode of Replication
• Setting the Latency Protection
• Setting the SRL Overflow Protection
• Setting the Network Transport Protocol
• Setting the Packet Size
• Controlling the Network Bandwidth Used for Replication

The vradmin set command changes the corresponding attributes on both the Primary and Secondary RLINK. The three attributes synchronous, latencyprot, and srlprot are only active on the Primary RLINK; however, the Secondary attributes are already set up and ready for use if the Primary role is transferred to the Secondary.

Setting the Mode of Replication

VVR replicates in two modes: synchronous and asynchronous. The decision to use synchronous or asynchronous mode must be made with an understanding of the effects of this choice on the replication process and the application performance. You can set up VVR to replicate to a Secondary in synchronous or asynchronous mode by setting the synchronous attribute of the RLINK to override, or off respectively.

Setting the synchronous attribute to override puts the RLINK in synchronous mode. During normal operation, VVR replicates in synchronous mode, but if the RLINK becomes inactive due to a disconnection or administrative action, VVR switches temporarily to asynchronous mode and continues to receive updates from the application and store them in the SRL. After the connection is restored and the SRL is completely drained, the RLINK automatically switches back to synchronous mode. Most system administrators set the synchronous attribute to override.

The vradmin command does not allow you to set the synchronous attribute to fail. Use the vxedit command to set the attribute synchronous=fail. For more information on using the vxedit command, refer to the vxedit manual page.

  To enable asynchronous mode of replication

To set the replication to asynchronous mode, set the synchronous attribute to off.

The argument local_rvgname is the name of the RVG on the local host and represents its RDS.

The argument sec_hostname is the name of the Secondary host displayed in the output of the vradmin printrvg command. If the RDS contains only one Secondary, the argument sec_hostname is optional.

Example:

To set the mode of replication to asynchronous for the RDS hr_rvg between the Primary seattle and the Secondary london, issue the following command on any host in the RDS:

  To enable synchronous mode of replication

To set the synchronous attribute of the RLINK to override, use the following command:

Example:

To set the mode of replication to synchronous for the RDS hr_rvg between the Primary seattle and the Secondary london, issue the following command on any host in the RDS:

Setting the Latency Protection

The Latency Protection feature of VVR protects the Secondary host from falling too far behind in updating its copy of data when replicating in asynchronous mode. The Latency Protection feature limits the number of outstanding writes lost in a disaster. It enables automatic control of excessive lag between the Primary and Secondary hosts when replicating in asynchronous mode. For details, see Latency Protection---latencyprot attribute.

The vradmin set command enables you to set the latencyprot attribute to override, fail, or off; it also enables you to specify a latency_high_mark and a latency_low_mark, which indicate when the protection becomes active or inactive.

  To enable latency protection

Set the latencyprot attribute to enable latency protection between a Primary and a Secondary:

1. Set the latencyprot attribute of the corresponding RLINKs on the Primary and Secondary.

   To set the latencyprot attribute to override:

   
     # vradmin -g diskgroup set local_rvgname sec_hostname \
          latencyprot=override

   To set the latencyprot attribute to fail:

   
     # vradmin -g diskgroup set local_rvgname sec_hostname \ 
          latencyprot=fail
2. Set the latency_high_mark and the latency_low_mark attributes:
     # vradmin -g diskgroup set local_rvgname sec_hostname \
         latency_high_mark=high_mark
     # vradmin -g diskgroup set local_rvgname sec_hostname \
          latency_low_mark=low_mark

   The argument local_rvgname is the name of the RVG on the local host and represents the RDS.

   The argument sec_hostname is the name of the Secondary host as displayed in the output of the vradmin printrvg command.

   Note that the value of latency_high_mark must be greater than the value of latency_low_mark. We recommend that the difference between the value of latency_high_mark and the value of latency_low_mark be a small number, for example, 50.

  To disable latency protection

Setting the latencyprot attribute to off disables latency protection. This does not limit the number of waiting updates in the SRL.

To set the latencyprot attribute to off:

The argument local_rvgname is the name of the RVG on the local host and represents the RDS.

The argument sec_hostname is the name of the Secondary host as displayed in the output of the vradmin printrvg command.

Setting the SRL Overflow Protection

VVR provides the following modes of SRL overflow protection: autodcm, dcm, and override. For details, see Protection Against SRL Overflow---srlprot attribute. The vradmin set command enables you to set up SRL protection by setting the srlprot attribute of the corresponding RLINK to either autodcm, dcm, override.

  To enable SRL overflow protection

To set the srlprot attribute to autodcm, use the following command:

To set the srlprot attribute to dcm, use the following command:

To set the srlprot attribute to override, use the following command:

The argument local_rvgname is the name of the RVG on the local host and represents the RDS.

The argument sec_hostname is the name of the Secondary host as displayed in the output of the vradmin printrvg command.

Setting the Network Transport Protocol

The value specified for the protocol attribute determines the protocol that will be used to communicate between the hosts. You can specify one of the following values for the protocol attribute.

• UDP---The hosts will communicate using UDP/IP protocol. This is the default. If no protocol is specified, then UDP will be used as the protocol of communication between hosts.
• TCP---The hosts will communicate using TCP/IP protocol.

---

  Note    UDP and TCP are case sensitive.

---

  To set the network protocol

To set the protocol for RDSs in disk group of version 120 or above, the following vradmin command can be used:

The argument protocol_name is the name of the protocol that the Primary will use to replicate to the Secondary. The protocol can be set to either TCP or UDP.

Setting the Packet Size

The packet size determines the number of bytes in a packet that are sent to the Secondary host. The packet size can be changed using the packet_size attribute for UDP mode only. If the protocol is set to TCP, the data is sent using the TCP stream. For more information on the packet_size attribute, see the VERITAS Volume Replicator Planning and Tuning Guide.

  To set the packet_size

The argument local_rvgname is the name of the RVG on the local host and represents the RDS.

The argument sec_hostname is the name of the Secondary host as displayed in the output of the vradmin printrvg command.

The argument n represents the packet size in bytes.

The minimum value for the packet_size is 1300 bytes.

The maximum value of the packet_size is 65464 bytes.

Example:

To set the packet size between the Primary host seattle and the Secondary host london to 1400 bytes, issue the following command on any host in the RDS:

Controlling the Network Bandwidth Used for Replication

VVR uses the network to replicate data from the Primary to the Secondary. The Bandwidth Throttling feature enables you to control the maximum network bandwidth to be used by VVR for replication. Bandwidth Throttling controls the rate at which data is sent from the Primary to the Secondary; it does not limit the rate at which the network acknowledgements are sent from the Secondary to the Primary.

You might want to control the bandwidth used by VVR depending on factors such as whether the available network connection is to be used by other applications or exclusively for VVR, the network costs, and network usage over time. For example, if the network is used for purposes other than replication, you might have to control the network bandwidth used by VVR.

Decide on the bandwidth limit for VVR depending on the bandwidth required for VVR, and the bandwidth required for other purposes. For information on how to decide the bandwidth limit to specify for VVR, refer to the VERITAS Volume Replicator Planning and Tuning Guide, and the VERITAS Volume Replicator Advisor User's Guide.

VVR enables you to change the network bandwidth used for replication to a Secondary even when replication is in progress. It is not necessary to pause replication before you change the bandwidth limit for a Secondary or for an RDS.

Use the vrstat command to determine the network bandwidth currently used by VVR. For instructions, see Determining the Network Bandwidth Being Used by VVR.

Use the bandwidth_limit attribute of the vradmin set command to set the limit on the network bandwidth used to replicate from the Primary to the Secondary. For example, if bandwidth_limit is set to 30 mbps, VVR uses 30 mbps for replication. If bandwidth_limit is set to none, then VVR uses the available network bandwidth. The default value is none.

You can also control the network bandwidth used by VVR when synchronizing volumes, which are not part of an RDS; use the bandwidth_limit attribute of the vradmin syncvol command to specify the limit.

For example, if bandwidth_limit is set to 30 mbps for replication between a Primary and Secondary in an RDS, and the bandwidth limit to be used when synchronizing volumes that are not part of an RDS using the vradmin syncvol command is specified as 10 mbps, then together VVR will use a maximum of 40 mbps.

  To control the network bandwidth used for replication

To limit the bandwidth used for replication between the Primary and a Secondary in an RDS, issue the following command on any host in the RDS. In the command, you can either use the units of bandwidth kbps, mbps, or gbps, or abbreviate the units of bandwidth to k, m, g, respectively. The default unit of bandwidth is bits per second (bps).

The argument local_rvgname is the name of the RVG on the local host and represents the RDS.

The argument sec_hostname is the name of the Secondary host as displayed in the output of the vradmin printrvg command.

Example:

To limit the bandwidth to 30 mbps for the RDS hr_rvg between the Primary seattle and the Secondary london, issue the following command on any host in the RDS:

  To disable Bandwidth Throttling for a Secondary

To disable Bandwidth Throttling for a Secondary in an RDS, issue the following command on any host in the RDS:

The argument local_rvgname is the name of the RVG on the local host and represents the RDS.

The argument sec_hostname is the name of the Secondary host as displayed in the output of the vradmin printrvg command.

Example:

To disable Bandwidth Throttling for replication between the Primary seattle and the Secondary london of RDS hr_rvg, issue the following command on any host in the RDS:

  To control the network bandwidth used to synchronize volumes

To limit the network bandwidth used by VVR when synchronizing volumes that are not part of an RDS, issue the following command:

The argument local_vols_list is a comma-separated list of volumes on the local host. The names of the volumes on the local and remote hosts are assumed to be the same.

The argument remote_hostname is a space-separated list of names of the remote hosts on which the volumes to be resynchronized reside. It must be possible for IP to resolve the remote host names.

Example:

This example shows how to limit the network bandwidth used by VVR when using full synchronization to synchronize the remote volumes on host london with the local volumes hr_dv01, hr_dv02, hr_dv03 in the disk group hrdg on the local host seattle. The names of the disk group and the volumes on the remote host are the same as the names of the disk group and volumes on the local host.