+

Search Tips   |   Advanced Search

Configure simple load balancing across multiple application server profiles

Simple load balancing distributes HTTP requests across multiple IBM WebSphere Application Server instances. We can configure simple load balancing to provide failover of an application state that is maintained in an HTTP session.

This offering applies to stand-alone application server profiles for IBM WAS. This offering does not include a centralized management capability such as the deployment manager in WAS ND.

We can configure simple load balancing capability with WAS 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 we can combine are bound by the limits that exist in the WAS license agreement. 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:

Configure simple load balancing across multiple stand-alone, base application server profiles:


Tasks

  1. Install WAS and create application server profiles. For more information, see the documentation on WAS installation and application server profiles.

  2. Install the enterprise application or web module. See documentation on the methods for installing applications or modules.

  3. 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.

  4. Optional: Configure a unique HTTP session clone ID for each application server. We must complete this step if you require session affinity.

    We can configure a unique HTTP session clone ID using wsadmin.sh 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:

    1. Expand Servers > Server Types and click WebSphere application servers > server.

    2. Under Container Settings, expand Web Container Settings, and click Web container.

    3. Under Additional Properties, click Custom properties > New.

    4. In the Name field, enter HttpSessionCloneId.

    5. In the Value field, enter a unique value for the server. The unique value must be 8 - 9 alphanumeric characters; for example, test1234

    6. Click Apply or OK.

    7. Click Save to save the configuration changes to the master configuration.

  5. Optional: Configure session persistence, if needed. If we require session failover capability, configure session persistence. Persistence of the session object to a database is the only option for session failover with WAS. 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.

  6. Restart the server.
  7. 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.

  8. Merge the plugin-cfg.xml files from multiple application server nodes.

    We 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 install_root/bin.

    To use the pluginCfgMerge tool:

    1. Rename the plugin-cfg.xml files to a unique name across the application server profiles.

    2. Copy the plugin-cfg.xml file for all stand-alone application server profiles into a common directory.

    3. 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:(AIX) (HPUX) (iSeries) (Linux) (Solaris) (ZOS) 
      install_root/bin/pluginCfgMerge.sh plugin_configuration_file1 plugin_configuration_file2 resulting_plugin_configuration_file
      (Windows) 
      install_root\bin\pluginCfgMerge.bat 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.

  9. Copy the merged plugin-cfg.xml file to the plugin_installation_root/config/web_server/ directory on the web server host.
  10. (UNIX) Ensure that we have defined the correct operating system file access permissions for the merged plugin-cfg.xml file. These file access permissions allow the HTTP server plug-in process to read the file.

When we complete this process, we have one plug-in configuration file for multiple stand-alone application server profiles.


Related:

  • Ways to install enterprise applications or modules
  • Create application server profiles
  • Configure for database session persistence
  • Create or update a global web server plug-in configuration file
  • Configure a unique HTTP session clone ID for each application server using scripting
  • Configure database session persistence using scripting
  • Implement a web server plug-in
  • Regenerating the node plug-in configuration using scripting
  • GenPluginCfg command
  • Merging plugin-cfg.xml files from multiple nodes