Hardware Configurations for WebSphere Application Server Production Environments Peter Van Sickel Consulting I/T Specialist IBM Pittsburgh Lab

Introduction This article describes the most common production hardware configurations and provides the reasons for choosing each one. It begins with a single machine configuration as a straw man and then proceeds with additional configurations that have higher fault tolerance, horizontal scaling, and a separation of Web and enterprise bean servers.

This article shows a step-by-step progression starting from something simple and ending up with various hardware configurations that are appropriate for production use. You should gain a clear understanding of the motivations for each step on the road to relatively complex configurations.

This article synthesizes a number of sources that focus on specific aspects of production configurations, such as fault tolerance, security, caching, and scalability. If you are interested in an in-depth discussion of these topics, you can find the sources listed in the "References" section at the end of this article.

This article focuses on configurations that are accessed from the Internet. However, keep in mind that the same principles tend to apply to access from intranet users. For example, production environments are often protected from internal systems just as they are protected from Internet access. In order to keep the diagrams manageable, they will not usually depict the intranet related aspects of a configuration.

This article does not illustrate the details of network infrastructure. The usual rule of thumb for production networks is that there are at least two paths to everything, so all switches, routers, and firewalls are replicated. For an even higher level of fault tolerance there would be three paths to everything.

Also, this article does not explain how to set up each configuration, and instead cites the appropriate references for that information (links for these references are listed at the end of the article.) It does, however, point out the salient features of each configuration and notes particularly important details.

Motivations for Complexity In any engineered system, simplicity tends to be preferred over complexity. You will see as the hardware configurations presented in this paper move from the very simple to the very complicated, that each added level of complexity addresses a deficiency that is present in the simpler configuration. As the hardware configurations become more complicated, they become also more expensive to implement and administer. Of course, the law of diminishing returns comes into play at some point. Each organization or

business enterprise needs to make economic decisions between complexity and cost. The primary motivations for increasing the complexity are:

�� Increased fault tolerance

�� Increased security

�� Increased load handling capability (scaling-up)

Simple configurations Just to get started, you can put all of the system applications, the HTTP server, the application server and the database server on one machine with no consideration for network security (no firewalls). Figure 1 shows this configuration using IBM HTTP Server, WebSphere Application Server and a DB2 database server. This is a common configuration in a development setting, and might be a possible production configuration for a low volume intranet application.

Figure 1: Single machine with IBM HTTP Server, WebSphere Application Server, and DB2

There are obvious problems that make this configuration inappropriate for Internet applications in a production setting:

��There is no network security to protect the server machine from attack.

��There is no fault tolerance. If something happens to this single machine, then everything stops.

��There is no opportunity for handling increases in request volume. (At best you can add CPU and memory to the machine and hope there are no bottlenecks.)

�� It is very likely that the HTTP server, application server, and database server processes will be competing for CPU cycles and real memory, and the task scheduler will be overwhelmed as it attempts to share the CPU among many threads. (You can use vmstat on AIX� or mpstat on Solaris to get a feel for CPU and paging activity.)

To first address the issue of resource (CPU and memory) contention, you can set up a two-machine configuration with the database server on its own machine, as shown in Figure 2. Database servers are resource intensive applications, so it is very easy to justify this.

Figure 2: Separate database server machine

Putting the database server is on a separate machine prepares the way for applying any number of “hardening” techniques to meet availability requirements for this server, which are briefly described later in this paper. The next obvious shortcoming of this simple configuration is the lack of a network firewall to protect the server machines from attacks on the ports that they might be using to provide services not intended for access by outside users. In other words, you want to limit outside access to only the HTTP server ports (80 and 443). Without a firewall, you cannot use this configuration for an Internet application. Figure 3 shows the addition of firewalls to the configuration.

Figure 3: Adding a firewall for network security

You would configure the firewalls to only allow HTTP traffic on port 80 and HTTPS traffic on port 443 to the IP address of the machine with the HTTP and application server.

There are still obvious shortcomings with the configuration shown in Figure 3. For one thing, only one firewall separates the enterprise servers from the outside world. For better network security, most sites use a dual configuration of firewalls to establish what is referred to as a DMZ (as in demilitarized zone). Machines with very limited, well understood, and logged services are placed in the DMZ, and the firewalls strictly limit traffic into and out of the DMZ.

In this configuration, shown in Figure 4, there are good reasons to put the HTTP and application server on separate machines. HTTP servers in general (and Apache-based HTTP servers such as IBM HTTP Server, in particular) have limited capabilities. For example, Apache-based HTTP servers do not support the ability to run Java programs. Because it is well understood how to protect them from attack, they can stay in the DMZ. But, putting something as complicated as an application server in the DMZ surely defeats the purpose of the DMZ. If the outside firewall were compromised, it would expose business logic and potentially confidential state information to attack. In addition, an application server obviously includes a JVM, which in turn might be used to assist an attacker in further compromising the site. Finally, separating the HTTP server and the application server into two machines alleviates resource contention between the two sets of processes.

At this point, the sample configuration has all the basic production components in place, but there are still improvements you can make to get to a production-worthy configuration.

Figure 4: Using 2 firewalls to set up a "DMZ"

The second firewall (FW2) in this DMZ configuration needs to allow traffic to pass between the WebSphere Application Server plug-in in the HTTP server and the Web container services (servlet engine) in the WebSphere Application Server. As of Version 4.0, WebSphere Application Server's HTTP server plug-in uses HTTP or HTTPS as the network protocol. The ports used by the Web container service of each application server are configurable. For the first application server in the domain, they default to 9080 for HTTP and 9443 for HTTPS, and increment from there. You will need to open Web container service ports in the second firewall for each application server that is running on the WebSphere Application Server machine.

The minimum hardware configuration recommended for production

The preceding section incrementally presented the basic components for a minimum production configuration. This configuration, represented by Figure 4, has the following shortcomings:

��There is a single point of failure (SPOF) at each of the HTTP, application and database servers.

�� It is unrealistic to expect single machines to handle the usual load from Internet applications.

You will need to add other system components to perform services such as a user registry (LDAP), edge services, and single sign-on.

The next section addresses the single points of failure at the IBM HTTP Server WebSphere Application Server, and (DB2 (It will not address the fault tolerance of firewalls and other network components.)

WebSphere Application Server implements the concept of server groups. Each server in a server group provides identical services such as running the same enterprise applications. Each server in a server group is identified in the HTTP server plug-in configuration file, plugin-cfg.xml. The HTTP server plug-in routes requests for services associated with a server group to any of the servers in the group. (The server

selection policy used by the HTTP server plug-in is something like round-robin, but session affinity is supported., Depending on which version of WebSphere Application Server you use, the specific load balancing behavior of the HTTP server plug-in will vary.)

With this understanding, you can create a server group and add an application server machine to the basic configuration that will run a clone of the original application server on the first machine. The HTTP plug-in will now send requests to both machines. This configuration, shown in Figure 5, eliminates the single point of failure at the application server and facilitates the handling of additional request volume at the application server.

Figure 5: Adding a "server group" eliminates SPOF at the application server

Occasionally the question arises regarding whether or not a WebSphere Application Server machine should be set up in a “highly available” configuration, that is, with an application server configured on a hot backup machine ready for take-over should the primary server fail. Given the built-in support for server groups in WebSphere, there is no reason to put an application server machine in an HA configuration. Additional machines should be configured as members of a server group available to handle incoming requests. This is simpler to configure and administer than an HA configuration and makes more efficient use of available hardware.

To address the single point of failure at the HTTP server an IP sprayer is introduced in front of the HTTP server. An IP sprayer is a device that accepts IP packets associated with a given request and forwards them on to a target server that is a member of a cluster of servers capable of handling the request. The IP sprayer will load balance a stream of requests across all of the servers in the cluster and avoid sending requests to servers that are out of operation. The WebSphere Edge Server product suite includes eNetwork Dispatcher that you can use as an IP sprayer. There are several other IP load balancers, produced by other vendors that you could use instead. Figure 6 shows the addition of eNetwork Dispatcher to the minimum production configuration. In order to avoid introducing a single point of failure in the IP dispatching layer, the configuration has two eNetwork Dispatcher machines with one configured as the primary and the other as a hot backup, in a highly available (HA) configuration.

Figure 6: Adding eNetwork Dispatcher and an IHS cluster

Finally, the minimum recommended configuration needs to include the database server in an HA configuration. For most applications, if the database server fails, meaningful work can no longer be performed, therefore many organizations use a HA database configuration in production, as a matter of course. Figure 7 illustrates the addition of a second machine configured as a hot backup to make the database server highly available. (See the Tom Alcott paper referenced below for a full discussion on availability.)

Figure 7: Adding an HA configured Database gets to a minimum production configuration

For an excellent white paper on Web site availability, see Maximizing Web site Availability, by the IBM High Volume Web Site team.

Another excellent white paper that covers WebSphere Application Server-specific high-availability topics is Failover and Recovery in WebSphere Application Server Advanced Edition 4.0 by Tom Alcott, et al.

The configuration in Figure 7 is called a three-tier configuration. In the typical three-tier configuration, each application server includes the Web container and the enterprise bean

container. In other words, the Web container and the enterprise bean container are running in the same Java Virtual machine (JVM). When the Web container and the enterprise bean container are in the same JVM, significant performance optimizations can be made to improve enterprise bean response time to requests from the Web container. One of these is the NoLocalCopies optimization described in the WebSphere Application Server InfoCenter. Since the EJB method calls are within process, this optimization avoids the overhead of a network call.

A three-tier hardware configuration could possibly run two application servers on each machine: one for the Web container and one for the enterprise bean container. However, there are no compelling reasons to configure the application servers that way.

Four-tier configuration In a four-tier configuration, as shown in Figure 8, the Web module and the enterprise bean module are running in two different machines. There are two reasons for such a configuration:

�� Some sites want an added layer of security around the enterprise bean servers and the database server. This leads them to put the enterprise bean servers and the database servers behind a firewall.

�� Some sites find it easier to administer the enterprise bean servers if they are running on a large centralized server or in a centralized server farm. This makes it easier to perform application upgrades and ensure that all applications are using the correct version of the enterprise beans. Of course, these centralized servers are likely to be behind a firewall, as well.

Figure 8: Single WebSphere Server domain, four-tier configuration

The four-tier configuration introduces some additional configuration complexity when a third firewall (FW3) is added. The WebSphere admin servers on the tier-2 machines and the tier-3 machines need to communicate with each other through the firewall, and the application server Object Request Brokers (ORBs) in the tier-2 machines need to communicate with the application server ORBs in the tier-3 machines. The ORBs normally have dynamically allocated port numbers, but with a firewall between the

servers, the ports used by the ORBs need to be statically assigned, or else the firewall port filter would need to be changed every time these processes are restarted because it is very likely the dynamically assigned ORB ports would be different. For a summary of how to set the ORB port for application servers, see the next section of this article. Also, since the ORBs in tier-2 and tier-3 will communicate using RMI/IIOP, the tier-3 firewall (FW3) cannot use Network Address Translation (NAT) because IIOP cannot be routed through a NAT firewall.

Four-tier, one-domain configuration One way to set up a four-tier configuration is to use only one WebSphere Application Server domain. By definition, a single WebSphere domain requires access to a single database. The admin servers running on the server hosts in tier-2 and tier-3 need to have access to the database server holding the common WebSphere Application Server repository database. This means the firewall between tier-2 and tier-3 (FW3) must permit database traffic to pass, which might defeat the purpose of putting in the firewall in the first place - restricting access to the application database server.

In a single-domain environment, all of the WebSphere Application Server admin servers on each node in the domain need to be able to communicate. This means opening the appropriate IP addresses and ports in FW3 and making sure the ORB ports for the administration servers are statically defined. The administration server ORB port is statically assigned by the -D argument to the JVM. To do this, the administrator must add the following argument to the adminServerJvmArgs attribute in admin.config file:

-Dcom.ibm.CORBA.listenerPort=35001

If the firewall administrator does not want to allow traffic on the default ports used for the administrative server bootstrap (900) and Location Service Daemon (9000), then these ports must be changed as follows:

com.ibm.ejs.sm.adminServer.bootstrapPort=91001

com.ibm.ejs.sm.adminServer.lsdPort=91002

(Note that the port numbers used in these examples are arbitrary.)

You can find more information about setting the ORB port by searching for listener port in the WebSphere Application Server InfoCenter.

Four-tier, two-domain configuration Another way to set up a four-tier configuration is to use two WebSphere domains. One WebSphere Application Server domain is located on a database server in tier-2 and the second domain is located on a database server in the zone that contains tier-3 and tier-4. This configuration avoids the need for database access through the firewall in front of tier-3 (FW3), but it adds the need for a database server to hold the admin repository in tier-2. In addition, the JNDI provider URL for the initial context will need to reference an admin server in tier-3 when the tier-2 application servers need to find EJB resources in tier-3.

Figure 9: Four-tier, two domain configuration with HA database in tier-2 and tier-4

The two-domain configuration adds a second, highly available database server to the scene, which is a significant added expense. This database server may be used for the admin repository and persistent session state information, and it can also serve as a convenient place for a persistent cache of information pulled from the tier-4 database.

Reminder: ORB to ORB communications is done with RMI over IIOP protocols. IIOP cannot traverse a firewall that implements Network Address Translation (NAT). This means that the firewall between tier-2 and tier-3 (FW3) cannot use NAT.

Three-tier vs. four-tier configurations Whether to choose a three-tier or four-tier configuration, of course, depends on the requirements of the application and the willingness to make tradeoffs to meet those requirements. Many considerations such as cost, security, application complexity, administrative complexity, performance, and availability, come into play when deciding on such architectures.

Three-tier configurations will usually have a performance advantage because they have the Web container and the enterprise bean container in the same JVM. Requests for service by the Web container modules or the enterprise bean container modules do not include the overhead of a network invocation. The degradation in performance between in-process and network method calls can range from 10% to 40%. The wide range in performance depends on the specific application and the version of WebSphere Application Server in use. (Keep in mind that the total request processing time may be such that even a 40% reduction in the enterprise bean method call performance is not significant.)

The JDK provided with WebSphere Application Server Version 4.0 has significant improvement in inter-ORB communications, which in turn improves RMI/IIOP performance. If you are seeing degradation in performance of more than 15% when comparing JVM method calls to RMI/IIOP method calls, then contact the IBM WebSphere Performance Team in Raleigh, NC, to get assistance in determining the source of the performance degradation.

Including an LDAP Directory Server Most applications need a user registry for authentication. It has now become common in many organizations for this service to be provided by a directory service that supports the Lightweight Directory Access Protocol (LDAP). The J2EE standards require that the application server supports the use of an LDAP directory for a user registry for authentication, and WebSphere Application Server meets this requirement. Figure 10 illustrates the addition of an LDAP server to the three-tier configuration.

The WebSphere Application Servers should be configured to communicate with the LDAP directory server using an SSL based connection. (See the WebSphere InfoCenter for details on configuring SSL communication with an LDAP server.)

Figure 10: Three-tier configuration with LDAP directory server added

In this configuration, the LDAP directory server is a single point of failure. You can eliminate the SPOF by using an HA configuration for the LDAP server. This approach is conceptually the simplest and the most general since it provides a hot backup to the master LDAP server that supports both read and write operations. Figure 11 shows the HA LDAP server configuration.

Another approach to improving the availability of the LDAP server would be to use eNetwork Dispatcher and multiple LDAP servers to eliminate the LDAP server SPOF. Be aware that this will mean one master LDAP and one or more read-only replicas. This approach might be adequate for cases where the LDAP server is used mostly for read operations. Read operations can be directed to the LDAP cluster, but write operations would need to be directed to the master LDAP server. WebSphere Application Servers only need read access when using LDAP for authentication. If enterprise applications installed on the Application Server need to do write operations, then the master LDAP server would be a single point of failure. (WebSphere Portal Server is on example of an application that needs write access to the LDAP server.) If it is not critical that the master LDAP server is always available as required for write operations, then this approach is reasonable. For more details on LDAP configurations, see Failover and

Recovery in WebSphere Application Server Advanced Edition 4.0 in the References section of this article.

Yet another approach to a fault tolerant LDAP server solution is to develop a custom registry that is programmed to failover to an LDAP replica when the primary LDAP server is unavailable. The custom registry code would be able to distinguish read and write operations and direct the write operations to the master LDAP and the read operations to any of the LDAP servers in the cluster.1 The custom registry approach provides fault tolerance to applications running in the application servers, but would not provide fault tolerance to other components in the environment that need to use the LDAP server (such as a reverse proxy security server that uses the LDAP server for authentication).

Figure 11: Adding a high availability configuration to the LDAP server.

Including an Edge Server Caching Proxy The WebSphere Edge Server product suite includes a Caching Proxy server that can be used to cache static content and “slowly changing” dynamic content. (This component of Edge Server was formerly called Web Traffic Express.) Caching static content saves a round trip to the application server to build a page that holds information that hasn’t changed since a previous request. The Edge Server Caching Proxy operates on the same configuration information as the WebSphere Application Server dynamic caching facility and it can handle parameterized URLs and offers very fine-grained control for cache invalidation. The Caching Proxy is limited to caching whole pages; it cannot cache JSP fragments. For applications with static or “slowly changing” information, the performance improvements can be significant. Aside from the obvious cases of sites that serve a large amount of static content, sites that present information about sporting

1 Keys Botzum, Senior Consulting I/T Specialist IBM Software Services for WebSphere, has developed such a custom registry.

events, and weather forecasts, are examples of where a Caching Proxy server can really pay off.

There are three primary kinds of configurations of the Caching Proxy server. The configuration shown in the illustration below (Figure 12) is referred to as a reverse proxy configuration and it is local to the server side of the network. Two other configurations are called a forward proxy and transparent forward proxy. The forward proxy configurations place the Caching Proxy server on the client side of the network. The details of configuring a Caching Proxy server are beyond the scope of this article, but the physical configuration of the machines in the reverse proxy case is shown in Figure 12. In this figure, the Caching Proxy is in a clustered configuration with a Network Dispatcher in front of it to avoid a single point of failure and illustrate the possibility for scaling.

Figure 12: Three-tier configuration with an Edge Server Caching Proxy in tier-1

For more information on Edge Server see the following Redbooks: IBM WebSphere Edge Server: New Features and Functions in Version 2 (SG24-6511) and WebSphere Edge Server: Working with Web Traffic Express and Network Dispatcher (SG24-6172). For a good article on using the WebSphere Application Server dynamic caching facility and the Edge Server Caching Proxy see Livin’ on the Edge: Dynamic Web Content with IBM WebSphere Application Server and WebSphere Edge Server by Bill Hines. If you are a subscriber to WebSphere Advisor you can get Bill Hines’ article: Improve Web Application Performance, Doc # 08983, December 2001.

Including a Reverse Proxy Security Server WebSphere Application Server and IBM HTTP Server have a certain amount of built-in security. For example, you can configure the IBM HTTP Server to use SSL and it can be set up to limit access to documents based on user and group. The Application Server provides the security services required of a J2EE application server, such as method level protection of Web and EJB components and integration with LDAP directory for user authentication. For some organizations the security infrastructure provided by these servers is sufficient. But some organizations need a more comprehensive, larger scale, security infrastructure that is provided by the components in the Tivoli Access Manager

suite of products. This next section examines the typical hardware configurations required for this level of security infrastructure.

The infrastructure diagram shown in Figure 13 now includes a Reverse Proxy Security Server (RPSS), provided by the WebSeal component of Tivoli Access Manager. WebSeal has two major roles:

��Authenticate users.

��Control access to protected resources. (Resources are represented by URLs.)

WebSeal receives the users’ HTTP/HTTPS requests as though it is the actual HTTP server, initiates an authentication sequence if the user is unauthenticated, checks that the user is authorized to access the URI of the request, and if so, forwards the request to downstream HTTP or application servers.

WebSeal servers can load balance across multiple HTTP servers or other downstream servers that they are protecting. (See the WebSeal documentation for how configure WebSeal for load balancing across identical content servers.)

WebSeal can create an LTPA token that is compatible with the Application Server, therefore the WebSeal authentication can serve as a single sign-on for the site. (Single sign-on or global sign-on is a large topic that is well covered in the references provided at the end of this article.). Figure 13 depicts intranet access to the site through a WebSeal server and a firewall. For a well-secured site, all access, even internal, will be through a WebSeal server

In keeping with the desire to avoid single points of failure, you don’t want to introduce just one WebSeal server. WebSeal servers may be clustered and dispatched to by an IP sprayer, such as an Edge Server Network Dispatcher. For good performance, the IP sprayer needs to provide “stickiness” to the WebSeal server. This is best accomplished by using the SSL session ID. You can configure Network Dispatcher and other IP sprayers to provide SSL-session-ID-based dispatching to achieve session stickiness.

WebSeal servers contain the facility to load balance across multiple, downstream HTTP servers. Which means you don’t need an IP sprayer in front of the HTTP servers to which WebSeal is forwarding requests.

WebSeal supports the use of an LDAP server as the user registry for authentication. WebSeal only needs read access to the LDAP directory; therefore it does not need access to the master LDAP server. LDAP servers tend to be set up with one master read-write server and one or more read-only replicas for load balancing and fault tolerance. Some vendors provide for multiple read-write servers. Letting WebSeal servers access an LDAP server means the firewalls between tier-1 and tier-2 need to allow a connection between the WebSeal servers and a read-only replica LDAP server. Opening a path out of the DMZ directly to an LDAP server is somewhat alarming, but that alarm is mitigated by the use of a read-only LDAP replica. It is best to put the master read-write LDAP server in its own firewall secured zone, as shown in the sample configuration. To avoid a single point of failure in the replica LDAP server used by WebSeal, 2 read-only replica LDAP servers are included in the configuration. Each WebSeal server is configured to use either LDAP server, in case one of the LDAP servers should be unavailable. The

connection between the WebSeal servers and the LDAP replicas should be configured to use SSL encryption.

Tivoli Access Manager uses a Policy Server to maintain the master copy of an authorization database that holds user and group authorization information. In the case of Tivoli Access Manager, this database is a proprietary implementation. The WebSeal servers cache the authorization database to improve performance. The sample configuration shows the policy server in the tier-3 protected zone. The WebSeal servers in tier-1 use read-only replica authorization servers in tier-2 to upload the authorization database. The tier-1 firewalls need to allow a connection to the authorization servers in tier-2. The connection from the WebSeal servers and the Authorization Servers should be configured to use SSL encryption. Likewise, the connection between the replica Authorization Servers and the Policy Server that holds the master copy of the authorization database should also be configured to use SSL encryption.

Figure 13 shows an additional firewall between tier-2 and tier-3 to set up a security zone to more tightly limit access to the database server, the LDAP server, and the Access Manager Policy and Portal Manager servers. This added firewall would be typical of a production environment.

Figure 13: Adding a reverse proxy security server (WebSeal) and accompanying security infrastructure (Access Manager)

Edge Server Caching Proxy and Access Manager Some sites might want to use the Edge Server Caching Proxy and WebSeal. One way to implement this is to include the Edge Server in tier-2 as the immediate downstream server from the WebSeal servers in the tier-1 DMZ. This configuration is illustrated in Figure 14. Putting the Edge Server in tier-2 keeps it behind the second firewall and better protects its cached content, but this does add an additional network “hop” in the path of a

request. Note that the WebSeal servers load balance across the Caching Proxy servers in the Edge Server cluster.

Figure 14: Combining WebSeal with an Edge Server cluster in tier-2.

Another way to use both WebSeal and Edge Server is to incorporate the WebSeal plug-in in the Edge Server Caching Proxy. This means putting the Edge Server in the DMZ, which might potentially expose sensitive cached content if certain security breakdowns occur. But, if that is not a concern, then this configuration eliminates an extra network hop in serving a request. This configuration is illustrated in Figure 15. Note that the WebSeal plug-in is used to load balance across the HTTP Server cluster.

Figure 15: Combining Edge Server and WebSeal using the WebSeal plugin

For a very thorough description of use Tivoli Access Manager to secure a site, see the Redbook, Enterprise Business Portals with IBM Tivoli Access Manager. Another good source of information is the Redbook, Enterprise Security Architecture Using IBM Tivoli.

Very Large Scale Configurations Sites that serve very high volumes of requests need to horizontally scale to many machines. What constitutes “high volume” and what constitutes “many machines” will vary. The idea here is that at some point a WebSphere Application Server domain becomes unwieldy to administer because of the number of machines (nodes) and application servers in the domain. This leads to the desire to break the site up into multiple domains. The actual number of machines desirable in one domain tends to range from 4 to 16, depending on the usual circumstances of machine speed, etc.

One scheme to organize the Application Server domains is to divide them along application lines. Being in separate domains does not preclude application interaction. To do this, take all the nodes supporting application “A” and put them in one domain, put all the nodes supporting application “B” in another domain, and so on. If this gets the number of nodes per domain down to something reasonable, then the problem is alleviated. A reasonable number is the point where administrative tasks perform well.

Of course, there are cases where a large number of machines are needed to support one application. It is advisable to create multiple Application Server domains to keep the number of nodes in each domain manageable. If the application is using persistent HTTP sessions, then depending on the desired flow of requests, some Application Servers in different domains might need to share the same session database. If the HTTP servers are to distribute load across Application Server domains, you will need to manually create the plugin-cfg.xml file by combining the plugin-cfg.xml files from each

domain. Obviously, you can use a scripting language such as Perl to create the merged plugin-cfg.xml file. The session cookie used by the WebSphere HTTP server plug-in to maintain session affinity will route properly across Application Server domains.

Figure 16 shows a two-domain configuration. This illustration depicts a cluster of HTTP servers that spread requests across two clusters of application servers in two Application Server domains. The application uses HTTP session state with session affinity and persistence. Given the use of HTTP session persistence, the application servers in both domains share a common session database defined on the database server.

Figure 16: Two-domain configuration serving a common application

There are many variations on this sort of configuration. If the added fault tolerance of session persistence is deemed unnecessary, then the shared session database may be eliminated. (Since WebSphere Application Server4.0.1, session affinity is guaranteed on the first request.) With an IP sprayer like Network Dispatcher, you could use content-based routing to achieve affinity at the HTTP server layer, and treat the application servers in the multiple WebSphere Application Server domains as totally independent domains.

For example, in Figure 16 you could configure two of the HTTP servers to send requests only to WebSphere Application Server Domain 1 application servers, and the other two HTTP servers to send requests only to WebSphere Application Server Domain 2. With Edge Server 2, eND has dramatically improved its performance for content-based routing using “kernel-based, content-based routing.” It can route on the SSL session ID, for example, to ensure that requests always get back to the same HTTP server. (See the Redbook: IBM WebSphere Edge Server: New Features and Functions in Version 2 (SG24-6511).)

You want to create multiple WebSphere Application Server administrative domains to:

�� Improve administrative task performance. (Many nodes in one domain tend to be unwieldy to administer.)

��Ease management of systems for maintenance outages and software upgrades.

�� Increase fault tolerance. The loss of a WebSphere Application Server domain only affects some small number of nodes.

Miscellaneous System Configuration Issues The WebSphere 4.0 Administration Handbook has several sections on installation and configuration that the Operations Team will find useful. Detailed descriptions of how to do various configurations are in the Handbook and not repeated here. In this section we merely identify common configuration issues and reference the appropriate section in the Handbook that covers the topic.

Configuration for more than one NIC It is common to have more than one Network Interface Card (NIC) in a given host. WebSphere Application Servers have a history of not behaving well on a machine that is configured with more than one IP address. Version 4.0 provides an explicit mechanism for specifying which IP address or node name to use for ORB communications. (See Section 8.4.6 “Configure for Multiple NICs,” in the WebSphere Administration Handbook.)

Running the administrative server as non-root (See “Section 8.4.5 Configure for non-root user (UNIX only)” in the WebSphere Administration Handbook.)

Running the administrative server as non-root imposes a couple of restrictions that may be important to consider:

��The application servers must all run using the same user ID as the administrative server. The ability to change the user ID of a process is a root privilege.

��The OS registry (/etc/passwd) cannot be used for authentication if WebSphere Application Server security is enabled. (This restriction is usually insignificant since most sites that use this security use an LDAP registry.)

Running the application servers with different user IDs Having a separate user ID for each application server provides the following advantages:

�� It allows file permissions to be set up according to the application server for some added security.

��The user ID of the Java process running the application server may determine access to resources the process needs.

�� It is easier to identify the Java process that is running each application server. (The output of the UNIX ps -ef command shows the user ID in one of the left hand columns.)

You can only have separate user Ids for each application server if the admin server runs as root.

Conclusion Hopefully you’ve gained an understanding of why production environments are so complex. Each increment of complexity is motivated by a need for increased fault tolerance, increased security or increased performance. A given application has certain qualities of service requirements that will drive an organization to choose among configurations that may be relatively simple or complex. As complexity increases, obviously cost increases, which increases the importance of these decisions.

References

Redbooks All IBM Redbooks are available for download as PDFs at http://www.redbooks.ibm.com/.

SG24-6176-00 IBM WebSphere V4.0 Advanced Edition Handbook

SG24-6520-00 IBM WebSphere V4.0 Advanced Edition Security

SG24-6014-00 Enterprise Security Architecture using IBM Tivoli

SG24-6556-00 Enterprise Business Portals with IBM Tivoli Access Manager

SG24-5132-00 IBM HTTP Server Powered by Apache on RS6000

SG24-6511 IBM WebSphere Edge Server: New Features and Functions in Version 2

Tecnical Articles These articles can be found at the WebSphere Developer Domain (WSDD) http://www.ibm.com/websphere/developer

Maximizing Web Site Availability by High-Volume Web Site Team (http://www7.software.ibm.com/vadd-bin/ftpdl?1/vadc/wsdd/hvws/HAfinal_25Feb.pdf)

Failover and Recovery in WebSphere Application Server Advanced Edition 4.0 by Tom Alcott, et al (http://www7.software.ibm.com/vadd-bin/ftpdl?1/vadc/wsdd/pdf/modjeski.pdf)

Livin’ on the Edge: Dynamic Web Content with IBM WebSphere Application Server and WebSphere Edge Server by Bill Hines. (http://www.ibm.com/websphere/developer/techjournal/0109_hines/hines.html)

Improve Web Application Performance, Doc # 08983, WebSphere Advisor, December 2001, by Bill Hines. (http://websphereadvisor.com/)

Web Sites DB2: http://www-3.ibm.com/software/data/db2/

Edge Server: http://www-3.ibm.com/software/webservers/edgeserver/

IBM HTTP Server: http://www-3.ibm.com/software/webservers/httpservers/

Tivoli Access Manager: http://www.tivoli.com/products/solutions/security/news.html

WebSphere Application Server: http://www-3.ibm.com/software/webservers/appserv/