|
|
In previous versions of WAS, transaction log recovery could only be achieved by restarting the appserver which leads to slow recovery time from a failure (you can either restart the appserver itself - automatically or manually - or use clustering software to failover to a backup server).
Starting a backup server using clustering software is known as a cold failover as the backup server needs to start an appserver process during the failover. WebSphere also requires IP failover for transaction log recovery in older versions of WebSphere. Figure 6-16 depicts a typical HA setup with previous versions of WAS:
Figure 6-16 Traditional Transaction Manager high availability setup
A shared drive is attached to both servers. It holds the configuration repository, log files, transaction logs and the WAS binaries as well. Both servers have their own IP addresses, and share a virtual IP address through which clients can access the appserver. An external HA software, such as IBM HACMP or Tivoli System Automation, is used to manage the resource group of the virtual IP address, shared disk and its file systems, and scripts to start or to stop the WAS process.
If the active server crashes or fails, the HA software moves the resource group to the backup server. It involves assigning and mounting the shared drive on the backup server, assigning the virtual IP address and then starting the WAS process. Although this is a proven solution, it has a number of disadvantages:
- Recovery time is slow. The appserver process can only be started during a failover to recover the transaction logs and resolve any in-doubt transactions. This can potentially take more than five minutes due to JVM start times.
- There is a single virtual IP address to be failed over, which leads to a limitation of having both servers on the same subnet. This is not desirable when you want to have your appservers physically located at different sites for a high level of resilience.
- The configuration of this HA solution is highly complex. Additional HA software is necessary. And there are timing and dependency issues in starting components in the resource group.
By leveraging the latest storage technologies, WAS V6 offers a much simpler HA configuration. The newly introduced peer-to-peer hot-failover model allows transaction recovery to be performed in a much shorter time. While the new version can still work with external HA software, IBM WAS ND V6 itself can be a Transaction Manager HA solution with the right environment as described in the following section.
