BeyondTrust Atlas Technology Overview
BeyondTrust Atlas Technology is intended for large enterprise customers performing more concurrent sessions than can be effectively or efficiently handled by a single existing B Series Appliance model. Atlas Technology allows a support organization to be effectively dispersed over different geographical locations and to support a global user base. Essentially, Atlas Technology enables large support organizations to scale horizontally across multiple B Series Appliances rather than vertically on a single B Series Appliance.
Creating a clustered Remote Support environment introduces new terminology: the primary and traffic node concept. The primary node serves as the main point of configuration for the site and also serves as the session initiation point of presence for the entire Remote Support deployment.
A Remote Support administrator accesses the primary node to create a cluster and define the structure of the traffic nodes and method of choosing a traffic node for a client connection. In addition, all configuration of the Remote Support site is handled on the primary node. So even though a cluster consists of multiple B Series Appliances, the /login administrative interface resides on the primary node and propagates most configuration settings to the traffic nodes automatically. The traffic nodes retain a /login interface on each respective B Series Appliance; however, the respective B Series Appliance has limited configuration settings available.
Licenses are designated for the site as a whole, and license utilization is not affected by the fact that there are multiple B Series Appliances involved.
All reporting is handled the primary. The session recordings reside on the respective traffic node where a customer client connects; however, when requesting to view any of the recordings, a dynamic link allows expected Remote Support reporting behavior just as if the recording resided on the primary itself.
For information on Atlas in the Cloud, please see BeyondTrust Atlas in the Cloud.
A key benefit of clustering via BeyondTrust Atlas Technology is the ability to distribute a site geographically. This is important in situations where a support organization may span regions or have global reach. For instance, if a customer support request originates in Sydney and a traffic B Series Appliance residing in Australia handles the support session, then the support experience is more responsive and efficient. This is mainly due to the bulk of the session traffic staying local to the B Series Appliance in Australia versus the client using a traffic node in NYC, where it would have to traverse all traffic data back and forth to NYC, thereby increasing the transport latency of the session.
In a clustered environment, all Remote Support traffic originates by first talking to the primary node. The representative console is downloaded from the primary node, and authentication into the representative console takes place against the primary node. Thus, any external authentication providers that need to be configured in your environment are done at the primary node level.
Initiating an attended support session is still done in the same method as a non-clustered environment. The public portal for your support site resides on the primary node B Series Appliance. From here, a customer can choose from the representative list, enter a session key, or use issue submission. Session initiation always occurs through the primary node and then bridges with the appropriate traffic node once the session is initiated.
Administrators control and define how a traffic node for a representative or customer client is chosen. The representative and customer independently bind to their own traffic nodes. Each may bind additionally to the other's traffic node depending on what is occurring within the session. If screen sharing is initiated, then the representative binds to the traffic node that the customer client is bound to, in order to receive the traffic stream that contains the actual screen sharing information.
Likewise, if the representative shares their screen within the session and chooses to send a file from their machine to the customer via the chat interface, then the customer client binds to the traffic node of the representative in order to receive the incoming file or to view the representative’s screen. When a representative transfers a session or if a session is shared between representatives, then the incoming representative binds to the traffic node of the customer in order to view the customer’s screen. All of this coordination between traffic nodes and clients is controlled by the primary node and happens automatically in the background.
When deploying Jump Clients in a clustered environment, the Jump Clients are initially deployed from, and communicate with, the primary node. Once deployed, they resolve a priority list of traffic nodes based on the site's currently set connection method. Jump Clients reconnect and use a traffic node to obtain future updates and to proxy communications to the primary node. This allows more Jump Clients to upgrade at once, and additionally allows the primary node to handle sessions and normal traffic with less customer impact during the process. If a Jump Client is unable to connect to its preferred traffic node, either due to capacity or an outage event, it falls back to another traffic node, or to the primary node if no traffic nodes are available.
As mentioned, all reporting is done from the primary node /login interface. The actual session recordings reside on the traffic node B Series Appliance that the customer client had bound to. If an aggregate, off-B Series Appliance session log store including session recordings is needed, a BeyondTrust Integration Client must be configured to talk to the primary node B Series Appliance and must be able to reach all traffic node B Series Appliances in the cluster.
Representatives using a mobile or web representative console to provide support always bind to the primary node. Similarly, customers using a mobile customer client always bind to the primary node.