Fabric OS Encryption Administrator's Guide

Fabric OS Encryption Administrator’s Guide 191
53-1002159-03
Firmware download considerations
5
• 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 re-key or
first-time encryption operation.
A firmware consistency check for Fabric OS v6.4.0(x) and later is enforced in an encryption group if
any of the version 6.4.0(x) features is enabled, for example, disk tape coexistence. If any Fabric OS
v6.4.0(x) feature is in an enabled state, then any firmware download to Fabric OS v6.3.x or earlier is
blocked.
• Do not try registering a node running Fabric OS v6.3.x or earlier to an encryption group when all
nodes are running Fabric OS v6.4.0(x) with one or more Fabric OS v6.4.0(x) features enabled.
• Disable all Fabric OS v6.4.0(x) features before ejecting a node running Fabric OS v6.4.0(x) and
registering the node as a member of an encryption group with nodes running Fabric OS v6.3.x
or earlier.
Data-at-rest encryption support for IBM SVC LUNs configuration
A highly available encryption group is a requirement for IBM SVC deployments, which can be
achieved using either an encryption HA cluster (HAC) or a DEK cluster. Failure to deploy high
availability in the encryption group could lead to IBM SVC nodes going offline and into service mode
when there is no encryption engine online.
NOTE
If IBM SVC nodes go offline and into service mode, all SVC ports are affected and not just those
configured for encryption operations.
Data-at-rest encryption, crypto target containers, and LUN configuration must be defined in front of
the SVC nodes and not between the SVC nodes and disk storage targets. Refer to the following IBM
publication regarding general IBM SVC best practices.
SAN Volume Controller Best Practices and Performance Guidelines
(http://www.redbooks.ibm.com/abstracts/sg247521.html)
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:
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.