Perform a BeyondTrust Atlas Technology Cluster Test

This step is optional for your deployment.

Given the extreme flexibility of BeyondTrust's Atlas technology, it is impossible to give a detailed and rigorous set of testing steps which will apply in all cases, but a general process with guidelines and expected behaviors should allow administrators to develop more detailed test procedures specific to their environments.

Review the Planning Process

An Atlas deployment revolves around the primary B Series Appliance routing client traffic to various nodes. Therefore, testing an Atlas cluster involves three basic steps:

1. Identify which node should be expected to handle any given client connection.
2. Run one or more test connections using BeyondTrust software from the Atlas cluster.
3. Check which traffic node a given test client connects with.

The following sections explain how to plan and implement a testing methodology based on these steps.

Identify the Expected Node

The traffic node chosen to handle any given client connection is based on the Method for Choosing Traffic Nodes setting. Please see Methods for Choosing Traffic Nodes in an Atlas Cluster. The current setting can be checked from the /login > Management > Cluster page of the BeyondTrust interface. The first steps of any test, therefore, are to verify the current settings and status of the cluster. To do this, perform the following steps on all traffic nodes in your BeyondTrust Appliance B Series cluster.

1. Log in to the /login interface as an administrator.
2. Go to /login > Management > Cluster.
3. Verify the configuration details and review the status history.

Depending on the settings, it is possible to artificially route new connections to different traffic nodes by modifying the settings of the client's local host. For example, if Method for Choosing Traffic Nodes is set to Timezone Offset and the local host's timezone setting is modified such that it matches the timezone offset of the desired traffic node, new BeyondTrust client connections made from the modified host will go to the desired traffic node.

Apart from modifying host settings per the Method for Choosing Traffic Nodes setting, it is also possible to simply hard code the network prefixes of the appropriate client hosts into the configuration of the respective traffic node. Once done, clients on the given networks will always route to the traffic nodes assigned to those networks regardless of which method is being used for choosing traffic nodes. This configuration is done from the Edit Node option in the cluster configuration page of the primary node. Simply enter the network prefixes in the Network Address Prefixes field of the traffic node to override the extant method for choosing traffic nodes.

Run Test Connections

In general, all BeyondTrust Clients are always connected to the primary node while they are online. Once a session is started, the client makes an additional connection to the appropriate traffic node (its home traffic node) based on the cluster configuration logic. In addition, the representative console involved in the session will make a third connection, which is to the home traffic node of the remote client involved in the session. Finally, if the representative uses Show My Screen during the session, the remote client makes a connection to the representative's home traffic node.

For example, if a representative in the US remotely connects to a customer in EMEA, the customer client in EMEA connects to the primary and the EMEA traffic node (its home traffic node). The representative console connects to the primary and the US traffic node (its home traffic node). Once the representative starts screen sharing, the representative console also connects to the customer's traffic node in EMEA in order to receive the incoming stream of the customer's screen. Thus, the representative console is connected to the primary, its own home traffic node, and the customer's home traffic node.

To take the scenario one step further, if the representative starts Show My Screen with the customer, then the customer client in EMEA connects to the representative's home traffic node in the US to receive the stream from the representative.

Check Connections

The API command get_connected_clients is the best way to gather details about which sessions are connected to any particular node. For details, see the API Programmer's Guide. However, if the total number of clients is small, you can use the Connected Clients table on the /login > Status > Information page of the BeyondTrust interface.

While all online clients always connect with the primary node, only active sessions show in the connected client list for a traffic node. If the traffic node itself goes offline during the session, then the session must be restarted; the reconnect always is attempted to the same traffic node. This reconnect logic is the same in an Atlas environment as a stand-alone B Series Appliance deployment.