從作用中故障轉移叢集成員資格移除節點時發生問題
本文介紹如何解決節點從作用中故障轉移叢集成員資格隨機移除的問題。
徵兆
發生問題時,您會看到類似此事件記錄在系統事件記錄檔中的事件:
此事件會記錄在叢集中的所有節點上,但已移除的節點除外。 此事件的原因是叢集中的其中一個節點標示為關閉。 然後它會通知事件的其他所有節點。 當節點收到通知時,它們會停止並卸除與已關閉節點的活動訊號連線。
導致節點標示為關閉的原因
Windows Server 故障轉移叢集中的所有節點會透過設定為允許此網路上叢集網路通訊的網路彼此通訊。 節點會將這些網路的活動訊號封包傳送給所有其他節點。 這些封包應該由其他節點接收,然後傳回回應。 叢集中的每個節點都有自己的活動訊號,它會監視以確保網路已啟動,而其他節點已啟動。 下列範例應該有助於釐清此行為:
如果未傳回其中任何一個封包,則會將特定活動訊號視為失敗。 例如,W2K8-R2-NODE2 會將要求傳送給 W2K8-R2-NODE1 的回應至活動訊號封包,以便判斷網路和節點已啟動。 如果 W2K8-R2-NODE1 將要求傳送至 W2K8-R2-NODE2 和 W2K8-R2-NODE1 未取得回應,則會將其視為遺失的活動訊號,而 W2K8-R2-NODE1 會追蹤它。 此遺漏的回應可能會讓 W2K8-R2-NODE1 將網路顯示為關閉,直到收到另一個活動訊號要求為止。
根據預設,叢集節點在聯機標示為關閉之前,在5秒內有五個失敗的限制。 因此,如果 W2K8-R2-NODE1 在時間週期內未收到五次回應,它會將特定路由視為 W2K8-R2-NODE2 關閉。 如果其他路由仍視為啟動,則 W2K8-R2-NODE2 會維持為作用中成員。
如果所有路由都標示為 W2K8-R2-NODE2,則會從作用中故障轉移叢集成員資格中移除,並記錄您在第一節中看到的事件 1135。 在 W2K8-R2-NODE2 上,叢集服務會終止,然後重新啟動,以便嘗試重新加入叢集。
如需如何處理具有三個或多個節點的特定路由的詳細資訊,請參閱 Jeff Hughes 所撰寫的「已分割」叢集網路 部落格。
既然我們知道活動訊號程序的運作方式,程式失敗的一些已知原因為何
實際的網路硬體失敗。 如果封包在節點之間某處的網路上遺失,則活動訊號會失敗。 涉及這兩個節點的網路追蹤將會顯示這一點。
您網路連線的配置檔可能會從 [網域] 跳到 [公用],然後再次跳回網域。 在這些變更轉換期間,可以封鎖網路 I/O。 您可以查看網路設定檔作業記錄檔,以查看此情況。 您可以開啟 事件檢視器 並流覽至 [應用程式和服務記錄]\Microsoft\Windows\NetworkProfile\Operational 來尋找此記錄檔。 查看事件標識碼 1135 中所提及節點上此記錄檔中的事件,並查看配置檔目前是否變更。 若是如此,請參閱 網路位置配置檔從 Windows 7 或 Windows Server 2008 R2 中的「網域」變更為「公用」。
您已在伺服器上啟用 IPv6,但已針對 Windows 防火牆中的輸入和輸出停用下列兩個規則:
- 核心網路 - 芳鄰探索公告
- 核心網路 - 芳鄰探索請求
防病毒軟體也可能干擾此程式。 如果您懷疑這一點,請停用或卸載軟體來進行測試。 基於您自己的風險執行此動作,因為您目前不受病毒保護。
網路上的延遲也可能導致這種情況發生。 這些封包可能不會在節點之間遺失,但在逾時期間到期之前,它們可能無法快速到達節點。
IPv6 是故障轉移叢集將用於其活動訊號的預設通訊協定。 活動訊號本身是UDP單播網路封包,可透過埠3343進行通訊。 如果有未正確設定的交換器、防火牆或路由器允許此流量通過,您可能會遇到如下的問題。
IPsec 安全策略重新整理也可能造成此問題。 具體問題是,在IPSec組策略更新期間,所有IPsec安全性關聯 (CA) 都會被具有進階安全性的 Windows 防火牆所破壞。 發生此情況時,會封鎖所有網路連線。 如果 Active Directory 執行驗證時發生延遲,重新談判安全性關聯時,這些延遲(封鎖所有網路通訊的位置)也會阻止叢集活動訊號通過,並導致叢集健康情況監視在 5 秒閾值內未回應時偵測節點關閉。
舊版或過期的網路卡驅動程式和/或韌體。 有時,網路卡或交換器的簡單設定錯誤也可能會導致活動訊號遺失。
新式網卡和虛擬網路卡可能會遇到封包遺失。 開啟 效能監視器 並新增計數器「網路介面\封包已捨棄」,即可追蹤此動作。此計數器是累積的,而且只會增加,直到伺服器重新啟動為止。 在此看到大量捨棄的封包可能是網路卡上的接收緩衝區設定太低或伺服器執行緩慢且無法處理輸入流量的標誌。 每個網路卡製造商都會選擇是否要在網路卡的屬性中公開這些設定,因此您必須參考製造商的網站,以瞭解如何增加這些值,以及應該使用建議的值。 如果您是在 VMware 上執行,下列部落格會更詳細地討論此問題,包括如何判斷此問題,以及將您指向 VMware 關於要變更之設定的文章。
這些是記錄這些事件最常見的原因,但也可能有其他原因。 此部落格的觀點是讓您深入瞭解此程序,同時也提供要尋找的內容。 有些人會將下列值提高到其最大值,以嘗試讓此問題停止。
參數 | 預設 | 範圍 |
---|---|---|
SameSubnetDelay | 1000 毫秒 | 250-2000 毫秒 |
CrossSubnetDelay | 1000 毫秒 | 250-4000 毫秒 |
SameSubnetThreshold | 5 | 3-10 |
CrossSubnetThreshold | 5 | 3-10 |
將這些值增加至最大值可能會讓事件和節點移除消失,只會遮蔽問題。 它不會修正任何專案。 最好的作法是找出活動訊號失敗的根本原因,並加以修正。 增加這些值的唯一實際需求是在多月臺案例中,節點位於不同位置和網路等待時間無法克服。