Oracle9i Real Application Clusters Concepts Release 1 (9.0.1) Part Number A89867-02 |
|
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 11-1 shows the relationship between these components of Oracle Real Application Clusters Guard to the Cluster Manager (CM).
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:
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 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.
Oracle Real Application Clusters Guard has three monitors:
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:
|
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:
|
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 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 enabling the IP address. New connections that request this IP address are routed to the primary instance by the Oracle Net listener.
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.
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.
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.
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.
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.
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.
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 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 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.
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.
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.
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.
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
|
Copyright © 1996-2001, Oracle Corporation. All Rights Reserved. |
|