Midtier Oracle Application Server Tips by Burleson Consulting

At the midtier, there normally are multiple instances of the application server, each implementing Oracle?s HTTP Server (OHS) and possibly multiple OC4J containers running multiple copies of the application. As we discussed in Chapter 4, each OHS server implements multiple processes to handle requests, the loss of one having little or no effect on the server. OHS also has the ability to restart without shutting down. As each process completes its request, OHS will kill it and restart it with the new configuration. Thus OHS is available even while reconfiguring itself. Additionally OHS will use mod_oc4j to load-balance to the OC4J containers, providing redundancy within the midtier instance. The mod_oc4j module insures that the OC4J container is running before sending it a request. Because OC4J containers clustered in an island replicate their state to all containers within the island, mod_oc4j can reroute a request to another container within the island if a container is no longer running and still maintain the session?s state.

The midtier instances are clustered using the infrastructure tier for configuration, OID and SSO. A cluster is a group of midtier instances that share a common configuration and work together to distribute the load across multiple servers. A cluster is created using the Enterprise Manager Application Server Control or the DCM utility. All instances in each cluster have the same configuration, and changes to one instance will be propagated to all the other instances in the cluster. If you deploy your application onto an instance that belongs to a cluster, it is propagated to all other instances in the cluster. To create a cluster using the Enterprise Manager web site, you need at least two instances associated with an infrastructure. Figure 9-2 shows an infrastructure with two instances. For this example, both midtier instances are installed on one server; normally they would be installed on separate servers.

Figure 2: Enterprise Manager Farm asdb.proxitec.com

Select the Create Cluster button to create a new cluster. Enter the name for this cluster (I used TestCluster1), and select create. This creates an empty cluster.

Figure 3: Enterprise Manager Farm with TestCluster1

Now we need to add the two midtier instances to the cluster. Select the midtier instance to add to TestCluster1 and select the Join Cluster button. You will get a list of available clusters and a warning that unless the cluster is empty, the OC4J instances will be invalidated because they will be reconfigured to match the other instances in the cluster. For this example I created two midtier instances, midtier_1 and midtier_2. I deployed the Pet Store application into midtier_1 and then added it to TestCluster1. Next I added the midtier_2 instance to the TestCluster1 cluster. From the Enterprise Manager Farm page, select the TestCluster1 link to list the instances and their status, which make up the cluster.

Figure 4: Enterprise Manager TestCluster1 status page

You can now view the status page for each of the instances in the cluster by selecting their link. The clustered instances share a common configuration. Applications deployed into one instance will automatically be deployed into all of the instances that belong to that cluster. In this example I deployed the Pet Store application into midtier_1 before adding it to the cluster. Since it was the first instance added, the cluster assumed its configuration. I then added midtier_2 to the cluster, and the Pet Store application was automatically deployed into the midtier_2 instance when it was added to the TestCluster1 cluster.

Figure 5: Enterprise Manager Midtier_2 status page

This ability to cluster instances greatly simplifies the management of multiple midtier instances. When the midtier needs an additional instance to support a growing workload, you can install a basic midtier instance on an additional server and simply add it to the cluster. The new instance will be configured to match the other instances in the cluster.

Note: You must reconfigure the Web Cache to use the new instance. Adding the instance to a cluster will not configure it to use a common Web Cache. See Chapter 5 for information on configuring the Web Cache.

Mid_tier instances (standalone and clusters) associated with a single infrastructure make up a farm. If an instance does not belong to a farm, you must add it to the farm before adding it to a cluster within a farm. Normally, instances are added to a farm when they are installed, but you can add an instance to a farm by navigating to the instance web page and using the Use Infrastructure Wizard. Once an instance is part of a farm, it can be added to a cluster or remain a standalone instance. It is possible to cluster instances without an infrastructure instance, but you lose the cluster manageability because you are now responsible for insuring that configuration changes are propagated to each instance.

Infrastructure Tier

The infrastructure tier not only contains the infrastructure instance but also the repository database. The diagram in Figure 9-1 shows the infrastructure tier configured within a Cold Failover Cluster. Unlike the midtier clusters that are all active, in a Cold Failover Cluster, only one server is active, while the other is standing by in case the first fails. This configuration requires an OS-supported clustering system such as Sun Cluster. When the active node fails, the clustering software restarts the failed programs on the cold node. An exciting new feature of Oracle Application Server 10g is the ability to create the repository database in an existing database. This allows the repository database to take advantage of an already existing high-available back-end database that may implement RAC or be hosted on a large, highly available server. This provides availability for the repository database but not for the infrastructure instance. Oracle will soon provide a capability to cluster and load-balance multiple infrastructure instances so that you can create a redundant infrastructure without using a cold server on standby.

Back-end Database

Behind the application servers is some type of continuous availability database using RAC, DataGuard, or replication. Oracle Real Application Clusters, or RAC, creates multiple database instances of the same database and allows for very fast recovery from an instance failure. DataGuard implements a standby database that is constantly updated from the active database. If the active database fails, the administrator will convert the standby database into an active database, reconfigure the network to point to the new active database, and resume processing. Replication implements multiple active databases that exchange changes between them so that they are consistent (with a small time delay). With replication, if one of the databases fails, processing continues on the remaining databases. Normally the back-end database will implement RAC, which is why the ability to implement the infrastructure?s repository database in the back-end RAC database greatly improves reliability. Implementing Real Application Clusters is outside the scope of this book. For additional information on implementing RAC, refer to the book Oracle9i RAC: Oracle Real Application Clusters Configuration and Internals by Mike Ault and Madhu Tumma (Rampant TechPress, 2003).

Fig 6 Typeset text:

Application Servers

Data Guard

Replication

Real Application Clusters

Figure 6: Highly available database solutions

 
This is an excerpt from "Oracle 10g Application Server Administration Handbook" by Don Burleson and John Garmany.