HP 4400 HP StorageWorks Fabric OS 6.4.1 Release Notes (5697-0760, November 201 - Page 41

HP StorageWorks Fabric OS 6.4.1 Release Notes, Execute the CLI

Page 41 highlights

-manual_rekey command to manually rekey these LUNs. • If an HA Cluster is configured within an Encryption Group with containers configured for auto Failback Mode, the following procedure must be followed when upgrading from Fabric OS 6.2.x to 6.3.1x. Note that the following procedure is required only under the above-mentioned conditions. 1. Before the firmware upgrade, change the Failback Mode to manual for all containers con- figured as auto. Take note of which Encryption Engines currently own which containers. 2. Upgrade all nodes in the Encryption Group to Fabric OS 6.3.1x, one node at a time. 3. After all nodes have been successfully upgraded, using the notes taken in step 1, manually invoke the failback of the containers to the correct Encryption Engine using the cryptocfg -failback -EE [slot num] [slot num] command . 4. Once the manual failback completes, change the Failback Mode back to auto from manual, if it was changed in step 1. • Avoid changing the configuration of any LUN that belongs to a CTC/LUN configuration while the rekeying process for that LUN is active. If you change the LUN settings during manual or auto, rekeying or First Time Encryption, the system reports a warning message stating that the encryption engine is busy and a forced commit is required for the changes to take effect. A forced commit command halts all active rekeying processes running in all CTCs and corrupts any LUN engaged in a rekeying operation. There is no recovery for this type of failure. • Configuration of crypto targets on HP StorageWorks encryption switches or encryption blades is accomplished in two stages: entering the configuration changes and issuing a commit operation. Previous to Fabric OS 6.3.1a, if the data encryption group (Encryption Group) became incomplete (one or more members became inaccessible due to network problems and the encryption group becomes degraded) between these two stages, the commit operation was still executed. While this did not result in any issue for the configured host and targets, it could lead to configuration changes being applied to only a subset of the encryption switches in the encryption group. This was a rare situation that had only been seen in test environments. This issue was resolved in Fabric OS 6.3.1a. • If the data encryption group (Encryption Group) gets into a state where the Group Leader encryption switch reports that another encryption switch is NOT a member node of the encryption group, and the encryption switch member node still indicates that it IS part of the encryption group, the following recovery action can be performed to re-merge the nodes into the encryption group: 1. On the Group Leader encryption switch, execute the CLI cryptocfg -dereg -membernode command. 2. Wait for 30 seconds. 3. Execute the CLI cryptocfg -reg -membernode command. This is a rare situation that has been noted in a test environment where there were intermittent management network connectivity problems. • To remove access between a given initiator and target, you must not only remove the active zoning information between the initiator and target, but must also remove the associated CTCs, which in turn removes the associated frame redirection zone information. Make sure to back up all data before taking this action. • Before committing configurations or modifications to the CTC or LUNs on an HP Encryption Switch or HP Encryption Blade, make sure that there are no outstanding zoning transactions in the switch or fabric. Failure to do so results in the commit operation for the CTC or LUNs failing and may cause the LUNs to be disabled. The user can check for outstanding zoning transactions by issuing the CLI cfgtransshow command : DCX_two:root> cfgtransshow HP StorageWorks Fabric OS 6.4.1 Release Notes 41

  • 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

-manual_rekey <CTC> <LUN Num> <Initiator PWWN>
command to manually rekey these
LUNs.
If an HA Cluster is configured within an Encryption Group with containers configured for
auto
Failback Mode, the following procedure must be followed when upgrading from Fabric OS 6.2.x
to 6.3.1x. Note that the following procedure is required only under the above-mentioned conditions.
1.
Before the firmware upgrade, change the Failback Mode to
manual
for all containers con-
figured as
auto
. Take note of which Encryption Engines currently own which containers.
2.
Upgrade all nodes in the Encryption Group to Fabric OS 6.3.1x, one node at a time.
3.
After all nodes have been successfully upgraded, using the notes taken in step 1, manually
invoke the failback of the containers to the correct Encryption Engine using the
cryptocfg
-failback -EE <WWN of hosting node> [slot num] <WWN of second node
in HAC> [slot num]
command .
4.
Once the manual failback completes, change the Failback Mode back to
auto
from
manual
,
if it was changed in step 1.
Avoid changing the configuration of any LUN that belongs to a CTC/LUN configuration while the
rekeying process for that LUN is active. If you change the LUN settings during manual or auto,
rekeying or First Time Encryption, the system reports a warning message stating that the encryption
engine is busy and a forced commit is required for the changes to take effect. A forced commit
command halts all active rekeying processes running in all CTCs and corrupts any LUN engaged
in a rekeying operation. There is no recovery for this type of failure.
Configuration of crypto targets on HP StorageWorks encryption switches or encryption blades is
accomplished in two stages: entering the configuration changes and issuing a commit operation.
Previous to Fabric OS 6.3.1a, if the data encryption group (Encryption Group) became incomplete
(one or more members became inaccessible due to network problems and the encryption group
becomes degraded) between these two stages, the commit operation was still executed. While
this did not result in any issue for the configured host and targets, it could lead to configuration
changes being applied to only a subset of the encryption switches in the encryption group. This
was a rare situation that had only been seen in test environments. This issue was resolved in
Fabric OS 6.3.1a.
If the data encryption group (Encryption Group) gets into a state where the Group Leader encryption
switch reports that another encryption switch is NOT a member node of the encryption group,
and the encryption switch member node still indicates that it IS part of the encryption group, the
following recovery action can be performed to re-merge the nodes into the encryption group:
1.
On the Group Leader encryption switch, execute the CLI
cryptocfg –dereg –membernode
<WWN of member node>
command.
2.
Wait for 30 seconds.
3.
Execute the CLI
cryptocfg –reg –membernode <WWN membernode> <certificate
file name> <ipaddr of member node>
command.
This is a rare situation that has been noted in a test environment where there were intermittent
management network connectivity problems.
To remove access between a given initiator and target, you must not only remove the active zoning
information between the initiator and target, but must also remove the associated CTCs, which in
turn removes the associated frame redirection zone information. Make sure to back up all data
before taking this action.
Before committing configurations or modifications to the CTC or LUNs on an HP Encryption Switch
or HP Encryption Blade, make sure that there are no outstanding zoning transactions in the switch
or fabric. Failure to do so results in the commit operation for the CTC or LUNs failing and may
cause the LUNs to be disabled. The user can check for outstanding zoning transactions by issuing
the CLI
cfgtransshow
command :
DCX_two:root> cfgtransshow
HP StorageWorks Fabric OS 6.4.1 Release Notes
41