Limitations

The following limitations exist for LDT over CIFS/NFS:

Windows

• Only supported for customers using unstructured data.

• LDT over CIFS is not supported on single processor systems.

• All nodes sharing a CIFS drive must have homogenous system drivers installed. You cannot have some nodes installed with the vmlfs.sys driver and some installed with the vmfiltr.sys driver. That scenario is not supported.

Linux

• Although CTE supports GuardPoints over NFS shares using NFS v3 and v4 protocols, Thales strongly recommends using NFS v4 protocols, or a subsequent version, when using LDT policies.

• CTE does not support mixing NFS v3 and v4 protocols on different CTE hosts for accessing the same GuardPoint. All members of an LDT GuardPoint Group must access the same GuardPoint using the same NFS protocol version.

• When installing CTE patches, make sure that the new patch is compatible with CTE latest release. Follow instructions in the release note for a patch release, if any, for upgrading CTE hosts sharing access to the same GuardPoints across multiple hosts.

• LDT can be slower when rekeying GuardPoints over NFS as compared to GuardPoints in local file systems. Communications between a primary host and other members of an LDT Communication Group add significant delay in execution of LDT operations. Delays in LDT operations slow down LDT progress to the point that QoS rekey IO rate may not be achievable, especially in environments with slow network bandwidth.

• Other current limitations will be removed over the next several patches. Refer to the release notes to determine which limitations, noted below, have been removed:

  1. Applications will experience performance degradations on secondary hosts when targeting files undergoing rekey, even while LDT is suspended. LDT disables read-ahead on files undergoing rekey on secondary hosts resulting in lower IO throughput.

  2. Loss of network connectivity to the NAS server from the primary host during active rekey can block access to files undergoing rekey across all members of LDT GuardPoint Groups for all GuardPoints on the NAS server.

  3. If the secfsd daemon fails on a secondary host, it will require rebooting the host and removing the secondary host from each LDT GuardPoint Group on that secondary host prior to reboot. If the secfsd daemon fails on the primary host, it also requires rebooting the primary host and the delegation of the primary role to one of the secondary members of the LDT GuardPoint Group.

LDT Communication Group

1. You must create an LDT Communication Group on your CipherTrust Manager and manually add all of the CTE clients to it sequentially.

2. Minimum of four CTE clients required for membership to the LDT Communication Group for proper and continuous operations of LDT services across all LDT GuardPoint Groups.

3. The first three nodes of the LDT Communication Group are critical and cannot be removed or shutdown/reboot simultaneously.

4. All nodes, Windows and Linux, must be running CTE 7.5.0, or a subsequent version, in order for the nodes to communicate properly.

5. The majority of the CTE clients must be fully operational for proper LDT operations across all LDT GuardPoint Groups.

   The LDT Communication Group requires that the majority of CTE clients are active, in order for the LDT Communication Group to work properly. If 50% of the LDT Communication Group servers, or 2 out of 3 triad nodes fail, then the LDT Communication Group cannot recover from that situation. To fix this issue, you must either:

   • Reboot all of the CTE clients in the entire LDT Communication Group.

   • In Windows, restart secfsd through the Control Panel > Services page on all of the CTE clients in the entire LDT Communication Group.

6. The name of the LDT Communication Group cannot contain special characters.

7. If you are repurposing a CTE client that is currently being used for LDT over NFS/CIFS, but still runs CTE and is still registered to the same CM, then you must:

   1. Remove all CIFS/NFS LDT GuardPoint Groups from the host prior to removing the host from the LDT Communication Group.
   2. Reboot the host.

8. Remove a host from the LDT Communication Group if the host is being decommissioned, meaning that you plan to power it down for the foreseeable future, or while CTE is being uninstalled.

LDT GuardPoint Group

• Failover, after an ungraceful failure, is manual. If a primary node becomes unavailable and LDT cannot automatically reassign the primary to another CTE client, the administrator must manually assign another CTE client as the primary node. See Failover for more information.

LDT Communication Group and LDT GuardPoint Group

• For continuous and seamless synchronization and control between all clients (excluding Windows AccessOnly clients) in an LDT Communication Group, in the LDT over CIFS/NFS environment, the secfsd service on each client must be continuous and uninterrupted. LDT support for NFS and CIFS depends on continuous availability of the secfsd process for management and availability of LDT GuardPoint Groups and continuous flow of LDT messages from primary hosts to members of the LDT GuardPoint Groups during rekey.

  In the event that the secfsd process abruptly fails and/or restarts for any reason, the LDT GuardPoint Groups will be erased on the CTE hosts and the LDT message flow to/from the CTE client to other members of the LDT GuardPoint Groups stops. The only method for recovering from this event is to reboot the CTE host. Do not terminate the secfsd process on the primary host, as this results in the election and promotion of another member of the LDT GuardPoint group to the primary role.

LDT Reverse Migration

• Converting LDT CIFS/NFS GuardPoints from Live Data Transformation policies to Standard CTE policies is not supported.

• LDT CIFS/NFS-protected GuardPoints cannot be migrated to clear_key.

• Reverse migration is not supported for network shares.

• LDT over CIFS/NFS DOES NOT support rolling back migrations.