![]() ![]() When deploying Jump Clients in a clustered environment, the Jump Clients are initially deployed from, and communicate with, the primary node. All of this coordination between traffic nodes and clients is controlled by the primary node and happens automatically in the background. 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. 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. 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. Each may bind additionally to the other's traffic node depending on what is occurring within the session. The representative and customer independently bind to their own traffic nodes. Session initiation always occurs through the primary node and then bridges with the appropriate traffic node once the session is initiated.Īdministrators control and define how a traffic node for a representative or customer client is chosen. From here, a customer can choose from the representative list, enter a session key, or use issue submission. The public portal for your support site resides on the primary node B Series Appliance. ![]() Initiating an attended support session is still done in the same method as a non-clustered environment. Thus, any external authentication providers that need to be configured in your environment are done at the primary node level. The representative console is downloaded from the primary node, and authentication into the representative console takes place against the primary node. ![]() In a clustered environment, all Remote Support traffic originates by first talking to the primary node. 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. 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 important in situations where a support organization may span regions or have global reach. BenefitsĪ key benefit of clustering via BeyondTrust Atlas Technology is the ability to distribute a site geographically. 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.įor information on Atlas in the Cloud, please see BeyondTrust Atlas in the Cloud. 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.Īll reporting is handled the primary. The traffic nodes retain a /login interface on each respective B Series Appliance however, the respective B Series Appliance has limited configuration settings available. 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. In addition, all configuration of the Remote Support site is handled on the primary node. 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.Ī 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. ![]() Essentially, Atlas Technology enables large support organizations to scale horizontally across multiple B Series Appliances rather than vertically on a single B Series Appliance.Ĭreating a clustered Remote Support environment introduces new terminology: the primary and traffic node concept. Atlas Technology allows a support organization to be effectively dispersed over different geographical locations and to support a global user base. 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. ![]()
0 Comments
Leave a Reply. |