Each cluster in the grid keeps its own copy of the collection of tokens, which represents all of the logical volumes that exist in grid, and those copies are kept updated at the same level by the grid mechanism. When coming back online, a cluster must reconcile its own collection of tokens with the peer members of the grid, ensuring that it represents the status of the grid inventory. This reconcile operation is also referred to as token merge . 

Consider the following items when going offline and coming online: 

GLYPH<SM590000> Pending token merge 

A cluster in a grid configuration attempts to merge its token information with all of the other clusters in the grid as it goes online. When no other clusters are available for this merge operation, the cluster that is attempting to go online remains in the going online (or blocked) state indefinitely as it waits for the other clusters to become available for the merge operation. If a pending merge operation is preventing the cluster from coming online, an option is available to skip the merge step. 

Click Skip Step  to skip the merge operation. This option is available only if the cluster is in a blocked state while waiting to share pending updates with one or more unavailable clusters. When you click Skip Step , pending updates against the local cluster might remain undetected until the unavailable clusters become available. 

GLYPH<SM590000> Ownership takeover 

If ownership takeover was set at any of the peers, the possibility exists that old data can surface to the host if the cluster is forced online. Therefore, before attempting to force this cluster online, it is important to know whether any peer clusters ever enabled ownership takeover mode against this cluster while it was unavailable. In addition, if this cluster is in service, automatic ownership takeover from unavailable peers also is likely and must be considered before attempting to force this cluster online. 

If multiple clusters were offline and must be forced back online, force them back online in the reverse order that they went down in (for example, the last cluster down is the first cluster up). This process ensures that the most current cluster is available first to educate the rest of the clusters forced online. 

GLYPH<SM590000> Autonomic Ownership Takeover Manager (AOTM) 

If it is installed and configured, AOTM attempts to determine whether all unavailable peer clusters are in a failed state. If it determines that the unavailable cluster is not in a failed state, it blocks an attempt to force the cluster online. 

If the unavailable cluster is not in a failed state, the forced online cluster can be taking ownership of volumes of which it need not take ownership. If AOTM discovers that all unavailable peers failed and network issues are not to blame, this cluster is then forced into an online state. 

After it is online, AOTM can further enable ownership takeover against the unavailable clusters if the AOTM option is enabled. Also, manual ownership takeover can be enabled, if necessary. 

GLYPH<SM590000> Shutdown restrictions 

To shut down a cluster, it is necessary to be logged in to this system. To shut down another cluster, log out of the current cluster and log in to the cluster to shut down. For more information, see “Cluster Shutdown window” on page 367. 

Note:  After a shutdown  or force shutdown action, the targeted cluster (and associated cache) are powered off. A manual intervention is required on site where the cluster is physically located to power it up again. 

