Configuring simple load balancing across multiple application server profiles
Simple load balancing distributes HTTP requests across multiple IBM® WebSphere® Application Server instances. You can configure simple load balancing to provide failover of an application state that is maintained in an HTTP session.
Before you begin
About this task
- 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 that uses 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 that uses the job manager.
- 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 whether you require session affinity.
Session affinity directs requests from a client to a specific application server. The application that is 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. If you require session affinity, you must complete this step.
You can configure a unique HTTP session clone ID by usingwsadmin scripting or the administrative console. To use wsadmin commands for the Jython or Jacl programming language, see the documentation on using scripting to configure a unique HTTP session clone ID for each application server. To configure a unique HTTP session clone ID by using the administrative console, complete the following steps:
- Expand WebSphere application servers > server_name. and click
- 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.
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 by using the administrative console, see the documentation on configuring database session persistence. To configure database session persistence by using wsadmin commands for the Jython or Jacl programming language, see the documentation on using scripting to configure database session persistence.
- Restart the server.
Generate the plugin-cfg.xml file for each application server by using the
GenPluginCfg script, the administrative console, or wsadmin
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 files from multiple application server profiles into a single output file. The pluginCfgMerge tool scripts pluginCfgMerge.bat and pluginCfgMerge.sh are located in the install_root/bin directory.Before you begin the merge, review any differences between global variables that are defined in the two plugin.cfg.xmlfiles to be merged, for example the global variables refreshInterval or esiEnable. Determine which settings best suit the environment to be governed by the merged plugin.cfg.xml files. The pluginCfgMergetool uses the first file in the command string as the source of global properties for the new xml file.Note: You need to re-merge the files when you make any changes to the WebSphere Application Server environment that require a new plug-in generation.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.
- Override any existing differences in global properties by modifying one of your xml files to those values you require in your new xml file. This modified file is used by the pluginCfgMerge tool as the source of global properties for the new xml file.
- Use the pluginCfgMerge tool to combine the
plugin-cfg.xml files from each of the application server profiles into a single
output file. Use the xml file that is modified in the previous step as the
first file in the pluginCfgMerge command string. Define the name of the
outputted file by defining the resulting_plugin_configuration_file variable value
in the command string. The resulting_plugin_configuration_file variable value
must match the name that is defined within the respective web server definition of the admin
console, which by default is plugin-cfg.xml. Your command resembles one of the
install_root/bin/pluginCfgMerge.sh plugin_configuration_file1 plugin_configuration_file2 resulting_plugin_configuration_file
install_root\bin\pluginCfgMerge.bat plugin_configuration_file1 plugin_configuration_file2 resulting_plugin_configuration_file
- Copy the merged plugin-cfg.xml file to the plugin_installation_root/config/web_server_name/ directory on the web server host.
Ensure that the merged output files have the correct operating system file access permissions
for the merged output file.
These file access permissions allow the HTTP server plug-in process to read the file.