| 瑕疵編號 | | 問題與解決方案 |
SR 8606198063
(JAGad672542) |
| | | 問題：當ServiceGuard協調(coordinator)節點無法擷取所有在叢集執行的套件子網路之狀態、cmsnmpd
與 cmcld失去關連，和停止更新與維護 ServiceGuard MIB時，cmsnmpd 子代理程式仍會維持作用，但是 EMS HA 監督程式及ClusterView
無法擷取目前的 ServiceGuard 套件和服務程式的狀態。使用者會在cmsnmpd
日誌檔 /var/adm/SGsnmpsuba.log中看到下列的錯誤訊息： ***Error: reading status of SUBNET XX.XX.XX.XX |
解決方案： 叢集 snmp 子代理程式 (cmsnmpd) 已修改為能正確地處理在叢集內所有的節點上不存在套件子網路的問題。 |
SR 8606199378
(JAGad68565) |
| | | 問題：當cmsnmpd 子代理程式啟動，或是當本機節點或叢集關閉時產生某些ServiceGuard事件時，則snmpd代理程式會在
/var/adm/snmpd.log 檔案內登錄 "CloneVarBind: Unable to clone vb->value.os_value” 訊息。 解決方案：程式碼已修改為cmsnmpd子代理程式能正確地初始叢集相關的變數，如此便不會再發生錯誤。 |
SR 860620735
(JAGad76208) |
| | | 問題：當ContinentalClusters
客戶在執行ContinentalClusters 命令時，若節點中止，則命令便會產生堆疊追蹤而失效。 解決方案：程式碼已修改為命令會回報正確的資訊，而非失效。 |
SR 8606209075, SR 8606222969
(JAGad78262,
JAGad92075)
|
| | | 問題：在某些節點上有額外的子網路
(但其他的節點上則無) 時，cmquerycl命令逾時並失效。出現如下所示的訊息：
Error: Unable to establish communication to node <nodename>.
Failed to gather configuration information.
此外，其他的ServiceGuard命令(例如 cmviewcl 和 cmhaltpkg)會延遲 10
秒。 解決方案：程式碼已修改為利用INADDR_ANY僅送出一次 UDP探測，以確認節點間的路徑是正確的。 |
SR 8606212693
(JAGad81880) |
| | | 問題：在套件ASCII配置檔中，以下列的設定值來配置套件的自動故障轉回失效： FAILBACK_POLICY AUTOMATIC
STORAGE_GROUP VxVMdg
|
其中，VxVMdg是CVM磁碟群組。 以FAILBACK_POLICY AUTOMATIC 配置的套件，在節點重回叢集時應該移回主要的節點。但在此情況時則否。 解決方案：已增加檢查 AUTO_FAILBACK，現已修正程式碼中的上述行為。 |
SR 8606214965
(JAGad84157) |
| | | 問題：新增節點至叢集時，
cmapplyconf 命令得到一個如下所示的內部錯誤訊息：
Internal error: Got unexpected generic_ack with no error number
from cmclcofnd on <nodename>.
Error:
Unable to retrieve configuration file from node <nodename>:
Error 0
cmapplyconf : Unable to apply the configuration. 解決方案：程式碼已修改為在新增節點至叢集時， cmapplyconf 命令會成功。 |
SR 8606215621
(JAGad84805) |
| | | 問題：若停用磁帶保留/釋出
(reserved release)功能的核心可調整參數時，需要能確保不能使用ServiceGuard共用的磁帶功能之機制。 解決方案：已在共用的磁帶協助程式 cmtaped 中增加檢查，此舉會在停用節點上的可調整核心參數 st_ats_enable時，它會將節點視為無
ATS 磁帶裝置。亦增加 ATS 配置命令中的檢查，以便當叢集中有一或多個節點停用核心可調整參數時，阻隔
ServiceGuard共用的磁帶配置。 |
SR 8606220905
(JAGad90041) |
| | | 問題：cmcld協助程式會因核心延遲時間(
latency)問題，而登錄 "timers delayed x.x seconds" (計時器延遲x.x秒)
訊息。ServiceGuard叢集若有兩個以上的節點沒有叢集鎖定，則在因這類延遲時間問題所導致的長時間核心懸置後，可能會重組為兩個叢集。遇長時間核心懸置的節點會在叢集中的其他節點組成另一個叢集時，組成單節點叢集。 解決方案：程式碼已修改並修正一個邏輯錯誤，並在叢集重組的後半已加入一些程式邏輯後，能確保節點無法從一個有三節點以上的叢集，組成另一個叢集。 |
SR 8606221218
(JAGad90352) |
| | | 問題：若所有的心跳網路有嚴重的網路壅塞或是在極短的時間內任何一個節點上的cmcld協助程式經常發生核心(kernel)懸置時，便能將具雙節點有一個叢集鎖定的ServiceGuard叢集重組為兩個叢集。 解決方案：新增一修正程式，以確保不會錯誤地解除叢集鎖定。此外，會在叢集重組的後半時加入一些程式邏輯以確保叢集鎖定仍在。 |
SR 8606221920
(JAGad91038) |
| | | 問題：當找不到 .rhost 和
cmclnodelist檔案，或是不當地設定時，ServiceGuard命令cmquerycl或cmviewcl不再列印錯誤訊息 "Permission
denied to X"；其中，X是節點的IP 位址。而是命令錯誤地列印錯誤訊息，例如：
"Error: Unable to establish communication to node Y"。 解決方案：訊息的日誌層級已改為預設層級，如此使用者便能看到訊息。 |
SR 8606222631
(JAGad91744) |
| | | 問題：即使網路配置中有浭on-uniform
connection detected” ( 偵測到無一致的連接)的錯誤，ServiceGuard
命令 cmapplyconf 仍能執行。 解決方案：程式碼已修改為當偵測到網路問題時，命令即結束。 |
SR 8606223632
(JAGad92729) |
| | | 問題：有序列連結的 ServiceGuard叢集會在所有的心跳網路轉接器故障時失效；當所有的心跳均使用跨接(crossover)纜線且其中一個節點失效時，它亦會失效。 解決方案：程式碼已修改為能正確地處理當所有心跳網路轉接器故障時的序列連結配置。 |
SR 8606224594
(JAGad93682) |
| | | 問題： 在叢集至少被中止一次後，無法在同一節點上重新啟動配置多個
EMS資源的套件。 解決方案：程式碼已修改為能重新啟動配置多個 EMS資源的套件。 |
SR 8606224615
(JAGad93703) |
| | | 問題：ServiceGuard管理員無法中止Linux叢集。 解決方案：程式碼已修改為能成功地中止 Linux 叢集。 |
SR 8606225203
(JAGad94290) |
| | | 問題：當資源名稱超過40個字元時，ServiceGuard 的 cmstartres 和cmstopres 命令失效，並產生"Resource name
should not be longer than 1024 characters" 錯誤訊息。 解決方案：程式碼已修改為能正確的比較資源名稱與允許的最長長度。 |
SR 8606225932
(JAGad95005) |
| | | 問題： 在極大的壓力測試(stress
test) 下，cmcld的記憶體可能會在叢集組成後跳至 128K。 解決方案：程式碼已修改為能預先配置供cmcld作業所需的額外記憶體。 |
SR 8606226503
(JAGad95572) |
| | | 問題：ServiceGuard 協助程式
/usr/lbin/cmcld 將異常結束，並有核心傾印到 /var/adm/cmcluster/core。狀況會在核心中包括各種不同的異常結束訊息，和各種不同的堆疊追蹤(stack
trace)。在syslog中沒有一個一致的訊息模式能預測此情況。通常失效會在進行「事件監視服務程式」時發生。然而，它常為無法解釋的區段違規(segment violation)。使用cmapplyconf或是使用資源的套件有時會導致此問題。 解決方案：程式碼已修改為能正確地執行記憶體「釋放」(free)
作業，如此便不會再發生異常結束的情形。 |
SR 8606226894
(JAGad95956) |
| | | 問題：配置為使用跨多個容體群組檔案系統的套件，在故障轉移時耗時過久。 解決方案：已更新的套件控制命令集樣本讓您能指定並行容體群組啟用或停用的數量、fsck命令，及檔案系統裝載或卸載。預設是設定為舊的模式，即是將這些操作順序排列。 |
SR 8606229487
(JAGad98539) |
| | | 問題：當ServiceGuard被告知有一個資源的值已改變時，若僅有其中一個RESOURCE_UP_VALUE準則未符，它便會認定該資源已關閉
(down)，並讓套件失效。 解決方案：當資源改變值時，程式碼便藉由至少檢查是否符合其中一個準則來判斷資源的狀態；若仍認為資源是作用中時，便會讓套件繼續執行。 |
SR 8606231088
(JAGade00326) |
| | | 問題：需要當子網路故障並隨即回復時，卻使得套件重新啟動而不是故障轉移之相關文件敘述。 解決方案：下次更新《《管理MC/ServiceGuard》 》和
《以ServiceGuard OPS Edition規劃OPS叢集》手冊時將包括下列的聲明： 「附註：套件若相依在子網路上，且在主要節點上的子網路故障，則套件即將關閉。若子網路隨即回復
(於套件子在承接節點上重新啟動之前)，則套件便可能在主要節點上重新啟動。因而在此情況時，套件便不會切換到叢集內的另一個節點。」 |
可列印版本
