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
Installing and configuring a Jazz application on primary
and backup servers
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:
- In the WebSphere Console, click the jazz.war application link
under Enterprise Applications.
- Select Manage Modules.
- Select the check box for the jazz.war application module.
- In the list of clusters and servers, choose both the Web server
and application server, then click Apply.
- Click OK, then Save changes.
- Restart the jazz.war application.
Reconfigure the Jazz application on the primary application
server to turn off security for the jazz.war application:
- 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.
- Change each occurrence of "CONFIDENTIAL" to "NONE".
- Make sure WebSphere Application Server is running, open a browser
and go to: https://localhost:9043/ibm/console/logon.jsp
- Go to the Applications -> Enterprise Applications page.
- Select the jazz_war application and click Update.
- Select Replace or add a single file.
- 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.
- Click Browse and select the web.xml file
that you modified in step 1.
- Click Next and follow through until the
application is saved.
- 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:
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.
- Add the following line to the teamserver.properties file on the
Backup server:
com.ibm.team.repository.scheduler.migration.mode.enabled=true
- 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.
- 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.
- Invoke the Snoop servlet from an HTML browser using the URL: https://webserver/snoop.
- 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.
- 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.