自動重新啟動 SRD 中的 gWLM 受管理節點 (高可用性)

每當受管理節點啟動時，該節點的 gWLM 代理程式便會試圖自動重新加入其 SRD 中的節點，以提供更高的可用性。下列為針對上述行為僅需執行的配置步驟：

確認已將每個受管理節點上的 /etc/rc.config.d/gwlmCtl 檔案 (HP-UX) 或
/etc/sysconfig/gwlmCtl 檔案 (Linux) 中之 GWLM_AGENT_START 設為1。只要在執行 gwlmagent 的每一個系統上執行下列命令，即可進行變更：
# /opt/gwlm/bin/gwlmagent --enable_start_on_boot
在相同的檔案中，執行 gwlmcmsd 的系統上亦需要 GWLM_CMS_START=1。然而，當您在安裝作業期間執行 /opt/vse/bin/vseinitconfig 時，便會自動進行變更。
(選用) 編輯 /etc/opt/gwlm/conf/gwlmagent.properties 檔案中的
com.hp.gwlm.node.HA.minimumTimeout
屬性，以設定受管理節點將其本身視為與其 SRD 分離之前，必須度過的秒數下限。設定此屬性，以確保不會因輕微的網路問題導致受管理節點過早將其本身視為與 SRD 分離。
只有在設定值大於 10 倍以上的 gWLM 配置時間間隔時，gWLM 才會使用此值。例如，由於預設配置時間間隔為 15 秒，因此在節點的 gWLM 代理程式試圖重新連接 SRD 之前，節點可有 2.5 分鐘不與其 SRD 通訊的情況下運作。

當一次遺失一個受管理節點或所有受管理節點皆遺失時，此特性便能發揮最佳功效。




	附註：若 vpar 在與其 SRD 失去聯繫的情況下，借用 (borrow) 其他 vpar 的 CPU，則出借的 CPU 可與 SRD 隔開。若 vpar 長時間關閉，請檢查 SRD 是否已在無 vpar 的情況下完成重組，以及是否有足以符合其承諾的 CPU。若否，試用 `vparmodify` 以回收 (reclaim) 部份 CPU (無法本機修改已關閉的 vpar，僅某些版本的 HP-UX 虛擬分區讓您能輕鬆地遠端修改 vpar)。同樣地，若 npar 在與其 SRD 失去聯繫的情況下有數個啟用的 CPU (由於隨機補充包)，則需以手動調整 npar 的大小，以回收那些 npar 仍在 SRD 中的 CPU。若需上述問題的相關資訊，請參閱隨機補充包文件。

自動重新啟動的運作方式

若將 /etc/rc.config.d/gwlmCtl (HP-UX) 或 /etc/sysconfig/gwlmCtl (Linux) 檔案中的
GWLM_AGENT_START 設為 1，便會在受管理節點啟動時自動啟動 gWLM 代理程式 (gwlmagent)。代理程式接著檢查 /etc/opt/gwlm/deployed.config 檔案，以決定其 CMS。接下來，它會試圖與 CMS 聯繫，讓 CMS 重新部署其 SRD 視界。若無法聯繫 CMS，只要所有的節點均同意，便會部署 deployed.config 檔案中的 SRD。

一般而言，若 SRD 因節點關閉或網路通訊問題受到干擾時，gWLM 便會試圖重組 SRD。此外，gWLM 對 SRD 中的節點仍維持叢集的概念。叢集中，只有一個是主節點，其餘皆為非主節點。若主節點與其餘的 SRD 失去聯繫，其餘的 SRD 在一致同意新主節點的情況下，仍可在無原有主節點的情況下以部份叢集 (partial cluster) 繼續運作。若非主節點與其餘的 SRD 失去聯繫，剩下的部份叢集仍可在沒有這個遺失節點的情況下繼續運作。主節點僅是忽略這個遺失的節點，直到再次可使用它為止。




	附註：因嘗試重組 SRD 逾時而未部署任何 SRD，導致無法管理任何資源配置。若發生這種情況，請先停止再重新開啟代理程式，如下節「「Node Failed to Rejoin SRD on Start-up」事件」所述。

相關事件

您可以配置下列與此自動重新啟動特性相關的 SIM 事件：

Node Failed to Rejoin SRD on Start-up (節點無法在啟動時重新加入 SRD)
SRD Reformed with Partial Set of Nodes (以部份節點組重組 SRD)
SRD Communication Issue (SRD 通訊問題)

若需啟用和檢視這些事件的相關資訊，請參閱 gWLM 的「Configure Events」功能表。

您可以利用 SIM 左側窗格的 Event List 項目檢視這些事件。

下列各節說明處理這些事件的方式。

「Node Failed to Rejoin SRD on Start-up」事件

若出現此事件：

停止受影響的 SRD 中每一個受管理節點上的 gwlmagent：
# /opt/gwlm/bin/gwlmagent --stop
重新啟動這些每一個受管理節點上的代理程式：
# /opt/gwlm/bin/gwlmagent
監視 SIM 中的 Shared Resource Domain 視界，或是使用 gwlm monitor 命令，以確認代理程式是否重新加入 SRD。
若問題仍然存在，請檢查 /var/opt/gwlm/gwlmagent.log.0 和 /var/opt/gwlm/gwlm/gwlmcmsd.log.0 檔案以取得其他的診斷訊息。

「SRD Communication Issue」/「SRD Reformed with Partial Set of Nodes」事件




	附註： SRD 中至少要有 3 個受管理節點，才能以部份節點群組進行重組。預設不啟用「SRD Communication Issue」事件。欲檢視這些事件，請透過 VSE Management 功能表列，利用 Tools -> Global Workload Manager -> Events，配置 SIM 中的事件。

若有包含 n 個節點的 SRD，而出現

n - 1 個「SRD Communication Issue」事件

但是

在第一次出現「SRD Communication Issue」事件後五分鐘內 (假設配置時間間隔為 15 秒)，沒有出現「SRD Reformed with Partial Set of Nodes」事件。

您必須：

停止受影響的 SRD 中每一個受管理節點上的 gwlmagent：
# /opt/gwlm/bin/gwlmagent --stop
重新啟動這些每一個受管理節點上的代理程式：
# /opt/gwlm/bin/gwlmagent

手動清理 SRD

gWLM 若無法重組 SRD，如下所述地手動清理 SRD。

清理 A.02.50.00.x (或更新版) 代理程式的 SRD

下文討論的命令是清理 SRD 的進階命令。使用 gwlm undeploy 命令是典型自管理移除主機的建議方法。

自 A.02.50.00.x 版代理程式開始，您可以利用下列命令手動清理 SRD：

# gwlm reset --host=主機

其中，主機指定欲清理具 SRD 的主機。

若上述命令無作用，請遵循下節中的程序進行。

清理任何版本代理程式的 SRD

下列程序清理 SRD，無關 SRD 中的代理程式版本為何：

刪除每一個受管理節點上的 deployed.config 檔案：
# rm -f /etc/opt/gwlm/deployed.config
強制解除 SRD (以下稱為 SRD) 部署，以確認 CMS 和受管理節點皆同意 SRD 的狀態。請在 CMS 上執行下列命令：
# /opt/gwlm/bin/gwlm undeploy --srd=SRD --force
停止每一個受管理節點上的 gwlmagent 協助程式：
# /opt/gwlm/bin/gwlmagent --stop
啟動每一個受管理節點上的 gwlmagent 協助程式：
# /opt/gwlm/bin/gwlmagent




	附註： gWLM CMS 和代理程式若對 SRD 是否已部署或尚未部署無法達成協議，可以使用搭配 `--force` 選項的 `gwlm deploy` 或 `gwlm undeploy` 命令。