|
|
|
|
| |
Planning WebLogic Server Clusters
Overview
This document describes common issues to consider before deploying one or more WebLogic Server clusters. You should read this document in conjunction with the Overview of WebLogic Server Clustering and Administering WebLogic Clusters sections to become familiar with how WebLogic Server clusters operate.
This document presents two recommended cluster configurations applicable to WebLogic Server versions 4.5 and 5.1. You should examine each recommended configuration to determine which architecture best meets the needs of your web application.
Capacity planning reminder
This document focuses on planning the network topology of your clustered system. It describes how to organize one or more WebLogic Server clusters in relation to load balancers, firewalls, and Web Servers, to fully utilize load balancing and failover features for your web application. Although this kind of planning directly influences the capacity of your cluster system, this document does not focus on traditional capacity planning topics. After determining the layout of your cluster system, you should perform rigorous testing using software such as LoadRunner to simulate heavy client usage. By testing your system under heavy loads, you can determine where you may need to add servers and/or server hardware to support real-world client loads.
Definition of terms
This document uses the following terms to describe the parts of a clustered system.
Web application "tiers"
A web application is divided into several "tiers" that describe the logical services the application provides. Keep in mind that not all web applications are alike, and therefore your application may not utilize all of the tiers described below. Also keep in mind that the tiers represent logical divisions of an application's services, and not necessarily physical divisions between hardware or software components. In some cases, a single machine running a single WebLogic Server instance can provide all of the tiers described below.
Web tier
The Web tier provides static content (for example, simple HTML pages) to clients of a web application. The web tier is generally the first point of contact between external clients and the web application. A simple web application may have a web tier that consists of one or more machines running WebLogic Express, Apache, Netscape Enterprise Server, or Microsoft Internet Information Server.
Presentation tier
The presentation tier provides dynamic content (for example, servlets or Java Server Pages) to clients of a web application. A cluster of WebLogic Server instances that hosts servlets and/or JSPs comprises the presentation tier of a web application. If the cluster also serves static HTML pages for your application, it encompasses both the web tier and the presentation tier.
Object tier
The object tier provides Java objects (for example, Enterprise JavaBeans or RMI classes) and their associated business logic to a web application. A WebLogic Server cluster that hosts EJBs provides an object tier.
De-Militarized Zone (DMZ)
The De-Militarized Zone (DMZ) is a logical collection of hardware and services that is made available to outside, untrusted sources. In most web applications a bank of web servers resides in the DMZ, to allow browser-based clients access to static content.
The DMZ may provide security against outside attacks to hardware and software. However, because the DMZ is available to untrusted sources, it is less secure than an internal system. For example, internal systems may be protected by a firewall that denies all outside access. The DMZ may be protected by a firewall that hides access to individual machines, applications, or port numbers, but it still permits access to those services from untrusted clients.
Load balancer
In this document, the term load balancer describes any technology that distributes client connection requests to one or more distinct IP addresses. For example, a simple web application may use the DNS round-robin algorithm as a load balancer. Larger applications generally use hardware-based load balancing solutions such as those from Alteon WebSystems, which may also provide firewall-like security capabilities.
Proxy plug-in
A proxy plug-in is a WebLogic Server extension to Apache, Netscape Enterprise Server, or Microsoft Internet Information Server that accesses clustered servlets provided by a WebLogic Server cluster. The proxy plug-in contains the load balancing logic for accessing servlets and JSPs in a WebLogic Server cluster. Proxy plug-ins also contain the logic for accessing the replica of a client's session state if the primary WebLogic Server hosting their session state fails. See How Servlet Clustering Works for more information.
Planning by Dividing Application Tiers
The simplest possible cluster topology uses a single cluster of WebLogic Server instances to provide all tiers of the web application: web tier, presentation tier, and object tier. In this "combined-tier" cluster, untrusted connections (HTTP and Java clients) have a single interface to the WebLogic Server cluster, as shown below.
Although the above configuration is simplified, it is not an invalid cluster architecture. Web applications that have limited needs for scaling, failover, and security can potentially use this configuration. However, this combined-tier architecture is generally not recommended due to its limitations. It is important to understand those limitations so that you can better understand how the recommended configurations overcome the limitations to provide more reliable platforms for your web application.
Limitations of "combined tier" cluster
Two key features of a clustered web application - load balancing and failover capabilities - can be introduced only at the interfaces between web application tiers. When those tiers are combined on a single hardware/software platform, as in the above example, you reduce the opportunities for introducing load balancing and failover capabilities to your system.
Combining tiers in this manner also precludes the use of HTTP session state replication for servlets and JSPs, since the architecture provides no proxy plug-in to associate clients with their primary and secondary session state replicas.
The following sections describe in detail how a "combined tier" cluster limits opportunities for load balancing, failover, and security. The two recommended cluster configurations - Recommended 2-Tier Cluster Architecture and Recommended Multi-tier Cluster Architecture - explain how to overcome these limitations by dividing logical application tiers onto separate physical layers of hardware and software.
Load balancing limitations
Combined-tier architectures provide only a single opportunity to introduce load balancing capabilities to your system: the interface between untrusted connections (HTTP and Java clients) and the WebLogic Server cluster itself. At this interface, you can use technologies such as load balancing hardware or DNS round-robin to balance client requests to multiple WebLogic Server instances. However, even these load balancing strategies have limitations when used with a combined-tier architecture.
HTTP session states
WebLogic Server versions 4.5 and 5.1 do not support HTTP session state replication when clients connect to the cluster directly via load balancing hardware. Clients that connect via a load balancer have no way to repeatedly access the WebLogic Server that hosts the client's primary session state. Instead, each connection request to the cluster may be forwarded to a different server instance, depending on the load balancing policy. This inability to associate a client with a particular server instance means that you cannot use in-memory HTTP session state replication with a combined-tier cluster. Automatic failover to secondary HTTP session states on another server is unsupported for the same reason.
Clustered objects
Combined-tier clusters provide no opportunities for load-balancing method calls to clustered EJB and RMI objects. In most cases, clustered objects are deployed on all WebLogic Server instances in the cluster. Because each object is available locally to each server, WebLogic Server optimizes method calls by always selecting the local object, rather than distributing requests to remote objects and incurring additional network overhead.
This co-location strategy is, in most cases, more efficient than load balancing each method request to a different server. However, if the processing load to individual servers becomes unbalanced, it may eventually become more efficient to submit method calls to remote objects rather than processing methods locally. This level of load balancing is not possible in a combined-tier cluster.
Failover limitations
WebLogic Server versions 4.5 and 5.1 do not support automatic HTTP session state failover services in a combined-tier cluster. If the server instance that hosts a client's session fails, the load balancing software or hardware cannot redirect subsequent client requests to the server that hosts the replica of the servlet session. To use WebLogic Server failover capabilities you must use the HttpClusterServlet or a proxy plug-in, which necessitates a 2-tier cluster architecture. See Recommended 2-Tier Cluster Architecture for more information.
More importantly, when clients connect directly to a combined-tier cluster through a firewall, the initial bootstrap server becomes a single point of failure for the entire client connection. If the client's bootstrap server fails, the client cannot automatically failover to servers hosting the replicas of the servlet state or clustered objects. Instead, the client must reconnect to the cluster, begin a new servlet session and obtain new clustered objects. This limitation is again addressed with the Recommended 2-Tier Cluster Architecture.
Security limitations
Combined-tier clusters impose severe restrictions on the types of firewalls you can place between clients and the cluster. In WebLogic Server versions 4.5 and 5.1, these limitations occur due to the nature of socket communication through a firewall.
As described in Server Communication in a Cluster, direct client connections to a WebLogic Server cluster via a firewall utilize a single socket, and they develop an association with the first server instance to which they connect. This association occurs any time there is server's public IP address and internal IP address differ, as is the case with firewalls that use address translation or IP masquerading policies.
The association between the client and server introduces a single point of failure for the client's connection to the cluster. If the point-of-contact server fails (or if the connection between the server and client fails), the client does not failover to an available server. Similarly, load balancing for the client connection does not occur, since all connections to the cluster are first routed through the point-of-contact server.
Addressing security limitations
The security limitations described above and in Load balancing limitations are caused primarily by having direct client connections to a combined-tier WebLogic Server version 4.5 or 5.1 cluster. To address the security limitations, the Recommended 2-Tier Cluster Architecture separates clients from the WebLogic Server cluster by a separate physical layer of hardware and software. This separation allows you to implement more flexible firewall policies for client connections without restricting load balancing and failover capabilities.
Recommended 2-Tier Cluster Architecture
The basic recommended configuration for WebLogic Server divides the web and presentation tiers of the web application into separate physical layers of hardware and software. Splitting these tiers provides increased opportunities for introducing load balancing, failover, and security features. It also negates many of the load balancing and firewall limitations exhibited by WebLogic Server 4.5 and 5.1 when configured as a combined-tier cluster.
Physical hardware and software layers
The recommended 2-tier configuration contains two physical layers of hardware and software.
Web layer
The basic recommended configuration utilizes a layer of hardware and software dedicated to the task of providing the application's web tier. This physical web layer can consist of one or more machines that host any combination of the following applications:
Regardless of which web server software you select, keep in mind that the physical tier of web servers should provide only static web pages. Dynamic content - servlets and JSPs - are proxied via the proxy plug-in or HttpClusterServlet to a WebLogic Server cluster that hosts servlets and JSPs for the presentation tier.
Servlet/Object layer
The recommended 2-tier cluster architecture hosts the presentation and object tiers on a cluster of WebLogic Server instances. This cluster can be deployed either on a multihomed machine or on multiple separate machines. However, you should generally use multiple machines where possible to avoid a single point of failure.
The Servlet/Object layer differs from the combined-tier cluster described in Planning by Dividing Application Tiers in that it does not provide static HTTP content to application clients. By removing static web server duties and disallowing direct connections from untrusted sources to the cluster itself, the Servlet/Object layer provides improved capabilities for load balancing, failover, and security.
Benefits of basic configuration
The 2-tier cluster architecture provides several key benefits over a combined-tier cluster:
The sections below describe these benefits in more detail.
Load balancing and failover for servlets
Splitting the web and presentation tiers provides the opportunity to introduce load balancing and failover for clustered servlets. The proxy plug-ins or HttpClusterServlet maintain a list of all WebLogic Server instances that host clustered servlets for the web application. As clients connect to a web server and request a servlet page, the plug-in or HttpClusterServlet uses a round-robin algorithm to load balance requests to available servers in the presentation/object layer.
The proxy plug-in or HttpClusterServlet also contains the logic required to redirect the client's request to the replicated servlet state if the primary WebLogic Server instance fails. The load balancing and failover for servlets occur completely transparently to the client application.
How Servlet Clustering Works explains the process of replicating servlet sessions states in more detail.
Improved security options
Because clients do not directly connect to the WebLogic Server cluster through a firewall, the 2-tier cluster architecture enables more flexible firewall policies for your web application. Between untrusted clients and the layer of static web servers, you are free to use NAT or IP masquerading restrictions as required. As long as the client can access one of the available web servers, the proxy plug-in can forward the client's request appropriately.
Limitations of basic configuration
Because the 2-tier cluster configuration still combines the presentation and object tiers onto a single layer of hardware and software, individual method calls to clustered objects are generally not load balanced across multiple WebLogic Server instances. (See Load balancing limitations for more information.)
Again, this co-location optimization is generally more efficient than load balancing object calls across the network. For situations where your web application requires load balancing to clustered object calls, consider using the recommended configuration described under Recommended Multi-tier Cluster Architecture.
FIrewall limitations
A firewall can be configured either in front of or behind the layer of web servers to place the web servers in the DMZ. If you place the firewall behind the web servers, you must ensure that proxy plug-ins can freely access members of the WebLogic Server cluster.
Recommended Multi-tier Cluster Architecture
The multi-tier cluster architecture is similar to the basic recommended architecture, in that it also separates the web and presentation tiers onto physical hardware/software layers. It differs insofar as it further splits the presentation and object tiers onto separate WebLogic Server clusters. The multi-tier cluster is recommended for web applications that:
The following figure depicts the recommended multi-tier architecture.
Physical hardware and software layers
The advanced recommended configuration contains three physical layers of hardware and software, which correspond to the logical tiers of the application itself: the web tier, presentation tier, and object tier.
Web layer
The web layer in the multi-tier architecture is the same as that of the 2-tier architecture. See Recommended 2-Tier Cluster Architecture for more information.
Presentation layer
The presentation layer consists of a cluster of WebLogic Server instances dedicated to hosting servlets and JSPs. This servlet cluster does not host clustered objects, and it does not serve static web pages to direct client connections. Instead, servlets in the presentation tier cluster act as clients for clustered objects, which reside on an separate WebLogic Server cluster in the Object layer.
Object layer
The object layer consists of a cluster of WebLogic Server instances that hosts only clustered objects - EJBs and RMI objects as necessary for the web application. By hosting the object tier on a dedicated cluster, you lose the default co-location optimization for accessing clustered objects described in How Object Clustering Works. However, you gain the ability to load balance on each method call to certain clustered objects, as described below.
Benefits of multi-tier architecture
The multi-tier configuration provides two general benefits for specialized web applications:
Load balancing for clustered object calls
WebLogic Server's co-location optimization for clustered objects relies on having a clustered object (the EJB or RMI class) hosted on the same server instance as the replica-aware stub that calls the object.
The net effect of isolating the object tier is that no client (HTTP client, Java client, or servlet) ever acquires a replica-aware stub on the same server that hosts the clustered object. Because of this, WebLogic Server cannot use its co-location optimization, and servlet calls to clustered objects are automatically load balanced according to the logic contained in the replica-aware stub. The following figure depicts a client accessing an clustered EJB instance in the multi-tier architecture.
Tracing the path of the client connection, you can see the implication of splitting each application onto separate hardware/software layers:
The servlet looks up the entity bean on the WebLogic Server cluster that hosts clustered objects. The servlet obtains a replica-aware stub for the entity bean, which lists the addresses of all servers that host the bean, as well as the load balancing logic for accessing the bean's methods.
In this example, if the same WebLogic Server cluster hosted both servlets and EJBs (as in the recommended 2-tier architecture), WebLogic Server would not load balance method calls to the EJB. Instead, the servlet would simply invoke methods on the EJB instance hosted on the local server. Using the local EJB instance is more efficient than making remote method calls to an EJB on another server. However, the multi-tier architecture enables remote EJB access for applications that require load balancing for EJB method calls.
Improved Server Load Balancing
Separating the presentation and object tiers onto separate clusters provides more options for distributing the load of the web application. For example, if the application accesses HTTP and servlet content more often than EJB content, you can use a large number of WebLogic Server instances in the presentation tier cluster to concentrate access to a smaller number of servers hosting EJBs.
Higher availability
The multi-tier cluster architecture also provides higher availability for the web application. The architecture uses an entirely separate WebLogic Server cluster for the object tier, and therefore has fewer points of failure than the 2-tier architecture.
Limitations of multi-tier architecture
Because the advanced configuration cannot optimize object calls using the co-location strategy, the web application incurs network overhead for all method calls to clustered objects. This overhead may be acceptable, however, for certain web applications.
For example, if your web clients make heavy use of servlets and JSPs but access a relatively small set of clustered objects, the multi-tier architecture enables you to concentrate the load of servlets and object appropriately. You may configure a servlet cluster of 10 WebLogic Server instances and an object cluster of 3 WebLogic Server instances, while still fully utilizing each server's processing power.
Firewall restrictions
You cannot place a firewall between the servlet cluster and object cluster in a multi-tier architecture. Placing a firewall between these tiers forces each servlet to use a single WebLogic Server in the object cluster (and a single socket connection) for accessing clustered EJBs. This destroys the load balancing capabilities for clustered objects, which is the primary feature the multi-tier architecture provides.
Configuration notes for multi-tier architecture
Because the multi-tier architecture provides load balancing for clustered object calls, the system generally utilizes more IP sockets than a two-tier or combined-tier architecture. In particular, during peak socket usage, each WebLogic Server in the cluster that hosts servlets and JSPs may use:
For example, in the figure shown under Recommended Multi-tier Cluster Architecture, each server in the servlet/JSP cluster could open a maximum of five sockets. (Each server in the EJB cluster could open a maximum of 3 sockets, assuming the cluster hosts only clustered EJBs that are deployed homogeneously).
If you use a pure-Java sockets implementation with the multi-tier architecture, ensure that you configure enough socket reader threads to accommodate the maximum potential socket usage. See Configuring reader threads for Java socket implementations for more details.
Improving Security in Recommended Cluster Architectures
The boundaries between physical hardware/software layers in the recommended configurations provide potential points for defining your web application's De-Militarized Zone (DMZ). However, not all boundaries can support a physical firewall, and certain boundaries can support only a subset of typical firewall policies.
This sections that follow describe several common ways of defining your DMZ to create varying levels of application security.
Basic firewall for untrusted connections
The basic firewall configuration uses a single firewall between untrusted clients and the web server layer, and it can be used with either the 2-tier or multi-tier cluster architectures.
In the above configuration, the single firewall can use any combination of policies (application-level restrictions, NAT, IP masquerading) to filter access to three HTTP servers. The most important role for the firewall is to deny direct access to any other servers in the system. In other words, the servlet layer, the object layer, and the database itself must not be accessible from untrusted clients.
Note that you can place the physical firewall either in front of or behind the web servers in the DMZ. Placing the firewall in front of the web servers simplifies your firewall policies, because you need only permit access to the web servers and deny access to all other systems. If you place the firewall between the three web servers and the WebLogic Server cluster, you must ensure that the proxy plug-ins can freely connect to each server in the cluster.
DMZ with basic firewall configurations
By denying access to all but the web server layer, the basic firewall configuration creates a small-footprint DMZ that includes only three web servers. However, a more conservative DMZ definition might take into account the possibility that a malicious client may gain access to servers hosting the presentation and object tiers.
For example, assume that a hacker gains access to one of the machines hosting a web server. Depending on the level of access, the hacker may then be able to gain information about the proxied servers that the web server accesses for dynamic content.
If you choose to define your DMZ more conservatively, you can place additional firewalls using the information in Additional security for shared databases.
Combining firewall with load balancer
If you use load balancing hardware with a recommended cluster configuration, you must decide how to deploy the hardware in relationship to the basic firewall. Although many hardware solutions provide security features in addition to load balancing services, most sites rely on a firewall as the first line of defense for their web applications. In general, firewalls provide the most well-tested and familiar security solution for restricting web traffic, and should be used in front of load-balancing hardware.
The above setup places the load balancer within the DMZ along with the web tier. Using a firewall in this configuration can simplify security policy administration, because the firewall need only limit access to the load balancer. This setup can also simplify administration for sites that support internal clients to the web application, as described below.
Expanding the firewall for internal clients
If you support internal clients that require direct access your web application (for example, remote machines that run proprietary Java applications) you can expand the basic firewall configuration to allow restricted access to the presentation tier. The way in which you expand access to the application depends on whether you treat the remote clients as trusted or untrusted connections.
If you use a Virtual Private Network (VPN) to support remote clients, the clients may be treated as trusted connections and can connect directly to the presentation tier going through a firewall. This configuration is shown below.
If you do not use a VPN, all connections to the web application (even those from remote sites using proprietary client applications) should be treated as untrusted connections. In this case, you can modify the firewall policy to permit application level connections to WebLogic Servers hosting the presentation tier, as shown below.
Additional security for shared databases
If you use a single database that supports both internal data and data for externally-available web applications, you should consider placing a hard boundary between the object layer that accesses your database. Doing so simply reinforces the DMZ boundaries described in Basic firewall for untrusted connections by adding an additional firewall.
DMZ with 2-firewall configuration
The following configuration places an additional firewall in front of a database server that is shared by the web application and internal (trusted) clients. This configuration provides additional security in the unlikely event that the first firewall is breached, and a hacker ultimately gains access to servers hosting the object tier. Note that this circumstance should be extremely unlikely in a production environment - your site should have the capability to detect and stop a malicious break-in long before a hacker gains access to machines in the object layer.
In the above configuration, the boundary between the object tier and the database is hardened using an additional firewall. This firewall maintains a strict application-level policy that denies access to all connections except JDBC connections from WebLogic Servers hosting the object tier.
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|