HP Brocade 8/12c Fabric OS Encryption Administrator's Guide - Page 234
A member node reboots and comes back up, Impact, Recovery
View all HP Brocade 8/12c manuals
Add to My Manuals
Save this manual to your list of manuals |
Page 234 highlights
6 Encryption group merge and split use cases 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 206. 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 re-key sessions in progress continue. Re-key sessions owned by N3's encryption engine are failed over to N1. Recovery If auto failback policy is set, no intervention is required. After the node has come back up, all devices and associated configurations and services that failed over earlier to N1 fail back to N3. The node resumes its normal function. If auto failback policy is not set, invoke a manual failback if required. Refer to the section "Performing a manual failback of an encryption engine" on page 212 for instructions. 214 Fabric OS Encryption Administrator's Guide 53-1002159-03