About this task
You can configure simple load balancing capability with
WebSphere Application Server by combining the
plug-in configuration files of multiple stand-alone application server
profiles into a single configuration file.
The number of configuration
files that you can combine are bound by the limits that exist in the WebSphere Application Server license agreement. You
can use the following different configurations of the application
server to combine the plug-in configuration files of multiple application
server profiles into a single output file:
- Using multiple stand-alone base application server profiles
- Using multiple stand-alone base application server profiles with
an administrative agent. For more information, see the documentation
on configuring simple load balancing across multiple stand-alone base
application server profiles with an administrative agent.
- Using multiple stand-alone base application server profiles with
an administrative agent using the job manager. The job manager function
is a part of WebSphere Application Server, Network Deployment.
However, you can use the job manager function with stand-alone, base
application server profiles. For more information, see the documentation
on configuring simple load balancing across multiple stand-alone,
base application server profiles with an administrative agent using
the job manager.
Complete the following steps to configure simple load balancing
across multiple stand-alone, base application server profiles:
- Install WebSphere Application Server and
create application server profiles. For more information,
see the documentation on WebSphere Application Server installation and
application server profiles.
- Install the enterprise application or web module. For
more information, see the documentation on the methods for installing
applications or modules.
- Determine if you require session affinity.
Session
affinity directs requests from a given client to a specific application
server. The application state maintained in the HTTP session is accessed
in the HTTP session cache, which is local to the application server.
Session affinity provides higher performance than database persistence
of the session object, alone. Without session affinity, session requests
must be obtained from the database if they are sent to a server that
does not have the session object in the local cache.
- Optional: Configure a unique HTTP session clone
ID for each application server. You must complete
this step if you require session affinity.
You can configure a unique
HTTP session clone ID using wsadmin scripting or the administrative
console. To use wsadmin commands for the Jython or Jacl programming
language, see the documentation on configuring a unique HTTP session
clone ID for each application server using scripting. To configure
a unique HTTP session clone ID using the administrative console, complete
the following steps:
- Expand and click WebSphere
application servers > server_name.
- Under Container Settings, expand Web
Container Settings, and click Web container.
- Under Additional Properties,
click .
- In the Name field, enter HttpSessionCloneId.
- In the Value field, enter a unique
value for the server. The unique value must be 8 - 9 alphanumeric
characters; for example, test1234
- Click Apply or OK.
- Click Save to save the configuration
changes to the master configuration.
- Optional: Configure session persistence, if
needed. If you require session failover capability, you
must configure session persistence. Persistence of the session object
to a database is the only option for session failover with WebSphere Application Server. To configure
session persistence using the administrative console, see the documentation
on configuring database session persistence. To configure database
session persistence using wsadmin commands for the Jython or Jacl
programming language, see the documentation on configuring database
session persistence using scripting.
- Restart the server.
- Generate the plugin-cfg.xml file for
each application server using the GenPluginCfg script, the administrative
console, or wsadmin scripting.
See the topic GenPluginCfg
command for a description of how to use the GenPluginCfg script
to generate the plugin-cfg.xml file.
See
the topic Implementing a web server plug-in for a description
of how to use the administrative console to generate the plugin-cfg.xml file.
See
the topic Regenerating the node plug-in configuration using
scripting for a description of how to use wsadmin scripting
to generate the plugin-cfg.xml file.
- Merge the plugin-cfg.xml files from
multiple application server nodes.
You can either manually
merge the plugin-cfg.xml files or use the pluginCfgMerge
tool to automatically merge the plugin-cfg.xml file
from multiple application server profiles into a single output file.
The pluginCfgMerge.bat and pluginCfgMerge.sh files
are located in the install_root/bin directory.
To
use the pluginCfgMerge tool, complete the following steps:
- Rename the plugin-cfg.xml files to a unique
name across your application server profiles.
- Copy the plugin-cfg.xml file for all stand-alone
application server profiles into a common directory.
- Use the pluginCfgMerge tool to combine the plugin-cfg.xml files
from each of the application server profiles into a single output
file. For example:
install_root/bin/pluginCfgMerge.sh plugin_configuration_file1 plugin_configuration_file2 resulting_plugin_configuration_file
The resulting_plugin_configuration_file variable
value is normally plugin-cfg.xml
For more information about manually merging the plugin-cfg.xml files,
see the technote on merging plugin-cfg.xml files
from multiple application server profiles.
- Copy the merged plugin-cfg.xml file
to the plugin_installation_root/config/web_server_name/ directory
on the web server host.