Sun Cluster 3.0 5/02 Release Notes Supplement

This document supplements the standard user documentation, including the Sun Cluster 3.0 5/02 Release Notes that shipped with the Sun™ Cluster 3.0 product. These “online release notes” provide the most current information on the Sun Cluster 3.0 product. This page includes the following information.

• Revision Record
• New Features
• Restrictions and Requirements
• Known Problems
• Known Documentation Problems

Top

Revision Record

The following tables list the information contained in this document and provides the revision date for this information.

Sun Cluster 3.0 5/02 Release Notes Supplement Revision Record: 2006

Top

New Features

In addition to features documented in Sun Cluster 3.0 5/02 Release Notes, this release now includes support for the following features.

Top

SPARC: Support for VxVM 4.0 and VxFS 4.0

A patch to Sun Cluster 3.0 software adds support on Sun Cluster 3.0 5/02 configurations for Veritas Volume Manager 4.0 and Veritas File System 4.0 software. Download and install the latest Sun Cluster 3.0 Core/Sys Admin patch from http://www.sunsolve.com. This support addition is associated with Bug ID 4978425.

Top

Support for Oracle 10g

The Sun Cluster HA for Oracle data service in Sun Cluster 3.0 5/02 now supports Oracle 10g.

If you are using Sun Cluster HA for Oracle with Oracle 10g, an attempt by the init(1M) command to start the Oracle cssd daemon might cause unnecessary error messages to be displayed. These error messages are displayed if the Oracle binary files are installed on a highly available local file system or on the cluster file system. The messages are displayed repeatedly until the file system where the Oracle binary files are installed is mounted.

These error messages are as follows:

These messages are displayed if the following events occur:

• A node is running in noncluster mode. In this situation, file systems that Sun Cluster controls are never mounted.
• A node is booting. In this situation, the messages are displayed repeatedly until Sun Cluster mounts the file system where the Oracle binary files are installed.
• Oracle is started on or fails over to a node where the Oracle installation was not originally run. In such a configuration, the Oracle binary files are installed on a highly available local file system. In this situation, the messages are displayed on the console of the node where the Oracle installation was run.

To prevent these error messages, remove the entry for the Oracle cssd daemon from the /etc/inittab file on the node where the Oracle software is installed. To remove this entry, remove the following line from the /etc/inittab file:

Sun Cluster HA for Oracle does not require the Oracle cssd daemon. Therefore, removal of this entry does not affect the operation of Oracle 10g with Sun Cluster HA for Oracle. If your Oracle installation changes so that the Oracle cssd daemon is required, restore the entry for this daemon to the /etc/inittab file.

Top

Sun Cluster Support for Oracle Real Application Clusters on a Subset of Cluster Nodes

To enable Sun Cluster Support for Oracle Real Application Clusters on a subset of cluster nodes, see Sun Cluster Support for Oracle Real Application Clusters on a Subset of Cluster Nodes.

Top

Support for Veritas NetBackup 4.5

The Sun Cluster HA for NetBackup data service in Sun Cluster 3.0 5/02 now supports Veritas NetBackup 4.5.

After you install and configure Sun Cluster 3.1, use the following procedure and your Veritas documentation to install and configure Veritas Netbackup.

Top

Installing Veritas Netbackup

How to Install Veritas Netbackup

In the examples throughout this procedure, the name nb-master refers to the cluster node that masters NetBackup, and slave-1 refers to the media server.

Before You Begin

You must have the following information to perform this procedure.

• A list of cluster nodes that can master the data service.
• The network resource that clients use to access the data service. Normally, you set up this IP address when you install the cluster. See the Sun Cluster concepts documentation document for details on network resources.

1. Ensure that Sun Cluster is running on all of the nodes.
   
2. Create a failover resource group to hold the network and application resources.
   
   You can optionally select the set of nodes that the data service can run on with the -h option, as follows.
   

   # scrgadm -a- -g- resource-group [-h- nodelist]

   -g resource-group

   Specifies the name of the resource group.

   [-h nodelist]

   Specifies an optional comma-separated list of physical node names or IDs that identify potential masters. The order here determines the order in which the nodes are considered as primary during failover. If all of the nodes in the cluster are potential masters, you do not need to use the -h option.

3. Verify that you have added all of your network resources to the name service database.
   
   You should have performed this verification during the Sun Cluster installation.
   

   Note Ensure that all of the network resources are present in the server's and client's /etc/inet/hosts file to avoid any failures because of name service lookup.

4. Add a logical host resource to the resource group.
   

   # scrgadm -a -L -g resource-group -l logical-hostname

5. Enable the failover resource group and bring the resource group online.
   

   # scswitch -Z -g resource-group

   -g resource-group

   Specifies the name of the resource group.

   -Z	Moves the resource group to the managed state, and brings the resource group online.

6. Log on to the node that masters the logical host resource.
   
7. Execute the install script to install the Veritas Netbackup packages from the Veritas product CD-ROM into the /usr/openv directory.
   

   phys-schost-1# ./install

8. When the menu appears, choose Option 1 (NetBackup).
   
   This option installs both the Media Manager and the NetBackup software on the server.
   
9. Follow the prompts in the installation script.
   
   The installation script adds entries to the /etc/services and /etc/inetd.conf files.
   

   phys-schost-1# ./install
   ...
   Would you like to use "phys-schost-1.somedomain.com" as the
   configured name of the NetBackup server? (y/n) [y] n
   ...
   Enter the name of the NetBackup server: nb-master
   ...
   Is nb-master the master server? (y/n) [y] y
   ...
   Enter the fully qualified name of a media (slave) server (q to quit)?
   slave-1

10. Switch the NetBackup resource to the backup node
    
11. Repeat Step 6 through Step 10 until you install the NetBackup binaries on all the nodes that will run the NetBackup resource.
    

Top

Enabling NetBackup to Run on a Cluster

This section contains the procedure you need to enable NetBackup to run on a cluster.

How to Enable NetBackup to Run on a Cluster

In the examples throughout this procedure, the name nb-master refers to the cluster node that masters NetBackup, and slave-1 refers to the media server.

1. Remove the /etc/rc2.d/S77netbackup and /etc/rc0.d/K77netbackup files from each cluster node on which Sun Cluster HA for NetBackup is installed.
   
   If you remove these files, you prevent NetBackup from starting at boot time.
   
2. On one node, modify the /usr/openv/netbackup/bp.conf file to specify the following information.
   
   • SERVER = logical-hostname-resource
     
     All requests to the backup server originate from the primary node. The server name equals the logical hostname resource.
   • CLIENT_NAME = logical-hostname-resource
     
     On a cluster that runs Sun Cluster HA for NetBackup, the CLIENT_NAME equals nb-master.

     Note Use this client name to back up files in the cluster running Sun Cluster HA for NetBackup.

   • REQUIRED_INTERFACE = logical-hostname-resource
     
     This entry indicates the logical interface that the NetBackup application is to use.
     The resulting file should resemble the following example.
     

     SERVER = nb-master
     SERVER = slave-1
     CLIENT_NAME = nb-master
     REQUIRED_INTERFACE = nb-master

3. From one node, put the NetBackup configuration files on a multihost disk.
   
   Place the files on a disk that is part of a failover disk device group that NetBackup is to use.
   
   1. Run the following commands from the primary node of the failover disk device group. In this example, the failover disk device group is global.
      

      # mkdir /global/netbackup
      # mv /usr/openv/netbackup/bp.conf /global/netbackup
      # mv /usr/openv/netbackup/db /global/netbackup
      # mv /usr/openv/volmgr/database /global/netbackup
      # ln -s /global/netbackup/bp.conf /usr/openv/netbackup/bp.conf
      # ln -s /global/netbackup/db /usr/openv/netbackup/db
      # ln -s /global/netbackup/database /usr/openv/volmgr/database

   2. If the directory /usr/openv/db/var and the file /usr/openv/volmgr/vm.conf exist on the node, move them to the disk that is part of the failover disk device group.
      
      You must configure the NetBackup master server before you move and link /usr/openv/volmgr/vm.conf file.
      

      # mv /usr/openv/db/var /global/netbackup/nbdb
      # mv /usr/openv/volmgr/vm.conf /global/netbackup
      # ln -s /global/netbackup/nbdb /usr/openv/db/var
      # ln -s /global/netbackup/vm.conf /usr/openv/volmgr/vm.conf

      Note Run the command scstat -D to identify the primary for a particular disk device group.

   3. Run the following commands from all of the other nodes that will run the NetBackup resource.
      

      # rm -rf /usr/openv/netbackup/bp.conf
      # rm -rf /usr/openv/netbackup/db
      # rm -rf /usr/openv/volmgr/database
      # ln -s /global/netbackup/bp.conf /usr/openv/netbackup/bp.conf
      # ln -s /global/netbackup/db /usr/openv/netbackup/db
      # ln -s /global/netbackup/database /usr/openv/volmgr/database

   4. On all of the other nodes that will run the NetBackup resource, if the directory /usr/openv/db/var and the file /usr/openv/volmgr/vm.conf exist on the node, run the following commands:
      

      # rm -rf /usr/openv/db/var
      # rm -rf /usr/openv/volmgr/vm.conf
      # ln -s /global/netbackup/nbdb /usr/openv/db/var
      # ln -s /global/netbackup/vm.conf /usr/openv/volmgr/vm.conf

      Note You must configure the NetBackup master server before you remove and link /usr/openv/volmgr/vm.conf file.

Top

Fault Monitoring Sun Cluster HA for NetBackup

Depending on the installed version of NetBackup, NetBackup application startup starts one of the following sets of daemons:

• vmd, bprd, and bpdbm
• vmd, bprd, bpdbm, bpjobd, and nbdbd

Sun Cluster HA for NetBackup can work with either of these two sets of daemons. The Sun Cluster HA for NetBackup fault monitor monitors either of these two sets of processes. While the START method runs, the fault monitor waits until the daemons are online before monitoring the application. The Probe_timeout extension property specifies the amount of time that the fault monitor waits.

After the daemons are online, the fault monitor uses kill (pid, 0) to determine whether the daemons are running. If any daemon is not running, the fault monitor initiates the following actions, in order, until all of the probes are running successfully.

1. Restarts the resource on the current node.
2. Restarts the resource group on the current node.
3. Fails over the resource group to the next node on the resource group's nodelist.

All process IDs (PIDs) are stored in a temporary file, /var/run/.netbackup_master.

Top

Security Hardening for Solaris 9

Sun Cluster Security Hardening now supports data services in a Solaris 8 and Solaris 9 environment. The Sun Cluster Security Hardening documentation is available athttp://www.sun.com/security/blueprints. From this URL, scroll down to the Architecture heading to locate the article “Securing the Sun Cluster 3.0 Software.”

Top

Failover File System (HAStoragePlus)

Failover File System (HAStoragePlus) is now supported in Sun Cluster 3.0 5/02 release. See the Sun Cluster 3.0 5/02 Supplement for information about this new feature.

The FilesystemMountPoints extension property can be used to specify a list of one or more file system mount points. This list can consist of both local and global file system mount points.

Top

RAID 5 on Sun StorEdge 99x0 Storage Arrays

RAID level 5 is supported on Sun StorEdge 99x0 storage arrays with multipathing and Sun adapters.

Top

Apache 2.0

Sun Cluster 3.0 5/02 now supports Apache version 2.0. For Apache version 2.0, the procedure for configuring the httpd.conf configuration file has changed as follows. (See the Sun Cluster data services collection for the complete procedure.)

• The ServerName directive specifies the hostname and the port.
• The BindAddress and Port directives have been replaced with the Listen directive. The Listen directive must use the address of the logical host or shared address.
• The Servertype directive no longer exists.

Top

New Guidelines for the swap Partition

The amount of swap space allocated for Solaris and Sun Cluster software combined must be no less that 750 Mbytes. For best results, add at least 512 Mbytes for Sun Cluster software to the amount required by the Solaris Operating System. In addition, allocate additional swap space for any third-party applications you install on the node that also have swap requirements. See your third-party application documentation for any swap requirements.

Top

Support for Oracle Real Application Clusters on the Cluster File System

You can use Oracle Real Application Clusters with the cluster file system.

Top

Pre-Installation Considerations

Oracle Real Application Clusters is a scalable application that can run on more than one node concurrently. You can store all of the files that are associated with this application on the cluster file system, namely:

• Binary files
• Control files
• Data files
• Log files
• Configuration files

For optimum I/O performance during the writing of redo logs, ensure that the following items are located on the same node:

• The Oracle Real Application Clusters database instance
• The primary of the device group that contains the cluster file system that holds the following logs of the database instance:
  • Online redo logs
  • Archived redo logs

For other pre-installation considerations that apply to Sun Cluster Support for Oracle Real Application Clusters, see Overview of the Installation and Configuration Process in Sun Cluster 3.0 12/01 Data Services Installation and Configuration Guide.

Top

How to Use the Cluster File System

To use the cluster file system with Oracle Real Application Clusters, create and mount the cluster file system as explained in Configuring the Cluster in Sun Cluster Software Installation Guide for Solaris OS. When you add an entry to the /etc/vfstab file for the mount point, set UNIX file system (UFS) file system specific options for various types of Oracle files as shown in the following table.

UFS File System Specific Options for Oracle Files

How to Install Sun Cluster Support for Oracle Real Application Clusters Packages With the Cluster File System

To complete this procedure, you need the Sun Cluster 3.0 5/02 Agents CD-ROM. Perform this procedure on all of the cluster nodes that can run Sun Cluster Support for Oracle Real Application Clusters.

1. Load the Sun Cluster 3.0 5/02 Agents CD-ROM into the CD-ROM drive.
   
2. Become superuser.
   
3. On all of the nodes, run the following command to install the data service packages.
   

   # pkgadd -d \
     /cdrom/scdataservices_3_0_u3/components/\
     SunCluster_Oracle_Parallel_Server_3.0_u3/Packages \
     SUNWscucm SUNWudlm SUNWudlmr

Troubleshooting

Before you reboot the nodes, you must ensure that you have correctly installed and configured the Oracle UDLM software. For more information, see Installing the Oracle Software in Sun Cluster 3.0 12/01 Data Services Installation and Configuration Guide.

See Also

Go to Installing the Oracle Software in Sun Cluster 3.0 12/01 Data Services Installation and Configuration Guide to install the Oracle UDLM and Oracle RDBMS software.

Top

Restrictions and Requirements

The following restrictions and requirements have been added or updated since the Sun Cluster 3.0 12/01 release.

Top

Compiling Data Services That Are Written in C++

If you are using Sun Cluster 3.0 and are writing data services in C++, you must compile these data services in compatibility mode.

Top

Reserved RPC Program Numbers

If you install an RPC service on the cluster, the service must not use any the following program numbers:

• 100141
• 100142
• 100248

These numbers are reserved for the Sun Cluster daemons rgmd_receptionist, fed, and rgmd, respectively. If the RPC service you install also uses one of these program numbers, you must change that RPC service to use a different program number.

Top

Dynamic Multipathing (DMP)

With VxVM 3.2 or later, Dynamic Multipathing (DMP) cannot be disabled with the scvxinstall command during VxVM installation. This procedure is described in the chapter, Installing and Configuring Veritas Volume Manager in Sun Cluster software installation documentation. The use of DMP is supported in the following configurations:

• A single I/O path per node to the cluster's shared storage
• A supported multipathing solution (Sun StorEdge Traffic Manager, EMC PowerPath, Hitachi HDLM) that manages multiple I/O paths per node to the shared cluster storage

The use of DMP alone to manage multiple I/O paths per node to the shared storage is not supported.

Top

Changing Quorum Device Connectivity

When you increase or decrease the number of node attachments to a quorum device, the quorum vote count is not automatically recalculated. You can reestablish the correct quorum vote if you remove all quorum devices and then add them back into the configuration.

Top

Storage Topologies Replaced by New Requirements

Sun Cluster 3.1 04/04 software now supports open topologies. You are no longer limited to the storage topologies listed in the Sun Cluster concepts documentation document.

Use the following guidelines to configure your cluster.

• Sun Cluster supports a maximum of eight nodes in a cluster, regardless of the storage configurations that you implement.
• A shared storage device can connect to as many nodes as the storage device supports.
• Shared storage devices do not need to connect to all nodes of the cluster. However, these storage devices must connect to at least two nodes.

Top

Shared Storage Restriction Relaxed

Sun Cluster 3.1 04/04 now supports greater than three-node cluster configurations without shared storage devices. Two-node clusters are still required to have a shared storage device to maintain quorum. This storage device does not need to perform any other function.

Top

EMC Storage Restriction

The quorum device access mode is not automatically set to scsi-3 in the following situations:

• After applying the core patch 110648-20 or later in a two node cluster with an EMC Powerpath configured quorum disk.
• After upgrading from Sun Cluster 3.0 12/01 software to Sun Cluster 3.0 05/02 software in a two node cluster with an EMC Powerpath configured quorum disk.

  Note This is a problem only for a multipath quorum device configured with EMC Powerpath in a two node configuration. The problem is characterized by a value of NULL being printed for the quorum device access mode property.

To fix the property setting after applying the patch or performing the upgrade, use the scsetup command to remove the existing quorum disk and add it back to the configuration. Removing and adding back the quorum disk will correct the Sun Cluster software to use scsi-3 PGR for reserving quorum disks. To verify that the quorum device access mode is set correctly, run scconf -p to print the configuration.

Top

Framework Restrictions and Requirements

• Upgrade to Solaris 9 – Upgrade to Solaris 9 software during upgrade to Sun Cluster 3.0 5/02 software is not supported. You can only upgrade to subsequent, compatible versions of the Solaris 8 Operating System during upgrade to Sun Cluster 3.0 5/02 software. To run Sun Cluster 3.0 5/02 software on the Solaris 9 Operating System, you must perform a new installation of the Solaris 9 version of Sun Cluster 3.0 5/02 software after the nodes are upgraded to Solaris 9 software.
• IPv6 – This is not supported.
• IP Network Multipathing – This is not supported.

Top

Oracle UDLM Requirement

Oracle RAC running on Sun Cluster software requires that the Oracle UDLM be at least version 3.3.4.5, which ships with the Oracle 9.2 release.

You can determine the version of Oracle UDLM currently installed on your system by running the following command.

The version of the Oracle UDLM currently installed on your system also appears in the file /var/cluster/ucmm/dlm_node-name/logs/dlmstart.log.

The version information appears just before the Copyright (c) line. Look for the latest occurrence of this information in the file. If you do not have this version of the Oracle UDLM package, please contact Oracle Support to obtain the latest version.

Top

Fixed Problems

Top

BugId 4818874

Problem Summary: When used in a clustered environment, the Sun StorEdge 3310 JBOD array relies on the cluster nodes to provide SCSI bus termination. Because termination power was not supplied from the array's “IN” ports, if the server connected to these ports lost power then SCSI bus termination was lost. This in turn could result in the remaining cluster node losing access to the shared storage on that bus.

Problem Fixed: The StorEdge 3310 JBOD array is now supported in a split-bus configuration, when using the updated version (part number 370-5396-02/50 or newer) of the I/O board.

Top

Known Problems

In addition to known problems documented in Sun Cluster 3.0 5/02 Release Notes, the following known problems affect the operation of the Sun Cluster 3.0 12/01 release.

Top

Bug ID 4346123

Problem Summary: When booting a cluster node after multiple failures, a cluster file system might fail to mount automatically from its /etc/vfstab entry, and the boot process will place the node in an administrative shell. Running the fsck command on the device might yield the following
error.

Workaround: This problem might occur when the global device is associated with a stale cluster file system mount. Run the following command, and check if the file system shows up in an error state to confirm a stale mount.

If the global device is associated with a stale cluster file system mount, unmount the global device. If any users of the file system exist on any of the nodes, the unmount cannot succeed. Run the following command on each node to identify current users of the file system.

If there are users of the file system, terminate those users' connection to the file system. Run the share(1M) command to confirm that the file system is not NFS- shared by any node.

Top

Bug ID 4662264

Problem Summary: To avoid panics when using VxFS with Sun Cluster software, the default thread stack size must be greater than the VxFS default value of 0x4000.

Workaround: Increase the stack size by putting the following lines in the /etc/system file:

After installing VxFS packages, verify that VxFS installation has not added similar statements to the /etc/system file. If multiple entries exist, resolve them to one statement per variable, using these higher values.

Top

Bug ID 4665886

Problem Summary: Mapping a file into the address space with mmap(2) and then issuing a write(2) call to the same file results in a recursive mutex panic. This problem was identified in a cluster configuration running the iPlanet™ Mail Server.

Workaround: There is no workaround.

Top

Bug ID 4668496

Problem Summary: The default JumpStart™ profile file allocates 10 Mbytes to slice 7. If you use Solaris 9 software with Solstice DiskSuite, this amount of space is not enough for Solstice DiskSuite replicas. Solaris 9 software with Solstice DiskSuite requires at least 20 Mbytes.

Workaround: Edit the default profile file to configure slice 7 of the system disk with 20 Mbytes of space, instead of 10 Mbytes. This workaround is only necessary if you install Solaris 9 software with Solstice DiskSuite

Top

Bug ID 4680862

Problem Summary: When you install Oracle or Sybase binaries and configuration files on a highly available local file system managed by HAStoragePlus, the node that does not have access to this file system fails validation. The result is that you cannot create the resource.

Workaround: Create a symbolic link named /usr/cluster/lib/hasp_check to link to the /usr/cluster/lib/scdsbuilder/src/scripts/hasp_check file.

Top

Bug ID 4779686

Problem Summary: Availability Suite 3.1 does not support the Sun Cluster 3.0 HAStoragePlus resource.

Workaround: If you intend to implement Availability Suite 3.1 and failover file system, use an HAStorage resource in the light-weight resource group that includes the Availability Suite logical host. For the application resource group, use HAStoragePlus. This allows you to use a failover file system for application performance and also use Availability Suite 3.1 to back up the disk blocks under the failover file system.

Top

BugId 4836405

Problem Summary: When using the PCI Dual Ultra3 SCSI host adapter in a clustered environment, the host adapter jumpers for each port must be set for manual SCSI termination. If the ports are not set to manual SCSI termination, a loss of power to one host could prevent correct SCSI bus operation and might result in loss of access to all SCSI devices attached to that bus from the remaining host.

Workaround: When using the PCI Dual Ultra3 SCSI host adapter in a clustered environment, set the jumpers on the host adapter to manual SCSI termination. This setting causes the host adapter to activate its built-in SCSI terminators, whether or not the host adapter receives PCI bus power.

The jumper settings needed for manual termination are listed below.

• SCSI bus 2 (external SCSI connector nearest to the PCI slot)
  • J4: 2-3 (factory default 2-3)
  • J5: 2-3 (factory default 2-3)

SCSI bus 1 (internal SCSI connector and external SCSI connector furthest from the PCI slot)

• • J8: 2-3 (factory default 1-2)
  • J9: 2-3 (factory default 1-2)

See the host adapter documentation for further information.

Top

BugID 4838619

Problem Summary: Without a patch, Sun Cluster software will not recognize bge(7D) Ethernet adapters.

Workaround: If you plan to use bge(7D) Ethernet adapters as cluster interconnects in your Sun Cluster configuration, you will need to install patches and use a modified installation procedure. The onboard Ethernet ports on the Sun Fire V210 and V240 are examples of bge(7D) Ethernet adapters.

If you use Solaris 8 software, install the following patches.

• 110648-28 or later (Sun Cluster 3.0: Core/Sys Admin)
• 112108-07 or later (Required for SunPlex Manager use)

If you use Solaris 9, install the following patches.

• 112563-10 or later (Sun Cluster 3.0: Core/Sys Admin)
• 114189-01 or later (Required for SunPlex Manager use)

For the modified installation procedure, refer to the patch's README file.

Top

Known Documentation Problems

This section discusses documentation errors you might encounter and steps to correct these problems. This information is in addition to known documentation problems documented in the Sun Cluster 3.0 5/02 Release Notes.

Top

System Administration Guide

The correct caption for Table 5-2 is “Task Map: Dynamic Reconfiguration with Cluster Interconnects.”

Top

Hardware Guide

The following subsections describe omissions or new information that will be added to the next publishing of the Hardware Guide.

Top

ATM with Sun Cluster 3.0 5/02

ATM is supported with Sun Cluster 3.0 5/02 software as a public network interface to be used in LAN Emulation (LANE) mode only. Use the SunATM 5.0 version to run on Solaris 8 software.

Use the following network, ATM card, and LANE instance guidelines to configure ATM with Sun Cluster 3.0 5/02. For additional configuration information, see the Platform Notes: The SunATM Driver Software, 816-1915.

Top

Network Configuration Guidelines

In order to support ATM LANE on Sun Cluster, an ATM capable router and switch are required. The router needs to provide LANE services, with 1 ELAN for each set of nodes. Configure the router to respond to ALLROUTERS (224.0.0.2) and the ALLHOSTS (224.0.0.1) pings. The ATM switch should have PNNI (Private Network-Node Interface) enabled.

The router provides Emulated LAN (ELAN) service to the cluster nodes and clients. The clients can belong to a different ELANs but the cluster nodes must be part of the same ELAN.

Top

ATM Card Guidelines

To use ATM as a public network adapter, Sun Cluster software requires at least one ATM card per NAFO group. For high availability, you can eliminate
the potential single point of failure by using more than one ATM card per NAFO group.

Top

LANE Instance Configuration Guidelines

Perform the following tasks to configure LANE instances.

• Create one LANE instance on each ATM card.
• All LANE instances in a NAFO group must be configured on the same ELAN. For example, all LANE instances in NAFO1 must be in the same ELAN on all cluster nodes.
• Configure the primary LANE interface using the /etc/hostname.lane_n_ file. This file is necessary, but will cause warning messages to display at boot up on SunATM 5.0. The following example is of the console messages. These messages can be ignored.

  Rebooting with command: boot
  Boot device: diskbrd:a File and args:
  SunOS Release 5.8 Version Generic_108528-13 64-bit
  Copyright 1983-2001 Sun Microsystems, Inc. All rights reserved.
  ip_rput_dlpi(lane1): DL_ERROR_ACK for DL_ATTACH_REQ(11), errno 8, unix 0
  ip_rput_dlpi(lane1): DL_ERROR_ACK for DL_BIND_REQ(1), errno 3, unix 71
  ip_rput_dlpi(lane1): DL_ERROR_ACK for DL_PHYS_ADDR_REQ(49), errno 3, unix 71
  ip_rput_dlpi(lane1): DL_ERROR_ACK for DL_UNBIND_REQ(2), errno 3, unix 71
  ip_rput_dlpi(lane1): DL_ERROR_ACK for DL_DETACH_REQ(12), errno 3, unix 71
  ifconfig: SIOCSLIFNAME for ip: lane1: Protocol error
  moving addresses from failed IPv4 interfaces: lane1 (couldn't move, no
  alternative interface).
  Hostname: atm10

• Assign an IP address to the primary LANE interface in the atmconfig file.

  Note Do not assign an IP address to the secondary, backup LANE interface.

  The following example shows an atmconfig file with the primary and secondary LANE interfaces configured. Note the IP address is assigned only to
  the primary LANE interface.

  ba0 3.1 - -
  ba0 SONET - - -
  ba0 - - 1 atm20
  ba1 3.1 - -
  ba1 SONET - - -
  ba1 - - 2 -

Top

Sun StorEdge T3/T3+ Partner Group and Sun StorEdge 3900 Storage Devices Supported in a Scalable Topology.

The Sun StorEdge T3/T3+ Partner Group and Sun StorEdge 3900 storage devices are supported with 4–node connectivity in a cluster environment.

To configure and maintain these storage devices with 4–node connectivity, use the procedures listed in the storage device's chapter and repeat the steps for Node B on each additional node that connects to the storage device.

For the following node-related procedures , see Appendix, Scalable Cluster Topology.

• Adding a Cluster Node
• Removing a Cluster Node
• How to Remove Connectivity Between an Array and a Single Node, in a Cluster With Greater Than Two-Node Connectivity

Top

Software Installation Guide

The following subsections describe omissions or new information that will be added to the next publishing of the Software Installation Guide.

Top

Correcting Stack Overflow Related to VxVM Disk Device Groups

If you experience a stack overflow when a VxVM disk device group is brought online, the default value of the thread stack size might be insufficient. To increase the thread stack size, add the following entry to the /etc/system on each node. Set the value for size to a number that is greater than 8000, which is the default setting.

How to Upgrade to the Sun Cluster 3.0 5/02 Software Update Release

Use the following procedure to upgrade any previous release of Sun Cluster 3.0 software to the Sun Cluster 3.0 5/02 update release.

1. Back up the shared data from all device groups within the cluster.
   
2. Get any necessary patches for your cluster configuration.
   
   In addition to Sun Cluster software patches, get any patches for your hardware, Solaris Operating System, volume manager, applications, and any other software products currently running on your cluster. See the Sun Cluster release notes documentation for the location of Sun patches and installation instructions. You will apply the patches in different steps of this procedure.
   
3. From any node, view the current status of the cluster to verify that the cluster is running normally.
   

   % scstat

   
   See the scstat(1M) man page for more information.
   

4. Become superuser on one node of the cluster.
   
   Upgrade only one node at a time.
   
5. Evacuate all resource groups and device groups that are running on the node to upgrade.
   
   Specify the node that you are upgrading in the node argument of the following scswitch command:
   

   # scswitch -S -h from-node

   -S	Evacuates all resource groups and device groups

   -h node

   Specifies the name of the node from which to evacuate resource groups and device groups (the node you are upgrading)

   
   See the scswitch(1M) man page for more information.
   

6. Verify that the evacuation completed successfully.
   

   # scstat -g -D

   
   Ensure that the node you are upgrading is no longer the primary for any resource groups or device groups in the cluster.
   

7. Reboot the node into noncluster mode.
   
   Include the double dashes (--) in the command.
   

   # reboot –– -x

8. Back up the system disk.
   
9. Determine whether any of the Cool Stuff CD packages are installed on the node.
   
   To display the version of an installed package, use the following command:
   

   # pkginfo -l package

   The following table lists the packages from the Sun Cluster 3.0 GA Cool Stuff CD-ROM:

   Package	Version	Description
   SUNWscrtw	3.0.0/2000.10.17.22.22	Resource Type Wizard
   SUNWscsdk	3.0.0/2000.10.10.13.06	Data Service Software Development Kit
   SUNWscset	3.0.0/2000.10.17.22.22	rgmsetup
   SUNWscvxi	3.0.0/2000.10.17.22.22	Cluster VxVM setup

   
   Remove any Cool Stuff CD-ROM packages found on the node. These packages will be replaced with supported versions in Sun Cluster 3.0 5/02 software.
   

   # pkgrm package

10. Do you intend to upgrade Solaris 8 software?
    

    Note The cluster must already run on, or be upgraded to, at least the minimum required level of the Solaris 8 Operating System to support Sun Cluster 3.0 5/02 software. See the Info Documents page for Sun Cluster 3.0 software on http://sunsolve.sun.com for the latest Solaris support information.

    • If yes, go to Step 11.
    • If no, go to Step 12.
11. Upgrade Solaris 8 software.
    
    1. Determine whether the following links already exist, and if so, whether the file names contain an uppercase K or S.
       

       /etc/rc0.d/K16apache
       /etc/rc1.d/K16apache
       /etc/rc2.d/K16apache
       /etc/rc3.d/S50apache
       /etc/rcS.d/K16apache

       
       If these links already exist and contain an uppercase K or S in the file name, no further action is necessary concerning these links. If these links do not exist, or if these links exist but contain a lowercase k or s in the file name, you will move aside these links in Step 7.
       

    2. Are you using the Maintenance Update upgrade method?
       
       • If yes, skip to Step 3.
       • If no, temporarily comment out all global device entries in the /etc/vfstab file.
         
         Do this to prevent the Solaris upgrade from attempting to mount the global devices. To identify global device entries, look for entries that contain global in the mount-options list.
    3. Shut down the node to upgrade.
       

       # shutdown -y -g0
       ok

    4. Follow instructions in the installation guide for the Solaris 8 update version you want to upgrade to.
       

       Note To reboot the node during Solaris software upgrade, always add the -x option to the command. This ensures that the node reboots into noncluster mode. The following two commands boot a node into single-user noncluster mode: # reboot –– -sx ok boot -sx Do not reboot the node into cluster mode during or after Solaris software upgrade.

    5. Are you using the Maintenance Update upgrade method?
       
       • If yes, skip to Step 6.
       • If no, uncomment all global device entries that you commented out in the /a/etc/vfstab file.
    6. Install any Solaris software patches and hardware-related patches, and download any needed firmware contained in the hardware patches.
       
       Do not reboot yet if any patches require rebooting.
       
    7. If the Apache links in Step 1 did not already exist or they contained a lowercase k or s in the file names before you upgraded Solaris software, move aside the restored Apache links.
       
       Use the following commands to rename the files with a lowercase k or s:
       

       # mv /a/etc/rc0.d/K16apache /a/etc/rc0.d/k16apache
       # mv /a/etc/rc1.d/K16apache /a/etc/rc1.d/k16apache
       # mv /a/etc/rc2.d/K16apache /a/etc/rc2.d/k16apache
       # mv /a/etc/rc3.d/S50apache /a/etc/rc3.d/s50apache
       # mv /a/etc/rcS.d/K16apache /a/etc/rcS.d/k16apache

       Note For the Maintenance Update upgrade method, the paths to the files do not begin with /a.

    8. Reboot the node into noncluster mode.
       
       Include the double dashes (--) in the command.
       

       # reboot –– -x

12. Determine whether the following packages are installed on the node.
    

    # pkginfo SUNWscva SUNWscvr SUNWscvw SUNWscgds

    
    Sun Cluster software upgrade requires that these packages exist on the node before upgrade begins. If any of these packages are missing, install them from the Sun Cluster 3.0 5/02 CD-ROM.
    

    # cd /cdrom/suncluster_3_0/SunCluster_3.0/Packages
    # pkgadd -d . SUNWscva SUNWscvr SUNWscvw SUNWscgds

13. Do you intend to use SunPlex Manager?
    
    • If no, go to Step 14.
    • If yes, ensure that the required Apache software packages are installed on the node.

      # pkginfo SUNWapchr SUNWapchu

      If any Apache software packages are missing, install them on the node from the Solaris CD-ROM.

      # pkgadd -d . SUNWapchr SUNWapchu

14. Upgrade to the Sun Cluster 3.0 5/02 update software.
    
    1. Insert the Sun Cluster 3.0 5/02 CD-ROM into the CD-ROM drive on the node.
       
       If the volume daemon vold(1M) is running and configured to manage CD-ROM devices, it automatically mounts the CD-ROM on the /cdrom/suncluster_3_0 directory.
       
    2. Change to the Tools directory.
       

       # cd /cdrom/suncluster_3_0/SunCluster_3.0/Tools

    3. Install the Sun Cluster 3.0 5/02 update patches.
       

       # ./scinstall -u update

       
       See the scinstall(1M) man page for more information.
       

    4. Change to the CD-ROM root directory and eject the CD-ROM.
       
    5. Install any Sun Cluster software patches.
       
    6. Verify that each Sun Cluster 3.0 5/02 update patch is installed correctly.
       
       View the upgrade log file referenced at the end of the upgrade output messages.
       
15. Reboot the node into the cluster.
    

    # reboot

16. Verify the status of the cluster configuration.
    

    % scstat

17. Repeat Step 4 through Step 16 on each remaining cluster node, one node at a time.
    
18. Take offline all resource groups for the data services you will upgrade.
    

    # scswitch -F -g resource-grp

    -F	Take offline

    -g resource-grp

    Specifies the name of the resource group to take offline

19. Upgrade applications as needed.
    
    Follow the instructions provided in your third-party documentation.
    
20. On each cluster node on which data services are installed, upgrade to the Sun Cluster 3.0 5/02 data services update software.
    
    1. Insert the Sun Cluster 3.0 5/02 Agents CD-ROM into the CD-ROM drive on the node.
       
    2. Install the Sun Cluster 3.0 5/02 data services update patches.
       
       Use one of the following methods:
       
       • To upgrade one or more specified data services, type the following command:

         # scinstall -u update -s srvc[,srvc,...] -d cdrom-image

       • To upgrade all data services present on the node, type the following command:

         # scinstall -u update -s all -d cdrom-image

         Note The -s all option assumes that updates for all installed data services exist on the update release. If an update for a particular data service does not exist in the update release, that data service is not upgraded.

    3. Eject the CD-ROM.
       
    4. Install any Sun Cluster data service software patches.
       
    5. Verify that each data service update patch is installed successfully.
       
       View the upgrade log file referenced at the end of the upgrade output messages.
       
21. After all data services on all cluster nodes are upgraded, bring back online the resource groups for each upgraded data service.
    

    # scswitch -Z -g resource-grp

    -Z	Bring online

22. From any node, verify the status of the cluster configuration.
    

    % scstat

23. Restart any applications.
    
    Follow the instructions provided in your application's documentation.
    

Top

Upgrading the Sun Cluster HA for NFS Data Service

In the procedure “How to Finish Upgrading Cluster Software” from the section “Upgrading From Sun Cluster 2.2 to Sun Cluster 3.0 Software,” the following command upgrades the Sun Cluster HA for NFS data service:

This command requires that the SUNWscnfs package is already installed from the Sun Cluster 3.0 5/02 Agents CD-ROM on all nodes before you invoke the scinstall command. To ensure successful upgrade of the Sun Cluster HA for NFS data service, do the following:

• Ensure that the SUNWscnfs package is installed on all nodes of the cluster before you run this scinstall command.
• If the scinstall command fails because the SUNWscnfs package is missing from a node, install the SUNWscnfs package on all nodes from the Sun Cluster 3.0 5/02 Agents CD-ROM, then rerun the scinstall command.

Top

Names for SCI-PCI Adapters

To configure SCI-PCI adapters for the cluster interconnect, specify sciN as the adapter name, for example, sci0. Do not use scidN as the adapter name.

Top

Solaris Volume Manager Replica Space Requirement

Problem Summary: The Sun Cluster 3.0 12/01 Software Installation Guide tells you to set aside at least 10 Mbytes in slice 7 to use to create three Solaris Volume Manager replicas in that slice. However, Solaris Volume Manager replicas in Solaris 9 software require substantially more space than the 10 Mbytes required for Solstice DiskSuite replicas in Solaris 8 software.

Workaround: When you install Solaris 9 software, allocate at least 20 Mbytes to slice 7 of the root disk to accommodate the larger Solaris Volume Manager replicas.

Top

IP Address Requirement for Sun Fire 15000 Systems

Before you install Sun Cluster software on a Sun Fire 15000 system, you must add the IP address of each domain console network interface to the /etc/inet/hosts file on each node in the cluster. Perform this task regardless of whether you use a naming service.

Top

Quorum Device Connection to Nodes

In the Planning chapter, the following statement about quorum devices is incorrect:

The statement should instead read as follows:

Top

Node Authentication When Installing Veritas Volume Manager

In the procedures “How to Install Veritas Volume Manager Software and Encapsulate the Root Disk” and “How to Install Veritas Volume Manager Software Only,” it is no longer necessary to first add cluster node names to the authentication list. You can therefore skip Step 3, “Add all nodes in the cluster to the cluster node authentication list.”

Top

How to Create State Database Replicas

When you use the metadb -af command to create state database replicas on local disks, use the physical disk name (cNtXdYs_ Z_), not the device-ID name (dN), to specify the slices to use.

Top

Data Services Installation and Configuration Guide

The following subsections describe omissions or new information that will be added to the next publishing of the Data Service Installation and Configuration Guide.

Top

Sun Cluster Data Service for NetBackup

The “Sun Cluster HA for NetBackup Overview” section should state that in a Sun Cluster environment, robotic control is only supported on media servers and on not the NetBackup master server running on Sun Cluster.

Top

Configuring an SAP J2EE Engine Cluster and an SAP Web Dispatcher

Sun Cluster now supports the SAP J2EE engine cluster and SAP Web dispatcher components on the Sun Cluster environment. To use these components you must complete additional steps during your Sun Cluster HA for SAP installation and configuration.

• To configure a J2EE engine cluster with your Sun Cluster HA for SAP with a Central Instance, see How to Configure an SAP J2EE Engine with your Sun Cluster HA for SAP with Central Instance.
• To configure a J2EE engine cluster with your Sun cluster HA for SAP with an SAP Application Server, see How to Configure an SAP J2EE Engine Cluster with your Sun Cluster HA for SAP with an Application Server.
• To configure SAP Web dispatcher with your Sun Cluster HA for SAP agent, see How to Configure a SAP Web Dispatcher with your Sun Cluster HA for SAP.

The SAP J2EE engine is started by the SAP dispatcher which is under the protection of the Sun Cluster HA for SAP. If the SAP J2EE engine goes down, the SAP dispatcher will restart it.

The SAP Web dispatcher has the capability of auto restart. If the SAP Web dispatcher goes down, the SAP Web dispatcher watch dog process will restart. Currently, there is no Sun Cluster agent available for the SAP Web dispatcher.

How to Configure an SAP J2EE Engine with your Sun Cluster HA for SAP with Central Instance

After you have completed the How to Enable Failover SAP Instances to Run in a Sun Cluster procedure in the Sun Cluster HA for SAP document, perform the following steps.

1. Using the SAP J2EE Admintool GUI, change the ClusterHosts parameter to list all logical hosts for the application server and port pair under dispatcher/Manager/ClusterManager. For example,
   

   as1–1h:port;as2–1h:port ...

2. Change the file j2ee-install-dir/additionalproperties as follows:
   

   com.sap.instanceId = logical-host-ci_SID_SYSNR

3. Change the file j2ee-install-dir/server/services/security/work/R3Security.properties as follows:
   

   sapbasis.ashost = logical-host-ci

4. Change the file SDM-dir/program/config/flow.xml
   

   host = logical-host-ci

How to Configure an SAP J2EE Engine Cluster with your Sun Cluster HA for SAP with an Application Server

After you have completed the How to Enable Failover SAP Instances to Run in a Sun Cluster or How to Install an SAP Scalable Application Server procedure in the Sun Cluster HA for SAP document, perform the following steps.

1. Using the SAP J2EE Admintool GUI, change ClusterHosts parameter to list the logical host for the central instance and port pair under the dispatcher/Manager/ClusterManager.
   

   logical-host-ci:port

2. Change the file j2ee-install-dir/additionalproperties as follows:
   

   com.sap.instanceId = logical-host-as_SID_SYSNR

3. Change the file {{j2ee-install-dir/server/services/security/work/R3Security.propertie}}s as follows:
   

   sapbasis.ashost = logical-host-as

How to Configure a SAP Web Dispatcher with your Sun Cluster HA for SAP

After you have configured the SAP Web dispatcher with your Sun Cluster HA for SAP, perform the following steps.

1. Ensure that SAP Web dispatcher has an instance number different than the Central Instance and the application server instances.
   
   For example, SAPSYSTEM = 66 is used in the profile for the SAP Web dispatcher.
   
2. Activate the Internet Communication Frame Services manually after you install the SAP Web Application Server.
   
   See SAP OSS note 517484 for more details.
   

Top

Configuring Sun Java System Web Server

The “How to Configure a Sun Java System Web Server” procedure in the Sun Cluster data services collection is missing the following step, which is not dependent on any other step in the procedure.

Create a file that contains the secure key password you need to start this instance, and place this file under the server root directory. Name this file keypass.

Top

Support for Sun ONE Proxy Server

Sun Cluster HA for Sun ONE Web Server now supports Sun ONE Proxy Server. For information about the Sun ONE Proxy Server product, see http://docs.sun.com/db/prod/s1.webproxys. For Sun ONE Proxy Server installation and configuration information, see http://docs.sun.com/db/coll/S1_ipwebproxysrvr36.

Top

Registering and Configuring the Sun Cluster for SAP liveCache

The procedure “How to Register and Configure Sun Cluster HA for SAP liveCache” has been revised. Add the following command to step 4 of this procedure.

For the procedure on how to set up an HAStoragePlus resource, see Sun Cluster 3.0 Data Service Installation and Configuration Guide.

Top

Using the Sun Cluster LogicalHostname Resource With Oracle Real Application Clusters

Information on using the Sun Cluster LogicalHostname resource with Oracle Real Application Clusters is missing from Chapter 8, Installing and Configuring Sun Cluster Support for Oracle Parallel Server/Real Application Clusters, in Sun Cluster 3.0 12/01 Data Services Installation and Configuration Guide.

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 TCP/IP network timeout is high, the client application might take a long time to detect the failure. Typically client applications take between three and nine minutes to detect such failures.

In such situations, client applications may use the Sun Cluster LogicalHostname resource for connecting to an Oracle Real Application Clusters database that is running on Sun Cluster. You can configure the LogicalHostname resource in a separate resource group that is mastered on the nodes on which Oracle Real Application Clusters is running. If a node fails, the LogicalHostname 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.

Top

Creating Node-Specific Files and Directories for Use With Oracle Real Application Clusters Software on the Cluster File System

When Oracle software is installed on the cluster file system, all the files in the directory that the ORACLE_HOME environment variable specifies are accessible by all cluster nodes.

An installation might require that some Oracle files or directories maintain node-specific information. You can satisfy this requirement by using a symbolic link whose target is a file or a directory on a file system that is local to a node. Such a file system is not part of the cluster file system.

To use a symbolic link for this purpose, you must allocate an area on a local file system. To enable Oracle applications to create symbolic links to files in this area, the applications must be able to access files in this area. Because the symbolic links reside on the cluster file system, all references to the links from all nodes are the same. Therefore, all nodes must have the same namespace for the area on the local file system.

How to Create a Node-Specific Directory for Use With Oracle Real Application Clusters Software on the Cluster File System

Perform this procedure for each directory that is to maintain node-specific information. The following directories are typically required to maintain node-specific information:

• $ORACLE_HOME/network/agent
• $ORACLE_HOME/network/log
• $ORACLE_HOME/network/trace
• $ORACLE_HOME/srvm/log
• $ORACLE_HOME/apache

For information about other directories that might be required to maintain node-specific information, see your Oracle documentation.

1. On each cluster node, create the local directory that is to maintain node-specific information.
   

   # mkdir -p local-dir

   -p	Specifies that all nonexistent parent directories are created first

   local-dir

   Specifies the full path name of the directory that you are creating

2. On each cluster node, make a local copy of the global directory that is to maintain node-specific information.
   

   # cp -pr global-dir local-dir-parent

   -p	Specifies that the owner, group, permissions modes, modification time, access time, and access control lists are preserved.

   -r	Specifies that the directory and all its files, including any subdirectories and their files, are copied.

   global-dir

   Specifies the full path of the global directory that you are copying. This directory resides on the cluster file system under the directory that the ORACLE_HOME environment variable specifies.

   local-dir-parent

   Specifies the directory on the local node that is to contain the local copy. This directory is the parent directory of the directory that you created in Step 1.

3. Replace the global directory that you copied in Step 2 with a symbolic link to the local copy of the global directory.
   
   1. From any cluster node, remove the global directory that you copied in Step 2.
      

      # rm -r global-dir

      -r	Specifies that the directory and all its files, including any subdirectories and their files, are removed.

      global-dir

      Specifies the file name and full path of the global directory that you are removing. This directory is the global directory that you copied in Step 2.

   2. From any cluster node, create a symbolic link from the local copy of the directory to the global directory that you removed in Step 1.
      

      # ln -s local-dir global-dir

      -s	Specifies that the link is a symbolic link

      local-dir

      Specifies that the local directory that you created in Step 1 is the source of the link

      global-dir

      Specifies that the global directory that you removed in Step 1 is the target of the link

Example: Creating Node-Specific Directories

This example shows the sequence of operations that is required to create node-specific directories on a two-node cluster. This cluster is configured
as follows:

• The ORACLE_HOME environment variable specifies the /global/oracle directory.
• The local file system on each node is located under the /local directory.

The following operations are performed on each node:

1. To create the required directories on the local file system, the following commands are run:

   # mkdir -p /local/oracle/network/agent

   # mkdir -p /local/oracle/network/log

   # mkdir -p /local/oracle/network/trace

   # mkdir -p /local/oracle/srvm/log

   # mkdir -p /local/oracle/apache

2. To make local copies of the global directories that are to maintain node-specific information, the following commands are run:

   # cp -pr $ORACLE_HOME/network/agent /local/oracle/network/.

   # cp -pr $ORACLE_HOME/network/log /local/oracle/network/.

   # cp -pr $ORACLE_HOME/network/trace /local/oracle/network/.

   # cp -pr $ORACLE_HOME/srvm/log /local/oracle/srvm/.

   # cp -pr $ORACLE_HOME/apache /local/oracle/.

The following operations are performed on only one node:

1. To remove the global directories, the following commands are run:

   # rm -r $ORACLE_HOME/network/agent

   # rm -r $ORACLE_HOME/network/log

   # rm -r $ORACLE_HOME/network/trace

   # rm -r $ORACLE_HOME/srvm/log

   # rm -r $ORACLE_HOME/apache

2. To create symbolic links from the local directories to their corresponding global directories, the following commands are run:

   # ln -s /local/oracle/network/agent $ORACLE_HOME/network/agent

   # ln -s /local/oracle/network/log $ORACLE_HOME/network/log

   # ln -s /local/oracle/network/trace $ORACLE_HOME/network/trace

   # ln -s /local/oracle/srvm/log $ORACLE_HOME/srvm/log

   # ln -s /local/oracle/apache $ORACLE_HOME/apache

How to Create a Node-Specific File for Use With Oracle Real Application Clusters Software on the Cluster File System

Perform this procedure for each file that is to maintain node-specific information. The following files are typically required to maintain node-specific information:

• $ORACLE_HOME/network/admin/snmp_ro.ora
• $ORACLE_HOME/network/admin/snmp_rw.ora

For information about other files that might be required to maintain node-specific information, see your Oracle documentation.

1. On each cluster node, create the local directory that will contain the file that is to maintain node-specific information.
   

   # mkdir -p local-dir

   -p	Specifies that all nonexistent parent directories are created first

   local-dir

   Specifies the full path name of the directory that you are creating

2. On each cluster node, make a local copy of the global file that is to maintain node-specific information.
   

   # cp -p global-file local-dir

   -p	Specifies that the owner, group, permissions modes, modification time, access time, and access control lists are preserved.

   global-file

   Specifies the file name and full path of the global file that you are copying. This file was installed on the cluster file system under the directory that the ORACLE_HOME environment variable specifies.

   local-dir

   Specifies the directory that is to contain the local copy of the file. This directory is the directory that you created in Step 1.

3. Replace the global file that you copied in Step 2 with a symbolic link to the local copy of the file.
   
   1. From any cluster node, remove the global file that you copied in Step 2.
      

      # rm global-file

      global-file

      Specifies the file name and full path of the global file that you are removing. This file is the global file that you copied in Step 2.

   2. From any cluster node, create a symbolic link from the local copy of the file to the directory from which you removed the global file in Step 1.
      

      # ln -s local-file global-dir

      -s	Specifies that the link is a symbolic link

      local-file

      Specifies that the file that you copied in Step 2 is the source of the link

      global-dir

      Specifies that the directory from which you removed the global version of the file in Step 1 is the target of the link

Example: Creating Node-Specific Files

This example shows the sequence of operations that is required to create node-specific files on a two-node cluster. This cluster is configured as follows:

• The ORACLE_HOME environment variable specifies the /global/oracle directory.
• The local file system on each node is located under the /local directory.

The following operations are performed on each node:

1. To create the local directory that will contain the files that are to maintain node-specific information, the following command is run:

   # mkdir -p /local/oracle/network/admin

2. To make a local copy of the global files that are to maintain node-specific information, the following commands are run:

   # cp -p $ORACLE_HOME/network/admin/snmp_ro.ora \
   /local/oracle/network/admin/.

   # cp -p $ORACLE_HOME/network/admin/snmp_rw.ora \
   /local/oracle/network/admin/.

The following operations are performed on only one node:

1. To remove the global files, the following commands are run:

   # rm $ORACLE_HOME/network/admin/snmp_ro.ora

   # rm $ORACLE_HOME/network/admin/snmp_rw.ora

2. To create symbolic links from the local copies of the files to their corresponding global files, the following commands are run:

   # ln -s /local/oracle/network/admin/snmp_ro.ora \
   $ORACLE_HOME/network/admin/snmp_rw.ora

   # ln -s /local/oracle/network/admin/snmp_rw.ora \
   $ORACLE_HOME/network/admin/snmp_rw.ora

Top

Supplement

The following subsections describe known errors in or omissions from the Sun Cluster 3.0 5/02 Supplement.

Top

How to Uninstall Sun Cluster Software From a Cluster Node (5/02)

The following note at the beginning of this procedure is incorrect:

The note should instead read as follows:

Top

Release Notes

The following subsections describe omissions or new information that will be added to the next publishing of the Release Notes.

Top

BugId 4662264

The Workaround documented in the Sun Cluster 3.1 8/05 Release Notes for Solaris OS is incorrect.

Incorrect:

Increase the stack size by putting the following lines in the /etc/system file.

Correct:

Increase the stack size by putting the following lines in the /etc/system file.

Top

Man Pages

The following subsections describe omissions or new information that will be added to the next publishing of the man pages.

Top

scconf_transp_adap_sci Man Page

The scconf_transp_adap_sci(1M) man page states that SCI transport adapters can be used with the rsm transport type. This support statement is incorrect. SCI transport adapters do not support the rsm transport type. SCI transport adapters support the dlpi transport type only.

Top

scconf_transp_adap_wrsm Man Page

The following scconf_transp_adap_wrsm(1M) man page replaces the existing scconf_transp_adap_wrsm(1M) man page.

NAME

scconf_transp_adap_wrsm.1m- configure the wrsm transport adapter

DESCRIPTION

wrsm adapters may be configured as cluster transport adapters. These adapters can only be used with transport types dlpi.

The wrsm adapter connects to a transport junction or to another wrsm adapter on a different node. In either case, the connection is made through a transport cable.

Although you can connect the wrsm adapters directly by using a point-to-point configuration, Sun Cluster software requires that you specify a transport junction, a virtual transport junction. For example, if node1:wrsm1 is connected to node2:wsrm1 directly through a cable, you must specify the following configuration information.

The transport junction, whether a virtual switch or a hardware switch, must have a specific name. The name must be sw_wrsmN where the adapter is wrsm_ N_. This requirement reflects a Wildcat restriction that requires that all wrsm controllers on the same Wildcat network have the same instance number.

When a transport junction is used and the endpoints of the transport cable are configured using scconf, scinstall, or other tools, you are asked to specify a port name on the transport junction. You can provide any port name, or accept the default, as long as the name is unique for the transport junction.

The default sets the port name to the node ID that hosts the adapter at the other end of the cable.

Refer to scconf(1M) for more configuration details.

There are no user configurable properties for cluster transport adapters of this type.

SEE ALSO

scconf(1M), scinstall(1M), wrsmconf(1M), wrsmstat(1M), wrsm(7D), wrsmd(7D)

Top

SUNW.HAStoragePlus.5

The SunW.HAStoragePlus.5 man page has been modified. The following paragraph replaces the paragraph in the Notes section of the man page.

Although unlikely, the SUNW.HAStoragePlus resource is capable of mounting any global file system found to be in a unmounted state. This check will be skipped only if the file system is of type UFS and logging is turned off. All file systems are mounted in the overlay mode. Local file systems will be forcibly unmounted.

The following FilesystemCheckCommand extension property has been added to the SUNW.HAStoragePlus.5 man page.

FilesystemCheckCommand

SUNW.HAStoragePlus conducts a file system check on each unmounted file system before attempting to mount it. The default file system check command is /usr/sbin/fsck -o p for UFS and VxFS file systems, and /usr/sbin/fsck for other file systems. The FilesystemCheckCommand extension property can be used to override this default file system check specification and instead specify an alternate command string/executable. This command string/executable will then be invoked on all unmounted file systems. The default FilesystemCheckCommand extension property value is NULL. When the FilesystemCheckCommand is set to NULL the command will be assumed to be /usr/sbin/fsck -o p for UFS/VxFS file systems and /usr/sbin/fsck for other file systems. When the FilesystemCheckCommand is set to a user specified command string, SUNW.HAStoragePlus will elect to invoke this command string with the file system mount point as an argument. Any arbitrary executable can be specified in this manner. A non-zero return value will be treated as a error which occurred during the file system check operation, causing the start method to fail. Any arbitrary executable can be specified in this manner. When the FilesystemCheckCommand is set to /usr/bin/true, file system checks will altogether be avoided.