Installing The WebSphere Plugin

Installing the WebSphere Plug-in with Apache
Configuring Apache HTTP Server V2.2 - background

This topic describes how to change configuration settings for Apache HTTP Server Version 2.2.
Install Apache 2.2 and the latest version of the Web server plug-ins for WebSphere Application
Server 7.0 using the UpdateInstaller.
Apache HTTP Server v2.2 is different from IBM HTTP Server (powered by Apache). When you
install the Web server plug-ins for WebSphere Application Server on a non-iSeries system, the
Plug-ins installation wizard configures the Web server.
This topic describes how to configure the Apache HTTP Server Version 2.2 Web server. Other
procedures in Editing Web server configuration files describe configuring other supported Web
servers.
Note:
If you are using an Apache HTTP Server that supports 64-bit addressing, you must use the 64-bit
CD provided with the WebSphere Application Server product to install the Apache Web server
plug-in binaries. If you use the 32-bit CD, you will receive an error message indicating that the
plug-in binaries did not load.
If you are using an Apache HTTP Server that supports 32-bit addressing, you must use the 32-bit
CD provided with the WebSphere Application Server product to install the Apache Web server
plug-in binaries. If you use the 64-bit CD, you will receive an error message indicating that the
plug-in binaries did not load.
A sample error message follows:
httpd: Syntax error on line XXX of /home/apache/conf/httpd.conf: Cannot load
/home/apache/Plugins/mod_was_ap22_http.sl into server: Invalid argument
The plug-in was tested with the threaded worker multi-processing module (MPM) on all
platforms except Windows. The plug-in was tested with the default threaded MPM on Windows.
The plug-in works with the Apache 2.2 prefork MPM but works best with the worker MPM. The
plug-in maintains connection pools to backend WebSphere Application Servers and uses in-
memory caching. These plug-in functions perform most efficiently when Apache is configured to
use a single child process with the ThreadsPerChild value equal to the MaxClients value. The
plug-in can be used with the prefork MPM or the worker MPM that is configured with multiple
child processes, but at reduced efficiency.
Compatibility Statement The plug-in works with versions of the Apache HTTP Server that claim
full binary compatibility with Apache 2.0.47 and later, which are built with compilers and
compiler options that are compatible with those used to build the plug-in.
Perform the step that configures Apache 2.2 for your operating system.
Examples and messages are shown on more than one line for clarity. Place each directive in a
Web server configuration file on one line.
Local file path means a file path to the plugin-cfg.xml file on an Application Server that is on the
same machine as the Web server. Remote file path means the file path to the plugin-cfg.xml file
when the Application Server is on a remote machine. The Plug-ins installation wizard installs a
dummy plugin-cfg.xml file during installation, but this file requires periodic propagation from
the real file on the Application Server machine.
The node_name in the following Application Server local file paths is web_server_name_node
for a stand-alone Application Server or managed_node_name for a managed node.
The name of the Web server definition in the following steps is webserver1.
[AIX] Configure entries in the httpd.conf file.
Use the following examples of the LoadModule and the WebSpherePluginConfig directives as
models for configuring your file:
LoadModule
was_ap22_module /usr/IBM/WebSphere/Plugins/bin/mod_was_ap22_http.so
Local distributed example:
WebSpherePluginConfig
profile_root/config/cells/
dmgrcell/nodes/managednode/servers/webserver1/plugin-cfg.xml
[Linux] [Solaris] Configure entries in the httpd.conf file.
LoadModule
was_ap22_module /opt/IBM/WebSphere/Plugins/bin/mod_was_ap22_http.so
[Solaris] On the Solaris SPARC 64-bit platform, the Plug-ins installation wizard installs both 32-
bit and 64-bit versions of the plug-in for Apache 2.2, however it configures the Web server to
use the 32-bit plug-in only. If the Web server is 64-bit, you need to configure the LoadModule
directive in the httpd.conf file to use the 64-bit plug-in as follows:
LoadModule
was_ap22_module /usr/IBM/WebSphere/Plugins/bin/64bits/mod_was_ap22_http.so
[HP-UX] Configure entries in the httpd.conf file.
LoadModule
was_ap22_module /opt/IBM/WebSphere/Plugins/bin/mod_was_ap22_http.sl
[Windows] Configure entries in the httpd.conf file.
LoadModule was_ap22_module
drive:\IBM\WebSphere\Plugins\bin\mod_was_ap22_http.dll
profile_root\config\cells\
dmgrcell\nodes\managednode\servers\webserver1\plugin-cfg.xml
The Apache 2.2 Web server is reconfigured.
The Plug-ins installation wizard installs the GSKIT SSL encryption library at the required level
if it is not installed. If you manually copy the plug-in to a new machine, you might not have the
required GSKIT libraries for encrypting back-end connections.
After configuring a Web server, you can install applications on it. See the Applications section of
the information center for more information.

Steps
1. cd lin_x64_suppl/plugin
2. ./install
3. Skip docs step, Accept License, click Next
4. Select Apache Web Server V2.2, then click Next

5. If Apache and Was plug are installed on the same machine as the DM, and cluster nodes then
choose local. For multiple Apache instances ie to be used with a load balancer then you would do
this for [n] Apache nodes.

/opt/IBM/WebSphere/Plugins
/var/apps/was7nd_apache/plugins

/opt/IBM/WebSphere/AppServer
/var/apps/was7nd

Select node01 profile.
Note: On a vertical cluster ie all nodes are on same physical machine and we have only one
apache server on same machine then we only need actual set of plug-in binaries for apache. If
Apache is on 2 machines then we install it twice. We also need to manually create web server
definitions for all nodes in the cluster.

/opt/IBM/HTTPServer/conf/httpd.conf
/etc/httpd/conf/httpd.conf

/var/apps/was7nd_apache/plugins/config/webserver01/plugin-cfg.xml

Restart the deployment manager as the wizard has created a web server definition (web server01)
and needs to be picked up. Note: we could have done this web server definition manually in
WAS admin console..
Best to restart Apache to check it is ok.
LoadModule was_ap22_module /var/apps/was7nd_apache/plugins/bin/64bits/mod_was_ap22_http.so
WebSpherePluginConfig /var/apps/was7nd_apache/plugins/config/webserver01/plugin-cfg.xml
Are added to httpd.conf file. You can see that the actual plugin binaries are located
/var/apps/was7nd_apache/plugins and could be anywhere, maybe even located near apache install if you want.
Lets log into the admin console to see the webserver01 definition.

Save, before we create another one , lets test it.

Wizard breaks, need to update httpd.conf to correct location for mod_was_ap22_http.so
#LoadModule was_ap22_module /var/apps/was7nd_apache/plugins/bin/64bits/mod_was_ap22_http.so
LoadModule was_ap22_module /var/apps/was7nd_apache/bin/64bits/mod_was_ap22_http.so

Process definitions
Use command:
which apachectl
To find where apache is installed
You can use WAS variables like $(APCHE_INSTALL_ROOT}/bin/apachectl, but I am using
full path as admins might not want to add WAS variables.
Process definition
/usr/sbin/httpd
Start command
/usr/sbin/apachectl
Start command arguments
-k start
-f
Stop command
/usr/sbin/apachectl
/usr/sbin/apachectl
-k stop
-f
Working directory
/usr/sbin/

Save changes and you should see that Apache process can be seen by web server definition. You
cannot stop and start due to bugs in WAS.

Enable automated Web server configuration processing

The service automatically generates the plug-in configuration file whenever the Web
server environment changes, with a few exceptions. For example, the plug-in
configuration file is regenerated whenever one of the following activities occurs:
A new application is deployed on an associated application server
The Web server definition is saved
An application is removed from an associated application server
A new virtual host is defined
In WebSphere Application Server, Network Deployment configurations, the plug-in
configuration file does not regenerate when:
A cluster member is added to a cluster.
TCP channel settings are updated for an application server.
By default, this option is selected. Clear the field to disable automated Web server
configuration processing.

Auto updating

You can change the timing, but best to leave as default.. When scripting we can call commands
to do this.

Testing
Install default application to get snoop servlet

Next past application setting screen and map modules to servers. The provides details for the
plugi-cfg.xl file which us used to tell Apache of the clusters and server etc.
Make sure all web modules are bound to both the cluster and the web server.

Save installation. Note: ,you can also go back in to application settings and re-map modules to
servers.
Ensure that the cluster is started.

Generate plugin

Result, the plugin-cfg.xml is updated with the URL paths for mapped applications and contain
cluster state.

Then click Propagate
Result, the plugin-cfg.xml is copied to the location that apache is looking for this file as specified
in httpd.conf

Restart Apache every time the Plugin is propagated
cd /var/apps/was7nd_apache/plugins/webserver01 to see the plugin-cfg.xml has been updated

<?xml version="1.0" encoding="ISO-8859-1"?>
<Config ASDisableNagle="false" AcceptAllContent="false"
AppServerPortPreference="HostHeader" ChunkedResponse="false" FIPSEnable="false"
FailoverToNext="false" HTTPMaxHeaders="300" IISDisableNagle="false"
IISPluginPriority="High" IgnoreDNSFailures="false" RefreshInterval="60"
ResponseChunkSize="64" SSLConsolidate="false" TrustedProxyEnable="false"
VHostMatchingCompat="false">
<Log LogLevel="Error"
Name="/var/apps/was7nd_apache/plugins/logs/webserver01/http_plugin.log"/>
<Property Name="ESIEnable" Value="true"/>
<Property Name="ESIMaxCacheSize" Value="1024"/>
<Property Name="ESIInvalidationMonitor" Value="false"/>
<Property Name="ESIEnableToPassCookies" Value="false"/>
<Property Name="PluginInstallRoot" Value="/var/apps/was7nd_apache/plugins/"/>
<VirtualHostGroup Name="default_host">
<VirtualHost Name="*:9080"/>
</VirtualHostGroup>
<ServerCluster CloneSeparatorChange="false" GetDWLMTable="false"
IgnoreAffinityRequests="true" LoadBalance="Round Robin" Name="Cluster01"
PostBufferSize="64" PostSizeLimit="-1" RemoveSpecialHeaders="true"
RetryInterval="60">
<Server CloneID="1631jggec" ConnectTimeout="5" ExtendedHandshake="false"
LoadBalanceWeight="2" MaxConnections="-1" Name="node01_server02_clone1"
ServerIOTimeout="60" WaitForContinue="false">
<Transport Hostname="localhost" Port="9082" Protocol="http"/>
<Transport Hostname="localhost" Port="9445" Protocol="https">
<Property Name="keyring"
Value="/var/apps/was7nd_apache/plugins/config/webserver01/plugin-key.kdb"/>
<Property Name="stashfile"
Value="/var/apps/was7nd_apache/plugins/config/webserver01/plugin-key.sth"/>
</Transport>
</Server>
<Server CloneID="1631jgho8" ConnectTimeout="5" ExtendedHandshake="false"
LoadBalanceWeight="2" MaxConnections="-1" Name="node02_server02_clone2"
ServerIOTimeout="60" WaitForContinue="false">
<Transport Hostname="localhost" Port="9083" Protocol="http"/>
<Transport Hostname="localhost" Port="9446" Protocol="https">
<Property Name="keyring"
Value="/var/apps/was7nd_apache/plugins/config/webserver01/plugin-key.kdb"/>
<Property Name="stashfile"
Value="/var/apps/was7nd_apache/plugins/config/webserver01/plugin-key.sth"/>
</Transport>
</Server>
<PrimaryServers>
<Server Name="node01_server02_clone1"/>
<Server Name="node02_server02_clone2"/>
</PrimaryServers>
</ServerCluster>
<UriGroup Name="default_host_Cluster01_URIs">
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid"
Name="/snoop/*"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/hello"/>
Name="/hitcount"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsp"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsv"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsw"/>
Name="/j_security_check"/>
Name="/ibm_security_logout"/>
Name="/servlet/*"/>
</UriGroup>
<Route ServerCluster="Cluster01" UriGroup="default_host_Cluster01_URIs"
VirtualHostGroup="default_host"/>
<RequestMetrics armEnabled="false" loggingEnabled="false" rmEnabled="false"
traceLevel="HOPS">
<filters enable="false" type="URI">
<filterValues enable="false" value="/snoop"/>
<filterValues enable="false" value="/hitcount"/>
</filters>
<filters enable="false" type="SOURCE_IP">
<filterValues enable="false" value="255.255.255.255"/>
<filterValues enable="false" value="254.254.254.254"/>
</filters>
<filters enable="false" type="JMS">
<filterValues enable="false" value="destination=aaa"/>
</filters>
<filters enable="false" type="WEB_SERVICES">
<filterValues enable="false" value="wsdlPort=aaa:op=bbb:nameSpace=ccc"/>
</filters>
</RequestMetrics>
</Config>
http://192.168.0.71:9082/snoop -> node01
http://192.168.0.71:9083/snoop - >node01
http://192.168.0.71/snoop
First refresh for node see port below is 9082 which is node 01 cluster clone 01 (server 01)

Second refresh on Apache produces port 9083 which is Node 02, cluster clone 02 (server 02)

Session Affinity (Sicky sessions)
IgnoreAffinityRequests
Specifies whether the plug-in ignores the number of affinity requests made to a server
when selecting servers based on the Round Robin algorithm. Specify zero or one
attribute for each ServerCluster. The value is true or false. If the value is set to
false, the number of affinity requests made is also taken into account in the server
selection process.
The default value is true, which means the number of affinity requests made are not
used in the Round Robin algorithm.

Setting IgnoreAffinityRequests
By default, when using Apache and Plugin, the JSESSIONID that you get remains for that
session until application clears that session cookie ie logout or the browser gets closed or the
server fails over, however The plugin by default has IgnoreAffinityRequests="true"
and we need to make this false.

After adding properties for the plug-in, Re-generate the plug-in-cfg.xml and propagate to
Apache.

Session persistence
Overview
Some basic background on how WAS deals with sticky sessions.

WAS plugin
The WebSphere Plugin for Apache can detect fail over
Detects failure in the WAS web container, then marks the web container as unavailable ie the
URI set is changed.
The request is then routed to the next available web container Of a clone in a cluster. Thus all
of this requires WAS ND and clusters. As new cluster members (Clones) are added to the cluster,
the plugin-cfg.xml files needs to be re-generated and propagated to Apache. These step are
outlines above.
In-flight sessions can be persisted to a data base and can be replicated to other cloves via
memory-to-memory replication.
You set up persistence to save sessions in case of failure during access and replication ensures
that once a session is failed over the sessions are available from the next clones web container

High Availability of Sessions

Session objects are volatile, and so are lost if the server fails or is restarted.

There are two methods to provide session high availability i.e. persisted in the event
of server failure.
Database
Session are stored in a session database
Uses JDBC
Greater overheard, but guaranteed.
Memory-t0-memory replication
Session are replicated to each server via the internal messaging provider
Less overhead, not guaranteed

Setting up session persistence

Must be applied to each server/clone. So they participate in session replication

Creating a DB for session persistence
How create a DB for session persistence and setup a JDBC data source as required.

Create a Schema / Creating a table for session persistence
To be verified
You can use a database table to collect and store session data. If you are using a database table
for session persistence, you must create and define a database table that is associated with the
application server.
Whenever the session manager is set for database persistence, the session manager creates a table
for its use. If you want to expand the column size limits to make it more appropriate for your
Web site, you can create the table externally. If the external table is specified as the target table
in the session manager database persistence configuration, then during the session manager start
up, the external table is used. In most cases it is better to let the session manager create the table
during startup.
To create a table for collecting session data, do the following:

For DB/2
CREATE TABLE <SchemaName>.sessions (
ID VARCHAR(128) NOT NULL ,
PROPID VARCHAR(128) NOT NULL ,
APPNAME VARCHAR(128) NOT NULL,
LISTENERCNT SMALLINT ,
LASTACCESS BIGINT,
CREATIONTIME BIGINT,
MAXINACTIVETIME INTEGER ,
USERNAME VARCHAR(256) ,
SMALL VARCHAR(3122) FOR BIT DATA ,
MEDIUM LONG VARCHAR FOR BIT DATA ,
LARGE BLOB(2M)
)

For Oracle:
CREATE TABLE SESSIONS (
LASTACCESS INTEGER,
CREATIONTIME INTEGER,
SMALL RAW(2000),
MEDIUM LONG RAW ,
LARGE RAW(1)
)
If the Web container custom property UseOracleBLOB is set to true then:
CREATE TABLE SESSIONS (
LASTACCESS INTEGER,
CREATIONTIME INTEGER,
SMALL RAW(2000),
MEDIUM BLOB,
LARGE RAW(1)
)
Note:
At run time, the session manager accesses the target table using the identity of the J2EE server in
which the owning Web application is deployed. Any Web container that is configured to use
persistent sessions must have both read and update access to the subject database table.
HTTP session processing uses the index defined using the CREATE INDEX statement to avoid
database deadlocks. In some situations, such as when a relatively small table size is defined for
the database, DB2 may decide not to use this index. When the index is not used, database
deadlocks can occur. If database deadlocks occur, see the DB2 Administration Guide for the
version of DB2 you are using for recommendations on how to calculate the space required for an
index and adjust the size of the tables that you are using accordingly.
It might be necessary to tune DB2 to make efficient use of the sessions database table and to
avoid deadlocks when accessing it. Your DB2 administrator should refer to the DB2
Administration Guide for specific information about tuning the version of DB2 that you are
using.
[Updated in February 2011] During run time, the session manager may create an entry in the
database for each web module of the application. This row of data is used internally for session
management purposes, such as in session invalidation. Do not be concerned with this entry. It
can be overlooked. [Updated in February 2011]

Create a Data source / J2C alias
Create the appropriate setting in the servers environment settings
Configuring a table for session persistence
To configure a table for collecting session data, you must add the name of the table to the Web
container configuration properties.
If you are using database for session persistence, you must create and define a database table to
the application server to collect session data.
To configure a table for collecting session data, use the administrative console to add the name
of this table to the Web container's configuration properties:

Procedure
1. Open the administrative console.
2. Click Servers > Server Types > WebSphere application servers.
3. Select a server from the list of application servers.
4. Under Additional Properties, click Web Container.
5. Under Additional Properties, click Custom properties.
6. Click SessionTableName to configure the DB2 table, or click New to create a new property.
7. Specify 'SessionTableName' in the Name field if you are creating a new property. In the Value
field, enter the name of the session table. The value must have the form,
schema_name.table_name. For example, if the schema name is DB2ADMIN and the table name
is SESSIONS, enter DB2ADMIN.SESSIONS for Value. Optionally, you can update the
description of this table in the Description field. For example, you might enter "Table name for
HTTP session data."
8. Click Apply > Save.
9. When the product is restarted, the session management facility creates the new SESSIONS
table in the specified tablespace.
.to be verified

How to configure session replication
You can create a replication domain for memory only.

How to tune session replication
Tips and settings on how to tune Memory-to-Memory session replication.
Single replica
o For every session there will be a copy stored on a different server/clone. This copy is then
used to failover when a server become unavailable.
Domain
o Sessions are copied to every member in the replication domain and every member has to store
all the copies from all other members, so performance can be an issue
Specify
o As the setting says, you can specify the number of replicas to use in the cluster. Replicas , this
way you can tune how may replicas of the session information exist.

Plug-in Administration Service
Plug-in Administration Services is set by default, but good to check.

Installing The WebSphere Plugin

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Installing The WebSphere Plugin

Uploaded by

Copyright:

Available Formats

Installing the WebSphere Plug-in with Apache

Configuring Apache HTTP Server V2.2 - background

You might also like