The Web server tier

 < Day Day Up > 



Clustering the Web server tier

The Web server tier provides several functions including serving static content, caching, and load balancing for the application server tier. This section describes how to use clustering to achieve continuous availability in the Web tier.

The key element to achieving continuous availability during application upgrades is virtualization of the tiers. Here virtualization means that individual servers are isolated from the requesters of service provided by this tier. The Web server tier is virtualized by allowing access only through a load balancer. For the Web server tier, the WebSphere Application Server Edge component Dispatcher acts as the load balancer as depicted in Figure 3-2. Dispatcher distributes all Web server requests to a cluster of Web servers. The Web site is known by the cluster IP address of Dispatcher.

click to expand
Figure 3-2: Using Dispatcher to cluster the Web server tier

To avoid a single point of failure, the cluster must have at least two Web server nodes, where the term node denotes a physical machine. This provides hardware redundancy and process redundancy. The load balancer also provides the following functionality essential to continuous availability at the Web server tier.

  • Detects if the HTTP server process fails to respond. If the process fails to respond to a request, the load balancer marks the server down and optionally retries the request with another server. Failure of a process is transparent to the requester.

  • Enables a system administrator to dynamically increase or decrease capacity by adding or removing Web server nodes, transparently to users.

Because the load balancer, or Dispatcher in this case, can also be a single point of failure, this component needs to be deployed in pairs. The backup dispatcher can be configured in standby mode, constantly polling the "heartbeat" of the primary dispatcher. If there is no response to a poll, the backup dispatcher takes over. There is also a mutual mode where each dispatcher node load balances for a different cluster. If either dispatcher process fails, the available dispatcher takes over load balancing for its respective cluster. This is especially useful for larger Web sites with multiple clusters.

WebSphere Application Server Network Deployment, Version 5 includes enhanced Edge load balancing components, which are also available in the WebSphere Edge components. In addition to the scenario in Figure 3-2, Dispatcher can be deployed with the Content Based Routing (CBR) and Site Selector components for more sophisticated load-balancing scenarios.

The load balancing algorithms available using these components are:

  • Random and round robin, as provided by Dispatcher. This load-balancing algorithm gives equal weight to all servers in a cluster.

  • Intelligent rules based algorithms based on weighting of active connections, CPU for each load balanced server, new connections, memory, port-specific (input from advisors listening on the port) and/or system metric (using the metric server component running on each load balanced server).

  • Content based routing based on the content of the incoming user request

For more information on Edge components shipped with WebSphere refer to www.ibm.com/software/webservers/appserv/doc/v50/ec/infocenter/index.html.

Maintenance

To keep maintenance simple, static content can be deployed with the application enterprise archive files (EARs) and edge side caching (ESI) features in the Web server, in the Edge component Caching Proxy, or an external service provider, such as Akamai. Maintenance is simple because static content is deployed in the same step as the application and the association between static and dynamic content is preserved.

To deploy static content on the Web servers, either:

  1. Keep it simple by copying the new content to the document directory of the Web server replacing the old content.

  2. When both the old content and new content must be available concurrently, and each version is referred to by a different version of the dynamic content in the application server tier, the new content must be deployed with different names than the old files being replaced. One way to achieve this is to have a new subdirectory structure. References in both the static and dynamic content must be updated to reflect the new location. For the dynamic content either:

    • Use a script to update the JSPs or XSLT templates during build.

    • Use property files to map to resources in JSPs or XSLT templates to their appropriate version or location of the static content.



 < Day Day Up > 



High-Volume Web Sites Team - More about High-Volume Web Sites
High-Volume Web Sites Team - More about High-Volume Web Sites
ISBN: N/A
EAN: N/A
Year: 2003
Pages: 117

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net