Summary

 

We have discussed various techniques to implement high availability end-to-end WebSphere production systems. Availability commonly refers to uptime. Using techniques discussed here, you can build the entire WebSphere system with 99.5% availability or better.

High availability is not only for 7x24 businesses. There are two types of downtimes: planned downtime and unplanned downtimes. The techniques we discussed above are for both planned downtime and unplanned downtime. Clustering techniques make rolling upgrades of hardware and software and hot replacement possible. Nobody knows when unplanned downtime will occur; it may occur during your business hours, even though you are in a 5x8 business. Clustering techniques help the system with automatic fault detection and service recovery. If you want to avoid interruptions to your operations due to system failures, then you need to use these techniques whether you are a 7x24, 6x20, or 5x8 business. Non-7x24 business hours provide opportunities for planned downtime for system maintenance and software/hardware upgrades off-line, but your system can still fail at any time due to hardware, software, and network problems.

High availability implementation needs high investment in hardware, software, and skilled personnel. Therefore, it is important to evaluate how much you will lose if your system is down during your operation hours.

WebSphere production system availability is determined by the weakest link in the WebSphere system chain. Therefore, it is very important to evaluate each part of the end-to-end WebSphere system high availability and eliminate all SPOFs, as shown in Figure 13-16.

Figure 13-16 An end-to-end WebSphere system that removes SPOFs

There are two kinds of availability:
Process availability
Data availability

Process availability is achieved by multiple processes of an application, such as WebSphere workload management using server clusters, multiple Web servers, multiple database instance processes, multiple firewall processes, and multiple LDAP server processes. Usually, clients find the available process using 1-to-n mapping, redirection (IP spraying), or transparent IP takeover.

Data availability is achieved by replication or clustering. When data is shared by multiple processes, data integrity should be ensured by distributed lock management. Data is either stored in memory or on disk. For in-memory or local data, we need to maintain client request affinity to access the same data. It is very important to make sure that data inconsistencies be corrected before any process uses data, since a failed process may damage data integrity.

Depending on data change and access frequencies, we have different approaches to achieve data high availability: Type I. Static data

There are no changes for a period of months. An example is software install binaries. This static data is usually placed in individual hosts. For convenience of management, it can also be placed in shared disks or file systems. Type II. Rarely changing data with planned change time (change period: several hours to several days)

Examples are firewall configuration files, HTTP server configuration files, WebSphere configuration files, or HTTP static files. You can copy these files to different nodes (replication). However, an HA file system can help to minimize your administration burden. If, for example, you have 10 Web servers and you need to copy HTTP files to 10 Web servers every day (assuming that you change Web pages once a day), content management software could be used to reduce the administrative work involved in managing this data. Type III. Rarely changing data with unplanned change time

Examples are LDAP data and WebSphere administrative repository. Clustering or replication can be used for high availability, as we have discussed. Type IV. Active data with frequent accesses and frequent changes

Examples are Entity EJBs data, session data, and application data. We have discussed how to make these data and data management services highly available.

Data high availability is more difficult to implement than process high availability. Most importantly, data high availability and process high availability are both needed to complete the task. Data high availability is essential in most applications. It does not make any sense for a business to run a process if that process cannot access required data. For example, there is little value in running a stock brokerage system if stock data and trading session data are unavailable. It does not help to have the WebSphere EJB container process available if Entity EJBs cannot access their data states, or to have the WebSphere Web container process if servlets cannot access needed HTTP session states.

We have discussed aspects and techniques for building an end-to-end highly available WebSphere production system. Through these techniques, we can achieve both data high availability and process high availability for the WebSphere system.

  Prev | Home | Next

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.