WSFC2016 VM彈性與存儲容錯

  很高興今天給你們介紹微軟2016羣集的VM彈性和存儲容錯技術，在老王看來，WSFC 2016裏面針對於羣集運做，VM彈性是一項很重要的改變，和滾動升級同樣，是一種顛覆式的思惟。

  簡單來講，在你們的認知裏，羣集就是應該當檢測到節點不可用以後，快速進行failover，把應用繼續轉移到其它節點上運行，對吧，相信你們都認同這一點。

  2012R2裏面默認相同子網和跨子網都是每隔一秒全網檢測一次，五次檢測失效，即斷定該節點不可用，RCM開始根據羣集數據庫內容，故障轉移角色到其它節點運做，檢測時間和檢測失敗次數操做，能夠改，若是您的環境存在網絡不穩定的狀況，嚴格的監測會致使節點頻繁故障轉移，您也改爲鬆散一些的1秒檢測一次，20次檢測失敗，再執行故障轉移

  可是這個閥值不易修改過久，緣由，一個是由於這個值是針對整個羣集級別，若是羣集上面有不少應用則全部應用都將受到這個影響，其二是若是檢測次數時間過長，會致使宕機時間好久才被發現，所以2012R2及以前，微軟建議，最長設置爲20次檢測失敗就故障轉移，不建議超過這個數值

  但歸根到底，咱們修改監測閥值，仍是爲了解決網絡不穩定的問題，以及用戶特定的需求，例如，若是客戶網絡不穩定，檢測會存在瞬時中斷，並且也沒辦法更改，那麼就能夠把監測閥值設置寬鬆一些，若是客戶環境網絡很穩定，須要很嚴格的檢測來保證SLA，也能夠把檢測閥值設置嚴格一些。

  這是2012R2時代的解決方案，到了2016，微軟認爲，真正的故障轉移狀況已經並很少見，反而是瞬時故障的狀況更常見，例如節點短暫沒法進行網絡通訊，或短暫沒法和存儲鏈接，以後又馬上恢復了，所以微軟從新設計了羣集中VM故障轉移策略，可以讓必定時間內的節點瞬時故障，沒必要再觸發節點虛擬機的故障轉移。

   在WSFC 2016中，VM彈×××默認被啓用，在2016 TP1中這項功能默認被禁用，隨後的版本都默認啓用，運行Get-Cluster |fl * 能夠看到和VM彈性相關的配置

參數說明

ResiliencyLevel : IsolateOnSpecialHeartbeat或1，AlwaysIsolate或2，默認爲AlwaysIsolate，即在發生節點瞬時中斷後，在一段時間內能夠容許虛擬機在線或暫停狀態，IsolateOnSpecialHeartbeat即當檢測到瞬時中斷後，馬上置節點爲失敗狀態，執行failover

以前咱們說過2016裏面重構了VM故障轉移策略

究竟是怎麼重構的呢

在WSFC 2016裏面，假設你發生了瞬時中斷，例如

1. 網絡短暫不穩定，節點沒法和其它節點通信

2. 羣集服務崩潰，沒法與其餘節點鏈接

3. 管理員誤操做
   

當發生例如這種瞬時中斷，羣集如今新增了三個屬性

1. 隔離：針對於羣集節點，在規定時間內，羣集節點發生瞬時中斷後，狀態會被標記爲隔離，該成員不會再是合格的羣集成員，但上面託管的虛擬機，在必定時間內依然能夠正常運行

   
   

2. 未監視：針對於羣集管理器中看虛擬機狀態，若是當節點發生瞬時中斷，變成隔離狀態後，在羣集裏面看虛擬機，虛擬機會是未監視狀態

   若是虛擬機存儲在SMB3/SOFS路徑下，節點隔離狀態後虛擬機可使用Online狀態運行，由於SMB可獨立運行，若是虛擬機存儲在FC/FCoE/iSCSI/ShareSAS等塊存儲構成的CSV路徑下，那麼虛擬機會被置爲暫停狀態，由於節點被隔離後，不是合格的羣集成員，也將失去CSV的訪問資格，若是節點恢復正常，虛擬機會從暫停狀態中恢復正常運行，若是節點的瞬時中斷一段時間內未恢復，虛擬機將會被failover到其它節點運做。

   3. 檢疫持續：咱們會設定一個時間，在這個時間內，節點若是發生瞬時中斷後又恢復了，虛擬機不會被遷移，只是繼續運行，但若是節點在一小時內，被隔離達到必定次數，屢次發生瞬時中斷，則咱們斷定該節點當前不正常，該節點可能會致使應用不穩定，所以咱們會把該節點置爲檢疫狀態，置爲檢疫狀態的節點，在一段時間內該節點將處於檢疫狀態，上面全部的虛擬機會被實時遷移走，直到咱們分析判斷該節點恢復正常後，再從新加入羣集。

ResiliencyPeriod：配置節點在隔離狀態下運做的時間，默認爲240秒，即240秒內的瞬時中斷，能夠被接受，不須要發生故障轉移，若是超過240秒仍未恢復，則按照羣集檢測走，執行故障轉移操做。

#配置隔離狀態時間

（Get-Cluster）.ResiliencyDefaultPeriod = 60

#關閉隔離狀態功能

（Get-Cluster）.ResiliencyDefaultPeriod =0

#配置單個虛擬機級別隔離狀態時間(即未監視狀態時間)

（Get-ClusterGroup「stat」).ResiliencyPeriod =  60

QuarantineThreshold：節點進入檢疫狀態前的隔離次數，默認爲3，即節點一小時內被置爲3次隔離狀態後，則節點進入檢疫狀態，全部虛擬機會被實時遷移走

#配置進入檢疫狀態前的隔離次數

(Get-Cluster).QuarantineThreshold =<value>

QuarantineDuration：節點處在檢疫狀態下的時間，默認爲7200秒，在這段時間，節點將不承載應用，全部虛擬機被實時遷移走，管理員能夠排查頻繁致使瞬時終端的問題，若是修復好了後能夠手動讓節點提早恢復，或等到7200秒自動恢復。

#配置檢疫狀態時間

(Get-Cluster).QuarantineDuration = <value>

這項技術說太多可能會以爲枯燥，下面咱們實際來看一下案例

當前環境裏面四臺虛擬機，其中RODC運做在SOFS路徑，其它三臺虛擬機運做在經過ISCSI提供的CSV路徑下，我設置節點隔離狀態時間爲60秒，檢疫狀態時間爲600秒，這裏老王只是爲了測試快點看到結果，真實環境下建議根據實際時間評估，多長時間內能夠算做瞬時中斷，頻繁發生瞬時中斷我須要多長時間進行排查問題節點。

WSFC 2016中要實現VM彈性的功能要求

1. 羣集功能級別爲9

2. 虛擬機配置級別升級至少6x以上

在老王的實驗中，我將模擬一個羣集服務短暫崩潰的場景，模擬羣集服務強制中止後，觀察羣集的反應

當前羣集四臺虛擬機都承載在HV01

咱們經過強制中止節點上面的clussvc進程來模擬羣集服務崩潰

Stop-process -name clussvc -Force

能夠看到，羣集服務崩潰後，節點會被置爲隔離狀態 

全部虛擬機在羣集裏面看會是未被監視狀態，這只是個羣集管理器中看到的臨時狀態

但其實在Hyper-V能夠看到，實質上，存放在SOFS的RODC在60秒內會持續運行，運行在CSV上的其餘虛擬機，雖然顯示 正在運行-關鍵，這個中文顯示是錯的，英文上面顯示爲Paused-Critical，實質上它們是由於節點被隔離，失去到CSV的資格，而被置爲暫停狀態。

若是60秒內，節點又恢復正常了，瞬時中斷恢復，網絡恢復正常，服務再也不崩潰，管理員恢復了誤操做，則節點從新加入回到正常狀態，已被暫停的虛擬機會從新開始運行，本例中咱們強制終止clussvc進程後，稍後會自動啓動起來

若是60秒內，瞬時中斷，或是羣集服務崩潰，或是網絡臨時中斷，或是管理員誤操做，沒有獲得修復，則節點會被置爲Down狀態，全部被置爲未被監視狀態的虛擬機會被遷移到其它活着的節點上，遷移過程是快速遷移，針對暫停的虛擬機會置爲關機狀態再遷移走。

下面咱們模擬1小時內3次隔離的狀況發生，即同一節點三小時內發生瞬時中斷

能夠看到，在節點的地方查看發現已經從紅隔離變成了綠隔離，但其實這個綠色的已隔離和上面紅色的已隔離已經不是同一個意思，一個是Isolate，一個是Quarantine，進入綠隔離狀態其實應該是咱們說的檢疫狀態，即根據咱們定義的算法，羣集已經能夠判斷這個節點不正常了，它生病了，不該該再繼續承載虛擬機，所以上面全部的虛擬機都會被實時遷移至其它節點，並在QuarantineDuration時間內，節點都將處於檢疫狀態，這時候管理員能夠對節點進行錯誤診斷，確認頻繁發生瞬時中斷，是否意味着有真實的問題存在須要處理，

若是600秒時間到了，則羣集認爲您已經解決了該問題，自動解除檢疫狀態，放節點正常加入羣集，若是您不想等待這個時間，或者您在已經提早解決了頻繁瞬時中斷的問題，那麼您也能夠運行命令 Start-ClusterNode -CQ 執行ClearQuarantine操做，把節點手動恢復正常

相信經過以上實驗你們對於VM彈×××已經有了必定了解了

有了這項技術後，咱們可讓羣集保持之前的樣子，根據檢測信號完成快速的故障轉移，也能夠根據經過VM彈性技術，設置在必定瞬時中斷時間內，接受短暫的中斷又恢復，不須要馬上執行故障轉移，能夠分別把主機在瞬時中斷下作隔離處理，甚至進一步檢疫處理，相對來講更加正規一些，也比原來咱們調整檢測信號的方式來的效果更好，所以若是你們環境中有瞬時中斷的狀況，不妨瞭解使用下這項功能。

若是不想要VM彈×××，還想恢復之前基於信號檢測直接作故障轉移的運做方式

設置VM彈性值以下，則回到從前，須要注意，在2016TP2以後的版本，這項功能默認被啓用，所以當發生網絡中斷，服務崩潰若是發現應用沒快速故障轉移，不要驚慌，那麼是由於羣集自動開啓了VM彈×××，不想要它，直接這樣disable掉便可

關閉VM彈性後，再次強制中止clussvc進程，發現節點直接進入故障狀態，執行故障轉移

以上爲VM彈×××，能夠幫助咱們解決節點級別的網絡，系統，誤操做等瞬時故障，除了計算級別能夠有這種彈×××，2016還在虛擬機存儲中也添加了這項技術，主要針對於虛擬機訪問VHDX，在2012R2中，若是虛擬機突然訪問不到VHDX，虛擬機確定會崩潰沒法使用，當存儲再次可用，咱們可能也須要從新打開虛擬機。

在WSFC 2016中羣集虛擬機能夠和存儲實現更好的容錯功能，很是的神奇，咱們能夠設置一個容許中斷時間，在這段時間內，若是羣集虛擬機到存儲之間發生了瞬時故障，沒法訪問VHDX了，能夠把虛擬機置爲暫停關鍵狀態，虛擬機將被凍結，狀態獲得保存，全部虛擬機的IO也都會被凍結

當VHDX恢復訪問後，虛擬機從暫停狀態回到正常運行，狀態釋放，全部IO獲得正常運轉，經過這樣內置的存儲容錯功能，能夠幫助咱們在存儲短暫鏈接失效的時候提供一種很好的方案，當存儲再次可用時，虛擬機自動load io，對於用戶來講，停機時間獲得改善。

當前除了RODC虛擬機，其它虛擬機都是直接鏈接到的CSV，咱們直接在ISCSI上面禁用掉16羣集用的數據磁盤，這樣CSV也就是失敗，節點到存儲失敗，VHDX也不再可讀取

能夠看到虛擬機又被置爲正在運行-關鍵，但其實這個狀態應該是Paused-Critical

那麼這個凍結虛擬機IO的時間是有限的，默認是30分鐘，不能夠太長，不能夠是無限期的，在一段時間內，若是虛擬機仍然沒法鏈接到VHDX，則VM將會關閉，下次啓動將是冷啓動

30分鐘以內若是虛擬機恢復到存儲的鏈接，則繼續運做，虛擬機被置爲正在運行，繼續保留以前的工做狀態，全部操做和IO正常運轉，若是這個到存儲的故障很短，那麼對於用戶來講是感覺不到的，一旦存儲鏈接上後，虛擬機會很快恢復運轉，SOFS虛擬機最快，其次是CSV虛擬機，開掛的ShareVHDX虛擬機會直接執行實時遷移。

#配置虛擬機存儲容錯，HV級別配置虛擬機

開啓虛擬機容錯功能

Set-VM -AutomaticCriticalErrorAction  <None | Pause>

默認爲Pause，即存儲沒法鏈接時暫停，改爲None則回到之前狀態，若是要修改需關閉虛擬機！

配置虛擬機存儲沒法鏈接等待時間 默認30分鐘

Set-VM –AutomaticCriticalErrorActionTimeout <value in minutes>

針對於ShareVhdx虛擬機在Hyper-V 2016會每隔十分鐘輪詢一次，存儲是否可用，若是不可用則自動實時遷移到其它節點上。

VM存儲容錯功能，僅支持基於CSV的VHD，VHDX檢測，或sharevhdx，sofs

不支持爲羣集化的本地VHD VHDX

不支持使用直通磁盤，或USB存儲的虛擬機

以上，老王爲你們介紹了VM彈性和存儲容錯的功能，關注這項技術好久了，一直很想把這項技術介紹給國內的朋友，此次終於寫好了，但願可以爲看到的朋友帶來收穫，若是您的環境中存在節點，網絡，存儲的瞬時故障，如今您能夠經過2016中的VM彈性技術進行控制，尤爲是針對於存儲的神奇容錯功能。