| 臺灣-繁體中文 |
|
|
|
![]() |
以 ServiceGuard OPS Edition 規劃 OPS 叢集 > 第 3 章. 認識ServiceGuard OPS Edition軟體元件對失效的回應 |
|
ServiceGuard會以特定的方式回應不同的失效。對於大部分硬體失效的回應都不是使用者可以配置的,但是套件和服務的失效,則可以在限制範圍內選擇系統的回應。 ServiceGuard叢集中對於失效最強烈的回應就是HP-UX TOC (Transfer of Control,控制權轉移),也就是立即終止SPU,而不是漸進式停機。TOC是為了保護您資料的完整。 如果叢集不能在預定時間內和多數的叢集成員溝通,如果存在核心懸滯、核心遽降、失控的即時程序,或如果ServiceGuard叢集協助程式cmcld失效時,就會完成TOC。GMS處理程序失效時也會發生TOC (OPS 8.0.5 以上)。發生這種情況時,就會執行系統轉存,並將下列訊息傳送給主控台:
在某些特殊的情況下,ServiceGuard本身也可能會啟動TOC。如果服務的failfast參數在套件配置檔中被啟用,只要有特定的服務失效,整個節點都會以TOC失效。在套件配置檔中,如果NODE_FAILFAST_ENABLED設定為「YES」,只要因發生逾時或故障而導致套件控制命令集以0或1以外的值結束時,整個節點將會有TOC失效。此外,節點層級的失效也可能是由與套件及其服務無關的事件而引起的。失去心跳或者失去叢集協助程式 (cmcld) 或其他重要的協助程式,都會使得節點失效,即使套件及其服務仍然正常也是一樣。 在某些狀況,在TOC之前會先嘗試重新啟動系統。如果能夠在安全時間內重新啟動,TOC就不會發生。在任何一種情形下,套件可以快速的移動到另一個節點。 如果發生嚴重的系統問題,例如系統緊急狀態或者SPU的電路中斷,ServiceGuard就會確認節點失效,並將目前在該節點上執行的套件轉移到叢集中其他地方的承接節點上。各套件的新位置要由套件的配置檔決定,後者會列出套件的主要節點與其他可用的節點。將套件轉移到另一個節點,並不會轉移程式的計數器。在已轉移的套件中進行的作業會重新開始。應用程式如果要在失效後快速重新啟動,必須能夠容忍故障;也就是說,套件中的所有作業都必須要寫成能偵測到這種重新啟動。一般的系統故障時,也需要有這樣的應用程式設計,才能夠重新啟動。 在LAN介面失效的事件中,如果備用LAN介面存在,其會完成本機切換。如果心跳LAN介面失效,而且沒有配置備用或備援的心跳,則節點會發生TOC而失效。如果監視資料LAN介面因沒有備用而失效,只有當套件的NODE_ FAILFAST_ENABLED (若需詳細的資訊,請參閱「第 4 章「規劃與記錄OPS叢集」」下的「「 套件配置規劃」」)設定為「YES」,節點才會發生TOC而失效。 RAID磁碟陣列或獨立產品MirrorDisk/UX會提供磁碟保護。此外,另一個可用的EMS磁碟監視程式允許您在特定故障發生時通知操作人員,例如鎖定磁碟失效。若需相關的資訊,請參閱手冊《《Using High Availablity Monitors》》(HP手冊編號B5736-90025)。 ServiceGuard不會直接回應電源失效,不過,個別叢集元件的停電對 Service Guard 來說,有如該元件的失效,會造成適當的切換行為。HP支援的不斷電系統 (UPS) 可提供電源保護,例如HP PowerTrust。 在預設的情況下,套件或者其中一項服務的失效會使得套件利用stop參數執行控制命令集而關閉,然後在另一個可用的節點上重新啟動套件。如果套件管理員收到EMS監視事件報告,表示與配置資源的隸屬關係不相符,則此套件會失效,而且會試著在替代節點上啟動。 您也可以修改這項預設的行為,方法是指定節點應該在轉移發生之前故障 (TOC)。如果指定此行為,ServiceGuard將會嘗試在TOC之前重新啟動系統。如果有足夠的時間清理暫存區的資料,且能成功地重新啟動,就不會發生TOC。不論是那一種情況,系統都可以保證在預定的幾秒鐘內停下來。 萬一套件在關閉時懸滯,使節點處在不明的狀況下時,可使用Failfast選項來快速故障轉移,之後節點便會在重新啟動時被清理。不過,請記住,當節點故障時,節點上的所有套件都會突然中止。 配置套件時節點和服務failfast參數的設定,決定了套件與節點在失效時的行為。在「第 4 章「規劃與記錄OPS叢集」」的「「 套件配置規劃」」一節中,有關於如何選擇適當的故障轉移行為的詳細說明。 |
||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||