 | ||
| Adding a Secondary to an RDS | ||
|---|---|---|
| Prev | Creating a Replicated Data Set | Next |
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.
Note: |
Run the vradmin addsec from the Primary node. If you run this command from the node being added as the Secondary, the command fails. |
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, associate the DCM of the required size to the data volumes before running the vradmin addsec command.
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.
If the Primary RVG includes a volume set, the vradmin addsec command associates the corresponding volume set to the Secondary, if the volume set exists on the Secondary. The volume set on the Secondary must include volumes of the same name, lengths and indices as the component volumes on the Primary. If the volume set exists on the Secondary and the volume set configuration is correct except that it does not include all of the component volumes corresponding to those in the volume set on the Primary, the vradmin addsec command attempts to add the remaining component volumes to the volume set on the Secondary and then associate the volume set to the Secondary RVG. This command succeeds if all of the remaining component volumes exist on the Secondary with the same names, lengths, and indices as the component volumes on the Primary. However, if any of the component volumes do not exist on the Secondary or have a mismatched name, length, or index, the vradmin addsec command fails with the appropriate error message.
If the volume set does not exist on the Secondary, but the component volumes exist with the same names, lengths, and indices, the vradmin addsec command creates the volume set on the Secondary and then associates it to the Secondary RVG.
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.
See Example - Creating a Primary RVG containing a volume set.
Note: |
For replication in asynchronous mode with secondary logging, the SRL size on both the Primary and Secondary must be the same. |
When you add a Secondary to an RDS, we recommend the following best practices:
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.
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 have multiple secondaries in your RDS setup, VVR automatically creates RLINKs between ever pair of secondaries. By doing 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.
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. Note that the SRL cannot be a volume set or a component volume of a volume set.
If the Primary RVG includes a volume set, make sure that the component volumes on the Secondary to be added have identical names, lengths, and indices as the component volumes on the Primary.
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
In a SAN disk group environment, if the application resides on the volume client, the Secondary data volumes must be attached to the corresponding volume client on the Secondary.
In a SAN disk group environment, if the application resides on the volume client, the Primary volume server must have network connection to the Secondary volume server and Secondary volume client.
In a SAN disk group environment, if the application resides on the volume client, the hostname or IP address for the Secondary must be available on the volume client on the Secondary.
In a SAN disk group environment, if the application resides on the volume server, the hostname or IP address for the Secondary must be available on the volume server on the Secondary.
To add a Secondary to an RDS
# vradmin -g local_diskgroup addsec local_rvgname pri_hostname \
sec_hostname
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: |
By default, SRL protection on the new Primary and Secondary RLINKs is set to autodcm. If you specify the -nodcm option, the vradmin addsec command disables SRL protection. |
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, which contains the RVG hr_rvg. 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.
# vradmin -g hrdg addsec hr_rvg seattle_priv london_priv
Example 2:
This example shows how to add the Secondary host london_priv to the RDS, which contains the RVG hr_rvg. 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.
# vradmin -g hrdg addsec hr_rvg seattle_priv london_priv \ prlink=to_london srlink=to_seattle
Example 3:
This example shows how to add a Secondary host london-v6_priv to the RDS, which contains the RVG hr_rvg. For replication, this example uses a private IPv6 network with the Primary hostname seattle-v6_priv, Secondary hostname london-v6_priv. Both hostnames london-v6_priv and seattle-v6_priv resolve to IPv6 addresses belonging to the private IPv6 network. 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.
# vradmin -g hrdg addsec hr_rvg seattle-v6_priv london-v6_priv
Example 4:
This example shows how to add a Secondary host london-v6 to the RDS, which contains the RVG hr_rvg. It creates the Secondary with the specific Primary and Secondary RLINK names to_london-v6 and to_seattle-v6. The RLINK connects the Primary host seattle-v6 and the Secondary host london-v6, which resolve to IPv6 addresses aaaa:bbbb:cccc:dddd:eeee:ffff:gggg:hhhh and pppp:qqqq:rrrr:ssss:wwww:xxxx:yyyy:zzzz respectively. On the Secondary, the RVG is added to the same disk group as the Primary, that is, hrdg. This example also automatically adds DCMs to the data volumes.
# vradmin -g hrdg addsec hr_rvg aaaa:bbbb:cccc:dddd:eeee:ffff:gggg:hhhh \ pppp:qqqq:rrrr:ssss:wwww:xxxx:yyyy:zzzz prlink=to_london-v6 \ srlink=to_seattle-v6