WSFC2016 跨站點運行情況檢測

以前在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爲最佳

參數	WSFC2012R2	WSFC2016	最大值
SameSubnetDelay	1秒	1秒	2秒
SameSubnetThreshold	5心跳	10個心跳	120心跳
CrossSubnetDelay	1秒	1秒	4秒
CrossSubnetThreshold	5心跳	20個心跳	120心跳
CrossSiteDelay	NA	1秒	4秒
CrossSiteThreshold	NA	20個心跳	120心跳

在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，那麼將會應用跨子網的運行情況檢測策略。