|
Key
This line was removed.
This word was removed. This word was added.
This line was added.
|
Changes (213)
View page history... |
| h3. {anchor:GCVSV} New Features and Functionality |
| This section describes new features and functionality in the Sun Cluster 3.2 2/08 software. |
| The following new features and functionality are provided in the May 2008 Core patch patches to Sun Cluster 3.2 2/08 software. |
| * [Support for Exclusive-IP Zones|#xip] * [New {{Global_zone_override}} resource property|#Global_zone_override] * [(SPARC) Support for solaris9 Brand Zones in HA-Containers|#solaris9brand] |
| * [(SPARC) Support for Oracle 11g|#11g] * [(SPARC) Support for Logical Domains (LDoms) Guest Domains as Cluster Nodes|#opt-guestdomain] |
| The following new features and functionality are provided in the initial Sun Cluster 3.2 2/08 release. |
| * [Sun Service Tags Support|#GFTDP] * [Support for Using NAS Devices From Sun Microsystems as Shared Storage and Quorum Devices|#GFPCU] * [Support for EMC Symmetrix Remote Data Facility (SRDF)|#GFXNP] |
| * [HA-Containers Support for Solaris Zones Brands | #brands] |
| * [Editable Properties in Sun Cluster Manager|#GFXOA] * [New Sun Cluster Upgrade Guide|#GFPPG] |
... |
| [Top|#top] |
| h4. |
| h4. {anchor:xip} Support for Exclusive-IP Zones |
| Sun Cluster software now supports non-global zones of {{ip-type=exclusive}}. This functionality is introduced in patch 126106-17 for SPARC based platforms and 126107-17 for x86 based platforms. To run logical-hostname resources in exclusive-IP zones, you must register version 3 of the {{SUNW.LogicalHostname}} resource type after you apply this patch. # Determine whether version 3 of the {{SUNW.LogicalHostname}} resource type is already registered. {{phys-schost# *clresourcetype list{*}{}}}{{{}SUNW.LogicalHostname:3}} # If {{SUNW.LogicalHostname:3}} is not registered, run the following command. {{phys-schost# *clresourcetype register SUNW.LogicalHostname{*}}} |
| h4. {anchor:11g}(SPARC) Support for Oracle 11g |
| For more details, see ["Registering a Resource Type|http://docs.sun.com/app/docs/doc/820-2561/babedged?a=view] in _Sun Cluster Data Services Planning and Administration Guide_. |
| Sun Cluster software now supports Oracle 11g in HA-Oracle and Oracle RAC configurations on SPARC based platforms. Procedures in the Sun Cluster 3.2 2/08 documentation set are valid for Oracle 11g. If an instruction is specific to a particular Oracle version, use instructions that apply to Oracle 10g for an Oracle 11g configuration. |
| The following information provides guidelines and procedures for using exclusive-IP zones in a Sun Cluster configuration. |
[Top|#top] |
| h4. {excerpt:hidden=true}1655{excerpt} |
| h5. Guidelines for Exclusive-IP Zones |
| * *Logical-hostname resource groups* \- In a resource group that contains a {{LogicalHostname}} resource, if the node list contains any non-global zone with the {{ip-type}} property set to {{exclusive}}, then all zones in that node list must have this property set to {{exclusive}}. Note that a global zone always has the {{ip-type}} property set to {{shared}}, and therefore cannot coexist in a node list that contains zones of {{ip-type=exclusive}}. This restriction applies only to versions of the Solaris OS that use the Solaris zones {{ip-type}} property. * *IPMP groups* \- For all public-network adapters that are used for data-service traffic in the non-global zone, you must manually configure IPMP groups in all {{/etc/hostname._adapter{_}}} files on the zone. This information is not inherited from the global zone. For guidelines and instructions to configure IPMP groups, follow the procedures in [Part VI, IPMP, in _System Administration Guide: IP Services_|http://docs.sun.com/app/docs/doc/816-4554/ipmptm-1?a=view]. * *Private-hostname dependency* \- Exclusive-IP zones cannot depend on cluster private hostnames and addresses. * *Shared-address resources* \- Shared-address resources cannot use exclusive-IP zones. [Top|#top] h5. Configuring IPMP Groups for Exclusive-IP Zones After you create an exclusive-IP non-global zone in a Sun Cluster configuration, perform the following steps. # Manually configure IPMP groups in each {{/etc/hostname._adapter{_}}} file that is on the zone. You must configure an IPMP group for each public-network adapter that is used for data-service traffic in the zone. This information is not inherited from the global zone. See ["Public Networks"|http://docs.sun.com/app/docs/doc/820-2555/z40001f61026966?a=view] in the _Sun Cluster Software Installation Guide_ for more information about configuring IPMP groups in a cluster. # Set up name-to-address mappings for all logical-hostname resources that are used by the zone. ## Add name-to-address mappings to the {{/etc/inet/hosts}} file on the zone. This information is not inherited from the global zone. ## If you use a name server, add the name-to-address mappings. [Top|#top] h4. {anchor:Global_zone_override}New {{Global_zone_override}} Resource Property A new resource property, {{Global_zone_override}}, is introduced in patch 126106-17 for SPARC based platforms and 126107-17 for x86 based platforms. This property overrides the value of the resource type property {{Global_zone}} for a specified resource. For more information about the {{Global_zone_override}} resource property and its effect on the {{Global_zone}} resource type property, see the sections for the [r_properties(5)|#r_properties] and [rt_properties(5)|#rt_properties] man pages. [Top|#top] h4. {anchor:solaris9brand}(SPARC) Support for solaris9 Brand Zones in HA-Containers The Sun Cluster Data Service for Solaris Containers now supports {{solaris9}} branded zones on SPARC based systems. The minimum patch requirement for this functionality is 126020-03. Procedures in the [Sun Cluster Data Service for Solaris Containers Guide|http://docs.sun.com/app/docs/doc/820-2578] that pertain to {{solaris8}} branded zones also apply to {{solaris9}} branded zones. [Top|#top] {anchor:11g}(SPARC) Support for Oracle 11g Sun Cluster software now supports Oracle 11g in HA-Oracle and Oracle RAC configurations on SPARC based platforms. Support is introduced in the May 2008 Core patch. Procedures in the Sun Cluster 3.2 2/08 documentation set are valid for Oracle 11g. If an instruction is specific to a particular Oracle version, use instructions that apply to Oracle 10g for an Oracle 11g configuration. {info:title=Note:}When you install the {{ORCLudlm}} package on Sun Cluster nodes for Oracle 11g RAC support, ensure that the package is installed with a UNIX group that is part of the groups of the {{crs}} user (Oracle Clusterware software owner) and the groups of the {{oracle}} user (Oracle Database software owner). For example, if the {{dba}} group is used for {{ORCLudlm}} installation, the {{dba}} group should be either the primary group or the secondary group for both the {{crs}} user and the {{oracle}} user. {info}[Top|#top] h4. {excerpt:hidden=true}1655 {excerpt} |
| h4. {anchor:opt-guestdomain} (SPARC) Support for Logical Domains (LDoms) Guest Domains as Cluster Nodes |
| You can now configure Logical Domains (LDoms) 1.0.3 guest domains as virtual Sun Cluster nodes. In this configuration, a guest domain node is viewed the same as a physical node of a cluster. Support is introduced in the May 2008 Core patch. |
You can configure Logical Domains (LDoms) guest and I/O domains as virtual Sun Cluster nodes. In other words, you can create a clustered pair, pair+N, N+1, and N*N cluster that consists of any combination of physical machines, LDoms I/O domains, and LDoms guest domains. You can also create clusters that consist of only LDoms I/O domains or only guest domains. |
... |
In this Logical Domains (LDoms) guest domain topology, a cluster and every node within that cluster are located on the same server. Each LDoms guest domain node acts the same as a physical node in a cluster. To preclude your having to include a quorum device, this configuration includes three nodes rather than only two. |
| \\ |
| \\ |
| In this topology, you do not need to connect each virtual switch (vsw) for the private network to a physical network because they need only communicate with each other. In this topology, cluster nodes can also share the same storage device, as all cluster nodes are located on the same server. To learn more about guidelines for using and installing LDoms domains in a cluster, see [SPARC: Guidelines for Logical Domains in a Cluster|#ldoms-guidelines], [SPARC: How to Install Logical Domains Software and Create Domains|#ldoms-install], and [SPARC: Configuring LDoms Domains as Cluster Nodes|#ldomsnodes]. |
| \\ |
| \\ |
| This topology does not provide high availability, as all nodes in the cluster are located on the same server. However, developers and administrators might find this topology useful for testing and other non-production tasks. This topology is also called a "cluster in a box". |
| \\ |
| \\ |
| The following figure illustrates a cluster in a box configuration. |
... |
In this Logical Domains (LDoms) guest domain topology, a single cluster spans two different servers and each cluster comprises one node on each server. Each LDoms guest domain node acts the same as a physical node in a cluster. To learn more about guidelines for using and installing LDoms domains in a cluster, see [SPARC: Guidelines for Logical Domains in a Cluster|#ldoms-guidelines], [SPARC: How to Install Logical Domains Software and Create Domains|#ldoms-install], and [SPARC: Configuring LDoms Domains as Cluster Nodes|#ldomsnodes]. |
| \\ |
| \\ |
| The following figure illustrates a configuration in which a single cluster spans two different servers. |
... |
In this Logical Domains (LDoms) guest domain topology, each cluster spans two different servers and each cluster comprises one node on each server. Each LDoms guest domain node acts the same as a physical node in a cluster. In this configuration, because both clusters share the same interconnect switch, you must specify a different private network address on each cluster. Otherwise, if you specify the same private network address on clusters that share an interconnect switch, the configuration fails. |
| \\ |
| \\ |
| To learn more about guidelines for using and installing LDoms domains in a cluster, see [SPARC: Guidelines for Logical Domains in a Cluster|#ldoms-guidelines], [SPARC: How to Install Logical Domains Software and Create Domains|#ldoms-install], and [SPARC: Configuring LDoms Domains as Cluster Nodes|#ldomsnodes]. |
| \\ |
| \\ |
| The following figure illustrates a configuration in which more than a single cluster spans two different servers. |
... |
In this Logical Domains (LDoms) guest domain topology, multiple I/O domains ensure that guest domains, or nodes within the cluster, continue to operate if an I/O domain fails. Each LDoms guest domain node acts the same as a physical node in a cluster. |
| \\ |
| \\ |
| In this topology, the guest domain runs IP network multipathing (IPMP) across two public networks, one through each I/O domain. Guest domains also mirror storage devices across different I/O domains. To learn more about guidelines for using and installing LDoms domains in a cluster, see [SPARC: Guidelines for Logical Domains in a Cluster|#ldoms-guidelines], [SPARC: How to Install Logical Domains Software and Create Domains|#ldoms-install], and [SPARC: Configuring LDoms Domains as Cluster Nodes|#ldomsnodes]. |
| \\ |
| \\ |
| The following figure illustrates a configuration in which redundant I/O domains ensure that nodes within the cluster continue to operate if an I/O domain fails. |
... |
| Sun Cluster 3.2 2/08 software supports LDoms 1.0.3 I/O domains and guest domains as cluster nodes, with the following requirements: * Solaris 10 5/08 OS |
| * At least Sun Cluster patch version 1261056-15, installed in the guest domain |
| * The following Solaris 10 patches (minimum versions): ** 137042-01 |
... |
| ** Use different network addresses for each of the clusters. * *Networking in guest domains*\- Network packets to and from guest domains must traverse service domains to reach the network drivers through virtual switches. Virtual switches use kernel threads that run at system priority. The virtual switch threads must be able to acquire needed CPU resources to perform critical cluster operations, including heartbeats, membership, checkpoints, and so forth. |
| While configuring virtual switches with the {{mode=sc{}}}setting {{mode=sc}} setting enables expedited handling of cluster heartbeat packets, the reliability of other critical cluster operations can be enhanced by adding more CPU resources to the service domain under the following workloads: |
| ** High interrupt load, such as due to network or disk I/O. Under extreme load, virtual switches can preclude system threads from running for a long time, including virtual switch threads. ** Real-time threads that are overly aggressive in retaining CPU resources. Real-time threads run at a higher priority than virtual-switch threads, which can restrict CPU resources for virtual-switch threads for an extended time. * *Exporting storage from I/O domains*\- If you configure a cluster that is composed of Logical Domains I/O domains, do not export its storage devices to other guest domains that also run Sun Cluster software. |
| * *Sun *Solaris I/O multipathing* \- Do not run Sun Solaris I/O multipathing software (MPxIO) from guest domains. Instead, run Sun Solaris I/O multipathing software in the I/O domain and export it to the guest domains. |
| * *Private interconnect IP address range* \- The private network is shared by all guest domains that are created on the same physical machine and is visible to all these domains. Before you specify a private-network IP address range to the {{scinstall{}}}utility for use by a guest-domain cluster, ensure that the address range is not already in use by another guest domain on the same physical machine. * *Adapter names* \- When you configure an I/O domain or a guest domain as a cluster node, specify adapter names by their virtual names, {{vnet{_}N{_}}}, such as {{vnet0}}, {{vnet1}}, and so forth. Virtual adapter names are recorded in the {{/etc/path_to_inst}} file. |
... |
| * Sun StorEdge™ NAS Appliance * Sun StorageTek™ NAS Appliance |
| \\ |
| {info:title=Note}A Sun NAS device is supported as a quorum device only in a two-node cluster. |
| {info}[Top|#top]\\ |
h4. {anchor:GFXNP} Support for EMC Symmetrix Remote Data Facility (SRDF) |
| Sun Cluster software now supports the use of EMC Symmetrix Remote Data Facility Software (SRDF) for storage-based data replication, as used in a campus cluster. The addition of this new support provides the user with two choices of storage-based data replication solutions for use with Sun Cluster: |
| * Hitachi True Copy * EMC SRDF |
... |
| {panel} set vds:vd_file_write_flags = 0 |
| {panel} |
| {panel}Contact your Sun service representative to determine whether a patch is available. |
h3. {anchor:excl-ip} Exclusive-IP Zones |
... |
| [Top|#top]h3. {anchor:GAEIL} 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|#top] |
... |
| 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. {info:title=Note}Sun Cluster 3.2 2/08 software is distributed under Solaris Cluster 3.2 2/08 and Sun Java Availability Suite. |
| {info} |
| {info}|| Current Product Name || Former Product Name || |
| | Sun Cluster Manager | SunPlex Manager | | Sun Cluster Agent Builder | SunPlex Agent Builder | |
... |
| * *Solaris Operating System (OS)* \- Sun Cluster 3.2 2/08 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 11/06, Solaris 10 8/07, Solaris 10 5/08*, Solaris 10 10/08\* |
| \*The Solaris 10 5/08 OS requires at least patch version 126106-12 for SPARC based platforms or at least patch version 126107-12 for x86 based platforms. |
| \*The Solaris 10 5/08 and Solaris 10 10/08 OS require the latest Sun Cluster patches. |
| {info:title=Note}Sun Cluster software does not support multiple versions of Solaris software in a running cluster. {info} |
| \\ |
| * *Volume managers* |
... |
| * External Volume Management: Solaris Volume Manager, VxVM | | " | " | QFS 4.5 - Shared QFS file system | * Feature: Oracle RAC |
| * External Volume Management: Solaris Volume Manager for Sun Cluster | |
| | " | " | QFS 4.6 | * Features: COTC-Shared QFS clients outside the cluster, HA-SAM Failover | | " | " | Veritas File System components that are delivered as part of Veritas Storage Foundation 5.0 | Not applicable | |
... |
| * Sun Cluster Data Service for SWIFTAlliance Gateway * Sun Cluster Data Service for Sybase ASE |
| \\ |
| {info:title=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_| http://docs.sun.com/app/docs/doc/817-1529]. |
| Beginning with Version 5.2 of Sun ONE Directory Server, see the Sun ONE Directory Server or Sun Java System Directory Server installation documentation. {info}The following data service is not supported on Solaris 10 OS in this Sun Cluster release. |
| \\ |
| * Sun Cluster Data Service for Agfa IMPAX |
... |
| [Top|#top] |
| Workaround: This issue is not related to the Sun Cluster Data Service for SAP and it is addressed in SAP note 888312. Refer to SAP note 888312 to resolve this issue. |
| h2. {anchor:CHDGGECB} Known Issues and Bugs |
... |
| h3. {anchor:GEBBO} Administration |
| h4. {anchor:6732481}Node Panics when InfiniBand Transport Cable is Disabled (6732481) |
| *Problem Summary:* If the InfiniBand transport cable is disabled on a node that runs Sun Cluster 3.2 or 3.2 2/08, a panic can occur on the node. *Workaround:* Perform one of the following actions: * Upgrade to Sun Cluster 3.2 1/09. * Apply the appropriate Sun Cluster 3.2 CORE patch: the latest version of Patch [126106|http://sunsolve.sun.com/search/advsearch.do?collection=PATCH&type=collections&max=50&language=en&queryKey5=126106&toDocument=yes] (Solaris 10) or Patch [126107|http://sunsolve.sun.com/search/advsearch.do?collection=PATCH&type=collections&max=50&language=en&queryKey5=126107&toDocument=yes] (Solaris 10_x86) is available on SunSolve. [Top|#top] h4. {anchor:GEBGA}The reconf.pl Script Fails on a Sun SPARC Enterprise T5440 Server Running Sun Cluster Software in an LDOM Configuration (6749189) *Problem Summary*: If you have a Sun SPARC Enterprise T5440 Server that runs Sun Cluster software in an LDOM configuration, do not run the reconf.pl script. This script can change device paths and device instances, and can damage or destroy your Sun Cluster configuration. Recovery is extremely difficult, if not impossible. *Workaround*: Do not run the reconf.pl script with this configuration. [Top|#top] |
| h4. {anchor:GEBGZ} {{clnode remove \-f}} Option Fails to Remove the Node With the Solaris Volume Manager Device Group (6471834) |
... |
| *Problem Summary*: The {{Auxnodelist}} property of the shared-address resource cannot be used during shared-address resource creation. If this property is used, it causes validation errors and {{SEGV}} when the scalable resource that depends on this shared address network resource is created. The scalable resource's validate error message is in the following format: {panel} |
| {{Method _methodname_ (scalable svc) on resource _resourcename_ stopped or terminated}} {{due to receipt of signal 11}} {panel} |
| {{Method _methodname_ (scalable svc) on resource _resourcename_ stopped or terminated{}}}{{{}due to receipt of signal 11}} |
| {panel}Also, the core file is generated from {{ssm_wrapper}}. Users will not be able to set the {{Auxnodelist}} property and thus cannot identify the cluster nodes that can host the shared address but never serve as primary. |
*Workaround*: On one node, re-create the shared-address resource without specifying the {{Auxnodelist}} property. Then rerun the scalable-resource creation command and use the shared-address resource that you re-created as the network resource. |
... |
| *Problem Summary*: Writing comments in the shared-QFS {{mcf}} file after the file-system information can cause the {{SUNW.ScalMountPoint}} methods to fail, due to improper handling by the {{SUNW.ScalMountPoint}} resource type. The following is an example of an {{mcf}} file that can lead to a problem: {panel} |
| {{\# File system for data{}}}{{{}Data 300 ms Data on shared{}}}{{\#/dev/md/oracle/dsk/d30 301 md Data on{}}}{{/dev/md/oracle/dsk/d31 302 md Data on }} |
| {panel}{*}Workaround*: Avoid writing the comments after the file-system information in the {{mcf}} file. |
| {{Data 300 ms Data on shared}} |
| h4. Creating an nfs resource throws an error message on s10u3 (6496879) |
| {{\#/dev/md/oracle/dsk/d30 301 md Data on}} |
| {{/dev/md/oracle/dsk/d31 302 md Data on }} |
| *Problem Summary*: Creating an nfs resource throws the following error message on s10u3. |
| {panel} |
| *Workaround*: Avoid writing the comments after the file-system information in the {{mcf}} file. |
| WARNING: lockd: cannot contact statd (error 4), continuing {panel}{*}Workaround*: The warning message shows up as {{lockd}} is being shut down while it is waiting for the {{rpc}} call to contact {{statd}}, because {{statd}} was not able to completely start up or is down. That {{rpc}} call is interrupted when {{svcadm disable nlockmgr}} is issued. This message is harmless and can be ignored. |
| h4. Sun Cluster does not support {{showmount(1M)}} and {{dfmounts(1M)}} (6503661) *Problem Summary*: Using either {{dfmounts}} or {{showmount \-a}} commands to display the current NFS mounts from a node in a Sun Cluster configured as an NFS server does not result in a correct list of the active mounted resources. Instead, the list is usually empty, but can occasionally contain a few entries that may only correspond to historical client activity. *Workaround*: The large number of clients in {{/etc/rmtab}} slows down the {{mountd}} startup in NFSv3, which leads to start timeouts in the cluster. Hence, {{/etc/rmtab}} is truncated for {{mountd}} to start fast. Any changes to the HA-NFS agent to patch up this problem would lead to switchover or failover issues. h4. Sun Cluster Data Service for SAP Web Application Server resource groups failing over when pub net is brought down on all the nodes simultaneously (6554601) *Problem Summary*: Sun Cluster Data Service for SAP Web Application Server resource groups that have another resource group with strong negative affinity with them going offline. The attempt to failover the resource group with strong negative affinity fails, but at the same time the resource group that is declared in {{rg_affinities}} with {{\-\-}} goes to offline on the other node. When we try to bring down the resource groups the resources goes into stop failed state because they need the pub net. The resource group goes to {{stop_failed}} state and the resource group remains unavailable even after pub net is restored until the user intervenes. *Workaround*: Comment out {{/net}} in {{/etc/auto_master}} and remove {{nis}} under {{automount}}, {{hosts}}, {{ipnodes}} in the {{/etc/nsswitch.conf}} file. h4. For SAP version 7.1, the SAP Web Application Server primary instance resource goes to {{Degraded}} mode after switchover of {{enq-msg}} resource group (6759302) *Problem Summary*: In the Sun cluster environment for SAP 7.1, the SAP Web Application Server probe returns an error message with status {{Degraded}} after switch over of {{enq-msg}} resource group. Once the switch over of {{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 an error message "error 503 service unavailable". *Workaround*: Refer to SAP note 966416 and follow the instructions to remove all krnlreg entries from the profile in order to prevent deadlock situations. h4. For SAP version 7.1, the SAP Web Application Server go to {{STOP_Failed}} mode after a public network failure (6766425) *Problem Summary*: In the Sun cluster environment for SAP 7.1, the SAP Web Application Server go to {{STOP_Failed}} mode after a public network failure. After a public network failure, the resource should failover instead of going to {{STOP_Failed}} mode. *Workaround*: This issue is not related to the Sun Cluster Data Service for SAP and it is addressed in SAP note 888312. Refer to SAP note 888312 to resolve this issue. |
| [Top|#top] |
... |
| h3. {anchor:GEAZH} Installation |
| h4. 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|#top] |
| h4. {anchor:GEDPT} Autodiscovery With InfiniBand Configurations Can Sometimes Suggest Two Paths Using the Same Adapter (6299097) |
... |
| *Workaround*: Check whether the file {{/tmp/admin.txt}} exists. If it exists, check whether this file has both read and write permissions for {{root}} user. If {{root}} does not have these permissions, assign the permissions to {{root}} by using the {{chmod}} command. If the file {{/tmp/admin.txt}} does not exist, create this file with read and write permissions for {{root}} user with the following content: {panel} |
| {{mail= }}{{{}instance=overwrite }}{{{}partial=nocheck }}{{{}runlevel=nocheck }}{{{}idepend=nocheck }}{{{}rdepend=nocheck }}{{{}space=nocheck }}{{{}setuid=nocheck }}{{{}conflict=nocheck }}{{{}action=nocheck }}{{{}basedir=default}} |
| {{instance=overwrite }} {{partial=nocheck }} {{runlevel=nocheck }} {{idepend=nocheck }} {{rdepend=nocheck }} {{space=nocheck }} {{setuid=nocheck }} {{conflict=nocheck }} {{action=nocheck }} {{basedir=default}} {panel} |
| {panel}[Top|#top] |
h4. Ensure That a Solaris 10 Cluster Node Is Not Forwarding Packets (6559444) |
... |
| {panel} {{\# */usr/sbin/routeadm{*}}} |
| {panel}IPv4 routing should be enabled and IPv4 forwarding should be disabled. IPv6 routing and forwarding should both be disabled. If IPv4 forwarding was enabled before Sun Cluster software was installed, execute the following command: |
| {panel} |
| IPv4 routing should be enabled and IPv4 forwarding should be disabled. IPv6 routing and forwarding should both be disabled. If IPv4 forwarding was enabled before Sun Cluster software was installed, execute the following command: {panel} |
| {{\# */usr/sbin/routeadm \-d ipv4-forwarding{*}}} |
| {panel} |
| {panel}See also the {{routeadm}}(1M) man page. |
[Top|#top] |
... |
| *Problem Summary*: When the existing version of the common agent container is 2.0 ({{/usr/sbin/cacaoadm \-V}}), it might not be properly upgraded to 2.1 during the installation of Sun Cluster 3.2 2/08 software. The following commands illustrate the problem conditions after installation of Sun Cluster 3.2 2/08 software: {panel} |
| {{\# *cacaoadm \-V{*}}} {{2.1.0}} |
| {{\# *cacaoadm \-V{*}{}}}{{{}2.1.0{}}}{{\# *cacaoadm list-modules \| grep rbac{*}{}}}{{{}com.sun.cacao.rbac 1.0}} |
| {{com.sun.cacao.rbac 1.0}} {panel} |
| {panel}This version of the RBAC module does not work with common agent container 2.1. |
*Workaround*: Finish the upgrade manually on each node as follows: {panel} |
| {{% *su{*}}} {{\# */usr/sbin/cacaoadm prepare-uninstall{*}}} {{\# *cacaoadm start{*}}} {{\# *cacaoadm list-modules \| grep rbac{*}}} {{com.sun.cacao.rbac 2.1}} |
| {{% *su{*}{}}}{{\# */usr/sbin/cacaoadm prepare-uninstall{*}{}}}{{\# *cacaoadm start{*}{}}}{{\# *cacaoadm list-modules \| grep rbac{*}{}}}{{{}com.sun.cacao.rbac 2.1}} {panel}[Top|#top] h4. SUNW.LogicalHostname methods missing from whole-root zones (6711918) *Problem Summary*: When creating {{SUNW.LogicalHostname}} resources for whole-root zones with {{ip-type=exclusive}}, the command might fail because of {{VALIDATE}} method failure. A syslog message similar to the following is reported on some of the nodes: |
| {panel} |
| Jun 6 22:30:45 lzkuda-2a Cluster.RGM.fed: \[ID 838032 daemon.error\] ...Couldn't run method tag. Error in execve: No such file or directory. {panel}{*}Workaround*: Configure a file-system resource that mounts the method directory from the global zone. {panel} phys-schost# *zonecfg \-z sczone* zonecfg:sczone> *add fs* zonecfg:sczone:fs> *set dir=/usr/cluster/lib/rgm* zonecfg:sczone:fs> *set special=/usr/cluster/lib/rgm* zonecfg:sczone:fs> *set type=lofs* zonecfg:sczone:fs> *end* zonecfg:sczone> *exit* |
| {panel}[Top|#top] |
h3. {anchor:GEAZO} Runtime |
| h4. |
| h4. Sun Cluster Manager Might Not Work Correctly with Sun Cluster 3.2 2/08 and Solaris 10 10/08 OS (6584336 and 6701123) |
| *Problem Summary*: If you install the Sun Cluster 3.2 2/08 software with Solaris 10 10/08 OS, the Sun Cluster installation removes the correct version of the SUNWcacaort package and installs the wrong version of this package. The result is that Sun Cluster Manager (formerly SunPlex Manager) might not start. See 6584336 for more information. |
| *Workaround*: After you install Sun Cluster 3.2 2/08 software, reinstall the SUNWcacaort package from the Solaris 10 10/08 OS distribution. You must then manually synchronize the Common Agent Container keys. See the [Sun Cluster Software Installation Guide for Solaris OS|http://docs.sun.com/app/docs/doc/820-2555] for instructions on how to manually synchronize the keys. *Problem Summary*: Sun Cluster Manager is unable to correctly display the information in the Tasks and Topology tabs. See 6701123 for more information. *Workaround*: Perform the following commands on all cluster nodes: {panel} # cd /usr/cluster/lib/SunClusterManager/WEB-INF/classes # mv ds ds.orig # cp \-r /usr/cluster/lib/ds ds # /usr/sbin/smcwebserver restart {panel}[Top|#top] |
| h4. *Transport Warnings on Guest LDoms Cluster Nodes* (6678045) |
... |
| {panel} WARNING: Received non interrupt heartbeat on phys-schost-1:ce5 - phys-schost-4:ce5 - path timeouts are likely. |
| {panel} |
| {panel}{*}Workaround*: These messages are safe to ignore. |
[Top|#top] |
| h2. |
| h4. Cannot Safely Link Applications Against libstlport4 on Sun Cluster (6298053) |
... |
| *Workaround*: On each cluster node, make modifications to the following configuration files. {note:title=Note}If you run the {{sccheck}} utility after removing the {{cluster}} switch from the {{nsswitch.conf}} lookup table, you might receive an error message about the missing {{cluster}} switch. Because you intentionally removed the {{cluster}} switch from the file, you can ignore this message. |
| {note} |
| # {note}# Make a backup copy of the {{/etc/inet/hosts}} file, {{/etc/netmasks}} file, and {{/etc/nsswitch.conf}} file on each node. |
| # Ensure that each private hostname in the cluster is listed in the {{/etc/inet/hosts}} file on each cluster node. These addresses are associated with the {{clprivnet0}} interface. The following example shows how to determine the IP address of a node's private hostname: {panel} |
| {{\#}} {{{*}ifconfig clprivnet0 \| fmt{*}}} {{clprivnet0:}} {{flags=1009843<UP,BROADCAST,RUNNING,MULTICAST,MULTI_BCAST,PRIVATE,IPv4>}} {{mtu 1500 index 5}} {{inet *172.16.4.1* netmask fffffe00 broadcast 172.16.5.255}} {{ether 0:0:0:0:0:1}} {{\# *cat > /etc/inet/hosts <<EOS{*}}} {{172.16.0.129 clusternode1-priv-physical1}} {{172.16.1.1 clusternode1-priv-physical2}} {{{*}172.16.4.1* clusternode1-priv}} {{172.16.0.130 clusternode2-priv-physical1}} {{172.16.1.2 clusternode2-priv-physical2}} {{172.16.4.2 clusternode2-priv}} {{EOS}} |
| {{\#}} {{{*}ifconfig clprivnet0 \| fmt{*}{}}}{{{}clprivnet0:}}{{{}flags=1009843<UP,BROADCAST,RUNNING,MULTICAST,MULTI_BCAST,PRIVATE,IPv4>}}{{{}mtu 1500 index 5{}}}{{{}inet *172.16.4.1* netmask fffffe00 broadcast 172.16.5.255{}}}{{{}ether 0:0:0:0:0:1}} {{\# *cat > /etc/inet/hosts <<EOS{*}{}}}{{{}172.16.0.129 clusternode1-priv-physical1{}}}{{{}172.16.1.1 clusternode1-priv-physical2{}}}{{{}{*}172.16.4.1* clusternode1-priv{}}}{{{}172.16.0.130 clusternode2-priv-physical1{}}}{{{}172.16.1.2 clusternode2-priv-physical2{}}}{{{}172.16.4.2 clusternode2-priv{}}}{{{}EOS}} |
| {panel} # Ensure that all cluster-interconnect netmasks are listed in the {{/etc/netmasks}} file on all cluster nodes. You can use the following script to collect the list of netmasks: |
... |
| {{p==1&&$3 ~ /netmask/{print $2\}'\|}}\ {{while read i; do getent netmasks $i; done > /tmp/netmasks}} |
| {panel}Check the list of collected netmasks, for example: |
| {panel} |
| Check the list of collected netmasks, for example: |
| {{\# *cat /tmp/netmasks{*}{}}}{{{}172.16.1.1 255.255.255.128{}}}{{{}172.16.0.129 255.255.255.128{}}}{{{}172.16.4.1 255.255.254.0}} {panel}When the list is correct, append the entries to the {{netmasks}} files: |
| {panel} |
| {{\# *cat /tmp/netmasks{*}}} {{172.16.1.1 255.255.255.128}} {{172.16.0.129 255.255.255.128}} {{172.16.4.1 255.255.254.0}} {panel} When the list is correct, append the entries to the {{netmasks}} files: {panel} |
| {{\# *cat /tmp/netmasks >> /etc/netmasks{*}}} |
| {panel}4) On each cluster node, remove the {{cluster}} switch from the lookups for the {{hosts}} and {{netmasks}} entries. For example: |
| {panel} |
| 4) On each cluster node, remove the {{cluster}} switch from the lookups for the {{hosts}} and {{netmasks}} entries. For example: \\ |
| _Before modification:_ {panel} ... |
| {{hosts: *cluster* files files dns nisplus dns}}... |
| ... |
| {{netmasks: *cluster* files nisplus}}... |
| ... |
| {panel}{_}After modification:_ |
| {panel} |
| _After modification:_ {panel} |
| ... |
| {{hosts: files files dns nisplus dns}} ... {{netmasks: files nisplus}} ... {panel} |
| {{hosts: files files dns nisplus dns}}... {{netmasks: files nisplus}}... |
| {panel}[Top|#top] |
h4. EFI-Labeled Disks on Top of EMC PowerPath Configuration Cause Error Messages (6536409) |
... |
| *Workaround*: Unencapsulate the root disk before you begin the upgrade. {note:title=Caution}If the previous procedure is not followed correctly, you might experience serious unexpected problems on all nodes being upgraded. Also, unencapsulation and encapsulation of root disk causes an additional reboot (each time) of the node automatically, increasing the number of required reboots during upgrade. |
| {note} |
| {note}[Top|#top] |
h4. {anchor:GESRE} Cannot Use Zones Following Live Upgrade From Sun Cluster Version 3.1 on Solaris 9 to Version 3.2 on Solaris 10 (6509958) |
... |
| # Create a script with the following content. {panel} |
| {{\#\!/bin/ksh}}\\ |
| \\ {{typeset PLATFORM=$\{PLATFORM:-`uname \-p`\}}} {{typeset PATHNAME=$\{PATHNAME:-/cdrom/cdrom0/Solaris_$\{PLATFORM\}/Product/sun_cluster/Solaris_10/Packages\}}} {{typeset BASEDIR=$\{BASEDIR:-/\}}}\\ \\ {{cd $PATHNAME}} {{for i in *}} |
| {{do}} |
| {{ if pkginfo \-R $\{BASEDIR\} $i >/dev/null 2>&1}} {{ then}} {{ mkdir \-p $\{BASEDIR\}/var/sadm/pkg/$i/save/pspool}} {{ pkgadd \-d . \-R $\{BASEDIR\} \-s $\{BASEDIR\}/var/sadm/pkg/$i/save/pspool $i}} {{ fi}}\\ {{done}} |
| {{typeset PLATFORM=$\{PLATFORM:}}{{{}{}}}{{{}{}}}{{{}{}}}{{{}-`uname \-p`\}{-}{}}}{{{}{}}}{{{}{}}}{{{}{}}}{{{}{-}typeset PATHNAME=$\{PATHNAME:-{}}}{{/cdrom/cdrom0/Solaris_$\{PLATFORM\}/Product/sun_cluster/Solaris_10/Packages\}{}}}{{{}typeset BASEDIR=$\{BASEDIR:-/\}}} {{cd $PATHNAME{}}}{{{}for i in *}}{{{}do{}}}{{ if pkginfo \-R $\{BASEDIR\} $i >/dev/null 2>&1{}}}{{ then{}}}{{ mkdir \-p $\{BASEDIR\}/var/sadm/pkg/$i/save/pspool{}}}{{ pkgadd \-d . \-R $\{BASEDIR\} \-s $\{BASEDIR\}/var/sadm/pkg/$i/save/pspool $i{}}}{{ fi{}}}{{{}done}} |
| {panel} # Set the variables {{PLATFORM}}, {{PATHNAME}}, and {{BASEDIR}}. Either set these variables as environment variables or modify the values in the script directly. |
| {section} |
| {column:width=10%}{{{}PLATFORM}} |
{column:width=10%} {{PLATFORM}} |
| {column} |
| {column:width=90%} |
| {column:width=90%}The name of the platform. For example, it could be {{sparc}} or {{x86}}. By default, the {{PLATFORM}} variable is set to the output of the {{uname \-p}} command. |
| {column} {section} |
| {section} |
| {column:width=10%}{{{}PATHNAME}} |
{column:width=10%} {{PATHNAME}} |
| {column} |
| {column:width=90%} |
| {column:width=90%}A A path to the device from where the Sun Cluster framework or data service packages can be installed. This value corresponds to the {{\-d}} option in the {{pkgadd}} command. |
| As an example, for Sun Cluster framework packages, this value would be of the following form: {panel} {{/cdrom/cdrom0/Solaris_$\{PLATFORM\}/Product/sun_cluster/Solaris_10/Packages}} |
| {panel}For the data services packages, this value would be of the following form: |
| {panel} |
| For the data services packages, this value would be of the following form: {panel} |
| {{/cdrom/cdrom0/Solaris_$\{PLATFORM\}/Product/sun_cluster_agents/Solaris_10/Packages}} {panel} {column} {section} |
| {section} |
| {column:width=10%}{{{}BASEDIR}} |
{column:width=10%} {{BASEDIR}} |
| {column} |
| {column:width=90%} |
| {column:width=90%}The full path name of a directory to use as the root path, which corresponds to the {{\-R}} option in the {{pkgadd}} command. For live upgrade, set this value to the root path that is used with the {{\-R}} option in the {{scinstall}} command. By default, the {{BASEDIR}} variable is set to the root ({{/}}) file system. |
| {column} {section} |
... |
| {info:title=Note}If the {{pspool}} directory already exists for a package or if the script is run twice for the same set of packages, the following error is displayed at the command prompt: {panel} |
| {{Transferring _pkgname_ package instance}} {{pkgadd: ERROR: unable to complete package transfer}} {{ -\- identical version of _pkgname_ already exists on destination device}} {panel} |
| {{Transferring _pkgname_ package instance{}}}{{{}pkgadd: ERROR: unable to complete package transfer{}}}{{ -\- identical version of _pkgname_ already exists on destination device}} |
| {panel}This is a harmless message and can be safely ignored. |
| {info} # After you run the script for both framework packages and data service packages, boot your nodes into cluster mode. |
... |
| *Problem Summary*: The Sun Cluster nodes fail to boot in cluster mode after a Live Upgrade. This failure happens only when local zones are configured on the nodes with their zone root path on a file system other than the root. The following error messages are seen during the bootup: {panel} |
| {{Configuring devices.}}{{{}NIS domain name is <domain name>}}{{{}Loading smf(5) service descriptions: 15/26ERROR: unable to mount zones: zoneadm: }}{{{}zone '<zonename>': "/usr/lib/fs/lofs/mount \-}}{{{}{}}}{{{}{}}}{{{}{}}}{{{}{-}o ro,nosub,nodevices /space/zones/<zonename>/root -{}}}{{{}{}}}{{{}{}}}{{{}{}}}{{{}-/.alt.sorce.15030/space/zones/<zonename>-{}}}{{{}{}}}{{{}{}}}{{{}{}}}{{{}{}}}{{{}{-}sorce.15030/lu/b" failed with exit code 33{-}{}}}{{{}{}}}{{{}{}}}{{{}{}}}{{{}{-}zoneadm: zone '<zonename>': cannot mount /.alt.sorce.15030/space/zones/<zonename>-{}}}{{{}{}}}{{{}{}}}{{{}{}}}{{{}{}}}{{{}{-}sorce.15030/lu/b on -{}}}{{{}{}}}{{{}{}}}{{{}{}}}{{{}-/space/zones/<zonename>/root: Error 0{-}{}}}{{{}{}}}{{{}{}}}{{{}{}}}{{{}{-}zoneadm: zone '<zonename>': destroying snapshot: No such zone configured{-}{}}}{{{}{}}}{{{}{}}}{{{}{}}}{{{}{-}zoneadm: zone '<zonename>': call to zoneadmd failed{-}{}}}{{{}{}}}{{{}{}}}{{{}{}}}{{{}{-}ERROR: unable to mount zone <zonename> in </.alt.sorce.15030>-{}}}{{{}{}}}{{{}{}}}{{{}{}}}{{{}{-}ERROR: unmounting partially mounted boot environment file systems{-}{}}}{{{}{}}}{{{}{}}}{{{}{}}}{{{}{-}ERROR: umount: warning: /dev/dsk/c0t0d0s0 not in mnttab{-}{}}}{{{}{}}}{{{}{}}}{{{}{}}}{{{}{-}umount: /dev/dsk/c0t0d0s0 not mounted{-}{}}}{{{}{}}}{{{}{}}}{{{}{}}}{{{}{-}ERROR: cannot unmount </dev/dsk/c0t0d0s0>-{}}}{{{}{}}}{{{}{}}}{{{}{}}}{{{}{-}ERROR: cannot mount boot environment by name <sorce.15030>-{}}}{{{}{}}}{{{}{}}}{{{}{}}}{{{}{-}Could not mount the last Live Upgrade Boot Environment{-}{}}}{{{}{}}}{{{}{}}}{{{}{}}}{{{}{-}Please reboot in noncluster mode(boot -{}}}{{\-x) and Repair{}}}{{{}19/26syncing file systems... done{}}}{{{}Program terminate}} |
| {{NIS domain name is <domain name>}} {{Loading smf(5) service descriptions: 15/26ERROR: unable to mount zones: zoneadm: }} {{zone '<zonename>': "/usr/lib/fs/lofs/mount --o ro,nosub,nodevices /space/zones/<zonename>/root }} {{/.alt.sorce.15030/space/zones/<zonename>--sorce.15030/lu/b" failed with exit code 33}} {{zoneadm: zone '<zonename>': cannot mount /.alt.sorce.15030/space/zones/<zonename>--sorce.15030/lu/b on }} {{/space/zones/<zonename>/root: Error 0}} {{zoneadm: zone '<zonename>': destroying snapshot: No such zone configured}} {{zoneadm: zone '<zonename>': call to zoneadmd failed}} {{ERROR: unable to mount zone <zonename> in </.alt.sorce.15030>}} {{ERROR: unmounting partially mounted boot environment file systems}} {{ERROR: umount: warning: /dev/dsk/c0t0d0s0 not in mnttab}} {{umount: /dev/dsk/c0t0d0s0 not mounted}} {{ERROR: cannot unmount </dev/dsk/c0t0d0s0>}} {{ERROR: cannot mount boot environment by name <sorce.15030>}} {{Could not mount the last Live Upgrade Boot Environment}} {{Please reboot in noncluster mode(boot --x) and Repair}} {{19/26syncing file systems... done}} {{Program terminate}} {panel} |
| {panel}{*}Workaround*: Perform the following steps: |
| # Use Live Upgrade to upgrade just the operating system. # Reboot the nodes in noncluster mode. |
... |
| If you are upgrading to Sun Cluster 3.2 2/08 software, see [_Sun Cluster Upgrade Guide for Solaris OS_|http://docs.sun.com/app/docs/doc/820-2270]. Applying a Sun Cluster 3.2 2/08 Core patch does not provide the same result as upgrading the software to the Sun Cluster 3.2 2/08 release. {info:title=Note}Read the patch {{README}} file before applying or removing any patch. |
| {info} |
| {info}If you are using the rebooting patch (node) method to install the Sun Cluster core patch, [125510|http://sunsolve.sun.com/search/document.do?assetkey=1-21-125510-02-1] (S9/SPARC), [125511|http://sunsolve.sun.com/search/document.do?assetkey=1-21-125511-02-1](S10/SPARC), or [125512|http://sunsolve.sun.com/search/document.do?assetkey=1-21-125512-02-1](S19/x64), you must have the \-02 version of the patch installed before you can install later versions of the patch. If you do not have the \-02 patch installed and want to install at least version \-03, you must use the rebooting cluster method. |
| See the following list for examples of patching scenarios: * If you have Sun Cluster 3.2 2/08 software using the Solaris 10 Operating System on SPARC with patch 125511-02 installed and want to install at least 125511-03, use the rebooting node or rebooting cluster method. |
... |
| ** Use the rebooting cluster method to install 125511-03. ** Install 125511-02 by using the rebooting node method and then install 125511-03 by using the rebooting node method. |
| \\ {info:title=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|http://sunsolve.ebay.sun.com]. {info}[Top|#top]\\ |
| {info:title=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.ebay.sun.com/|http://sunsolve.ebay.sun.com]. {info}[Top|#top] |
| h3. {anchor:GEZEZ} Applying the Sun Cluster 3.2 2/08 Core Patch |
... |
| {{\# *patchrm *{*}{_}patch--id{_}{*}}} {panel} |
| # If you are removing a Sun Cluster 3.2 core patch (patch 126106-17 or later for Solaris 10 SPARC or patch 126107-17 or later for Solaris 10 x86) and you are returning to an earlier Sun Cluster 3.2 patch (patch 126106-16 or lower for Solaris 10 SPARC or patch 126107-16 or lower for Solaris 10 x86), you must perform an additional step on each cluster node. Before the first reboot on each cluster node, the pnm SMF manifest must be re-imported for the system to fully recover. Run the following command in the global zone: {panel} {{\# *svccfg import /var/svc/manifest/system/cluster/pnm.xml{*}}} {panel}If you do not re-import the manifest, all data services could go into maintenance mode. |
| # Reboot into cluster mode all of the nodes from which you removed the Sun Cluster 3.2 2/08 core patch. Rebooting all of the nodes from which you removed the Sun Cluster 3.2 2/08 core patch before rebooting any unaffected nodes ensures that the cluster is formed with the correct information in the CCR. If all nodes on the cluster were patched with the core patch, you can reboot the nodes into cluster mode in any order. |
... |
| h3. {anchor:patch} Patch Management Tools |
| Information about patch management options for the Solaris OS is available at the web sites for [Sun Connection Update Manager|http://www.sun.com/download/products.xml?id=4457d96d] and [Sun xVM Ops Center|http://www.sun.com/software/products/xvmopscenter/]. Additional information for using the Solaris patch management utility, {{patchadd}}, is provided in _Solaris Administration Guide: Basic Administration_ at [http://docs.sun.com/app/docs/prod/solaris|http://docs.sun.com/app/docs/prod/solaris]. Refer to the version of this manual that is published for the Solaris OS release that is installed on your system. |
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)|http://docs.sun.com/app/docs/doc/820-2558/6ne5de338?a=view] 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. |
... |
| h3. {anchor:X-1DIMK} 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.ebay.sun.com/|http://sunsolve.ebay.sun.com] for the most current matrixes of supported software, firmware, and patch revisions. |
Sun Cluster 3.2 2/08 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 2/08 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. |
... |
| * [Sun Cluster 3.2 2/08 Data Service Manuals for Solaris OS (x86 Platform Edition)|#RELNOTES-35] * [Sun Cluster 3.1 - 3.2 Hardware Collection for Solaris OS (SPARC Platform Edition)|#RELNOTES-35S] |
| * [Sun Cluster 3.1 - 3.2 Hardware Collection for Solaris OS (x86 Platform Edition)|#RELNOTES-35X]\\ |
| {info:title=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_| http://docs.sun.com/app/docs/doc/817-1529]. |
| Beginning with Version 5.2 of Sun ONE Directory Server, see the Sun ONE Directory Server or Sun Java System Directory Server installation documentation. {info}Some manuals are not updated since the previous Sun Cluster 3.2 release. Their content, however, also applies to the Sun Cluster 3.2 2/08 release. The Sun Cluster 3.2 2/08 user documentation is available in PDF and HTML format at the following web site: |
| \\ |
| bq. [http://docs.sun.com/app/docs/prod/sun.cluster32|http://docs.sun.com/app/docs/prod/sun.cluster32] |
| \\ \\ |
| {info:title=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. |
| {info}[Top|#top]\\ |
| \\ \\ \\ \\ \\ |
| h3. {anchor:RELNOTES-39S} Sun Cluster 3.2 2/08 Software Manuals for Solaris OS |
... |
This section discusses errors or omissions for documentation, online help, or man pages in the Sun Cluster 3.2 2/08 release. |
| * [Software Installation Guide|#SWIG] |
| * [System Administration Guide|#SYSADMIN] * [Data Services Developer's Guide|#GDYMM] |
| * [Sun Cluster Data Service for Sybase ASE Guide|#Sybase] * [Network-Attached Storage Devices Manual|#nas] |
| * [Man Pages|#X-1DINF] [Top|#top] |
| h3. {anchor:SWIG}Software Installation Guide This section discusses errors and omissions in the _Sun Cluster Software Installation Guide for Solaris OS_. h4. Location of Sun Cluster Plug-in for Service Provisioning System In procedures in Chapter 3, "Establishing the Cluster", the location of documentation for the Sun Cluster Plug-in for Sun N1 Service Provisioning System is missing from the HTML version and incorrect in the PDF version. The correct location of this documentation is the following: http://wikis.sun.com/display/SunCluster/Sun+Cluster+Framework+Plug-In [Top|#top] |
| h3. {anchor:SYSADMIN}System Administration Guide |
... |
| h4. Renaming a Replication Device |
| If the name of a replication device group changes, additional steps are required for Hitachi TrueCopy and SRDF. Follow the steps in [How to Configure DID Devices for Replication Using EMC Symmetrix Remote Data Facility (SRDF)|http://docs.sun.com/app/docs/doc/820-2558/6ne5de2us?a=view#gfltb] _in Sun (SRDF)|http://docs.sun.com/app/docs/doc/820-2558/gfltb?a=view] in _Sun Cluster System Administration Guide for Solaris OS_, and perform the following steps: |
For TrueCopy: |
| If the name of the replication device group (and the corresponding global device group) changes, you must rerun the {{cldevice replicate}} command to update the replicated device information. |
For SRDF: |
... |
| {info:title=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. {info} |
| h3. {anchor:Sybase} Sun Cluster Data Service for Sybase ASE Guide |
| This section discusses the errors and omissions in Sun Cluster Data Service for Sybase ASE Guide. h4. HA-Sybase support of non-global zones in SPARC architecture In the Sun Cluster Data Service for Sybase ASE guide the information that HA-Sybase can be installed and configured on SPARC architecture is missing. Installation and configuration of HA-Sybase can be performed on non-global zones in a SPARC architecture also and this is a documentation error. [Top|#top] h2. 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|#top] |
| h3. {anchor:X-1DINF} Man Pages |
... |
The following information for the {{cldevice replicate}} command is missing from the {{cldevice}}(1M) man page: |
| {section} |
| {column:width=10%} |
| {{replicate}} {column} {column:width=90%} |
| The {{replicate}} subcommand is not a supported method for combining DID instances with SRDF. This subcommand can be used only with TrueCopy. To combine DID instances with SRDF, use {{cldevice combine}}. {column} |
... |
* The following option is missing from the {{clresource}}(1CL) man page: |
| {section} |
| {column:width=5%}{{\-u}} |
{column:width=5%} {{\-u}} |
| {column} |
| {column:width=95%} |
| {column:width=95%}With the + operand, specifies that the command operates on resources whose resource group is suspended. If you do not also specify the {{\-u}} option when you specify the + operand, the command ignores all resources whose resource group is suspended. |
| The {{\-u}} option is valid when the + operand is specified with the {{clear}}, {{disable}}, {{enable}}, {{monitor}}, {{set}}, and {{unmonitor}} subcommands. {column} |
... |
| * The description of the + operand should state that, when used with the {{clear}}, {{disable}}, {{enable}}, {{monitor}}, {{set}}, or {{unmonitor}} subcommand, the command ignores all resources whose resource group is suspended, unless you also specify the {{\-u}} option. * The example provided in the definitions of the + and {{\-}} operands for the {{\-p}}, {{\-x}}, and {{\-y}} options are incorrect. The definitions should be as follows: |
| {section} |
| {column:width=5%}{{+}} |
{column:width=5%} + |
| {column} |
| {column:width=95%} |
| {column:width=95%}Adds a value or values to a string array value. Only the set subcommand accepts this operator. You can specify this operator only for the properties that accept lists of string values, for example, {{Resource_dependencies}}. |
| {column} {section} |
| {section} |
| {column:width=5%}{{\-}} |
{column:width=5%} {{\-}} |
| {column} |
| {column:width=95%} |
| {column:width=95%}Deletes a value or values from a string array value. Only the set subcommand accepts this operator. You can specify this operator only for properties that accept lists of string values, for example {{Resource_dependencies}}. |
| {column} {section} |
... |
| * The man page incorrectly states that the {{\-s}} _state_ option is available for use with the {{list}} subcommands. The {{\-s}} option is currently not available in the {{clresourcegroup}} command for the {{list}} subcommand. This option is only available for the {{status}} subcommand. Ignore all information in the man page about the {{\-s}} option when used with the {{list}} subcommand. * The following option is missing from the {{clresourcegroup}}(1CL) man page: |
| {section} |
| {column:width=5%}{{\-u}} |
{column:width=5%} {{\-u}} |
| {column} |
| {column:width=95%} |
| {column:width=95%}Specifies that the command operates on suspended resource groups, if you specify the + operand. If you do not also specify the {{\-u}} option when you specify the + operand, the command ignores all suspended resource groups. |
| The {{\-u}} option is valid when the + operand is specified with the {{add-node}}, {{manage}}, {{offline}}, {{online}}, {{quiesce}}, {{remaster}}, {{remove-node}}, {{restart}}, {{set}}, {{switch}}, and {{unmanage}} subcommands. {column} |
... |
| [Top|#top] |
| h4. {anchor:GGBKZ} {{rt_properties}}(5) |
| h4. {anchor:r_properties} {{r_properties}}(5) |
| The following new resource property is added: h5. {{Global_zone_override}} (boolean) This property is allowed only for resource types that set the {{Global_zone=TRUE}} property in the RTR file. The setting of the {{Global_zone_override}} property overrides the value of the resource type property {{Global_zone}} for the particular resource. Setting the {{Global_zone_override}} property to {{FALSE}} forces the resource methods to execute in the non-global zone in which the resource group is configured, rather than always executing in the global zone as they usually would when the {{Global_zone property}} is set to {{TRUE}}. This property is optional if a default value is specified in the RTR file. If the {{Tunable}} attribute is not specified in the RTR file, the {{Tunable}} value for the property is {{At_creation}}. You can set the {{Tunable}} attribute in the RTR file to {{At_creation}}, {{When_disabled}}, or {{Anytime}}. Use caution when you set the {{Tunable}} attribute to Anytime in the RTR file. Changes to the {{Global_zone_override}} property take effect immediately, even if the resource is online. For example, suppose that the {{Global_zone_override}} tunability is set to {{ANYTIME}} and the {{Global_zone_override}} property is currently set to {{FALSE}} on a resource that is configured in a non-global zone. When the resource is switched online, the starting methods are executed in the non-global zone. If the {{Global_zone_override}} property is then set to {{TRUE}} and the resource is switched offline, the stopping methods are executed in the global zone. Method code must be able to deal with this possibility. If it cannot, then you must set the {{Tunable}} attribute to {{When_disabled}} or {{At_creation}} instead. | Category | Conditional/Optional | | Default | {{TRUE}} | | Tunable | At creation | [Top|#top] h4. {anchor:rt_properties} {{rt_properties}}(5) h5. {{API_version}} |
| In the {{rt_properties}}(5) man page, in the description of the {{API_version}} property, the date shown for the release (12/07) is incorrect. The date should be 2/08, as shown next. |
| {panel} |
| {{3.2 2/08}}\\ |
| bq. {{8}} |
| {panel}[Top|#top] |
| {panel} |
| h5. {{Global_zone}} The following information describes the effect that the new {{Global_zone_override}} resource property has on the {{Global_zone}} resource-type property: A resource type that declares {{Global_zone=TRUE}} might also declare the {{Global_zone_override}} resource property. In that case, the value of the {{Global_zone_override}} property supersedes the value of the {{Global_zone}} property for that resource. |
| [Top|#top] |
... |
The following information about the new {{\-b}} option is missing from the {{scdidadm}}(1M) man page: |
| {section} |
| {column:width=5%} |
| {{\-b}} {column} {column:width=95%} |
| Returns a replicated DID instance to its prior state of being two separate DID instances. {column} {section} |
| Example 5.5 Undo Replicated DID Device Configuration |
| {panel} {{\# *scdidadm \-b 10{*}}} |
| {panel} \\ |
| {panel}[Top|#top] |
h2. {anchor:CJACKKKD} Resolved Issues |
... |
| h3. InfiniBand Host Channel Adapter (HCA) Support (6599044) |
| The Sun SPARC Enterprise T5120 and T5220 servers that use Sun Cluster 3.2 2/08 software no longer require CORE Patch [126106|http://sunsolve.sun.com/search/advsearch.do?collection=PATCH&type=collections&max=50&language=en&queryKey5=126106&toDocument=yes] (Solaris 10) or Patch [126107|http://sunsolve.sun.com/search/advsearch.do?collection=PATCH&type=collections&max=50&language=en&queryKey5=126107&toDocument=yes] (Solaris 10_x86) for InfiniBand configurations. |
| h3. |
| [Top|#top] |
| The Sun SPARC Enterprise T5120 and T5220 servers that use Sun Cluster 3.2 2/08 software no longer require CORE Patch [126106|http://sunsolve.sun.com/search/advsearch.do?collection=PATCH&type=collections&max=50&language=en&queryKey5=126106&toDocument=yes] (Solaris 10) or Patch [126107|http://sunsolve.sun.com/search/advsearch.do?collection=PATCH&type=collections&max=50&language=en&queryKey5=126107&toDocument=yes] (Solaris 10_x86) for InfiniBand configurations. |
| h3. {anchor:89736} Private Network Interfaces Using the {{nxge}} Driver Can Cause a Solaris OS Panic (6525548 and 6726165) |
| *Problem Summary:* Private network interfaces that use the [{{nxge}}(7D)|http://docs.sun.com/app/docs/doc/816-5177/nxge-7d?a=view]driver can cause a panic in the Solaris OS (6525548 and 6726165). A cluster node might panic if the network adapter meets the following criteria: # Your private network adapter uses the {{nxge}} driver. # A change in network adapter state follows a change in cluster configuration. A stack trace of the panic might look like this stack trace (6525548): {panel} \_1cGcursorHgetdata6MIpv_I_+0xb0(3, d0, 7b28d0dc, 60008f6d9d8, c, 4) \_1cNMarshalStreamJget_bytes6MpvIb_v_+0x30(60008f6d9b0, 2a102d05784, 0, 0, 16, 60008f6d9d8) \_1cTckpt_handler_serverHprocess6MrnHservicev_+0x28(60005aed740, 2a102d05858, 0, 703d88a0, 70578000, 0) \_1cJckpt_elemHexecute6M_v_+0x50(60006c4b3c0, 0, 703aa800, 60008f6d980, 60006c4b3e0, 2a102d05858) \_1cTthreadpool_worker_tVdeferred_task_handler6M_v_+0x120(703d9078, 60004b071c0, 60006c4b3c0, 703d8820, 1, 703d8820) \_1cKthreadpoolOthread_handler6FpnTthreadpool_worker\+_t{+}v_\+0x24(60004b071c0, 1883800, 703fac00, 703fac00, 0, 0) cllwpwrapper+0xf8(7b357cac, 0, 70422c00, 70422c00, 0, 0) thread_start+4(2a102d05b70, 18, 0, 0, 0, 0) {panel}A demangled stack trace of the panic might look like this stack trace (6525548): {panel} unsigned cursor::getdata+0xb0(3, d0, 7b28d0dc, 60008f6d9d8, c, 4) void MarshalStream::get_bytes+0x30(60008f6d9b0, 2a102d05784, 0, 0, 16, 60008f6d9d8) void ckpt_handler_server::process+0x28(60005aed740, 2a102d05858, 0, 703d88a0, 70578000, 0) void ckpt_elem::execute+0x50(60006c4b3c0, 0, 703aa800, 60008f6d980, 60006c4b3e0, 2a102d05858) void threadpool_worker_t::deferred_task_handler+0x120(703d9078, 60004b071c0, 60006c4b3c0, 703d8820, 1, 703d8820) void threadpool::thread_handler+0x24(60004b071c0, 1883800, 703fac00, 703fac00, 0, 0) cllwpwrapper+0xf8(7b357cac, 0, 70422c00, 70422c00, 0, 0) thread_start+4(2a102d05b70, 18, 0, 0, 0, 0) {panel}A stack trace of the panic might look like this stack trace (6726165): {panel} > ::stack __1cHserviceKget_object6MpnSMarshalInfo_object{_}{_}pnFCORBAGObject_\_+0x3c(2a10461b860, 706c1bc8, 4, 2e0, 60017b41e08, 5c) __1cTckpt_handler_serverHprocess6MrnHservice{_}{_}v_\+0x58(60019c0d040, 2a10461b860, 5c5c5c5c, 7071f3d8, 0, 0) __1cJckpt_elemHexecute6M_v_\+0x40(6001a9f4dc0, 60010b2ac40, 2a10461b860, 706cbc38, 706cb000, 706cb) __1cTthreadpool_worker_tVdeferred_task_handler6M_v_\+0x114(7071fc10, 60017dec580, 6001a9f4dc0, 7071f328, 1, 7071f328) __1cKthreadpoolOthread_handler6FpnTthreadpool_worker_t{_}{_}v_\+0x1c(60017dec580, 18cec00, 60017e03c40, 0, 706ee000, 706ee) cllwpwrapper+0xc4(2a10461bb70, 7b342de4, 0, 0, 70702000, 70702) thread_start+4(2a10461bb70, 18, 0, 0, 0, 0) {panel}A demangled stack trace might look like this stack trace (6726165): {panel} > ::stack CORBA::Object*service::get_object+0x3c(2a10461b860, 706c1bc8, 4, 2e0, 60017b41e08, 5c) void ckpt_handler_server::process+0x58(60019c0d040, 2a10461b860, 5c5c5c5c, 7071f3d8, 0, 0) void ckpt_elem::execute+0x40(6001a9f4dc0, 60010b2ac40, 2a10461b860, 706cbc38, 706cb000, 706cb) void threadpool_worker_t::deferred_task_handler+0x114(7071fc10, 60017dec580, 6001a9f4dc0, 7071f328, 1, 7071f328) void threadpool::thread_handler+0x1c(60017dec580, 18cec00, 60017e03c40, 0, 706ee000, 706ee) cllwpwrapper+0xc4(2a10461bb70, 7b342de4, 0, 0, 70702000, 70702) thread_start+4(2a10461bb70, 18, 0, 0, 0, 0) > {panel}To determine whether you are using the {{nxge}} driver, type one of the following commands: * If you are using Sun Cluster 3.2, on a cluster node, type {{{*}clinterconnect status{*}}}. * If you are using Sun Cluster 3.1, on a cluster node, type {{{*}scstat \-W{*}}}, as shown in the following example. {panel} {{\# *scstat \-W{*}{}}}{{\-\- Cluster Transport Paths \-\-}}{{ Endpoint Endpoint Status}} {{ Transport path: phys-host-1:nxge1 phys-host-2:nxge1 Path online{}}}{{ Transport path: phys-host-1:nxge0 phys-host-2:nxge0 Path online{}}}{{\#}} {panel} {info:title=Note}You can also use the {{modinfo}} or the {{ifconfig}} command to determine if the {{nxge}} driver is used on a node. For example, you can type {{modinfo -c \| grep nxge}} . {info}Examples of a change in adapter state that follows a change in cluster configuration are: * The cluster switches over and the private adapter fails. * The private adapter is disabled. *Solution:* For SPARC, apply Patch 138048-03 or later to resolve both the Solaris OS panic and the Sun Cluster software issue. For x86, apply Patch 138049-03 or later. *Workaround:* You can perform the following workaround until you apply the appropriate patch: # On each node that uses an {{nxge}} private adapter, add the following entry to the {{/etc/system}} file. {panel} {{set nxge:nxge_rx_threshold_hi=0}} {panel} # Reboot. |
| [Top|#top]\\ |
| pick up v.146 for l10n translation. |
h3. {anchor:89737} Required Minimum Solaris Kernel Patch for UltraSPARC T2 and UltraSPARC T2 Plus Servers *Problem Summary:* The Sun Cluster software requires Solaris kernel Patch 137111-01 or later to avoid a node panic on all UltraSPARC T2 and UltraSPARC T2 Plus-based servers. Without this patch, a panic can occur when a node in the cluster attempts to mount a Global File System (pxfs). A stack trace of the panic is similar to the following: {panel} > ::stack fop_ioctl+0x20(6001bafaac0, 20006657, 2a1044d900c, 200000, 60010803e48, 1313624) __1cRpxfs_namespace_v1Rfs_dependent_implMkernel_ioctl6MpnDvfs_il_i_\+0x110(18f0, 706caed8, 20006657, 2a1044d900c, 70400, 1800) __1cRpxfs_namespace_v1Sufs_dependent_implSconvert_to_primary6Mpn0AFfs_ii{_}{_}i_\+0x100(6001597ff30, 6001198d510, 0, 30004878548, 3000555c3c4, 0) __1cRpxfs_namespace_v1Ffs_iiSconvert_to_primary6Mb_i_\+0x214(6001198d510, 0, 1, 7a6aac2c, 7088c860, 6001198d570) __1cRpxfs_namespace_v1Qrepl_pxfs_serverObecome_primary6MrknL_string_seq_rnFCORBALEnvironment{_}{_}v_\+0x950(6001bad5c00, 6001bad5c00, 2a1044d9828, 6001198d500, 6001913c648, 6001b1e8508) __1cRgeneric_repl_provObecome_primary6MrknL_string_seq_rnFCORBALEnvironment{_}{_}v_\+0xe4(60019e66540, 2a1044d9500, 2a1044d9828, 70400, 1, 2a1044d9358) __1cNrma_prov_implObecome_primary6MrknL_string_seq_rnFCORBALEnvironment{_}{_}v_\+0x78(60017b69910, 7, 2a1044d9828, 7071dc08, 7aa2c240, 7080e418) __1cbX_replica_int_rma_repl_prov_become_primary_receive6FpvrnHservice{_}{_}v_\+0x68(60017b69918, 2a1044d97c8, 706cac18, 2a1044d9828, 706ca000, 2a1044d9500) __1cOremote_handlerUhandle_incoming_call6MrnHservice{_}{_}v_\+0x10c(60017b69920, 2a1044d97c8, 7b2f1920, 60017b69918, 70731348, 7b318e70) 600173c5a00, 2a1044d9828) __1cGrxdoorNhandle_twoway6FpnJrecstream{_}{_}v_\+0xf8(60014ca5380, 70400, 60014ca53b0, b9, 60014ca5450, 2a1044d97c8) __1cTthreadpool_worker_tVdeferred_task_handler6M_v_\+0x114(7080e418, 60017de10a8, 60014ca5380, 60017936f98, 2, 60017936f98) __1cKthreadpoolOthread_handler6FpnTthreadpool_worker_t{_}{_}v_\+0x1c(60017de10a8, 18cec00, 60017dd96a0, 0, 706ee000, 706ee) cllwpwrapper+0xc4(2a1044d9b70, 7b330de4, 0, 0, 70702000, 70702) thread_start+4(2a1044d9b70, 18, 0, 0, 0, 0) {panel}A demangled stack trace of the panic is similar to the following: {panel} > $G C+\+ symbol demangling enabled > ::stack fop_ioctl+0x20(6001bafaac0, 20006657, 2a1044d900c, 200000, 60010803e48, 1313624) int pxfs_namespace_v1::fs_dependent_impl::kernel_ioctl+0x110(18f0, 706caed8, 20006657, 2a1044d900c, 70400, 1800) int pxfs_namespace_v1::ufs_dependent_impl::convert_to_primary+0x100(6001597ff30, 6001198d510, 0, 30004878548, 3000555c3c4, 0) int pxfs_namespace_v1::fs_ii::convert_to_primary+0x214(6001198d510, 0, 1, 7a6aac2c, 7088c860, 6001198d570) void pxfs_namespace_v1::repl_pxfs_server::become_primary+0x950(6001bad5c00, 6001bad5c00, 2a1044d9828, 6001198d500, 6001913c648, 6001b1e8508) void generic_repl_prov::become_primary+0xe4(60019e66540, 2a1044d9500, 2a1044d9828, 70400, 1, 2a1044d9358) void rma_prov_impl::become_primary+0x78(60017b69910, 7, 2a1044d9828, 7071dc08, 7aa2c240, 7080e418) void \_replica_int_rma_repl_prov_become_primary_receive+0x68(60017b69918, 2a1044d97c8, 706cac18, 2a1044d9828, 706ca000, 2a1044d9500) void remote_handler::handle_incoming_call+0x10c(60017b69920, 2a1044d97c8, 7b2f1920, 60017b69918, 70731348, 7b318e70) void rxdoor::handle_request_common+0x3f4(60014ca5450, 2a1044d97c8, 2a1044d981c, 8, 600173c5a00, 2a1044d9828) void rxdoor::handle_twoway+0xf8(60014ca5380, 70400, 60014ca53b0, b9, 60014ca5450, 2a1044d97c8) void threadpool_worker_t::deferred_task_handler+0x114(7080e418, 60017de10a8, 60014ca5380, 60017936f98, 2, 60017936f98) void threadpool::thread_handler+0x1c(60017de10a8, 18cec00, 60017dd96a0, 0, 706ee000, 706ee) cllwpwrapper+0xc4(2a1044d9b70, 7b330de4, 0, 0, 70702000, 70702) thread_start+4(2a1044d9b70, 18, 0, 0, 0, 0) {panel}{*}Solution:* Apply Patch 137111-01 to eliminate the cause of the Solaris kernel panic. [Top|#top] |