Sun Cluster 3.0 Data Services Installation and Configuration Guide

Chapter 1 Planning for Sun Cluster Data Services

This chapter provides planning information and guidelines for installing and configuring Sun Cluster data services. It contains the following sections:

For conceptual information about data services, resource types, resources, and resource groups, see the Sun Cluster 3.0 Concepts document.

For applications not currently offered as Sun Cluster data services, see the Sun Cluster 3.0 Data Services Developers' Guide for information on how to configure those applications to become highly available data services.

Sun Cluster Data Services Installation and Configuration Tasks

Table 1-1 lists the chapters that describe the installation and configuration of Sun Cluster data services.

Table 1-1 Task Map: Installing and Configuring Sun Cluster Data Services


Task	For Instructions, Go To ...
Install and configure Sun Cluster HA for Oracle	Chapter 2, Installing and Configuring Sun Cluster HA for Oracle
Install and configure Sun Cluster HA for iPlanet^TM Web Server	Chapter 3, Installing and Configuring Sun Cluster HA for iPlanet Web Server
Install and configure Sun Cluster HA for Netscape Directory Server	Chapter 4, Installing and Configuring Sun Cluster HA for Netscape Directory Server
Install and configure Sun Cluster HA for Apache	Chapter 5, Installing and Configuring Sun Cluster HA for Apache
Install and configure Sun Cluster HA for DNS	Chapter 6, Installing and Configuring Sun Cluster HA for Domain Name Service (DNS)
Install and configure Sun Cluster HA for NFS	Chapter 7, Installing and Configuring Sun Cluster HA for Network File System (NFS)
Install and configure Sun Cluster HA for Oracle Parallel Server	Chapter 8, Installing and Configuring Sun Cluster HA for Oracle Parallel Server
Administer data services	Chapter 9, Administering Data Service Resources
Understand data service fault monitors	Chapter 10, Understanding Data Service Fault Monitors

Configuration Guidelines for Sun Cluster Data Services

This section provides configuration guidelines for Sun Cluster data services.

Determining the Location of the Application Binaries

The two locations where you can install the application software and application configuration files are: on the local disks of each cluster node or on the cluster file system. The advantage to placing the software and configuration files on the individual cluster nodes is that if you want to upgrade the application software later, you can do so without shutting down the cluster. The disadvantage is that you then have several copies of the software and configuration files to maintain and administer.

If you put the application binaries on the cluster file system, you have only one copy to maintain and manage, but you must shut down the data service in the entire cluster to upgrade the application software. If you can spare a small amount of downtime for upgrades, put a single copy of the application and configuration files on the cluster file system.

For information on creating cluster file systems, see the planning chapter of the Sun Cluster 3.0 Installation Guide.

Verifying the `nsswitch.conf` File Contents

The nsswitch.conf file is the configuration file for name service lookups. This file determines which databases within the Solaris environment to use for name service lookups and in what order to consult the databases.

For some data services, direct "group" lookups to "files" first. Change the "group" line in the file so that the "files" entry is listed first. To determine whether you need to change the "group" line, see the chapter for the data service you are configuring.

For additional information on how to configure nsswitch.conf for the Sun Cluster environment, see the planning chapter in the Sun Cluster 3.0 Installation Guide.

Planning the Cluster File System Configuration

Depending on the data service, you might need to configure the cluster file system to meet Sun Cluster requirements. To determine whether any special considerations apply, see the chapter for the data service you are configuring.

For information on creating cluster file systems, see the planning chapter of the Sun Cluster 3.0 Installation Guide.

Relationship Between Resource Groups and Disk Device Groups

Sun Cluster has the concept of a node list for disk device groups and resource groups. These node lists are ordered lists of nodes that are potential masters of the disk device group or resource group. Associated with the node list is a failback policy. This policy describes the action to be taken when the node that masters the disk device group or resource group (the primary) leaves the configuration and later rejoins-that is, whether the disk device group or resource group is once again mastered by the primary when it rejoins the cluster.

To ensure high availability of a failover resource group, make the group's node list match the node list of any associated disk device group. For a scalable resource group, the resource group's node list cannot always match the device group's node list because, currently, a device group's node list can contain exactly two nodes only. For a greater than two-node cluster, the node list for the scalable resource group can have more than two nodes.

For example, assume you have a disk device group dg-schost-1 that has nodes phys-schost-1 and phys-schost-2 in its node list and the failback policy is set to Enabled. Assume you also have a failover resource group, rg-schost-1, which uses dg-schost-1 to hold its application data. When you set up rg-schost-1, also specify phys-schost-1 and phys-schost-2 for its node list and set its failback policy to True.

To ensure high availability of a scalable resource group, make the group's node list a superset of the node list for the disk device group. Doing so ensures that the nodes that are directly connected to the disks are also nodes that can run the scalable resource group. The advantage is that, when at least one node connected to the data is up and in the cluster, the scalable resource group is running on those same nodes, making the scalable services available also.

For information on setting up disk device groups, refer to the Sun Cluster 3.0 Installation Guide. For more details on the relationship between disk device groups and resource groups, see the Sun Cluster 3.0 Concepts document.

`SUNW.HAStorage` Resource Type

The resource type SUNW.HAStorage serves the following purposes:

Coordinates the boot order by monitoring the global devices and cluster file systems and causing the START methods of the other resources in the same resource group that contains the SUNW.HAStorage resource to wait until the disk device resources become available.
With AffinityOn set to True, enforces colocation of resource groups and disk device groups on the same node, thus enhancing the performance of disk-intensive data services.

Note -

If the device group is switched to another node while the SUNW.HAstorage resource is online, AffinityOn has no effect and the resource group does not migrate along with the device group.

Recommendations

To determine whether to create SUNW.HAStorage resources within a data service resource group, consider the following criteria:

In cases where a data service resource group has a node list in which some of the nodes are not directly connected to the storage, you must configure SUNW.HAStorage resources in the resource group and set the dependency of the other data service resources to SUNW.HAStorage. This requirement is to coordinate the boot order between the storage and the data services.
If your data service is disk-intensive, such as Sun Cluster HA for Oracle and Sun Cluster HA for NFS, then we recommend that you add a SUNW.HAStorage resource to your data service resource group, set the dependency of your data service resources to the SUNW.HAStorage resource, and set AffinityOn to True. That way, the resource groups and disk device groups are colocated on the same node. On the other hand, if your data service is not disk-intensive-such as one that reads all its files at startup (for example, Sun Cluster HA for DNS), configuring SUNW.HAStorage is optional.
If your cluster contains only two nodes, configuring SUNW.HAStorage is optional. However, if you plan to add nodes and run scalable services later on, you must configure SUNW.HAStorage at that time. To get prepared, you can go ahead and set up SUNW.HAStorage now and add nodes to the node list later.

See the individual chapters on data services in this document for specific recommendations.

For the procedure on how to set up SUNW.HAStorage, see "How to Set Up SUNW.HAStorage Resource Type for New Resources". Additional details are in the SUNW.HAStorage(5) man page.

Node List Properties

You can specify three node lists when configuring data services:

installed_nodes - A property of the resource type. This property is a list of the cluster node names on which the resource type is allowed to be run.
nodelist - A property of a resource group. A list of cluster node names where the group can be brought online, in order of preference. These nodes are known as the potential primaries or masters of the resource group. For failover services, you configure only one resource group node list. For scalable services, you configure two resource groups and thus two node lists. One lists the nodes on which the shared addresses are hosted. This list is a failover resource group on which the scalable resources depend. The other is a list of nodes on which the application resources are hosted. The node list for the resource group that contains the shared addresses must be a superset of the node list for the application resources because the application resources depend on the shared addresses.
auxnodelist - A property of a resource group that contains shared addresses. This property is a list of physical node IDs that identify cluster nodes that can host the shared address but never serve as primary in the case of failover. These nodes are mutually exclusive with the nodes identified in the node list of the resource group. These auxiliary nodes can never serve as masters of the resource group. This list pertains to scalable services only.

Overview of the Installation and Configuration Process

You use three procedures to install and configure data services, as follows:

Install the data service packages from the Sun Cluster data services CD.
Install and configure the application to run in the cluster environment.
Configure the resources and resource groups used by the data service. When you configure a data service, you specify the resource types, resources, and resource groups to be managed by the Resource Group Manager (RGM). These procedures are described in the chapters for each of the data services.

Before installing and configuring data services, see the Sun Cluster 3.0 Installation Guide, which includes procedures on how to install the data service software packages and how to configure Network Adapter Failover (NAFO) groups used by the network resources.

Installation and Configuration Task Flow

Table 1-2 shows a task map of the procedure for installing and configuring a Sun Cluster failover data service.

Table 1-2 Task Map: Sun Cluster Data Service Installation and Configuration


Task	For Instructions, Go to ...
Install Solaris and Sun Cluster	Sun Cluster 3.0 Installation Guide
Set up NAFO groups	Sun Cluster 3.0 Installation Guide
Set up multihost disks	Sun Cluster 3.0 Installation Guide
Plan resources and resource groups	Sun Cluster 3.0 Release Notes
Decide the location for application binaries; configure the `nsswitch.conf` file	Chapter 1, Planning for Sun Cluster Data Services
Install and configure the application software	The chapter for each data service in this book.
Install the data service software packages	Sun Cluster 3.0 Installation Guide or the chapter for each data service in this book.
Register and configure the data service	The chapter for each data service in this book.

Example

This example in this section shows how you might set up the resource types, resources, and resource groups for an Oracle application that has been instrumented to be a highly available failover data service.

The main difference between this example and an example of a scalable data service is that, in addition to the failover resource group that contains the network resources, a scalable data service requires a separate resource group (called a scalable resource group) for the application resources.

The Oracle application has two components, a server and a listener. Sun Cluster HA for Oracle is a Sun-supplied data service so these components have already been mapped into Sun Cluster resource types. Both of these resource types are associated with resources and resource groups.

Because this example is a failover data service, it uses logical host name network resources, which are the IP addresses that fail over from a primary node to a secondary node. You place the logical host name resources into a failover resource group and then place the Oracle server resources and listener resources into the same resource group. This ordering enables all of the resources to fail over as a group.

To have the HA Oracle data service run on the cluster, you must define the following objects:

LogicalHostname resource type - This resource type is built in so you need not define it explicitly.
Oracle resource types - Sun Cluster HA for Oracle defines two Oracle resource types, a database server and a listener.
Logical host name resources - These resources host the IP addresses that fail over in the event of a node failure.
Oracle resources - You must specify two resource instances for Sun Cluster HA for Oracle, a server and a listener.
Failover resource group - This container is composed of the Oracle server and listener and logical host name resources that will fail over as a group.