WSFC日常管理操作

   在本篇文章中，老王將為大家介紹一些WSFC日常管理的功能，相對來說會輕松一些，其中有的功能可能您之前看到過，但是不知道什么意思，或者一直沒用過，老王希望通過這篇文章能夠讓更多的人知道WSFC原來還有這些管理功能，應該如何去操作使用。

   老王主要會圍繞著兩個層面來講，一個層面是WSFC的運行放置，一個層面是WSFC的維護更新

   說起WSFC的放置策略，首先想和大家聊聊所有者這個概念，在WSFC中，不論是我們做計劃內的維護，或是計劃外的故障轉移，群集總是要把維護故障節點上的資源遷移走，那么遷移到哪里去呢，這里首先要考慮的概念就是所有者，默認情況下，如果安裝好一個群集什么也不額外設置，那么當一個節點發生故障時候，它上面的資源是會被隨機的放在群集里面其它活著的節點上，因為對于該節點上面的群集資源來講，所有存活節點都是一樣的，我那個節點都可以去。

   到了2008R2時×××始，WSFC群集開始實行智能放置，即是說，如果沒有做任何群集應用的管理配置，默認情況下，當節點發生計劃內維護，或計劃外故障轉移時，群集會去評估看看那個節點上的群集資源少，群集會盡可能的幫我們把故障節點的資源轉移至群集資源負載少的節點上繼續運行。

   以2008R2為例，目前我們有三個節點，兩個群集應用，分別是devtestdtc和devtestdtc1，devtestdtc1當前在Node3運行，devtestdtc當前在Node1運行

直接斷電Node1，可以看到devtestdtc并沒有去Node3，而是去了沒有任何負載的Node2

    首先要給大家介紹的所有者概念是首選所有者，剛才和大家說過，默認情況下如果什么都不做，則對于群集應用來說，發生故障的時候，它轉移到那個節點運作都是一樣的，但是一旦我們設置了首選所有者，就相當于我們告訴了應用，當發生計劃內維護或計劃外遷移的時候，你應該首先去這個首選節點，你在這上面會運行的更好    

    打開群集應用屬性可以看到首選所有者設置，默認并沒有勾選，即對于群集應用所有節點都一樣

在本例中，我們將devtestdtc的首選所有者手動設置為Node3

當前devtestdtc首選所有者設置為Node3，Node3上面已有應用devtestdtc1運行

在這里我們選擇將devtestdtc移動至另一個節點，選擇最佳，最佳則意味著，讓群集去根據放置策略評估，幫我們選擇最適合的節點

默認情況下應該是根據智能放置，選擇沒有負載的Node2，但是由于我們手動設置了devtestdtc的首選所有者為Node3，因此devtestdtc會被放置在Node3

由此可以看出，首選所有者的執行會優于群集默認智能放置的執行，群集會感知到這里存在我們手動的指定，因此會以首選所有者為準。

另外一個重要的概念則是可能所有者，這兩個概念在2003時代就有了，可能所有者的概念即是說，對于一個群集應用來講，當你做計劃內維護，或計劃外故障轉移時，你有哪些節點可以轉移，默認情況下對于群集應用來說所有節點都可以去，但是我們可以通過手動編輯可能所有者列表，讓群集應用只可以被聯機上線到指定的節點，如果指定節點不在，則應用不要聯機運行。

在本實例中，我們使用四臺群集服務器，devtestdtc托管于node1，devtestdtc1托管于Node3

當前devtestdtc的首選所有者為Node3

直接斷電Node1，可看到按照我們預想的devtestdtc去了Node3，因此首選所有者設置無論是在計劃內維護或是計劃外故障轉移都會生效。

打開devtestdtc屬性，高級策略可以看到，當前所有群集節點都是可能所有者，因此，即使首選所有者Node3不可用，devtestdtc也可以去其它節點。

接下來我們看另外一個例子，當前devtestdtc和devtestdtc1都在Node1運行，devtestdtc的首選所有者設置為Node1，Node2，Node3，但是可能所有者只有Node1和Node2，devtestdtc1不做任何設置

devtestdtc首選所有者

devtestdtc可能所有者

devtestdtc1不做任何設置

這時直接斷電HV01和HV02，可以看到，devtestdtc1由于沒有做任何設置，因此會根據智能放置隨機放在Node3，devtestdtc只是被轉移到了節點，但是并沒有辦法聯機上線，因為沒有合格的可能所有者

  雖然我們設置了devtestdtc首選所有者為Node3，但是因為devtestdtc的可能所有者只有Node1和Node2，因此devtestdtc并不會在Node3首選所有者上線，可以看出，不論是群集默認的智能放置，或是首選所有者，但只要沒有合格的首選所有者，應用都將無法聯機上線，可能所有者的設置會蓋過首選所有者和智能放置來執行。

   至此，我們已經了解了首選所有者和可能所有者，老王認為這兩個概念看似很普通，但是掌握好了也各有個的用途，例如，如果你知道，你的群集應用在某些節點上面運行的很好，那么你就可以設置首選所有者，確保計劃內維護或計劃外故障時，只要看到這個首選節點活著，應用就優先去它上面運行。如果你知道群集里面有的節點硬件很老的，執行效率很低，那么你就可以設置一些關鍵群集應用的可能所有者，設置只在性能好的節點上面執行，永遠也不讓關鍵應用在老舊節點執行。

  除了首選所有者和可能所有者，在2008R2時代，群集還新增了一個資源屬性，保持模式，老王也叫它默認所有者

   那么什么是默認所有者呢，簡單來說，就是一旦你針對于群集資源勾選了這個屬性，那么群集就會去記住，這個資源在下一次冷啟動之前運行的是哪個節點，當發生故障轉移之后，再次冷啟動時，會讓應用回到故障轉移之前的節點上面運行，通過這個屬性，你可以控制一些對于節點有粘合性的應用，例如一些關鍵的VM，希望它們可以始終在這個節點上面運行，那么你可以啟動保持模式

    在2012時×××始這個功能在GUI界面被隱藏，可以通過powershell命令控制，2012時代針對于VM默認啟用該功能。

當前devtestdtc1并沒有設置首選所有者和可能所有者，只是勾選了啟用保持模式

Node3發生故障時，devtestdtc1被轉移到node1

當Node3恢復，這時重新啟動Node1的群集服務，模擬節點冷啟動

可以看到應用回到Node3運行，默認所有者設置生效

在實際使用中老王發現默認所有者有以下節點需要注意的地方

1.如果針對于啟用保持模式的應用，手動移動至其它節點，例如devtestdtc1當前運行在Node3，你手動把它移動至node1，當群集節點冷啟動后，devtestdtc1并不會再回到Node3運行，因為當你手動移動的時候，群集就又會重新記憶devtestdtc1的默認所有者為node1

2.默認所有者設置，并不會在節點恢復后立刻生效，需要在轉移后節點重新啟動群集服務，或重新開機后，才可以回到默認節點

3.如果資源設置了首選所有者，則首選所有者設置優于默認所有者執行，例如，devtestdtc1的首選所有者設置為Node1，那么當Node3發生故障后，devtestdtc1將一直在Node1運作，不會再回到Node3。

4.默認所有者可以看成是可能所有者中的最優節點，如果群集應用有指定首選所有者則優先考慮首選所有者，如果首選所有者不可用，則考慮默認所有者

5.不論是默認所有者設置或是首選所有者設置，都需要按照可能所有者的列表來執行，如果可能所有者列表發生變化，例如應用的默認所有者被剔除，則不會再回去默認所有者節點，而是按照可能所有者列表，選擇其它可用的節點放置

 在2008R2中，WSFC針對于資源放置還新增一個屬性，ClusterGroupWaitDelay，如果我們設置了首選所有者或使用了保持模式，則每次群集冷啟動時，群集會等待應用的首選所有者或保持節點上線，然后優先把應用放在首選所有者和保持節點，這樣可以一定程度上保證應用始終回到我們想要它在的節點上

 2008R2時代默認每個群集應用的ClusterGroupWaitDelay屬性為30秒，2012R2中是120秒，可以通過powershell命令自行設置，冷啟動后，如果在這段時間內，首選所有者或默認所有者還沒上線，則群集會選擇其它可能的所有者進行上線應用

 你也可以針對群集應用設置允許故障回復，這樣即便是ClusterGroupWaitDelay時間內，首選所有者和默認所有者沒有上線，應用在其它可能所有者上面運行了，但是當首選所有者或默認所有者恢復，也可以通過故障回復回到原來的節點上

  #手動修改ClusterGroupWaitDelay時間

（Get-Cluster devcluster）.ClusterGroupWaitDelay = 300

   總結一下，所有者概念是我們看群集放置的第一個概念，其中，首選所有者和默認所有者，都可以理解為增強×××，一旦我們設置之后，不論是計劃內維護或計劃外故障轉移時，群集都會嘗試幫我們把資源放在首選所有者上面，如果首選所有者不可用，則放置在默認所有者上面，如果沒有設置首選所有者，則默認所有者設置直接生效。

   如果最終經過等待，首選所有者和默認所有者節點都無法聯機，群集應用也會去嘗試使用其他可能所有者節點上線，并不會因為首選所有者和默認所有者不在，而導致應用沒辦法聯機，群集默認是希望所有應用都能夠持續的聯機可用，但是如果我們希望應用始終不要在指定的節點上面運行也可以通過手動修改可能所有者列表進行實現，可能所有者是強制×××，會蓋過首選所有者，默認所有者，智能放置來執行。

   說完所有者的概念之后，我們再來看看優先級，優先級對于群集放置來說也是個重要的概念，默認情況下，如果不設置優先級，那么當節點開關機的時候，或者故障轉移的時候，應用會隨機爭搶資源，因為大家都一樣，沒什么區別，我們都是要搶到資源，快速聯機上線，但是這時候，就有可能會發生一個啟動風暴的問題。

    例如，如果說，你的節點服務器資源有限，單個節點不能承載所有應用的聯機上線，那么當發生故障轉移的時候，如果只剩下這個節點，那么就很有可能會發生，很多重要的群集應用，沒有上線，而不那么重要的群集應用聯機上線了，把資源都給搶占沒了，導致重要應用計算資源不足，沒辦法上線。

    如果你設置了群集資源的優先級，則可以避免這個問題，優先級設置會在以下場景中生效

1. 群集節點關機開機時，優先聯機上線高優先級應用

2. 節點置為維護模式時，優先遷移處理高優先級應用

3. 節點故障轉移時，優先轉移高優先級應用

   優先級功能在2008R2時代被引入，在2008R2時代，我們僅可以設置資源是否要自動啟動，可以通過設置一些不重要資源，讓他們在冷啟動或故障轉移后，不要自動啟動，等待管理員手動把它們聯機，這樣初步可以確保重要的應用不會被不重要的應用搶占資源。

  到了2012時代，優先級功能得到完善，走向成熟，在2012時代，我們不僅可以設置資源是否自動啟動，還可以設置資源的優先級為高中低，這樣可以從一個更加細粒度的層面幫我們控制啟動風暴的問題

  例如，當節點重新開機，計劃內維護，或故障轉移時，會優先幫我們處理高優先級的資源，確保高優先級的資源會首先轉移聯機上線，然后再處理中優先級的，最終處理低優先級的，如果高優先級和中優先級把節點CPU和內存資源占滿，則低優先級應用不會上線與高中優先級應用搶占資源，設置為不自動啟動的資源，則在故障轉移后，需要管理員手動啟動上線，在2012虛擬化場景下，如果在高優先級虛擬機所在節點發生故障，故障轉移時，如果其它服務器上沒有可用內存，會搶占低優先級虛擬機的資源，釋放脫機低優先級虛擬機，而讓高優先級虛擬機上線。

 除了可以幫助我們很好的處理啟動風暴，轉移風暴的問題，通過優先級還可以幫我們解決一些依賴性場景，例如，當前群集跑了一套sharepoint環境，有AD域，sharepointdb，sharepointweb，在資源充足的情況下，我們可以設置AD域的優先級為高，數據庫的優先級為中，web的優先級為低，這樣當節點開機關機時，AD會首先聯機，其次是數據庫，最后Web再聯機，計劃內維護或故障轉移時，也會優先轉移AD，其次是DB，最后Web。

實驗驗證，當前群集一共有兩個節點，四個群集應用，優先級分別是高中低，不自動啟動，當前所有應用托管于HV01節點

HV01忽然宕機，可以看到，群集應用按照優先級順序，處理上線，針對于設置為不自動啟動的devtestdtc2，則并不會聯機上線，需管理員確認有足夠資源后，手動給予聯機上線。

優先處理高優先級Test1

處理中優先級devtestdtc

處理低優先級Test2

處理不自動啟動devtestdtc2

  任何一項技術都有它存在的意義，關鍵在于人們是否能深入挖掘到它的用途，老王認為優先級設置的意義就在于幫助處理啟動風暴的問題，或者幫助處理依賴性啟動的問題

  如果您的群集資源規劃的很好，節點資源很充足，單臺節點宕機，或只剩下最后一個節點時，節點可以支撐起所有應用，那么你可能并不需要優先級設置，除非您的環境涉及到依賴性啟動，那么您也可以利用優先級設置。

  如果您的服務器資源有限，或者的群集上面有很重要的應用，那么老王建議您可以使用優先級功能，逐步規劃資源的優先級，確保發生故障或冷啟動時重要的應用優先上線，優先級設置不論是針對群集角色或虛擬機都可以生效，雖然使用優先級設置，有時候會犧牲低優先級的可用性，來保證高優先級資源的可用，但是至少在資源不足的情況下，能夠保證關鍵應用優先在線，等到資源充足時，再重新規劃資源，確保所有應用都可以一直在線

  在放置策略中另外一個要考慮到的因素則是反相關性，什么是反相關性呢，簡單來說，默認情況下，如果我們使用首選所有者，默認所有者，可能所有者，智能放置等策略，都可能沒辦法避免一種情況，即兩個資源同時在一個節點上運行，一旦出現兩個資源都在一個節點運行的情況，那么當這個節點宕機，就需要整個應用的故障轉移，應用也會出現宕機時間

  例如，我們在WSFC群集中部署了AD域控制器，兩臺域控制器，DC1，DC2，假設現在兩個虛擬機都在同一個節點運作，這個節點忽然斷電，兩個虛擬機都需要故障轉移至其它節點，在故障轉移這段時間，用戶是沒辦法登錄到域控的

  反相關性則可以解決這個問題，我們可以設置兩個資源，具備同樣的反相關性屬性，這樣不論是手動移動至最佳節點，或是維護模式，故障轉移，只要其中一個資源看到另外一個資源上面有相同反相關性屬性的資源，就不會轉移過去，確保兩個相同反相關性的資源，始終不在同一個節點上面運行，這樣從一些程度來說會幫助減少應用的停機時間。

  在WSFC群集中，反相關性在2008R2時代可以通過自定義類實現，2012時×××始新增了powershell設置命令，更加簡單，把自定義類的過程封裝了起來，但是并不能在GUI界面配置，在SCVMM和Azure中，實現為GUI界面可用性集，也是為了增加應用的可用性而用。

實驗驗證

當前群集內共三個節點，兩個協同工作的DTC應用，分別運作在HV01和HV03

當前并沒有設置首選所有者，HV01直接宕機，devtestdtc會根據內存智能放置，而被放置在HV02

將devtestdtc重新移動回HV01，設置HV03為首選所有者

HV01再次宕機，可以看到資源并沒有按照內存智能放置策略放置在HV02，而是根據首選所有者策略放置在了HV03，首選所有者蓋過了默認的內存智能放置。

再次將devtestdtc移動回HV01，首選所有者依然設置為HV03

#設置devtestdtc和devtestdtc2相同反相關性屬性

(Get-ClusterGroup devtestdtc).AntiAffinityClassNames = "DTC"

(Get-ClusterGroup devtestdtc2).AntiAffinityClassNames = "DTC"

反相關性屬性可以針對于群集角色或群集虛擬機生效，同一個群集角色或群集虛擬機可以有多個反相關性屬性

再次宕機HV01，可以看到devtestdtc并沒有去首選所有者HV03，而是去了HV02，反相關性策略生效

查看clusterlog，可以看到當群集評估放置策略的時候，會看到Node 2 即 HV03上面具備自定義class類，即AntiAffinityClass屬性DTC，因此RCM取消放置在它上面，最終決定放置在Node4 即HV02

因此大家可以看出，反相關性在一些場景下會起到作用，例如如果你是一個虛擬化集群，里面你跑了兩臺AD，或兩臺DHCP，或兩臺DNS，兩臺SQL，等兩個節點協作完成的應用，你希望始終可以有一臺虛擬機能夠對外提供服務，那么就可以利用反相關性，設置兩臺虛擬機的相同反相關性，以確保在正常情況下兩臺虛擬機始終分散在不同節點上，防止單個節點故障帶來整個應用的故障轉移。

通過實踐老王總結出一些關于反相關性的理論

1. 反相關性設置優先于首選所有者執行，優先默認所有者執行，優于內存智能放置執行

2. 反相關性，首先所有者，默認所有者，智能放置，都需要可能所有者支持

3. 反相關性設置同樣是一項增強性設置，僅在群集有多于一個節點時起作用，如果群集只剩下最后一個節點，則兩個相同反相關性屬性的應用同樣會在這個節點上線，在只剩下最后一個節點的情況下，并不會因為反相關性而阻止兩個應用上線

對于反相關性我們還有很多話要說，等后面我們完成維護模式和故障回復的部分再回過頭來看它

在群集中我們可能會經常看到一個概念，即最佳節點，很多朋友可能會很好奇，到底什么是最佳節點，這個最佳到底是怎么評定出來的，事實上最佳，則是所謂最佳，就是群集幫我們選擇的最合適的節點，當我們點擊下去最佳的時候，事實上群集會去根據反相關性，首選所有者，可用所有者，智能放置策略來綜合考慮，最終決定出最合適的節點

最初始的情況，如果沒有做過任何額外的配置，在2008R2時代，點擊移動至最佳，群集會根據智能放置策略，幫助我們選擇其它活著節點上面，當前承載群集應用負載最少的節點

在2012時代，點擊移動至最佳，則不僅僅會考慮節點應用負載，也會考慮節點剩余內存，2012時代的智能放置，也叫做內存智能放置，會根據節點群集應用負載和內存負載，來盡可能的幫助我們選擇，當前剩余內存多，上面負載又少的節點作為最佳。

如果群集應用額外做了設置，則群集又會去重新評估最佳節點

1. 如果應用設置了首選所有者，則首先去到首選所有者為最佳

2. 如果應用設置了首選所有者和反相關性，則反相關性優先執行，繼續根據內存智能放置選擇其它節點為最佳

3. 如果應用設置了首選所有者，反相關性，可能所有者，若反相關性判定的節點沒有合格的可能所有者投票，則繼續根據內存智能放置選擇其它節點為最佳

在WSFC群集中，除了最佳節點會調用內存智能放置來判斷最佳節點，當計劃內維護，或計劃外故障轉移時，默認情況下群集也會優先根據內存智能放置來放置群集應用到合適的節點，如果檢測到了有首選所有者，反相關性，可能所有者等設置，則再一層一層的過濾，但是在默認情況下，群集的意識始終都是為了能夠讓應用不論是計劃內或計劃外都能始終盡快的上線，因此群集對于負載的平衡，2012時代中WSFC故障轉移默認情況下至多只能是根據上面的內存負載和群集應用負載來進行考慮。

如果在您的環境中有SCVMM，通過SCVMM管理群集，則SCVMM的動態優化功能可以和群集的內存智能放置相互配合，默認情況下群集節點故障轉移，根據內存智能放置策略快速把虛擬機轉移走進行上線，稍后SCVMM檢測到各節點負載發生變化，又會根據CPU，內存，硬盤IO，網絡等綜合指標，來重新動態平衡各節點的負載，實現更加深入準確的負載均衡控制

SCVMM在執行動態優化的時候如果感知到了群集的首選所有者，反相關性，可能所有者，仲裁等設置，也會遵守執行

WSFC群集更側重的是故障轉移后讓應用快速上線聯機使用，執行簡單的應用和內存負載調度，而SCVMM則更側重整個虛擬化集群環境的負載均衡，因此把WSFC群集和SCVMM相結合可以實現真正的虛擬化資源負載均衡。

在使用最佳節點這項功能時，有一點需要注意，之前我們點擊移動最佳節點，是點擊單個角色，選擇移動至最佳節點，如果這時應用了內存智能放置策略，會幫我們選擇內存和負載盡可能少的節點，但是如果我們一次選擇了多個角色，一起移動至最佳節點，則并不一定都會移動至同樣的節點，因為內存智能放置的處理，一次只能處理一個角色或一個虛擬機，可能對于這個虛擬機來說，它移動至HV01節點為最佳，因為HV01節點沒有負載，但是下一臺虛擬機要移動的時候又會重新評估，當前HV01和HV02節點都有一個群集資源，我應該是那個節點為最佳呢，這時候又會根據內存使用情況去選擇，如果最終內存使用情況也一致，則會再根據可能所有者列表選擇其它節點為最佳。

以上我們看了群集運行放置中設置到的一些概念，內存智能放置，首選所有者，保持模式，可能所有者，優先級，反相關性，可以說幾乎已經涵蓋了運行放置中絕大部分要考慮的點，下面我們再綜合看下在不同的放置場景下，這些概念的應用。

手動移動至指定節點

優先級失效，內存智能放置失效，首選所有者失效，反相關性失效，在手動移動至指定節點時，群集只會評估目標節點是否是可能所有者節點，如果在可能所有者列表內，節點資源充足，則可以移動

手動移動至最佳節點

優先級生效，群集會按照優先級設置進行處理，先移動處理高優先級應用，確保高優先級應用會首先被上線，優先級確認好了處理順序后，放置策略再根據處理順序，逐步評估每個應用的放置，群集默認會基于可能所有者列表進行內存智能放置評估，如果檢測到應用有首選所有者設置，則移動至首選所有者節點為最佳節點，忽略內存智能放置的決定。如果設置了反相關性，則反相關性優于首選所有者執行，忽略首選所有者決定，群集會再根據內存智能放置選擇其它節點為最佳。

群集整體冷啟動

優先級生效，群集節點會根據優先級順序，優先聯機上線高優先級的應用，如果僅剩下最后一個節點，則高優先級會被優先聯機上線，緊接著在處理中，低優先級應用，如果最終低優先級應用沒有計算資源可用，則不會上線。隨著節點逐步上線，當檢測到應用有設置首選所有者，且故障回復，則應用會故障回復到到首選所有者運行，但如果檢測到目標節點已有反相關性資源，則重新選擇其它節點。

在只剩下最后一個節點啟動的情況下，只要該節點是合格的可能所有者，那么即便它不是應用的首選所有者，即便會讓兩個相同反相關性的應用一起在它上面，應用也會聯機

群集節點故障轉移

優先級生效，群集會根據優先處理，優先處理高優先級的應用，將高優先級的應用進行優先轉移上線，其它優先級排隊等待，確認好了處理順序后，群集會再根據放置策略進行評估，首先根據可能所有者列表考慮內存智能放置策略，優先嘗試把高優先級應用放置在內存和應用負載少的節點上，如果感知到了應用有設置首選所有者，且首選所有者活著，則直接把應用放置到首選所有者節點，如果檢測到應用設置了反相關性，則反相關性設置會優于首選所有者，故障轉移時，在多于1個可能節點的情況下，并不會把相同反相關性的資源放在一起，而是會根據可能所有者列表和內存智能放置策略選擇，確保反相關性得到應用。

 通過以上場景，我們可以看出，優先級設置，被應用在群集處理放置策略之前，優先級設置幫助我們確定出應該處理的順序，然后放置策略會再根據內存智能放置，首選所有者，反相關性，去幫助我們選擇每個順序應用合適的節點，但是內存智能放置，首選所有者，反相關性都只是增強屬性，如果群集只剩下最后一個節點，則應用同樣會轉移到該節點上運行，而忽略遵守內存智能放置，首選所有者，反相關性，如果內存智能放置，首選所有者，反相關性選擇出的節點，并不是可能所有者列表，則重新選擇，最終放置節點一定要在可能所有者列表才可以放置。

 在群集中，除了手動移動，最佳節點，冷啟動，故障轉移，還有一種放置行為，即維護模式，也就是計劃內維護，什么是計劃內維護呢，計劃內維護就是我們知道將會發生維護行為，有節點將要宕機被維護，可能是更換硬件，或者處理性能問題，在這種我們知道會發生問題的場景下，我們就可以收到把節點上面的應用遷移走，等到都遷移完成后再進行關機更換配置維護

 而計劃外故障則是說，在我們沒有預料的情況下，節點忽然因為網絡或存儲等原因宕機，這時候節點上面的應用會被故障轉移走

 計劃內維護和計劃外故障轉移的區別就在于，計劃內維護我知道宕機將會發生，那么我們就可以通過最少停機時間的方式，把上面應用都盡可能平滑的遷移走。而計劃外故障轉移發生時，則會涉及到群集組的離線上線，群集磁盤的重新掛載上線，因此，通常情況下，計劃內維護的停機時間會很短

 在以前如果群集本身沒有計劃內維護的技術，我們需要自己做規劃，例如規劃周四晚上，我們要針對群集做計劃內維護，給節點上配置，那么到了周四晚上，我們就需要手動的移動節點上的資源，確保都移動走了之后，關機上配置，再開機，然后一臺一臺執行。

 在2008時代群集有暫停模式，我們可以通過點擊節點暫停，但是暫停的功能，只會告訴其它節點，我當前置為暫停模式，你們的資源不要遷移到我上面，但仍然需要管理員手動把暫停節點的資源移動走，這在群集更新的場景下特別有用，如果沒有暫停模式，我們對節點打補丁還需要擔心這時候其它資源可千萬不要過來，否則打補丁說不好就重啟，故障轉移又會有宕機時間，有了暫停模式就需要擔心啦，把節點置為暫停模式，手動漂移走上面的資源，就可以放心的對節點打補丁了，這時候其它任何資源在放置的時候都不會考慮到暫停節點

到了2012時代，群集則更加智能，2012WSFC實現了，當我們對節點進行暫停時，不僅可以阻止其它資源放置到當前節點，還可以根據放置策略，評估內存智能放置，首選所有者，反相關性，可能所有者，自動的幫助我們把暫停節點上面資源排水遷移走，同時最小化宕機時間，當我們針對節點進行暫停維護時，針對于虛擬機會執行無停機的實時遷移，針對于群集角色會采用群集組交換的方式，交換群集組所有者，可能會涉及到群集角色短暫的的脫機再聯機，計劃內維護時只有這部分會出現宕機時間。

實驗驗證

在本例中老王將為大家呈現一個綜合性的實驗，當前群集一共HV01，HV02，HV03三個節點工作，上面跑了五個應用，這五個應用的放置策略如下，稍后我會對HV02節點置為維護模式

Test1：首選所有者HV01，因此維護模式后會直接去HV01節點

Test2：首選所有者HV02，HV03，但是可能所有者只有HV01和HV02，因此維護模式后會試圖去HV03節點，但發現不是合格可能所有者，而會被移動至HV01

devtestdtc：首選所有者HV01，但因為和devtestdtc2相同反相關性DTC，因此會被移動至HV03

devtestdtc3：未設置首選所有者，因此會被根據內存智能放置策略放置在HV03，但剛放置并不會自動啟動

在節點的位置，點擊HV02，點擊暫停，排出角色，則會按照我們所說的根據放置策略放置節點，如果點擊不排出角色，則和2008時代一樣，只是宣告當前節點不接受資源的放置，但管理員可以手動移走

我們點擊排出角色，可以看到節點首先會被置為正在耗盡

按照放置策略都排出成功會顯示已暫停，如果某些角色未排出成功，也會給出提示。

可以看到，群集應用已經按照我們預想的情況被放置

優先處理高優先級Test1虛擬機

處理中優先級虛擬機Test2

處理中優先級角色devtestdtc

Test1虛擬機處理策略

打開cluster log，大家可以看到，對于群集的資源放置，我們已知的概念，內存智能放置，首選所有者，可能所有者，反相關性都被實現成了一個個的filter，當我們要對資源進行維護模式時，實際上HV02會先等待RCM-plcmt組件去根據filter逐條評估各節點放置策略，最終得出結論placement manager result，則RCM把得到的結果返回給HV02維護模式節點，維護模式節點根據RCM-plcmt得出的結論去放置節點

HV01根據RCM放置組件得出，Test1應該直接去首選所有者節點HV01

HV02會等待RCM返回放置結果，收到放置結果后，按照結果進行移動，放置Test1虛擬機至首選所有者HV01

Test2 放置策略

Test2首選所有者設置為HV02，HV03，因此HV02維護之后，它會首先嘗試實時遷移至HV03，但是在HV03上面可以看到，由于Test2虛擬機可能所有者只有Node1 即HV01，Node4即HV02，而不能被放置在Node2 即 HV03，因此HV03上面RCM放置組件重新判定Test2應該被移動至可能所有者HV01

HV02收到HV03傳回的RCM放置結果，重新決定把Test2虛擬機移動至HV01節點，而非首選所有者HV03

devtestdtc3放置策略

查看clusterlog可以看到，當HV02需要處理devtestdtc3時，首先詢問RCM放置組件，應該放置在哪里，經過filter篩選，最終決定devtestdtc3應該按照內存智能放置策略放置在Node2即HV03

HV02收到RCM放置結果，開始操作移動devtestdtc3角色至HV03節點

devtestdtc3會首先被置為不自動啟動離線狀態，但稍后如果資源充足仍會嘗試聯機。

devtestdtc放置策略

因為devtestdtc首選所有者為HV01，因此發生故障轉移時會優先轉移至HV01，但是HV01上面，RCM-plcmt根據filter評估，HV01上面有自定義class即反相關資源devtestdtc2，因此取消放置在HV01的決定，placement manager 最終決定應該放置在Node2即HV03

HV02 收到RCM返回結果，于是操作devtestdtc移動至HV03，在HV03上面可以看到收到HV02的移動請求，接受請求，并且完成執行devtestdtc角色遷移，最終devtestdtc運行于HV03。

當我們完成排除角色后，當前維護節點上面負載為空，且被置為暫停模式，其它節點資源再想移動至維護節點會發現沒辦法移動

這時候我們就可以針對維護節點該加配置加配置，該打補丁打補丁，不會影響到任何的群集應用

在微軟產品體系中，維護模式這個概念貫穿了很多產品，如果通過SCVMM管理了群集，那么可以在SCVMM中對節點進行維護模式操作，如果VMM檢測到當前節點屬于群集，會按照群集放置策略實時遷移虛擬機，如果VMM檢測到當前節點不屬于群集，則置為維護模式時會通過快速遷移的方式把虛擬機遷移到其它節點。VMM也可以和SCOM整合，整合之后，如果節點被VMM置為維護模式，則SCOM中也會聯動將節點置為維護模式，避免維護期間產生警報，SCOM中的維護模式主要是為了防止維護時警報產生，并不起到實際操作作用，SCCM中我們也可以針對于集合設置維護模式，這樣如果我們應用要求必須在指定時間安裝，處于維護模式的集合不會安裝可以得到延遲。如果SCOM,SCVMM,SCSM相結合，SCVMM置節點為維護模式，SCOM會聯動置為維護模式，SCSM如果配置針對SCOM警報產生事件，則不會針對于維護模式而產生事件。真正在維護模式中會把節點上面資源遷移走的只有SCVMM和WSFC群集

當我們維護完成該節點后，通常有這樣幾種選擇，如果你只是要維護這一個節點的話，當你維護它時，應用會漂移到其它節點繼續運行，節點維護完成后，你可以選擇恢復或不恢復，恢復則意味著把之前漂移出去的應用再漂移回來，不恢復則意味著不需要應用再回來維護節點，你們先在其它節點運作也可以。如果是針對于群集所有節點的維護，老王認為您可以選擇恢復角色，這樣子可以一臺一臺的執行維護，維護好了恢復角色，再維護下一臺，也可以確保應用還回到原來的節點運作。

在2012WSFC中，故障回復分為兩種，一種是維護模式里面的回復，一種是應用自帶的故障回復，兩者區別是，如果是維護模式里面的故障回復，不論你的應用是否設置了首選所有者，都會被回復到原來的節點上運作，除非檢測到應用當前就在首選所有者，則不會移動。如果是應用自帶的故障回復，則一定要看首選所有者，如果首選所有者未設定，則不會故障回復。

兩者的相同點在于，2012時代中，不論是故障回復，或維護模式回復，對于虛擬機都是采取實時遷移的方式回復，針對于群集角色則采取群集組離線上線移動的方式回復

點擊暫停節點 - 恢復 - 則可以看到回復或不回復的選項，如果點擊回復，則會把之前該節點運行的應用試圖遷移回來，除非檢測到應用已經在首選所有者運行，否則都會被移動回來

實際測試老王發現維護模式故障回復是單獨的回復機制，和單純的應用故障回復并不相同，也并不會自動勾選應用的故障回復選項，即便你的群集應用都沒有勾選故障回復的選項，維護模式也會幫你恢復的原來的節點上

說起故障回復，這里也許有的朋友沒有使用過，不僅僅是2012，在之前的群集中，我們如果點開一個虛擬機或一個群集角色，在屬性中都可以看到故障回復的選項，到底什么是故障回復呢，到底要不要故障回復，這在2008時代也是很值得思考的一個話題，那時候群集里面只有一種故障回復，就是當節點發生故障之后，上面應用會被遷移到其它節點，當節點恢復正常后，應用要不要回來

在2008時代，是否故障回復會涉及到應用宕機時間的問題，因為2008時代發生故障時，針對于虛擬機時采取快速遷移的方式，針對于角色也是直接整個群集組離線再上線，本身故障轉移的宕機時間就有點長，好不容易轉移過去之后已經可以正常提供服務了，你又要故障回復，在2008時代如果設置了應用故障回復，那么應用會再把應用和虛擬機通過快速遷移和群集組離線上線的方式遷移一次，又會有宕機時間，所以在2008時代，應用到底要不要故障回復，除非是粘合性應用，只在原來節點可以工作很好，否則一般我們都不選故障回復，即便選了故障回復，我們通常會進行另外一項設置，即設置故障間隔，選擇一個時間段，例如半夜1點到3點，沒有用戶訪問的時候再故障回復，而不是立即回復

在2012時×××始，故障回復的宕機考慮變得不再重要，因為在2012時×××始，針對于故障回復時，虛擬機是采用實時遷移的方式回到原來節點，傳統群集組的故障回復時間也得到了優化

在2012R2中，還新增了另外一個屬性，即DrainOnshutdown，2012R2中，如果我們是正常關機的節點，那么針對于上面的虛擬機會采取實時遷移的方式遷移走，再進行關機，在過去如果我們維護一個節點時，忘記了暫停模式，直接在上面更新操作，然后關機，虛擬機會采取快速遷移的方式遷移走，產生宕機時間，2012R2則幫我們設置了這樣一個保護傘，一旦我們忘記暫停模式，針對于虛擬機也會實時遷移走，除非忽然斷電來不及實時遷移，則依然會快速遷移，但還是建議大家維護時使用暫停模式，這真的是一項很不錯的功能。

實驗驗證故障回復

當前所有群集角色都在HV02節點運作，無反相關性設置，無首選所有者設置，但勾選所有應用允許故障回復，立即

直接斷電HV02節點，可以看到應用分散去了其它節點上運行

當HV02回復正常時，可以看到，并沒有按照我們預想的一樣，應用全部故障回復HV02節點，因為我們并沒有設置首選所有者，所以故障回復失效！

再次把應用都遷移回HV02，然后設置應用首選所有者都為HV02

HV02再次斷電，應用遷移至其它節點

HV02恢復，所有群集應用因為設置了首選所有者，所以故障回復生效，回到HV02節點。

以上老王介紹了群集中的放置策略，維護回復，在群集中放置，維護概念也需要配合仲裁來啟動，設想一下，仲裁主要是為了確保群集的可用，當節點發生變化，新增，宕機，分區時，是否影響群集仲裁模型，宕機節點數量是否影響了群集的正常工作，如果只剩下最后一個節點，仲裁失敗，我們又需要執行強制仲裁啟動起來讓群集可用，而我們將的放置，維護，都是在仲裁判定群集可用的情況下才有效果，因此，仲裁和放置是相輔相成的，沒有仲裁，群集沒辦法啟動，放置也就沒有意義，只有仲裁，但是沒有放置策略，群集管理也沒有意義。

最后還有一些小菜和大家分享，是老王通過實踐得出的一些，關于放置策略和維護的容易被忽略的點

不自動啟動到底自不自動啟動

老王實際驗證發現不自動啟動，只在一種場景下生效，即故障轉移后，不自動啟動應用，不會被啟動自動，必須要管理員手動啟動

在手動移動，維護模式，維護模式回復，故障回復的場景下，不自動啟動會等待高中低級別應用啟動完，如果節點還有剩余資源則會自動嘗試啟動聯機！

故障恢復到底回不回復

針對于維護模式排出角色，沒有設置首選所有者都會恢復到原節點，如果檢測到在首選所有者節點，則不會回復

針對于故障時應用故障回復，按照首選所有者故障回復，如果沒有設置首選所有者，不會回復原節點

維護模式不會自動設置應用故障回復屬性

反相關性到底反不反

不會反的情況：

維護模式

如果維護前兩個反相關性應用都在HV01，首選者設置為HV02，則反相關失效，兩個應用都會去HV02

如果維護前兩個反相關性應用都在HV01，未設置首選所有者，則根據內存放置策略隨機放置，兩個反相關性應用仍有幾率被放在同一節點

這里關鍵在于維護模式中，反相關應用需要有參照，如果目標節點上面已有反相關性應用，則不會遷移過去，如果目標節點都為空，則無法參照，反相關性失效。

維護模式故障回復

如果維護前兩個反相關性資源都在HV01，首選所有者設置為HV01，置為維護模式后由于內存智能放置仍有幾率被放置在一起，如果維護完成后選擇恢復角色，則兩個應用都會回復到HV01，反相關性失效，因為HV01，當前為空，維護模式恢復沒有找到參照

如果維護前兩個反相關性資源都在HV01，均未設置首選所有者，置為維護模式后由于內存智能放置隨機放置扔有幾率被放置在一起，維護完成后選擇恢復角色，兩個角色都會回復到HV01，反相關性生效，理由同上，維護模式故障回復沒有找到參照，即便沒設置首選所有者也一起回到原節點

故障轉移

如果故障前兩個反相關性資源都在HV01，首選所有者設置為HV02，HV02上面當前為空沒有參照，則發生故障時兩個應用都會轉移至HV02，反相關性失效。

如果故障前兩個反相關性資源都在HV01，未設置首選所有者，其它節點上面沒有可以參照的反相關性資源，群集會根據默認內存智能放置策略評估，兩個反相關性資源仍然有很大幾率被放置在同一節點

故障轉移后故障回復

如果兩個資源設置了相同反相關性，相同首選所有者，當故障轉移后，需要執行故障回復時，如果首選所有者節點為空，則失去參照，不考慮反相關性，反相關性資源都會回去首選所有者

只剩下最后一個節點時，反相關性失效

會反的情況：

反相關性參照生效

不論是手動移動至最佳節點，維護模式，維護模式回復，故障轉移，故障回復，只要檢測到目標節點上面有相同反相關性資源，則不會移動至該節點

神奇的跳動

在一些場景下會發生些神奇的事情，例如針對于相同反相關性設置了同樣的首先所有者HV02，當前它們都運行在HV01，HV02節點上面資源為空，沒有反相關性參照資源的情況下，不論我們執行維護模式，或故障轉移，它們都會去到首先所有者HV02。正常來說，不論是維護模式的回復，或是應用自帶的故障回復，如果檢測到應用當前運行在首選所有者節點，則不會移動回原節點。但是如果是相同反相關資源在首選所有者則不同，當HV01恢復正常加入群集時，或再有其它節點加入群集時，反相關性資源會嘗試分散至新節點，但按照正常邏輯來說，已經在首選所有者節點，不應該再有這種嘗試，因此老王管它叫做神奇的跳動。

到這里，本篇文章也就接近尾聲啦，不知道會不會有能夠堅持看到最后的朋友呢，本篇文章中，老王不僅為大家介紹了群集運行放置和維護管理的功能，我們還通過群集日志深入去探索放置執行的底層過程，老王相信，只要是熱愛群集技術的朋友看到最后都能夠有自己的收獲，我們學習技術不僅要學會用，更多時候我們應該去關注Why的層面，當我們執行移動至最佳節點，故障轉移，故障回復時，為什么會產生這樣的效果，為什么會放置在這節點，這個放置是否是我期望的，我可以通過那些功能控制，知道了解老王介紹的這些技術后，相信您腦袋中會有自己的答案，最終希望通過這篇文章可以讓更多朋友知道群集有這些管理功能，有這些思考的地方，也希望能夠讓對于放置功能已經有所了解朋友能夠更加加深一層印象！

彩蛋

當當當當~彩蛋到，嘿嘿，為了獎勵看到最后的朋友們，老王特地準備了小彩蛋，在文章開頭老王和大家說過，本篇文章主要會圍繞群集的運行放置和維護更新來講，其實放置的部分叫做放置策略似乎更合適一些，但是之所以老王叫做運行放置，是因為放置，只有發生在仲裁判定群集可用時才有意義，只有群集通過正常仲裁也好，強制仲裁也好，整個群集啟動起來了可以對外提供服務，才能到達放置這個步驟，因此老王取名運行放置就是希望大家能夠明白這個概念

這篇文章中我們涉及了放置策略，涉及了維護模式，故障回復，但是唯獨對于更新沒有過多的講解，既然開頭已經說了，怎么會不講呢，于是老王決定在彩蛋中和大家聊聊群集的更新。

如果說您的環境中當前是沒有群集的虛擬化環境，或者群集沒有使用暫停模式的情況下，在一個理想的情況下，更新流程應該是這樣進行的，首先，通過WSUS建立補丁策略，補丁這個東西，老王建議只打系統級別的關鍵更新，安全更新，定義更新，如果說是Hyper-V服務器，或SQL節點，則針對于應用補丁的下載應該謹慎。

應該建立一套接近生產環境的測試環境，WSUS檢測到補丁，首先在測試環境打，測試環境打完如果沒問題，再去生產環境打，總結就是WSUS只下載重要的更新，而不要什么補丁都下，最好可以建立測試環境，新補丁先在測試環境通過，再去生產環境打。

如果在2012環境下，流程應該是WSUS測試環境通過，審批到生產環境，節點收到補丁，但是不應該自動安裝，應該是通知安裝，但是可以推遲時間。如果沒有群集的虛擬化環境，可以手動把虛擬機實時遷移走，然后再針對于宿主機打補丁，重啟，如果有必要可以實現記錄下來節點的虛擬機，遷移走后，維護完成再遷移回來，一切都手動完成。但是在一個理想的環境下，所有虛擬化節點應該被類似于VMM這種VIM系統管理，當做一個整體的資源池來看待，虛擬機去哪個節點都沒關系，VIM系統會重新平衡負載。

如果是群集環境下，沒有使用群集暫停模式，過程和上面一樣，2012時代可以實時遷移把虛擬機資源移走，其它傳統群集角色則離線上線群集組，在群集環境中打補丁，存在一個問題，即放置策略帶來的隱患，例如，我們當前要對這個節點打補丁，我們只是手動把資源移動走了，但是這時候如果其它節點上面發生放置操作，也會考慮移動到我們打補丁的節點，這時候可能我們打完補丁需要重啟，移過來的群集應用又會故障轉移，導致產生宕機時間，因此，在2008時代，我們如果要對群集打補丁，或者關機上配置，資源都手動移動走后，把節點置為維護模式，這樣其它節點再執行放置策略的時候就不會考慮維護節點，可以放心的進行更新配置了，如有必要，可以記錄下節點維護遷移之前承載的角色和虛擬機，更新完成后再手動遷移回來。

大家可以看到，不論是在2008R2群集，還是沒有群集的環境，當我們要執行群集更新時，不可避免的要執行很多手動操作，手動把資源都移動走，置為暫停節點，甚至可能還要手動記錄下節點之前承載的角色，維護完了再遷移回來，每次要更新對于管理員來也是個不小的麻煩事

在2012時代這些都發生了改變，首先是2012里面的維護模式變了，變得超級智能，置為維護模式，可以自動把資源按照放置策略移走，維護完成后，還可以選擇故障回復，再把所有角色漂移回來，既不用手動移動，也不用手動記下來維護節點承載應用了，只要維護時點擊維護，維護好了點擊恢復就可以了，就這么簡單，點擊維護后，節點都清空，宣告我是暫停節點，不要遷移到我了，管理員就可以手動應用WSUS測試后審批下來的補丁，更新完成后重啟開機，點擊恢復，則就會把之前角色再遷移回來，然后再執行下個節點，這里我們要做的，就是手動選擇更新，安裝有用的更新

最終形態，在2012時代中，群集還新增了一項專門用于群集節點更新的功能，叫做CAU，Cluster Aware Updating，群集感知更新，用一句話來概括它的話老王會說：在保持群集應用持續可用性的情況下，對群集進行補丁更新管理的工具，將08 03時代群集更新的重復性手動工作采用了自動化的方式。

簡單來講，CAU就是一種可以配合維護模式來完成更新的一種群集更新協調工具，大家可以這樣以為它，CAU本身并不下載補丁，它的補丁可以可以來自于直接和microsoft同步，WSUS，或SCCM，CAU做的只是協調，和標準化，確保群集更新按照我的協調來完成，完成后我要輸出標準的報告。

協調，就是當我們觸發CAU維護操作，CAU收到WSUS補丁就會開始按照排水邏輯更新，針對于虛擬機資源都按照放置策略實時遷移走，資源都遷移走后更新補丁，重啟檢測，是否有依賴補丁未安裝，確認沒有安裝完成，自動執行恢復操作，再把節點之前的負載遷移回來。

可以看到，CAU直接幫我們自動做了三件事 ，自動置為維護模式 - 安裝補丁 - 自動故障恢復，之前我們需要手動點一下維護，手動點一下安裝補丁，手動點一下故障回復，現在這三下你也不用點了，CAU直接全幫你做了，你要做的就是點一下，開始CAU更新就好了。

CAU的工作模式有兩種，一種是老王說的這種，點一下，還是由我們去選擇在一個合適的時間節點觸發群集進行CAU更新流程， 每次手動觸發更新的時候，CAU會隨機選擇一個節點做協調器，這時候CAU Update Coordinator會暫時駐留在一個節點上，之后群集節點都會按照CAU的指示一臺一臺的完成更新，維護模式，然后自動恢復。這里手動觸發模式關鍵的點在于，可以由管理員選擇一個合適的時間節點更新，可以由管理員仔細核對補丁后再確認觸發更新。

另外一種則是采取完全自動化的更新方式，CAU會在群集里面長出來一個VCO角色，由這個VCO角色擔任CAU更新協調器的功能，完全自動化的更新方式，你只需要指定一個時間段，剩下的就什么也不需要管了，每次到了那個時間段，CAU就會自動按照排水邏輯去進行更新。

不論是手動觸發更新，或是完全自動化更新，都會在完成群集整體更新后生成一份報告，會詳細列出執行CAU更新時，是否全部按照CAU的協調流程執行，期望的補丁是否都已經安裝，安裝過程有那些異常，都會看到，老王認為這個就是CAU的意義所在，可以配合維護模式協調實現持續可用的群集更新，完成更新后也可以輸入標準化的報告，既解放管理員雙手，也標準化工作，關于CAU老王這里只把涉及到的主要理論進行介紹，我的好朋友ZJUNSEN張俊森，寫了CAU實際操作方面很不錯的博客，大家感興趣可以去看。

在微軟的更新體系中，可以偵測到當前架構中存在群集，并可以采用排水邏輯實現零宕機的更新方式，目前只有SCVMM 和 CAU ，VMM更新也會采取符合性基線的方式去協調更新過程，逐個排水確保群集可用，其它更新方式WSUS，SCCM，VMST，MBSA則都不會感知到群集，默認情況下都會造成一定的更新宕機時間