![[V5.1 and later]](../../v51x.gif)
Multimachine topology concepts
Multiple machine environments extend basic single machine WebSphere Application Server configurations by distributing the Application Server over multiple machines, increasing the overall processing power from one machine to contributions from all machines in the configuration.
The flow of data in a WebSphere Application Server environment starts with a Web server receiving requests and routing them to the Application Server for processing. A WebSphere Application Server node stores administrative configuration data in XML files. A database can hold application data for applications that require a place to store data, such as user session information. There are also one or more administrative clients, such as the administrative console, for manipulating configuration data.
Some of the reasons for creating WebSphere Application Server applications that run on multiple machine systems include:
- Scalability. Adding more machines increases processing power, which
scales up the system to handle a higher client load than that provided by
a basic, single machine configuration. Scalability pertains to the capability
of a system to adapt readily to a greater or lesser intensity of use, volume,
or demand. For example, a scalable system can efficiently adapt to work with
larger or smaller networks performing tasks of varying complexity. Ideally,
it is possible to handle any given load by adding more servers and machines,
assuming each additional machine processes its fair share of client requests.
Each machine should process a share of the total system load that is proportional
to the processing power of the machine.
Consider these primary scalability factors when adopting a WebSphere Application Server topology:
- Security. Address certain security concerns by physically separating
the Web server from the Application Server, by using firewalls.
- Performance. Maximize performance by ensuring the response time
for transactions is as short as possible. You can use two general topologies
to improve transaction performance:
- Vertical scaling, in which you create additional Application Server
processes on a single physical machine. The Vertical scaling sample topology topic
describes a physical implementation for vertical scaling.
- Horizontal scaling, in which you create additional application server processes on multiple physical machines to take advantage of the additional processing power available on each machine. You can also use WebSphere Application Server Edge Components, such as the Caching Proxy Edge component, and the Load Balancer component set (which includes the Dispatcher component), to implement horizontal scaling. The Horizontal scaling with cluster members sample topology and Horizontal scaling with Load Balancer sample topology topics describe physical implementations for horizontal scaling.
- Vertical scaling, in which you create additional Application Server
processes on a single physical machine. The Vertical scaling sample topology topic
describes a physical implementation for vertical scaling.
- Throughput. Add Application Server clusters to scale vertically
or horizontally. Application server clusters can increase the number of concurrent
transactions that the application can perform, to help process as many transactions
as possible within a given time period.
- Availability and failover support. Avoid a single point of failure
and maximize system availability by ensuring that the topology has some degree
of process redundancy. High-availability topologies typically involve horizontal
scaling across multiple machines. Vertical scaling can improve availability
by creating multiple processes, but the machine becomes a point of failure.
A Load Balancer server performs intelligent load balancing to determine where to send a TCP/IP request. It can direct client HTTP requests to available Web servers, bypassing any that are offline. Another server can back up the Load Balancer server, to eliminate it as a single point of failure. Workload management of Application Servers and administrative servers also improves availability and failover support.
Failover support distributes client requests to the remaining servers, which ensures continued client access without significant interruptions. (In practice, failover is not entirely transparent to clients.)
WebSphere Application Server supports these methods of ensuring availability with multiple machines and applications:
- Multiple tiers The components of an application (the Web server,
Application Servers, databases, and so forth) are physically separated on
different machines.
- HTTP server separation The Web (HTTP) server is located on a different
physical machine than the Application Server. You can redirect requests to
Application Servers through a variety of methods.
- Demilitarized zone (DMZ) Firewalls create demilitarized zone machines,
which are isolated from both the public Internet and other machines in the
configuration. The DMZ scales security processing, which improves security
and throughput in the application environment.
- Multiple cells Multiple WebSphere Application Server cells provide
failover for clustering Application Servers and deploying applications.
- Multiple applications Multiple application instances can be on the same physical machine, or on more than one machine in the cell.
- Multiple tiers The components of an application (the Web server,
Application Servers, databases, and so forth) are physically separated on
different machines.
- Maintainability. Understand that the topology affects the ease
with which you can update system hardware and software. For instance, using
multiple WebSphere Application Server deployment manager cells or horizontal
scaling can make a system easier to maintain because you can take individual
machines offline without interrupting other machines, running the application.
Maintainability sometimes conflicts with other topology considerations. For example, limiting the number of Application Server instances makes the application easier to maintain but can have a negative effect on throughput, availability, and performance.
- Maintaining session state between client HTTP requests. Consider that session state is important for stateful applications, or for applications that run on multiple machines or Application Server instances. You can share a session between multiple Application Server processes (cluster members) by saving the session state to a database. In addition, configuring a Load Balancer affects how the session state is maintained. This consideration does not apply if your application runs on a single Application Server instance or is completely stateless.
- Security. Address certain security concerns by physically separating
the Web server from the Application Server, by using firewalls.
- Shared data access. Placing backend resources, such as databases,
on different machines provides ease of use when sharing these resources.
- Fault isolation. Providing more robust failover support through
a configuration that includes a degree of fault isolation, reduces the potential
for failure of one server to affect other servers. Configurations that provide
simple failover support are concerned only with individual server failures
that have no effect on the performance of other servers. However, in some
situations, a malfunctioning server can create problems for other servers
that are otherwise functioning normally. For example, a failing server can
consume more than its share of system and database resources, preventing other
servers from gaining adequate access to these resources. You can configure
WebSphere Application Server to provide fault isolation between different
parts of a system.
- Dynamic changes to configurations. Modifying the system configuration
without interrupting its operation enhances the manageability and flexibility
of the system. For instance, administrators can add or remove cluster members
to handle variations in the client load, change server characteristics and
propagate the changes to its cluster members, temporarily stop servers for
maintenance, and so forth.
- Mixed Application Server versions. Migrating a few machines and
applications at one time is possible on certain multiple machine configurations.
In addition to V5 Application Servers, your server configuration can
include earlier version Application Servers, where you currently deploy all
applications you intend to migrate. You can migrate applications to Version
5 and deploy them in stages. You can also easily upgrade system hardware and
software. When combined with the ability to make dynamic changes to the configuration,
you can use a configuration of mixed Application Server versions to upgrade
an application or machine without any interruption of service.
The ability to run different versions of an Application Server in a configuration does not let you include V5 Application Servers in an existing administrative domain, nor does it let you include V3.5.x or V4.0.x application servers in a V5 cell.
You can configure multiple machines to add processing power, improve security, maximize availability, and balance workloads. WebSphere Application Server Network Deployment and WebSphere Application Server Edge Components provide clusters, workload management, and the Load Balancer to implement configurations that address these issues. These scaling techniques are generally combined to maximize benefits and minimize problems associated with multiple machine systems.
There are various ways to scale up the basic, single-machine WebSphere Application Server system to meet the needs of your organization. Some scaling techniques include:
- Clusters. Clusters are identical multiple Application Server copies.
A cluster member is one Application Server in a cluster. The configuration
of each cluster member is based upon the Application Server that you copied
to create the cluster member. You can create all cluster members on the same
physical machine, or on different machines. Using cluster members can improve
the performance of a server, simplify its administration, and enable the use
of workload management.
- Workload management (WLM). WLM enables both load balancing and
failover, improving the reliability and scalability of applications deployed
on the WebSphere Application Server server. Incoming processing requests from
clients are transparently distributed among the cluster members of an Application
Server.
- Load Balancer. The Dispatcher component of Load Balancer transparently redirects incoming HTTP requests from Web clients to a set of Web servers. Although the clients behave as if they are communicating directly with a given Web server, the Dispatcher is actually intercepting all requests and distributing them among all the available Web servers in the cluster. The Dispatcher can provide scalability, load balancing, and failover for Web servers. (Load Balancer was known as Network Dispatcher in previous releases.)
Keep in mind that the techniques described above are not mutually exclusive. You can combine their basic elements in various ways.
Firewalls and demilitarized zone configurations
Enterprise beans
Sessions
Setting up a multinode environment
Accessing data from applications