Share via


從作用中的故障轉移叢集成員資格移除節點時發生問題

本文介紹如何解決從作用中故障轉移叢集成員資格中隨機移除節點的問題。

徵狀

發生問題時,您會在系統事件記錄檔中看到類似此事件的事件:

事件 1135 範例的螢幕快照。

此事件會記錄在叢集中的所有節點上,但已移除的節點除外。 此事件的原因是叢集中的其中一個節點將該節點標示為關閉。 然後,它會通知事件的其他所有節點。 當節點收到通知時,它們會停止並中斷其與已關閉節點的活動訊號連線。

導致節點標示為關閉的原因

Windows 2008 或 2008 R2 故障轉移叢集中的所有節點都會透過設定為允許此網路上的叢集網路通訊的網路彼此通訊。 節點會跨這些網路將活動訊號封包傳送至所有其他節點。 這些封包應該由其他節點接收,然後傳回回應。 叢集中的每個節點都有自己要監視的活動訊號,以確保網路已啟動,而且其他節點已啟動。 下列範例應該有助於釐清此行為:

兩個節點彼此交談的圖表。

如果未傳回其中任何一個封包,則會將特定活動訊號視為失敗。 例如,W2K8-R2-NODE2 會傳送要求,並接收來自 W2K8-R2-NODE1 到活動訊號封包的回應,以便判斷網路和節點是否已啟動。 如果 W2K8-R2-NODE1 將要求傳送至 W2K8-R2-NODE2,而 W2K8-R2-NODE1 未取得回應,則會被視為遺失的活動訊號,且 W2K8-R2-NODE1 會持續追蹤。 這個遺漏的回應可能會讓 W2K8-R2-NODE1 將網路顯示為關閉,直到收到另一個活動訊號要求為止。

根據預設,在聯機標示為關閉之前,叢集節點在5秒內有5次失敗的限制。 因此,如果 W2K8-R2-NODE1 在這段期間內未收到回應五次,它會將 W2K8-R2-NODE2 的特定路由視為關閉。 如果其他路由仍被視為已啟動,W2K8-R2-NODE2 會保留為作用中成員。

如果 W2K8-R2-NODE2 的所有路由都標示為已關閉,則會從作用中的故障轉移叢集成員資格中移除,並記錄您在第一節中看到的事件 1135。 在 W2K8-R2-NODE2 上,叢集服務會終止並重新啟動,以便嘗試重新加入叢集。

如需如何處理與三個或多個節點中斷之特定路由的詳細資訊,請參閱 Jeff 按下程式撰寫的 「已分割的叢集網路」 部落格。

既然我們知道活動訊號程序的運作方式,程式失敗的一些已知原因為何

  1. 實際的網路硬體失敗。 如果封包在節點之間某處的網路上遺失,則活動訊號會失敗。 來自這兩個相關節點的網路追蹤將會顯示此資訊。

  2. 網路連線的配置檔可能會從網域跳回公用,然後再次跳回網域。 在這些變更的轉換期間,可能會封鎖網路 I/O。 您可以查看網路設定檔作業記錄,以查看情況是否如此。 您可以開啟 事件檢視器 並瀏覽至應用程式和服務記錄\Microsoft\Windows\NetworkProfile\Operational 來找到此記錄。 在事件標識碼 1135 中提及的節點上查看此記錄中的事件,並查看配置檔目前是否正在變更。 如果是, 請參閱 Windows 7 或 Windows Server 2008 R2 中的網路位置配置檔從「網域」變更為「公用」

  3. 您已在伺服器上啟用 IPv6,但在 Windows 防火牆中針對輸入和輸出停用下列兩個規則:

    • 核心網路 - 芳鄰探索公告
    • 核心網路 - 芳鄰探索請求
  4. 防病毒軟體也可能會干擾此程式。 如果您懷疑這一點,請停用或卸載軟體來進行測試。 請自行承擔風險,因為此時您未受到病毒的保護。

  5. 網路上的延遲也可能導致這種情況發生。 這些封包可能不會在節點之間遺失,但是在逾時期間到期之前,它們可能無法以夠快的速度到達節點。

  6. IPv6 是故障轉移叢集將用於其活動訊號的預設通訊協定。 活動訊號本身是透過埠 3343 通訊的 UDP 單播網路封包。 如果有未正確設定參數、防火牆或路由器以允許此流量通過,您可能會遇到這類問題。

  7. IPsec 安全策略重新整理也可能導致此問題。 特定問題是,在IPSec組策略更新期間,所有IPsec安全性關聯 (SA) 會由具有進階安全性 (WFAS) 的 Windows 防火牆拆解。 發生這種情況時,會封鎖所有網路連線。 如果在使用 Active Directory 執行驗證時發生延遲,重新交涉安全性關聯時,這些延遲 (會封鎖所有網路通訊) 也會封鎖叢集活動訊號通過,並導致叢集健康情況監視偵測到節點在 5 秒閾值內未回應時關閉。

  8. 舊的或過期的網路卡驅動程式和/或韌體。 有時候,網路卡或交換器的簡單設定錯誤也可能導致活動訊號遺失。

  9. 新式網路卡和虛擬網路卡可能會發生封包遺失。 開啟 效能監視器 並新增計數器「網路介面\已捨棄的封包」,即可追蹤此狀況。此計數器是累積的,而且只會在伺服器重新啟動之前增加。 在這裡看到大量封包被捨棄,可能是網路卡上的接收緩衝區設定太低,或伺服器執行速度緩慢且無法處理輸入流量的徵兆。 每個網路卡製造商會選擇是否要在網路卡的屬性中公開這些設定,因此您需要參閱製造商的網站,以瞭解如何增加這些值,並應使用建議的值。 如果您是在 VMware 上執行,下列部落格會更詳細地討論此問題,包括如何判斷這是否為問題,以及指向有關要變更之設定的 VMware 文章。

    從 VMware ESX 上的故障轉移叢集成員資格移除的節點

這些是記錄這些事件的最常見原因,但也可能有其他原因。 此部落格的重點是讓您深入了解程式,並提供要尋找之項目的構想。 有些會將下列值提升為其最大值,以嘗試停止此問題。

參數 預設 Range
SameSubnetDelay 1000 毫秒 250-2000 毫秒
CrossSubnetDelay 1000 毫秒 250-4000 毫秒
SameSubnetThreshold 5 3-10
CrossSubnetThreshold 5 3-10

將這些值增加到其最大值可能會使事件和節點移除消失,只會遮罩問題。 它無法修正任何問題。 最佳做法是找出活動訊號失敗的根本原因,並加以修正。 增加這些值的唯一實際需求是在節點位於不同位置且無法克服網路等待時間的多月臺案例中。