WSFC日常管理操作

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

當前devtestdtc的首選所有者為Node3

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

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

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

devtestdtc首選所有者

devtestdtc可能所有者

devtestdtc1不做任何設(shè)置

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

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

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

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

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

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

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

Node3發(fā)生故障時，devtestdtc1被轉(zhuǎn)移到node1

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

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

在實際使用中老王發(fā)現(xiàn)默認所有者有以下節(jié)點需要注意的地方

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

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

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

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

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

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

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

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

  #手動修改ClusterGroupWaitDelay時間

（Get-Cluster devcluster）.ClusterGroupWaitDelay = 300

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

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

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

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

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

1. 群集節(jié)點關(guān)機開機時，優(yōu)先聯(lián)機上線高優(yōu)先級應用

2. 節(jié)點置為維護模式時，優(yōu)先遷移處理高優(yōu)先級應用

3. 節(jié)點故障轉(zhuǎn)移時，優(yōu)先轉(zhuǎn)移高優(yōu)先級應用

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

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

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

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

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

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

優(yōu)先處理高優(yōu)先級Test1

處理中優(yōu)先級devtestdtc

處理低優(yōu)先級Test2

處理不自動啟動devtestdtc2

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

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

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

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

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

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

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

實驗驗證

當前群集內(nèi)共三個節(jié)點，兩個協(xié)同工作的DTC應用，分別運作在HV01和HV03

當前并沒有設(shè)置首選所有者，HV01直接宕機，devtestdtc會根據(jù)內(nèi)存智能放置，而被放置在HV02

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

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

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

#設(shè)置devtestdtc和devtestdtc2相同反相關(guān)性屬性

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

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

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

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

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

因此大家可以看出，反相關(guān)性在一些場景下會起到作用，例如如果你是一個虛擬化集群，里面你跑了兩臺AD，或兩臺DHCP，或兩臺DNS，兩臺SQL，等兩個節(jié)點協(xié)作完成的應用，你希望始終可以有一臺虛擬機能夠?qū)ν馓峁┓?，那么就可以利用反相關(guān)性，設(shè)置兩臺虛擬機的相同反相關(guān)性，以確保在正常情況下兩臺虛擬機始終分散在不同節(jié)點上，防止單個節(jié)點故障帶來整個應用的故障轉(zhuǎn)移。

通過實踐老王總結(jié)出一些關(guān)于反相關(guān)性的理論

1. 反相關(guān)性設(shè)置優(yōu)先于首選所有者執(zhí)行，優(yōu)先默認所有者執(zhí)行，優(yōu)于內(nèi)存智能放置執(zhí)行

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

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

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

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

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

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

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

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

2. 如果應用設(shè)置了首選所有者和反相關(guān)性，則反相關(guān)性優(yōu)先執(zhí)行，繼續(xù)根據(jù)內(nèi)存智能放置選擇其它節(jié)點為最佳

3. 如果應用設(shè)置了首選所有者，反相關(guān)性，可能所有者，若反相關(guān)性判定的節(jié)點沒有合格的可能所有者投票，則繼續(xù)根據(jù)內(nèi)存智能放置選擇其它節(jié)點為最佳

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

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

SCVMM在執(zhí)行動態(tài)優(yōu)化的時候如果感知到了群集的首選所有者，反相關(guān)性，可能所有者，仲裁等設(shè)置，也會遵守執(zhí)行

WSFC群集更側(cè)重的是故障轉(zhuǎn)移后讓應用快速上線聯(lián)機使用，執(zhí)行簡單的應用和內(nèi)存負載調(diào)度，而SCVMM則更側(cè)重整個虛擬化集群環(huán)境的負載均衡，因此把WSFC群集和SCVMM相結(jié)合可以實現(xiàn)真正的虛擬化資源負載均衡。

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

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

手動移動至指定節(jié)點

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

手動移動至最佳節(jié)點

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

群集整體冷啟動

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

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

群集節(jié)點故障轉(zhuǎn)移

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

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

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

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

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

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

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

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

實驗驗證

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

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

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

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

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

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

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

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

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

優(yōu)先處理高優(yōu)先級Test1虛擬機

處理中優(yōu)先級虛擬機Test2

處理中優(yōu)先級角色devtestdtc

Test1虛擬機處理策略

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

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

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

Test2 放置策略

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

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

devtestdtc3放置策略

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

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

devtestdtc3會首先被置為不自動啟動離線狀態(tài)，但稍后如果資源充足仍會嘗試聯(lián)機。

devtestdtc放置策略

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

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

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

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

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

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

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

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

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

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

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

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

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

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

實驗驗證故障回復

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

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

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

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

HV02再次斷電，應用遷移至其它節(jié)點

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

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

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

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

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

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

故障恢復到底回不回復

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

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

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

反相關(guān)性到底反不反

不會反的情況：

維護模式

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

如果維護前兩個反相關(guān)性應用都在HV01，未設(shè)置首選所有者，則根據(jù)內(nèi)存放置策略隨機放置，兩個反相關(guān)性應用仍有幾率被放在同一節(jié)點

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

維護模式故障回復

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

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

故障轉(zhuǎn)移

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

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

故障轉(zhuǎn)移后故障回復

如果兩個資源設(shè)置了相同反相關(guān)性，相同首選所有者，當故障轉(zhuǎn)移后，需要執(zhí)行故障回復時，如果首選所有者節(jié)點為空，則失去參照，不考慮反相關(guān)性，反相關(guān)性資源都會回去首選所有者

只剩下最后一個節(jié)點時，反相關(guān)性失效

會反的情況：

反相關(guān)性參照生效

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

神奇的跳動

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

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

彩蛋

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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