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 Communications Group

• When you create an LDT Communications Group, add the CTE clients sequentially.

• CTE 7.5 has architectural design changes. Due to these changes:

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

  • All nodes, Windows and Linux, must be running CTE 7.5.0 in order for the nodes to communicate properly.

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

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 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.