Responsibilities of the Primary host

As described earlier, the primary host in the LDT GuardPoint Group is responsible for performing data transformation operations. In addition:

1. On Linux, the primary host drives execution of committing a new key version to all members of the LDT GuardPoint Group. During this process, the primary host sends a message to all members, inquiring if each member has received the new key version from CipherTrust Manager. If all members have received the new key, then the primary host, and the members, commit the new key version to their GuardPoints. If at least one member does not have the new key version, the primary host delays committing the new key version and retries the commit process in 30 seconds.

   The delay in committing the new key version avoids applications accessing files encrypted with the new key version. Without the delay, the primary host would proceed to rekey the GuardPoint, and consequently, applications running on those member(s), without the latest key version, would be blocked when accessing files encrypted with the latest key version.

   

   Note

   The delay only affects rekey operations re-encrypting existing files to the new key version. It does not affect newly created files which inherit the latest key version, that may not have been committed across the entire LDT GuardPoint Group by the primary host. If newly created files are accessed on CTE hosts which do not have the latest key version, the process of accessing such files will be blocked until the latest key version becomes available on those CTE hosts.

2. On Linux, the primary host is also responsible for updating and committing LDT metadata for file operations in progress on the secondary hosts. For example, truncating a file while the primary host is rekeying the file requires changing the LDT metadata for that file. As the primary host is updating the LDT metadata during the rekey process, the member host truncating the file does not update the metadata that the primary host is changing. Instead, the secondary host sends a message to the primary host, requesting LDT metadata changes for the truncate operation, and the primary host provides the metadata updates for the truncate operation triggering the secondary to proceed. The host then commits or discards the metadata changes for the truncate operation after the secondary hosts completes it and notifies the primary host of their status. This process forces the primary host to engage with the hosts that perform truncate operations, strictly on those files that the primary host is rekeying.

3. Operations such as file or directory rename initiated on a member of the group also involves engagement of the primary host, if the primary host is actively rekeying the affected files or GuardPoints. Renaming a subdirectory on a secondary host engages the primary host to scan a list of files under the renamed subdirectory. The primary host performs the scan outside of the scope of the GuardPoint level rekey process and starts separate file level rekey operations for each file not undergoing rekey in the renamed subdirectory. The primary host conducts up to 8 concurrent file level operations, and the GuardPoint level rekey operation does not complete until every file in the renamed subdirectory is rekeyed. File level rekey operations are slow as compared to GuardPoint rekey operations, therefore, subdirectories with a large number of renamed files delay rekey completion time.

Responsibilities of non-primary hosts

When secondary hosts in the LDT GuardPoint Group perform file operations on files that the primary host is actively rekeying, it must notify the primary host of those operations. Truncating a file on secondary hosts, as described earlier, is an example of a secondary host notifying the primary host for updating LDT metadata.

Secondary hosts can also be selected for promotion to the primary role within an LDT GuardPoint Group. A host elected for promotion checks whether it's capable of assuming the primary role for the LDT GuardPoint Group, and if capable, it accepts and promotes itself to assume the primary role for the LDT GuardPoint Group.

Note

Ensure that at least one secondary host is always qualified to accept promotion to primary status. Connectivity to CipherTrust Manager and mounting NFS shares with read and write access are critical for qualifying secondary hosts for promotion to the primary role.

GuardPoint Directories (Linux Only)

The pathname of a GuardPoint directory does not have to be fixed across all members of the group. For example, if host_1 mounts the share at /nfs-host-1/gp-dir and host_2 mounts the same share at /nfs-host-2/gp-dir, the LDT GuardPoint Group for the GuardPoint represents both pathnames.

GuardPoint Directories (Windows Only)

GuardPoints for Windows directories use the UNC format. See Creating a GuardPoint on a CIFS Share Drive on CipherTrust Manager for more information.

Overhead in LDT over NFS/CIFS

The primary host performs LDT operations across all members of an LDT GuardPoint Group. It sends a message, for each operation, to all members of the LDT GuardPoint Group and waits for acknowledgment from all members before executing the operation. A message holds information specific to an operation that the primary host wants to perform, such as file initialization for rekey, lock/unlock operations, LDT launch on GuardPoint, etc. Each member of the LDT GuardPoint Group validates each operation requested by the primary host before responding to the request. This coordination incurs significant overhead in execution of LDT operations on GuardPoints over NFS/CIFS shares in contrast to the same operations performed over GuardPoints in local file systems. It also increases network traffic across all members of LDT GuardPoint Group and potentially increasing overhead in your network infrastructure.

This overhead can pose challenges for LDT to achieve the desired rekey IO rate specified under QoS. Delays incurred in delivery of requests and responses can slow down LDT operations such that the expected rekey IO rate becomes difficult to achieve. Consider the bandwidth of your network infrastructures, number of GuardPoints on the primary host and number of members sharing access to those GuardPoints before setting the rekey IO rate. With multiple GuardPoints on the same primary host such that some of those GuardPoints are over NFS/CIFS and others on locally attached storage devices, rekey IO rate on GuardPoints over NFS/CIFS shares will likely be significantly lower.