The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This appendix includes information on cluster management and recovery procedures that are used when one or more switches in a Cisco IOA cluster is offline or when you want to change the master switch assignment from one switch to another switch.
This appendix includes the following sections:
This section describes the Cisco IOA cluster quorum and the process for electing the master switch in a cluster.
Every switch in a cluster has a node ID. Cisco IOA assigns a node ID to every new switch as it is added to the cluster. The switch where the cluster is created is assigned the node ID of 1. This is the master switch. When a new switch is added to the cluster, it is assigned the next available higher node ID. For example, when a second switch is added to the cluster it gets the node ID of 2 and the third switch gets the node ID of 3, and so on.
The cluster view is the set of switches that are part of the operational cluster.
For a cluster to be operational, it must include more than half the number of configured switches in the cluster view. In an N-node cluster, N/2 + 1 nodes form a cluster quorum.
If N is even, the cluster quorum requires N/2 nodes and also, the presence of the switch with the lowest node ID.
The quorum logic ensures that in the event of cluster partitions at least one partition can be operational. All other switches are nonoperational. This guarantees the consistency of the cluster.
When a cluster is created, the switch on which the cluster is created becomes the cluster master switch. When the master switch fails or is rebooted, another switch takes over as the master switch. The master election logic uses the node ID and the latest cluster configuration to determine which switch in the cluster will become the master switch. The master election logic is described as follows:
For example, there are three switches S1, S2, and S3 with node IDs 1, 2, and 3, respectively. If switches S2 and S3 form a quorum then switch S2 becomes the master switch. Even if switch S1 with the node ID of 1 comes up and joins the cluster at a later time, switch S2 continues to be the master. However, if switch S2 goes down for any reason, switch S1 will become the master switch.
According to the cluster quorum logic, a cluster with two configured switches can be operational if both switches are operational or the switch with the lowest node ID is operational.
In the latter case, the switch with the lowest node ID is the master of the one-switch cluster. The other switch could have failed or simply lost connectivity to the operational switch. In either case, the switch with the higher node ID would become nonoperational. If the node with the lower node ID failed, the other switch cannot form an operational cluster.
The examples that follow describe these scenarios. The first three examples consider single switch failures.
When the switches lose connectivity between them, the master switch S1 continues to be operational since it has the lower node ID and can form an (N/2) switch cluster. Switch S2 becomes nonoperational.
When the switches lose connectivity between them, switch S2 becomes nonoperational and S1 takes over as the master to form a 1-switch cluster. This is consistent with the quorum logic in a two-switch cluster (N/2 with lowest node ID).
When S1 comes up, S1 and S2 will form a two-switch cluster.
The next set of examples describe reboots of both switches (S1 with node ID 1 and S2 with node ID 2):
Caution | If you perform any configuration change on a cluster, you must save the running configuration to the startup configuration by entering the copy running-config startup-config CLI command on all switches before rebooting them. Otherwise, the cluster may not form correctly after the reboot (see example Example 3). |
When S2 comes up and if it happens to have the latest cluster configuration in the startup configuration (this can happen if you did not save the running configuration to the startup configuration on S1 but did so on S2), it will not be able to join the cluster formed by S1.
Caution | It is critical that you save the running configuration on all switches before a reboot. |
In a three-switch cluster, the quorum requires two switches to be in the cluster view (N/2 + 1). The examples below explain three scenarios in a three-switch cluster with switches S1 (node ID 1), S2 (node ID 2) and S3 (node ID 3). S1 is the master switch.
These examples describe reboots on all switches in the cluster:
Caution | If you perform any configuration change on a cluster, you must save the running configuration to the startup configuration by entering the copy running-config startup-config command on all switches before rebooting them. Otherwise, the cluster may not form correctly after the reboot. |
If the third switch happens to be running the latest cluster configuration in the startup configuration (this can happen if you save the running configuration only on this switch but not on the other two), the third switch will not be able to join the cluster.
Caution | It is critical that you save the running configuration on all switches before a reboot. |
The four-switch cluster scenario is very similar to the examples above. The cluster will be operational if the cluster view has at least three switches (N/2 + 1), or if the cluster view has two switches including the switch with the lowest node ID (N/2 with lowest node ID).
In-Service Software Upgrade (ISSU) is a comprehensive, transparent software upgrade application that allows you to deploy bug fixes and add new features and services without any disruption to the traffic.
In a cluster comprising of the MDS 9222i Switches as nodes, if the nodes are not able to communicate, then the node having the lowest node identifier (node ID) remains in the cluster while the other node leaves the cluster. However, when an ISSU is performed on a node having the lowest node identifier, a complete loss of the cluster results because both the nodes leave the cluster.
Note | This feature is tied to ISSU logic and no additional commands need to be executed. |
Cisco IOA supports a single-fabric topology. Multiple modules can be deployed in a Fibre Channel fabric to easily scale-up performance, to enable simplified load balancing, and to increase availability. In a typical configuration, one IOA engine per site is required in each IOA cluster.
IOA clusters include designated backup servers, tape libraries, and one or more MDS switches running Cisco SAN-OS Release 3.2(2c) or alter. One cluster switch must include an IOA engine per site. With easy-to-use provisioning, traffic between any host and tape on the fabric can utilize the IOA services.
Required Cisco IOA engines are included in the following Cisco products:
The MSM-18/4 Module can be anywhere in the fabric. Cisco IOA does a one-to-one mapping of the information from the host to the target and forwards the encrypted data to the dedicated HR tape. Cisco IOA also tracks the barcodes on each encrypted tape and associates the barcodes with the host servers.
Encryption and compression services are transparent to the hosts and storage devices. These services are available for devices in any virtual SANs (VSANs) in a physical fabric and can be used without rezoning.
In certain topologies, edge switches are interconnected across the WAN. Plan for deployment at the core and transition of WAN links to core switches for optimal routing.
Refer to this section for information on recovery procedures that are used when one or more switches in a Cisco IOA cluster is offline or when you want to change the master switch assignment from one switch to another switch.
This section includes the following topics:
To delete an offline switch when one or more switches are offline and the master switch is online, use these procedures.
To delete a Cisco IOA cluster that includes one or more offline switches and online master switch, use these procedures.
Caution | Do not remove a cluster master switch from a cluster and then try to revive the cluster on an offline switch. Since the offline switch was not part of the operational cluster, the cluster master may have progressed beyond what is in the offline switch’s state. Deleting the cluster master and reviving the cluster on an offline switch can result in stale configuration. |
Step 1 | switch#
configure
terminal
Enters configuration mode. | ||
Step 2 | switch(config)#
ioa
cluster
ABC
Enter the IOA Cluster mode. | ||
Step 3 | switch(config-ioa-cl)#
shutdown
Shuts down the ABC cluster on the offline switch.
| ||
Step 4 | switch(config-ioa-cl)#
no
node
switch2
Deletes switch2 from the ABC cluster configuration.
| ||
Step 5 | switch(config-ioa-cl)#
exit
Exits the IOA Cluster mode and enters the Global configuration mode. | ||
Step 6 | switch(config)#
no
ioa
cluster
ABC
|
To delete a Cisco IOA cluster when the master switch and all other switches are offline, use these procedures.
Note | When all switches are offline, the cluster is offline. |
On the offline switch (for example, switch2), shut down the cluster by performing this task:
Step 1 | switch#
configure
terminal
Enters configuration mode. | ||
Step 2 | switch(config)#
ioa cluster
ABC
Enter the IOA Cluster mode. | ||
Step 3 | switch(config-ioa-cl)#
shutdown
Shuts down the ABC cluster on the offline switch.
| ||
Step 4 | switch(config-ioa-cl)#
exit
Exits the IOA Cluster mode and enters the Global configuration mode. | ||
Step 5 | switch(config)#
no
ioa
cluster
ABC
|
To revive a cluster on the switch that has the latest Cisco IOA configuration version, use these procedures.
This procedure is used to revive a cluster when one or more switches are offline and the cluster is nonoperational (for example, due to a quorum loss). The recovery procedure includes deleting one or more offline switches and then reviving the cluster on the remaining switches.
Caution | A Cisco IOA cluster must only be revived on the switch with the latest IOA configuration version as displayed by the show IOA cluster detail command. Reviving the cluster on a switch that does not have the highest configuration version can result in stale configuration. |
Note | The following procedure assumes that switch1 has the latest IOA configuration version. The steps shown for switch2 should be carried out for every switch that needs to be removed before reviving the cluster. |
Step 1 | switch# configure
terminal
Enters configuration mode. | ||
Step 2 | switch(config)# ioa
cluster
ABC
Enter the IOA Cluster mode. | ||
Step 3 | switch(config-ioa-cl)# shutdown
Shuts down the ABC cluster on the offline switch. | ||
Step 4 | switch(config-ioa-cl)# exit
Exits the IOA Cluster mode and enters the Global configuration mode. | ||
Step 5 | switch(config)# no
ioa
cluster
ABC
| ||
Step 6 | switch(config)# ioa
cluster
ABC
Enter the IOA Cluster mode. | ||
Step 7 | switch(config-ioa-cl)# no node switch 2
Deletes switch2 from the ABC cluster configuration.
| ||
Step 8 | switch(config-ioa-cl)# no
shutdown
Restarts the cluster on the switch. |