Brocade Fabric OS Encryption Administrator’s Guide Supporting RSA Data Protection Manager (DPM) Environments (Supporting Fabric OS v7.2.0) - Manual (Page 263)

Fabric OS Encryption Administrator’s Guide (DPM) 243
53-1002922-01
Best practices for host clusters in an encryption environment
5
Best practices for host clusters in an encryption environment
When host clusters are deployed in a encryption environment, please follow these
recommendations:
• If two encryption engines are part of an HA cluster, configure the host/target pair so they have
different paths from both encryption engines. Avoid connecting both the host/target pairs to
the same encryption engine. This connectivity does not give the full redundancy needed in
case of encryption engine failure and failover to another encryption engine in an HA cluster.
• For Windows-based host clusters, when a quorum disk is used, the quorum disk plays a vital
role in keeping the cluster synchronized. It is recommended that you configure the quorum
disk to be outside of the encryption environment.
• For AIX-based Power HA System Mirror host clusters, the cluster repository disk should be
defined outside of the encryption environment.
HA Cluster deployment considerations and best practices
It is mandatory that the two encryption engines in the HA cluster belong to two different nodes for
true redundancy. This is always the case for Brocade Encryption Switches, but is not true if two
FS8-18 blades in the same DCX Backbone chassis are configured in the same HA cluster. In Fabric
OS v6.3.0 and later releases, HA cluster creation is blocked when encryption engines belonging to
FS8-18 blades in the same DCX Backbone chassis are specified.
Key vault best practices
• Make sure that the time difference on the Brocade Encryption Switch and the DPM key vault
does not exceed one minute.
• When encrypted disk LUNs are to be configured or moved to an Encryption Group that uses a
different key vault, make sure to decommission the encrypted LUNs from the old Encryption
Group.
Tape device LUN mapping
When performing LUN mapping, ensure that a given LUN number from a backend physical target is
the same across all initiators in the container. Failure to do so can result in unpredictable switch
behavior including blade/switch faults. Use the following command to list the LUNs in the target.
switch:admin> cryptocfg --discoverLUN <container name>
NOTE
It is recommended that you follow the above rule if a given LUN on the backend target is LUN
mapped to different initiators.