Hello All,
In this blog, we will go through the steps necessary in order to configure Apache Web Server as load balancer for Tomcat Application server. This document is helpful for BI 4.0/4.1 as it has Tomcat 6 or 7.
Why to Loadbalance?
To reduce a load on the web applications server alone you can setup a dedicated web server.
You can use Apache web server to load balance Tomcat, Weblogic, Websphere or other Web applications servers.
Please go through the Web Application Deployment guide for more details.
Why use Apache web server as a Loadbalancer?
The amount of request and users requires multiple application servers running so that all requests can be handled in timely manner, and to have a safety option if one of the applications server crashes. One of the common approaches in situations like that is to use Apache web server as a load balancer for the web traffic targeted to multiple tomcat applications servers. Because Apache web server is quick and has only one responsibility to forward requests to tomcat servers which do the actual work such as loading data from the database and returning it to the user. It makes sense to use it as a load balancer to easily relieve the pressure on hard worked tomcat instances.
NOTE: This blog is intended to provide the steps to configure Tomcat loadbalancing using Apache. Please note that SAP would not assist in the setup as well as post-configuration steps as this solution involves configuration of 3rd party applications.
Ingredients:
1. SAP BusinessObjects Business Intelligence platform 4.0
2. SAP BusinessObjects Business Intelligence platform 4.1
3. Any OS
4. Apache 2.x
5. mod_jk as connector
The following steps outline the required downloads for Apache 2.2:
1. Download the Apache 2.2 64-bit package from http://www.apachelounge.com/download/win64/
• At the time of writing, the latest version was 2.2.9
2. Download the mod_jk connector binary from http://www.apachelounge.com/download/win64/
• At the time of writing, the latest version was 1.2.40
Extract the included mod_jk.so and place it in C:\Apache2\modules (or whichever directory you extract Apache to) after you have completed the next section.
Step 1: Installation of Apache service on Windows server.
1. Once you have extracted the Apache2.2, copy it to the appropriate drive. Eg: C:\Apache2
2. Launch command prompt & navigate till location C:\Apache2\bin.
3. Type below command
httpd -k install -n BOEXI40Apache
• Note that the CCM is configured to render any services labeled with a prefix of BOEXI40. By doing this we allow it to appear in the CCM for ease of management.
4. Change the display name of the service to include the version of Apache:
sc config BOEXI40Apache displayname= "Apache HTTPD 2.2.29"
• Note that if you have the World Wide Publishing Service (IIS) on the server, it is required that you stop/disable it or ensure it runs on a port other than 80. You may test that Apache is running properly by accessing http://localhost. If the server is up and running you should get a simple HTML page with the text, "It works!"
Step 2: Configure httpd.conf
1. Stop Apache & Tomcat service.
2. Navigate to C:\Apache2\conf.
3. Backup the existing httpd.conf.
4. Edit httpd.conf & add the below parameters to the end of the file:
# Load module
LoadModule jk_module modules/mod_jk.so
# Specify path to worker configuration file
JkWorkersFile conf/workers.properties
# Configure logging and memory
JkShmFile logs/mod_jk.shm
JkLogFile logs/mod_jk.log
JkLogLevel info
# Configure monitoring
JkMount /jkmanager/* jkstatus
<Location /jkmanager>
Order 'deny,allow'
Deny from all
Allow from localhost
</Location>
# Configure applications
JkMount /webapp-directory/* LoadBalancer
JkMount /jsp-examples/* loadbalancer
JkMount /servlets-examples/* loadbalancer
JkMount /clusterjsp/* loadbalancer
JkMount /* loadbalancer
JkMount /*.jsp loadbalancer
Here's a quick explanation of the parameters we just configured:
LoadModule | This command makes the mod_jk module available for use. The extension of the module itself will vary by operating system. |
JkWorkersFile | Sets the path to the worker configuration file, which we will create in the next step. |
JkShmFile | Sets the path to the shared memory files for the module. Generally, you'll want to keep this with the logs. |
JkLogFile | Sets the path to the module log file. |
JkLogLevel | Sets the level of logging for the module. The valid values for this attribute, in descending order by verbosity, are "debug", "error" or "info". |
JkMount | This is used to map a certain URL pattern to a specific worker configured in the worker configuration file. Here, we use it twice - once to enable /jkmanager as the access URL for jkstatus, a virtual monitoring worker, and once to map all requests we want to be handled by the cluster to the "lb" worker, a virtual worker that contains the load balancing capability. |
Location | This is a security constraint. The settings we have included allow access to the jkmanager only from the localhost (this is a Good Idea). |
Step 3: Configure cluster Workers:
1. Create a workers.properties under C:\Apache2\conf
2. Edit the worker.properties file & copy the below lines
#workers.java_home="C:\Program Files (x86)\Java\jre7"
worker.list= appserv1, appserv2, loadbalancer
#define appserv1 instance Tomcat worker
worker.appserv1.port=8009
worker.appserv1.host=<ServerName1>
worker.appserv1.type=ajp13
worker.appserv1.lbfactor=1
worker.appserv1.cache_timeout=600
worker.appserv1.socket_keepalive=1
worker.appserv1.socket_timeout=300
#failover node for appserv1
worker.appserv1.redirect= appserv2
#define appserv2instance Tomcat worker
worker.appserv2.port=8009
worker.appserv2.host=<ServerName2>
worker.appserv2.type=ajp13
worker.appserv2.lbfactor=1
worker.appserv2.cache_timeout=600
worker.appserv2.socket_keepalive=1
worker.appserv2.socket_timeout=300
#failover node for appserv2
worker.appserv2.redirect= appserv1
#define load balancer
worker.loadbalancer.type=lb
worker.loadbalancer.balanced_workers= appserv1, appserv2
worker.loadbalancer.sticky_session=true
For detailed explanation of worker.properties you can refer the below Apache link:
http://tomcat.apache.org/connectors-doc/generic_howto/loadbalancers.html
There is also WIKI SCN link for configuring Apache as Load Balancer which provides some more detailing on worker.properties:
http://wiki.scn.sap.com/wiki/display/BOBJ/Configuring+the+load+balancer
You can also refer the KBA for configuring Apache as a Loadbalancer in 3.1:
1529429 - How to create a Tomcat cluster with Apache Web server as load balancer and BusinessObjects Enterprise XI 3.1
As given in the 3.1 configuration there are certain changes that need to be done in server.xml files of the tomcat system. The same for Tomcat 7 has been addressed in the below section.
Step 4: Tomcat side configuration
1. Navigate to <Install Directory>\tomcat\conf
2. Back up server.xml file.
3. Uncomment
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" URIEncoding="UTF-8" enableLookups="false"/>
4. You should set jvmRoute to support load-balancing via AJP. In server.xml file locate jvmRoute. The “jvmRoute=worker1” can be changed to worker 1 or worker 2. All the Tomcat's that you include in the cluster you will have to make the changes in each server.xml file.
5. Now in server.xml file search for channelSendOptions="8", make sure you remove a ‘/’ after =”8”.
6. Now copy the below parameters after channelSendOptions=”8”.
<Manager className="org.apache.catalina.ha.session.DeltaManager" expireSessionsOnShutdown="false" notifyListenersOnReplication="true"/>
<Channel className="org.apache.catalina.tribes.group.GroupChannel">
<Membership className="org.apache.catalina.tribes.membership.McastService" address="228.0.0.4" port="45564" frequency="500" dropTime="3000"/>
<Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
<Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
</Sender>
<Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver" address="auto" port="4000" autoBind="100" selectorTimeout="5000" maxThreads="6"/>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
</Channel>
<Valve className="org.apache.catalina.ha.tcp.ReplicationValve" filter=""/>
<Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
<ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
<ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>
Explanation of the parameters:
Engine | This is the standard Engine element that defines Catalina as the component responsible for processing requests, to enable session replication; you must set the "jvmRoute" attribute to match the corresponding worker you have configured in mod_jk's workers.properties file. This value must be unique for every node included in the cluster. |
Cluster | This is the main Cluster element, within which all other clustering elements are nested. It supports a variety of attributes, but in this simple example, we have only configured one, "channelSendOptions". This attribute sets a flag within Tomcat's clustering class that chooses between different methods of cluster communication. These options are outside the scope of this article, but a safe default setting is "8", which enables asynchronous communication. |
Manager | This is the standard element that Tomcat uses for session management. When nested inside the Cluster element, it is used to tell Tomcat which cluster-aware session manager should be used for session replication. |
Channel | This element communicates with a component of Tomcat's clustering solution called Tribes. This component handles all communication between the clustered nodes. |
Membership | This Tribes-related element defines the address all nodes will use to keep track of one another. The settings we have used here are the Tribes defaults. |
Sender | This Tribes-related element, in conduction with the Transport element nested inside of it, is used to choose from and configure a number of different implementations of cluster communication. Here, we have used the NIO transport, which generally provides the best performance. |
Receiver | This Tribes-related element configures a single Receiver component, which receives messages from other nodes' Sender components. The attributes of the element allow you to specify addresses, buffer sizes, thread limits, and more. The settings we have used here allow the nodes to automatically discover one another via an address that Tribes will generate automatically. |
Interceptor | Interceptor elements are used to make modifications to messages sent between nodes. For example, one of the Interceptor elements we have configured here detects delays that may be preventing a member from updating its table due to timeout, and provides an alternative TCP connection. |
Valve | Tomcat's standard Valve element can be nested within Cluster elements to provide filtering. The element includes a number of cluster-specific implementations. |
ClusterListener | This element listens to all messages sent through by cluster workers, and intercepts those that match their respective implementation's specifications. These elements operate in a very similar manner to Inteceptor elements, except that rather than modifying messages and passing them on to a Receiver, they are the intended recipient of the messages for which they are listening. |
The above given parameters are just a selective options that has been used & tested in-house. For detailed information on the parameters according to the configuration of your environment you can refer the following link:
http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
Thank You,
Shriraj Suresh Vitkar