Edit
Attach
P
rintable
r5 - 2013-05-14 - 10:12:41 - Main.sbeard
You are here:
TWiki
>
Deployment Web
>
InstallHighAvailability
>
JazzManualFailoverTechniques
<div id="header-title" style="padding: 10px 15px; border-width:1px; border-style:solid; border-color:#FFD28C; background-image: url(<nop>https://jazz.net/wiki/pub/Deployment/WebPreferences/TLASE.jpg); background-size: cover; font-size:120%"> ---+!! <img src="https://jazz.net/wiki/pub/Deployment/WebPreferences/new.png" alt="new.png" width="50" height="50" align="right"/> Manual failover techniques %DKGRAY% Authors: Main.MichaelAfshar <br> Build basis: CLM version 4.0 or later with !WebSphere Application Server 7 or later %ENDCOLOR%</div></sticky> <!-- Page contents top of page on right hand side in box --> <sticky><div style="float:right; border-width:1px; border-style:solid; border-color:#DFDFDF; background-color:#F6F6F6; margin:10px 10px 10px; padding: 10px 10px 10px;"> %TOC{title="Page contents"}% </div></sticky> <sticky><div style="margin:15px;"></sticky> Deploy each of the jts.war, ccm.war, rm.war (cold standby only), and qm.war on their respective Primary and Backup servers so that you can use idle standby as a strategy for failover in high availability environments. To plan your high availability deployment and learn more about the idle standby and cold standby, see [[IdleStandbyDeploymentForCrashRecovery][Idle standby deployment for crash recovery]]Idle standby deployment for crash recovery. ---++ Requirements The following table lists the basic high availability requirements: <sticky><div style="border-width:1px; border-style:solid; border-color:#ffd324; background-color:#fff6bf; margin:0 0 15px 15px; padding: 0 15px 0 15px;"> *Note:* To configure high availability in a fully distributed environment for all CLM applications, you will need 8 application servers. </div></sticky> <table width="100%" border="1" style="border-collapse:collapse;" cellspacing="3" cellpadding="5" bordercolor="#999"> <caption> <i>Table 1. Basic high availability requirements</i> </caption> <tr> <th bgcolor="#CCCCCC" scope="col"><b>Server</b></th> <th bgcolor="#CCCCCC" scope="col"><b>Software</b></th> <th bgcolor="#CCCCCC" scope="col"><b>Operating system</b></th> </tr> <tr> <td>IBM HTTP Server</td> <td><ul> <li>IBM HTTP Server 7.0 Fix Pack 18 or greater</li> <li>Web server plug-ins for !WebSphere Application Server 7.0 Fix Pack 23 or 8.0.0.3</li> <li>IBM Key Management v7.0.3.28</li> </ul></td> <td>Windows, Linux, AIX</td> </tr> <tr> <td>WebSphere Application Server Primary Server A</td> <td><ul> <li>WebSphere Application Server 7.0 Fix Pack 23 or 8.0.0.3</li> <li>Rational solution for Collaborative Lifecycle Management products (JTS, CCM, QM, RM)</li> </ul></td> <td>Windows, Linux, AIX</td> </tr> <tr> <td>WebSphere Application Server Backup Server B</td> <td><ul> <li>WebSphere Application Server 7.0 Fix Pack 23 or 8.0.0.3</li> <li>Rational solution for Collaborative Lifecycle Management products (JTS, CCM, QM, RM)</li> </ul></td> <td>Windows, Linux, AIX</td> </tr> <tr> <td>File Server, Shared Disk</td> <td>Lucene Index - file-based indexes used by the applications</td> <td>Windows, Linux, AIX</td> </tr> </table> ---++ Limitations The following is a list of known issues in the active CCM backup server: * The Jazz Build Engines will not run the scheduled builds, but can only run those explicitly requested builds. * The !BuildForge Build Engines will not run the scheduled or requested builds. * Due to the issue with the !BuildForge Build Engines, the Dependency Based Builds will not work while using the CCM standby. * !ClearQuest Synchronizer will not automatically synchronize the outgoing change requests. ---++ Setting up servers for a basic high-availability configuration The following sections describe setting up and configuring your primary and backup servers for a basic high-availability environment. ---+++ Installing and configuring the IBM HTTP Server and Web server plug-ins <sticky><div style="border-width:1px; border-style:solid; border-color:#ffd324; background-color:#fff6bf; margin:0 0 15px 15px; padding: 0 15px 0 15px;"> *Note:* If you use the Developer for Workgroups Client Access License, high availability is not supported. </div></sticky> To install and configure the IBM HTTP Server and Web server plug-ins, see these resources: 1. Installing the IBM HTTP Server: * For !WebSphere Application Server 7, see [[http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.ihs.doc/info/ihs/ihs/welcome_ihs.html][IBM HTTP Server, Version 7]] * For !WebSphere Application Server 8, see [[http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=/com.ibm.websphere.ihs.doc/info/ihs/ihs/welcome_ihs.html][IBM HTTP Server, Version 8]] 1. Installing the Web server plug-ins: * For !WebSphere Application Server 7, see [[http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.base.doc%2Finfo%2Faes%2Fae%2Ftins_webplugins.html][Installing web server plug-ins]] * For !WebSphere Application Server 8, see [[http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=%2Fcom.ibm.websphere.base.doc%2Finfo%2Faes%2Fae%2Ftins_webplugins.html][Installing and configuring web server plug-ins]] 1. Configuring a Web server and an application server on separate computes remotely: * For !WebSphere Application Server 7, see [[http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/tihs_remotesetup.html][Setting up a remote Web server]] * For !WebSphere Application Server 8, see [[http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/tihs_remotesetup.html][Setting up a remote web server]] 1. Securing transmissions between the Web server and the client and enable SSL on the IBM HTTP Server: * For !WebSphere Application Server 7, see [[http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.ihs.doc%2Finfo%2Fihs%2Fihs%2Fwelc6topsecureihs.html][Securing IBM HTTP Server]] * For !WebSphere Application Server 8, see [[http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=%2Fcom.ibm.websphere.ihs.doc%2Finfo%2Fihs%2Fihs%2Ftihs_sectaskov.html][Securing IBM HTTP Server]] <sticky><div style="border-width:1px; border-style:solid; border-color:#ffd324; background-color:#fff6bf; margin:0 0 15px 15px; padding: 0 15px 0 15px;"> *Note:* If you plan to replace the self-signed SSL certificates with those that belong to your organization, see the information center topic <a href="http://pic.dhe.ibm.com/infocenter/clmhelp/v4r0m3/topic/com.ibm.jazz.install.doc/topics/t_install_server_certificates.html" target="_blank">Installing a security certificate</a>. </div></sticky> ---+++ Installing and configuring a Jazz application on primary and backup servers The jts.war, ccm.war, and qm.war applications use the idle standby environment, while the rm.war and admin.war (Lifecycle Project Administration) remain in a stopped state on the backup server (cold standby). Also note that the admin.war (LPA) and jts.war applications must be installed on the same server. In the event of a failover of the Jazz Team Server, stop the primary server completely, fail over to the backup server, and start the admin.war application on the backup server. The following table lists the abbreviations that are used throughout these deployment instructions: <table width="600px" border="1" style="border-collapse:collapse;" "cellspacing:3px;" "cellpadding:5px;" bordercolor="#999"> <caption> <i>Table 2. Acronyms</i> </caption> <tr> <th bgcolor="#CCCCCC" scope="col"><b>Acronym</b></th> <th bgcolor="#CCCCCC" scope="col"><b>Term</b></th> </tr> <tr> <td>URI</td> <td>Uniform Resource Identifier</td> </tr> <tr> <td>JTS</td> <td>Jazz Team Server</td> </tr> <tr> <td>CCM</td> <td>Change and Configuration Management application</td> </tr> <tr> <td>QM</td> <td>Quality Management Application</td> </tr> <tr> <td>RM</td> <td>Requirements Management Application</td> </tr> <tr> <td>LPA</td> <td>Lifecycle Project Administration</td> </tr> <tr> <td>CLM</td> <td>Rational solution for Collaborative Lifecycle Management (JTS, CCM, QM, RM)</td> </tr> </table> To install and configure copies of the Rational solution for Collaborative Lifecycle Management (CLM) applications on the primary and backup servers, follow these steps. 1. Install the CLM applications on the primary and backup servers. 1. Configure !WebSphere Application Server and deploy the .WAR files on the primary and backup servers. 1. Run the setup wizard *ONLY* on the primary server. Do not run the setup wizard on the backup servers. 1. Set the public URL to point to the IBM HTTP Server and not the application server. 1. After installing and configuring the primary server, shut it down and copy its configuration files into the backup server installation. For information about installing CLM applications, configuring !WebSphere Application Server and deploying .WAR files, see the information center [[http://pic.dhe.ibm.com/infocenter/clmhelp/v4r0m3/topic/com.ibm.jazz.install.doc/topics/roadmap_form.html][Interactive Installation Guide]]. ---+++ Configuring high availability for both primary and backup servers <sticky><div style="border-width:1px; border-style:solid; border-color:#ffd324; background-color:#fff6bf; margin:0 0 15px 15px; padding: 0 15px 0 15px;"> *Note:* Examples in this section are for the jts.war application. You can use the same procedure for the ccm.war and qm.war applications. </div></sticky> The jts.war application is typically installed with a single application server as its target. With the introduction of the Web server, the application container configuration must be modified to allow routing through the Web server. To modify the application: 1. In the !WebSphere Console, click the jts.war application link under *Enterprise Applications*. 1. Select *Manage Modules*. 1. Select the check box for the jts.war application module. 1. In the list of clusters and servers, choose both the Web server and application server, and then click *Apply*. 1. Click *OK*, and then save the changes. 1. Restart the jts.war application. Reconfigure both the primary and backup Jazz Team Server instances 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 servers, update the =com.ibm.team.fulltext.indexLocation= and =com.ibm.team.jfs.index.root.directory= properties in the =teamserver.properties= files on both the primary and backup servers to store the index on a shared drive. * This property value is an example of what you can see on Windows: <verbatim>com.ibm.team.fulltext.indexLocation=I\:/sharedIndexFolder/workitemindex</verbatim> * This property setting is an example of what you can see on Linux: <verbatim>com.ibm.team.fulltext.indexLocation=/net/LinuxHost/sharedIndex/workitemindex</verbatim> ---+++ Turning off asynchronous tasks on the backup server To avoid any possible data contention between the two running Jazz Team Servers, 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: <verbatim>com.ibm.team.repository.scheduler.migration.mode.enabled=true</verbatim> 1. Restart the jts.war application on the backup server. <sticky><div style="border-width:1px; border-style:solid; border-color:#ffd324; background-color:#fff6bf; margin:0 0 15px 15px; padding: 0 15px 0 15px;"> *Note:* Ensure that the preceding property is preserved on the backup server after any updates are applied to the asynchronous task that changes the configuration file on the primary server. When asynchronous tasks are turned off, the backup server will not run the asynchronous tasks. If circumstances dictate that the backup server is used as the primary server for an extended period of time, this property should be reset to false to enable the background tasks in the Advanced Properties. Make sure to set it to true before restarting the primary server. </div></sticky> ---+++ 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= file 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= file on the Web server to complete the configuration. This =plugin-cfg.xml= file is located in the =plugin\config\<i>webserver1</i>= folder of the web server, where <i>webserver1</i> is the name that you assigned to the web server in the previous section, "Installing and configuring the IBM HTTP Server and Web Server plug-ins". ---+++ URI groups Depending on the high-availability environment setup and whether you intend to have a single !WebSphere Application Server instance for each application or one application server for all applications, you must plan accordingly. The URI groups is a logical grouping of the URIs that a cluster serves up. For example, if a single !WebSphere Application Server instance per application is used, declare a cluster for each application. One URI group is applied to a single cluster. A URI grouping might look like this example: <verbatim> <!-- JTS URI Group --> <UriGroup Name="default_host_JTS_basicHA_Cluster_URIs"> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/admin/*"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/jts/*"/> </UriGroup> <!-- CCM URI Group --> <UriGroup Name="default_host_CCM_basicHA_Cluster_URIs"> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/ccm/*"/> </UriGroup> <!-- QM URI Group --> <UriGroup Name="default_host_QM_basicHA_Cluster_URIs"> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/qm/*"/> </UriGroup> <!-- RM URI Group --> <UriGroup Name="default_host_RM_basicHA_Cluster_URIs"> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/rm/*"/> </UriGroup> </verbatim> ---+++ Server cluster If you set up one !WebSphere Application Server instance per application, a server cluster must be set up to include all servers that serve up that one application URI. A server cluster for the CLM applications might look like this example: <verbatim> <!-- JTS Server Cluster --> <ServerCluster CloneSeparatorChange="false" GetDWLMTable="false" IgnoreAffinityRequests="true" LoadBalance="Round Robin" Name="server1_jts_Cluster" PostBufferSize="64" PostSizeLimit="-1" RemoveSpecialHeaders="true" RetryInterval="60"> <Server LoadBalanceWeight="0" ConnectTimeout="0" ExtendedHandshake="false" MaxConnections="-1" Name="jts1Node01_server1" ServerIOTimeout="0" WaitForContinue="false"> <Transport Hostname="jts1.example.com" Port="9080" Protocol="http"/> <Transport Hostname="jts1.example.com" Port="9443" Protocol="https"> <Property Name="keyring" Value="/root/IBM/HTTPServer/Plugins/config/webserver1/plugin-key.kdb"/> <Property Name="stashfile" Value="/root/IBM/HTTPServer/Plugins/config/webserver1/plugin-key.sth"/> </Transport> </Server> <Server LoadBalanceWeight="1" ConnectTimeout="0" ExtendedHandshake="false" MaxConnections="-1" Name="jts2Node01_server1" ServerIOTimeout="0" WaitForContinue="false"> <Transport Hostname="jts2.example.com" Port="9080" Protocol="http"/> <Transport Hostname="jts2.example.com" Port="9443" Protocol="https"> <Property Name="keyring" Value="/root/IBM/HTTPServer/Plugins/config/webserver1/plugin-key.kdb"/> <Property Name="stashfile" Value="/root/IBM/HTTPServer/Plugins/config/webserver1/plugin-key.sth"/> </Transport>> </Server> </ServerCluster> <!-- End JTS Server Cluster --> <!-- CCM Server Cluster --> <ServerCluster CloneSeparatorChange="false" GetDWLMTable="false" IgnoreAffinityRequests="true" LoadBalance="Round Robin" Name="server1_ccm_Cluster" PostBufferSize="64" PostSizeLimit="-1" RemoveSpecialHeaders="true" RetryInterval="60"> <Server LoadBalanceWeight="0" ConnectTimeout="0" ExtendedHandshake="false" MaxConnections="-1" Name="ccm1Node01_server1" ServerIOTimeout="0" WaitForContinue="false"> <Transport Hostname="ccm5.example.com" Port="9080" Protocol="http"/> <Transport Hostname="ccm5.example.com" Port="9443" Protocol="https"> <Property Name="keyring" Value="/root/IBM/HTTPServer/Plugins/config/webserver1/plugin-key.kdb"/> <Property Name="stashfile" Value="/root/IBM/HTTPServer/Plugins/config/webserver1/plugin-key.sth"/> </Transport> </Server> <Server LoadBalanceWeight="1" ConnectTimeout="0" ExtendedHandshake="false" MaxConnections="-1" Name="ccm2Node01_server1" ServerIOTimeout="0" WaitForContinue="false"> <Transport Hostname="ccm6.example.com" Port="9080" Protocol="http"/> <Transport Hostname="ccm6.example.com" Port="9443" Protocol="https"> <Property Name="keyring" Value="/root/IBM/HTTPServer/Plugins/config/webserver1/plugin-key.kdb"/> <Property Name="stashfile" Value="/root/IBM/HTTPServer/Plugins/config/webserver1/plugin-key.sth"/> </Transport> </Server> </ServerCluster> <!-- End CCM Cluster --> <!-- QM Server Cluster --> <ServerCluster CloneSeparatorChange="false" GetDWLMTable="false" IgnoreAffinityRequests="true" LoadBalance="Round Robin" Name="server1_qm_Cluster" PostBufferSize="64" PostSizeLimit="-1" RemoveSpecialHeaders="true" RetryInterval="60"> <Server LoadBalanceWeight="0" ConnectTimeout="0" ExtendedHandshake="false" MaxConnections="-1" Name="qm1Node01_server1" ServerIOTimeout="0" WaitForContinue="false"> <Transport Hostname="qm7.example.com" Port="9080" Protocol="http"/> <Transport Hostname="qm7.example.com" Port="9443" Protocol="https"> <Property Name="keyring" Value="/root/IBM/HTTPServer/Plugins/config/webserver1/plugin-key.kdb"/> <Property Name="stashfile" Value="/root/IBM/HTTPServer/Plugins/config/webserver1/plugin-key.sth"/> </Transport> </Server> <Server LoadBalanceWeight="1" ConnectTimeout="0" ExtendedHandshake="false" MaxConnections="-1" Name="qm2Node01_server1" ServerIOTimeout="0" WaitForContinue="false"> <Transport Hostname="qm8.example.com" Port="9080" Protocol="http"/> <Transport Hostname="qm8.example.com" Port="9443" Protocol="https"> <Property Name="keyring" Value="/root/IBM/HTTPServer/Plugins/config/webserver1/plugin-key.kdb"/> <Property Name="stashfile" Value="/root/IBM/HTTPServer/Plugins/config/webserver1/plugin-key.sth"/> </Transport> </Server> </ServerCluster> <!-- End QM Cluster --> <!-- RM Server Cluster --> <ServerCluster CloneSeparatorChange="false" GetDWLMTable="false" IgnoreAffinityRequests="true" LoadBalance="Round Robin" Name="server1_rm_Cluster" PostBufferSize="64" PostSizeLimit="-1" RemoveSpecialHeaders="true" RetryInterval="60"> <Server LoadBalanceWeight="0" ConnectTimeout="0" ExtendedHandshake="false" MaxConnections="-1" Name="rm1Node01_server1" ServerIOTimeout="0" WaitForContinue="false"> <Transport Hostname="rm3.example.com" Port="9080" Protocol="http"/> <Transport Hostname="rm3.example.com" Port="9443" Protocol="https"> <Property Name="keyring" Value="/root/IBM/HTTPServer/Plugins/config/webserver1/plugin-key.kdb"/> <Property Name="stashfile" Value="/root/IBM/HTTPServer/Plugins/config/webserver1/plugin-key.sth"/> </Transport> </Server> <Server LoadBalanceWeight="1" ConnectTimeout="0" ExtendedHandshake="false" MaxConnections="-1" Name="rm2Node01_server1" ServerIOTimeout="0" WaitForContinue="false"> <Transport Hostname="rm4.example.com" Port="9080" Protocol="http"/> <Transport Hostname="rm4.example.com" Port="9443" Protocol="https"> <Property Name="keyring" Value="/root/IBM/HTTPServer/Plugins/config/webserver1/plugin-key.kdb"/> <Property Name="stashfile" Value="/root/IBM/HTTPServer/Plugins/config/webserver1/plugin-key.sth"/> </Transport> </Server> </ServerCluster> <!-- End RM Cluster --> </verbatim> ---+++ Route The route element is where the URI group and server cluster get bound together. The rout element tells the plug-in which URIs are served up by which cluster. Using the preceding example, the example route elements will bind the application URIs to their respective clusters as shown: <verbatim> <Route ServerCluster="server1_jts_Cluster" UriGroup="default_host_JTS_basicHA_Cluster_URIs" VirtualHostGroup="default_host"/> <Route ServerCluster="server1_ccm_Cluster" UriGroup="default_host_CCM_basicHA_Cluster_URIs" VirtualHostGroup="default_host"/> <Route ServerCluster="server1_qm_Cluster" UriGroup="default_host_QM_basicHA_Cluster_URIs" VirtualHostGroup="default_host"/> <Route ServerCluster="server1_rm_Cluster" UriGroup="default_host_RM_basicHA_Cluster_URIs" VirtualHostGroup="default_host"/> </verbatim> ---+++ Synchronizing the configuration files for the primary and backup servers Customized server properties are not automatically synchronized between the primary and backup servers. In order to ensure that the backup servers have consistent configuration attributes, all customized settings must be propagated to the backup servers before they become active. Periodically backing up from the primary server and restoring those files to the backup server are sufficient to keep customizable server properties in sync. <sticky><div style="border-width:1px; border-style:solid; border-color:#ffd324; background-color:#fff6bf; margin:0 0 15px 15px; padding: 0 15px 0 15px;"> *Note:* If there are any configuration changes that require that you restart the primary server, then the backup server must also be restarted to get these changes. </div></sticky> This list includes configuration files (by CLM Application) that might need to be synchronized between the primary and backup servers. * JTS <verbatim> JazzInstallDir/server/conf/jts/teamserver.properties JazzInstallDir/server/conf/jts/log4j.properties </verbatim> * CCM <verbatim> JazzInstallDir/server/conf/ccm/teamserver.properties JazzInstallDir/server/conf/ccm/log4j.properties </verbatim> * QM <verbatim> JazzInstallDir/server/conf/qm/teamserver.properties JazzInstallDir/server/conf/qm/log4j.properties JazzInstallDir/server/conf/qm/integration_config.xml </verbatim> * RM <verbatim> JazzInstallDir/server/conf/rm/log4j.properties JazzInstallDir/server/conf/rm/fronting.properties JazzInstallDir/server/conf/rm/friendsconfig.rdf JazzInstallDir/server/rrcweb/composerweb.properties JazzInstallDir/server/rrcweb/log4j.properties </verbatim> * ADMIN <verbatim> JazzInstallDir/server/conf/admin/friends.rtf JazzInstallDir/server/conf/admin/log4j.properties JazzInstallDir/server/conf/admin/admin.properties </verbatim> ---+++ 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 on the !PrimaryNode01 _server1 the !LoadBalanceWeight = 0 property is set and on the !BackupNode01_server1 the !LoadBalanceWeight = 1 property is set. Save the =plugin-cfg.xml= file. 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. 1. Invoke the Snoop servlet from an HTML browser by going to =https://webserver/snoop=. 1. The requested information displays the host that is serving the request as the localhost. In this case the server with the !LoadBalanceWeight =1 property is displayed. 1. Try trading the !LoadBalanceWeight property between the primary and backup servers, and note which server handles the Snoop servlet request. ---+++ Detecting failure on the primary server <sticky><div style="border-width:1px; border-style:solid; border-color:#ffd324; background-color:#fff6bf; margin:0 0 15px 15px; padding: 0 15px 0 15px;"> *Important:* You must ensure that the primary server is completely stopped before switching over to the failover server. Also be sure that there are no running processes that are interacting with the database. </div></sticky> To achieve high availability, you must know when the primary server is down. This knowledge is especially important for this basic high-availability solution, which does not support automatic failover of the primary server to the backup server. The process of detecting a failed server is a critical and time-sensitive 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 rapid as possible. ---++ Taking the primary servers offline If your primary servers fail, or if you suspect your server is experiencing problems and requires maintenance, the first priority is to redirect clients to a backup server so that client applications work with as little interruption as possible. Sometimes, you can fix the failed application server by restarting it. If you suspect the repair or maintenance of the primary application server might take more time to fix, then it is best to mark the primary server as unavailable. <sticky><div style="border-width:1px; border-style:solid; border-color:#ffd324; background-color:#fff6bf; margin:0 0 15px 15px; padding: 0 15px 0 15px;"> *Important:* You must ensure that the primary server is completely stopped before switching over to the failover server. Also be sure that there are no running processes that are interacting with the database on the primary server. </div></sticky> 1. In the web server =plugin-cfg.xml= file, locate the following line: =<Server <nop>LoadBalanceWeight ="1" ...= 1. Change the =<nop>LoadBalanceWeight= attribute from 1 to 0. 1. Save the =plugin-cfg.xml= file. 1. After the backup servers are started, run the following commands to resume the indexer on the backup servers for Jazz Team Server, Change and Configuration Management (CCM), and Quality Management (QM) applications: <verbatim>repotools-jts -resumeIndexer repositoryURL=https://server.example.com/jts adminUserId=wasadmin adminPassword=wasadmin</verbatim> <verbatim>repotools-ccm -resumeIndexer repositoryURL=https://server.example.com/ccm adminUserId=wasadmin adminPassword=wasadmin</verbatim> <verbatim>repotools-qm -resumeIndexer repositoryURL=https://server.example.com/qm adminUserId=wasadmin adminPassword=wasadmin</verbatim> When failing over to the Jazz Team Server backup, start the LPA application from the !WebSphere console. When the =LoadBalanceWeight= property is set to 0, no requests can be sent to the server even if it becomes available. To restore availability to the server, change the =LoadBalanceWeight= property setting back to 1. ---++ Restoring the primary server To restore the primary server to operation, you must schedule the server startup, and switch the =LoadBalanceWeight= property attributes so that you prevent the primary and backup servers from communicating to the repository at the same time. During the recovery process, some users might experience a brief disconnection or delay. However, after the primary server is back up, the server resumes taking requests from the web server. 1. Make sure the primary server is turned off. 1. In the web server =plugin-cfg.xml= file, locate the entry for the =PrimaryNode01_server1= property, and change the =LoadBalanceWeight= attribute from 0 to 1. 1. In the web server =plugin-cfg.xml= file, locate the entry for the =BackupNode01_server1= property, and change the =LoadBalanceWeight= attribute from 1 to 0. 1. Save the edits to the web server =plugin-cfg.xml= file. 1. Shut down the backup server before switching back to the primary server to prevent concurrent database access or stale cached data in the application. After the backup server is turned off, start the primary server. 1. When the primary server is back up and has resumed taking requests, you can start the backup server again. ---+++++!! Related topics: [[IdleStandbyDeploymentForCrashRecovery][Idle standby deployment for crash recovery]] ---+++++!! External links: * !WebSphere Application Server version 7: * [[http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.ihs.doc/info/ihs/ihs/welcome_ihs.html][IBM HTTP Server]] * [[http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.base.doc%2Finfo%2Faes%2Fae%2Ftins_webplugins.html][Installing web server plug-ins]] * [[http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/tihs_remotesetup.html][Setting up a remote Web server]] * [[http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.ihs.doc%2Finfo%2Fihs%2Fihs%2Fwelc6topsecureihs.html][Securing IBM HTTP Server]] * !WebSphere Application Server version 8: * [[http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=/com.ibm.websphere.ihs.doc/info/ihs/ihs/welcome_ihs.html][IBM HTTP Server]] * [[http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=%2Fcom.ibm.websphere.base.doc%2Finfo%2Faes%2Fae%2Ftins_webplugins.html][Installing and configuring web server plug-ins]] * [[http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/tihs_remotesetup.html][Setting up a remote web server]] * [[http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=%2Fcom.ibm.websphere.ihs.doc%2Finfo%2Fihs%2Fihs%2Ftihs_sectaskov.html][Securing IBM HTTP Server]] ---+++++!! Additional contributors: None <sticky></div></sticky>
Edit
|
Attach
|
P
rintable
|
V
iew topic
|
Backlinks:
We
b
,
A
l
l Webs
|
H
istory
:
r12
|
r7
<
r6
<
r5
<
r4
|
More topic actions...
Deployment
Deployment web
Planning and design
Installing and upgrading
Migrating and evolving
Integrating
Administering
Monitoring
Troubleshooting
Community information and contribution guidelines
Create new topic
Topic list
Search
Advanced search
Notify
RSS
Atom
Changes
Statistics
Web preferences
NOTE: Please use the Sandbox web for testing
Status icon key:
To do
Under construction
New
Updated
Constant change
None - stable page
Smaller versions of status icons for inline text:
Copyright © by IBM and non-IBM contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our
Terms of Use.
Please read the following
disclaimer
.
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more
here
.