Search <book_title>...

InfoScale™ 9.0 Disaster Recovery Implementation Guide - Linux

Last Published: 2025-04-14

Product(s): InfoScale & Storage Foundation (9.0)

Platform: Linux

Section I. Introducing Storage Foundation and High Availability Solutions for disaster recovery
1. About supported disaster recovery scenarios
2. Planning for disaster recovery
  1. Planning for cluster configurations
  2. Planning for data replication
    1. Data replication options
    2. Data replication considerations
Section II. Implementing campus clusters
1. Setting up campus clusters for VCS and SFHA
2. Setting up campus clusters for SFCFSHA, SFRAC
Section III. Implementing replicated data clusters
1. Configuring a replicated data cluster using VVR
2. Configuring a replicated data cluster using third-party replication
Section IV. Implementing global clusters
Section V. Reference
1. Appendix A. Sample configuration files

Prerequisites for adding a Secondary to an RDS

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