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則都不會感知到羣集，默認狀況下都會形成必定的更新宕機時間