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 238)

220 Fabric OS Encryption Administrator’s Guide (LKM/SSKM)
53-1002925-01
Encryption group merge and split use cases
6
NOTE
When attempting to reclaim a failed Brocade Encryption Switch, do not execute
cryptocfg
--
transabort. Doing so will cause subsequent reclaim attempts to fail.
4. Set up the member node: Configure the IP address of the new node that is replacing the failed
node, and the IP addresses of the I/O cluster sync ports (Ge0 and Ge1), and initialize the node
with the cryptocfg
--
initnode command.
5. On the new node that is to be added, invoke cryptocfg
--
reclaimWWN
-
cleanup.
6. Export the CP certificate from the member node.
7. Import the member node CP certificate into the group leader.
8. On the group leader node, register the member node with the group leader node. Enter the
cryptocfg
--
reg
-
membernode command with appropriate parameters to register the
member node. Specify the member node’s WWN, Certificate filename, and IP address when
executing this command. Successful execution of this command distributes all necessary node
authentication data to the other members of the group.
SecurityAdmin:switch>cryptocfg --reg -membernode \
10:00:00:05:1e:39:14:00 enc_switch1_cert.pem 10.32.244.60
Operation succeeded.
9. Establish the connection between the member node and the key vault.
10. Register the new node with the key manager appliance.
11. On the new node, invoke cryptocfg
--
initEE, and cryptocfg
--
regEE to initialize the encryption
engines.
12. After the new node has come online, invoke the cryptocfg
–-
enableEE [slot_number]
command to enable crypto operations on the node’s encryption engines.
13. Replace the failed encryption engine on N3 with the encryption engine of the new node N4 to
restore broken HA cluster peer relationships. Use the cryptocfg -- replace command.
14. Remove the failed node from the encryption group. Follow the procedures described in the
section “Removing a member node from an encryption group” on page 210.
A member node reboots and comes back up
Assume N1, N2 and N3 form an encryption group and N2 is the group leader node. N3 and N1 are
part of an HA cluster. Assume that N3 reboots and comes back up.
Impact
When N3 reboots, all devices hosted on the encryption engines of this node automatically fail over
to the peer encryption engine N1. N1 now performs all of N3’s encryption services. Any rekey
sessions in progress continue. Rekey sessions owned by N3’s encryption engine are failed over to
N1.