Skip to main content

Patterns for e-business > Select Custom design > Select Non-Functional Requirement >
c


Non-Functional Requirements::High Availability: Runtime patterns

Basic Runtime pattern
The figure below shows the base Runtime pattern for the Self-Service::Stand-alone Single Channel application pattern. (Although this Runtime pattern was historically used as an entry-level footprint, the proliferation of hacker attacks has caused it now to be regarded as an anti-pattern. However for the moment we will keep it on the web site because it has been used in the IBM Redbook, IBM WebSphere V5 Edge of Network Patterns (SG24-6896), as the simplest base design to which various High Availability and High Performance nodes can be added.) The variations that follow show the additional nodes added to this basic Runtime design to enable each high availability configuration. This does not mean that Self-Service::Stand-alone Single Channel application pattern is the only design upon which these high availability variations could be made. These same principles can be used in many business and runtime patterns.

For this basic Runtime pattern, both the presentation and application tier are located in the Web application server. The Web application server node itself is located between two firewalls. This semi-secure area is referred to as the DMZ (demilitarized zone). The Web application server node also provides authentication and authorization services through the use of a common directory services node in the secure, or internal network behind a second firewall. Application data and application server configuration data is also kept on a database node behind the second firewall.

High Availability: Basic Runtime pattern
(Click a node to get a detailed explanation.)
Design Last Updated: 12-2002
High Availability application pattern: Runtime pattern Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information

Variation 1: Single load balancer
In this variation, multiple Web application servers are running an application. A single load balancer distributes incoming requests for an application among the Web servers on the Web application server nodes. The load balancer balances incoming traffic among a cluster of back-end servers (in this case, web application servers that serve the same content) through a combination of load balancing and management software. It can detect a failed back-end server and forward traffic to other servers within the same cluster of back-end servers (web application servers in this case). When a failed back-end server (web application server) is brought back online, the load balancer will automatically resume forwarding traffic to it. All client requests received by the load balancer machine are directed to the "best" back-end server (web application server in this case) in a cluster, according to weights that can be set dynamically or fixed. Dynamic weights can be adjusted using advisors to gather information on the health and load of the back-end servers (web application servers in this case).

For this variation at least two additional nodes are added to those in the basic Runtime pattern:

  • One load balancer node
  • One or more additional Web Application Server nodes


This Runtime pattern represents an initial step in your effort to provide high availability for the site. Although scalability and high availability for the application is achieved through the use of a load balancer node in front of a cluster of web application server nodes, it does not provide failover for the load balancer node itself.


High Availability: Runtime pattern: Single load balancer
(Click a node to get a detailed explanation.)
Design Last Updated: 12-2002
High Availability: Runtime pattern: Single load balancer

Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information

From a security point of view, the load balancer node is neutral. It does not affect the security of your site as long as you do not forward unauthorized requests directly into your internal network.

Note that, when designing your runtime pattern, be careful not to forward unauthenticated requests from the internet directly through the domain firewall into your private network. If you have files which do not need to be protected, place the server in the DMZ. It is recommended that you do an address and/or port change through the NAT/NAPT forwarding method before forwarding requests into your private network. Some companies security policies even demand a protocol change between the first and the second firewall.

Benefits
This runtime pattern offers the following benefits:

  • Very simple installation and configuration
  • Very little delay for the forwarding task if the Media Access Control (MAC) forwarding method is used
  • High availability and failover for the Web application server nodes is provided
  • Horizontal scalability is possible by simply adding more servers to the web application server load balancer cluster


Limitations
This runtime pattern has the following limitations:

  • The load balancer node still represents a single point of failure


Variation 2: Load balancer hot standby
This is the standard high availability solution for the load balancer nodes themselves. This pattern removes the single point of failure from the load balancer node by adding a second node with the same function. The first node will be the active, working load balancer. It is the primary load balancer. The second one keeps track of the balancing information and is ready to take over the work of the primary node at any moment. It is the standby load balancer.

This variation requires at least three nodes in addition to the basic Runtime pattern:

  • Two load balancer nodes
  • One or more additional Web Application Server nodes



High Availability: Runtime pattern: Load balancer hot standby
(Click a node to get a detailed explanation.)
Design Last Updated: 12-2002
High Availability: Runtime pattern: Load balancer hot standby

Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information

Benefits
This variation offers all of the benefits listed for variation 1 plus:

  • High availability and failover is provided for the load balancer nodes


Disadvantages
This variation has the following disadvantage:

  • One server is in hot standby mode, not doing any productive work


Variation 3: Mutual high availability
This variation demonstrates an advanced way to run two load balancer nodes in a highly available configuration called the mutual high availability mode. In the previous patterns, a second load balancer node existed, but was in hot standby mode. It did not perform load balancing unless the primary load balancer node failed.

In a mutual high availability configuration, both load balancer nodes are active and balancing requests for their own configured back-end server clusters. It is possible to configure this feature if you have at least two clusters of back-end servers to be load balanced.

As can be seen in the Runtime diagram below, each load balancer is configured with its own set of back-end servers to be load balanced. In addition, each load balancer also has connections to, and definitions for, the back-end servers of the other load balancer machine. Each load balancer monitors the health of the other load balancer, and if one detects the failure of the other, it takes over the load balancing function for the failing load balancer machine.

Each load balancer presents a different IP address and DNS name to the Internet. When a failure is detected by one of the load balancer machines, one of the functions it performs during takeover is to dynamically alias the IP address of the failing load balancer machine to its Network Interface Card (NIC). It will then receive packets destined for the failed machine.

For this variation, you need at least three nodes in addition to the Basic Runtime pattern:

  • Two load balancer nodes.
  • One or more additional Web application server nodes.



High Availability: Runtime pattern: Mutual high availability
(Click a node to get a detailed explanation.)
Design Last Updated: 12-2002
High Availability: Runtime pattern: Mutual high availability

Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information

With mutual high availability each load balancer node has at least one load balancer cluster assigned to it and hence acts in the role of the primary load balancer for it. Each node also performs the backup load balancer role for the cluster(s) of its partner node.

Benefits
Additional benefits from previous Runtime patterns are:

  • Both load balancer nodes are active and perform load balancing.


Disadvantages
This variation has the following disadvantage:

  • The configuration of mutual high availability is more complex


Variation 4: Wide area load balancing
This variation introduces load balancing among remote networks. A load balancer node balances requests between remote networks. Load balancer nodes in each local network are members of a wide area cluster and act as both a router between the main load balancer node and the local cluster as well as a load balancer for the local cluster. Such a local cluster could also represent an entire site.

This variation addresses those issues with the introduction of additional caching proxy nodes and a high availability load balancer node to distribute client requests between the caching proxy nodes.


High Availability: Runtime pattern: Wide area load balancing
(Click a node to get a detailed explanation.)
Design Last Updated: 12-2002
High Availability: Runtime pattern: Wide area load balancing

Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information

Benefits
This variation provides all the advantages of Single load balancer plus:

  • Provides high availability among remote clusters or even entire sites, but is still simple to implement
  • Supports cookie based server affinity
  • Entire sites can be added and removed by simply adding or removing the local load balancer node from the wide area load balancer cluster
  • When using Media Access Control (MAC) forwarding, response data is sent directly to the client


Disadvantages
This variation has the following disadvantage:

  • When load balancing entire sites, everything depends on those main load balancer nodes


Variation 5: Caching proxies with security plug-in
This variation adds elements of scalability, high availability and back-up to the authentication and authorization functions performed in the caching proxy node with the introduction of additional caching proxy nodes and a high availability load balancer node to distribute client requests between the caching proxy nodes.

The second caching proxy node provides a measure of replication and failover support in the event of a caching proxy node failure (or if one is brought down for maintenance purposes). Each caching proxy node can perform the authentication/authorization functions required for clients in addition to proxying and caching requests to the back-end application servers.


Note: Variations of caching proxies runtime patterns (with or without security services) are described in High Performance Runtimes:


High Availability: Runtime pattern: Caching proxies with security plug-in
(Click a node to get a detailed explanation.)
Design Last Updated: 02-2004
High Availability: Runtime pattern: Caching proxies with security plug-in

Click for more information Click for more information Click for more information Click for more information Clink for more information Click for more information CLick for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information Click for more information

This configuration is well suited for e-business environments demanding highly scalable and uninterrupted access to secure Web applications.

Benefits

  • Replicated caching proxy nodes adds scalability, increased bandwidth, and failover capabilities to the caching and security configuration.
  • High availability load balancer nodes provide automatic back-up and recovery from failures within both the load balancer nodes and the caching proxy nodes. In addition, scalability support is enhanced by being to easily add and remove additional caching proxy nodes as network traffic demands.

Limitations

  • Additional hardware is needed for caching proxy and load balancer nodes.


Next, review product mappings.

c