WSFC2016 故障域站點感知

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

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

   以CloudStack爲例，在CloudStack中，針對於資源架構，咱們能夠手動來定義架構模型，從最上層Region，Zone，Pod，Cluster，再到最底層的Host，經過規劃這樣一套架構模型，咱們能夠在雲管理軟件上面定義出雲資源池底層的架構，實現既可以對於用戶屏蔽技術細節，也可以讓雲管理軟件按照架構模型運轉

   其中最上層，最大的架構爲  Region，也就是地域了，例如，咱們在使用阿里雲，Azure，AWS的時候建立虛擬機，都只須要選擇一個區域就行了，對應到後臺就是這個概念，Region的概念是地域，不一樣Region，則應該意味着不一樣地域，若是說用戶把兩臺虛擬機部署在兩個不一樣的Region，那麼它們同時出現故障的概率會很低

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

 

   定義這樣的架構後，對於用戶來講，用戶不須要知道太多，它們只須要知道，咱們要部署到離咱們訪問地方比較近的Region，若是個人不一樣虛擬機放在不一樣Region，會被放置在不一樣的，很遠的地方，不會同時發生故障，這樣就夠了

   

   一些雲平臺例如Azure，可讓用戶選擇不一樣的可用性集，對應的概念，就是這裏的機架，若是選擇虛擬機在不一樣的可用性集，意味着虛擬機會被放置在不一樣的Pod，微軟也叫作Rack，若是部署了可用性集後Azure才能夠保證SLA在99.95%

   一套雲管理系統，對於資源管理員來講，管理員主要關注的是持續保證租戶資源的SLA，置備多種高可用方案，災備方案，等等，這裏咱們主要討論的是高可用方案，在高可用方案裏面，一般在雲計算業內，人們會談到故障域

   什麼是故障域呢，例如，我一個節點壞了，上面虛擬機能夠漂到其它節點，這時候節點是一個故障域，單個節點故障了，咱們部署了羣集系統，會故障轉移，並不會影響SLA

   默認狀況下大多數雲管理平臺的failover級別都是Cluster內的節點級別，理想狀況下，老王認爲，全部已定義的Region，zone，pod，Cluster都是應該能夠感知的，例如，若是羣集裏面一個節點壞了，我能夠把虛擬機先遷移到Cluster內其它節點，若是不行，再遷移到同Pod上面其它羣集，若是不行再遷移到Zone裏面的不一樣Pod，若是不行再遷移到不一樣Zone，甚至最後整個Zone癱瘓，還能夠轉移到其它Region恢復運行，若是真的能夠作到這樣就太強大了，真正實現了雲計算持續可用的目的

   不過在現實狀況下，根據老王的觀察，咱們軟件的定義的這些Region，zone，pod，Cluster，一部分是用來看的，一部分是用來用的，假設Region，zone，pod這些東西沒有和雲資源故障系統達成感應，那麼是不會有老王上面說的效果的，可能最多就是，咱們能夠集中針對同一個Pod裏面的Cluster或Host進行policy設置，可讓一個Zone中內心面的全部Pod，Cluster使用相同的共享二級存儲，或者經過報告集中輸出下報告之類的。

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

   這裏老王說了這麼多，是但願把故障域這樣的一個概念帶給你們，這個概念是相通的，不光在微軟WSFC 2016會有，在Cloudstack，Openstack等其它雲平臺管理軟件中也會有，老王認爲這項功能在雲平臺管理，或者大型數據中心，大型託管數據中內心面會很常見，是項規範管理的好功能。

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

   好比咱們知道，租戶的虛擬機在HV01節點，Cluster01上面運行，Cluster 01在Pod01上面，Pod01在Zone01，Zone01在Region北京運行，以前是在腦子裏知道，如今咱們能夠經過軟件定義在管理系統中

   若是HV01節點Host級別壞了，因爲Cluster自動實現主機級別故障域，節點會轉移到其它節點上面運行，注意，只要是經過能夠正常進行故障轉移的系統構成的cluster，那麼默認物理上就已經實現爲了主機故障域

  若是Cluster壞了呢，那麼Cluster就是一個故障域，Cluster上面會有不少臺虛擬機，也會隨之跟着停機，若是沒有置備跨Cluster的轉移機制，這裏就會產生宕機時間。

  若是Pod級別壞了，那麼Pod就是一個故障域，Pod上面會有不少Cluster，Cluster裏面又會有不少應用，全部所有停機。

  若是Zone級別壞了，那麼整個Zone就是一個故障域

  若是Region級別壞了，那麼整個Region就是一個故障域

  你們能夠看出，越大的級別壞了，影響到的越多，因此對於架構人員來講，若是你做爲一個雲提供商或者大型託管數據中心提供商，那麼首先您應該針對於每一個故障域級別強化可靠性，儘可能作好災難恢復機制，什麼級別的故障域出現故障，須要如何恢復處理，其次，應該想辦法實現用戶雲資源的跨故障域轉移，例如當前在Cluster運做，若是Cluster壞了，可否轉移到其它Pod，或其它Zone繼續運行，實現後建議用戶在不一樣的可感應故障域上面部署資源。

   故障域級別，一般這種東西，是管理員內心有數，或者寫在合同上面的東西，咱們經過一些雲平臺軟件或管理軟件，無非就是實現故障域，在電腦界面上面可見，可出集中管理，出報表，出架構視圖

   可是更重要的，咱們是要實現故障域的感知，確保用戶選擇到不一樣故障域的相同資源不會同時出現故障，確保故障域發生能夠跨故障域感知，讓用戶虛擬機正常狀況在同Region下面的羣集節點運行，若是同Region出現故障，能夠直接讓虛擬機跨Region遷移繼續運行，所以故障域的定義大致會有如下功能

    1.實現軟件層面的故障域架構，便於記錄查看，便於與物理架構對應

    2.實現雲管理策略按照故障域架構分配策略

    2.實現故障域感知，確保用戶選擇到不一樣故障域的相同資源不會同時出現故障

    3.實現跨故障域感知，在發生故障時可以讓資源跨不一樣級別故障域進行轉移

    4.經過故障域功能，能夠提升同一故障域內，存儲，網絡，計算資源的粘性性能，確保同一故障域內的存儲和計算資源能夠很快的工做。

  要實現故障域，主要工做應該分爲兩步，1.邏輯定義 2.具體實現

   

  邏輯定義，便是咱們先定義出來，故障域數據，先在軟件層面建立出來，讓後把資源加進來，這樣看起來咱們有了故障域了，但其實只是看着好看，若是雲平臺支持，能夠作一些報表或策略控制

  具體實現，既真正實現故障域的功能，讓用戶不一樣做用域的資源不會同時宕機，讓低級別故障域不可用，用戶資源還能夠跨故障域遷移到更高的級別，具體實現這個步驟呢，一部分咱們能夠依賴於技術手段，若是技術手段不到位，咱們也能夠依賴於手動，或者說，人腦把

   定義了故障域不是說了幾個字那麼簡單，管理員作維護的時候，是要內心有數的，例如，不能同一時間對全部故障域作維護吧，必定要先維護好一個故障域，再維護另一個，若是技術手段不行，不能作到跨故障域級別故障轉移，那麼真的一個故障域級別壞了，管理員是須要手動把用戶資源弄走再到另外故障域恢復的。

  

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

 

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

  在WSFC 2016中微軟針對於故障域，開通了個四個級別，分別是Site，Rack，Chassis，Node，其中Node是羣集安裝後默認就有，站點，機架，機箱，咱們能夠自行建立，自行構建它們之間的嵌套級別，而且針對於每一個故障域級別均可以作詳細的說明，便於查看，讓我很感到驚喜的是WSFC 2016中的故障域並不僅是說說而已，而是真的WSFC自己就能夠幫助咱們實現故障域感知的功能，目前老王觀察看到  Site，Rack，Chassis這三種故障域級別都有各自生效的場景

   例如，同一個Site上面的Node，默認狀況會在Site內執行故障轉移，若是Site全部羣集節點不可用，再轉移至不一樣Site，隨之又有不少Site故障域級別的粘合性優化，能夠配置羣集級別的首選Site，應用級別的首選Site，同一個Site虛擬機會使用同一個Site的存儲，若是存儲移動到其它Site，則虛擬機也跟着移動，等等，本文後面我也將主要介紹WSFC 2016 Site級別的故障域感知。

   還有一種場景，即Storage Direct Spaces，這項技術相信不少關注微軟技術的朋友已經測過了，相似於VSAN，能夠將每一個節點肚子裏面存儲貢獻出來造成一個存儲池，再基於這個存儲池構建存儲空間，CSV，SOFS，最終交付給應用，在SDS的場景下，當咱們寫入數據給SDS存儲空間，數據是會被撒在不一樣節點的，配置了雙向鏡像，三向鏡像，雙重校驗的等容錯技術後，數據會被撒多份，屆時在容錯技術允許的狀況下，能夠容許指定的節點數壞掉，而後新加節點恢復，或磁盤壞掉，新加磁盤恢復，因此，默認狀況下SDS就已經有了磁盤級別故障域，節點級別故障域

   咱們也能夠把SDS技術和WSFC 2016故障域新功能結合起來，在開啓SDS功能前，咱們針對於節點構建Rack或Chassis級別的故障域，屆時SDS執行容錯時，將按照拓撲進行操做，例如會保證數據始終灑在不一樣Rack或不一樣chassis節點上面，這樣即使是一個Rack或一個chassis故障，也不會影響SDS，注意，若是但願實現這項功能，建議最好在SDS開啓以前就規劃好故障域級別，不然SDS建好以後在規劃，須要從新移除節點，再加入到故障域。

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

Get-ClusterFaultDomain：獲取羣集故障域架構，能夠從羣集級別，或任意故障域級別

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

New-ClusterFaultDomain：建立羣集故障域，能夠選擇Site，Rack，Chassis級別的故障域

Remove-ClusterFaultDomain：刪除故障域

實驗示例：

#建立北京站點和上海站點

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

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

#建立北京站點數據中心Rack和上海站點數據中心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"

#建立北京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

還能夠把，在這裏你們能夠看到，老王以前定義的全部故障域，以及嵌套關係，還有位置信息和說明信息，這兩個也是新屬性，主要用於對故障域作標註使用，便於排錯或者查找，能夠看到，從城市級別，到數據中心大廈級別，到屋子級別，機架級別，甚至定義到機架上面機箱的位置。您也能夠在站點Location的位置輸入城市+數據中心信息，Location和description信息也能夠後期Set去改，這裏有不少種玩法，你們能夠本身去發掘，關鍵是準確，有意義，明瞭便可。

#獲取單一故障域拓撲

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

#刪除故障域

若是要刪除一個故障域，要求下面沒有子資源，例如咱們要刪除Chassis 01，可是下面有HV01節點，咱們就須要先移除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中新增的故障域功能，以及配置辦法，可是到目前爲止咱們只是邏輯建立出了故障域，能夠看到，能夠和物理對應，可是有沒有生效呢，尚未，由於故障域的生效，取決於雲管理平臺，或WSFC能感應到什麼程度

在常規設計中，故障域一般是在雲平臺管理系統中定義的，故障域會運做在雲基礎架構的總體架構上，而WSFC則是反其道而行之，在羣集的級別上面定義Site，Rack，Chassis，這樣不管是Site，Rack，Chassis都須要在羣集的框架內運行，這也是微軟的架構和其它廠商不一樣之處。

其中老王認爲，對於故障域站點感知，WSFC作的還算不錯，咱們定義了站點故障域，把節點放入站點故障域下面後可以實現

站點感知：設置好了站點後，咱們可讓羣集節點每次故障轉移或維護模式，都先在站點內進行角色轉移，若是本站點無正常節點可轉移，再轉移至其它站點，在之前的版本中是沒有這項技術的，之前版本中若是咱們但願實現相似的需求，是經過設置應用的首選全部者來實現，2016則把站點感知帶到羣集中

存儲站點感知：羣集中的虛擬機，將會follow同站點內的CSV，假設CSV遷移到其它站點，一分鐘後，虛擬機發現，CSV遷移到其它站點，那麼虛擬機也會實時遷移過去，配置站點感知後，會確認首選站點始終直接訪問存儲，若是存儲移動，則虛擬機也跟隨移動。

羣集組站點感知：咱們也能夠配置應用的站點感知，例如設置SQL實例1的首選站點爲beijing，SQL實例2的首選站點爲shanghai，這樣能夠實現一種多主運行應用的場景，讓SQL1故障轉移首先在beijing站點內，SQL2故障轉移首先在shanghai站點內。

首選站點：配置了站點感知以後，咱們首先要選擇出首選站點，首選站點能夠確保，當羣集出現50/50投票時，動態仲裁始終去掉非首選站點的投票，讓首選站點運做，沒錯，這替代LowerQuorumPriorityNodeID，在羣集冷啓動時，虛擬機也會優先在首選站點啓動

它們的優先級順序以下

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

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

OK，下面開始實驗驗證

清空全部故障域配置

實驗環境

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

故障域配置以下

實現驗證站點感知，在未配置首選全部者狀況下，三個羣集應用運做於HV01，歸屬於同一站點故障域beijing

手動中止節點HV01羣集服務，應用自動首先遷移至同站點內HV02

打開clusterlog查看

   這裏咱們雖然成功了，可是也有必定概率的狀況下，咱們達不到這樣的效果，在2016中，當咱們構建了站點故障域後，羣集再次進行故障轉移時，傳統羣集角色會直接在本站點內向嘗試進行故障轉移，而基於CSV的虛擬機則並不必定，緣由是CSV是能夠漂移的，可能如今CSV主控制點在HV04，可是虛擬機在HV01，這也是能夠跑的

   若是CSV的主控節點和虛擬機就在同一個節點，那麼當節點宕機時，有可能CSV會去其它站點，假設CSV去了其它站點的節點，那麼虛擬機也會跟着follow過去

   若是CSV的主控節點和HV01不在一個Site，那麼當HV01故障轉移時，虛擬機會follow CSV所在的site，CSV在哪，虛擬機就去哪，確保虛擬機能夠得到最好的性能，而忽略站點內感知的功能，所以存儲感知的優先級也最高

   若是虛擬機當前是開機狀態，則每一個一分鐘會檢測，我和CSV是否在同一個Site，若是不在同一個Site，我要實時遷移過去，若是虛擬機時關機狀態則不會檢測，可是故障轉移或維護時，會先去找CSV所在站點，在羣集日誌中能夠看到

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

  這樣北京站點的虛擬機始終就找北京站點的CSV01，CSV01也始終會在北京站點，虛擬機故障轉移或維護也始終會先在北京站點，由於CSV已經被固定，若是CSV出現維護操做或失敗操做也能夠第一時間回到北京站點，配置在同一個站點的CSV會在節點內執行負載分佈

#獲取CSV的羣集組名稱

Get-ClusterSharedVolume | Get-ClusterGroup

CSV也是羣集組 Really？

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

（Get-ClusterGroup -name  CSVClusterGroupName）.PreferredSite =「beijing」

OK，如今咱們就能夠放心了，虛擬機會始終follow CSV，CSV也始終follow 本地站點，這樣確保了虛擬機發生故障，在本地站點有可用節點，必定會先遷移到本地站點。

下面咱們再配置羣集級別的首選站點，配置羣集級別首選站點的目的無非是發生50 50分時讓羣集始終確保首選站點能夠獲勝。

#查看羣集當前節點投票與見證投票

直接禁用仲裁磁盤，模擬羣集仲裁失效，50 50分紅狀況下，動態仲裁自動選擇一個節點去掉投票數

能夠看到默認狀況下，羣集自動去掉了上海站點的投票

咱們若是手動指定首選站點，例如，咱們手動指定上海爲首選站點，那麼當下次再發生五五分紅的時候，動態仲裁將始終去掉北京站點節點的投票

ClusterLog

存儲見證在的時候完整投票數

見證失效的臨時投票數，隨後馬上會被動態仲裁隨機去掉投票

默認下動態仲裁去掉HV03投票

手動修改後去掉HV01投票

以上爲首選站點在羣集級別配置後的效果之一，看起來2012R2 LowerQuorumPriorityNodeID並沒太大差異

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

(Get-Cluster).PreferredSite = Beijing

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

在看應用程序多主站點感知，老王仍是想爲你們看下羣集級別站點感知的效果，當前咱們已經配置了存儲站點感知，所以能夠發揮出完整的效果

時間節點1

全部應用和虛擬機運行於北京站點HV01

手動中止HV01羣集服務，CSV遷移同站點其它節點，全部角色遷移同站點內其它節點

再次中止HV02羣集服務，失去整個Beijing站點，全部應用跨站點故障域遷移到Shanghai

  至此就是故障域站點感知的效果了，對於瞭解故障域概念，可是不瞭解微軟WSFC的人來講，這可能很炫，應用感知到故障域，而且優先在故障域內轉移，同一站點故障域內虛擬機能夠得到存儲最好的性能，若是同級別站點故障域不可用，能夠跨故障域轉移至新故障域站點繼續運行，看起來很不錯，可是內行看門道，其實呢，只不過是包上來一層新的概念，咱們經過原來的首選全部者技術也能夠實現相似的效果，只不過經過新的方式配置，看起來更加專業些，便於故障域概念的落地。

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

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

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

  2.站點感知：代替首選全部者

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

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

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

  6.新增跨站點心跳檢測參數

  故障域和站點感知支持WSFC傳統同域部署，工做組部署與同林多域部署

  做爲微軟本地端產品首次嘗試引入故障域屬性，老王認爲微軟作的已經還能夠，指望將來能夠不斷完善，在老王看來，故障域其實能夠更上一個級別，例如咱們能夠在SCVMM的級別定義故障域，從站點，數據中心，機架，機箱，羣集，Host，這樣從上向下作的話也許會更好，由於現階段從下向上定義，畢竟羣集的規模受限，若是是在VMM級別，則咱們沒必要受限於單個羣集的規模，甚至能夠針對站點，或機架，機箱，數據中心，配置不一樣的故障轉移策略，網絡策略，存儲策略，那樣就更好了，但願這項功能可以獲得不斷的完善，愈來愈多的本地端產品，或羣集上層應用能夠更好的和故障域協同。

最後，應用多主首選站點感知，咱們能夠配置在羣集組的級別，配置不一樣的羣集組選擇不一樣的首選站點，這樣不一樣的羣集組就都會在各自的首選站點中先執行故障轉移，若是首選站點無可用節點，再轉移至其它站點，這樣在必定程度上，能夠減小跨站點轉移的成本，確保每一個站點的資源都獲得合理的利用，不會本站點還有節點就轉移到跨站點，必定程度上能夠減小宕機時間，提升應用運行的時間。

#配置多主站點感知

對於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

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