Setting up HTTP Server in a WebSphere Application Server Liberty profile farm

You can set up an IBM® HTTP Server in a MobileFirst cluster environment with the Liberty profile.

Before you begin

Install a server farm for Liberty. See Installing a server farm. If a server farm is not configured, the MobileFirst Server installation does not work properly. As a consequence, the changes that are made by using the MobileFirst Operations Console or the Administration Service are not replicated to all the servers of the farm. The result is inconsistent behavior for client devices that connect to the MobileFirst Server.

About this task

You can set up IBM MobileFirst™ Platform Foundation in the topology similar to the one shown in Figure 1.

Figure 1. MobileFirst cluster topology with the Liberty profile

If you install IBM HTTP Server, you set up some JNDI properties to configure the administration components. For more information, see Using a reverse proxy with server farm and WebSphere Application Server Network Deployment topologies and Defining the endpoint of the MobileFirst Administration services.

This procedure uses the following hardware and software elements.

Table 1. Hardware
Host name Operating system Description
Host1 RHEL 6.2 IBM HTTP server with Web Server plug-in, acting as load balancer.
Host2 RHEL 6.2 Liberty farm server 1
Host3 RHEL 6.2 Liberty farm server 2
Host4 RHEL 6.2 DB2® server
Table 2. Software
Name Description
IBM Installation Manager Install IBM HTTP Server , IBM Liberty profile, and IBM MobileFirst Platform Foundation.
IBM HTTP Server You need to get access to the installation repository before you start the procedure. IBM HTTP Server is also included in the WebSphere® Application Server installation repository.
Web Server Plug-ins You need to get access to the installation repository before you start the procedure. IBM HTTP Server Plug-in is also included in the WebSphere Application Server installation repository.
IBM Liberty profile You need to get access to the installation repository before you start the procedure. IBM Liberty profile is also included in the WebSphere Application Server installation repository.
IBM MobileFirst Platform Foundation You need to get access to the installation repository before you start the procedure.
IBM DB2 Your DB2 server must be available before you start the IBM MobileFirst Platform Foundation installation.

Procedure

  1. Install IBM HTTP Server and Web Server Plug-ins.
    1. On the Host1 server, log on as the root user ID and run IBM Installation Manager to install the IBM HTTP server and Web Server Plug-ins. This documentation assumes that the applications are installed in the following places:
      IBM HTTP Server home
      /opt/HTTPServer
      Web Server Plug-ins home
      /opt/Plugins
  2. Start the Liberty profile servers to test whether you can access the MobileFirst Operations Console on Host2 and Host3 by browsing to the associated URLs:
    • http://Host2:9080/worklight/console
    • http://Host3:9080/worklight/console
    Check that both MobileFirst Operations Console are running.
  3. Run the following command on Host1 to start the IBM HTTP server.
    /opt/HTTPServer/bin/apachectl start
    If you encounter problems when IBM HTTP server is starting, see Troubleshooting IBM HTTP Server startup.
  4. Ensure that the IBM HTTP Server can be accessed at the following URL in a web browser:
    http://<hostname>:<port>
  5. For each Liberty server, generate a web server plug-in configuration file named plugin-cfg.xml.

    The web server plug-in is used to forward HTTP requests from the web server to the application server.

    1. Start the server that hosts your applications and ensure that the localConnector-1.0 feature and other required features are included in the server configuration. Use the pluginConfiguration element in the server configuration file to specify the webserverPort and webserverSecurePort attributes for requests that are forwarded from the web server. By default, the value of webserverPort is 80 and the value of webserverSecurePort is 443. Assign the value * to the host attribute to ensure that applications on the Liberty server can be accessed from a remote browser. Here is an example of a server.xml server configuration file:
      <server description="new server">
        <featureManager>
          <feature>localConnector-1.0</feature>
          <feature>jsp-2.2</feature>
        </featureManager>
        <httpEndpoint id="defaultHttpEndpoint" host="*" httpPort="9080">
          <tcpOptions soReuseAddr="true" />
        </httpEndpoint>
        <pluginConfiguration webserverPort="80" webserverSecurePort="443"/>
      </server>
    2. Use one of the following methods to generate the plugin-cfg.xml file for the Liberty server that is running your application.
      jConsole
      1. Using the same JDK as the server, run the jConsole Java™ utility from a command prompt. For example, run the following command:
        C:\java\bin\jconsole
      2. In the jConsole window, click Local Process, click the server process in the list of local processes, and then click Connect.
      3. In the Java Monitoring & Management Console, click the MBeans tab.
      4. Select and invoke the defaultPluginConfig generation MBean operation to generate the plugin-cfg.xml file.
        You can find the generated file in the \wlp\usr\servers\<server_name> directory. Here is an example:
        <?xml version="1.0" encoding="UTF-8"?>
        <Config ASDisableNagle="false"
          AcceptAllContent="false"
          AppServerPortPreference="HostHeader"
          ChunkedResponse="false"
          FIPSEnable="false"
          IISDisableNagle="false"
          IISPluginPriority="High"
          IgnoreDNSFailures="false"
          RefreshInterval="60"
          ResponseChunkSize="64"
          SSLConsolidate="false"
          SSLPKCSDriver="REPLACE"
          SSLPKCSPassword="REPLACE"
          TrustedProxyEnable="false"
          VHostMatchingCompat="false">
          <Log LogLevel="Error" Name="String\logs\String\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="String"/>
          <VirtualHostGroup Name="default_host">
            <VirtualHost Name="*:443"/>
            <VirtualHost Name="*:80"/>
            <VirtualHost Name="*:9080"/>
          </VirtualHostGroup>
          <ServerCluster CloneSeparatorChange="false"
            GetDWLMTable="false"
            IgnoreAffinityRequests="true"
            LoadBalance="Round Robin"
            Name="String_default_node_Cluster"
            PostBufferSize="64"
            PostSizeLimit="-1"
            RemoveSpecialHeaders="true"
            RetryInterval="60">
            <Server CloneID="s56"
              ConnectTimeout="0"
              ExtendedHandshake="false"
              MaxConnections="-1"
              Name="default_node_String0"
              ServerIOTimeout="900"
              WaitForContinue="false">
                <Transport Hostname="wasvm56" Port="9080" Protocol="http"/>
            </Server>
            <PrimaryServers>
              <Server Name="default_node_String0"/>
            </PrimaryServers>
          </ServerCluster>
          <UriGroup Name="default_host_String_default_node_Cluster_URIs">
            <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/tri-web/*"/>
          </UriGroup>
          <Route ServerCluster="String_default_node_Cluster"
            UriGroup="default_host_String_default_node_Cluster_URIs"
            VirtualHostGroup="default_host"/>
        </Config>
      Eclipse
      1. Make sure that your Liberty server is started.
      2. In Eclipse, in the servers panel, right-click the Liberty server, and then click Utilities > Generate Plugin Config.
    3. Copy the plugin-cfg.xml file to the machine that hosts the IBM HTTP Server web server, and then restart the web server to activate the settings in the file. Typically, you must enable the plug-in within the httpd.conf file of the web server by using the LoadModule phrase, and you must specify the location of the plugin-cfg.xml file using the WebSpherePluginConfig phrase.
      On Windows
      LoadModule was_ap22_module "path\to\mod_was_ap22_http.dll"
      WebSpherePluginConfig "path\to\plugin-cfg.xml"
      On other distributed systems
      LoadModule was_ap22_module "path\to\mod_was_ap22_http.so"
      WebSpherePluginConfig "path\to\plugin-cfg.xml"
  6. Use one of the following methods to merge the plugin-cfg.xml files for all the Liberty servers in the cluster.
  7. Verify that workloads are distributed to multiple Liberty servers via the IBM HTTP Server and Web Server Plug-ins.
    1. Ensure that session affinity is enabled.

      To do so, check that a CloneID attribute is included for each server in the plugin-cfg.xml file of the IBM HTTP Server and Web Server Plug-ins. Although you can generate CloneID values automatically, in production environments, you must specify particular strings in the Liberty Profile server.xml file. See Configuring session persistence for the Liberty profile.

      If you do not specify particular strings, the value of the CloneID might change under some circumstances and session affinity would stop working. Automatically generated CloneID attributes should not be used in a production environment. In the WebSphere Application Server Liberty profile, the CloneID attribute is generated when you start a server for the first time; it is regenerated if you start the server with the --clean option.

      In a production use case, manually assigning a clone ID ensures that the CloneID attribute is stable and that request affinity is correctly maintained. The CloneID attribute must be unique for each server and can be 8 to 9 alphanumeric characters in length.

      The following example shows CloneID attributes for three servers:
      <ServerCluster CloneSeparatorChange="false"
        GetDWLMTable="false"
        IgnoreAffinityRequests="true"
        LoadBalance="Round Robin"
        Name="String_default_node_Cluster1"
        PostBufferSize="64"
        PostSizeLimit="-1"
        RemoveSpecialHeaders="true"
        RetryInterval="60">
        <Server CloneID="s59"
          ConnectTimeout="0"
          ExtendedHandshake="false"
          MaxConnections="-1"
          Name="default_node_String1"
          ServerIOTimeout="900"
          WaitForContinue="false">
          <Transport Hostname="wasvm59.example.com" Port="9080" Protocol="http"/>
        </Server>
        <Server CloneID="s56"
          ConnectTimeout="0"
          ExtendedHandshake="false"
          MaxConnections="-1"
          Name="default_node_String2"
          ServerIOTimeout="900"
          WaitForContinue="false">
          <Transport Hostname="wasvm56.example.com" Port="9080" Protocol="http"/>
        </Server>
        <Server CloneID="vm28"
          ConnectTimeout="0"
          ExtendedHandshake="false"
          MaxConnections="-1"
          Name="default_node_String3"
          ServerIOTimeout="900"
          WaitForContinue="false">
          <Transport Hostname="wasvm28.example.com" Port="9080" Protocol="http"/>
        </Server>
        <PrimaryServers>
          <Server Name="default_node_String1"/>
          <Server Name="default_node_String2"/>
          <Server Name="default_node_String3"/>
        </PrimaryServers>
      </ServerCluster>
    2. Ensure that each Liberty server is started.
    3. Verify that the round-robin load balancing process is successfully routing application requests to each of the back-end Liberty servers.