1.1.1 Scalability
The proposed configurations should allow the overall system to service a higher client load than that provided by the simple basic configuration. Ideally, it should be possible to service any given load simply by adding the appropriate number of servers or machines.
Performance
Performance involves minimizing the response time for a given transaction load.
Throughput
Throughput, while related to performance, more precisely defines the number of concurrent transactions that can be accommodated.
1.1.2 Workload management
The proposed configurations should ensure that each machine or server in the configuration processes a fair share of the overall client load that is being processed by the system as a whole. In other words, it is not efficient to have one machine overloaded while another machine is mostly idle. If all machines have roughly the same power, each should process a roughly equal share of the load.
Otherwise the workload should be based on weights associated with each machines processing power assuming no affinity configuration.
Furthermore, if the total load changes over time, the system should automatically adapt itself, for example, all machines may use 50% of their capacity, or all machines may use 100% of their capacity. But not one uses 100% of its capacity and rest uses 15% of their capacity.
1.1.3 Availability
Availability requires that the topology provide some degree of process redundancy in order to eliminate single points of failure. While vertical scalability can provide this by creating multiple processes, the physical machine then becomes a single point of failure. For this reason, a high availability topology typically involves horizontal scaling across multiple machines.
Hardware-based high availability
Using a WebSphere Application Server multiple machine configuration eliminates a given application server process as a single point of failure. In WebSphere Application Server V5.0 and higher, the removal of the dependency on the administrative server process further reduces the potential that a single process failure can disrupt processing on a given node. In fact, the only single point of failure in a WebSphere cell/cluster is the Network Deployment Manager where all central administration is done. However, a failure at the Deployment Manager is less catastrophic. Application servers are more self sufficient in WebSphere Application Server V5.0 and higher compared to WebSphere Application Server V4.x. To provide high availability, an external High Availability solution should be examined for the Deployment Manager of WebSphere Application Server V5.0 and higher.
Failover
The proposition to have multiple servers (potentially on multiple independent machines) naturally leads to the potential for the system to provide failover. That is, if any one machine or server in the system were to fail for any reason, the system should continue to operate with the remaining servers. The load-balancing property should ensure that the client load gets redistributed to the remaining servers, each of which will take on a proportionately slightly higher percentage of the total load. Of course, such an arrangement assumes that the system is designed with some degree of overcapacity, so that the remaining servers are indeed sufficient to process the total expected client load.
Ideally, the failover aspect should be totally transparent to clients of the system.
When a server fails, any client that is currently interacting with that server should be automatically redirected to one of the remaining servers, without any interruption of service and without requiring any special action on the part of that client. In practice, however, most failover solutions may not be completely transparent. For example, a client that is currently in the middle of an operation when a server fails may receive an error from that operation, and may be required to retry (at which point the client would be connected to another, still-available server). Or the client may observe a “hiccup” or delay in processing, before the processing of its requests resumes automatically with a different server. The important point in failover is that each client, and the set of clients as a whole, is able to eventually continue to take advantage of the system and receive useful service, even if some of the servers fail and become unavailable.
Conversely, when a previously-failed server is repaired and again becomes available, the system may transparently start using that server again to process a portion of the total client load.
The failover aspect is also sometimes called fault tolerance, in that it allows the system to survive a variety of failures or faults. It should be noted, however, that failover is only one technique in the much broader field of fault tolerance, and that no such technique can make a system 100 percent safe against every possible failure. The goal is to greatly minimize the probability of system failure, but keep in mind that the possibility of system failure cannot be completely eliminated.
Note that in the context of discussions on failover, the term server most often refers to a physical machine (which is typically the type of component that fails).
But we will see that WebSphere also allows for the possibility of one server process on a given machine to fail independently, while other processes on that same machine continue to operate normally.
1.1.4 Maintainability
While maintainability is somewhat related to availability, there are specific issues that need to be considered when deploying a topology that is maintainable. In fact, some maintainability factors are at cross purposes to availability. For instance, ease of maintainability would dictate that one should minimize the number of application server instances in order to facilitate online software upgrades. Taken to the extreme, this would result in a single application server instance, which of course would not provide a high availability solution. In many cases, it is also possible that a single application server instance would not provide the required throughput or performance.
Some of the maintainability aspects that we consider are:
- Dynamic changes to configuration
- Mixed configuration
- Fault isolation
Dynamic changes to configuration
In certain configurations, it may be possible to modify the configuration on the fly without interrupting the operation of the system and its service to clients. For example, it may be possible to add or remove servers to adjust to variations in the total client load. Or it may be possible to temporarily stop one server to change some operational or tuning parameters, then restart it and continue to serve client requests. Such characteristics, when possible, are highly desirable, since they enhance the overall manageability and flexibility of the system.
Mixed configuration
In some configurations, it may be possible to mix multiple versions of a server or
application, so as to provide for staged deployment and a smooth upgrade of the
overall system from one software or hardware version to another. Coupled with
the ability to make dynamic changes to the configuration, this property may be
used to effect upgrades without any interruption of service.
Fault isolation
In the simplest application of failover, we are only concerned with clean failures of
an individual server, in which a server simply ceases to function completely, but
this failure has no effect on the health of other servers. However, there are
sometimes situations where one malfunctioning server may in turn create
problems for the operation of other, otherwise healthy servers. For example, one
malfunctioning server may hoard system resources, or database resources, or
hold critical shared objects for extended periods of time, and prevent other
servers from getting their fair share of access to these resources or objects. In
this context, some configurations may provide a degree of fault isolation, in that
they reduce the potential for the failure of one server to affect other servers.
1.1.5 Session state
Unless you have only a single application server or your application is completely
stateless, maintaining state between HTTP client requests will also play a factor
in determining your configuration. In WebSphere V5.1 there are two methods for
sharing of sessions between multiple application server processes (cluster
members). One method is to persist the session to a database. An alternate
approach is to use memory-to-memory session replication functionality, which
was added to WebSphere V5 and is implemented using WebSphere internal
messaging. The memory-to-memory replication (sometimes also referred to as
“in-memory replication”) eliminates a single point of failure found in the session
database (if the database itself has not been made highly available using
clustering software). See “HTTP sessions and the session management facility”
on page 22 for additional information.
1.1.6 Performance impacts of WebSphere Application Server security
The potential to distribute the processing responsibilities between multiple
servers and, in particular, multiple machines, also introduces a number of
opportunities for meeting special security constraints in the system. Different
servers or types of servers may be assigned to manipulate different classes of
data or perform different types of operations. The interactions between the
various servers may be controlled, for example through the use of firewalls, to
prevent undesired accesses to data.
From the performance point of view, there are a few things to consider when
designing a secure solution. Building up SSL communication causes extra HTTP
requests and responses between the machines and every SSL message is
encrypted on one side and decrypted on the other side. The authorization
process adds additional load to the application server. In a distributed
environment, the authorization server should be put onto a separate machine in
order to offload application processing. The following three settings can help to
fine-tune the security-related configurations to enhance performance:
_ Security cache timeout
Its setting determines how long WebSphere should cache information related
to permission and security credentials. When the cache timeout expires, all
cached information becomes invalid. Subsequent requests for the information
result in a database lookup. Sometimes, acquiring the information requires
invoking an LDAP-bind or native authentication, both of which are relatively
costly operations in terms of performance.
_ HTTP session timeout
This parameter specifies how long a session will be considered active when it
is unused. After the timeout, the session expires and another session object
will be created. With high-volume Web sites, this may influence the
performance of the server.
_ Registry and database performance
Databases and registries used by an application influence the WebSphere
Application Server performance. Especially in a distributed environment,
when the authorization process uses an LDAP server, you have to consider
tuning the LDAP database and LDAP server for performance first, before
starting to tune WebSphere.
Tip: Please refer to the redbook A Practical Guide to DB2 UDB Data
Replication V8, SG24-6828 for details about DB2 replication.