Use Case for Setting up LDT Communication Group and LDT GuardPoint Group

Overview

When using LDT across multiple clients that share access to the same guarded NAS share, those clients must communicate and coordinate with each other for LDT to succeed.

An LDT GuardPoint Group is defined by a set of clients and a single GuardPoint pathname. It represents the clients that guard the same NAS share, using the NFS protocol on CTE Linux clients and the CIFS protocol on CTE Windows clients. Multiple LDT GuardPoint Groups can exist simultaneously: one for each GuardPoint, or across the same set of CTE clients.

All clients in an LDT GuardPoint Group communicate exclusively through a single LDT Communication Group. Each client is a member of the corresponding LDT GuardPoint Group, which enables direct communication and coordination among the clients.

Understanding the differences between an LDT GuardPoint Groups and an LDT Communication Group will help you setup your LDT clients properly. The table below depicts the functions of both types of groups:

Reference Information

• LDT Communication Groups and LDT GuardPoint Groups

Minimum Client Requirements

3 clients (strictly enforced) | Required for triad. |

Basic Configuration

All CTE clients intending to guard NFS/CIFS shares with an LDT policy must be able to communicate with each other. In order for the CTE clients to communicate, they must:

• Have the ports and protocols between clients open for communication.

• Belongs to a single LDT Communication Group. The agents can specify the LDT Communication Group to join at the time of registration.

• A client can be a part of only one LDT Communication Group.

• Triad clients must be on same subnet with low-latency network connections to ensure stable failover.

• Ports 7024 (Master-Replica), and 7025 (Monitor), must be open on all triad clients, and on the network switch if a firewall is present in the switch.

Creating an LDT Communication Group

To create an LDT Communication Group:

1. In CipherTrust Manager, open the Transparent Encryption application.

2. In the left pane, click Clients > LDT Communication Groups.

3. Click Create LDT Communication Group. The Create LDT Communication Group wizard displays.

4. On the General Info screen:

   1. Specify a Name for the LDT Communication Group. The name must start with a letter or number and can only have alphanumeric characters, periods (.), underscores (_), and hyphens (-).

   2. Provide a Description for the LDT Communication Group.

   3. Click Next.

5. On the Add Clients screen:

   1. Select a minimum of three clients to add to the LDT Communication Group from the available client list. Use the Client Name filter to search for the desired clients.To select all clients visible on the page, select the top check box to the left of the Client Name heading.

      Note

      • You cannot add Windows AccessOnly clients to the LDT Communication Group.

      • You must select at least three nodes for the LDT Communication Group. If the LDT Communication Group has fewer than three nodes, failover is not supported and the group runs in degraded mode.

   2. Click Next. The Confirmation screen displays.

6. Verify the group details.

   If the details are incorrect or you want to modify them, click Back and update the details.

7. Click Create. CipherTrust Manager creates the LDT Communication Group, associates the clients, and displays it under the LDT COMMUNICATION GROUP section on the Membership tab of the client.

Reference Information

• Key Guidelines for Configuration of an LDT Communication Group

• LDT Communication Groups

Creating an LDT GuardPoint Group

Unlike LDT Communication Groups, LDT GuardPoint Groups are created logically. When a member of a CTE client group, or an individual client, enables an NFS/CIFS GuardPoint, it becomes part of the corresponding LDT GuardPoint Group for that guard path. This applies to both individual clients and client groups. Note that these clients must belong to the same LDT Communication Group.

The first client in the LDT Communication Group that enables a GuardPoint on an NFS/CIFS share is automatically designated as the primary host for the LDT GuardPoint Group. Clients that enable the GuardPoint later become secondary hosts for the same group. The primary role remains in effect until the GuardPoint is disabled on the primary host, or the primary host crashes. In such cases, one of the secondary clients is promoted and becomes the new primary host of the LDT GuardPoint Group.

LDT GuardPoint Group Primary Failover

Graceful Failover

Occurs when the primary node exits cleanly. It is powered off, but there are other live CTE clients in the LDT Communication Group so failover can occur and another CTE client in the group, a secondary node, is automatically promoted to primary.

Example

1. GuardPoint is disabled on the primary.

2. secfs is manually stopped.

3. Client is removed from the client group

Ungraceful Failover

Occurs when the primary fails unexpectedly. Typically, it is due to a kernel crash, abrupt reboot, hardware failure or power cycle.

• If the failed client resumes, repair it, type:

  voradmin ldt group repair <failed host> <guard path>
  

• If the client cannot be recovered, remove it from the group, type:

  voradmin ldt group remove <failed host> <guard path>
  

Reference Information

• LDT GuardPoint Group Commands

• Failover for the LDT Communication Group Master

DPS

The Designated Primary Set (DPS) contains a list of CTE clients from an LDT Communication Group, of which one is elected as a primary client for the LDT GuardPoint Group after the current primary client disables the GuardPoint or crashes.

1. In CipherTrust Manager, click Transparent Encryption > Clients > Client Groups.

2. Click the desired client group name.

3. Select the Designated Primary Set tab.

   It displays the list of Designated Primary Sets. Expand the desired Designated Primary Set to see its details.

4. Click Create Designated Primary Set.

5. In the General Info screen, provide a name for the Designated Primary Set and select an LDT Communication Group. Click Next.

6. In the Add Clients screen, select, or search for, the clients for the primary set.

   Note

   • A Designated Primary Set must contain at least one client.

   • Add two or more clients to the Designated Primary Set to have available clients in DPS for election to the primary role, in the case of LDT primary promotion.

   • During the promotion process, if the corresponding GuardPoint is not enabled on any members of the DPS, another client in the LDT GuardPoint Group that is not a member of the DPS will be promoted to the primary role. As such, it is a best practice to select multiple clients for the Designated Primary Set for each GuardPoint.

   • Select/un-select designated primaries only when guarding NFS/CIFS shares in a client group.

7. In the Confirmation screen, review the details of Designated Primary Set.

8. Click Create. The screen displays a message indicating whether the Designated Primary Set was created successfully.

9. Click Close to close the screen. The Designated Primary Set displays in the Designated Primary Set tab.

10. After you have created a Designated Primary Set for a client group, you can create a corresponding LDT GuardPoint for it.

Adding New Clients to a Designated Primary Set

To add new clients to an existing Designated Primary Set:

1. Under Clients > Client Groups, click the desired client group name.

2. Select the Designated Primary Set tab.

3. Expand the desired Designated Primary Set.

4. Click Add Clients.

5. Select the checkboxes for the desired client names.

6. Click Add.

Changing the Designated Primary Set Associated with a GuardPoint

You can modify the Designated Primary Set associated with a GuardPoint, after the GuardPoint is created.

To change the Designated Primary Set associated with a GuardPoint:

1. Open the Transparent Encryption application from the CipherTrust Manager console.

2. Click the client group name in the Client Group Name column.

3. On the GuardPoints tab, click the ellipsis corresponding to the desired GuardPoint.

4. Click View/Edit. The Edit GuardPoint dialog box is displayed.

5. In the Designated Primary Set drop-down list, select a different client.

6. Click Save.

The GuardPoint is updated successfully with the new Designated Primary Set.

Validating the Designated Primary Set

In CipherTrust Transparent Encryption, you can get the list of designated primary clients for the guard path if you have configured a Designated Primary Set.

• To get the list, type:

  voradmin ldt group get_dp <guard path>
  

  Example

  voradmin ldt group get_dp /test/nov25
  

  Response

  LDT GuardPoint Primary: 192.68.34.54
  LDT GuardPoint Designated Primary List: 192.68.34.53,192.68.34.54
  

  Note

  If the DPS is not configured and you type the command to get the list, the command output shows N/A for the designated primary list:

  LDT GuardPoint Primary: 192.168.34.54
  LDT GuardPoint Designated Primaries: N/A

Reference Information

• Designation of Primary role and Primary Set in an LDT GuardPoint Group

Windows AccessOnly Nodes

CIFS protocol supports exclusive mode for access when opening files. When a client opens a file in exclusive mode, other clients are blocked from accessing the file. CTE Windows enables the option for configuring an LDT Windows client for AccessOnly.

• Windows AccessOnly clients are optional

• Windows AccessOnly clients are clients that have a GuardPoint applied on a CIFS share, but are not a part of an LDT Communication Group or an LDT GuardPoint Group.

• They have the same designated GuardPoint applied as other LDT GuardPoint Group clients, however, Windows AccessOnly clients do not participate in data transformation.

• Windows AccessOnly clients guarding a CIFS path do not have a primary or secondary role assigned to them.

• Apply GuardPoints on a CIFS paths from an LDT GuardPoint Group client first, before applying the same GuardPoints to a Windows AccessOnly client.

Converting to/from AccessOnly clients

To designate a Windows LDT client as a Windows AccessOnly client, use either of the following methods:

• At the time of registration with CipherTrust Manager, select the checkbox to designate this client as AccessOnly

• If the client is already registered with a CipherTrust Manager:

  1. Remove the client from any LDT Communication Group that it is in.

  2. Select the option "LDT Access Only" on the client page.

To convert an Windows AccessOnly client to an LDT Node:

1. Unguard/disable the GuardPoint from the Access Only client.

2. Un-check the "LDT Access Only" checkbox on the client page on CipherTrust Manager.

3. Add the client to the relevant LDT Communication Group.

4. Enable/apply the GuardPoint on the CIFS path from this new LDT client.

Reference Information

• For information on using Windows AccessOnly clients, see Sharing and Reading Encrypted Data with Windows and Linux Clients

• For general information, see LDT AccessOnly clients

Best Practices for Upgrading

• Triad Nodes: Upgrade the LDT Communication Group triad clients consecutively. Within each triad, upgrade the replica nodes before upgrading the master nodes. When the master node is upgraded, the fails over to one of the replica clients, which then becomes the new master. Identify the triad nodes of a LDT Communication Group by typing:

  voradmin ldt group comm_info
  

• LDT GuardPoint Group: Upgrade the secondary clients first, followed by the primary client. To check the current client role and status of the LDT GuardPoint Group, type,

  voradmin ldt group list <guard path>
  

• Ensure that you perform the upgrade only when LDT is not in progress or is in a SUSPENDED state.

Reference Information

• Upgrading an LDT Communication Group

Failure Scenario examples

Secondary client crash (Non-Triad client)

Scenario

• Nodes A, B, C, D, E, and F are part of the LDT Communication Group

• A, B, and C are designated as Triad clients

• An NFS/CIFS share is guarded on clients D, E, and F, forming an LDT GuardPoint Group where client D is the LDT primary. After the LDT GuardPoint Group has been active for a while, client E crashes.

Outcomes

• If client E remains down, verify the status of the LDT GuardPoint Group. From the LDT primary, (client D), type:

  voradmin ldt group list | check

• If client E shows as UNKNOWN, even after rebooting, check if the network share is mounted on E. If it's not mounted, fix the network connectivity. Once resolved, client E should rejoin the LDT GuardPoint Group as a secondary.

• If client E does not reactivate, remove the client from the LDT GuardPoint Group. From the LDT primary (client D), type:

  voradmin ldt group remove E

Primary Node Crash (Non-Triad Node)

Scenario

Same setup as above, but this time, Node D crashes.

Outcomes

• If client D does not reactivate: remove client D from the LDT GuardPoint Group. From any of the secondary clients (E or F), type:

  voradmin ldt group remove D <guard path>
  

• If client D reactivates but fails to guard the share, repair the LDT GuardPoint Group from any of the secondary clients (E or F), type:

  voradmin ldt group repair D <guard path>
  

Communication Group in Inconsistent State

Scenario

• Nodes A, B, C, D, and E are part of the LDT Communication Group.

• A, B, and C are Triad clients.

• An NFS/CIFS share is guarded on clients C, D, and E, with D as the primary and C and E as secondaries.

• If clients A and B (both Triad clients) fail at the same time (gracefully or ungracefully), the LDT Communication Group enters an inconsistent state

Outcome

• Restart the secfsd service on all clients to restore the LDT Communication Group

Primary Node Ungraceful Reboot (Triad Node)

Scenario

• Nodes A, B, C, D, and E are part of the LDT Communication Group.

• A, B, and C are Triad clients.

• An NFS/CIFS share is guarded on all clients, and client A is the primary for the LDT GuardPoint Group.

• Node A undergoes maintenance or a software update, and is rebooted with the expectation of a graceful failover to one of the secondary clients. However, failover does not occur. Once client A reactivates, it fails to guard the network share and displays: Group Join Failed, needs LDT repair in secfsd -status guard output.

Explanation

During shutdown, the secfs service stops, which disables all GuardPoints. A successful disable operation triggers failover to another secondary client. However, if the system proceeds with the shutdown before the service is cleanly stopped, it results in an ungraceful shutdown, and the failover does not happen.

Outcome

Run the repair command from any active secondary client, type:

    voradmin ldt group repair <failed hostname> <guard path>

Reference Information

• See Failover for the LDT Communication Group Master and the LDT GuardPoint Group

Troubleshooting

Issue: Degraded mode

LDT Communication Group has less than 3 clients.

Solution

An LDT Communication Group must contain at least 3 clients.

Issue: LDT Communication Group clients have multiple/different masters

An LDT Communication Group can only have one master. If the LDT Communication Group has more than one master, it means that there are network disruptions among the clients and the clients cannot reach each other.

Solution

To recover from this situation, establish robust connections among the clients and make sure the clients can talk to each other.

Issue: Communication Monitor and/or Servers are down on some clients

Either the Communication Monitor servers, or the CIFS/NFS servers are down, on a client, due to a system crash or graceful shutdown.

Solution

Restart the client/secfsd if the client can be reached. If you cannot reach the client, remove the client from the LDT Communication Group.