之前在WSFC基礎知識奠基篇曾經為大家介紹過微軟WSFC故障轉移的過程，我們來重溫一下

1.按照要求部署配置群集節點，確保群集服務器利用了冗余技術消除了服務器，網絡，存儲的單一故障點

2.保證群集內所有節點都可以訪問到共享存儲

3.群集應用將應用數據寫入到群集共享存儲

4.管理員新增節點1服務器上面功能角色，新增完成後節點1服務器群集數據庫記錄新增的角色功能以及相關聯的信息，稍後會把信息同步至其它節點2，及群集仲裁磁盤

5.群集節點之間按照預定的心跳檢測頻率進行全網握手檢測

6.節點1出現故障服務器忽然關機，這時節點2心跳檢測頻率達到閾值，判定節點1已經離線

7.節點2判定節點1已經離線後，會根據已經同步的群集數據庫信息，查看節點1服務器當前承載的群集應用，重新將群集應用與關聯IP地址，群集磁盤在節點2進行上線

8.客戶端正常訪問群集名稱，使用群集服務，但原有節點1的群集應用，現已由節點2提供，故障轉移結束

本篇我們將主要關註與群集故障轉移的發生，大家可以看到從第五步開始，群集開始進行運行狀況檢測，隨後以運行狀況檢查結果，來決定群集節點是否應執行故障轉移

這在任何一個高可用群集裏面都是必須的，只要群集是高可用性質，那麽一定會有一種節點運行狀況檢測的機制，這種機制可以是ping檢測，握手檢測，API探測檢測，總之我們需要一種機制來準確確保節點的健康與否

針對於節點的運行狀況檢測機制是否準確，是一個群集的核心，真正可以被使用的群集運行狀況檢測機制，應該是準確可以反應節點健康與否狀態的，同時可以根據實際情況靈活更改健康監測的閾值。

節點的運行狀況檢測是故障轉移裏面執行節點故障轉移的依據，針對於節點的運行狀況檢測如果達到了一定閾值，群集就會判定該節點故障，隨之會導致節點上面所有承載的群集資源進行failover操作，而failover操作有時又會產生停機時間，因此，群集節點運行狀況的檢測頻率，和決定要進行故障檢測的閾值，一定是要進行環境評估的。

群集中健康檢測分為兩大類，一類是節點檢測，一類是資源檢測，節點的檢測更為簡單，不需要置備很多重試邏輯，只要我群集規定的運行狀況檢測方式，你在規定時間，規定次數裏面沒有讓群集檢測到，群集就認為你是出現故障的，無法再提供服務，需要對你進行所有應用的failover

而資源檢測相對於節點檢測，則更為復雜一些，可以把節點檢測理解為外層的檢測，針對於一個節點level的檢測，如果節點檢測失敗，則節點上所有資源failover，資源檢測則更關註資源級別的運行狀況，正如老王在日誌排錯進階篇講解到的，群集裏面每個資源都會有自己的resource.dll，群集正常運作過程中，RHS會按照每個資源的resource.dll定義對資源進行lookalive和isalive的檢測，針對於每個資源的lookalive和isalive檢測方式都會不同，lookalive只是粗略檢測，isalive則更為深入，isalive檢測的結果會報告給RCM，RCM會再根據資源的故障策略，進行失敗重試，在機器上嘗試多次啟動資源，或把資源轉移到其他節點運行。

總結來說，節點的運行狀況檢測結果，決定了節點上面所有應用是否要被故障轉移，資源的運行狀況檢測結果，決定了單個資源是否要被按照故障策略進行操作。資源檢測更為復雜，要根據resource dll定義的檢測方法，考慮多種情況，來進行lookalive和isalive的檢測。管理員針對一些資源也可以收到設置故障策略，例如不嘗試重啟，直接出現失敗就轉移到其他節點，或重啟資源嘗試三次失敗，再轉移到其他節點。

在過去單個資源的RHS檢測失敗，可能還會影響到其它群集資源，2008之後，大多數程序都已經被隔離到單獨的RHS進程中進行檢測，因此很少會出現單個資源檢測影響到其它資源的場景。

節點運行狀況檢測結果影響面更大，資源運行狀況檢測影響面只是單個資源。大家只需要這樣記住就可以了

介紹了一些基本的理論之後，我們再來專註於節點的運行狀況檢測

在WSFC 2012時代開始，微軟針對於節點的運行狀況發生了改變，不再簡單的執行一個ping操作，而是會執行一個真正的握手

例如，當前群集裏面有2個節點，默認情況下他們每間隔一秒做一次全網檢測，每個節點與節點之前都會進行檢測，如果這次握手檢測為節點1發起，實際上它會執行一個握手，通過UDP 3343端口發送134byte的檢測信號，詢問節點2你在嗎，節點回復，我在，那麽你呢，你在嗎，節點1回復我也在。到這裏一個檢測結束，WSFC的節點運行狀況檢測，是每隔一秒，會在所有節點之間都執行這種運行狀況檢測，確保沒有節點會被遺漏，節點運行狀況檢測主要是通過UDP 3343端口

那麽進行這個UDP 3343端口的檢測，是在群集裏面那塊網卡進行呢，答案是所有已被勾選用於群集通信的網絡，在WSFC 2008時代之後，群集只有三種網絡類型，分別是

0 無群集通信

1 啟用客戶端和群集通信

3 僅用作群集通信

默認情況下，在我們創建群集，或添加群集時，群集內部會有一個網絡拓撲生成器來幫我們自動去啟發網卡的群集網絡類型，生成群集內網絡通信拓撲。

例如

如果檢測到網卡上面跑了ISCSI Initiator，那麽自動啟發它為類型0無群集通信，確保存儲網絡只用來交換存儲數據

如果檢測到網卡上面配置了網關，那麽拓撲生成器會以為你這塊卡是要與外面客戶端通信提供服務的，因此會自動把設置了網關的網卡設置為群集網絡類型3

如果檢測到網卡上面沒有設置網關，那麽拓撲生成器會以為你這塊卡只是要做內部群集通信的，不需要對外提供服務，會被設置為群集群集網絡類型1

需要註意，群集裏面群集通信這種流量下面會做三件事

1.執行群集內所有節點的運行狀況全網檢測

2.執行群集數據庫的更新同步

3.執行群集CSV元數據的同步

這三種操作都對網絡質量的要求極高，尤其是CSV元數據和群集數據庫，如果因為網絡質量不好，頻繁丟包，會導致群集數據庫更新慢，可能會體現為操作執行下去很久返回結果，或CSV操作寫入數據效率低下

因此建議對於群集網絡類型3的群集網卡，規劃好網絡質量，確保不會出現丟包現象，默認情況下針對於這三種流量會由群集網絡類型3的網卡來做，如果一旦群集網絡類型3的網卡失敗，那麽群集會通過網絡拓撲生成器重新規劃流量群集通信流量由網絡類型1執行，但一定不會讓網絡類型0執行。

群集網絡類型3的網卡我們通常需要額外配置一些東西，例如不要設置網卡DNS 服務器、WINS 服務器或默認網關，取消群集類型3網卡DNS註冊，禁用Netbios，調整網卡順序，讓群集類型1網卡最前，確保群集類型3網卡在後面，這些設置大都是為了確保故障轉移後，應用聯機DNS可以直接快速使用群集類型1進行註冊，確保出站網絡連接時始終是網絡類型1優先級最高，確保訪問AD進行身份驗證時對外網卡優先級最高，在WSFC 2012之後對於網卡順序開始變得不再重要，WSFC 2016時代已經取消了網卡訪問順序設置，因此大部分場景只需要去掉群集類型3網卡的DNS和Netbios註冊即可

如果WSFC 2016群集是依賴於AD的群集，例如基於域驗證的SQL Server群集，您擔心不設計網卡順序，當進行AD域驗證時萬一挑選由群集類型3網卡進行，會因為網卡聯系不到AD而超時，影響依賴於AD的群集應用程序性能，那麽您可以選擇通過Powwershell命令修改網卡接口度量值，以達到以前控制網卡順序優先級的目的

配置命令如下，度量值越低優先級越高

Set-NetIPInterface -InterfaceAlias“LAN”-InterfaceMetric 1

Set-NetIPInterface -InterfaceAlias“CLUS”-InterfaceMetric 2

Set-NetIPInterface -InterfaceAlias“ISCSI”-InterfaceMetric 3

如果群集應用不依賴於AD，或群集部署為工作組模型，那麽完全沒必要進行設置。

針對於我們本文提到的節點運行狀況檢測，會由NetFT這個組件進行構建檢測拓撲，NetFT通常指的是Failover Cluster Virtual Adapter，當我們安裝群集之後，在設備管理器裏面顯示隱藏設備可以看到有這樣一個虛擬網絡適配器，用ipconfig /all也可以看到這塊網卡，但是並沒有配置IP地址，這個群集虛擬網絡適配器的主要作用是幫助我們構建一個群集中網絡通信的高可用拓撲，例如，我們群集節點與節點之間要進行心跳檢測，每隔一段時間，NetFT就會去幫我們重新構建這個拓撲，例如節點1和節點2，分別有兩塊網卡，一塊專用於群集網絡，一塊用於群集網絡+管理網絡，那麽當NetFT檢測到如果專用的群集網絡不能執行心跳檢測，就會動態切換至另外一塊網卡幫助我們進行心跳檢測，NetFT的功能主要就是幫助管理員自動構建群集先有的通信拓撲，在最大程度的幫我們確保群集網絡都可以正常的通信。

我們已經知道了節點運行狀況檢測是基於UDP 3343端口發起的實際握手檢測，但是每隔多少秒檢測一次，檢測的時間和閾值，是可以進行配置修改的。最終，我們是要結合實際場景來修改更為合適的閾值。

例如，如果場景的需求是要求應用必須達到高可用，節點和應用非常重要一定不能出現問題，沒有瞬時中斷的情況，網絡狀況非常好，那麽我們就可以設置節點檢測嚴格一些，例如每隔一秒檢測一次，五次檢測失敗，就標記節點為故障狀態，故障轉移上面所有的資源應用。

如果場景就是避免不了瞬時中斷的情況，例如客戶的網卡就是不太穩定 會忽然斷掉又馬上好了，系統很慢，檢測信號maybe不會那麽快響應，這時候您也可以把檢測閾值設置的寬松一些，例如針對這種瞬時中斷的場景，設置當20次檢測失敗時才觸發故障轉移操作

微軟的建議首先是檢測時間不要更改，始終保持每隔一秒進行一次全網心跳檢測，其次是檢測失敗次數不要改的過於寬松，最長建議設置為20次，如果設置的超過20次，設置次數過多，會導致應用宕機很久才會被發現，延遲宕機時間，上面所有應用都會受到影響，因此微軟建議寬松的閾值最高為20次。

其實更改這樣一個節點檢測的閾值很簡單，一條命令的事情，但更多的是我們要思考應用的運行狀況，來選擇最適合的閾值

如果說您的環境，對於應用的可用性要求的很嚴格，一旦節點出現問題，應用需要立刻被故障轉移到其它節點上，且您的環境中網絡質量很高，不會出現丟包，瞬時中斷的情況，那麽您可以設置檢測閾值為5或10，這樣帶來的好處是應用始終在最可靠的節點運行，只要應用當前運作節點5次檢測lost，立刻failover到其它節點，但隨之帶來的問題是，一定要確保網絡環境無瞬時中斷，一旦出現瞬時中斷的情況，應用會頻繁的進行failover，因此設置檢測閾值嚴格的前提，一定是對於應用可用性要求嚴格，網絡環境足夠穩定。

如果說您的環境，網絡質量不高，確實會存在瞬時中斷，檢測信號有時不會及時響應，那麽您可以選擇設置檢測閾值寬松一些，最高建議設置到20次信號丟失，再進行故障轉移，這是個微軟的最佳實踐。設置檢測閾值寬松，帶來的好處是，確保節點正常情況下不會被故障轉移，容許20次信號檢測失敗，maybe是因為節點距離遠，或者有瞬時中斷的情況。帶來的壞處是，如果設置的閾值過於寬松，將會延遲宕機時間，例如，如果節點確實宕機了，但是卻在60次檢測後才觸發故障轉移，原本5次檢測後就該故障轉移的，因此這額外的55次檢測的過程就是額外的宕機時間。

對於設置節點檢測閾值寬松這件事情，一個層面是解決跨子網檢測的情況，例如北京2節點，廣州2節點，這樣一個四節點跨地域跨子網的群集，由於網絡鏈路過於復雜，5次檢測有時確實會因為網絡鏈路而導致檢測失敗，觸發故障轉移，因此您應該調整他們的檢測閾值，但最多不要超過20，另外一點，調整檢測閾值寬松，也是為了應對瞬時中斷的問題，如果網絡環境質量不高，不夠穩定，會出現無法避免的丟包，但又不想頻繁的故障轉移，那麽也可以調整檢測閾值為20。

針對於瞬時中斷的情況，WSFC 2016裏面已經有了新的技術，即VM彈性，默認情況下該功能被開啟，對於虛擬化群集來講，微軟默認認為環境會存在瞬時中斷的問題，因此對於虛擬機資源新增了兩個狀態，如果240秒內出現瞬時故障，則節點進入隔離狀態，虛擬機會處於無監視狀態，虛擬機仍然可以正常運行或暫停。如果1小時內節點三次被隔離，則群集認為節點存在問題，需要被徹底排查，因此會被置為檢疫狀態，實時遷移所有虛擬機到其它節點，到達7200秒時間之前，檢疫節點會被排查，不會正常加入群集。

WSFC 2016裏面的VM彈性技術，主要提出的是一種新的思路，微軟知道對於虛擬化群集瞬時中斷比較多，經常因為網絡質量而導致故障轉移，所以新增了隔離到檢疫到正常修復加入的流程。但是這項功能僅針對於VM資源有效，且默認的隔離時間過長，如果要使用這項功能，首先你需要了解它，老王在前面博客有詳細寫，然後需要調整這些閾值，240秒，3次隔離進檢疫，檢疫7200秒。如果不想要這項功能，也可以直接關閉。則群集又回到以前完全參照運行狀況檢測閾值設定進行故障轉移，需要註意，運行狀況檢測針對於節點生效，一旦運行狀況檢測閾值達到，所有節點資源將會被failover，而VM彈性功能，則隔離狀態下，只有虛擬機會被置為未監視狀態。因此大家可以根據實際場景選擇要是用的功能。

OK，涉及到的理論都講清楚了，接下來看操作命令就簡單多了

調整運行狀況檢測閾值涉及到的參數如下

Delay為檢測頻率，Threshold為我們說的檢測閾值

除了下表中列出的，在2012時代還有一種情況，即節點添加Hyper-V角色作為Hyper-V群集，那麽SameSubnetThreshold會被自動設置為10，CrossSubnetThreshold會被自動設置為20，猜想可能是因為微軟考慮Hyper-V上面虛擬機可能很多，5會導致頻繁故障轉移，故障轉移時間也較長，而且也考慮到瞬時中斷情況，因此虛擬化場景下，10和20為最佳

在WSFC 2016之前，當我們要調整節點運行狀況檢測閾值時只有相同子網和跨子網，這四個選項可以設置，CrossSite是新增的功能

這裏的Site是依據我們通過定義故障域，定義出來的站點為基準，因此跨站點心跳檢測可以被歸置到站點感知功能下

在WSFC 2016中，如果我們分別對這三種場景，同子網，跨子網，跨站點進行了設置，不同的場景下它們的生效優先級也不一樣

如果集群節點在同一個站點和相同的子網中，則相同子網的閾值生效

如果集群節點在同一個站點和兩個不同的子網中，則跨子網閾值生效

如果集群節點位於不同的站點和不同的子網中，則跨站點閾值將覆蓋跨子網閾值

如果集群節點位於不同的站點和相同的子網中，則跨站點閾值將覆蓋相同子網的閾值

這裏和之前最大的不同點，在於多了不同站點的概念，如果你定了節點在不同站點，那麽群集就會認為，他們之間離得很遠，需要被應用不同站點的檢測閾值，那怕它們在同一個子網

這很適合stretch vlan的場景，即有的群集節點雖然離得很遠，但是存在同一個子網下，因此你沒辦法控制，說其它節點對於這個遠程節點要進行比較寬松的信號檢測，因為都在一個子網，所以只會被應用SameSubnetThreshold，但這個節點上面也會承載應用，如果就是因為網絡鏈路過長，或瞬時中斷，導致信號檢測失準，發生故障轉移，那我們也沒辦法控制，最終只能要求更改子網，但在WSFC 2016，我們可以把該節點邏輯定義到另外一個Site，這樣，雖然還是同子網，但是一旦對於遠程節點進行運行狀況檢測，會應用上跨Site的寬松檢測策略

#獲取WSFC節點運行狀況檢測相關設置

Get-Cluster | fl *delay*

Get-Cluster | fl *threshold*

#調整同子網心跳檢測閾值為15

(Get-Cluster).SamSubnetThreshold = 15

#調整跨子網心跳檢測閾值為15

(Get-Cluster).CrossSubnetThreshold = 15

當前環境繼續延續上篇博客，HV01 HV02 屬於北京站點，HV03, HV04屬於上海站點

查看ClusterLog，可以看到由NETFT構建的運行狀況檢測拓撲

針對於同子網同站點，應用SamSubnetThteshold檢測策略

針對於不同子網跨站點，應用CrossSiteThteshold檢測策略

針對相同子網不同Site，應用CrossSiteThteshold檢測策略

#手動移動HV01至上海站點

再次查看發現從18.0.0.9 到 18.0.0.10 已經應用CrossSiteThteshold檢測標準！

針對不同子網，但其中一個節點退出Site，應用跨Site節點檢測策略

針對相同站點，但其中一個節點移動為跨子網，應用跨子網節點檢測策略

移動HV01回北京站點

修改HV01為上海子網IP

查看ClusterLog發現其它節點到HV01節點的運行狀況檢測已經應用CrossSubnetThreshold

一旦18.0.0.0網段無法通過心跳檢測，NetFT會重新路由其它網絡進行運行狀況檢測，這時一旦選擇了跨子網的網段，又在同一個Site，那麽將會應用跨子網的運行狀況檢測策略。

本文出自 “老王的微軟技術研究樂園” 博客，請務必保留此出處http://wzde2012.blog.51cto.com/6474289/1965135

WSFC2016 跨站點運行狀況檢測