Sun Cluster 3.0 5/02 发行说明

已知问题

以下已知问题会影响 Sun Cluster 3.0 5/02 发行版的运行。有关已知问题的最新信息，请参阅 http://docs.sun.com 上的《Sun Cluster 3.0 5/02 Release Notes Supplement》联机版本。

BugId 4490386

问题摘要：如果在群集中使用 Sun Enterprise 10000 服务器，则当使用某种 I/O 卡配置时，这些服务器会进入应急状态。

解决方法：在群集的 Sun Enterprise 10000 服务器中，不要在其 SBus I/O 板的插槽 0 中安装 UDWIS I/O 卡。

BugId 4501655

问题摘要：如果所要锁定的设备是一个全局设备（例如 /dev/global/rdsk/d4s0），则记录锁定将在其他节点上不起作用。

如果在任何特定节点上多次在后台运行该程序，则记录锁定看上去可正常工作。预计将出现以下情况：在该程序的第一个副本锁定设备的一部分后，该程序的其他副本将发生阻塞，等待该设备被解除锁定。但是，如果从另一个节点上运行此程序，则该程序会成功地再次锁定该设备，尽管它应该发生阻塞以等待设备被解除锁定。

解决方法：没有解决方法。

BugId 4504311

问题摘要：将 Sun Cluster 配置升级到 Solaris 8 10/01 软件（升级到 Sun Cluster 3.0 12/01 时要求这样做）后，将恢复 Apache 应用程序的启动脚本和停止脚本。如果群集中已存在 Apache 数据服务 (Sun Cluster HA for Apache)，并且它采用缺省配置（/etc/apache/httpd.conf 文件存在，但 /etc/rc3.d/S50apache 文件不存在），则 Apache 应用程序会独立于 Sun Cluster HA for Apache 数据服务而自行启动。这可避免启动该数据服务，因为 Apache 应用程序已在运行。

解决方法：在每个节点上执行以下操作。

在关闭节点进行升级之前，请先确定下列链接是否已经存在。如果存在，请确定文件名中是否包含大写字母 K 或 S。
/etc/rc0.d/K16apache /etc/rc1.d/K16apache /etc/rc2.d/K16apache /etc/rc3.d/S50apache /etc/rcS.d/K16apache
如果这些链接已存在，并且文件名中包含大写字母 K 或 S，则不需要采取进一步操作。否则，在将节点升级到 Solaris 8 10/01 软件之后，请执行下一步中的操作。

在将节点升级到 Solaris 8 10/01 软件之后，但在重新引导该节点之前，通过重命名文件（改用小写字母 k 或 s）来移除已恢复的 Apache 链接。

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

BugId 4511699

问题摘要： Sun Cluster HA for NFS 要求将 files [SUCCESS=return] 用于 /etc/nsswitch.conf 文件中的 hosts 查找项，并要求所有群集节点上的 /etc/inet/hosts 文件中包含了所有的群集专用 IP 地址。

否则，在公共网络出现故障的情况下，Sun Cluster HA for NFS 将无法正常进行故障转移。

解决方法： 在群集的每个节点上执行以下步骤。

修改 /etc/nsswitch.conf 文件中的 hosts 项，以便在本地成功解析名称之后，它立即返回成功信息而不必联系 NIS 或 DNS。
hosts:cluster files [SUCCESS=return] nis dns

将所有的群集专用 IP 地址的相关项均添加到 /etc/inet/hosts 文件中。

您只需在 /etc/nsswitch.conf 文件和 /etc/inet/hosts 文件中列出在各物理专用接口上探测到的 IP 地址。逻辑 IP 地址已可以通过群集 nsswitch 库进行解析。

要列出这些物理专用 IP 地址，请在任一群集节点上运行以下命令。

% grep ip_address /etc/cluster/ccr/infrastructure

此列表中的每个 IP 地址都必须分配一个唯一主机名，该主机名不会与域中的任何其他主机名产生冲突。

注意：

Sun Cluster 软件已要求任何 HA IP 地址 (LogicalHostname/SharedAddresses) 都必须出现在所有群集节点上的 /etc/inet/hosts 中，而且还要求 files 列在 nis 或 dns 之前。本错误所强加的附加要求是：必须在 files 之后列出 [SUCCESS=return]，而且必须在 /etc/inet/hosts 文件中列出所有的群集专用 IP 地址。

BugId 4526883

问题摘要：在极少数情况下，终点为 qfe 适配器的那个专用互连传输路径无法使用。

解决方法： 请执行以下步骤：

确定发生故障的适配器。

在 Scstat -W 的输出中，所有将该适配器作为终点的传输路径都应显示在"faulted"或"waiting"状态中。

使用 scsetup(1M) 来从群集配置中删除所有与该适配器之间存在连接的电缆。

再次使用 scsetup 以从群集配置中删除此适配器。

将该适配器和上述电缆重新添加到群集配置中。

检验这些步骤是否已修复了这一问题，以及这些路径现在是否能够使用了。

如果删除电缆和适配器然后重新添加它们这一方法并不奏效，则请多次重复该过程。如果仍不奏效，则请重新引导带有该故障适配器的那个节点。引导该节点后，此问题很可能就消失了。在重新引导节点之前，请确保剩下的群集具有足够的定额选票，能够不受该节点重新引导所带来的影响。

BugId 4620185

问题摘要：如果 rpc.pmfd 守护程序监视一个进程，而该进程在处理某个信号之后又派生了一个新进程，则使用 pmfadm -k tag signal 可能会导致一个无限循环。由于 pmfadm(1M) 试图杀死标记 (tag) 的进程树中的所有进程，但同时派生出的新进程又不断地添加到该进程树中（每杀死一个旧进程就会向该进程树中添加一个派生进程），因此可能会发生上述这种情况。

注意：

使用 pmfadm -s tag signal 时应该不会出现此错误。

解决方法：请使用 pmfadm -s tag signal，而不要使用 pmfadm -k。使用 pmfadm 的 -s 选项时，不会出现使用 -k 选项时所发生的循环情况。

BugId 4629536

问题摘要：同时使用 forcedirectio 安装选项和 mmap(2) 功能可能会导致数据损坏、系统挂起或出现应急状况。

解决方法： 请注意下列限制。

请勿使用在重新安装时所新添加的 directio 安装选项来重新安装文件系统。
请勿通过使用 directio ioctl 来对单个文件设置 directio 安装选项。

如果需要使用 directio，请使用 directio 选项来安装整个文件系统。

BugId 4634409

问题摘要： 如果试图在不同的安装点上安装同一设备，在大多数情况下，系统会发现此错误并使第二个安装无法进行。但是，在极少数情况下，系统可能无法发现此错误，从而可成功完成这两次安装。仅当以下四个条件全部得到满足后才会发生这种情况。

同时执行这两个安装
安装同一设备
将该设备安装到两个不同的安装点上
一个为全局安装，另一个为本地安装。

解决方法：系统管理员在群集中安装文件系统时，应特别注意这一点。

BugId 4638586

问题摘要：在某些情况下，scconf(1M) 命令不能给 VxVM 磁盘组重新分配次编号，并因此显示错误信息，说明设备已用于另一个设备组中。

解决方法： 请执行以下步骤，以便给该磁盘组分配一个新的次编号。

查找已在使用的次编号。

请注意已在使用的次编号，以及下列输出中所列出的主编号。

% ls -l /dev/vx/rdsk/*/*
 
crw-------   1 root     root     210,107000 Mar 11 18:18 /dev/vx/rdsk/fix/vol-01
crw-------   1 root     root     210,88000 Mar 15 16:31 /dev/vx/rdsk/iidg/vol-01
crw-------   1 root     root     210,88001 Mar 15 16:32 /dev/vx/rdsk/iidg/vol-02
crw-------   1 root     root     210,88002 Mar 15 16:33 /dev/vx/rdsk/iidg/vol-03
crw-------   1 root     root     210,88003 Mar 15 16:49 /dev/vx/rdsk/iidg/vol-04
crw-------   1 root     root     210,13000 Mar 18 16:09 /dev/vx/rdsk/sndrdg/vol-01
crw-------   1 root     root     210,13001 Mar 18 16:08 /dev/vx/rdsk/sndrdg/vol-02

选择当前尚未使用的、1000 的其他任何一个倍数作为该新磁盘组的基本次编号。

给出现错误的磁盘组分配一个未使用的次编号。

使用 vxdg 命令的 reminor 选项。

重试上面那个失败了的 scconf 命令。

BugId 4644289

问题摘要：在 Solaris 9 上，当公共网络出现故障时，如果外部名称服务不可用，则 Sun Cluster HA for Oracle 数据服务的停止方法可能会超时。Sun Cluster HA for Oracle 数据服务使用 su(1M) 用户命令来启动和停止数据库。

解决方法：在每个可能成为 oracle_server 或 oracle_listener 资源的主节点的节点上，修改 /etc/nsswitch.conf 文件，以便在其中包含以下用于 passwd、group、publickey 和 project 等数据库的各项。

passwd:files
group:files
publickey:files
project:files

所做的这些修改可确保 su(1M) 命令不会引用 NIS/NIS+ 名称服务，同时还确保在出现网络故障的情况下，可以正确启动和停止数据服务。

BugId 4648767

问题摘要：使用 sendfile(3EXT) 将导致节点出现应急状况。

解决方法：对于这一问题，除了不使用 sendfile 之外，没有其他解决办法。

BugId 4651392

问题摘要： 在 Solaris 9 上，一个正在关闭的群集节点可能出现应急状况，并在其关闭过程中出现以下信息。

CMM:Shutdown timer expired.Halting

解决方法： 这一问题没有解决办法。这种节点应急状况没有其他的不良影响，因此可以当作无害情况处理。

BugId 4653151

问题摘要：如果在 FilesystemMountPoints 扩展特性中指定的文件系统安装点的顺序与在 /etc/vfstab 文件中指定的相应顺序不同，则无法创建 HAStoragePlus 资源。

解决方法：确保在 FilesystemMountPoints 扩展特性中指定的安装点列表与在 /etc/vfstab 文件中指定的顺序相匹配。例如，如果在 /etc/vfstab 文件中是按 /a、/b 和 /c 的顺序指定文件系统项，则 FilesystemMountPoints 中的相应顺序可以是"/a,/b,/c"或"/a,/b"或"/a,/c"，但不能是"/a,/c,/b"。

BugId 4653788

问题摘要：如果 Failover_enabled 扩展特性设置为 FALSE，则意味着资源监视器无法启动资源组故障转移。

但是，如果该监视器正尝试重新启动某个资源，而 START 或 STOP 方法却失败或超时了，则不管 Failover_enabled 的设置如何，该监视器都将尝试进行故障转移。

解决方法： 这一错误没有解决办法。

BugId 4655194

问题摘要：如果发出设备组切换命令 (scswitch -D device-group)，则于本地安装的 VxFS 上的、基于 Solstice DiskSuite 软分区的设备组可能会触发错误。

Solstice DiskSuite 内部执行镜像重新同步操作，这些操作可能会花费大量的时间。镜像重新同步操作会降低冗余级别。此时，VxFS 会报告错误，导致故障监视器/应用程序 IO 出现故障，从而使应用程序重新启动。

解决方法：对于任何已配置了 HAStoragePlus 的 Solstice DiskSuite 设备组，请勿手动切换设备组，而应切换资源组。之后，就将开始毫无故障的设备切换。

或者，也可以在 VxVM 磁盘组上配置本地安装的 VxFS 文件系统。

BugId 4656367

问题摘要： 有些错误信息未包含到 Sun Cluster 3.0 5/02 CD-ROM 中。

解决方法：这些错误信息可"新的错误信息"中找到。

BugId 4656391

问题摘要：如果从非主节点（辅助节点）上，对位于 Sun Cluster 全局 Solstice DiskSuite/VxVM 设备组上的文件系统执行 fsck(1M) 命令，此命令将会失败。在 Solaris 9 上已经发现这一问题，而在更早的 Solaris 发行版中也可能出现过该问题。

解决方法：只在主节点上调用 fsck 命令。

BugId 4656531

问题摘要： 如果将多个侦听程序资源配置为使用同一个侦听程序名称来启动多个侦听程序，则 Sun Cluster HA for Oracle 侦听程序资源不能正常工作。

解决方法：请勿让在群集中运行的多个侦听程序使用同一个侦听程序名称。

BugId 4657088

问题摘要： 如果在 Sun Cluster 下将一个丛与 VxVM 磁盘组断开连接，可能会使群集节点进入应急状态，而且显示以下表明应急状态的字符串。

  panic[cpu2]/thread=30002901460:BAD TRAP:type=31 rp=2a101b1d200 addr=40  
  mmu_fsr=0 occurred in module "vxfs" due to a NULL pointer dereference

解决方法： 在断开丛的连接之前，请先卸载相应的文件系统。

BugId 4657833

问题摘要：如果将资源组特性 auto_start_on_new_cluster 设置为 false，则不会发生故障转移。

解决方法：每次重新引导整个群集时，对于 auto_start_on_new_cluster 特性设置为 false 的资源组，请将 auto_start_on_new_cluster 特性设置为 true，然后将 auto_start_on_new_cluster 特性重置为 false。

# scrgadm -c -g rgname -y auto_start_on_new_cluster=true
# scrgadm -c -g rgname -y auto_start_on_new_cluster=false

BugId 4659042

问题摘要：对于全局安装的 VxFS 文件系统，/etc/mnttab 文件可能不显示全局选项。

解决方法：如果在群集的所有节点上都找到了一个用于该给定文件系统的 /etc/mnttab 项，则说明该文件系统是全局安装的。

BugId 4659091

问题摘要：重新安装全局安装的文件系统后，没有更新 /etc/mnttab。

解决方法：没有解决方法。

BugId 4660479

问题摘要：如果将 Sun Cluster HA for NFS 用于 HAStoragePlus，则在故障转移和切换期间不能恢复块锁定。结果，Sun Cluster HA for NFS 无法重新启动 lockd，从而导致 nfs_postnet_stop 方法失败，而这将使该群集节点崩溃。

解决方法：请勿在 HAStoragePlus 上使用 Sun Cluster HA for NFS。群集文件系统则不会出现该问题。因此，可以在群集文件系统上配置 Sun Cluster HA for NFS，从而解决这一问题。

BugId 4660521

问题摘要：在某个节点上停止 HTTP 服务器时，它将在该节点上留下一个 PID 文件。下一次启动该 HTTP 服务器时，它将检查此 PID 文件是否存在，并检查任何带有此 PID 的进程是否已在运行 (kill -0)。由于 PID 可重复使用，因此可能存在以下情况：即其他一些进程与最后那个 HTTP 服务器使用相同的 PID。这将导致 HTTP 服务器无法启动。

解决方法： 如果 HTTP 服务器无法启动并出现以下错误信息，则请手动删除其 PID 文件，以便正确重新启动该 HTTP 服务器。

Mar 27 17:47:58 ppups4 uxwdog[939]:could not log PID to PidLog 
/app/iws/https-schost-5.example.com/logs/pid, server already running (No such file or directory)

BugId 4662264

问题摘要： 在 Sun Cluster 软件中使用诸如 VxFS 之类的 VERITAS 产品时，为避免出现应急状况，需要增加线程栈的缺省大小。

解决方法：可通过在 /etc/system 文件中添加下列行来增加栈的大小。

set lwp_default_stksize=0x6000
set svc_default_stksize 0x8000

NFS 操作需要用到 svc_default_stksize 项。

在安装 VERITAS 软件包后，请检验 VERITAS 尚未向 /etc/system 文件中添加类似的语句。如果已添加了类似语句，请使用更高的值将这些语句融合为一条语句。

BugId 4663876

问题摘要：在多于两个节点、并带有节点顺序列表的设备组中，如果所要删除的节点不是顺序列表中最后那个节点，则 scconf 输出将显示有关该节点列表的部分信息。

解决方法：

要防止用户遇上此错误，请从节点列表中的最后那个节点开始，逐个删除节点，直到选定的那个节点被删除为止。然后，将其他节点重新添回到设备组中。
要在碰上此错误的情况下修复群集状态，请执行以下操作：
1. 停止使用此设备组的所有服务（文件系统，数据服务等）。
2. 使用 scsetup(1m) 命令从群集的内存中删除该设备组。注意：请让该设备组对象自身保持不动。
3. 使用 scsetup(1m) 命令重新注册该设备组（将其当作一个新的设备组进行注册），并添加正确的节点列表。
在将已删除的那个节点重新添加到设备组中时，请明确给出一个顺序列表，其中包含所有的有效节点。

BugId 4664510

问题摘要：如果在关闭其中一个 Sun StorEdge T3 Array 的电源之后又运行了 scshutdown，此时若重新引导这两个节点，则群集将进入非工作状态。

解决方法： 如果半数复本丢失，请执行下列步骤：

确保群集处在群集模式下。

强制导入磁盘集。
# metaset -s set-name -f -C take

删除已破坏的复本。

# metadb -s set-name -fd /dev/did/dsk/dNsX

释放该磁盘集。
# metaset -s set-name -C release
现在，就可以安装和使用文件系统了。但是，复本中的冗余并没有得到恢复。如果另一半复本丢失，则无法将镜像恢复到正常状态。

在执行了上述的修复过程后，请重新创建数据库。