Element version 11.5 or earlier allows nodes with non-encrypted drives to be added to an encryption at rest (EAR) enabled cluster
Applies to
- HCI Flash Storage Node
- HCI Storage Element OS
- SolidFire All Flash Arrays
- SolidFire Element OS
Issue
Element 11.5 or lower clusters that have encryption at rest (EAR) enabled and non-encrypting nodes may lose access to data.
Element versions 11.5 and earlier with encryption at rest (EAR) enabled will allow nodes with non-encrypting drives to be added to the cluster and used, until the node with non-encrypting drives is rebooted or power cycled for any reason. If more than one non-encrypting nodes reboots at the same time or if one node reboots while a block sync is occurring, data will become unavailable.
On Clusters with all versions of Element and EAR disabled, intermixing encrypting and non-encrypting nodes is supported. However, encryption at rest (EAR) cannot be enabled unless all nodes in the cluster are encryption capable. It is best practice to not mix nodes of different encryption types in the same cluster.
Element versions 11.5 and earlier with encryption at rest (EAR) enabled will allow non-encrypting nodes to be added to the cluster and used. However, after a reboot or power cycle of the non-encrypting node, Element check logic will fail the non-encrypting node’s drives. If more than one node with non-encrypting drives reboots or power cycles for any reason at the same time or within the sync data replication time after the first node goes offline, data will become unavailable.
On Clusters with Element 11.7 and higher, adding nodes with non-encrypted drives in an encryption at rest (EAR) enabled cluster is blocked (see the summary table below).
Table of Element responses for encrypting with / without EAR
Element version |
Ability to enable EAR with a non-encrypting node in the cluster |
Ability to add a non-encrypting node to a cluster with EAR enabled |
Ability to add a non-self-encrypting drive to an encrypting node in a cluster with EAR enabled |
Ability to add encrypting capable nodes or self-encrypting drives to a non-encrypted cluster & EAR NOT enabled |
10.0 to 11.5 |
No - Blocked w/error |
Yes, with no cluster faults, and drive(s) will be marked as failed with reboot or power cycle |
Yes, with cluster faults, and drive(s) will be marked as failed with reboot or power cycle |
Supported |
11.7 & Later |
No - Blocked w/error |
No, Blocked w/error |
Yes, with cluster faults, and drive(s) will be marked as failed with reboot or power cycle |
Supported |
- Error response with API attempt to enable EAR with a non-encrypting node in the cluster on Element versions 10.0 and later
EnableEncryptionAtRest Failed: Encryption not allowed. Cluster detected non-encryptable node. nodeId=X
- Error response with API attempt to add a non-encrypting node to a cluster with EAR enabled on Element 11.7 to 12.0
Cannot add node X because EAR is enabled but node is not encryptable
- Error response with API attempt to add a non-encrypting node to a cluster with EAR enabled on Element 12.2 and later
Cannot add node X because EAR is enabled but either node is not encryption-capable or nodesConnectFailed/nodesQueryFailed connection issues prevented determination of encryption capability
- Cluster fault after adding a non-self-encrypting drive to an encrypting node in a cluster with Element 10.0 and later
- If a node and drive in that node have conflicting encryption capabilities, a warning fault is issued.
- 10.0 and after: “Drive encryption capable state mismatches node's encryption capable state for the drive in X.”
- For additional information, see the following KB:
"Drive encryption capable state" warning after node replacement