Sun Cluster 3.0 5/02 版次注意事項

已知問題

下列已知問題會影響到 Sun Cluster 3.0 5/02 版次的操作。如需最新資訊，請參閱線上 Sun Cluster 3.0 5/02 Release Notes Supplement，網址為 http://docs.sun.com。

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

問題摘要：在 /etc/nsswitch.conf 檔案的 hosts 查找項目中，Sun Cluster HA for NFS 需有 files [SUCCESS=return]，且所有叢集節點上的 /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 軟體已要求所有叢集節點上的 /etc/inet/hosts 中需包含所有 HA IP 位址 (LogicalHostname/SharedAddresses)，且 files 需列示在 nis 或 dns 前面。這個錯誤所處理的其他需求是將 [SUCCESS=return] 列在 files 後面，以及列出 /etc/inet/hosts 檔案中所有的叢集專用 IP 位址。

BugId 4526883

問題摘要：少數狀況下，以 qfe 配接卡結尾的專用互連傳輸路徑無法啟動。

解決方法： 執行下列步驟。

找出故障的配接卡。

Scstat -W 輸出應該顯示以該配接卡作為其路徑端點之一的所有傳輸路徑，且端點狀態為「faulted」或「waiting」。

使用 scsetup(1M) 從叢集配置中移除連接該配接卡的所有電纜。

然後再次使用 scsetup 從叢集配置中移除該配接卡。

將配接卡和電纜重新加入叢集配置中。

確認這些步驟是否解決了問題，以及路徑是否能夠重新啟動。

如果移除電纜和配接卡然後再重新將它們加入的步驟無效，則請重複執行這個程序幾次。如果還是沒有用，則請重新啟動配接卡有問題的節點。這個問題很有可能在節點重新啟動時就會消失了。在您重新啟動該節點前，請確定其餘的叢集是否有足夠的法定票數可承受重新啟動節點。

BugId 4620185

問題摘要：如果 rpc.pmfd 常駐程式監視的程序因處理 signal 而新增一個新的程序，則使用 pmfadm -k tag signal 可能會造成無窮迴圈。這個問題發生的原因可能是 pmfadm(1M) 在剛新增的程序正要加入標記的程序樹中時，嘗試刪除程序樹中的所有程序 (因為刪除前一個程序而導致加入一個程序)。

註解 -

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 磁碟群組的次要號碼，並會產生下列錯誤訊息 device is already in use in another device group。

解決方法：請執行下列步驟為磁碟群組指定新的次要號碼。

找出已在使用的次要號碼。

請注意已在使用的次要號碼以及下列輸出中所列出的主要號碼。

% 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 的設定為何，監視器都會嘗試送交 (giveover)。

解決方法：這個錯誤沒有解決方法。

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 global Solstice DiskSuite/VxVM 裝置群組之檔案系統上的 fsck(1M)，便會失敗。雖然舊版 Solaris 上可能會顯示這個行為，Solaris 9 上也已注意到這個問題。

解決方法：只能在主要節點上啟動 fsck 指令。

BugId 4656531

問題摘要：如果配置了多個接收程式資源，並以相同的接收程式名稱啟動，Sun Cluster HA for Oracle 接收程式資源便無法正確執行。

解決方法：在叢集上執行的多個接收程式請勿使用相同的接收程式名稱。

BugId 4657088

問題摘要： 從 Sun Cluster 3.0 下的 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

問題摘要：搭配 HAStoragePlus 使用 Sun Cluster HA for NFS 時，區塊鎖定不會在故障轉移和切換保護移轉時回復。如此，lockd 便無法由 Sun Cluster HA for NFS 重新啟動，而造成 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 相同的 PID。這樣會造成 HTTP 伺服器啟動失敗。

解決方法：如果 HTTP 伺服器啟動失敗，並顯示如下述的錯誤訊息，請手動移除 HTTP 伺服器的 PID 檔，以正確重新啟動。

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
至此，便可裝載及使用檔案系統。但是，複本中的冗餘尚未回復。如果複本的另一半也遺失了，便無法將鏡像回復到完整的狀態。

請在採取上述修復程序之後重新建立資料庫。