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.