WSFC2016 故障域站點感知

   很高興和大家介紹另外一項WSFC2016的酷炫技術，即故障域功能

   與之類似的技術有CloudStack，Openastack等

   以CloudStack為例，在CloudStack中，針對于資源架構，我們可以手動來定義架構模型，從最上層Region，Zone，Pod，Cluster，再到最底層的Host，通過規(guī)劃這樣一套架構模型，我們可以在云管理軟件上面定義出云資源池底層的架構，實現(xiàn)既能夠對于用戶屏蔽技術細節(jié)，也能夠讓云管理軟件按照架構模型運轉

   其中最上層，最大的架構為  Region，也就是地域了，例如，我們在使用阿里云，Azure，AWS的時候創(chuàng)建虛擬機，都只需要選擇一個區(qū)域就好了，對應到后臺就是這個概念，Region的概念是地域，不同Region，則應該意味著不同地域，如果說用戶把兩臺虛擬機部署在兩個不同的Region，那么它們同時出現(xiàn)故障的幾率會很低

   其次是Zone，CloudStack中，Zone主要是指數(shù)據(jù)中心，我們說一個Zone，就是說一個數(shù)據(jù)中心，一個數(shù)據(jù)中心里面可能有多個Pod，即機架，不同機架可能使用不同的網(wǎng)絡架構設施，一個機架上面有可能有多個Cluster，一個Cluster上面又可能有多個Host，同一個Zone內共用一個二級存儲。

   定義這樣的架構后，對于用戶來說，用戶不需要知道太多，它們只需要知道，我們要部署到離我們訪問地方比較近的Region，如果我的不同虛擬機放在不同Region，會被放置在不同的，很遠的地方，不會同時發(fā)生故障，這樣就夠了

   一些云平臺例如Azure，可以讓用戶選擇不同的可用性集，對應的概念，就是這里的機架，如果選擇虛擬機在不同的可用性集，意味著虛擬機會被放置在不同的Pod，微軟也叫做Rack，如果部署了可用性集后Azure才可以保證SLA在99.95%

   一套云管理系統(tǒng)，對于資源管理員來說，管理員主要關注的是持續(xù)保證租戶資源的SLA，置備多種高可用方案，災備方案，等等，這里我們主要討論的是高可用方案，在高可用方案里面，通常在云計算業(yè)內，人們會談到故障域

   什么是故障域呢，例如，我一個節(jié)點壞了，上面虛擬機可以漂到其它節(jié)點，這時候節(jié)點是一個故障域，單個節(jié)點故障了，我們部署了群集系統(tǒng)，會故障轉移，并不會影響SLA

   默認情況下大多數(shù)云管理平臺的failover級別都是Cluster內的節(jié)點級別，理想情況下，老王認為，所有已定義的Region，zone，pod，Cluster都是應該可以感知的，例如，如果群集里面一個節(jié)點壞了，我可以把虛擬機先遷移到Cluster內其它節(jié)點，如果不行，再遷移到同Pod上面其它群集，如果不行再遷移到Zone里面的不同Pod，如果不行再遷移到不同Zone，甚至最后整個Zone癱瘓，還可以轉移到其它Region恢復運行，如果真的可以做到這樣就太強大了，真正實現(xiàn)了云計算持續(xù)可用的目的

   不過在現(xiàn)實情況下，根據(jù)老王的觀察，我們軟件的定義的這些Region，zone，pod，Cluster，一部分是用來看的，一部分是用來用的，假設Region，zone，pod這些東西沒有和云資源故障系統(tǒng)達成感應，那么是不會有老王上面說的效果的，可能最多就是，我們可以集中針對同一個Pod里面的Cluster或Host進行policy設置，可以讓一個Zone中心里面的所有Pod，Cluster使用相同的共享二級存儲，或者通過報告集中輸出下報告之類的。

   實務上通常一些云計算廠商會實現(xiàn)Region級別，Pod級別，Cluster級別的故障域感知，例如Cluster失效，會恢復到其它Region繼續(xù)運行，或是Cluster維護，由Pod上面其它Cluster暫時負責服務。

   這里老王說了這么多，是希望把故障域這樣的一個概念帶給大家，這個概念是相通的，不光在微軟WSFC 2016會有，在Cloudstack，Openstack等其它云平臺管理軟件中也會有，老王認為這項功能在云平臺管理，或者大型數(shù)據(jù)中心，大型托管數(shù)據(jù)中心里面會很常見，是項規(guī)范管理的好功能。

   這項技術把它叫做軟件定義故障域也好，故障域也好，舉個例子

   比如我們知道，租戶的虛擬機在HV01節(jié)點，Cluster01上面運行，Cluster 01在Pod01上面，Pod01在Zone01，Zone01在Region北京運行，之前是在腦子里知道，現(xiàn)在我們可以通過軟件定義在管理系統(tǒng)中

   如果HV01節(jié)點Host級別壞了，由于Cluster自動實現(xiàn)主機級別故障域，節(jié)點會轉移到其它節(jié)點上面運行，注意，只要是通過可以正常進行故障轉移的系統(tǒng)構成的cluster，那么默認物理上就已經(jīng)實現(xiàn)為了主機故障域

  如果Cluster壞了呢，那么Cluster就是一個故障域，Cluster上面會有很多臺虛擬機，也會隨之跟著停機，如果沒有置備跨Cluster的轉移機制，這里就會產生宕機時間。

  如果Pod級別壞了，那么Pod就是一個故障域，Pod上面會有很多Cluster，Cluster里面又會有很多應用，所有全部停機。

  如果Zone級別壞了，那么整個Zone就是一個故障域

  如果Region級別壞了，那么整個Region就是一個故障域

  大家可以看出，越大的級別壞了，影響到的越多，所以對于架構人員來說，如果你作為一個云提供商或者大型托管數(shù)據(jù)中心提供商，那么首先您應該針對于每個故障域級別強化可靠性，盡量做好災難恢復機制，什么級別的故障域出現(xiàn)故障，需要如何恢復處理，其次，應該想辦法實現(xiàn)用戶云資源的跨故障域轉移，例如當前在Cluster運作，如果Cluster壞了，能否轉移到其它Pod，或其它Zone繼續(xù)運行，實現(xiàn)后建議用戶在不同的可感應故障域上面部署資源。

   故障域級別，通常這種東西，是管理員心里有數(shù)，或者寫在合同上面的東西，我們通過一些云平臺軟件或管理軟件，無非就是實現(xiàn)故障域，在電腦界面上面可見，可出集中管理，出報表，出架構視圖

   但是更重要的，我們是要實現(xiàn)故障域的感知，確保用戶選擇到不同故障域的相同資源不會同時出現(xiàn)故障，確保故障域發(fā)生可以跨故障域感知，讓用戶虛擬機正常情況在同Region下面的群集節(jié)點運行，如果同Region出現(xiàn)故障，可以直接讓虛擬機跨Region遷移繼續(xù)運行，因此故障域的定義大體會有以下功能

    1.實現(xiàn)軟件層面的故障域架構，便于記錄查看，便于與物理架構對應

    2.實現(xiàn)云管理策略按照故障域架構分配策略

    2.實現(xiàn)故障域感知，確保用戶選擇到不同故障域的相同資源不會同時出現(xiàn)故障

    3.實現(xiàn)跨故障域感知，在發(fā)生故障時能夠讓資源跨不同級別故障域進行轉移

    4.通過故障域功能，可以提高同一故障域內，存儲，網(wǎng)絡，計算資源的粘性性能，確保同一故障域內的存儲和計算資源可以很快的工作。

  要實現(xiàn)故障域，主要工作應該分為兩步，1.邏輯定義 2.具體實現(xiàn)

  邏輯定義，即是我們先定義出來，故障域數(shù)據(jù)，先在軟件層面創(chuàng)建出來，讓后把資源加進來，這樣看起來我們有了故障域了，但其實只是看著好看，如果云平臺支持，可以做一些報表或策略控制

  具體實現(xiàn)，既真正實現(xiàn)故障域的功能，讓用戶不同作用域的資源不會同時宕機，讓低級別故障域不可用，用戶資源還可以跨故障域遷移到更高的級別，具體實現(xiàn)這個步驟呢，一部分我們可以依賴于技術手段，如果技術手段不到位，我們也可以依賴于手動，或者說，人腦把

   定義了故障域不是說了幾個字那么簡單，管理員做維護的時候，是要心里有數(shù)的，例如，不能同一時間對所有故障域做維護吧，一定要先維護好一個故障域，再維護另外一個，如果技術手段不行，不能做到跨故障域級別故障轉移，那么真的一個故障域級別壞了，管理員是需要手動把用戶資源弄走再到另外故障域恢復的。

   所以說故障域，不光是軟件上面的定義和技術實現(xiàn)，更多的也是要求管理員維護的時候有故障域這樣的一個思路，如果用戶資源在不同故障域，我應該怎么維護，不同的故障域級別壞了，我應該關注那些內容，參照什么流程恢復，如何跨故障域級別恢復，等等，軟件技術層面實現(xiàn)之后，更多的是維護流程

  Ok，上面看了很多通用性的概念，下面我們就來看下微軟WSFC 2016在故障域上面交出的答卷把

  在WSFC 2016中微軟針對于故障域，開通了個四個級別，分別是Site，Rack，Chassis，Node，其中Node是群集安裝后默認就有，站點，機架，機箱，我們可以自行創(chuàng)建，自行構建它們之間的嵌套級別，并且針對于每個故障域級別都可以做詳細的說明，便于查看，讓我很感到驚喜的是WSFC 2016中的故障域并不只是說說而已，而是真的WSFC本身就可以幫助我們實現(xiàn)故障域感知的功能，目前老王觀察看到  Site，Rack，Chassis這三種故障域級別都有各自生效的場景

   例如，同一個Site上面的Node，默認情況會在Site內執(zhí)行故障轉移，如果Site所有群集節(jié)點不可用，再轉移至不同Site，隨之又有很多Site故障域級別的粘合性優(yōu)化，可以配置群集級別的首選Site，應用級別的首選Site，同一個Site虛擬機會使用同一個Site的存儲，如果存儲移動到其它Site，則虛擬機也跟著移動，等等，本文后面我也將主要介紹WSFC 2016 Site級別的故障域感知。

   還有一種場景，即Storage Direct Spaces，這項技術相信很多關注微軟技術的朋友已經(jīng)測過了，類似于VSAN，可以將每個節(jié)點肚子里面存儲貢獻出來形成一個存儲池，再基于這個存儲池構建存儲空間，CSV，SOFS，最終交付給應用，在SDS的場景下，當我們寫入數(shù)據(jù)給SDS存儲空間，數(shù)據(jù)是會被撒在不同節(jié)點的，配置了雙向鏡像，三向鏡像，雙重校驗的等容錯技術后，數(shù)據(jù)會被撒多份，屆時在容錯技術容許的情況下，可以允許指定的節(jié)點數(shù)壞掉，然后新加節(jié)點恢復，或磁盤壞掉，新加磁盤恢復，所以，默認情況下SDS就已經(jīng)有了磁盤級別故障域，節(jié)點級別故障域

   我們也可以把SDS技術和WSFC 2016故障域新功能結合起來，在開啟SDS功能前，我們針對于節(jié)點構建Rack或Chassis級別的故障域，屆時SDS執(zhí)行容錯時，將按照拓撲進行操作，例如會保證數(shù)據(jù)始終灑在不同Rack或不同chassis節(jié)點上面，這樣即便是一個Rack或一個chassis故障，也不會影響SDS，注意，如果希望實現(xiàn)這項功能，建議最好在SDS開啟之前就規(guī)劃好故障域級別，否則SDS建好之后在規(guī)劃，需要重新移除節(jié)點，再加入到故障域。

WSFC 2016故障域群集配置命令：

Get-ClusterFaultDomain：獲取群集故障域架構，可以從群集級別，或任意故障域級別

Set-ClusterFaultDomain：移動資源所屬故障域，配置故障域相關參數(shù)

New-ClusterFaultDomain：創(chuàng)建群集故障域，可以選擇Site，Rack，Chassis級別的故障域

Remove-ClusterFaultDomain：刪除故障域

實驗示例：

#創(chuàng)建北京站點和上海站點

New-ClusterFaultDomain -Type Site -Name "Beijing" -Description "Primary Site"

New-ClusterFaultDomain -Type Site -Name "Shanghai" -Description "Secondary Site"

#創(chuàng)建北京站點數(shù)據(jù)中心Rack和上海站點數(shù)據(jù)中心Rack 

New-ClusterFaultDomain -Type Rack -Name "Rack Beijing1" -Location "Fumadasha 17, Room 501"

New-ClusterFaultDomain -Type Rack -Name "Rack Shanghai1" -Location "TaiDidash 14, Room 203"

#創(chuàng)建北京Rack上面的兩個機箱，上海Rack上面的兩個機箱

New-ClusterFaultDomain -Type Chassis -Name "Chassis 01"-Location "Rack Beijing01 Ontop"

New-ClusterFaultDomain -Type Chassis -Name "Chassis 02"-Location "Rack Beijing01 Under"

New-ClusterFaultDomain -Type Chassis -Name "Chassis 03"-Location "Rack Shanghai01 Ontop"

New-ClusterFaultDomain -Type Chassis -Name "Chassis 04"-Location "Rack Shanghai01 Under"

需要注意，這里每個故障域Name都將是唯一的

#添加服務器進入機箱

Set-ClusterFaultDomain -Name "HV01" -Parent "Chassis 01"

Set-ClusterFaultDomain -Name "HV02" -Parent "Chassis 02"

Set-ClusterFaultDomain -Name "HV03" -Parent "Chassis 03"

Set-ClusterFaultDomain -Name "HV04" -Parent "Chassis 04"

#構建機箱機架站點依賴關系

Set-ClusterFaultDomain -Name "Chassis 01" -Parent "Rack Beijing1"

Set-ClusterFaultDomain -Name "Chassis 02" -Parent "Rack Beijing1"

Set-ClusterFaultDomain -Name "Chassis 03" -Parent "Rack Shanghai1"

Set-ClusterFaultDomain -Name "Chassis 04" -Parent "Rack Shanghai1"

Set-ClusterFaultDomain -Name "Rack Beijing1" -Parent "Beijing"

Set-ClusterFaultDomain -Name "Rack Shanghai1" -Parent "Shanghai"

#獲取故障域拓撲

Get-ClusterFaultDomain

#獲取故障域完整信息

Get-ClusterFaultDomain | ft name,type,parentname,childrennames,Location,description  -autosize

還可以把，在這里大家可以看到，老王之前定義的所有故障域，以及嵌套關系，還有位置信息和說明信息，這兩個也是新屬性，主要用于對故障域做標注使用，便于排錯或者查找，可以看到，從城市級別，到數(shù)據(jù)中心大廈級別，到屋子級別，機架級別，甚至定義到機架上面機箱的位置。您也可以在站點Location的位置輸入城市+數(shù)據(jù)中心信息，Location和description信息也可以后期Set去改，這里有很多種玩法，大家可以自己去發(fā)掘，關鍵是準確，有意義，明了即可。

#獲取單一故障域拓撲

#獲取某一級別故障域拓撲

#刪除故障域

如果要刪除一個故障域，要求下面沒有子資源，例如我們要刪除Chassis 01，但是下面有HV01節(jié)點，我們就需要先移除HV01出去

#移除要被刪除故障域下面資源

Set-ClusterFaultDomain -Name "HV01" -Parent ""

#刪除故障域

除了可以使用Poweshell配置群集故障域，還可以導出xml進行配置，編輯完成后再導入xml

#導出故障域架構xml

Get-ClusterFaultDomain | Out-File <Path>

使用工具完成XML后，需要使用以下命令再把XML上傳回去生效

$xml = Get-Content <Path> | Out-String  

Set-ClusterFaultDomainXML -XML $xml

以上，老王簡單為大家介紹了下WSFC2016中新增的故障域功能，以及配置辦法，但是到目前為止我們只是邏輯創(chuàng)建出了故障域，可以看到，可以和物理對應，但是有沒有生效呢，還沒有，因為故障域的生效，取決于云管理平臺，或WSFC能感應到什么程度

在常規(guī)設計中，故障域通常是在云平臺管理系統(tǒng)中定義的，故障域會運作在云基礎架構的整體架構上，而WSFC則是反其道而行之，在群集的級別上面定義Site，Rack，Chassis，這樣不論是Site，Rack，Chassis都需要在群集的框架內運行，這也是微軟的架構和其它廠商不同之處。

其中老王認為，對于故障域站點感知，WSFC做的還算不錯，我們定義了站點故障域，把節(jié)點放入站點故障域下面后能夠實現(xiàn)

站點感知：設置好了站點后，我們可以讓群集節(jié)點每次故障轉移或維護模式，都先在站點內進行角色轉移，如果本站點無正常節(jié)點可轉移，再轉移至其它站點，在以前的版本中是沒有這項技術的，以前版本中如果我們希望實現(xiàn)類似的需求，是通過設置應用的首選所有者來實現(xiàn)，2016則把站點感知帶到群集中

存儲站點感知：群集中的虛擬機，將會follow同站點內的CSV，假設CSV遷移到其它站點，一分鐘后，虛擬機發(fā)現(xiàn)，CSV遷移到其它站點，那么虛擬機也會實時遷移過去，配置站點感知后，會確認首選站點始終直接訪問存儲，如果存儲移動，則虛擬機也跟隨移動。

群集組站點感知：我們也可以配置應用的站點感知，例如設置SQL實例1的首選站點為beijing，SQL實例2的首選站點為shanghai，這樣可以實現(xiàn)一種多主運行應用的場景，讓SQL1故障轉移首先在beijing站點內，SQL2故障轉移首先在shanghai站點內。

首選站點：配置了站點感知之后，我們首先要選擇出首選站點，首選站點可以確保，當群集出現(xiàn)50/50投票時，動態(tài)仲裁始終去掉非首選站點的投票，讓首選站點運作，沒錯，這替代LowerQuorumPriorityNodeID，在群集冷啟動時，虛擬機也會優(yōu)先在首選站點啟動

它們的優(yōu)先級順序如下

存儲站點感知>群集組站點感知>首選站點感知

除了這些信息外，站點感知功能隨之增加了新的跨站點心跳檢測機制，我們將在下一篇博客中進行介紹

OK，下面開始實驗驗證

清空所有故障域配置

實驗環(huán)境

群集當前基于CSV跑了一臺虛擬機，兩個dtc，都運作在北京站點HV01

故障域配置如下

實現(xiàn)驗證站點感知，在未配置首選所有者情況下，三個群集應用運作于HV01，歸屬于同一站點故障域beijing

手動停止節(jié)點HV01群集服務，應用自動首先遷移至同站點內HV02

打開clusterlog查看

   這里我們雖然成功了，但是也有一定幾率的情況下，我們達不到這樣的效果，在2016中，當我們構建了站點故障域后，群集再次進行故障轉移時，傳統(tǒng)群集角色會直接在本站點內向嘗試進行故障轉移，而基于CSV的虛擬機則并不一定，原因是CSV是可以漂移的，可能現(xiàn)在CSV主控制點在HV04，但是虛擬機在HV01，這也是可以跑的

   如果CSV的主控節(jié)點和虛擬機就在同一個節(jié)點，那么當節(jié)點宕機時，有可能CSV會去其它站點，假設CSV去了其它站點的節(jié)點，那么虛擬機也會跟著follow過去

   如果CSV的主控節(jié)點和HV01不在一個Site，那么當HV01故障轉移時，虛擬機會follow CSV所在的site，CSV在哪，虛擬機就去哪，確保虛擬機可以獲得最好的性能，而忽略站點內感知的功能，因此存儲感知的優(yōu)先級也最高

   如果虛擬機當前是開機狀態(tài)，則每個一分鐘會檢測，我和CSV是否在同一個Site，如果不在同一個Site，我要實時遷移過去，如果虛擬機時關機狀態(tài)則不會檢測，但是故障轉移或維護時，會先去找CSV所在站點，在群集日志中可以看到

  接下來就要進入另外的一項技術，即首選站點功能，首選站點配置級別，可以是在群集級別，存儲級別，群集組級別，這里我們首先要配置的就是存儲級別，我們手動來規(guī)定確保CSV和站點的粘性，例如CSV01 始終follow 北京站點，CSV02始終follow上海站點

  這樣北京站點的虛擬機始終就找北京站點的CSV01，CSV01也始終會在北京站點，虛擬機故障轉移或維護也始終會先在北京站點，因為CSV已經(jīng)被固定，如果CSV出現(xiàn)維護操作或失敗操作也可以第一時間回到北京站點，配置在同一個站點的CSV會在節(jié)點內執(zhí)行負載分布

#獲取CSV的群集組名稱

Get-ClusterSharedVolume | Get-ClusterGroup

CSV也是群集組 Really？

#基于獲取到的CSV群集組名稱，配置到首選站點

（Get-ClusterGroup -name  CSVClusterGroupName）.PreferredSite =“beijing”

OK，現(xiàn)在我們就可以放心了，虛擬機會始終follow CSV，CSV也始終follow 本地站點，這樣確保了虛擬機發(fā)生故障，在本地站點有可用節(jié)點，一定會先遷移到本地站點。

下面我們再配置群集級別的首選站點，配置群集級別首選站點的目的無非是發(fā)生50 50分時讓群集始終確保首選站點可以獲勝。

#查看群集當前節(jié)點投票與見證投票

直接禁用仲裁磁盤，模擬群集仲裁失效，50 50分成情況下，動態(tài)仲裁自動選擇一個節(jié)點去掉投票數(shù)

可以看到默認情況下，群集自動去掉了上海站點的投票

我們如果手動指定首選站點，例如，我們手動指定上海為首選站點，那么當下次再發(fā)生五五分成的時候，動態(tài)仲裁將始終去掉北京站點節(jié)點的投票

ClusterLog

存儲見證在的時候完整投票數(shù)

見證失效的臨時投票數(shù)，隨后立刻會被動態(tài)仲裁隨機去掉投票

默認下動態(tài)仲裁去掉HV03投票

手動修改后去掉HV01投票

以上為首選站點在群集級別配置后的效果之一，看起來2012R2 LowerQuorumPriorityNodeID并沒太大差別

#配置群集級別首選站點回到北京

(Get-Cluster).PreferredSite = Beijing

看過了存儲級別的站點感知，以及首選站點替代LowerQuorumPriorityNodeID的新功能，最后我們來看下主菜，即應用程序的多主站點感知

在看應用程序多主站點感知，老王還是想為大家看下群集級別站點感知的效果，當前我們已經(jīng)配置了存儲站點感知，因此可以發(fā)揮出完整的效果

時間節(jié)點1

所有應用和虛擬機運行于北京站點HV01

手動停止HV01群集服務，CSV遷移同站點其它節(jié)點，所有角色遷移同站點內其它節(jié)點

再次停止HV02群集服務，失去整個Beijing站點，所有應用跨站點故障域遷移到Shanghai

  至此就是故障域站點感知的效果了，對于了解故障域概念，但是不了解微軟WSFC的人來說，這可能很炫，應用感知到故障域，并且優(yōu)先在故障域內轉移，同一站點故障域內虛擬機可以獲得存儲最好的性能，如果同級別站點故障域不可用，可以跨故障域轉移至新故障域站點繼續(xù)運行，看起來很不錯，但是內行看門道，其實呢，只不過是包上來一層新的概念，我們通過原來的首選所有者技術也可以實現(xiàn)類似的效果，只不過通過新的方式配置，看起來更加專業(yè)些，便于故障域概念的落地。

  相對于站點感知功能，老王更看重的是另一大塊，即首選站點感知，首先站點感知里面包括群集級別，存儲級別，群集組級別，其中老王更看重存儲級別的首選站點感知，可以和站點感知功能融合，確保同站點內虛擬機始終訪問同站點的存儲，讓CSV存儲和虛擬機始終在同一個站點，同站點始終獲取最好的性能，這是以前版本沒有的

  梳理下WSFC 2016針對于故障域新增的新功能

  1.故障域定義：全新，支持站點感知，SDS感知

  2.站點感知：代替首選所有者

  3.首選站點感知：替代LowerQuorumPriorityNodeID

  4.應用多主首選站點感知：代替首選所有者

  5.CSV存儲首選站點感知：存儲follow站點，VMfollow存儲

  6.新增跨站點心跳檢測參數(shù)

  故障域和站點感知支持WSFC傳統(tǒng)同域部署，工作組部署與同林多域部署

  作為微軟本地端產品首次嘗試引入故障域屬性，老王認為微軟做的已經(jīng)還可以，期望未來可以不斷完善，在老王看來，故障域其實可以更上一個級別，例如我們可以在SCVMM的級別定義故障域，從站點，數(shù)據(jù)中心，機架，機箱，群集，Host，這樣從上向下做的話也許會更好，因為現(xiàn)階段從下向上定義，畢竟群集的規(guī)模受限，如果是在VMM級別，則我們不必受限于單個群集的規(guī)模，甚至可以針對站點，或機架，機箱，數(shù)據(jù)中心，配置不同的故障轉移策略，網(wǎng)絡策略，存儲策略，那樣就更好了，希望這項功能能夠得到不斷的完善，越來越多的本地端產品，或群集上層應用可以更好的和故障域協(xié)同。

最后，應用多主首選站點感知，我們可以配置在群集組的級別，配置不同的群集組選擇不同的首選站點，這樣不同的群集組就都會在各自的首選站點中先執(zhí)行故障轉移，如果首選站點無可用節(jié)點，再轉移至其它站點，這樣在一定程度上，可以減少跨站點轉移的成本，確保每個站點的資源都得到合理的利用，不會本站點還有節(jié)點就轉移到跨站點，一定程度上可以減少宕機時間，提高應用運行的時間。

#配置多主站點感知

對于devtestdtc首選站點為beijing

對于MikeWang首選站點為beijing

(Get-ClusterGroup -Name devtestdtc).PreferredSite = Beijing

(Get-ClusterGroup -Name MikeWang).PreferredSite = Beijing

對于devtest1dtc首選站點為shanghai

(Get-ClusterGroup -Name devtestdtc1).PreferredSite = Shanghai

當前devtestdtc Mikewang在HV01運行，devtestdtc1在HV04運行

停機HV01，devtestdtc Mikewang轉移至北京同站點HV02

停機HV04，devtestdtc轉移至上海同站點HV03

針對于站點感知或應用多主首選站點感知，建議配置應用的故障回復屬性，這樣當檢測到首選站點，或本地站點可用時，會回到原來站點運行