Draft Document for Review February 7, 2020 3:15 pm 8464ch02_Architecture.fm To take advantage of AOTM, you must provide an IP communication path between the  TS3000 TSSCs at the cluster sites. Ideally, the AOTM function uses an independent network  between locations, but this configuration is not a requirement. With AOTM, the user-configured takeover mode is enabled if normal communication between  the clusters is disrupted and the cluster that is running the takeover can verify that the other  cluster failed or is otherwise not operational. For more information, see 9.3.11, “Service icon”  on page 511.  When a cluster loses communication with another peer cluster, it prompts the attached local  TS3000 to communicate with the remote failing cluster’s TS3000 to confirm that the remote  TS7700 is down. If it is verified that the remote cluster is down, the user-configured takeover  mode is automatically enabled. If it cannot validate the failure or if the system consoles  cannot communicate with each other, AOTM does not enable a takeover mode. In this  scenario, ownership takeover mode can be enabled only by an operator through the MI or by  using the  LI REQ  command. Without AOTM, an operator must determine whether one of the TS7700 clusters failed and  then enable one of the ownership takeover modes. This process is required to access the  logical volumes that are owned by the failed cluster. It is important that WOT be enabled only  when a cluster failed and not when a problem exists only with communication between the  TS7700 clusters. If ownership takeover is enabled in the read/write mode against a network-inaccessible  cluster and the inaccessible cluster is in fact handling host activity, volumes can be modified  at both locations. This issue results in conflicting volume versions. When the Read Ownership  Takeover (ROT) is enabled rather than read/write mode, the original owning cluster can  continue to modify the volume where peers have read-only access to an earlier version.  Therefore, manually enabling ownership takeover when only network issues are present  should be limited to only those scenarios where host activity is not occurring to the  inaccessible cluster. If two conflicting versions are created, the condition is detected when  communications are resolved and the volumes with conflicting versions are moved into an  error state. When in this error state, the MI can be used to choose which version is most  current. Even if AOTM is not enabled, configure it to provide protection from a manual takeover mode  being selected when the cluster is functional. This extra TS3000 TSSC path is used to  determine whether an unavailable cluster is still operational. This path is used to prevent the  user from forcing a cluster online when it must not be or enabling a takeover mode that can  result in dual volume use. 2.4.34 Selective Write Protect for DR testing This function enables clients to emulate DR events by running test jobs at a DR location  within a TS7700 grid configuration and enabling volumes only within specific categories to be  manipulated by the test application. This configuration prevents any changes to  production-written data. Up to 128 categories can be identified and set to be excluded from  Write Protect Mode by using the Category Write Protect Property table.  When a cluster is write protect-enabled, all volumes that are protected cannot be modified or  have their attributes changed. Write protection is cluster scope and configured through the  MI. Settings are persistent. Chapter 2. Architecture, components, and functional characteristics  93