Methods for Selecting Traffic Nodes in an Atlas Cluster

After defining traffic nodes in your BeyondTrust Atlas Technology environment, you can decide on the process which clients use to connect to them.

Session initiation always occurs through the primary node and then bridges with the appropriate traffic node. Administrators control and define how a traffic node for an access console or endpoint client is chosen using the Method for Choosing Traffic Nodes dropdown in the primary node. Once a node is chosen, the primary node usually provides the unique DNS address of the respective traffic node to the client software. The only traffic node setting where an IP address would be specifically provided would be when using the IP Anycast selection method.

If the network prefixes are defined, the Method for Choosing Traffic Nodes setting will be overridden. Please see Set Up the Traffic Nodes in an Atlas Cluster.

The available methods for defining the connection are:

• Random: Randomly chooses the node to which a client will connect.

  This method will most likely be used if you have taken the time to accurately define all network address prefixes for each traffic node. If a client's network does not match any of the predefined networks on any of the participating traffic nodes, then the client will be assigned a random traffic node. Each traffic node's network address prefixes should be well-defined, so that client network matching will be automatic.

  This method is simple and inexpensive and enables you to rely on the network prefix defined for each traffic node. However, if your clustered environment spans multiple regions and your network prefixes are left undefined, this method could yield less than optimal results.

• SRV Record Lookup: Similar to A Record Lookup, SRV traffic node selection will rely on the underlying DNS infrastructure to determine the node to which to connect. The main difference between the two methods is that SRV records have the ability to assign a weight and a priority to a specific host entry. The advantage that this gives you is a method for providing load balancing and backup service at the network level.

  Note that this method requires that you have control over the DNS infrastructure used by your clients. If you are deploying in a WAN environment, the use of SRV records is probably already a common practice which you can leverage to provide an extra layer of redundancy and load balancing to your clustered BeyondTrust environment.

• A Record Lookup: Instructs clients to attempt connection to a specified (shared) hostname and rely on the DNS configuration to return the appropriate IP address of the traffic node for connection.

  This method can be used within an environment where you have complete control of the DNS resources which all of your customers will be using. For instance, you could have an A record defined for traffic1.access.example.com. For your customers in the US who use DNSserver01, the A record points to IP address 1.1.1.1. For your customers in Europe who use DNSserver02, the A record for traffic1.access.example.com resolves to 2.2.2.2.

• IP Anycast: Uses a shared IP address among all traffic nodes and relies on the network infrastructure to return the nearest traffic node to the client.

  If you are part of an organization that already has a global content delivery network in place, this may be a preferable option for you. IP Anycast is a robust solution but can be complicated to implement and maintain. However, if you already have this type of infrastructure in place, this will be your best method for endpoint and user client traffic node selection.

• Timezone Offset: A simple and inexpensive method for configuring a BeyondTrust cluster.

  The time zone offset process involves detecting the time zone setting of the machine hosting the client and using that setting to match the appropriate traffic node which has the closest time zone offset. The time zone offset is derived from the customer time zone setting relative to Coordinated Universal Time (UTC). The time zone offset method is good for testing and can be used in production. Specifically, in cases where multiple traffic nodes are located in the same time zone, this method may not be the most effective solution. A DNS-based solution would be the preferable method in a production environment.

The Use primary node's email configuration on traffice nodes checkbox ensures traffic nodes use the same email configuration as the primary node.

Click Save Changes to keep all configured settings.