10g AS Clustering

10g AS supports both J2EE mid- tier application server clustering and WC clustering. This chapter will focus on J2EE mid-tier clusters fronted by a single WC server. 10g AS clusters provide the following benefits:

  • Integrated management and communication. To be part of a cluster, each mid tier must first be a member of a farm and then made into a cluster. This means the mid tiers are part of a managed infrastructure repository. The benefit is that because they're integrated together, OPMN processes manage and monitor each cluster member and DCM propagates the configuration and synchronization information.

  • Fault tolerance. If any member of the cluster fails, the other members continue processing. Additionally, if individual components within an instance fail, OPMN will attempt to restart the failed components . This mid-tier clustering is still vulnerable to failures on the database or WC tier, but both of these tiers can also be clustered.

  • Automatic failover. When a member does fail, its work is automatically routed to the surviving members. In cases of OC4J islands where application state is replicated between OC4J processes within the cluster, the individual transactions can transparently continue to be processed on the surviving islands.

  • Load balancing. WC can be configured so cache misses are routed to the mid-tier cluster members based on a load percentage. Specifically, each mid tier can be assigned a percentage of incoming requests that it will receive. For example, Server A could get 40 percent, Server B could get 30 percent, and Server C could get 30 percent of all cache misses.

  • Simplified application deployment. Deploying J2EE applications via the Application Server Control (ASC) utility is already simple, and with clusters you only need to deploy the application to one mid-tier instance. Because each cluster member must be identical in terms of application deployment and configuration, DCM automatically propagates new applications and updates to each cluster member.

  • Simplified management. The ASC utility was designed to manage large, multi-instance clustered environments like this. "Enterprise" has long been an Oracle buzzword and the ASC utility fits the bill by allowing a single entry point into controlling multiple instances, both within the farm and the cluster.

Note 

With the 10g AS (9.0.4) release, only J2EE mid tiers can be clustered. Oracle Business Intelligence and Forms and Portal and Wireless mid tiers cannot be clustered.

On the members of a cluster 10g AS imposes the following two requirements, which make the preceding benefits possible:

  • All members of the cluster must belong to an infrastructure repository.

  • Each member has an identical application configuration.

Each member of a cluster must be attached to an infrastructure repository. The repository can be a file-based repository for small clusters or, as we'll show you, the Infrastructure installation composed of a J2EE installation, Oracle asdb database, and Oracle Internet Directory (OID) and Single Sign-On (SSO) components. Remember that the infrastructure stores metadata, configuration information, and potentially OID and SSO information for the mid-tier instances. Mid-tier installations attached to an infrastructure compose farms when they have different configurations.

A cluster is formed when mid-tier instances in a farm have an identical application configuration. This means that the same applications are automatically deployed to them with the same configuration options. The number of OC4J processes may differ and node-specific information (IP, hostname, ports, and so on) may be different, but in all other aspects each node is identical.

By having the members of a cluster centrally managed and identical, it's possible to implement failover, load balancing, and simplified deployment.

Architecture

10g AS clusters ideally have multiple, separate, dedicated nodes, all of which have a mid-tier cluster instance installed on it. Located behind a WC server (potentially a WC cluster), the mid-tier cluster members connect to an infrastructure on a separate node (possibly a cluster) and the customer databases on another node (possibly being clustered). You see a possible implementation in Figure 21-1.

image from book
Figure 21-1: 10g AS cluster

In Figure 21-1 you see a single WC server supporting two J2EE mid-tier instances ( 904mt1 and 904mt2 ). The mid tiers connect both to the infrastructure instance and to the customer database server. Under this architecture you have redundancy and fault tolerance only at the mid-tier level. This topology would be sufficient for medium- to large- sized applications that had a high user load and wanted fault tolerance at the mid-tier level. However, it's vulnerable to losses at the database, infrastructure, and WC levels as each of these components represents a single point of failure. If necessary, each of those components could also be clustered to eliminate the single point of failure vulnerability.

In this chapter, the example cluster will follow the basic architecture as defined in Figure 21-1 except that it will be located on one node for demonstration purposes.

In the following sections you'll create your cluster using the following steps:

  • Creating a farm

  • Creating clusters

  • Deploying an application

  • Implementing failover



Oracle Application Server 10g. J2EE Deployment and Administration
Oracle Application Server 10g: J2EE Deployment and Administration
ISBN: 1590592352
EAN: 2147483647
Year: 2004
Pages: 150

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net