Designing Disaster Recovery Clusters using Metroclusters and Continentalclusters, Reprinted October 2011 (5900-1881)

# rcp /etc/dtsconf/caeva.map <new_node_name>:/etc/dtsconf/caeva.map
3. If you are using Metrocluster legacy packages, follow the steps mentioned below:
a. Create the Metrocluster package directory on the newly added node.
b. Copy the package control script and Metrocluster environment file from one of the existing
nodes to the same pathname on the newly added node:
# rcp <package_directory>/<package_control_Script>
<new_node_name>:<package_directory>
# rcp <package_directory>/<Metrocluster_environment_file>
<new_node_name>:<package_directory>
4. If you are using Metrocluster modular package and if node_name is set to “*” in Metrocluster
package configuration, follow the steps mentioned below:
a. Create the Metrocluster package directory on the newly added node.
b. Copy Metrocluster environment file from one of the existing nodes to the same pathname
on the newly added node:
# rcp <package_directory>/<Metrocluster_environment_file>
<new_node_name>:<package_directory>
5. If you are using Metrocluster modular package and if the node names are explicitly specified
for node_name parameter in Metrocluster package configuration, then add the newly added
node in a Metrocluster package by editing the Metrocluster package configuration and
applying the configuration:
# cmapplyconf –P <package_config_file>
Maintaining a Cluster that Uses Metrocluster Continuous Access EVA
While the package is running, a manual storage failover on Continuous Access EVA outside of
Metrocluster Continuous Access EVA software can cause the package to halt due to unexpected
condition of the Continuous Access EVA volumes. It is recommended that no manual storage failover
be performed while the package is running.
A manual change of Continuous Access EVA link state from suspend to resume is allowed to
re-establish data replication while the package is running.
Continuous Access EVA Link Suspend and Resume Modes
Upon Continuous Access links recovery, Continuous Access EVA automatically normalizes (the
Continuous Access EVA term for “synchronizes”) the source Vdisk and destination Vdisk data.
If the log disk is not full, when a Continuous Access connection is re-established, the contents of
the log are written to the destination Vdisk to synchronize it with the source Vdisk. This process of
writing the log contents, in the order that the writes occurred, is called merging. Since write ordering
is maintained, the data on the destination Vdisk is consistent while merging is in progress.
If the log disk is full, when a Continuous Access connection is re-established, a full copy from the
source Vdisk to the destination Vdisk is done. Since a full copy is done at the block level, the data
on the destination Vdisk is not consistent until the copy completes.
If all Continuous Access links fail and if failsafe mode is disabled, the application package continues
to run and writes new I/O to source Vdisk. The virtual log in EVA controller collects host write
commands and data; DR group's log state changes from normal to logging. When a DR group is
in a logging state, the log will grow in proportion to the amount of write I/O being sent to the
source Vdisks. If the links are down for a long time, the log disk may be full, and full copy will
happen automatically upon link recovery. If primary site fails while copy is in progress, the data
in destination Vdisk is not consistent, and is not usable. To prevent this, after all Continuous Access
links fail, it is recommended to manually put the Continuous Access link state to suspend mode by
using the Command View EVA UI. When Continuous Access link is in suspend state, Continuous
Access EVA will not try to normalize the source and destination Vdisks upon links recovery until
you manually change the link state to resume mode.
Building a Metrocluster Solution with Continuous Access EVA 245