Upgrading CSM Software

Chapter Overview

This chapter covers the following topics:

• Upgrading Clusters
• Automatic Upgrade during Node Addition
• Upgrading in Service Mode
• Upgrading the Switch Software
• Replacing CSMs

Upgrading Clusters

Cluster software upgrades can be performed concurrently with user I/O operations. During an upgrade, some nodes may not be fully operational, and the cache might operate in write-through mode. Configuration changes are disallowed during the upgrade process. If an upgrade fails, nodes must be reverted to their original software version before configuration changes are permitted.

Cluster Upgrade Prerequisites

1. Wait for all data migration to complete.
2. Wait for all FlashCopy mappings to complete or stop them. Stopping FlashCopy mappings will result in the targets going offline.
3. Stop all remote copy relationships.

Recognizing Failure Situations

Cluster software upgrades can fail under the following conditions:

• A configured cluster member node is not present.
• Not all nodes in the cluster have the same software level.
• The new SVC software image is incompatible with the current switch or SVC software level.
• A node has been deleted, leaving an I/O group with only one member.

Cluster Upgrade Guidelines

• Nodes are updated one at a time, with one node from each I/O group updated before the second node in that group.
• During an update, a node does not participate in I/O activity. The other node in the I/O group handles I/O, potentially flushing cache to write-through mode.
• A 30-minute delay is inserted between updating the first and second nodes in each I/O group to allow host multipathing software to rediscover paths.
• The update is committed only after all nodes are successfully updated.
• Event logs record the start and completion or failure of the upgrade.
• The config node may change during the upgrade, requiring reconnection to the cluster IP address.

Performing the Cluster Upgrade

Step 1: Issue the cluster name <cluster-name> upgrade svc-system command at the configuration node. Use the optional force keyword if an I/O group has a single node.

Example command:

switch(svc) % cluster name SampleCluster upgrade svc-system scp://userc@171.69.16.22/auto/andusr/userc/hkrel/VegasSW/build/gdb.sb-avanti/isan/targetfs/m9000-ek9-csm-svc-mzg.1.3.x.bin

This process involves compatibility checks between the new SVC software image and the running switch and SVC software on all nodes.

Step 2: Verify the upgrade success using either the show node local command or the show cluster <cluster-name> nodevpd command.

Example verification using show node local:

switch(svc) % show node local

The output should show the node software version corresponding to the new version.

Automatic Upgrade during Node Addition

If a node with a different SVC software version is added to the cluster, the config node automatically downloads the cluster software to the new node. If the software is incompatible, the add node operation will fail.

Upgrading in Service Mode

Service mode upgrade is a recovery alternative for situations where a normal upgrade is not possible. A single node is placed in service access mode for this type of upgrade.

Caution: This process should only be used by experienced administrators with customer support guidance.

Performing a Single Node Service Mode Upgrade

Step 1: Issue the node svc <slot/node> servicemode command to place the node in service mode.

Example:

switch(svc)# node svc 7/2 servicemode

Step 2: Verify the node is in service mode using the show nodes local command.

Example verification:

switch(svc) # show nodes local

The output should indicate the node status as 'servicemode'.

Step 3: Issue the node svc <slot/node> upgrade svc-system command to begin the upgrade.

Example:

switch(svc)# node svc 7/2 upgrade svc-system scp://userc@171.69.16.22/auto/andusr/userc/hkrel/VegasSW/build/gdb.sb-avanti/isan/targetfs/m9000-ek9-csm-svc-mzg.1.3.x.bin

This command performs compatibility checks.

Step 4: Verify the node is running the new software version using the show node local command.

Example verification:

switch1 (svc)% show nodes local

The node automatically exits service mode upon completion.

Upgrading the Switch Software

This procedure upgrades the switch software, not the SVC software on the nodes. It requires a dual-supervisor MDS 9500 director.

Performing the Switch Upgrade

Step 1: Log into the switch via console, Telnet, or SSH.

Step 2: Issue the install all system <bootflash:system-image> <bootflash:kickstart-image> command.

Example:

switch# install all system bootflash:system-image kickstart bootflash:kickstart-image

The installer checks compatibility with SVC software and provides an assessment of changes, including compatibility, upgrade assessment, and module version comparison.

Step 3: Respond 'y' to the prompt Do you want to continue y/n? [n] : to proceed with the upgrade. Responding 'n' aborts the process.

Step 4: Exit the console and open a new session to view the upgraded supervisor module using the show module command.

The upgrade process ensures that only one node in an I/O group is down at a time, with 30-minute gaps between module upgrades.

Replacing CSMs

When replacing a CSM, ensure the new CSM uses valid nWWNs and pWWNs. The process differs based on whether the new CSM is installed in the same or a different slot.

Prerequisites to Replacing a CSM

Step 1: Use show nodes local and show interface svc <slot/node> commands to gather information about the existing nodes, including slot number, node number, node name, cluster name, I/O group, nWWNs, pWWNs, and current software version. Document this information.

Step 2: Verify the node is not functional.

Step 3: Verify the other node in the I/O group is operational before deleting the node.

Step 4: Delete the nodes to be replaced from their clusters.

Replacing a CSM in the Same Slot

If a CSM is replaced in the same slot, the same nWWNs and pWWNs are automatically assigned. No further configuration is needed if the replacement nodes are assigned the same nWWNs and pWWNs as the replaced nodes. Ensure they are in the same I/O group and cluster to prevent data corruption.

If you do not wish to retain the same nWWNs and pWWNs:

Step 1: Remove the CSM as per the hardware installation guide.

Step 2: Use the svc purge-wwn module <slot-num> command to erase the nWWNs and pWWNs from the original slot.

Step 3: Replace the CSM in the same slot. The new CSM will have new nWWNs and pWWNs.

Replacing a CSM in a Different Slot

If a CSM is replaced in a different slot and the same nWWNs and pWWNs are to be retained:

Step 1: Document the nWWN and pWWN values for the CSM before removal.

Step 2: Remove the CSM as per the hardware installation guide.

Step 3: Use the svc purge-wwn module <slot-num> command to erase the nWWNs and pWWNs from the original slot.

Step 4: Replace the new CSM in the desired slot as per the hardware installation guide.

Step 5: Wait for the module to initialize.

Step 6: Configure the VSAN for initiator, target, and management N-ports.

Step 7: Set the nWWN and pWWN values for the interfaces using the provided commands, ensuring the related SVC interface is shut down first.

Step 8: Reload the CSM using the reload module slot-number command for the new WWNs to take effect.

Post-Replacement Verification

Step 1: Use the show nodes local command to verify that the nodes in the CSM have initialized without errors. Incompatible software versions may prevent initialization.

Step 2: Wait for the nodes to initialize.

Step 3: Add the nodes back to their clusters. If the previous node used a default name, it cannot be reassigned. A named node can be reassigned the same name.

Step 4: Use the SDD management tool on host systems to verify that all paths are online.