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.
- IBM HTTP Server
- 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
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.
Availability
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.