Bomgar Atlas Technology Overview
Bomgar Atlas Technology is intended for large enterprise customers performing more concurrent sessions than can be effectively or efficiently handled by a single existing Bomgar 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 appliances rather than vertically on a single appliance.
Creating a clustered Bomgar support environment introduces new terminology: the master and traffic node concept. The master node serves as the main point of configuration for the site and also serves as the session initiation point of presence for the entire Bomgar support site.
A Bomgar administrator accesses the master 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 Bomgar site is handled on the master node. So even though a cluster consists of multiple appliances, the /login administrative interface resides on the master node and propagates most configuration settings to the traffic nodes automatically. The traffic nodes retain a /login interface on each respective appliance; however, the respective 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 appliances involved.
All reporting is done from the master. The actual session recordings reside on the respective traffic node where a customer client connected; however, when requesting to view any of the recordings, a dynamic link allows expected Bomgar reporting behavior just as if the recording resided on the master itself.
A key benefit of clustering via Bomgar 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 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 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 Bomgar traffic originates by first talking to the master node. The representative console is downloaded from the master node, and authentication into the representative console takes place against the master node. Thus, any external authentication providers that need to be configured in your environment are done at the master 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 master node 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 master 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 master node and happens automatically in the background.
When deploying Jump Clients in a clustered environment, the Jump Clients always communicate directly with the master node. For Jump Clients, the polling intervals always occur between the respective Jump Client and the master node.
As mentioned, all reporting is done from the master node /login interface. The actual session recordings reside on the traffic node appliance that the customer client had bound to. If an aggregate, off-appliance session log store including session recordings is needed, a Bomgar Integration Client must be configured to talk to the master node appliance and must be able to reach all traffic node appliances in the cluster.