Application Server Load Balancing & Failover

What is High Availability

High availability is a computing concept whereby a user’s request does so with the utmost reliability, by using built-in failover mechanisms that mitigate against the effects of any one component failing. Such systems typically have redundant hardware and software that makes the system available despite failures. Well-designed high availability systems avoid having single points-of-failure. Any hardware or software component that can fail has a redundant component of the same type.

When failures occur, the failover process moves processing performed by the failed component to the backup component. This process remasters systemwide resources, recovers partial or failed transactions, and restores the system to normal, preferably within a matter of microseconds. The more transparent that failover is to users, the higher the availability of the system.

What is Application Clustering?

Application clustering (sometimes called software clustering) is a method of turning multiple computer servers into a cluster (a group of servers that acts like a single system) to provide higher availability and scalability. In a cluster, each of the servers maintains the same information and collectively they perform administrative tasks such as load balancing, determining node failures, and assigning failover duty. The other clustering method, hardware clustering, requires that specialized hardware be installed in a single server that controls the cluster.

Because servers can easily be added or removed from the cluster as needs dictate, an application cluster is more scalable than its hardware-based counterpart. Furthermore, because it doesn’t require specialized hardware, an application cluster tends to be easier and cheaper to configure. For these reasons, application clustering is the more commonly practiced method.

High Availability, Clustering, Load Balancing and Failover in PeopleSoft

PeopleSoft application provides out-of-box high availability by using Tuxedo’s domain failover mechanism. Instead of clustering application servers, high availability is provided by running multiple domains and using software loadbalancing and failover.

Within a PeopleSoft system all application server processes belong to a domain. There can be multiple domains running on a host but domains do not span multiple hosts. Therefore each host will contain one or more application server domains. Within a domain there are multiple application server processes that handle service requests. The total number of application server processes in a domain is configurable and should be set according to the server’s capacity. Service requests are load balanced across these server processes. If any one of these application server processes crash, Tuxedo will route any active call currently handled by the affected process to another available server process in the domain. It will also restart the failed server process if needed. This is application server recovery mechanism. The failure is handled transparently and no error is reported to the webserver (JOLT client).

To do application server load balancing and failover, you need two or more applications servers. These application servers should ideally be running on different servers but if they’re on the same server, then the domain name and Jolt port should be different from each other.

PeopleSoft application only supports load balancing of application server domains using the configuration.properties file. External load balancers are not supported and do not work when trying to load balance application server domains. Read here for fundamental concepts of  load balancing.

The configuration.properties file in mention resides in your webserver and is located at <PS_HOME>/webserv/<DOMAIN-NAME>/applications/peoplesoft/PORTAL.war/WEB-INF/psftdocs/<PIASITE>/

There are different options you can specify in the configuration.properties file to load balance requests and also for failover in case a domain is down.

Load Balancing and Failover

In the configuration.properties file, there is a variable, psserver, which is used to provide the application server name and jolt port number. If you’re connecting a single web, the variable would be like:

psserver=<server>:<port>

where server is application server name or IP address and port is the application server jolt port number.

for example, psserver=app.peoplesofttutorial.com:9000

In case of multiple appservers, you use comma to provide multiple appserver names:

psserver=<server1>:<port1>,<server2>:<port2>

for example, psserver=app1.peoplesofttutorial.com:9000,app2.peoplesofttutorial.com:9000

It is also known as equally weighted load balancing.

Note: The web server uses the round robin algorithm for load balancing. Oracle recommends using server name instead of IP address in psserver.

Tip: In a multi-server architecture, it is best not to use psserver defined exactly the same across all web instances. For example, if you have 3 web and 3 appservers, you can make “rotate” the server names in the psserver as well. For example:

1st web psserver=<server1>:<port1>,<server2>:<port2>,<server3>:<port3>

2nd web psserver=<server2>:<port2>,<server3>:<port3>,<server1>:<port1>

3nd web psserver=<server3>:<port3>,<server1>:<port1>,<server2>:<port2>

Weighted Load Balancing

It is common to have equal configuration servers and you may never need to have a weighted load balancing enabled, but it is good to know just because some place may need it. Using the above concept, you can also provide different “weights” when doing PeopleSoft application server load balancing and failover. Weight values are integers 1–10, with 1 being lowest and 10 being a highest load. Servers that can handle extra work can take heavy loads, while servers that are either less powerful or are configured for some other activities as well can take lower loads.

Weighted load balancing is done just by appending #Wt to the jolt port number used. The following format is used.

psserver=<server1>:<port1>#Wt,<server2>:<port2>#Wt

For example,

psserver=app1.peoplesofttutorial.com:9000#7,app2.peoplesofttutorial.com:9000#3

In this case, appserver1 would receive 7 requests for every 3 requests going to appserver2.

Strict Failover with Load Balancing

When implementing failover, you have the option to do a sequential or weighted failover/backup. You add the failover string within curly brackets at the end of the server entry.

psserver=<host>:<port>#wt{failover servers}

Sequential Failover with Load Balancing

To set sequential backup, you separate multiple backup servers using a semicolon (;).

psserver=<server1>:<port1>#Wt{<server3>:<port3>;<server4>:<port4>},<server2>:<port2>#Wt

In this case, server3 and server4 are failover servers when server1 is down. The system assigns server3 the requests when server1 is down. Server4 gets the the requests when both server1 and server3 are down.

By appending #Wt, the above equation can be used for added weight as well. With the failover string, you can set weighted backup by separating failover server with a comma (,).

psserver=<server1>:<port1>#Wt{<server3>:<port3>#Wt,server4>:<port4>#Wt},<server2>:<port2>#Wt

You can assign weighted load balancing to the backup servers just as you would a primary server.