Load balancers in AR System
High-load environments present special issues relating to performance, hardware capacity, system downtime, and so on. A high-load environment presents two major issues:
- System scalability is dependent upon the capacity of the hardware. If the existing hardware is at its limit, it needs to be replaced by bigger, more powerful hardware. New hardware is often much more expensive than existing hardware. The old hardware could only be used as a "hot" standby system. (A hot standby system is running and ready for immediate service. It can be switched into service manually or automatically upon detection of a failure in the active equipment.)
- The system needs to be available for as much time as possible. This can be challenging and often requires redundant systems. The backup system is often in hot standby mode and is only activated in the event of an outage. Only one system can be used in production.
The solution to both challenges is a technology commonly used in the web environment—a load balancer. You can use a hardware load balancer to improve the scalability and availability of Action Request System.
A load balancer is a valuable component in building a scalable, highly available AR System server infrastructure. Scalability is achieved through the ability to add AR System server as demand and workload increase. High availability is achieved by configuring multiple AR System server to handle client requests, and if one server fails, other servers in the group handle the additional workload. By creating an infrastructure that scales with workload and reduces downtime, you can maximize the return on your Action Request System investment.
What a load balancer does
A load balancer is a transparent network device that distributes the traffic from multiple clients to several servers, preventing AR System server from becoming overloaded. Distributing workload among several AR System server can lead to performance benefits and cost savings. Buying many smaller machines is far less expensive than paying for a single high-performance machine. Since load balancers redirect incoming traffic, they are sometimes referred to as redirectors.
A load balancer also provides high availability through redundancy and failover protection. Failover is the process of moving operations from one server to another upon service or machine failure. If one AR System server becomes unavailable for software reasons or if the hardware fails, other AR System servers in the group (or cluster) can take over the workload. Users will not be aware of any problems, nor will they experience any downtime.
Most load balancers work on the TCP level of the network protocol and can therefore balance the load of many applications that use this protocol. Some examples include HTTP, FTP, and the AR System server. The load balancer is transparent to users, so the client application cannot see it and is unaware that the client requests are being load-balanced.
You can think of the load balancer as a virtual system, or as a super AR System server in this case. The load balancer is given a virtual IP address and a DNS name, either of which Mid Tier clients use when connecting to the group of load-balanced AR System servers. Both the short and long DNS names must be resolvable. (Long DNS names are fully qualified with a domain.) When a client request is received, the load balancer 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. This balancing of connections spreads out the client requests evenly and distributes the load.
For performance reasons, the Action Request System API clients establish a connection with the AR System server and keep the connection until the session is terminated or the connection is interrupted.
How load balancers route requests
Load balancers forward data packets in the same manner as network address translation (NAT) devices. The packets are forwarded at the TCP level with modified address information to the target system.
To distribute client requests across each group of AR System servers, the load balancer can use various scheduling policies. The following two policies are the most common:
- Round Robin—This policy directs client requests to eachAR System server, one at a time. Successive requests are routed to the next AR System server, and the next, and the next. This process is repeated consecutively.
- Least Connections—This policy directs client requests to the AR System server that has the fewest connections.
For better throughput, most load balancers offer multiple network ports. This method avoids collisions between the incoming and outgoing routed network traffic.
The load balancer also offers clients the ability to stick to one target system. This means that all requests from a single client are routed to the same system.
Using a load balancer with server groups
The load balancer acts like a NAT device that routes any TCP or UDP traffic. Since the AR System server uses an ONC-RPC implementation that is layered on top of TCP/IP, AR System server traffic can be load balanced. Server groups are independent of load balancing, but the concepts are complementary.
You can run multiple AR System servers in a cluster and distribute the load between them with a third-party load balancer. All of these instances work on the same database, so they are always in sync. This is a typical server group configuration. This clustered environment creates a highly scalable and highly available AR System installation.
The servers in a server group can be given different responsibilities (such as one for handing approvals, another for escalations, and so on). The servers in the group are aware of each other, and if one server fails, another can take over its responsibilities.
When installing applications in a server group environment, install all of the software on each computer before setting up the server group. This is necessary because the installer creates required configuration file entries, creates all required folders, and puts all the binary files in place. After installing the software, add each server to the server group, and configure the load balancer to distribute load among these instances.
The example below uses a load balancer to direct traffic to a server group of three AR System servers. In the example, the uppermost AR System server has the primary ranking for the Administration and Escalation operations. The other two AR System servers can be used to back up these operations, when the uppermost server is not running.
Basic load-balancer configuration with multiple AR System servers 
For more information, see Configuring-a-hardware-load-balancer-with-AR-System.
If the load balancer belongs to a different domain than the AR System servers, then the fully qualified domain name of the Server-Name alias will be wrong. In this case, the domain name parameter should be specified in the ar.cfg file for each AR System server using the domain of the load balancer.