Oracle9i Real Application Clusters Concepts
Release 1 (9.0.1)

Part Number A89867-02
Go To Documentation Library
Home
Go To Product List
Book List
Go To Table Of Contents
Contents
Go To Index
Index

Master Index

Feedback

Go to previous page Go to next page

11
Oracle Real Application Clusters Guard Architecture

This chapter describes the architecture of Oracle Real Application Clusters Guard. It includes the following topics:

Overview of Oracle Real Application Clusters Guard Components

Oracle Real Application Clusters Guard works with Real Application Clusters and the port-specific Cluster Manager to monitor and maintain availability. Figure 11-1 shows the relationship between these components of Oracle Real Application Clusters Guard to the Cluster Manager (CM).

Figure 11-1 How Oracle Real Application Clusters Guard is Related to Real Application Clusters and the Cluster Manager


Text description of pfscn025.gif follows
Text description of the illustration pfscn025.gif

A database server that runs Real Application Clusters consists of the Oracle database, Real Application Clusters software, and the Oracle Net listeners that accept client requests. These software components run on each node of a cluster. They use the services provided by the hardware, the operating system, and the port-specific Cluster Manager. The Cluster Manager monitors and reports the health of the nodes in the cluster and controls pack behavior.

A pack is a piece or suite of software that adds functionality to Oracle Enterprise Manager, ensuring the availability of the set of resources required to run an Oracle instance. The pack controls the startup, shutdown, and restarting of Oracle processes. There is one pack for each instance. In the context of Real Application Clusters and Oracle Real Application Clusters Guard, packs were formerly called PFS packs. The application software or middleware receives direction from the packs and from Real Application Clusters.

Oracle Real Application Clusters Guard consists of the components described in the following sections:

Packs

The pack controls the startup, shutdown, and restarting of Oracle processes. There is one pack for each instance. Each pack controls the following resources on its node:

PFSCTL Control Utility

The PFSCTL control script is responsible for starting, stopping, and operating Oracle Real Application Clusters Guard through its interaction with the Cluster Manager. It provides a command-line interface to the user.

See Also:

Chapter 12, "Oracle Real Application Clusters Guard Operation" 

Oracle Real Application Clusters Guard Monitors

Oracle Real Application Clusters Guard has three monitors:

Instance monitor

Detects termination of the local instance (such as a SHUTDOWN ABORT) and initiates a resulting action

Heartbeat monitor

Detects unavailable service (such as an instance hang) for the primary and secondary instance roles and initiates a resulting action

Listener monitor

Monitors and restarts the listeners

See Also:

"Monitors" 

Oracle Real Application Clusters Guard Configuration Templates

Oracle Real Application Clusters Guard provides configuration templates that allow it to be easily configured. The templates contain configurations for such settings as Oracle Net Services and initialization parameters that have already been tested. The PFS setup utility assists with the generation of the files that are required by Oracle Real Application Clusters Guard. The files are automatically generated with the correct values, derived from the customized templates.

See Also:

 

PFS Setup Utility

The PFS setup utility assists with the generation of appropriate PFS files for the specified environment, as well as simplified configuration and set up of Oracle Real Application Clusters Guard software. It also makes it easier to deploy changes in the Oracle Real Application Clusters Guard environment.

See Also:

 

Concepts of Oracle Real Application Clusters Guard

The concepts described in the following sections are important for understanding Oracle Real Application Clusters Guard architecture:

Instance Roles

In a Real Application Clusters environment where the ACTIVE_INSTANCE_COUNT parameter in the initialization parameter file (init.ora) is set to 1, an instance has either a primary instance role or a secondary instance role. The instance that mounts the database first assumes the role of primary instance. The second instance to mount the database assumes the role of secondary instance. If the primary instance fails or is shut down, then the secondary instance automatically assumes the primary instance role. When the failed instance returns to active status, it assumes the role of secondary instance. The V$INSTANCE dynamic performance view displays the instance roles of the instances.

See Also:

"High Availability Configurations"  

Preferred Primary and Secondary Nodes

The preferred primary node is the node where the pack with the primary instance role resides by default at startup. It is designated by the user in the Oracle Real Application Clusters Guard configuration file. Oracle Real Application Clusters Guard ensures that the first instance to be started starts on the preferred primary node.

The preferred secondary node is the node where the pack with the secondary instance role resides by default at startup. It is designated by the user in the Oracle Real Application Clusters Guard configuration file. Oracle Real Application Clusters Guard starts the secondary instance on the preferred secondary node.

Real Application Clusters enforces a Primary/Secondary Configuration when the ACTIVE_INSTANCE_COUNT parameter in the initialization parameter file (init.ora) is set to 1. The user must set ACTIVE_INSTANCE_COUNT to 1 as shown in the sample configuration files provided with Oracle Real Application Clusters Guard.

The Oracle Net listener then enforces the routing of work requests to the primary and secondary instances by using the INSTANCE_ROLE parameter tnsnames.ora found in the CONNECT_DATA portion of the tnsnames.ora file.

All locks are mastered by the primary instance only. This minimizes communication between nodes and improves performance.

See Also:

Oracle Real Application Clusters Guard Administration and Reference Guide 

Home and Foreign Nodes

The home node (primary) is the default node for a specific pack. When the pack is not running on its home node, it is running on its foreign node (secondary). At initial startup, each pack runs on its home node.

When a pack runs on its foreign node, the only pack function that occurs is enabling the IP address. New connections that request this IP address are routed to the primary instance by the Oracle Net listener.

Architecture of Oracle Real Application Clusters Guard

Figure 11-2 shows Oracle Real Application Clusters Guard architecture for a two-node cluster. Node A is the primary node, and Node B is the secondary node. Each node contains:

The resources on each node include:

During failover, the primary instance role moves from Node A to Node B, making Node B the new primary node.

Figure 11-2 Oracle Real Application Clusters Guard Architecture for a Two-Node Cluster


Text description of pfscn026.gif follows
Text description of the illustration pfscn026.gif

This rest of this section contains the following topics:

Packs

A pack is software that ensures the availability of the resources required to run an Oracle instance. It supports and maintains access to the instance through the listeners. A pack controls the startup, shutdown, and restarting of Oracle processes. There is one pack for each instance.

Resources

Each pack controls the following resources on its node:

Listeners

The public listener connects a client to an instance. Private listeners are used by tools such as Oracle Enterprise Manager and Recovery Manager (RMAN) to connect to an instance. Private listeners can also be used by the database administrator for administration tasks.

IP Addresses

A relocatable IP address is a public IP address that is started by a Oracle Real Application Clusters Guard pack. A relocatable IP address can be moved among nodes to ensure that it is always available. The IP address is started as the first step when running the pack and is stopped as the last step when halting the pack. This ensures that the address is absent for as little time as possible.

A stationary, private IP address is configured for private tasks such as IPC, heartbeat, system management and RMAN operations. A private listener supports access to the instance through the private IP address.

Disk Storage

On platforms that activate and deactivate disk storage without affecting the status of existing disk storage, the pack controls the acquisition and release of disk storage on the home node.

Some platforms affect the status of existing disk storage when they activate and deactivate disk storage. In this case, the Cluster Manager acquires the disk storage in shared mode after the node is brought into the cluster.

Pack Functions

Packs do the following:

A pack starts up the Oracle instance and monitors the instance. If it determines that the instance has expired, then it ensures that the resources associated with that instance are moved to the secondary node and reenables service at the secondary node.

A pack can run on either its home node or its foreign node. When it is on its home node, it starts up and shuts down everything. When the pack is on its foreign node, it only starts and stops the IP address. This behavior reduces TCP/IP timeouts for new connections.

Monitors

Oracle Real Application Clusters Guard has three monitors. They are discussed in the following sections:

Instance Monitor

The instance monitor detects termination of the local instance and initiates failover or restarts the instance.


Note:

Because the instance monitor connects as a user session, its actions are reflected in database statistics such as enqueue waits. 


Listener Monitor

The listener monitor checks and restarts the public and private listeners on its own node. When the public listener fails to restart a configurable number of times within a configurable interval, the listener monitor exits, initiating a halt script. Oracle Real Application Clusters Guard either begins failover or restarts the primary instance, depending on the state of the secondary node.

Heartbeat Monitor

The heartbeat monitor checks the availability of the Oracle instance. The local Oracle instance is considered unavailable if the heartbeat monitor fails to complete after three consecutive attempts. During normal operation, the heartbeat monitor on each instance:

The heartbeat monitor on the primary instance also executes a customer query specified by the user. Executing the customer query tests whether the primary instance is capable of work.

The heartbeat monitor allows for special circumstances such as instance recovery and unusually large numbers of sessions logging on.

The heartbeat monitor also initiates one kind of failover action: If the primary instance is unavailable and the primary instance role has not resumed normal function on its new node, then the heartbeat monitor initiates takeover. A takeover occurs when the secondary node executes failover of the primary instance role to itself.

See Also:

Oracle Real Application Clusters Guard Administration and Reference Guide 

Additional Configurations of Oracle Real Application Clusters Guard

The two-node cluster configuration with one database, with one node serving as the primary node and the other node serving as the secondary node is an ideal configuration. Because it is ideal, users may need to use their resources more efficiently. Multiple installations of Oracle Real Application Clusters Guard can exist on a multinode cluster, so that nodes are shared by several database services. Two multinode configurations have been tested for Oracle Real Application Clusters Guard:

Although these configurations use resources more efficiently than a configuration with a single dedicated secondary node for each primary node, there are disadvantages to these configurations:

The following sections describe two tested configurations:

Hub Configuration

A hub configuration consists of one node that serves as the secondary node for other nodes that serve as primary nodes for separate installations of Oracle Real Application Clusters Guard databases. The simplest possible hub configuration consists of three nodes. Oracle Real Application Clusters Guard has been tested in a four-node hub configuration. Figure 11-3 shows that the primary instance for database A resides on Node 1, the primary instance for database B resides on Node 2, and the primary instance for database C resides on Node 3. The secondary instances for all three databases reside on Node 4.

Figure 11-3 Four-Node Hub Configuration for Oracle Real Application Clusters Guard Databases


Text description of pfscn023.gif follows
Text description of the illustration pfscn023.gif

In a stable, (or resilient) state, all primary instances run on their preferred primary nodes. When a failure on a primary node occurs, the primary instance fails over to its secondary instance on Node 4. A single failover has minimal impact on the other Oracle Real Application Clusters Guard installations, but if several failures occur, then performance may suffer. In addition, if Node 4 itself fails, then all of the Oracle Real Application Clusters Guard installations lose resilience.

Table 11-1 summarizes the advantages and disadvantages of a hub configuration.

Table 11-1 Hub Configuration Advantages and Disadvantages.

Advantages  Disadvantages 

Reduces use of resources: n+1 nodes for n databases 

The secondary node must be capable of handling all of the load for n services if all of them fail over at the same time. 

 

If the secondary node fails, then all of the Oracle Real Application Clusters Guard installations lose their resilience. 

 

It is more difficult to isolate failures. 

Ring Configuration

Another multinode configuration is the ring configuration. Each node contains a primary instance and serves as the secondary node for another node. The simplest possible ring configuration is the two-node ring configuration shown in Figure 11-4.

Figure 11-4 Two-Node Ring Configuration for Oracle Real Application Clusters Guard Databases


Text description of pfscn022.gif follows
Text description of the illustration pfscn022.gif

The primary instance for database A resides on Node 1, while the secondary instance for database A resides on Node 2. The primary instance for database B resides on Node 2, while the secondary instance for database B resides on Node 1.

Oracle Real Application Clusters Guard has been tested for a three-node ring configuration. This is shown in Figure 11-5.

Figure 11-5 Three-Node Ring Configuration for Oracle Real Application Clusters Guard


Text description of pfscn024.gif follows
Text description of the illustration pfscn024.gif

The primary instance for database A resides on Node 1, while the secondary instance for database A resides on Node 2. The primary instance for database B resides on Node 2, while the secondary instance for database B resides on Node 3. The primary instance for database C resides on Node 3, while the secondary instance for database C resides on Node 1.

Table 11-2 summarizes the advantages and disadvantages of a three-node ring configuration.

Table 11-2 Ring Configuration Advantages and Disadvantages

Advantages  Disadvantages 

All nodes hold equal roles. 

Failover results in two primary instances sharing a single node. Performance may suffer compared to a dedicated secondary configuration. 

More efficient use of resources than hub configuration because there are n nodes for n databases 

It is more difficult to isolate failures compared to a dedicated secondary configuration. 

Reduced resource requirement for a single node because only two primary instances must run on a single node. 

 


Go to previous page Go to next page
Oracle
Copyright © 1996-2001, Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Home
Go To Product List
Book List
Go To Table Of Contents
Contents
Go To Index
Index

Master Index

Feedback