Configuration Planning Questions

Use the questions in the subsections that follow to plan the installation and configuration of Sun Cluster Support for Oracle Real Application Clusters. Write the answers to these questions in the space that is provided on the data service worksheets in “Configuration Worksheets” in Sun Cluster 3.1 Data Service Planning and Administration Guide.

Resource Groups for Oracle RAC Server Resources

Which resource groups will you use for the Oracle Real Application Clusters (RAC) server resources?

You require one resource group for each Oracle Real Application Clusters database instance. Each resource group contains the Oracle RAC server resource for the database instance.

Use the answer to this question when you perform the procedure in Registering and Configuring Oracle RAC Server Resources.

Resource Groups for Oracle Listener Resources

Which resource groups will you use for the Oracle listener resources?

Use the answer to this question when you perform the procedure in Registering and Configuring Oracle Listener Resources.

The resource groups depend on your configuration of Oracle listeners with Real Application Clusters database instances. For general information about possible configurations of listeners for Real Application Clusters instances, see your Oracle documentation. Example configurations are described in the subsections that follow.

One Listener For One Real Application Clusters Instance

One listener serves only one Real Application Clusters instance. The listener listens on the fixed Internet Protocol (IP) address of the node. The listener cannot fail over.

In this situation, configure the listener resource as follows:

• Configure the listener resource and the RAC server resource in the same resource group.

• Ensure that this resource group is mastered on only one node.

One Listener That Cannot Fail Over for Several Real Application Clusters Instances

One listener serves several Real Application Clusters instances on the same node. The listener uses Oracle's transparent application failover (TAF) and load balancing to distribute client connections across all Real Application Clusters instances. The listener cannot fail over.

In this situation, configure the listener resource as follows:

• Configure the listener resource in its own resource group.

• Ensure that the listener's resource group is mastered on only one node.

• Create a dependency between the listener's resource group and RAC servers' resource groups.

One Listener That Can Fail Over for Several Real Application Clusters Instances

One listener that can fail over serves several Real Application Clusters instances on the same node. When the listener fails over to another node, the listener serves several Real Application Clusters instances on the other node.

The listener uses Oracle's TAF and load balancing to distribute client connections across all Real Application Clusters instances. To ensure fast error detection and short failover times, the listener listens on an address that is represented by a LogicalHostname resource.

In this situation, configure the listener resource as follows:

• Configure the listener resource and the LogicalHostname resource in the same resource group.

• Ensure that this resource group is mastered on the nodes on which Oracle Real Application Clusters is running.

For more information, see LogicalHostname Resources for Oracle Listener Resources.

One Listener for the Entire Cluster

One listener serves all Real Application Clusters instances on all nodes. The listener listens on an address that is represented by a LogicalHostname resource. This configuration ensures that the address is plumbed very quickly on another node after a node fails.

You can use this configuration if you configure Real Application Clusters instances to use a multithreaded server (MTS). In such a configuration, the REMOTE_LISTENERS parameter in the init.ora file specifies that each dispatcher registers with the listener on a logical IP address.

All clients connect through the one listener. The listener redirects each client connection to the least busy dispatcher. The least busy dispatcher might be on a different node from the listener.

If the listener fails, the listener's fault monitor restarts the listener. If the node where the listener is running fails, the listener is restarted on a different node. In both situations the dispatchers reregister after the listener is restarted.

If you are using one listener for the entire cluster, configure the following resources in the same resource group:

• The listener resource

• The LogicalHostname resource

For more information, see LogicalHostname Resources for Oracle Listener Resources.

LogicalHostname Resources for Oracle Listener Resources

Which LogicalHostname resources will Oracle listener resources use?

Use the answer to this question when you perform the procedure in Registering and Configuring Oracle Listener Resources.

If a cluster node that is running an instance of Oracle Real Application Clusters fails, an operation that a client application attempted might be required to time out before the operation is attempted again on another instance. If the Transmission Control Protocol/Internet Protocol (TCP/IP) network timeout is high, the client application might require a significant length of time to detect the failure. Typically, client applications require between three and nine minutes to detect such failures.

In such situations, client applications can connect to listener resources that are listening on an address that is represented by the Sun Cluster LogicalHostname resource. Configure the LogicalHostname resource and the listener resource in a separate resource group. Ensure that this resource group is mastered on the nodes on which Oracle Real Application Clusters is running. If a node fails, the resource group that contains the LogicalHostname resource and the listener resource fails over to another surviving node on which Oracle Real Application Clusters is running. The failover of the LogicalHostname resource enables new connections to be directed to the other instance of Oracle Real Application Clusters.

Resources for the Sun StorEdge QFS Shared File System

If you are using the Sun StorEdge QFS shared file system, answer the following questions:

• Which resources will you create to represent the metadata server for the Sun StorEdge QFS shared file system?

  One resource is required for each Sun StorEdge QFS metadata server.

• Which resource groups will you use for these resources?

For more information, see the following documentation for Sun StorEdge QFS:

• Sun StorEdge QFS and Sun StorEdge SAM-FS Software Installation and Configuration Guide

• Sun StorEdge QFS and Sun StorEdge SAM-FS File System Administration Guide

Use the answers to these questions when you perform the procedure in Registering and Configuring Oracle RAC Server Resources.

Location of System Configuration Files

Where will the system configuration files reside?

For the advantages and disadvantages of using the local file system instead of the cluster file system, see Location of Oracle Binary Files and Oracle Configuration Files.