Draft Document for Review February 7, 2020 3:15 pm 8464ch09_Oper.fm 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 .  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. 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. 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. 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.  GLYPH<SM590000> Shutdown restrictions GLYPH<SM590000> Autonomic Ownership Takeover Manager (AOTM) GLYPH<SM590000> Ownership takeover GLYPH<SM590000> Pending token merge Consider the following items when going offline and coming online: Chapter 9. Configuring and operating the IBM TS7700  363