Non-Functional Requirements::High Performance: Runtime patterns

Basic Runtime pattern
If you've already reviewed the Non-Functional Requirements::High Availability application emphasis, you may recognize the figure below. It is, in fact, the "High Availability: Runtime pattern: Variation 2: Load balancer hot standby". It is used here as the base application pattern for the High Performance patterns. ( The figure is based on the Basic 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 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 Performance configuration.

High Performance: Basic Runtime pattern
(Click a node to get a detailed explanation.)
Design Last Updated: 12-2002

Variation 1: Redirectors
For this variation, at least two additional nodes are needed:

• Two or more Web server redirector nodes

This pattern splits the Web Application Server node into two functional nodes by separating HTTP server function from the application server function.

High Performance: Runtime pattern: Redirectors
(Click a node to get a detailed explanation.)
Design Last Updated: 12-2002

The Web server redirector node decides whether the request is being served by the local HTTP server or forwarded to the application server nodes. This pattern moves the application server nodes behind the domain firewall adding further security.

The Web server redirector node is capable of performing workload management for the requests targeted at the application server nodes in the secure network. In addition, it can perform a port change to match the ports on which the application server nodes are listening. It also takes care of cookie based server affinity.

Benefits
This variation has the following additional benefits:

• Each node type (Redirector and Application Server) can be configured to the specific tasks
• A domain firewall between the two node types adds additional security
• More flexibility in number of nodes of each type
• Flexibility to not apply security on certain static content

Disadvantages
This variation has the following disadvantages:

• Many configuration changes on the Application Server node call for a redeployment of the plugin-cfg.xml file to all Web server redirector nodes
• The configuration of the domain firewall requires additional skills. especially if NAT is implemented, IIOP traffic must be tunneled.

Variation 2: Separation
The Runtime pattern we see here further separates the functionality to distinct Application Server nodes. The presentation tasks (Web modules) are run on the Presentation Server behind the domain firewall. The application tasks (EJB modules) run on the Application Server nodes behind the domain firewall in the secure network.

High Performance: Runtime pattern: Separation
(Click a node to get a detailed explanation.)
Design Last Updated: 12-2002

With this topology you would create two (WebSphere) server groups in order to execute the presentation and the application modules on different nodes. One would have clones on the Presentation Server nodes in the secure network running the Web modules. The other one would have clones on the Application Server nodes in the secure network running the EJB modules. In this manner, more repetitive and mundane presentation tasks can be offloaded from the application servers freeing more processing power for business application workload.

Benefits
This variation has the following additional advantages:

• Flexibility to choose the protocol between the two application server nodes (HTTP, HTTPS, RMI, RMI/IIOP)
• Further separation of presentation and application functionality

Disadvantages
This variation has the following disadvantages:

• Configuration changes on the Presentation Server node may require a manual update of the Web server redirector nodes
• More planning for application deployment is required

Variation 3: Caching proxy
A caching proxy node performs a similar function as redirector node in that it receives the initial HTTP request from the Internet. It can serve client requests from its cache, or redirect the request to back-end application servers behind a firewall. The advantage of a caching proxy node is that it can cache both static and dynamic pages in its local cache, thus reducing the traffic to and load on back-end Web application servers. The caching proxy can be configured to proxy one or more Web application server domains. In addition, the caching proxy can be configured to cache not only static pages served by the back-end servers, but also dynamic pages created by the back-end Web application servers.

Variation 3a: Single Caching proxy
In this variation, the Web application server is moved behind the Domain Firewall and a single caching proxy node is placed in the DMZ. This configuration further isolates and protects the Web application server from the outside world by locating it within the internal network.

High Performance: Runtime pattern: Single caching proxy
(Click a node to get a detailed explanation.)
Design Last Updated: 02-2004

This Runtime pattern represents an initial step in providing authentication and authorization functions for the site. In addition, performance has potentially been enhanced due to the introduction of the caching proxy machine.

Benefits
This variation offers the following benefits:

• The caching proxy reduces response times tor static and dynamic content.
• Serving static and dynamic content from the caching proxy (when appropriate) reduces the load on the back-end Web application servers.

Limitations
This variation has the following limitations:

• The caching proxy node is a single point of failure.
• Depending on the amount of traffic to be proxied, the caching proxy node could become a bottleneck.

Variation 3b: Caching proxies
This variation introduces a layer of caching proxy server nodes between the load balancer nodes and the Web application server nodes. Because a pure caching proxy node cannot balance requests to multiple (identical) proxy target nodes, a second layer of load balancer nodes is introduced as well. The second layer of load balancing can be configured on the two existing load balancer nodes. For This Runtime pattern variation, you need at least two nodes in addition to those in the Basic Runtime pattern above:

• Two or more additional caching proxy server nodes

High Performance: Runtime pattern: Caching proxy
(Click a node to get a detailed explanation.)
Design Last Updated: 02-2004

The first load balancer node passes the request for the information to the caching proxy nodes. The caching proxy determines if the requested page is in its cache. If the requested information is in the cache, it is served from there. If it is not in the cache, the request is passed on by the caching proxy to the second load balancer node which forwards the request to the back-end servers.

To minimize the overlap of duplicated content in the local cache of each caching proxy machine, remote cache access (RCA) can be implemented in each caching proxy. RCA allows each proxy to share the contents of its cache with the other proxy servers. This results in bandwidth savings because objects are not fetched multiple times, and the larger combined logical cache yields a higher hit rate. The challenge to efficiently use multiple caching proxy nodes is to have high speed connections between them or, in case of disk cache, a high performance shared file system.

Benefits
This variation offers the following benefits:

• High availability is provided for all node types
• The caching proxy layer reduces response times for static, cachable content
• It reduces the load on the Web server redirector nodes
• Supports SSL encryption between client and Proxy Sever node as well as Proxy Server node to content server node

Limitations
This variation has the following limitation:

• To harvest the benefit of cache arrays, high speed connections or a high performance shared file system between the caching proxy server nodes is necessary

Variation 4: Caching proxy with security plug-ing
This variation introduces security services in the DMZ in the form of authentication and authorization checking performed by a plug-in component added to the caching proxy node. Security functions are implemented in front of all content server nodes to provide security services at the edge of your network. This reduces the amount of security processing load on the application server nodes, freeing resources to perform application processing work.

Security services in the form of a plug-in to a caching proxy node adds:

• Robust authentication: only authenticated traffic is allowed into the trusted internal network.
• Robust authorization: only authorized traffic is allowed into the internal network.
• Flexibility of authentication and authorization rules: authentication and authorization rules can be easily changed without affecting the back-end application space.
• Mix-and-match authentication: authenticating rules can be defined based on where a user is authenticating from, so that stronger authentication means can be required for users coming from the Internet, in contrast to weaker authentication means required by users within the internal network.
• Cost effectiveness: authentication/logging software and hardware is located at the proxy server only. Heavily loaded back-end application servers are not required to implement security functionality or to increase their processing capacity to do so.

Variation 4a: Single Caching proxy with security plug-in

High Performance: Runtime pattern: Single caching proxy security plug-in
(Click a node to get a detailed explanation.)
Design Last Updated: 01-2004

For this variation, you require the nodes shown in the High Performance: Basic Runtime pattern and at least two additional nodes:

• One caching proxy node with security plug-in software added to the proxy. If an optional load balancer node is not present in the configuration, then the caching proxy node would be attached to each back-end Web application server node through the Domain firewall.
• A directory and security services node if one has not been implemented previously
• Optionally, one or more additional Web application server nodes (if you want to proxy multiple back-end servers)
• Optionally, a load balancer node to balance client requests received from the caching proxy node amongst multiple Web application server nodes. If WebSphere Application Server is running on the application server nodes, then a separate load balancer node is not required since WebSphere Application Server can balance requests within a cluster.

Benefits
This variation offers the following benefits:

• Adding the authentication and authorization functions in the form of a plug-in to the caching proxy eliminates much if not all the security processing power required by back-end application servers.
• Removing security processing from back-end servers and moving it to machines running in the DMZ further isolates the back-end servers from potential security breaches.
• Potentially allows for single sign-on support for all applications within the secure domain.

Limitations
This variation has the following limitation:

• The caching proxy node is a single point of failure.
• Depending on the amount of traffic to be proxied, and the amount of security processing required to perform enterprise security policies, the caching proxy node could become a bottleneck.

Variation 4b: 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.

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

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.