Brocade Fabric OS Encryption Administrator’s Guide Supporting NetApp Lifetime Key Manager (LKM) and KeySecure Storage Secure Key Manager (SSKM) Environments (Supporting Fabric OS v7.2.0) - Manual (Page 211)

Fabric OS Encryption Administrator’s Guide (LKM/SSKM) 193
53-1002925-01
Firmware upgrade and downgrade considerations
5
• Guidelines for firmware upgrade of encryption switches and a DCX Backbone chassis with
encryption blades deployed in DEK cluster with No HA cluster (each node hosting one path).
- Upgrade one node at a time.
- In the case of active/passive arrays, upgrade the node which is hosting the passive path
first. Upgrade the node which is hosting active path next. The Host MPIO ensures that I/O
fails over and fails back from active to passive and back to active during this firmware
upgrade process.
- In the case of active/active arrays, upgrade order of nodes does not matter, but you still
must upgrade one node at a time. The Host MPIO ensures that I/O fails over and fails back
from one active path to another active path during this firmware upgrade process.
• All nodes in an encryption group must be at the same firmware level before starting a rekey or
first-time encryption operation.
A firmware consistency check for Fabric OS 6.4.0(x) and later is enforced in an encryption group if
any of the v6.4.0(x) features is enabled, for example, device decommission and disk tape
coexistence. If any Fabric OS 6.4.0(x) feature is in an enabled state, then any firmware download to
Fabric OS 6.3.x or earlier is blocked.
• Do not try registering a node running Fabric OS 6.3.x or earlier to an encryption group when all
nodes are running Fabric OS 6.4.0(x) with one or more Fabric OS 6.4.0(x) features enabled.
• Disable all Fabric OS 6.4.0(x) features before ejecting a node running Fabric OS 6.4.0(x) and
registering the node as a member of an encryption group with nodes running Fabric OS 6.3.x or
earlier.
Specific guidelines for HA clusters
The following are specific guidelines for a firmware upgrade of the encryption switch or blade when
deployed in HA cluster. The guidelines are based on the following scenario:
• There are 2 nodes (BES1 and BES2) in the HA cluster.
• Each node hosts certain number of CryptoTarget containers and associated LUNs.
• Node 1 (BES1) needs to be upgraded first.
1. Change the failback mode to manual if it was set to auto by issuing the following command on
the group leader:
Admin:switch> cryptocfg --set -failbackmode manual
2. On node 1 (BES1), disable the encryption engine to force the failover of CryptoTarget
containers and associated LUNs onto the HA cluster peer member node 2 (BES2) by issuing
the following command.
Admin:switch> cryptocfg --disableEE
3. Ensure that these CryptoTarget Containers and LUNs actually fail over to node 2 (BES2) in the
HA cluster. Check for all LUNs in encryption enabled state on node 2 (BES2). This ensures that
I/O also fails over to node 2 (BES2) and continues during this process.
4. On node 1 (BES1) enable the encryption engine (EE), by issuing the following command.
Admin:switch> cryptocfg --enableEE