This document provides the following information for Sun™ Cluster 3.2 1/09 software.

• What's New in the Sun Cluster 3.2 1/09 Software
• Features Nearing End of Life
• Compatibility Issues
• Commands Modified in This Release
• Product Name Changes
• Supported Products
• Sun Cluster Security Hardening
• Known Issues and Bugs
• Patches and Required Firmware Levels
• Sun Cluster 3.2 1/09 Documentation
• Documentation Issues

Top

What's New in the Sun Cluster 3.2 1/09 Software

This section provides information related to new features, functionality, and supported products in the Sun Cluster 3.2 1/09 software.

New Features and Functionality

The following new features and functionality are provided in patches to Sun Cluster 3.2 1/09 software:

• EMC SRDF Data Recovery
• Sun Storage 7000 Unified Storage Systems With Oracle RAC
• Sun Storage J4200/J4400 SATA Arrays

The following new features and functionality are provided in the initial Sun Cluster 3.2 1/09 release:

• Cluster Configuration Checker
• Data Service for Informix
• Exclusive-IP Zones Support
• Global-Devices Namespace on a lofi Device
• IPsec on the Cluster Interconnect
• Optional Fencing
• PostgreSQL WAL Shipping Support
• Quorum
  • Quorum Monitoring
  • Software Quorum
  • New Automated Response to a Change in Quorum-Device Status
• Solaris Containers Clusters, or Zone Clusters
• ZFS Root File Systems, Except the Global-Devices Namespace

Top

Cluster Configuration Checker

The sccheck command is replaced by the cluster check command. The new check subcommand performs the same role as sccheck. In addition, a new cluster list-checks command is added, which displays a list of all available cluster configuration checks.

For details about the check and list-checks subcommands, see the cluster(1CL) man page.

Top

Data Service for Informix

A new data service is added for Informix. This data service is supported on the Solaris 10 OS for both SPARC® based platforms and x86 based platforms.

Top

Support EMC SRDF Data Recovery After a Complete Failure in a Primary Room

A patch to Sun Cluster 3.2 1/09 software changes Sun Cluster behavior so that if the primary campus cluster room fails, Sun Cluster automatically fails over to the secondary room. The patch makes the secondary room's storage device readable and writable, and enables the failover of the corresponding device groups and resource groups. When the primary room returns online, you can manually run the procedure that recovers the data from the EMC Symmetrix Remote Data Facility (SRDF) device group by resynchronizing the data from the original secondary room to the original primary room.

The following are the minimum patch versions that contain this new functionality:

• Solaris 10 SPARC - 126106-30
• Solaris 10 x86 - 126107-31
• Solaris 9 - 126105-29

For more information, see the procedure in the Documentation Issues section for the System Administration Guide.

Top

Exclusive-IP Zones Support

Support of SUNW.LogicalHostname resources is added for non-global zones with ip-type=exclusive. Such zones can have complete network isolation from the global zone and from one another, with their own network interfaces, routing, filtering, IPMP groups, and so forth. You can now use zones with ip-type=exclusive to host network resources of type SUNW.LogicalHostname that are used by failover data services. The use of zones with ip-type=exclusive is not available for scalable data services or with zone clusters.

For clusters that upgrade to the Sun Cluster 3.2 1/09 release, you must upgrade the SUNW.LogicalHostname resource to version 3 to make this feature available to the cluster. For new installations of Sun Cluster 3.2 1/09 software, this feature is automatically available.

Top

Global-Devices Namespace on a lofi Device

On the Solaris 10 OS, as an alternative to creating the global-devices namespace on a dedicated partition, you can instead choose to create the namespace on a lofi device. This feature is particularly useful if you are installing Sun Cluster software on systems that are pre-installed with the Solaris 10 OS.

This feature is not available on the Solaris 9 OS.

For more information, see New Choice for the Location of the Global-Devices Namespace.

Top

IPsec on the Cluster Interconnect

Support is added to use IP Security Architecture (IPsec) on the cluster private interconnect. For details, see "How to Configure IP Security Architecture (IPsec) on the Cluster Interconnect" in the Sun Cluster Software Installation Guide.

Top

Optional Fencing

You can now use the cluster command to set a default value for fencing that is applied to all storage devices. You can also now use the new default_fencing property with the cldevice command to enable or disable fencing for particular devices. If you disable fencing on a device, Sun Cluster software performs neither SCSI-2 nor SCSI-3 reservation-related operations on that device.

The default_fencing property replaces the localonly raw-disk device group property that you used to turn off fencing for devices in specific situations. The localonly property remains available, however, as you still need it to create local VxVM device groups.

For details, see "Administering the SCSI Protocol Settings for Storage Devices" in the Sun Cluster System Administration Guide and the cluster(1CL) and cldevice(1CL) man pages.Top

PostgreSQL WAL Shipping Support

The Sun Cluster data service for PostgreSQL now supports PostgreSQL Write Ahead Log (WAL) shipping. WAL shipping provides the ability to support log shipping functionality as a replacement for shared storage, thus eliminating the need for shared storage in a cluster when using PostgreSQL databases. This feature provides support for PostgreSQL database replication between two different clusters or between two different PostgreSQL failover resources within one cluster.

For details, see the Sun Cluster Data Service for PostgreSQL Guide.

Top

Quorum Enhancements

New quorum features are available, as described in the following sections.

Software Quorum

Sun Cluster software now supports a new protocol called "software quorum". Software quorum implements all Sun Cluster quorum device operations entirely in software. Software quorum does not use SCSI-2 or SCSI-3 reservation-related operations. Consequently, you can now use any kind of shared disk with Sun Cluster software. For example, you can now use Serial Advanced Technology Attachment (SATA) devices as well as solid-state storage devices as quorum devices.

To use a shared disk with software quorum, you first need to turn off SCSI fencing for that device. When you subsequently configure the device as a quorum device, Sun Cluster software determines that SCSI fencing for the device is turned off and automatically uses software quorum. Note, however, that Sun Cluster still supports the SCSI-2 and SCSI-3 protocols with shared disks.

Software quorum provides a level of data-integrity protection comparable to SCSI-2-based fencing.

Top

Quorum Monitoring

This new feature periodically probes all configured quorum devices and sends notification to syslog if a quorum device fails. You can monitor syslog for quorum-device failures and proactively replace a failed quorum device before node reconfiguration occurs.

Top

New Automated Response to a Change in Quorum Device Status

In previous Sun Cluster releases, if a configured quorum device stopped working, the cluster would subsequently ignore the quorum device completely. If such a quorum device became functional again, the user needed to unconfigure and then reconfigure the device, to return it to use as a quorum device in the cluster. Alternatively, the user could reboot the entire cluster.

This release changes the quorum device behavior. Now when the cluster encounters a problem with a quorum device, such as during a node reconfiguration, the cluster automatically takes the quorum device offline.

The new quorum-monitoring feature periodically checks the status of all configured quorum devices and initiates the following actions:

• Takes offline any quorum device that is not working properly.
• Brings online any formerly nonfunctional quorum device whose problem is resolved, and loads the quorum device with the appropriate information.

Any changes in the status of quorum devices are accompanied by notifications on syslog.

The following is one example of how this feature can affect cluster behavior. When a quorum device is located on a different network than the cluster nodes, transient network problems might cause communication failures. The quorum-monitoring feature automatically detects a communication
failure and takes the quorum device offline. Similarly, when communications are restored, the quorum-monitoring feature automatically brings the quorum device back online.

If you check the status of quorum devices by using the clquorum status command, or if the cluster undergoes a reconfiguration, the software performs the same actions that the quorum monitor does upon detecting a change in quorum-device status.

In addition, if you check the status of quorum devices by using the clquorum status command, the command now reports the present status of quorum devices, rather than report the status as of the last cluster reconfiguration.

Top

Solaris Containers Clusters, or Zone Clusters

On the Solaris 10 OS, with this release of Sun Cluster software you can now create a Solaris Containers cluster, simply called a zone cluster. The new zone-cluster feature is a virtual cluster, where each virtual node is a cluster brand zone. A zone cluster provides the following primary features:

• Cluster application fault isolation
• Security isolation
• Resource management
• License fee cost containment
• Cluster application consolidation

A zone cluster is a simplified cluster that only contains those resources that are directly used by applications. There can be any number of zone clusters, and each zone cluster can run any number of applications.

The first data service that has been qualified to run in a zone cluster is Oracle RAC, including all RAC software, such as the data base instances, CRS, and ASM. You can also run user-developed applications that run with RAC. As additional data services become qualified to run in a zone cluster, they will be added to Zone Cluster Support in this Release Notes.

For details about configuring a zone cluster, see "Configuring a Zone Cluster" in the Sun Cluster Software Installation Guide and the clzonecluster(1CL) man page.

For a discussion of the terminology that was changed related to virtual clusters, see "Introduction to the Sun Cluster Environment" in the Sun Cluster Concepts Guide.

Top

Support for Sun Storage 7000 Unified Storage Systems With Oracle RAC

Sun Cluster 3.2 1/09 software now supports Sun Storage 7000 Unified Storage Systems, for use with Oracle RAC in the following configurations:

• Up to four SPARC nodes
• At least Oracle RAC 10.2.0.4 10g Release 2 or Oracle RAC 11.1.0.7 11g software
• NFS file systems are used for Oracle RAC database files

No data services other than Oracle RAC are currently supported for use with these storage systems.

Observe the following guidelines when you use Sun Storage 7000 Unified Storage Systems with NFS file systems in a cluster configuration:

• You can use an iSCSI LUN from the storage system as a cluster quorum device. You must disable fencing for the LUN, which automatically enables the use of the software quorum protocol. For information about configuring a quorum device with fencing disabled, follow instructions in How to Configure Quorum Devices in the Sun Cluster Software Installation Guide.

• When Oracle RAC is installed in the global zone, you can also use NFS file systems for Oracle Clusterware OCR and Voting disks.

• When Oracle RAC is installed in a zone cluster, you must use iSCSI LUNs from Sun Storage 7000 Unified Storage Systems as OCR and Voting devices. You cannot use NFS file systems in this configuration due to a problem with Oracle Clusterware's detection of NFS mount options when running inside a non-global zone.

• If you use iSCSI LUNs for Oracle Clusterware OCR and Voting disks, either in the global zone or in a zone cluster, configure the corresponding Sun Cluster DID devices with fencing disabled. Use Sun Cluster DID device paths, not Solaris device paths, to reference those LUNs. For instructions to disable fencing globally or for individual disks, see procedures in Administering the SCSI Protocol Settings for Storage Devices . For instructions to add a raw device to a zone cluster, see How to Add a Raw-Disk Device to a Zone Cluster .

• Use the mount options that are required by Oracle RAC for NFS file systems. See OracleMetaLink bulletin 359515.1, "Mount Options for Oracle Files When Used with NAS Devices".

• Set the mount at boot option to yes in the /etc/vfstab file to automate the NFS file systems mount.

Example:

 #device                 device   mount     FS   fsck  mount    mount
 #to mount               to fsck  point     type pass  at boot  options
 #
 ...
 qualfugu:/export/oracrs -        /data/crs nfs  2     yes      rw,bg,forcedirectio,wsize=32768,rsize=32768,hard,noac,nointr,proto=tcp,vers=3
 qualfugu:/export/oradb  -        /data/db  nfs  2     yes      rw,bg,forcedirectio,wsize=32768,rsize=32768,hard,noac,nointr,proto=tcp,vers=3

• At this time, you cannot use the Sun Cluster clnas command to register Sun Storage 7000 Unified Storage Systems with the cluster.

• When you configure the RAC framework and RAC proxy resources, either by using the RAC wizard or by using maintenance commands, use the procedure for hardware RAID storage management and not for NAS NFS. See Sun Cluster Data Service for Oracle RAC Guide .

Top

Support for Sun Storage J4200/J4400 SATA Arrays

Sun Cluster 3.2 1/09 software now supports the use of Sun Storage J4200 and J4400 arrays with SATA HDDs in a cluster configuration. Sun Storage J4200 and J4400 storage arrays with SATA drives rely on an internal STP/SATA bridge, which handles the mapping to SATA. Storage arrays with SATA drives have certain limitations that must be taken into consideration in a Sun Cluster configuration. Observe the following requirements and guidelines when you configure dual-ported Sun Storage J4200 and J4400 SATA drives for use in a Sun Cluster configuration:

• SATA constraint - Because of the SATA protocol's point-to-point nature, only one initiator can be affiliated with a SATA drive on each J4200 or J4400 array's SIM card.
• Cabling- To work around the SATA protocol constraints, the cabling layout from hosts to the J4200 or J4400 arrays might expose the SIMs and the HBAs as a single point of failure in certain configurations. Figure 2 shows an example of such a configuration.
• Initiators - You must use one initiator from a host to a SIM card, as shown in Figures 1 and 2.

Figure 1 - Simple Configuration With Standalone J44xx Array

Figure 2 - Simple Configuration With Cascaded J44xx Array

• Mirroring - To avoid possible loss of data if a disk fails, use host-based mirroring of the data.
• Sharing arrays - You cannot share a SATA JBOD array between hosts that belong to different clusters.
• Disabling global fencing- You must disable global fencing for all disks in the SATA storage array. This is required regardless of whether any SATA disks are to be used as a quorum device or simply as shared storage.
  • To disable fencing during initial cluster configuration, run the scinstall utility in Custom Mode. When prompted by the utility whether to disable global fencing, respond "Yes".
  • To disable fencing of all storage devices in the cluster after the cluster is established, follow instructions in "How to Change the Default Global Fencing Protocol Settings for All Storage Devices" in the Sun Cluster System Administration Guide to set the global_fencing property to nofencing_noscrub. Alternatively, follow instructions in "How to Change the Fencing Protocol for a Single Storage Device" to set the default_fencing property of each SATA disk to nofencing_noscrub.

For more information about setting up Sun Storage J4200 or J4400 arrays, see the Sun Storage J4200/J4400 Array System Overview at http://docs.sun.com/source/820-3223-11/ and the Sun Storage J4200/J4400 Array System Hardware Installation Guide at http://docs.sun.com/app/docs/doc/820-3218-11.

Top

ZFS Root File Systems, Except the Global-Devices Namespace

This release supports the use of ZFS for root file systems, with one significant exception. If you use a dedicated partition of the boot disk for the global-devices file system, you must use only UFS as its file system. The global-devices namespace requires the proxy file system (PxFS) running on a UFS file system.

However, a UFS file system for the global-devices namespace can coexist with a ZFS file system for the root (/) file system and other root file systems, for example, /var or /home. Alternatively, if you instead use a lofi device to host the global-devices namespace, there is no limitation on the use of ZFS for root file systems.

Top

Features Nearing End of Life

The following feature is nearing end of life in Sun Cluster software.

Solaris 9

Sun Cluster support for the Solaris 9 OS might no longer be supported in a future release.

Top

Compatibility Issues

• Accessibility Features for People With Disabilities
• GlassFish with Sun Cluster Data Service for Sun Java System Application Server
• Loopback File System (LOFS)
• SAP 7.1 with Sun Cluster Data Service for SAP Web Application Server
• Oracle RAC Clusters With Solaris Volume Manager
• Shared QFS With Solaris Volume Manager for Sun Cluster
• Solaris 10 Patch 137137-09/137138-09 Causes ZFS Pool Corruption
• Solaris Trusted Extensions
• Solaris Volume Manager GUI
• ZFS Root Disk Encapsulation

This section contains information about Sun Cluster compatibility issues.

• Additional Sun Cluster framework compatibility issues are documented in "Planning the Sun Cluster Configuration" in Sun Cluster Software Installation Guide for Solaris OS.
• Additional Sun Cluster upgrade compatibility issues are documented in "Upgrade Requirements and Software Support Guidelines" in Sun Cluster Upgrade Guide for Solaris OS.
• For other known problems or restrictions, see Known Issues and Bugs.

Top

Accessibility Features for People With Disabilities

To obtain accessibility features that have been released since the publishing of this media, consult Section 508 product assessments that are available from Sun on request to determine which versions are best suited for deploying accessible solutions.

Top

GlassFish with Sun Cluster Data Service for Sun Java System Application Server

In GlassFish V2 UR2, the Domain Administration Server (DAS) takes a long time to start if the node agent's host is not online. This behavior is due to an existing bug in GlassFish. To support GlassFish V2 UR2 in a Sun Cluster environment, ensure that node-agent hosts are online before you bring the DAS resource online. For detailed information about the bug, see GlassFish Bug 5057.

Top

Loopback File System (LOFS)

Sun Cluster 3.2 1/09 software does not support the use of LOFS under certain conditions. If you must enable LOFS on a cluster node, such as when you configure non-global zones, first determine whether the LOFS restrictions apply to your configuration. See the guidelines in "Solaris OS Feature Restrictions" in Sun Cluster Software Installation Guide for Solaris OS for more information about the restrictions and workarounds that permit the use of LOFS when restricting conditions exist.

Top

(SPARC) Oracle RAC Clusters With Solaris Volume Manager

Due to CR 6580729, Solaris Volume Manager support is not available on SPARC based clusters with more than eight nodes that run Oracle RAC.

Top

SAP 7.1 with Sun Cluster Data Service for SAP Web Application Server

The following SAP 7.1 issues affect the operation of the Sun Cluster Data Service for SAP:

• In the Sun Cluster environment for SAP 7.1, the SAP Web Application Server goes to STOP_Failed mode after a public-network failure. After a public-network failure, the resource should fail over instead of going to STOP_Failed mode. Refer to SAP note 888312 to resolve this issue.
• The SAP Web Application Server probe returns an error message with status Degraded after switchover of the enq-msg resource group. Once the switchover of the enq-msg resource is complete, the SAP Web Application Server restarts due to a dependency on the messaging server. The restart of the SAP Web Application Server fails and returns the error message error 503 service unavailable. Refer to SAP note 966416 and follow the instructions to remove all krnlreg entries from the profile, to prevent deadlock situations.

Top

Shared QFS With Solaris Volume Manager for Sun Cluster

The following behavior has been reported on x86 Oracle RAC configurations with one or more Sun StorageTek QFS shared file systems that mount devices from multiowner disksets of Solaris Volume Manager for Sun Cluster (CR 6655081).

If the QFS file system metadata server is located on a node that is not the master node of the disk set and that node loses all storage connectivity, Oracle CRS will reboot the node. At the same time, the other nodes that are QFS metadata client nodes might experience errors writing to related database files. The write error condition corrects itself when the Oracle RAC instances are restarted. This restart should be an automatic recovery action by Oracle CRS, after the QFS metadata server and Solaris Volume Manager automatic recovery has been completed by Sun Cluster software.

Top

Solaris 10 Patch 137137-09/137138-09 Causes ZFS Pool Corruption

A change to the zpool_import() management of the zpool.cache file, as delivered by Solaris 10 kernel patches 137137-09 (for SPARC) or 137138-09 (for x86), might cause systems that have their shared ZFS (zfs(1M)) storage pools under the control of HAStoragePlus to be simultaneously imported on multiple cluster nodes. Importing a ZFS storage pool on multiple cluster nodes will result in pool corruption, which might cause data integrity issues or cause a cluster node to panic.

To avoid this problem, install Solaris 10 patch 139579-02 (for SPARC) or 139580-02 (for x86) immediately after you install 137137-09 or 137138-09 but before you reboot the cluster nodes.

Alternatively, only on the Solaris 10 5/08 OS, remove the affected patch before any ZFS pools are simultaneously imported to multiple cluster nodes. You cannot remove patch 137137-09 or 137138-09 from the Solaris 10 10/08 OS, because these patches are preinstalled on that release.

For more information, see Sun Alert 245626.

Top

Solaris Trusted Extensions

Starting with the Solaris 10 11/06 release, the Solaris 10 OS includes support for Solaris Trusted Extensions, including with the use of non-global zones. The interaction between Sun Cluster and Solaris Trusted Extensions when using non-global zones is not yet tested and is not supported.

Top

Solaris Volume Manager GUI

The Enhanced Storage module of Solaris™ Management Console (Solaris Volume Manager) is not compatible with Sun Cluster software. Use the command-line interface or Sun Cluster utilities to configure Solaris Volume Manager software.

Top

VxVM and ZFS Root Disk

There is currently an incompatibility with VxVM root disk encapsulation of a root disk that runs on ZFS. Therefore, you cannot use the clvxvm encapsulate command on a cluster node whose root disk uses ZFS. Instead, you can create a root disk group by using local nonroot disks, or choose not to create a root disk group.

[excerpt:hidden=true}CR 6803117

Top

Commands Modified in This Release

This section describes changes to the Sun Cluster command interfaces that might cause user scripts to fail.

clzonecluster Utility

A new clzonecluster utility is added to the Solaris 10 version of the Sun Cluster 3.2 1/09 software. This command is used to create and administer a zone cluster. This utility is similar to the zonecfg utility and accepts resources that are used by the zonecfg and sysidcfg utilities. See the clzonecluster(1M) man page for usage details.

Top

New num_zoneclusters Network Property for the cluster Command

A new network property, num_zoneclusters, is introduced for use with the cluster set-netprops command. This property specifies the number of zone clusters that you expect to include in the global cluster. The cluster infrastructure uses this value to modify the private-network IP address range, to support the additional number of addresses that the specified number of zone clusters would require. Unlike the other network properties, you can set this property while the global cluster is in cluster mode as well as in noncluster mode. This property is valid only on the Solaris 10 OS.

Top

New check and list-checks Subcommands for the cluster Command

The new cluster check subcommand replaces the sccheck command and performs the same role as sccheck. For any procedures that use sccheck, run cluster check instead, except continue to use the sccheck command to verify the existence of mount points when you configure a cluster file system. For details about the check subcommand, see the cluster(1CL) man page.

The new list-checks subcommand is also added. Use cluster list-checks to display a list of all available cluster configuration checks. For details about the list-checks subcommand, see the cluster(1CL) man page.

Top

pnmd Daemon

The pnmd daemon is replaced by the cl_pnmd daemon, and the pnmd(1M) man page is replaced by the cl_pnmd(1M) man page. This change has little to no user impact, as this daemon is used only by the system.

Top

Product Name Changes

This section provides information about product name changes for applications that Sun Cluster software supports. Depending on the Sun Cluster software release that you are running, your Sun Cluster documentation might not reflect the following product name changes.

Note Sun Cluster 3.2 1/09 software is distributed under Solaris Cluster 3.2 1/09 and Sun Java Availability Suite.

Top

Supported Products

This section describes the supported software and memory requirements for Sun Cluster 3.2 1/09 software.

• Common Agent Container
• Data Services
• File Systems
• Memory Requirements
• Solaris Operating System (OS)
• Sun Management Center
• Sun StorageTek Availability Suite
• Sun StorEdge Availability Suite
• Volume Managers

Common Agent Container

This Sun Cluster release supports the common agent container version 2.1.

Top

Data Services

Contact your Sun sales representative for the complete list of supported data services (agents) and application versions.

Note Data service documentation, including man pages and wizard online help, is no longer translated from English to other languages.

• HA-Containers Brand Support
• Non-Global Zones Support
• Zone Cluster Support
• Resource Type Names

HA-Containers Brand Support

The Sun Cluster Data Service for Solaris Containers supports non-global zones of the following brands:

• lx
• native
• solaris8
• solaris9

Non-Global Zones Support

The following Sun Cluster data services are supported to run in non-global zones that are not part of a zone cluster.

Note This support is available only for native brand non-global zones.

• Sun Cluster Data Service for Apache
• Sun Cluster Data Service for Apache Tomcat
• Sun Cluster Data Service for DHCP
• Sun Cluster Data Service for Domain Name Service (DNS)
• Sun Cluster Data Service for Kerberos
• Sun Cluster Data Service for MaxDB
• Sun Cluster Data Service for mySQL
• Sun Cluster Data Service for N1 Grid Service Provisioning Server
• Sun Cluster Data Service for Oracle
• Sun Cluster Data Service for Oracle Application Server
• Sun Cluster Data Service for PostgreSQL
• Sun Cluster Data Service for Samba
• Sun Cluster Data Service for SAP
• Sun Cluster Data Service for SAP liveCache
• Sun Cluster Data Service for SAP Web Application Server
• Sun Cluster Data Service for Sun Java System Application Server
• Sun Cluster Data Service for Sun Java System Message Queue Server
• Sun Cluster Data Service for Sun Java System Web Server
• Sun Cluster Data Service for SWIFTAlliance Access
• Sun Cluster Data Service for SWIFTAlliance Gateway
• Sun Cluster Data Service for Sybase ASE

The SUNW.gds resource type is supported in a native brand non-global zone.

Note Procedures for the version of Sun Cluster HA for Sun Java™ System Directory Server that uses Sun Java System Directory Server 5.0 and 5.1 are located in Sun Cluster 3.1 Data Service for Sun ONE Directory Server. Beginning with Version 5.2 of Sun ONE Directory Server, see the Sun ONE Directory Server or Sun Java System Directory Server installation documentation.

Note The Sun Cluster Data Service for Agfa IMPAX 6.3 is supported only on the Solaris 10 OS in this Sun Cluster release. This data service is not supported on the Solaris 9 OS.

Top

Zone Cluster Support

The following Sun Cluster data services are supported in a zone cluster:

• Sun Cluster Data Service for Apache (failover and scalable)
• Sun Cluster Data Service for MySQL - requires the following minimum patch version to run in a zone cluster:
  • SPARC: 126032-06
  • x86: 126033-07
• Sun Cluster Support for Oracle RAC

The SUNW.gds resource type is supported in a zone cluster.

Top

Resource-Type Names

The following is a list of Sun Cluster data services and their resource types.

Top

File Systems

Solaris 10 SPARC

Top

Solaris 10 x86

Top

Solaris 9 SPARC

Top

Memory Requirements

Sun Cluster 3.2 1/09 software requires the following memory requirements for every cluster node:

• Minimum of 1 Gbytes of physical RAM (2 Gbytes typical)
• Minimum of 6 Gbytes of available hard drive space

Actual physical memory and hard drive requirements are determined by the applications that are installed. Consult the application's documentation or contact the application vendor to calculate additional memory and hard drive requirements.

Top

Solaris Operating System (OS)

Sun Cluster 3.2 1/09 software and Quorum Server software require the following minimum versions of the Solaris OS:

• Solaris 9 (SPARC only) - Solaris 9 9/05, Solaris 9 9/05 HW
• Solaris 10 - Solaris 10 5/08, Solaris 10 10/08, Solaris 10 5/09*
      *The Solaris 10 5/09 OS requires the latest Solaris patches

  Note Sun Cluster software does not support multiple versions of Solaris software in the same running cluster.

Top

Sun Management Center

This Sun Cluster release supports Sun Management Center software versions 3.6.1 and 4.0.

Top

Sun StorageTek™ Availability Suite

This Sun Cluster release supports Sun StorageTek Availability Suite 4.0 software on the Solaris 10 OS only.

Top

Sun StorEdge™ Availability Suite

This Sun Cluster release supports Sun StorEdge Availability Suite 3.2.1 software on the Solaris 9 OS only.

Top

Volume Managers

This Sun Cluster release supports the following volume managers.

Solaris 10 SPARC

Solaris 10 x86

Solaris 9 SPARC

Top

Sun Cluster Security Hardening

Sun Cluster Security Hardening uses the Solaris Operating System hardening techniques recommended by the Sun BluePrints™ program to achieve basic security hardening for clusters. The Solaris Security Toolkit automates the implementation of Sun Cluster Security Hardening.

The Sun Cluster Security Hardening documentation is available at http://www.sun.com/blueprints/0203/817-1079.pdf. You can also access the article from http://www.sun.com/software/security/blueprints. From this URL, scroll down to the Architecture heading to locate the article "Securing the Sun Cluster 3.x Software." The documentation describes how to secure Sun Cluster 3.x deployments in a Solaris environment. The description includes the use of the Solaris Security Toolkit and other best-practice security techniques recommended by Sun security experts. The following data services are supported by Sun Cluster Security Hardening:

• Sun Cluster HA for Apache
• Sun Cluster HA for Apache Tomcat
• Sun Cluster HA for DHCP
• Sun Cluster HA for DNS
• Sun Cluster HA for MySQL
• Sun Cluster HA for N1 Grid Engine
• Sun Cluster HA for NFS
• Sun Cluster HA for Oracle
• Sun Cluster HA for Oracle E-Business Suite
• Sun Cluster Support for Oracle Real Application Clusters
• Sun Cluster HA for PostgreSQL
• Sun Cluster HA for Samba
• Sun Cluster HA for Siebel
• Sun Cluster HA for Solaris Containers
• Sun Cluster HA for SWIFTAlliance Access
• Sun Cluster HA for SWIFTAlliance Gateway
• Sun Cluster HA for Sun Java System Directory Server
• Sun Cluster HA for Sun Java System Message Queue
• Sun Cluster HA for Sun Java System Messaging Server
• Sun Cluster HA for Sun Java System Web Server
• Sun Cluster HA for Sybase ASE
• Sun Cluster HA for WebLogic Server
• Sun Cluster HA for WebSphere MQ
• Sun Cluster HA for WebSphere MQ Integrator

Top

Known Issues and Bugs

The following known issues and bugs affect the operation of the Sun Cluster 3.2 1/09 release. Bugs and issues are grouped into the following categories:

• Administration
• Data Services
• GUI
• Installation
• Localization
• Upgrade

Top

Administration

Logical-Hostname/Shared-Address Resource Creation Fails in Zone Cluster When Adapters Are Not in IPMP (6798276 and 6796386)

Problem Summary: The creation of a logical-hostname or shared-address resource in a zone cluster fails if any public adapter in the cluster is not part of an IPMP group. The action fails with the following message:

Workaround: Configure in IPMP groups all public adapters that are available on the cluster nodes, including those that are not currently used by Sun Cluster software.
Top

An Update to HAStoragePlus Resources Fails in Sun Cluster 3.2 1/09 on Solaris 9 (6787430)

Problem Summary: On the Solaris 9 OS, an update to HAStoragePlus resources fails with the hastorageplus_validate method being killed with the SIGSEGV signal.

Workaround: Delete the failing resource and recreate the HAStoragePlus resource with the latest required property values.

Top

Validate Method Core Dumps While Creating Logical-Hostname/Shared-Address Resource in Zone Cluster (6784809)

Problem Summary: The creation of a logical-hostname resource or a shared-address resource in a zone cluster fails when there are no other resource groups configured in the cluster. The validate method dumps core and the resource is not created. This problem is not seen if any resource groups already exist in the cluster, either in the global zone or in native brand non-global zones.

Workaround: Before you create a logical-hostname resource or a shared-address resource in a zone cluster, if no resource group already exists in the cluster, create an empty resource group in the global zone by using the clesourcegroup command.

Top

Removal of Last Quorum Device From Two-Host Cluster Does Not Work for a Quorum Server or NAS Device (6775391)

Problem Summary: On a two-node cluster with installmode disabled, the last quorum device cannot be removed by using clquorum remove quorum_device_name, which is the usual procedure to remove a quorum device. It is necessary to use the force option, -F, to remove the last quorum device on a two-node cluster with installmode disabled. The usage is clquorum remove -F quorum_device_name. However, this force option works only for scsi2, scsi3, and software_quorum types of quorum devices.

If the last quorum device configured on a two-node cluster with installmode disabled is a quorum server or a NAS quorum device, it cannot be removed by using clquorum remove quorum_device_name or clquorum remove -F quorum_device_name. If the user attempts this action, error messages similar to the following would be shown (in these examples, the last quorum device is a quorum server named qs1, and clq is the short form equivalent of clquorum):

• For clquorum remove qs1:

  clq:  (C115344) Cluster quorum could be compromised if you remove "qs1".

• For clquorum remove -F qs1:

  Warning: Force option used.This cluster is at risk of experiencing a serious outage.Configure a new quorum device to prevent loss of cluster quorum and outages.clq:  (C115344) Cluster quorum could be compromised if you remove "qs1".

Workaround: If the last quorum device configured on a two-node cluster, with installmode disabled, is a quorum server or a NAS quorum device, do the following to remove this last quorum device:

1. Become superuser on a node running in cluster mode.
2. Enable installmode.

   # cluster set -p installmode=enabled

3. Remove the last quorum device.

   # clquorum remove quorum_device_name

Top

Scalable Services Fail to Fail Over When There Is a Network Outage (6774504)

Problem Summary: The failover of scalable resources does not happen if there is a network outage on the nodes where the resources are currently online. Due to this issue, the resources do not fail over to a healthy node and the resource's status still shows as online on the failed node.

Workaround: There is no workaround for this issue. Contact your Sun service representative to determine whether a patch is available.

Top

clresourcegroup create and add-node Subcommands Cannot Prevent Mixing Global-Cluster Nodes With Zone-Cluster Nodes (6762845)

Problem Summary: When zone clusters are configured, the clresourcegroup create and clresourcegroup add-node subcommands do not prevent the node list from containing both the global-cluster nodes and the zone-cluster nodes. You will see the following error message when you try to bring a resource group with mixed nodes online:

Workaround: If a resource group's node list contains both global-cluster nodes and zone-cluster nodes, change the node list so that the list contains only global-cluster nodes or only zone-cluster nodes. Use the clresroucegroup add-node or clresourcegroup remove-node commands to add or remove nodes from the node list.
Top

Resource Groups Might Come Online on Less-Preferred Nodes When a Zone Cluster is Rebooted. (6761158)

Problem Summary: When an entire zone cluster is rebooted at once, for example, by executing the clzonecluster reboot command, resource groups might fail to come online on their most-preferred nodes. For example, you might find that all resource groups come online on the same node, even though their node lists indicate a preference for different nodes.

Workaround: There are two simple workarounds. However, neither of them exactly matches the behavior that should occur when this bug is fixed:

• Manually execute the clresourcegroup remaster command on all resource groups, after the zone cluster has booted up:

  # clresourcegroup remaster -Z myzonecluster +

  This will cause all resource groups in the zone cluster to switch onto their most-preferred master, if they are not already mastered by that node. This command should be executed just once after a zone cluster reboot, when all of the zone-cluster nodes are up and running. However, on an unattended cluster, this workaround will not automatically take effect, for example, after a power outage when power is restored, since the clresourcegroup remaster command must be executed manually.

• Set the Failback property to TRUE on all resource groups in the zone cluster:

  # clresourcegroup set -Z myzonecluster -p Failback=TRUE +

  With this setting, a resource group might initially come online on a less-preferred node, but will automatically switch over to a more-preferred node that joins the cluster membership. However, the automatic switchover will be performed any time a more-preferred node joins the zone-cluster membership, not only when the zone cluster is initially booted.

Top

rpcbind Authentication Errors When JASS is Deployed with Sun Cluster 3.2 1/09 (6727594)

Problem Summary: When JASS is installed and enabled on a cluster node, the Sun Cluster commands to retrieve IPMP group status, scstat -i or clnode status -m, might fail with the following message:

Workaround: Add IP addresses that correspond to all cluster nodes' private hostnames to the rpcbind line in the /etc/hosts.allow file. By default, the cluster nodes' private hostnames are of the form clusternodeN-priv. Their corresponding IP addresses can be determined by using the following command:

For instance, on a four-node cluster, you might update the rpcbind line in /etc/hosts.allow to be:

Top

Whole-Root Zones of ip-type=exclusive Do Not Have Access to SUNW.LogicalHostname Resource Methods (6711918)

Problem Summary: Attempts to create SUNW.LogicalHostname resources for whole-root zones with ip-type=exclusive fail. Error messages similar to the following can be found in the syslog:

Workaround: For each whole-root zone with ip-type=exclusive that might host a SUNW.LogicalHostname resource, configure a file-system resource that mounts the method directory from the global zone.

Top

Data Services

The START_TIMEOUT for WebAS Instance Needs to be Changed to 600 (6808410)

Problem Summary: The default START_TIMEOUT value for the SAP WebAS resource is 300 seconds. The Sun Cluster agent for  SAP WebAS starts the instance and then waits for the server to be completely up (by probing for the server) before successfully returning from the start method. Depending on your system resources and the load on your server, the startup of the SAP WebAS instance might take longer than 300 seconds.

Workaround: If the WebAS instance needs more than 300 seconds to start up on the cluster nodes, create the SAP WebAS resource with a higher value for the START_TIMEOUT property, for example, 600, 

Top

Scalable WebAS Resource Fails to Come Online if Wrapper Script Is Not Used in Webas_start_up_script (6808403)

Problem Summary: For the SAP Web Application Server (WebAS) scalable data service, as of the SAP 6.4 release it should no longer be necessary to create wrapper scripts when you create the WebAS instances. But even in SAP 64 and later versions the WebAS resource does not come online if no wrapper scripts are created.

Workaround: To make the SAP Web Application Server (WebAS) instances highly available as a scalable service, create wrapper scripts as described in Step 7 of  "How to Install and Configure the SAP Web Application Server and the SAP J2EE Engine" from the Sun Cluster HA for SAP Web Application Server Guide. You must use these wrapper scripts as the startup- and shutdown-script extension properties when you create the WebAS instances, regardless of which version of SAP software you run.

Top

BEA WLS Managed Server Went to Admin State After Fault Injection, Client Access Failed (6626817)

Problem Summary: When a non-global zone that runs BEA WebLogic Server managed servers panics and goes down, the data service for WebLogic Server fails over and starts all its resources in another available non-global zone in the cluster. In some situations, after the failover the WebLogic Managed Servers might go into in the Admin state instead of the Running state and require operator assistance.

Workaround: Use the WebLogic Server administration interface to manually change the state to the Running state.

Top

GUI

RAC Wizard Under Some Scenarios Tries to Create Configuration in a Zone Cluster Even When Global Cluster Is Selected (6801490)

Problem Summary: The RAC wizard sometimes attempts to create the configuration for a zone cluster even when the user selects global cluster.

Workaround: Perform the following steps:

1. Remove the state file /opt/cluster/lib/ds/history/RacStateFile, if present.
2. Restart the common agent container.

   # cacaoadm restart

Top

The RAC GUI Storage Wizard Does Not Create the Resources in a Zone Cluster when Solaris Volume Manager Is Selected (6799694)

Problem Summary: The web-based RAC storage wizard attempts to create the scalable device group resources and resource groups for the Solaris Volume Manager for Sun Cluster disk groups in the global cluster, when the user selects Solaris Volume Manager from the storage-scheme selection panel.

Workaround: Use the text-based wizard. The problem exists only in the web-based wizard.

Top

clsetup Does Not Display Existing VxVM Device Groups in the Global Zone (6798909)

Problem Summary: The wizards do not list the existing VxVM device groups in the global zone.

Workaround: Use the command-line interface for RAC configuration on VxVM storage.

Top

Configuration of RAC Framework Fails in a Zone Cluster with a Resource type not found Error (6768473)

Problem Summary: The Oracle RAC wizard fails to create the configuration for a zone cluster with a Resource type not found error message.

Workaround: Copy the RTR files that are used by the RAC configuration, which are present in the directories /usr/cluster/lib/rgm/rtreg and /opt/cluster/lib/rgm/rtreg, from the global cluster to the zoneclusterpath/root/usr/cluster/lib/rgm/rtreg and zoneclusterpath/root/opt/cluster/lib/rgm/rgtreg directories, respectively. Namely, the following RTR files need to be copied:

From /usr/cluster/lib/rgm/rtreg in the global zone:

From /opt/cluster/lib/rgm/rtreg in the global zone:

Top

Installation

Auto Discovery During Installation for Sun Cluster/Transport Does Not Work for igb Interfaces on Solaris OS x64 Platforms (6821699)

Problem Summary: During a Sun Cluster installation, auto discovery for Sun Cluster/transport does not work for igb interfaces on Solaris OS x64 platforms.

Workaround: When you run scinstall and you are prompted for the interconnect adapters, select Other and type each igb interface name.

Top

sczonecfg Should Set name_service to NONE if Global Zone Does Not Use Name Service (6798938)

Problem Summary: When you create a new zone cluster, the only common system identification parameter that the user is required to specify is the root password. The zone cluster software obtains the values for any other sysid parameters, such as name_service and timezone, from the global zone's /etc/sysidcfg file.

If the /etc/sysidcfg file does not exist on the system or the zone-cluster software cannot open the file to obtain the parameter values, the name_service parameter is left unspecified. Because a value of name_service= is invalid, system initialization of the new zone cluster fails and the boot process does not complete. The user is prompted to supply the missing parameter value.

Workaround: When you create a new zone cluster, manually specify a value for the name_service parameter. Specify either the name service to use or NONE if no name service is used.

Top

Common Agent Container Dependency on RGM Service Was Removed in rgm_starter Service (6779277)

Problem Summary: When you install Sun Cluster 3.2 1/09 software and establish the cluster, the service svc:/application/management/common-agent-container-1:default might be in the maintenance state. If so, Sun Cluster Manager and some of the command-line interfaces will not work.

Workaround: Add the cluster Resource Group Manager (RGM) service rgm-starter as a dependency of the cluster-management service on all cluster nodes right after Sun Cluster 3.2 1/09 software is installed and configured. Perform the following steps on each node of the cluster:

1. Become superuser on a node of the cluster.
2. Add a property group of dependents to the rgm-starter SMF service.

   # svccfg -s rgm-starter:default addpg dependents framework

3. Add the value for the dependents property group for the rgm-starter SMF service.

   # svccfg -s rgm-starter:default addpropvalue dependents/rgm_cacao fmri: svc:/application/management/common-agent-container-1:default

4. Verify that the value is correctly set for the dependent property group for the rgm-starter SMF service.

   # svccfg -s rgm-starter:default listprop | grep dependents

5. If the service svc:/application/management/common-agent-container-1:default is in the maintenance state, clear the common-agent-container SMF service from the maintenance state and enable the SMF service.

   # svcadm clear svc:/application/management/common-agent-container-1:default
   # svcadm enable svc:/application/management/common-agent-container-1:default

6. Verify that Sun Cluster Manager now works properly by using a web browser to connect to the URL https://_nodename_:6789.

Top

Localization

[zh_CN]:Result of System Requirements Checking Is Wrong (6495984)

Problem Summary: When you use the installer utility to install Sun Cluster software, the software that checks the system requirements incorrectly reports that the swap space is 0 Mbytes in the Simplified Chinese and Traditional Chinese locales.

Workaround: Ignore this reported information. In these locales, you can run the following command to determine the correct swap space:

Top

Upgrade

Rebooting Multiple Upgraded Nodes Into the Cluster During Rolling Upgrade Panics Nodes on Old Software (6788866)

Problem Summary: In a rolling upgrade, old software nodes are taken out of cluster mode and upgraded to the new software, and then booted back into cluster mode. Depending on the quorum configuration and availability of operational quorum on the running cluster, the user could take one or more than one nodes out of the cluster at a time for upgrades, and then boot them back into cluster after upgrade.

While performing rolling upgrade of a cluster to Sun Cluster 3.2 1/09 software, if more than one upgraded node is booted back into the cluster at the same time, then one or more of the nodes running the older software version in the cluster might panic.

Workaround: After nodes are upgraded to run Sun Cluster 3.2 1/09, boot only one node at a time into cluster mode to join the running cluster.

Top

Common Agent Container Dependency on RGM Service Was Removed in rgm_starter Service (6779277)

Problem Summary: When you upgrade to Sun Cluster 3.2 1/09 software by using the live upgrade method, the service svc:/application/management/common-agent-container-1:default might be in the maintenance state. If so, Sun Cluster Manager and some of the command-line interfaces will not work.

Workaround: Add the cluster Resource Group Manager (RGM) service rgm-starter as a dependency of the cluster-management service on all cluster nodes right after Sun Cluster 3.2 1/09 software is upgraded. Perform the following steps on each node of the cluster:

1. Become superuser on a node of the cluster.
2. Add a property group of dependents to the rgm-starter SMF service.

   # svccfg -s rgm-starter:default addpg dependents framework

3. Add the value for the dependents property group for the rgm-starter SMF service.

   # svccfg -s rgm-starter:default addpropvalue dependents/rgm_cacao fmri: svc:/application/management/common-agent-container-1:default

4. Verify that the value is correctly set for the dependent property group for the rgm-starter SMF service.

   # svccfg -s rgm-starter:default listprop | grep dependents

5. If the service svc:/application/management/common-agent-container-1:default is in the maintenance state, clear the common-agent-container SMF service from the maintenance state and enable the SMF service.

   # svcadm clear svc:/application/management/common-agent-container-1:default
   # svcadm enable svc:/application/management/common-agent-container-1:default

6. Verify that Sun Cluster Manager now works properly by using a web browser to connect to the URL https://_nodename_:6789.

Top

Sun Cluster Manager Does Not Work After Upgrading From Pre-3.2 2/08 Release to 3.2 1/09 Release (6768115)

Problem Summary: After performing a live upgrade from the Sun Cluster 3.2 release or earlier to Sun Cluster 3.2 1/09 software, activating the new BE, and booting the nodes, the service svc:/system/cluster/rgm:default is in maintenance state and the service svc:/application/management/common-agent-container-1:default is offline. Due to these states, Sun Cluster Manager cannot display the cluster configuration data.

Workaround: Become superuser and issue the following commands on all nodes:

You can then verify that Sun Cluster Manager works properly by connecting to the URL https://_nodename_:6789.
Top

Upgrade From 3.2 Plus Patch 126107-15 Failed; pkgrm of SUNWscr Fails (6747530)

Problem Summary: On the Solaris 10 OS, upgrading Sun Cluster software from the 3.2 2/08 release to the 3.2 1/09 release fails when removing the package SUNWscr.

Workaround: Before starting the upgrade, install one of the following pairs of patches as appropriate, which provide a new pkg_preremove script that resolves this problem. The patch version numbers shown are the minimum required:
140017-01 and 126538-02 (S10 Sparc)
140018-01 and 126539-02 (S10 X86)
If you have already started the upgrade and it fails with the above error, you can install the appropriate patches, then restart the upgrade by running scinstall -u update.
Top

Zones With ip-type=exclusive Cannot Host SUNW.LogicalHostname Resources After Upgrade (6702621)

Problem Summary: Resource type SUNW.LogicalHostname is registered at version 2 (use the clresourcetype list command to display the version). After upgrade, logical-hostname resources can be created for zones with ip-type=exclusive, but network access to the logical hostname, for example, telnet or rsh, does not work.

Workaround: Perform the following steps:

1. Delete all resource groups with a node list that contains a zone with ip-type=exclusive that hosts logical-hostname resources.
2. Upgrade the SUNW.LogicalHostname resource type to version 3:

Top

Patches and Required Firmware Levels

This section provides information about patches for Sun Cluster configurations, including the following subsections:

• Applying the Sun Cluster 3.2 1/09 Core Patch
• Removing the Sun Cluster 3.2 1/09 Core Patch
• Patch Management Tools
• SunSolve Online
• Sun Cluster Patch Lists

If you are upgrading to Sun Cluster 3.2 1/09 software, see the Sun Cluster Upgrade Guide for Solaris OS. Applying a Sun Cluster 3.2 1/09 Core patch does not provide the same result as upgrading the software to the Sun Cluster 3.2 1/09 release.

Note Read the patch README file before applying or removing any patch.

If you are using the rebooting patch (node) method to install the Sun Cluster core patch 126105 (S9/SPARC), 126106 (S10/SPARC), or 126107 (S19/x64), you must have the 125510-02, 125511-02, or 125512-02 core patch, respectively, installed before you can install the 126105, 126106, or 126107 patch. If you do not have the 125510-02, 125511-02, or 125512-02 patch installed and want to install 126105, 126106, or 126107, you must use the rebooting cluster method.
See the following list for examples of patching scenarios:

• If you have Sun Cluster 3.2 1/09 software using the Solaris 10 Operating System on SPARC with patch 125511-02 installed and want to install 126106, use the rebooting node or rebooting cluster method.

• If you have Sun Cluster 3.2 1/09 software using the Solaris 10 Operating System on SPARC without 125511-02 installed and want to install 126106, choose one of the following methods:
  • Use the rebooting cluster method to install 126106.
  • Install 125511-02 by using the rebooting node method and then install 126106 by using the rebooting node method.

    Note You must be a registered SunSolve™ user to view and download the required patches for the Sun Cluster product. If you do not have a SunSolve account, contact your Sun service representative or sales engineer, or register online at http://sunsolve.sun.com.

    Top

Applying the Sun Cluster 3.2 1/09 Core Patch

Complete the following procedure to apply the Sun Cluster 3.2 1/09 core patch. Ensure that all nodes of the cluster are maintained at the same patch level.

How to Apply the Sun Cluster 3.2 1/09 Core Patch

1. Install the patch by using the usual rebooting patch procedure for a core patch.
2. Verify that the patch has been installed correctly on all nodes and is functioning properly.
3. Register the new version of resource types SUNW.HAStoragePlus, SUNW.ScalDeviceGroup, and SUNW.ScalMountPoint that are being updated in this patch. Perform resource type upgrade on any existing resources of these types to the new versions.

For information about registering a resource type, see "Registering a Resource Type" in the Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

Caution If the Sun Cluster 3.2 1/09 core patch is removed, any resources that were upgraded in Step 3 must be downgraded to the earlier resource type versions. The procedure for downgrading requires planned downtime of these services. Therefore, do not perform Step 3 until you are ready to commit the Sun Cluster 3.2 1/09 core patch permanently to your cluster.

Top

Removing the Sun Cluster 3.2 1/09 Core Patch

Complete the following procedure to remove the Sun Cluster 3.2 1/09 core patch.

How to Remove the Sun Cluster 3.2 1/09 Core Patch

Top

1. List the resource types on the cluster.

   # clresourcetype list

2. If the list returns SUNW.HAStoragePlus:5, SUNW.ScalDeviceGroup:2, or SUNW.ScalMountPoint:2, you must remove these resource types. For instructions about removing a resource type, see "How to Remove a Resource Type" in the Sun Cluster Data Services Planning and Administration Guide for Solaris OS.
3. Reboot all nodes of the cluster into noncluster, single-user mode.
   For instructions about rebooting cluster nodes into noncluster, single-user mode, see "How to Boot a Cluster Node in Noncluster Mode" in the Sun Cluster System Administration Guide for Solaris OS.
4. Remove the Sun Cluster 3.2 1/09 core patch from each node on which you installed the patch.

   # patchrm patch-id

5. Reboot into cluster mode all of the nodes from which you removed the Sun Cluster 3.2 1/09 core patch.
   Rebooting all of the nodes from which you removed the Sun Cluster 3.2 1/09 core patch before rebooting any unaffected nodes ensures that the cluster is formed with the correct configuration information on all nodes. If all nodes on the cluster were patched with the core patch, you can reboot the nodes into cluster mode in any order.
6. Reboot any remaining nodes into cluster mode.

For instructions about rebooting nodes into cluster mode, see "How to Reboot a Cluster Node" in the Sun Cluster System Administration Guide for Solaris OS.

Top

Patch Management Tools

Information about patch management options for the Solaris OS is available at the web sites for Sun xVM Ops Center and Sun Connection Update Manager.

The following tools are part of the Solaris OS. Refer to the version of the manual that is published for the Solaris OS release that is installed on your system:

• Information for using the Solaris patch management utility, patchadd, is provided in Solaris Administration Guide: Basic Administration at http://docs.sun.com.
• Information for using Solaris Live Upgrade to apply patches is provided in the Solaris installation guide for Live Upgrade and upgrade planning at http://docs.sun.com.

If some patches must be applied when the node is in noncluster mode, you can apply them in a rolling fashion, one node at a time, unless a patch's instructions require that you shut down the entire cluster. Follow procedures in How to Apply a Rebooting Patch (Node) in Sun Cluster System Administration Guide for Solaris OS to prepare the node and boot it into noncluster mode. For ease of installation, consider applying all patches at once to a node that you place in noncluster mode.

Top

Patch for Cluster Support for StorageTek 2530 Array

The Sun StorageTek Common Array Manager (CAM) software, Version 6.0.1, provides SCSI3 or PGR support for the Sun StorageTek 2530 array for up to three nodes. The patch is not a required upgrade for the Sun StorEdge 6130, 2540, 6140, and 6540, and StorageTek FLX240, FLX280 and FLX380 platforms. The CAM 6.0.1 patch is available from the Sun Download Center.

Top

SunSolve Online

The SunSolve™ Online Web site provides 24-hour access to the most up-to-date information regarding patches, software, and firmware for Sun products. Access the SunSolve Online site at http://sunsolve.sun.com for the most current matrixes of supported software, firmware, and patch revisions.

Sun Cluster 3.2 1/09 third-party patch information is provided through a SunSolve Info Doc. This Info Doc page provides any third-party patch information for specific hardware that you intend to use in a Sun Cluster 3.2 1/09 environment. To locate this Info Doc, log on to SunSolve. From the SunSolve home page, type Sun Cluster 3.x Third-Party Patches in the search criteria box.

Before you install Sun Cluster 3.2 1/09 software and apply patches to a cluster component (Solaris OS, Sun Cluster software, volume manager software, data services software, or disk hardware), review each README file that accompanies the patches that you retrieved. All cluster nodes must have the same patch level for proper cluster operation.

For specific patch procedures and tips on administering patches, see Chapter 10, "Patching Sun Cluster Software and Firmware" in Sun Cluster System Administration Guide for Solaris OS.

Top

Sun Cluster Patch Lists

The Sun Cluster Patch Klatch provides a complete and up-to-date list of patches that you need to apply to the Solaris OS, to Sun Cluster software, and to other software in your cluster configuration, based on the versions of the particular software that you are using.

Top

Sun Cluster 3.2 1/09 Documentation

The Sun Cluster 3.2 1/09 user documentation set consists of the following collections:

• Sun Cluster 3.2 1/09 Software Manuals for Solaris OS
• Sun Cluster 3.2 1/09 Reference Manuals for Solaris OS
• Sun Cluster 3.2 1/09 Data Service Manuals for Solaris OS (SPARC Platform Edition)
• Sun Cluster 3.2 1/09 Data Service Manuals for Solaris OS (x86 Platform Edition)
• Sun Cluster 3.1-3.2 Hardware Collection for Solaris OS (SPARC Platform Edition)
• Sun Cluster 3.1-3.2 Hardware Collection for Solaris OS (x86 Platform Edition)

  Note Procedures for the version of Sun Cluster HA for Sun Java™ System Directory Server that uses Sun Java System Directory Server 5.0 and 5.1 are located in Sun Cluster 3.1 Data Service for Sun ONE Directory Server. Beginning with Version 5.2 of Sun ONE Directory Server, see the Sun ONE Directory Server or Sun Java System Directory Server installation documentation.

  Some manuals were not updated since the previous Sun Cluster 3.2 release. Their content, however, also applies to the Sun Cluster 3.2 1/09 release.

The Sun Cluster 3.2 1/09 user documentation is available in PDF and HTML format at the following web site:

http://docs.sun.com/app/docs/prod/sun.cluster32

Note Beginning with the Sun Cluster 3.2 release, documentation for individual data services is not translated. Documentation for individual data services is available only in English.

Top

Sun Cluster 3.2 1/09 Software Manuals for Solaris OS

Top

Sun Cluster 3.2 1/09 Reference Manuals for Solaris OS

Top

Sun Cluster 3.2 1/09 Data Service Manuals for Solaris OS (SPARC Platform Edition)

Top

Sun Cluster 3.2 1/09 Data Service Manuals for Solaris OS (x86 Platform Edition)

Top

Sun Cluster 3.1-3.2 Hardware Collection for Solaris OS (SPARC Platform Edition)

Top

Sun Cluster 3.1-3.2 Hardware Collection for Solaris OS (x86 Platform Edition)

Top

Documentation Issues

This section discusses errors or omissions for documentation, online help, or man pages in the Sun Cluster 3.2 1/09 release.

• Software Installation Guide
• System Administration Guide
• Data Services Developer's Guide
• Upgrade Guide
• Network-Attached Storage Devices Manual
• Man Pages

Top

Software Installation Guide

This section discusses errors and omissions in the Sun Cluster Software Installation Guide for Solaris OS.

Change to Restriction of ZFS for Root (/) File Systems

In "Guidelines for the Root (/) File System" in Chapter 1, a Note states that no file-system type other than UFS is valid for the root file system. This restriction is no longer valid. However, the /globaldevices partition for the global-devices namespace still requires the UFS file system.

Top

Restriction for Encapsulation of a ZFS Root Disk

The procedure "SPARC: How to Encapsulate the Root Disk" in Chapter 5, "Installing and Configuring Veritas Volume Manager", is not valid when the root disk uses ZFS rather than UFS. For a ZFS root disk, you must instead create the root disk group on local nonroot disks, or choose to not create a root disk group.

Top

1483, for 3.2u2 New Choice for the Location of the Global-Devices Namespace

The following information applies to all procedures in the chapter "Establishing the Cluster" that you would use to establish a new cluster or a new cluster node.

When you establish a new cluster or new cluster node on the Solaris 10 OS, you can now choose between using a dedicated partition or using a lofi-based file on which to create the global-devices namespace.

Use one of the following methods to choose a lofi device for the global-devices namespace:

• Run the interactive scinstall utility in Custom mode and, when prompted, specify the use of a lofi device.
• If a /globaldevices entry does not exist in the /etc/vfstab files on the hosts that you are configuring as cluster nodes, run the interactive scinstall utility in Typical mode and, when prompted, choose to use a lofi device.

  Note: If the scinstall utility in Typical mode finds an /etc/vfstab entry for /globaldevices, the utility creates the namespace on that file system, the same as in previous Sun Cluster releases. If you choose not to use lofi and no /etc/vfstab entry for /globaldevices exists, the installation fails.

• Add the -G lofi option to the scinstall command in noninteractive mode or the clnode add command.

If you use a lofi device to create the global-devices namespace, no /global/.devices/node@nodeID entry is added to the /etc/vfstab file. The root file system must have 100 MBytes of free space to create a lofi-based global-devices namespace.

See the following for additional information:

• For information about specifying a lofi device when you establish a cluster or cluster node from the command line, see the scinstall(1M) and clnode(1CL) man pages.
• For more information about lofi devices, see the lofi(7D) man page.
• For procedures to migrate the global-devices namespace from a dedicated partition to a lofi device or the reverse, see Migrating the Global-Devices Namespace.

Top

Replacement Command for sccheck

The sccheck command is replaced by the cluster check command. This new check subcommand performs the same role as sccheck with the exception of checking the existence of mount points. In the procedure "How to Create Cluster File Systems", continue to use the sccheck command.

For details about the check subcommand, see the cluster(1CL) man page.

Top

Setting the IPsec p2_idletime_secs Parameter

After you complete the procedures in "How to Configure IP Security Architecture (IPsec) on the Cluster Private Interconnect", perform the following additional step. This setting provides the time for security associations to be regenerated when a cluster node reboots, and limits how quickly a rebooted node can rejoin the cluster. A value of 30 seconds should be adequate.

4. On each node, edit the /etc/inet/ike/config file to set the p2_idletime_secs parameter.

Add this entry to the policy rules that are configured for cluster transports.

Top

Non-Shared Storage with LDoms Guest-Domain Cluster Nodes

The following is an addition to "SPARC: Guidelines for Sun Logical Domains in a Cluster" .

Non-shared storage - On the Solaris 10 OS, for non-shared storage, such as for LDoms guest-domain OS images, you can use any type of virtual device. You can back such virtual devices by any implement in the I/O domain, such as files or volumes. However, do not copy files or clone volumes in the I/O domain for the purpose of mapping them into different guest domains of the same cluster. Such copying or cloning would lead to problems because the resulting virtual devices would have the same device identity in different guest domains. Always create a new file or device in the I/O domain, which would be assigned a unique device identity, then map the new file or device into a different guest domain.

Top

System Administration Guide

This section discusses errors and omissions in the Sun Cluster System Administration Guide for Solaris OS.

Restoring an Encapsulated Root File System for VERITAS Volume Manager

The instructions in Chapter 11 for restoring an encapsulated root file sytem for VERITAS Volume Manager are incorrect. Replace Step #14 with the following step:

14. Run the clvxvm encapsulate  command to encapsulate the disk and reboot.

Top

EMC SRDF Data Recovery for Failed Campus Cluster Primary Room

A patch to Sun Cluster 3.2 1/09 software changes Sun Cluster behavior so that if the primary campus cluster room fails, Sun Cluster automatically fails over to the secondary room. The patch makes the secondary room's storage device readable and writable, and enables the failover of the corresponding device groups and resource groups. When the primary room returns online, you can manually run the procedure that recovers the data from the EMC Symmetrix Remote Data Facility (SRDF) device group by resynchronizing the data from the original secondary room to the original primary room.

The following are the minimum patch versions that contain this new functionality:

• Solaris 10 SPARC - 126106-30
• Solaris 10 x86 - 126107-31
• Solaris 9 - 126105-29

In the procedure below, dg1 is the SRDF device group name. At the time of the failure, the primary room in this procedure is phys-campus-1 and the secondary room is phys-campus-2.

How to Recover EMC SRDF Data After a Primary Room's Complete Failure

1. Log in to the campus cluster's primary room and become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.
2. From the primary room, use the symrdf command to query the replication status of the RDF devices and view information about those devices.

   phys-campus-1# symrdf -g dg1 query

   A device group that is in the split state is not synchronized.

3. If the RDF pair state is split and the device group type is RDF1, then force a failover of the SRDF device group.

   phys-campus-1# symrdf -g dg1 -force failover

4. View the status of the RDF devices.

   phys-campus-1# symrdf -g dg1 query

5. After the failover, you can swap the data on the RDF devices that failed over.

   phys-campus-1# symrdf -g dg1 swap

6. Verify the status and other information about the RDF devices.

   phys-campus-1# symrdf -g dg1 query

7. Establish the SRDF device group in the primary room.

   phys-campus-1# symrdf -g dg1 establish

8. Confirm that the device group is in a synchronized state and that the device group type is RDF2.

   phys-campus-1# symrdf -g dg1 query

Top

Replacement Command for sccheck

The sccheck command is replaced by the cluster check command. This new check subcommand performs the same role as sccheck. For any procedures that use sccheck, run cluster check instead. The exception is that, to check the existence of mount points when you create a cluster file system, continue to use the sccheck command.

In addition, a new list-checks subcommand is added. Use cluster list-checks to display a list of all available cluster checks.

For details about the check and list-checks subcommands, see the cluster(1CL) man page.

Top

Migrating the Global-Devices Namespace

The following procedures describe how to move an existing global-devices namespace from a dedicated partition to a lofi device or the opposite:

• How to Migrate the Global-Devices Namespace From a Dedicated Partition to a lofi Device
• How to Migrate the Global-Devices Namespace From a lofi Device to a Dedicated Partition

How to Migrate the Global-Devices Namespace From a Dedicated Partition to a lofi Device

1. Become superuser on the global-cluster voting node whose namespace location you want to change.
2. Ensure that no file named /.globaldevices already exists on the node. If the file does exist, delete it.
3. Create the lofi device.

   # mkfile 100m /.globaldevices# lofiadm -a /.globaldevices# LOFI_DEV=`lofiadm /.globaldevices`# newfs `echo ${LOFI_DEV} | sed -e 's/lofi/rlofi/g'` < /dev/null# lofiadm -d /.globaldevices

4. In the /etc/vfstab file, comment out the global-devices namespace entry. This entry has a mount path that begins with /global/.device/node@nodeID.
5. Unmount the global-devices partition /global/.devices/node@nodeID.
6. Disable and re-enable the globaldevices and scmountdev SMF services.

   # svcadm disable globaldevices# svcadm disable scmountdev# svcadm enable scmountdev# svcadm enable globaldevices

   A lofi device is now created on /.globaldevices and mounted as the global-devices file system.

7. Repeat these steps on any other nodes whose global-devices namespace you want to migrate from a partition to a lofi device.
8. From one node, populate the global-device namespaces.

   # /usr/cluster/bin/cldevice populate

   On each node, verify that the command has completed processing before you perform any further actions on the cluster.

   # ps -ef | grep scgdevs

   The global-devices namespace now resides on a lofi device.

Top

How to Migrate the Global-Devices Namespace From a lofi Device to a Dedicated Partition

1. Become superuser on the global-cluster voting node whose namespace location you want to change.
2. On a local disk of the node, create a new partition that meets the following requirements:
   • Is at least 512MB in size
   • Uses the UFS file system
3. Add an entry to the /etc/vfstab file for the new partition to be mounted as the global-devices file system.
   1. Determine the current node's node ID.

      # /usr/sbin/clinfo -nnodeID

   2. Create the new entry in the /etc/vfstab file, using the following format:

      blockdevice rawdevice /global/.devices/node@nodeID ufs 2 no global

      For example, if the partition that you choose to use is /dev/did/rdsk/d5s3, the new entry to add to the /etc/vfstab file would then be as follows:

      /dev/did/dsk/d5s3 /dev/did/rdsk/d5s3 /global/.devices/node@3 ufs 2 no global

4. Unmount the global devices partition /global/.devices/node@nodeID.
5. Remove the lofi device that is associated with the /.globaldevices file.

   # lofiadm -d /.globaldevices

6. Delete the /.globaldevices file.

   # rm /.globaldevices

7. Disable and re-enable the globaldevices and scmountdev SMF services.

   # svcadm disable globaldevices# svcadm disable scmountdev# svcadm enable scmountdev# svcadm enable globaldevices

   The partition is now mounted as the global-devices namespace file system.

8. Repeat these steps on any other nodes whose global-devices namespace you want to migrate from a lofi device to a partition.
9. From one node in the cluster, run the cldevice populate command to populate the global-devices namespace.

   # /usr/cluster/bin/cldevice populate

   Ensure that the process completes on all nodes of the cluster before you perform any further action on any of the nodes.

   # ps -ef | grep scgdevs

   The global-devices namespace now resides on the dedicated partition.

Top

Data Services Developer's Guide

This section discusses errors and omissions in the Sun Cluster Data Services Developer's Guide for Solaris OS.

Method Timeout Behavior Is Changed

A description of the change in the behavior of method timeouts as of the Sun Cluster 3.2 release is missing. If an RGM method callback times out, the process is now killed by using the SIGABRT signal instead of the SIGTERM signal. Terminating the process by using the SIGABRT signal causes all members of the process group to generate a core file.

Note Avoid writing a data service method that creates a new process group. If your data service method does need to create a new process group, also write a signal handler for the SIGTERM and SIGABRT signals. Write the signal handlers to forward the SIGTERM or SIGABRT signal to the child process group before the signal handler terminates the parent process. This increases the likelihood that all processes that are spawned by the method are properly terminated.

Top

Upgrade Guide

This section discusses errors and omissions in the Sun Cluster Upgrade Guide for Solaris OS.

Incorrect Command to Change the Private-Network IP Address Range

In Step 9 of "How to Finish Upgrade to Sun Cluster 3.2 1/09 Software", an incorrect command is provided to change the IP address range of the private network.

Incorrect:

Correct:

Top

Network-Attached Storage Devices Manual

The section "Requirements When Configuring Sun NAS Devices as Quorum Devices" omits the following requirement:

The Sun NAS device must be located on the same network as the cluster nodes. If a Sun NAS quorum device is not located on the same network as the cluster nodes, the quorum device is at risk of not responding at boot time within the timeout period, causing the cluster bootup to fail due to lack of quorum.

Top

Man Pages

This section discusses errors, omissions, and additions in the Sun Cluster man pages.

clnode(1CL)

The clnode(1CL) man page states that the clnode evacuate subcommand works only in a global cluster. However, functionality was added to the clnode evacuate subcommand so that it does work within a zone cluster.

Top

clquorum(1CL)

The status subcommand command has been enhanced to actively check the state of quorum devices. The updated description of the status subcommand should read as follows:

Checks and displays the current status and vote counts of quorum devices.

You can use this subcommand in the global zone or in a non-global zone to immediately check the status of quorum devices that are connected to the specified node. For quorum devices that are not connected to the node, this subcommand displays the status that was true during the previous cluster reconfiguration. For ease of administration, use this form of the command in the global zone.

Top

clquorumserver(1CL)

disable and enable

Disregard the information previously reported here about disable and enable subcommands to the clquorumserver command. That information was reported in error; these subcommands were not added to the clquorumserver command.

stop

The new -d option to the stop subcommand is not documented in the clquorumserver(1CL) man page. The following is the updated syntax for the stop subcommand:

/usr/cluster/bin/clquorumserver stop [-d] {+ | quorumserver [...]}

The -d option disables the automatic restarting of the quorum server after a reboot.

Top

clresource(1CL)

The inter-cluster dependencies are not documented in the clresource(1CL) man page.

A resource in a zone cluster can have a dependency on a resource in another zone cluster or on a resource on the global cluster. Also, a resource from the global cluster can have a dependency on a resource in any of the zone clusters on that global cluster. The inter-cluster dependencies can be set only from the global cluster.

You can use the following command to specify the inter-cluster dependencies:

For example, if you need to specify a dependency from resource R1 in zone cluster ZC1 to a resource R2 in zone cluster ZC2, use the following command:

If you need to specify a dependency of zone cluster ZC1 resource R1 on global-cluster resource R2, use the following command:

The existing resource dependencies (Strong, Weak, Restart,and Offline-Restart) are supported.

Top

clresourcegroup(1CL)

The zone cluster affinities are not documented in the clresourcegroup(1CL) man page.

The cluster administrator can specify affinities between a resource group in a zone cluster and a resource group in another zone cluster or a resource group on the global cluster. You can use the following command to specify the affinities between resource groups in different zone clusters:

The affinity types can be one of the following:

• + (weak positive)
• ++ (strong positive)
• - (weak negative)
• -- (strong negative)

Note: The affinity type +++ (strong positive with failover delegation) is not supported in this release.

For example,if you need to specify a strong positive affinity (++) between resource group RG1 in zone cluster ZC1 and resource group RG2 in zone cluster ZC2, use the following command:

If you need to specify a strong negative affinity (--) between resource group RG1 in zone cluster ZC1 and resource group RG2 in the global cluster, use the following command:

Top

clresourcetype(1CL)

The description of the set subcommand currently states, "The only resource type property that you can set is the Installed_nodes property." This property is no longer the only property that is tunable at any time. See the rt_properties(5) man page for the descriptions of resource-type properties, including when each is tunable.

Top

cluster(1CL)

-f Option

The check and list-checks subcommands support the following option, which is not documented in the cluster(1CL) man page:

-F--force

Forces the execution of the subcommand by ignoring the /var/cluster/logs/cluster_check/cfgchk.lck file, if it exists. Use this option only if you are sure that the check and list-checks subcommands are not already running.

Zone Cluster Compatibility

The cluster(1CL) man page states that the cluster command does not work in a zone cluster. However, functionality was added to the following cluster subcommands to make them work within a zone cluster:

• cluster show - Lists the zone cluster, nodes, resource groups, resource types,and resource properties.
• cluster status - Displays the status of zone cluster components.
• cluster shutdown - Shuts down the zone cluster in an orderly fashion.
• cluster list - Displays the name of the zone cluster.
• cluster list-cmds - Lists the following commands, which are supported inside a zone cluster:
  • clnode
  • clreslogicalhostname
  • clresource
  • clresourcegroup
  • clresourcetype
  • clressharedaddress
  • cluster

scdpmd.conf(4)

The following new man page describes how to tune the scdpmd daemon.

Name

scdpmd.conf - Disk-path-monitoring daemon configuration file

Synopsis

/etc/cluster/scdpm/scdpmd.conf

Description

The scdpmd daemon monitors the disk paths and takes appropriate action upon path failures. You can tune this daemon by creating or modifying the configuration file /etc/cluster/scdpm/scdpmd.conf with tunable properties and send a SIGHUP signal to the scdpmd daemon to read the configuration file.

You can tune the following properties in the scdpmd.conf file:

ping_interval

    Description
        Interval, in seconds, between disk-path status checks

    Default
        600

    Minimum
        60

    Maximum
        3600

ping_retry

    Description
        Number of retries to query the disk-path status on failure

    Default
        3

    Minimum
        2

    Maximum
        10

ping_timeout

    Description
        Timeout, in seconds, to query any disk-path status

    Default
        5

    Minimum
        1

    Maximum
        15

Examples

The following is an example of a valid scdpmd.conf file:

ping_interval = 120
ping_retry = 5
ping_timeout = 10

Attributes

See attributes(5) for descriptions of the following attributes:

See Also

cldevice(1CL), clnode(1CL)

TopLabels parameters

Labels

Top