HP Brocade 8/12c Fabric OS Encryption Administrator's Guide - Page 234

A member node reboots and comes back up, Impact, Recovery

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

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204
  • 205
  • 206
  • 207
  • 208
  • 209
  • 210
  • 211
  • 212
  • 213
  • 214
  • 215
  • 216
  • 217
  • 218
  • 219
  • 220
  • 221
  • 222
  • 223
  • 224
  • 225
  • 226
  • 227
  • 228
  • 229
  • 230
  • 231
  • 232
  • 233
  • 234
  • 235
  • 236
  • 237
  • 238
  • 239
  • 240
  • 241
  • 242
  • 243
  • 244
  • 245
  • 246
  • 247
  • 248
  • 249
  • 250
  • 251
  • 252
  • 253
  • 254
  • 255
  • 256
  • 257
  • 258
  • 259
  • 260
  • 261
  • 262
  • 263
  • 264
  • 265
  • 266
  • 267
  • 268
  • 269
  • 270
  • 271
  • 272
  • 273
  • 274
  • 275
  • 276
  • 277
  • 278
  • 279
  • 280
  • 281
  • 282

214
Fabric OS Encryption Administrator’s Guide
53-1002159-03
Encryption group merge and split use cases
6
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.