Although Novell Business Continuity Clustering provides an automatic failover feature that fails over resources between peer clusters, we recommend that you manually migrate cluster resources between the peer clusters instead. For information about configuring and using automatic failover for a business continuity cluster, see Section C.0, Setting Up Auto-Failover.
A cluster resource can be migrated or failed over to nodes in the same cluster or to nodes in a peer cluster. Typically, you migrate or fail over locally to another node in the same cluster whenever it makes sense to do so. If one site fails (all nodes in a given cluster are not functional), you can use iManager to manually BCC migrate resources to any of the peer clusters. Each resource starts on its preferred node on the peer cluster where you have BCC migrated the resources.
Migrating a pool resource to another cluster causes the following to happen:
If the source cluster can be contacted, the state of the resource is changed to offline.
The resource changes from primary to secondary on the source cluster.
Any storage management unload script that is associated with the pool resource is run.
The cluster scan for new devices command is executed on the peer cluster so that the cluster is aware of LUNs that are no longer available.
On the destination peer cluster, the resource changes from secondary to primary so that it can be brought online.
Any storage management load script that is associated with the pool resource is run.
If an error is returned from the BCC load script, the resource is not brought online and remains in the offline, not comatose, state.
The cluster scan for new devices command is executed on the destination peer cluster so that the cluster is aware of LUNs that are now available.
Resources are brought online and load on the most preferred node in the cluster (that is, on the first node in the preferred node list).
HINT:You can use the cluster migrate command to start resources on nodes other than the preferred node on the destination cluster.
Resources appear as running and primary on the cluster where you have migrated them.
WARNING:Do not migrate resources for a test failover if the storage connection between the source and destination cluster is down. Possible disk problems and data corruption can occur if the down connection comes up and causes a divergence in data. This warning does not apply if resources are migrated during an actual cluster site failure.
To manually migrate cluster resources from one cluster to another:
Log in to iManager as the BCC Administrator user.
In, click > , then click the cluster name.
Select one or more cluster resources, then click.
The cluster you chose is shown as the.
is associated with the first table on the BCC Migrate page. It tells you what cluster you selected to manage the BCC. Information is provided from the point of view of that cluster.
For example, if the resource is assigned to a node in the cluster you are managing from, the cluster resource status is the same as if you were looking at the cluster itself, such asor . If the cluster resource is not assigned to the cluster you are managing from (that is, not in the current cluster), then the status is shown as .
In the list of clusters, select the cluster where you want to migrate the selected resources, then click.
The resources migrate to their preferred node on the destination cluster. If you selectas the destination cluster, the Business Continuity Clustering software chooses a destination cluster for you. The destination cluster that is chosen is the first cluster that is up in the peer clusters list for this resource.
View the state of the migrated resources by selecting, then select the Cluster object of the cluster where you have migrated the resources.
The migration or failover of NSS pools or other resources between peer clusters can take additional time compared to migrating between nodes in the same cluster. Until the resource achieves astate, iManager shows multiple states as the resource is unloaded from the node in the source cluster and loaded successfully on its preferred node in the destination cluster.