Setting up a basic high availability configuration

Setup and configure your primary and backup servers for a basic high availability environment.

Installing and configuring the IBM HTTP Server and Web server plug-ins

To install and configure the IBM HTTP Server and Web server plug-ins, follow these steps:
  1. Install the IBM HTTP Server. See http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/tins_webserver.html.
  2. Install the Web server plug-ins. See http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/tins_webplugins.html.
  3. Configure a Web server and an application server on separate machines (remote). See http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/tins_webplugins_remotesa.html.
  4. To secure transmissions between the Web server and the client, enable SSL on the IBM HTTP Server. See Guide to properly setting up SSL within the IBM HTTP Server

Installing and configuring a Jazz application on primary and backup servers

To install and configure two instances of jazz.war application on WebSphere Application Server, see Setting up a WebSphere® Application Server and Deploying jazz.war on WebSphere Application Server.
Remember: Install one server at a time. Each server references the same database in its teamserver.properties. Make sure that the first server is shut down and not attached to the repository before beginning second installation.

Configuring high availability for both primary and backup servers

The jazz.war application normally installs with a single application server as its target. With the introduction of the Web server, the jazz.war application must be modified to allow routing through the Web server.

To modify the application:
  1. In the WebSphere Console, click the jazz.war application link under Enterprise Applications.
  2. Select Manage Modules.
  3. Select the check box for the jazz.war application module.
  4. In the list of clusters and servers, choose both the Web server and application server, then click Apply.
  5. Click OK, then Save changes.
  6. Restart the jazz.war application.
Reconfigure the Jazz application on the primary application server to turn off security for the jazz.war application:
  1. Modify the web.xml from the WAR file that was installed into WebSphere Application Server.
    Tip: You might need to uncompress the WAR file into a temporary directory to get to the web.xml file.
  2. Change each occurrence of "CONFIDENTIAL" to "NONE".
  3. Make sure WebSphere Application Server is running, open a browser and go to: https://localhost:9043/ibm/console/logon.jsp
  4. Go to the Applications -> Enterprise Applications page.
  5. Select the jazz_war application and click Update.
  6. Select Replace or add a single file.
  7. In the "Specify the path beginning with the installed application archive file to the file to be replaced or added" field enter jazz.war\WEB-INF\web.xml.
  8. Click Browse and select the web.xml file that you modified in step 1.
  9. Click Next and follow through until the application is saved.
  10. Go back to the Applications -> Enterprise Applications page and stop and start the jazz_war application.
Reconfigure both the primary and backup Jazz™Team Server to reference the same location for the full text index. To keep the index up to date and available to both the primary and back up server, update the com.ibm.team.fulltext.indexLocation in teamserver.properties on both the primary and backup servers to store the index on a shared drive. Modify the following property in the teamserver.properties file on the primary and backup servers:
  • The following property value is an example of what you can see on Windows:
    com.ibm.team.fulltext.indexLocation=I\:/sharedIndexFolder/workitemindex
  • The following property setting is an example of what you can see on Linux:
    com.ibm.team.fulltext.indexLocation=/net/LinuxHost/sharedIndex/workitemindex

Turning off asynchronous tasks on the backup server

To avoid any possible data contention between the two running JazzTeam Server, asynchronous (or background) tasks must be turned off on the backup server.
  1. Add the following line to the teamserver.properties file on the Backup server:
    com.ibm.team.repository.scheduler.migration.mode.enabled=true
  2. Restart the jazz.war application on the Backup server.

Editing the Web server plugin_cfg.xml file for idle standby

Each time a WebSphere Application Server is configured to route requests through a Web server to an application server, the Web server plugin.xml is updated with the connection information for that application server. At this point, you have partially configured the plugin-cfg.xml file. Replace and then edit the following section of the plugin-cfg.xml on the Web server to complete the configuration. This plugin-cfg.xml file resides in the plugin\config\webserver1 folder of the Web server (where webserver1 is the name that you assigned to the Web server in the previous section about Installing and configuring the IBM HTTP Server and Web Server plug-ins).
<ServerCluster CloneSeparatorChange="false" GetDWLMTable="false" IgnoreAffinityRequests="true" LoadBalance="Round Robin" Name="RTC_basicHA_Cluster" RetryInterval="60" PostBufferSize="64" PostSizeLimit="-1" RemoveSpecialHeaders="true">
<Server LoadBalanceWeight="1" ConnectTimeout="0" ExtendedHandshake="false" MaxConnections="-1" Name="PrimaryNode01_server1" ServerIOTimeout="0" WaitForContinue="false">
<Transport Hostname="primary.hostname.company.com" Port="9080" Protocol="http"/>
</Server>
<Server LoadBalanceWeight="0" ConnectTimeout="0" ExtendedHandshake="false" MaxConnections="-1" Name="BackupNode01_server1" ServerIOTimeout="0" WaitForContinue="false">
<Transport Hostname="backup.hostname.company.com" Port="9080" Protocol="http"/>
</Server>
</ServerCluster>
<UriGroup Name="default_host_RTC_basicHA_Cluster_URIs">
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/jazz/*"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/snoop/*"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/hello"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/hitcount"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsp"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsv"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsw"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/j_security_check"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/ibm_security_logout"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/servlet/*"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/ivt/*"/>
</UriGroup>
<Route ServerCluster="RTC_basicHA_Cluster" UriGroup="default_host_RTC_basicHA_Cluster_URIs" VirtualHostGroup="default_host"/>

Verifying the server setup for manual failover ability

To verify the manual failover ability of the WebSphere Application Server, edit the plugin-cfg.xml file on the Web server so that the PrimaryNode01 _server1 has a LoadBalanceWeight ="0" and the BackupNode01_server1 has a LoadBalanceWeight ="1". Save the plugin-cfg.xml file.
Important: Because "true" clustering and load balancing is not yet supported, at no time can both the primary and backup servers have non-zero for LoadBalanceWeight.
  1. With both primary and backup servers online, run the WebSphere sample Snoop servlet to get the name of the server that is handling the request.
  2. Invoke the Snoop servlet from an HTML browser using the URL: https://webserver/snoop.
  3. The request information displays the host that is serving the request as the local host - in this case, the server with the LoadBalanceWeight =1 is displayed.
  4. Try trading the LoadBalanceWeight between the primary and backup server and note which server handles the Snoop servlet request.

Detecting failure on the primary server

To achieve high availability, you need to know when your primary server is down. This is especially important for this basic high availability solution, which does not allow for automatic failover of the primary server to the backup server.

The process of detecting a failed server is a critical and timely task. Several factors can indicate that a server has failed, such as network problems, configuration problems, application overloading, or user error. Whatever solution you choose to detect server failures, you must ensure that the alert is as instantaneous as possible.


Feedback