Load Balancing
Digest
Load-Balancing is the process by which activity in the system is evenly distributed across a network (multiple application servers) so that no single device/server is overwhelmed.
With the re-architecture of Cascade Server 5.0, users are provided the ability to load balance multiple application servers to reduce downtime and improve performance. This involves running multiple Cascade Server 5 machines behind a proxy, or load balancer; typically this will be Apache. To the end user, the CMS address stays the same; behind the scenes, one of many different application servers will handle each user’s requests.
Concept
Introduction to Load Balancing in Cascade Server
Load Balancing provides concurrency; it allows for more users in the system at one time. In addition, Load Balancing allows the system to handle server down-time more gracefully and includes failure detection. In the event of a server failure, for example, with three Cascade Servers running and Apache “in-front” of it handling load balancing, Apache will simply stop sending requests to the failing server.
Please Note- When using Load Balancing, it is recommended that you have all of your servers living on the same LAN.
This diagram illustrates a typical CS5 load balanced network topology. Requests from end users are received by an Apache instance running the mod_jk module. These requests are then dispatched by mod_jk to the CS5 machines. The CS5 servers interact with the database normally. Typically one will be able to run multiple CS5 servers against a single database. Sometimes, depending on the configuration, it may be desirable for the database to also be load balanced; this is currently outside the scope of this document. At present, only CS5 load balancing is supported by Hannon Hill.
Technical
Load Balancing Requirements
- All CS5 machines must be running the exact same version of the software.
- Running multiple CS5 nodes on the same physical machine is not supported.
- When upgrading a group of CS5 servers, all nodes must be brought down before the software is upgraded on each node.
- Hannon Hill supports using Apache 2+ mod_jk for fail-over and load balancing.
- Each CS5 node name must be unique.
Additional Notes
If you have CS5.0 deployed in something other than the ROOT webapp, you will need to ensure that your JkMount directive uses the same webapp name as the mount point.
Session replication will not be a part of the CS5.0 load balancing strategy. That means that any user sessions that are on a node will be terminated if that node is brought down. The user will see this event as being redirected to the login screen.
When running in a load balanced configuration, all servers on which Cascade Server are running must have their internal clocks synchronized to within one second of each other. The preferred solution is to use a common NTP (Network Time Protocol) server setting on all application servers.
Load Balancing Configuration
Tomcat Configuration
Each CS5.0 application server runs off of an included Tomcat 5.5 instance. In order to enable load balancing, edit the conf/server.xml file:
Add a jvmRoute=”nodename” attribute to the <Engine.../> element:
The name of each node must be unique across all CS5.0 servers.
Apache Configuration
The supported load balancing configuration includes Apache 2 + mod_jk. This document assumes that Apache 2 will load mod_jk as a shared module. This document also assumes that the reader has some familiarity with configuring Apache. A tutorial / guide to building and configuring Apache may be provided later.
Once Apache 2 and mod_jk have been built, ensure that the following configuration file changes are made:
The JkMount directive assumes that the sole purpose of this apache instance is to proxy to a group of CS5.0 machines. If this is not the case, one may provide these directives in the context of a virtual host.
Note also that depending on how Apache is launched on your system, it may be necessary to provide full paths to the shared memory file, log file, and workers file.
The workers.properties file is the configuration file that mod_jk uses to determine where to relay requests. We’ll go over each one of the lines in this configuration:
This defines the load balancer worker. It will distribute requests to each CS5.0 server.
Defines a worker called xpproone. This must be the same name as that node’s jvmRoute attribute in server.xml. This worker is available at 192.168.168.128. Note that the port should be the same across all instances. This worker has a load factor of 1. Higher load factors will get more requests from mod_jk.
Similarly defines a worker called xpprotwo. The semantics in the previous section also apply here.
Defines the loadbalancer worker to be special type of worker that can distribute requests to other workers. Configures that worker to distribute its requests to xpproone and xpprotwo.
Tying it Together
Once configuration files have been edited, start Apache, and each Tomcat node. After the servers have been brought up, users should be able to access Cascade Server through Apache.
Troubleshooting
I try to log in, but keep getting redirected to the login screen over and over.
This is usually a result of a misconfiguration with mod_jk. Make sure that each node’s jvmRoute attribute is set correctly, and is the name of the worker as defined in worker.properties.
I can log in, but I get automatically logged out repeatedly.
This is a common result of having asynchronized internal clocks on multiple servers. When running in a load balanced configuration, all servers on which Cascade Server are running must have their internal clocks synchronized to within one second of each other. The preferred solution is to use a common NTP (Network Time Protocol) server setting on all application servers.