|By Sudhir Upadhyay||
|August 8, 2005 12:00 PM EDT||
In enterprise application architecture, it is naïve to assume that none of the software/hardware components will go down. In fact, most of the IT managers and architects acknowledge this. However, a well-tested and robust recovery procedure continues to take a back seat when designing and implementing software projects. In several scenarios, administrators end up performing basic failover testing by shutting down the processes and verifying that the subsequent requests succeeded.
Although this level of testing can satisfy the failover requirements for the records, more robust failover testing needs to be performed to ensure a proper recovery if failures do occur. One of the primary reasons for the lack of robust recovery and well-tested procedures can be attributed to a high degree of reliance on the application server's in-built failover capabilities. While it is true that most of the popular application servers boost their clustering and associated high-availability features, it is equally important that system architects need to go beyond those features for an end-to-end high availability of the application. This article suggests how good planning, robust scripting, and a well- thought-out application design, along with application server facilities, can provide a highly available environment for the entire application. In the first article in a series of three, I will cover the basic high-availability options available while deploying a J2EE application on WebLogic Server.
Before diving into specifics, it is important to understand some of the commonly used terms when one talks about high-availability.
High Availability - So, what does high availability really mean? From a user's point of view, it means an application that is always available to perform the user's transactions. In other words, even though one or more of the back-end system becomes unavailable, the application may be architected in such a manner that these failures are not visible to the end user. High availability is a relative term - for some applications, there is high availability only if the site is never down - or zero downtime. For some applications it should be available, without interruptions - during the normal business operations. How and when a system is called highly available is typically defined by SLA - Service Level Agreements. Each organization may have its own system level agreements for the nonavailability of the applications during certain maintenance windows.
Transparent Failover - A highly available system does not necessarily imply that failover is always transparent. In other words, when one of the components within the application fails, the subsequent requests get routed to other available servers, thereby making it highly available. However it is possible for users to lose their sessions. There may even be a loss of data during the failure and things of that nature. In these cases, even though the system is available for subsequent requests, none of the above scenarios truly represents a transparent failover within an enterprise application.
Fault Tolerance - Fault tolerance is the system's ability to keep the system available and maintain data consistency in case of failure in one or more of its software components.
Clustering - Perhaps the most common term used in conjunction with HA, clustering is essentially a service provided by application servers in which multiple servers run as a group. The clustering service is responsible for load balancing the user requests and also for rerouting the incoming traffic to available servers should one of the servers in the cluster become unavailable.
Recovery - The ability of the system to recover itself from a failure condition as well as to bring the state of the objects into their pre-failure condition.
In an enterprise application, there are several points of failure - both within each individual component and at integration touch points with other components and interfaces. As the number of interfaces increases, the failover and recovery procedures become increasingly complex due to interdependencies involved. Although each component within the application may have recovery procedures for itself, the problem arises when one component or a combination of components within the system fails simultaneously.
So, a first step in designing a highly available enterprise system is identifying all of the possible permutations and combinations of failure points within the system. The identification process should involve all of the components within the system - application, network, hardware, and database - each and every component involved. As one begins to create such a matrix, it becomes overly complicated as the number of components and products that are mixing increases. This article will serve to focus failover and recovery of components and applications within the WebLogic Platform.
WebLogic Server - WebLogic Server provides a number of J2EE services that include Java Messaging Service (JMS), Transactions (JTS/JTA) and Security, Servlet Engine, EJB container, and so forth. When designing enterprise applications for high availability it is crucial that architects have a good understanding of how these services failover when one of the instances hosting them goes down. A thorough understanding of the failover and recovery procedures of these services is also critical in automating the recovery of a downed instance or a system.
Clustering Overview - Perhaps no discussion on WLS high availability is complete without touching on WebLogic Clustering. An application that is deployed homogenously in a cluster is generally highly available. When one of the server instances goes down, the request is routed to the other available server in the cluster. In fact, the concept of the cluster is not new to J2EE architects and WebLogic Server administrators. Readers of this article are encouraged to review the WebLogic Server clustering documentation (http://e-docs.bea.com/wls/docs81/cluster/index.html). Essentially, most of the services provided by WebLogic can be categorized as either clusterable (i.e., multiple instances of these run on different services on multiple servers), or nonclusterable (there may be multiple instances of these services configured, but only one is active at a given time within the cluster). More information on which services can be clustered is provided in WebLogic Server documentation. Table 1 lists the clustered and nonclustered services in WebLogic Platform 8.1.
|Thirunavukarasu 02/04/06 06:31:00 AM EST|
A neatly explained technical atricle. Very useful, very crisp. Thanks .
|Viktor Lioutyi 08/12/05 10:34:27 AM EDT|
How to test failover in automatic manner?
"In several scenarios, administrators end up performing basic failover testing by shutting down the processes and verifying that the subsequent requests succeeded.
Although this level of testing can satisfy the failover requirements for the records, more robust failover testing needs to be performed to ensure a proper recovery if failures do occur."
We did the manual testing and failover worked. But we would like to do automatic testing of failover to make sure that it works for all our 1000+ pages. BEA does not have any tool for such testing.
There are different reasons why someone may want to test all pages for failover.
1) WebLogic only replicates attributes that were modified. Call of session's setAttribute() method is an indication for WebLogic that attribute was modified. This call may be done explicitly or implicitly when jsp tags are used. It is possible that on some pages members of complex attributes were modified but WebLogic was not notified about it, so it will not replicate such attributes.
2) Complex attributes may reference other objects and attributes. After replication these references may be broken. For example, attribute A and B references object C. Only attribute A was modified, so only A will be replicated. After the replication A and B may point to different copies of C and program may not work correctly anymore.
3) Some objects are assumed to be singletons. Developer needs to provide special implementation for serialization to support replication of singleton objects. If this implementation is omitted, then replication may create copies of a singleton object.
4) Transient fields are not going to be replicated but there should be a recovery code that restores values of these fields after replication. Without testing we do not know if all our recovery code works correctly or not.
There are probably other reasons too.
Does anybody know about any tool for automatic testing of failover (or at least just session replication) for WebLogic and/or WebSphere?
Jun. 30, 2015 02:15 PM EDT Reads: 2,063
Jun. 30, 2015 01:45 PM EDT Reads: 1,914
Jun. 30, 2015 01:45 PM EDT Reads: 1,790
Jun. 30, 2015 10:20 AM EDT Reads: 438
Jun. 30, 2015 09:45 AM EDT Reads: 812
Jun. 29, 2015 12:15 PM EDT Reads: 2,597
Jun. 29, 2015 11:00 AM EDT Reads: 2,138
Jun. 29, 2015 09:45 AM EDT Reads: 2,477
Jun. 28, 2015 11:00 AM EDT Reads: 2,187
Jun. 27, 2015 10:00 AM EDT Reads: 2,203
Jun. 26, 2015 12:00 PM EDT Reads: 2,191
Jun. 26, 2015 10:00 AM EDT Reads: 2,058
Jun. 25, 2015 02:00 PM EDT Reads: 1,997
Jun. 25, 2015 01:30 PM EDT Reads: 2,143
Jun. 22, 2015 02:15 PM EDT Reads: 2,746
Jun. 20, 2015 12:00 PM EDT Reads: 3,845
Jun. 15, 2015 08:45 PM EDT Reads: 4,075
Jun. 15, 2015 07:15 PM EDT Reads: 3,872
Jun. 15, 2015 10:15 AM EDT Reads: 5,936
Jun. 11, 2015 08:00 AM EDT Reads: 2,337