Oracle Application Server 10g Essentials [Electronic resources] نسخه متنی

2.4 Scalability Architectures

Oracle Application Server is highly scalable as
a J2EE application server. As demand for a particular J2EE web
application grows, so too can the application
server's capacity grow, both vertically and
horizontally. The following subsections describe the various types of
scaling supported by the product.

2.4.1 Vertical Scaling with OC4J

Oracle Application Server can scale its
capacity vertically by running more than one instance of
OC4J on a given host, or by running more
than one Java Virtual Machine in a given
instance of OC4J.

2.4.1.1 Multiple OC4J instances per host

An Oracle Application Server instance can be configured to run one or
more instances of OC4J. In such a configuration, each OC4J instance
runs with its own JVM. However, running multiple instances of OC4J on
the same host is more of a configuration convenience than it is a
means of scalability because multiple OC4J instances on a single
machine share the same configuration files.

It isn't uncommon for several applications to share
an application server. By running multiple OC4J instances, each
heterogeneous application can run in its own OC4J instance. This
reduces the risk that the deployment of an application may affect
other applications (or appear that it has). It also makes it possible
to do resource consumption accounting by application, which is a
necessary evil in many business environments.

2.4.1.2 Multiple JVM processes per OC4J instance

Vertical scaling is better achieved by running more than one
JVM process in an OC4J instance.
Doing so leverages the processing power of a host that has multiple
CPUs.

When more than one JVM process is running,
HTTP
session objects and EJB states are
replicated among the JVMs. In addition to the
server's offering increased capacity to process
incoming requests in such a configuration, the server is also better
equipped to recover from JVM process failures. In case of such a
failure, it can redirect a request to one of the other JVMs running
in the same OC4J instance.

Replicating HTTP session objects can
become a resource-intensive task. To better manage this state
replication, Oracle Application Server provides a mechanism that
provides a finer level of control. Each JVM is assigned to an island.
An island
logically
groups JVMs together for the purpose of HTTP session object
replication. If two or more JVMs have the same island name (even in
clustered Oracle Application Server instances on different hosts),
HTTP session objects are replicated among them. This capability means
that you can control which JVMs replicate state with each other.

For example, if you have an OC4J instance that has four JVM processes
running, you can have two JVMs assigned to
default_island, and the other two assigned to
island_two. With this configuration, HTTP session
objects are replicated between the two JVMs that are part of the same
island. This reduces the overhead of replicating each HTTP session
object because each JVM has only one replication site, rather than
three.

In contrast, no refined replication control exists for EJB state. EJB
state replication doesn't use the island replication
facility. The state of any stateful EJB is replicated among all JVMs
in an OC4J instance (or in clustered Oracle Application Server
instances).

2.4.2 Horizontal Scaling with Oracle Application Server

Horizontal scaling is accomplished
using clusters. A
cluster groups two or more Oracle
Application Server instances so that they appear as one application
server. Clustered Oracle Application Server instances utilize only
the Oracle HTTP Server and OC4J components.

Figure 2-2 shows two Oracle Application Server
instances in a cluster. In this figure, a load balancer receives a user
request. The load balancer forwards the request to an Oracle
Application Server instance, where it is processed. Looking at the
figure, you can see that both instances of Oracle Application Server
use the same metadata repository, as well as any other resource, such
as an application database.

Figure 2-2. Clustered Oracle Application Server instances

2.4.2.1 Oracle Application Server farm

To be clustered, Oracle Application Server instances must be part of
the same farm. A
farm
is a group of one or more Oracle Application Server instances
(clustered or not) that share the same OracleAS Infrastructure or
that use the same Oracle Application Server instance for their
file-based OracleAS
Metadata Repository.

Oracle Application Server instances automatically become part of a
farm during installation. The farm assignment is based on which
OracleAS Infrastructure or Oracle Application Server instance (for a
file-based repository) they use for their OracleAS Metadata
Repository. This assignment can be changed at a later date using
Oracle Enterprise Manager.

2.4.2.2 Oracle Application Server cluster definition

An Oracle Application Server cluster definition is created within a
farm using Oracle Enterprise Manager. After a cluster
is defined, the first Oracle Application Server instance added to the
cluster defines the cluster-wide configuration. Thereafter, each
server that is added to the cluster gets its configuration and any
deployed applications from the cluster-wide configuration. The only
configuration properties that aren't part of the
cluster-wide configuration are the OC4J-specific properties: the
number of JVM processes per OC4J instance and the ports an OC4J
instance uses to communicate with the Oracle HTTP Server.

2.4.2.3 Cluster management

Clustered
Oracle Application Server
instances appear as one application server not only to the end user
but also to the Oracle Application Server administrator. If changes
are made to any Oracle Application Server instance in a cluster, the
DCM process automatically replicates the changes to all the other
instances in the cluster. This process significantly reduces the
amount of work an administrator has to do to deploy applications in a
clustered environment.

2.4.3 Load Balancing

As mentioned earlier, a load balancer is required when Oracle
Application Server instances are being clustered together. There are
three traditional choices for load balancing:

Hardware

Operating system

OracleAS Web Cache

Of the three, Oracle recommends using a hardware-based load balancer.
The following subsections describe these three approaches, along with
a brief discussion of load balancing with the Oracle HTTP Server.

2.4.3.1 Hardware load balancer

A hardware load balancer works by
receiving a request from an end user and then forwarding the request
to a clustered Oracle Application Server instance. Hardware load
balancers support various forwarding algorithms, including the
following:

Fastest Response

Forwards a request to the application
server that responds the most quickly

Round Robin

Forwards a request to the next application
server in a predetermined list of servers

Least Connections

Forwards a request to the application
server with the fewest number of connections

Calculated Ratio

Forwards a request to the application
server with the best calculated ratio based on predetermined
statistics

Geographic Location

Forwards a request to the application
server located closest to the requestor

Hardware load balancers are preferred because they are faster and
have redundant components that eliminate downtime caused by
mechanical or electrical failure. Figure 2-3 shows
a typical hardware load balancer configuration. In this figure, an
end user sends a request to a hardware load balancer. The hardware
load balancer forwards the request to a clustered instance of
OracleAS Web Cache. OracleAS Web Cache returns cached content, if
available. If cached content isn't available, it
forwards the request on to a clustered instance of Oracle Application
Server.

Figure 2-3. A hardware load balancer example

Examples of hardware load balancers include the following products:

F5 Networks' BIG-IP

See http://www.f5.com/f5products/bigip/

Nortel Network's Alteon

See http://www.nortelnetworks.com/products/01/alteon/

2.4.3.2 Operating system load balancer

Some operating systems provide a built-in
load-balancing mechanism. In particular, Microsoft Windows Advanced
Server allows you to forward requests to different machines that
share the same IP or MAC level address. In addition, load-balancing
software applications are available for almost all operating systems.

2.4.3.3 OracleAS Web Cache load balancer

OracleAS
Web Cache
can be used as a load balancer for clustered Oracle Application
Server instances. When OracleAS Web Cache acts as a load balancer, it
uses a Weighted Available Capacity algorithm
to determine the particular Oracle Application Server instance to
which it will forward the request. This algorithm uses a weight,
assigned by an administrator, to distribute the load unequally among
instances. If the weighted available capacity is the same, OracleAS
Web Cache uses a Round Robin algorithm.

If an Oracle Application Server instance fails, OracleAS Web Cache
redistributes requests to the remaining instances. Meanwhile,
OracleAS Web Cache intermittently polls the failed server until it is
once again available to process requests. At that time, the failed
server is included in the load-balancing algorithm.

For more information about this capability of OracleAS Web Cache, see
the detailed discussion in Chapter 7.

2.4.3.4 Oracle HTTP Server load balancer

While our discussion so far has focused
on load-balancing requests to clustered Oracle Application Server
instances, another type of load balancing may also be taking place.
Oracle HTTP Server's mod_oc4j
load-balances requests among multiple JVM processes in an
OC4J instance or among OC4J instances
in a cluster.

If an OC4J instance is configured to use two or more JVM processes or
is part of a cluster, mod_oc4j routes a stateful
request to the JVM that last processed the stateful request. If the
JVM that last processed a stateful request has failed, the request is
rerouted using a predetermined algorithm to another OC4J
instance's JVM process that is part of the same
island as the failed JVM.

Three algorithms are available for
rerouting a request to a failed OC4J instance:

Round Robin

As usual with a Round Robin algorithm,
mod_oc4j uses the next OC4J instance (and the next
JVM process in the same island), remote and local to the Oracle
Application Server instance, on a predetermined list.

Random

With the Random algorithm, an OC4J instance is
picked randomly from the predetermined list.

Metric-Based

This algorithm uses OC4J performance
metrics to determine where to route a request.

All these algorithms can be configured with local affinity, so a
local OC4J process is used in favor of a remote process. Similarly,
the Round Robin and Random algorithms can employ a weighting factor
to determine which OC4J process is chosen.

Stateless requests are always processed using one of these
predetermined algorithms. You can configure the desired algorithm,
along with all the other settings, using Oracle Enterprise Manager.