r9 - 2014-05-22 - 14:20:24 - SusanYeshinYou are here: TWiki >  Deployment Web > DeploymentPlanningAndDesign > ApproachesToImplementingHAAndDR > ImplementingJazzApplicationServerRecoveryUsingAnIdleStandbyConfiguration

Implementing Jazz application server recovery using an idle standby configuration

Authors: MichaelAfshar, StevenBeard
Build basis: CLM and SSE Jazz applications 4.0 or later with WebSphere Application Server 7 or later

This topic describes how to plan an idle standby Jazz deployment for application server failure.

The idle standby configuration enables recovery from failover to help ensure minimal impact on business operations during planned or unplanned server outages. This document covers planning the idle standby configuration with Jazz Team Server using WebSphere Application Server.

Key points

Before you decide to use the idle standby configuration, consider the following key points:

  • Determine what the outage tolerance is for your organization, and if you need a truly idle standby or if having a backup server in the stopped state (also referred to as "cold standby") is adequate. The trade-off is additional complexity for an idle standby vs. a slightly longer outage for a cold standby. See the section Differences between idle standby and cold standby for details.
  • Jazz applications are licensed for use as single-server configurations and cannot be used in either a cloned or a clustered configuration, except if implemented in an idle standby configuration. In this configuration, you can activate a backup server if the primary server fails, or if maintenance needs to be performed on the primary server.
  • If considering implementing a true high availability deployment, see Clustering for high availability.

Idle standby configuration is not intended to provide complete support for failover. If the primary server fails or if it is intentionally taken offline, some users might need to authenticate to the Web again, or wait for their client to refresh a view.

  • The backup server is not intended to be run for extended periods in place of the primary server.
Important: Jazz Team Server applications allow only a single server to be active at any one time to a repository; therefore, the backup (or Idle) server is configured to never run asynchronous (or background) tasks. If a switch is made to the backup server, you must plan to bring the primary server back up as quickly as possible.

Deployment topology

The following topology diagram illustrates the configuration for basic high availability when using idle standby. In the following figure, the IBM HTTP Server is used to direct incoming traffic to one of the two WebSphere Application Servers, Primary Server A or Backup Server B. The WebSphere servers represent a primary and secondary node in the cluster. They are both members of the same cluster cell. In addition to the WebSphere nodes, there is an LDAP server, a file server (for file-based RDF and Text indexes), and a Database server.

basic_ha.gif

In order to minimize the risk of a single point of failure, you should also consider the database server and the shared file server. For information about configuring the DB2 high availability database repository, see this jazz.net article. You should also ensure the storage solution for the shared files provides for redundancy; for example, RAID 10 or other SAN solutions that provide HA. See this topic in the information center for a more detailed example of a Fully distributed enterprise topology with idle standby.

Differences between idle standby and cold standby

As you are planning your standby configuration, you should consider whether to have an idle standby or a cold standby environment for your applications. Cold standby refers to having backup servers in place with installed applications in a stopped state, while idle standby comprises backup servers with installed applications already started and in an idle state. Following are a few key considerations for each environment:

Manual failover with backup: Applications not started (cold standby)

  • The applications in the backup servers will be in a stopped state. You can either do this with the entire WebSphere Application Server not started, or WebSphere Application Server started but individual applications not started. The latter is recommended for a shorter outage.
  • It is simpler to set up. You clone the Primary server after it is provisioned and configured.
  • Configuration updates made on the Primary server can be propagated by a simple file synchronization using rsync or other utilities.
  • Because the Backup server is not running, it is not necessary to disable background tasks in the backup. The backup can therefore service requests indefinitely (if needed) after the failover.
  • The outage time would be the time needed to change the request routing in the web server, and the time to start the application on the Backup server. The total time taken to recover would include: time to detect the failure, time for administrators to become available to support the recovery and time to manually recover. This would lead to a typical Mean time to recovery (MTTR) of 30 minutes - 2 hours.

Manual failover with backup: Applications are started but excluded from network (idle or warm standby)

  • The idle standby can be considered when the tolerance for outage is very low and immediate failover is required. The idle standby is currently supported for a subset of the CLM applications. (JTS, CCM, and QM)
  • Extra care is needed to prevent concurrent database access by the Primary and Backup instances.
    • Background tasks must be disabled in order to ensure the application is completely idle; this involves a modification to the configuration files after cloning.
    • The Backup server must be completely inaccessible from the network (by using a firewall), in order to prevent any side-door access from users using the actual address of the Backup server.
  • To propagate configuration updates made on the Primary server, you must merge the changes with the Backup server while ensuring the background tasks remain disabled on the backup. A restart of the backup application is needed to apply the changes.
  • Because the background tasks are disabled, the backup should only be in service for a minimal amount of time.
Note: For both cold standby or idle standby, you must ensure that the Primary server is completely stopped prior to failover. Also be sure that there are no running processes that are interacting with the database.

Related topics: Jazz manual failover techniques

External links:

Additional contributors: None

Edit | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r9 < r8 < r7 < r6 < r5 | More topic actions
Deployment.ImplementingJazzApplicationServerRecoveryUsingAnIdleStandbyConfiguration moved from Deployment.ImplementingJazzApplicationRecoveryUsingAnIdleStandbyConfiguration on 2014-03-30 - 13:45 by StevenBeard -
 
This site is powered by the TWiki collaboration platformCopyright © by the 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.
Ideas, requests, problems regarding the Deployment wiki? Create a new task in the RTC Deployment wiki project