Benefits of high availability configurations

High availability topologies provide several benefits, including the following:

• Scalability
  High availability topologies allow you to add application server processes as needed to handle a growing workload. As your processing needs change, you can easily modify your application server configuration to keep pace with that workload. Ideally, you can add more application servers and machines to handle any given load. WebSphere Application Server supports these methods of scaling your e-business network:

  • Multiple tiers The components of an application (for example, the Web server, application servers, and databases) reside on separate machines or logical partitions.
  • Vertical scaling Additional application server processes exist on a single physical machine. Vertical scaling uses clusters and cluster members.
  • Horizontal scaling Additional application server processes exist on multiple physical machines or logical partitions. Horizontal scaling uses clusters and cluster members. You can also use HTTP redirector products such as WebSphere Edge Server to implement horizontal scaling.
  • Demilitarized zone (DMZ) Use firewalls to create demilitarized zone machines, which are isolated from both the public Internet and other machines in the configuration. This configuration scales security processing, which improves security and throughput in the application environment.
  • Multiple cells You can deploy applications on multiple WebSphere Application Server Network Deployment cells to improve scalability and availability.

• Load balancing
  In a high availability topology you can distribute client requests among several application servers. The load balancing features of WebSphere Edge Server route requests to the application servers that are best suited to handle them. For example, you can direct requests from high-traffic URLs to more powerful servers. See workload management for more information.

• Security
  In a high availability topology you can configure firewalls and demilitarized zones (DMZs) to protect sensitive resources from unauthorized access. See Firewalls and demilitarized zone (DMZ) configurations for more information.

• Failover support
  Failover support is a critical component of high availability. In a single-machine configuration, any failure means that the entire system is unavailable. In high availability topologies you can configure hardware and process redundancy, which allow the system to continue operating if any one machine or server in the system fails. The following practices ensure failover support:

  • Keep backup servers, which do not run under normal circumstances. For example, you can use a single HTTP server to route client requests to several application servers. A backup HTTP server monitors the activity of the primary HTTP server, and if the primary server fails, the backup server takes over.
  • Configure multiple application servers that operate simultaneously on multiple physical machines. You can create multiple copies, or cluster members, of an application server. The cluster members are distributed over multiple machines or partitions, and all of them work simultaneously to process client requests. If a single application server or machine fails, the other servers and machines are not affected, and continue processing requests.
  • Deploy an application in multiple cells. If an entire cell fails, the others are still available to process client requests.

• Fault isolation
  Configurations that provide simple failover support are concerned only with individual server failures that have no effect on the performance of other servers. However, in some situations a malfunctioning server can create problems for other servers that are otherwise functioning normally. For example, it can consume more than its share of system and database resources, preventing other servers from gaining adequate access to these resources. A configuration that provides more robust failover support includes a degree of fault isolation, reducing the potential for the failure of one server to affect other servers. You can configure WebSphere Application Server to provide fault isolation between different parts of the system.

  • Deploy the Web server onto a separate machine or partition from the application servers. Separating the Web server ensures that problems with the application servers do not affect the Web server, and vice versa.
  • Use horizontal scaling to segregate application server processes onto different machines or logical partitions.
  • Deploy an application in multiple cells. Problems are confined to one domain while the other remains available.

• Shared data access
  In a high availability topology you can place backend resources such as databases on seperate machines or on logical partitions on the same system. When you separate backend databases from the application server process, it is easier to share those resources among multiple application servers. In addition, separating these resources from the rest of the application server environment can a layer of security to your configuration. For more informatoin on configuring database access for your application servers, see Administer JDBC resources.

• Data resiliency
  When failures occur, transient data can be lost. Data resiliency ensures that no data, or the least amount of data, is lost when a failure occurs. Use any of these methods to increase data resiliency:

  • Data replication maintains a current copy of you data. This backup copy of your database eliminates the database as a single point of failure. For more information, see Data replication.
  • Switchable disk uses IASPs to maintain a single copy of your data. In the event of a failure, the IASPs disconnect from the failed application server and connect to a functioning application server. For more information see Switchable disk.
  • Enable the Session Manager to store session information in a persistent database. This preserves session state in case of server failure. For more information see Sessions.

• Dynamic changes to configurations
  You can modify the system configuration without interrupting its operation. For instance, can add or remove cluster members to handle variations in the client load, change server characteristics and propagate the changes to its cluster members, or temporarily stop some servers for maintenance while other servers continue processing client requests.

• Mixed application server configurations
  Some high availability topologies allow you to deploy multiple versions of an application server simultaneously in separate cells. Applications can be deployed in stages and you can easily upgrade system hardware and software. When combined with the ability to make dynamic changes to the configuration, you can use a mixed server configuration to upgrade an application without any interruption of service.

  Note: The ability to run different versions of an application server in a configuration does not allow you to include Version 5 application servers in an existing 3.5 or 4.0 administrative domain, or to include Version 3.5.x or Version 4 application servers in a Version 5 cell.