Configure simple load balancing across multiple application server profiles with an administrative agent using a job manager

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.

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:

• Use multiple stand-alone base application server profiles. See documentation on configuring simple load balancing across multiple application server profiles.

• Use multiple stand-alone base application server profiles with an administrative agent. See documentation on configuring simple load balancing across multiple application server profiles with an administrative agent

• Use multiple stand-alone base application server profiles with an administrative agent using the job manager. The job manager function is a part of WAS ND. However, we can use the job manager function with stand-alone, base application server profiles. Use this topic to complete this configuration.

Complete the following steps to register stand-alone application server profiles with an administrative agent using a job manager and combine the plug-in configuration files from these profiles into a single output file.

Tasks

1. Install WAS and create application server profiles. See documentation on WAS installation and application server profiles.

2. Configure the administrative agent and register each application server profile with the administrative agent. Complete the following steps:

   1. Set up the administrative agent, which includes creating the administrative agent profile.
   2. Register the stand-alone application server with the administrative agent.
   3. Restart the administrative agent.

   After completing these steps, we can complete all the administrative operations through the administrative agent. When we log in to the administrative console for the administrative agent, we can select which application servers to manage. See documentation on administering stand-alone nodes using the administrative agent.

3. Install WAS ND for the licensed WAS ND instances that will perform centralized management for the stand-alone application server instances. See installation documentation for the WAS ND product.

   We must access the Information Center for WAS ND to read its installation documentation.

4. Create the job manager profile, configure the job manager, and register stand-alone application servers with the job manager. See documentation on setting up a job manager environment. We can complete administrative options centrally using the job manager. For more information about the job manager, see the conceptual information about the job manager.

5. Install the enterprise application or web module. Using one of the following methods to install the enterprise application or web module:

   • Install the enterprise application or web module on each application server. See documentation on installing enterprise applications or modules.

   • Install the enterprise application or web module using the job manager. For more information, see the documentation on installing applications using the job manager.

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

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

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

8. Optional: Configure session persistence. 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.

9. Restart the server.
10. Generate plugin-cfg.xml for each stand-alone application server using the GenPluginCfg script, the administrative console, or wsadmin scripting.

    To use the GenPluginCfg script, enter on the command line: profile_root/config/cells/GenPluginCfg.sh|bat

    To use the administrative console, see the documentation on creating or updating a global web server plug-in configuration file.

    The following variables apply to the Jython and Jacl commands:

    • cell is the name of our cell.
    • web_server_node is the name of the node for our web server.
    • web_server is the name of our web server.

    Jython

    On the command line, enter each of the following commands on a separate line:

    generator = AdminControl.completeObjectName('type=PluginCfgGenerator,*')
    AdminControl.invoke(generator, 'generate', " profile_root/config cell web_server_node web_server true true")
    

    Jacl

    On the command line, enter each of the following commands on a separate line:

    set generator [$AdminControl completeObjectName type=PluginCfgGenerator,*]
    $AdminControl invoke $generator generate " profile_root/config cell web_server_node web_server true true"
    

11. Merge plugin-cfg.xmls from multiple application server nodes.

    We can either manually merge plugin-cfg.xmls or use the tool to automatically merge plugin-cfg.xml from multiple application server profiles into a single output file. The .bat or .sh tool is available after we install this fix pack and is located in install_root/bin. To use the tool:

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

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

    3. Use the tool to combine plugin-cfg.xmls from each of the application server profiles into a single output file. For example:(AIX) (HPUX) (iSeries) (Linux) (Solaris) (ZOS)

       install_root/bin/.sh plugin_configuration_file1 plugin_configuration_file2 resulting_plugin_configuration_file
       

       (Windows)

       install_root\bin\.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 plugin-cfg.xmls, see the technote on merging plugin-cfg.xml files from multiple application server profiles.

12. Copy the merged plugin-cfg.xml file to the plugin_installation_root/config/web_server/ directory on the Web server host.
13. (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

Administrative agent

Job manager

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

Administer stand-alone nodes using the administrative agent

Set up a job manager environment

Install applications using the job manager

Merging plugin-cfg.xml files from multiple nodes