Server Groups: Shared Floating Licenses and Load Balancing

This week's theme:  Cool Tech Tips

 

NOTE: This Tech Tip was written for ARS 6.3, and the section on shared floating licenses is not relevant for ARS versions 7.1 and up.

Server Groups: Shared Floating Licenses and Load Balancing

Last week we discussed creating server groups and utilizing the fail-over feature. This week we'll dive into shared floating licenses and load balancing.

Shared Floating Licenses

An additional benefit of a server group is the ability for floating licenses to be shared across the group. When a set of floating licenses is purchased for a server group environment, an individual license is created for each server with a special tag that associates it with the server group. The same number of floating licenses must exist on each server in the group. The figure below shows a floating license definition useable in a server group.

Note: Click images for full screen view.

Figure 1:  Server Group Floating License Specification

In a server group environment, floating license tokens are claimed from the group as a whole. For example, in a two-server group, if a 5-pack of floating licenses is purchased, a separate user license with a count of five will exist on each system. As users Mary and Steve claim a license on Server A, two licenses will be in use. As users Bill and Joan claim a license on Server B, a total of four licenses will be in use. When Steve claims a license on Server B, the total licenses in use remains at four because Steve already has a license token from his previous access of Server A. When a fifth user, Tom, claims a license on Server A, a total of five licenses will be in use and the next new user attempting to get a license on Server A or Server B will not be granted the license.

Using a Load Balancer

A load balancer is a transparent network device that distributes the traffic from multiple clients to a group of servers. It distributes the workload among the servers to achieve a more balanced usage of available resources. It also provides for high-availability through redundancy and fail-over protection. If one AR System® server in the group becomes unavailable for hardware or software reasons, other AR System servers in the group assume the workload. Users already connected to a server that is no longer running will be automatically connected to another server the next time they access the system, and they will be unaware that a server failure occurred.

You can think of the load balancer as a virtual system, or as one "super" AR System server. In the Remedy environment, the load balancer is given a virtual IP address that is used by Remedy User clients to connect to the group of servers. When the load balancer receives a client request, it passes the request to one of the actual AR System servers within the group. The chosen AR System server performs the work and sends the results to the client.

For technical reasons, all traffic from a single client must be routed to the same actual server. This is controlled by the "sticky" option in the load balancer configuration. The figure below illustrates a sample load balanced configuration, with two of the special operations (Administration, Escalation) spread between two different servers.

Figure 2:  Sample Load Balanced Configuration


Summary

With the Server Group feature of AR System 6.0, the Administrator now has an improved platform for running a multi-server, shared database system. Coupled with a load balancer on the front-end, all the components are in place to create a highly available, reliable, and scalable environment for AR System applications.

~Bob
Staff Product Developer, AR System Server team
Joined Remedy in September 1997