WebSphere Application Server clusters

A large IBM® WebSphere® Application Server cluster is composed of front end HTTP servers and proxy servers with a load balancer that directs requests around the cluster.
Restriction: To create and use a cluster of application servers, you must have IBM WebSphere Application Server Network Deployment (ND), which is not bundled with IBM Rational® Asset Manager.

You can scale WebSphere Application Server both vertically and horizontally. Use a dedicated database server and file server. The degree to which WebSphere Application Server can be scaled and the number of servers that you can use depend on the type and magnitude of server requests and the number of assets.

The first tier is the HTTP server, which handles requests from web clients and relieves the application server from serving static content. It provides a logical URL that encompasses ancillary applications, such as the IBM Rational Asset Manager application, the Rational Asset Manager Help application, and the Rational Asset Manager Asset Based Development application. Note that in a large configuration, a cache server is deployed in front of the HTTP server.
Load Balancer
A load balancer distributes load across a number of systems. If you have more than one HTTP server, you must use a load balancer. For moderately sized deployments, use a software-based load balancer, such as Edge Component. For larger deployments, which support a large number of concurrent users, use a hardware-based load balancer.
Cache Proxy
A forward-caching proxy system stores application data for clients in a cache and relieves load from other server systems. If your Rational Asset Manager server supports a moderate number of concurrent users, you need only one forward proxy system. If your Rational Asset Manager server supports a large number of concurrent users, you might need multiple proxy systems.
Application Server
The Rational Asset Manager EAR file is comprised of two WAR files: the repository and web application file and the web services file. Deploy the Rational Asset Manager EAR file on every WebSphere Application Server instance in a cluster. Rational Asset Manager also includes Help and IBM Rational Unified Process (RUP) WAR files; you do not have to deploy these WAR files. If high availability is not required for the Help and RUP support functions, deploy them on a single WebSphere Application Server instance or on an external WebSphere Application Server container.
Rational Asset Manager application
The Rational Asset Manager repository is normalized for searches and data retrieval so that data is stored in a manner that is designed to make searching for data, browsing artifacts, and downloading assets more efficient. To do so, every Rational Asset Manager server instance builds a local index for assets and a local index for artifacts. This optimizes search performance, relieves database load, and enhances scalability in a clustered environment. Local index directories might perform better than an index that is shared across nodes.
Database server
The most important considerations in choosing database hardware are the number of disks in the machine and the RAID schema that the machine uses. A RAID array should contain at least 6 to 10 drives for every processor. While memory is important, there is no significant difference between database server configurations with 4GB and 8GB of memory for 1000 users and 50,000 assets.
Database disk space requirements depend on many factors: the number of assets, the number of artifacts for each asset, the number of team spaces, the number of roles, the number of reviews, the number of asset types, the number of users, the amount of transactions on the server (user metrics), and quantity of forum discussions.
File server
Assets must be shared across WebSphere Application Server instances. Use a concurrently accessed file system. Rational Asset Manager accesses these files only during uploads, downloads, artifact indexing, and significant changes to the Rational Asset Manager model that require an asset manifest update.

Clustering topologies

Clustering is combining a group of machines into a logical entity that can be referenced as if it were one machine. This section describes various cluster configurations and the primary advantages and disadvantages of each.

Horizontal clustering
Horizontal clustering, sometimes referred to as scaling out, is adding physical machines to increase the performance or capacity of a cluster pool. Typically, horizontal scaling increases the availability of the clustered application at the cost of increased maintenance. Horizontal clustering can add capacity and increased throughput to a clustered application; use this type of clustering in most instances.
Vertical clustering
Vertical clustering, sometimes referred to as scaling up, is adding WebSphere Application Server instances to the same machine. Vertical scaling is useful for taking advantage of unused resources in large SMP servers. You can use vertical clustering to create multiple JVM processes that, together, can use all of the available processing power.
Hybrid horizontal and vertical clustering
Hybrid clustering is a combination of horizontal and vertical clustering. In this configuration, disparate hardware configurations are members of the same cluster. Larger, more capable machines might contain multiple WebSphere Application Server instances; smaller machines might be horizontally clustered and only contain one WebSphere Application Server instance.
When you use vertical clustering, be cautious. The only way to determine what is correct for your environment and application is to tune a single instance of an application server for throughput and performance, and then add it to a cluster and incrementally add additional cluster members. Test performance and throughput as each member is added to the cluster. When you configure a vertical scaling topology, always monitor memory usage carefully; do not exceed the amount of addressable user space or the amount of available physical memory on a machine.


Scalability is how easily a site can expand. The number of users, assets, and communities for a given Rational Asset Manager installation must be able to expand to support an increasing load. The increasing load can come from many sources, such as adding additional teams or departments to the set of Rational Asset Manager users or importing large sets of historical assets into Rational Asset Manager.

Scalability is an architectural consideration that drives the design of your architecture. While you might improve scalability by adding additional hardware to your system, it might not improve performance and throughput.

The choice between scaling up (vertical clustering) and scaling out (horizontal clustering) is usually a decision of preference, cost, and the nature of your environment. However, application resiliency issues can change your preferences.

  • Scaling up implements vertical scaling on a small number of machines with many processors and large amounts of addressable user space memory. This can present significant single points of failure (SPOF) because your environment is composed by fewer large machines.
  • Scaling out uses a larger number of smaller machines. In this scenario, it is unlikely that the failure of one small server will create a complete application outage. However, scaling out creates more maintenance needs.


Also referred to as fault-tolerance or resiliency, availability is the ability of a system to provide operational continuity in spite of failed components and systems. Architectural decisions, such as horizontal versus vertical scaling and using backup load balancers (that is, dispatchers), can impact the availability of your Rational Asset Manager application. Consider availability for all shared resources, networks, and disk storage systems that compose your Rational Asset Manager environment. In a fault-tolerant design, if an application or server fails, other members of the cluster can continue to service clients.

There are two categories of failover: server failover and session failover. When server failover occurs, sessions on the failed cluster member are lost (a user will have to log in again) but services are still available to the clients. In session failover, the existing sessions are resumed by other members of the cluster as if the cluster member had not failed (although the last transaction can have been lost). If a redundant infrastructure is configured to support server failover, Rational Asset Manager will support it.