# 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