Release 2 (9.2)
Part Number A96601-01
 Home |
 Book List |
 Contents |
 Index |
 Master Index |
 Feedback |
| Oracle9i Real Application Clusters Real Application Clusters Guard I - Concepts and Administration Release 2 (9.2) Part Number A96601-01 |
|
This chapter describes the architecture of Oracle Real Application Clusters Guard. It includes the following topics:
Oracle Real Application Clusters Guard works with Real Application Clusters and the port-specific cluster manager to monitor and maintain availability. Figure 1-1 shows the relationship between these components of Oracle Real Application Clusters Guard to the cluster manager.
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 software that ensures 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. 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:
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:
The PFSCTL control utility 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.
Oracle Real Application Clusters Guard has three monitors. They are described in the following table.
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 PFSSETUP 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:
|
The PFSSETUP utility assists with the generation of appropriate Oracle Real Application Clusters Guard 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:
|
The concepts described in the following sections are important for understanding Oracle Real Application Clusters Guard architecture:
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.
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 that 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.
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 configuring the relocatable IP address to be up. New connections that request this IP address are routed to the primary instance by the Oracle Net listener.
Figure 1-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.
This rest of this section contains the following topics:
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.
Each pack controls the following resources on its node:
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.
Clients can use the pack's relocatable IP address to access the resources managed by the pack. A relocatable IP address is not associated with a specific physical server; it can float between physical servers. The relocatable IP address is initially associated with only the primary node. If the primary node fails, then the relocatable IP address fails over to a different cluster node (a secondary node). The relocatable IP address is configured to be up as the first step when the pack is running and is configured to be down as the last step when the pack is halted.
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.
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 configures the relocatable IP address to be up or down.
Oracle Real Application Clusters Guard has three monitors. They are discussed in the following sections:
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. |
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.
The heartbeat monitor checks the availability of the Oracle instance. The local Oracle instance is considered unavailable if the heartbeat monitor fails to complete its tasks 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.
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:
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 1-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.
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 1-1 summarizes the advantages and disadvantages of a hub configuration.
Table 1-1 Hub Configuration Advantages and Disadvantages.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 1-4.
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 1-5.
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 1-2 summarizes the advantages and disadvantages of a three-node ring configuration.
Table 1-2 Ring Configuration Advantages and Disadvantages
|
 Copyright © 2001, 2002 Oracle Corporation. All Rights Reserved. |
|
