Fabric OS Encryption Administrator's Guide

Fabric OS Encryption Administrator’s Guide 209
53-1002159-03
Encryption group and HA cluster maintenance
6
HA cluster name: HAC1 - 2 EE entries
Status: Committed
WWN Slot Number Status
11:22:33:44:55:66:77:00 0 Online
10:00:00:05:1e:53:74:87 3 Online
HA cluster name: HAC2 - 1 EE entry
Status: Defined
WWN Slot Number Status
10:00:00:05:1e:53:4c:91 0 Online
In the following example, the encryption group brocade has one HA cluster HAC3. The
encryption engine with the WWN of 10:00:00:05:1e:53:89:dd has failed over containers from
the encryption engine with the WWN of 10:00:00:05:1e:53:fc:8a it is offline.
SecurityAdmin:switch>cryptocfg --show -hacluster -all
Encryption Group Name: brocade
Number of HA Clusters: 1
HA cluster name: HAC3- 2 EE entries
Status: Committed
WWN Slot Number Status
10:00:00:05:1e:53:89:dd 0 Online - Failover active
10:00:00:05:1e:53:fc:8a 0 Offline
NOTE
In this particular case, the correct status of Failover active is displayed only if group leader
node is queried. If the other node is queried Failover active is not displayed, which is not
consistent with the actual HA status.
Replacing an HA cluster member
1. Log in to the Group Leader as Admin or SecurityAdmin.
2. Enter the cryptocfg
--replace -haclustermember command. Specify the HA cluster name, the
node WWN of the encryption engine to be replaced, and the node WWN of the replacement
encryption engine. Provide a slot number if the encryption engine is a blade. The replacement
encryption engine must be part of the same encryption group as the encryption engine that is
replaced.
SecurityAdmin:switch>cryptocfg --replace -haclustermember HAC2 \
10:00:00:05:1e:53:4c:91 10:00:00:05:1e:39:53:67
Replace HA cluster member status: Operation Succeeded.
3. Enter cryptocfg --commit to commit the transaction.
Case 1: Replacing a failed encryption engine in an HA cluster
Assume a working HA cluster with two operational encryption engines, EE1 and EE2. The target T1
is hosted on EE1 and target T2 is hosted on EE2. Refer to Figure 110.
EE2 fails and generates an offline notification. The target hosted on EE2 (T2 in this case)
automatically fails over to EE1. Even though the target T2 is now hosted on EE1 because of the
failover process, the target association is still EE2, and the container status is displayed on the
hosting node as failover. Use the cryptocfg --show -container crypto target container name -stat
command to display the container status.