WSFC多站點與災難恢復

隨着企業IT規模的不斷擴大，各大企業開始再也不僅僅考慮單個服務器節點的災難恢復，而是考慮到整個數據中心的災難恢復，一旦我整個數據中心都出現災難，我應該怎麼去恢復，所以這兩年不少企業都意識到了這一點，開始在同城或異地創建多個數據中心，以實現數據中心級別的全面高可用，災難恢復，那麼在制定這種災難恢復過程當中會遇到的一些問題，應該如何制定災難恢復計劃，若是使用微軟WSFC做爲災難恢復方式，我應該如何去考慮，有哪些須要注意的地方，就是咱們今天須要討論的話題。

首先，談起災難恢復，不少企業想過要作，可是一些狀況下，作了災難恢復方案，可是最終災難發生的時候，卻沒有成功，其緣由大概有三

1. 災難恢復機制未生效

2. 沒有明確的災難恢復計劃，操做人員未進行測試，致使延遲災難恢復時間

3. 未實現自動化機制，災難發生時須要手動操做，人員由於災難發生沒法進行操做

總結來看，不外乎兩點，1.災難恢復計劃未通過周密測試 2.災難恢復機制未實現自動化機制

自動化技術是IT運維的利器，能夠幫助咱們節省很大效率，一些時候咱們應該去使用自動化，但也不該該所有使用自動化，不過在災難恢復領域，當咱們真正去採用一個災難恢復方式時，必定要越自動化越好，就是說，我這個災難恢復方案，在恢復的時候，越少經過人爲操做越好，理想狀況下，咱們應該是實現既定的一套災難恢復機制，災難發生時一切自動化執行，應用恢復，若是災難恢復過多依賴人爲操做，則這不必定是個很好的方案，由於一旦真的災難發生，人不必定可以第一時間到現場恢復應用。

因此，當咱們要作異地數據中心時，必定要認真的坐下來，定好災難恢復的計劃，定義災難恢復計劃 咱們首先要考慮如下幾個內容

1. 災難發生後，咱們應該作那些事，完成那些目標，如何儘快達成這些目標

2. 這些事情的優先級順序是怎麼樣的，我應該先作那件，後作那件

3. 這些事情應該有那些人作，是否每件事情都在由最合適的人作，每一個步驟每一個人是否有備崗

4. 執行災難恢復的具體步驟，應該是造成標準化手冊。

大致內容想好了後，咱們就能夠開始制定具體的災難恢復計劃，一個完整的災難恢復計劃至少應該包含如下內容

災難恢復的範圍：定義災難恢復的範圍，範圍越大，這裏要寫的內容就越多，數據中心，下面的服務器，上面的應用，等等。

災難恢復系統相依性：此處以業務系統級別爲主，按照應用系統級別來看每一個系統的依賴性，便於咱們制定恢復策略流程

災難恢復策略：根據災難恢復範圍和依賴性的定義，編寫恢復策略，每個系統，每個組件，災難發生時應該如何恢復，使用什麼方式，應該按照怎麼樣的順序，如何操做，操做完成後如何驗證，如何規避風險。

災難恢復方式：具體災難恢復策略執行時要使用的方式：能夠是手動，高可用羣集，複製副本，備份，等等，儘量採用業務系統支持的，人員熟悉的，自動化的方式。

緊急聯絡方式：災難恢復干係人，領導負責人，災難恢復操做人員，應用驗證人員的聯繫方式，確保能夠第一時間聯繫到

災難按期演練 : 災難恢復一大部分沒有成功的緣由就是由於缺乏按期演練，致使災難發生時，既定的災難恢復計劃失效，不能獲得執行，所以災難按期演練事關重要，建議最少每一年執行一次災難演練

災難重現 ：若是能作到這一點最好，每次災難恢復演練後，或實際的災難恢復後，要求操做人員，或災難恢復小組，將這次災難恢復過程進行記錄，過後回看，是否按照計劃執行，還有那些能夠優化的地方，做爲寶貴的知識。

以上，老王結合本身的一點學習，爲你們總結的災難恢復基本理論，之因此要寫這些呢，是由於老王看到不少企業明明想要作多地數據中心，想要作雙活數據中心，災備數據中心，可是一拍腦殼就作了，沒有事先規劃好，也就沒有意義，但願看到的朋友能夠有所收穫，在制定災備數據中心的時候能夠帶來一些幫助。

那麼，咱們今天主要談的是災難恢復的方式，微軟對於災難恢復的方式有不少，hyper-v複製，備份，WSFC羣集，ASR，等等，均可以作災難恢復的方式

其中咱們今天關注的就是WSFC羣集，WSFC用於多站點數據中心羣集，它有一個好處，就是WSFC系統自己，是能夠實現徹底自動化的故障轉移機制的，只要羣集獲得正確的配置，故障發生時，WSFC會自動的進行切換，不須要人爲干預，除非你WSFC羣集上面跑的應用，須要故障轉移後額外作配置。

WSFC真正開始對於多站點數據中心支持的是WSFC 2008，在2008時代，WSFC開始支持多子網的羣集架構，便是說，你能夠北京兩個節點是10網段，上海兩個節點是20網段，也能夠容許你建立一個羣集，北京節點崩潰時候，應用也能夠漂移到20網段的上海上面繼續工做，而在2003則不能夠，2003時代全部羣集節點必須是同一子網。

實現多子網技術，最關鍵的是2008時代WSFC開始支持羣集組網絡名稱依賴關係自定義了，對於一個羣集組，咱們可讓網絡名稱對應不少個子網的IP地址，這些不一樣子網IP地址能夠是OR關係，只要其中一個可以聯機註冊，那麼應用就能夠正常提供服務。當故障轉移以後，在另外子網地址聯機註冊名稱，應用切換到另外子網地址提供服務。

在WSFC 2008時代，雖然WSFC自己實現了對於多子網的支持，可是一些羣集上面的應用卻並不能很好的支持多子網，例如SQL 2005，SQL 2008，Hyper-V 2008實時遷移 ，雖然咱們部署了多子網的羣集，可是這些應用卻並不支持多子網，依然也沒有意義，SQL2008R2，Hyper-V 2012後，一切都獲得了改善。

在咱們考慮WSFC多站點時，咱們主要能夠從如下幾個方面來看

1. 網絡

2. 仲裁

3. 存儲

網絡

對於WSFC多站點網絡，咱們首先要思考，整個多站點環境採用什麼樣的網絡架構

1. 多子網

不一樣站點的節點，是否要使用不一樣子網，若是使用不一樣子網，上層應用是否支持，是否會帶來額外的手動操做，多子網是對外網絡多子網，仍是心跳網絡也要多子網，若是心跳網絡多子網如何通信，是否須要添加靜態路由。

 2.延伸VLAN，網絡打通

不一樣站點的節點，網絡已經打通，不須要各節點使用不一樣子網，全部節點都在一個子網，這種方案，對於羣集，應用來說最爲省事，支持度最好，可是可能網絡人員會須要額外進行一些配置。

多站點羣集網絡環境下的思考

1. 跨站點心跳檢測閥值

因爲羣集部署爲多站點，其間網絡確定會多或少會有一些延遲，如何調整心跳檢測閥值爲最合適，這裏的心跳檢測閥值爲最關鍵，一旦因爲網絡延遲，或網絡質量，致使心跳檢測閥值達到，將會觸發故障轉移，所以務必要確保網絡質量可靠，並根據實際的網絡延遲狀況調整最爲合適，最能準確反應故障的檢測閥值，若是多站點網絡架構使用延伸VLAN的方式，可使用WSFC 2016裏面的跨站點閥值定義功能

2.跨站點羣集通信是否加密

默認狀況下同一子網內節點羣集通訊，將會被簽名，一般狀況下不須要更改此內容，若是說您的羣集架構是跨站點，會通過internet，您能夠把羣集通訊安全級別改成加密，這樣羣集間通訊會經過加密，更爲安全，若是您的跨站點架構，是經過單獨的安全通道構建，那麼您也能夠取消簽名和加密，須要注意的是取消羣集通訊簽名和加密會帶來性能提升，若是採用羣集通訊加密，會帶來一點點的性能降低，由於節點每次收發流量都會多一個加密解密的過程，如需更改，建議事先作好測試，確認加密後性能帶來的降低能夠接受，再更改成加密

3.多子網環境下VM如何鏈接

若是咱們在多子網的環境下部署了虛擬機，那麼虛擬機的網絡鏈接是個問題，若是虛擬機在北京站點配置的靜態IP，是經過北京虛擬交換機出去的，到了上海子網不一樣，虛擬機原有IP將沒法通訊

所以，對於多站點環境下的VM，咱們一般有如下幾種辦法

1. 針對虛擬機使用DHCP IP地址

2. 針對虛擬機使用靜態IP，可是在虛擬機內部編寫腳本，一旦檢測到網絡環境發生改變，即切換爲目標靜態IP

3. 針對多站點環境使用延伸VLAN網絡架構，虛擬機接入同一個子網

4. 針對虛擬機使用網絡虛擬化功能，讓虛擬機帶着IP遷移到不一樣站點

在Hyper-V複製中和ASR中又更好的解決方案，能夠實現災難恢復後自動設置虛擬機爲目標IP，所以對於虛擬化的災難恢復，若是考慮到多子網WSFC不太方便，您也能夠選擇Hyper-V複製，或ASR。

4.多站點環境下客戶端鏈接延遲的問題

所謂客戶端鏈接延遲，便是說，羣集完成了故障轉移，可是客戶端卻仍是不能訪問應用的這段時間，一般狀況下，有兩種緣由，1.羣集故障轉移完成後應用須要額外配置才能夠提供訪問 2.DNS客戶端延遲

這裏咱們主要談的是DNS客戶端延遲的問題，什麼是DNS客戶端延遲，如下圖爲例，若是咱們使用多站點多子網的網絡架構，就會面臨這樣的問題，VCO在 SiteA是10網段IP，註冊到DNS，DNS把這條記錄複製到SiteB，SiteB客戶端訪問VCO覺得地址就是10網段，當發生故障轉移，羣集從SiteA轉移到SiteB，VCO的地址發生了改變，修改後的記錄複製到DNS Server 2，雖然羣集完成了故障轉移，DNS記錄也獲得了複製，可是SiteB的客戶端在1200秒內仍是沒辦法訪問轉移後的服務，由於DNS服務器上每一個記錄都會有一個HostRecordTTL時間，這段時間內，客戶端將使用緩存的地址，而再也不請求新的地址，所以，這是咱們須要考慮的地方。

要解決DNS客戶端延遲問題，有幾種辦法

1. 使用延伸VLAN的網絡架構，都是同一個子網，不須要修改地址，不涉及到DNS緩存

2. 使用網絡抽象設備，讓羣集網絡名稱始終註冊到一個抽象的網絡設備上面，而後網絡設備在把一個抽象的地址註冊到DNS，不管是Site A或是Site B，DNS Server始終面對抽象網絡設備的地址，不涉及到DNS緩存

3. 使用優先本地轉移方案，配置應用的首選全部者未本地節點，本地全部者失敗後，再轉移至跨站點

4. 優化多子網下的DNS緩存時間和機制：2008時代WSFC針對於多站點，新增兩個屬性，分別是HostRecordTTL和RegisterAllProvidersIP，HostRecordTTL屬性能夠修改DNS緩存的時間，默認是1200秒客戶端再和DNS請求新的地址，咱們修改某個羣集網絡名稱的這個時間爲300秒，這樣客戶端就會更頻繁的和DNS服務器請求新的地址。微軟建議最短不要超過300秒，不然會帶來DNS服務器性能問題。RegisterAllProvidersIP屬性可讓一個網絡名稱，同時註冊多個子網的地址，默認狀況下網絡名稱對應多個OR關係IP，同一個時間只會註冊一個地址，若是這個網絡的地址不可用，切換到另外站點，再註冊另一個，而RegisterAllProvidersIP則是直接支持註冊全部站點的DNS記錄，但此功能要求應用支持，SQL 2012以後開始支持此功能，應用實際上會先嚐試鏈接一個IP，若是嘗試連不到，自動連另一個地址。

仲裁

對於多站點羣集來講，仲裁也是個值得思考的問題

1. 見證應該放在那

對於多站點羣集而言，見證最好不要放在多站點自己，由於這樣會存在必定的偏袒效應，當發生網絡分區時，只要得到見證的一方將會啓動提供服務

所以，建議對於多站的見證仲裁，最好放在第三個站點的文件見證，磁盤見證，或使用WSFC 2016的雲見證功能，這樣不存在偏袒效應，那個站點能夠正常與第三個站點或雲鏈接，即存活。

 2.見證網絡應該如何設計

一個失敗的見證網絡設計是和心跳網絡，對外網絡設計在一塊兒，例如，若是多站點的對外網絡線路完全癱瘓，而見證鏈接網絡和對外網絡使用相同網絡鏈路，那麼見證鏈接網絡也將會癱瘓，災備站點可能所以沒辦法正常啓動，所以見證的鏈接必定要作到單獨使用一個網絡，防止由於網絡故障，而致使見證失去效果。

3.是否要搭建冷備站點

一些企業可能會有冷備站點的需求，即一個正常狀況下，不對外提供服務的站點，只有當出現重大災難時纔會將其啓動，例如北京一個站點，天津一個站點，上海一個站點，我但願正常狀況北京壞了，只要轉移到天津就行了，只有萬不得已的狀況下才轉移到上海，這時候您就能夠搭建一個冷備站點，操做有兩種選擇 1.取消上海站點的投票資格，這樣上海站點將沒法得到爭取資格，除非您再強制啓動上海站點，併爲其賦予投票。 2.設置應用可能全部者只有北京和天津，這樣也能夠實現相似的效果，可是若是羣集應用少還能夠，羣集應用過多，到時操做起來會有所麻煩，須要一個一個改。

4.是否要優先本地站點轉移

當災難發生時，若是未知足必定閥值，咱們其實不必啓動數據中心級別的災難恢復的計劃，能夠在數據中心內部主機級別實現災難恢復，這時能夠配置應用首選全部者爲本地，本地沒辦法轉移再轉移至跨站點，或若是使用WSFC 2016能夠利用應用站點感知功能，實現應用多主站點運做。

或者說數據中心內部，針對於重要應用，架設幾臺冷備機，平時關機，應急時候開機使用，強制啓動，賦予投票，加入羣集，但前提是見證磁盤存活，冷備機能夠得到最新羣集配置數據庫。

5.腦裂或少數站點狀況如何處理的操做規範

在2008R2時代，若是咱們部署多站點架構，很容易遇見網絡問題而致使羣集出現腦裂，2012開始，微軟新增動態仲裁功能，在動態仲裁狀況下，咱們不多能夠看見腦裂的狀況，通常若是出現腦裂狀況，咱們會根據業務須要，選擇最合適的一個站點，強制啓動它，其它站點稍後啓動時須要通過阻止啓動，以和強制啓動站點同步最新羣集數據庫，所以，多站點架構須要考慮腦裂狀況下，如何評定那方爲權威站點，應該如何操做啓動權威站點。

WSFC 2012時×××始推出動態仲裁功能，便是說當羣集爲偶數節點，沒有見證的狀況下，羣集會始終自動去掉一個節點的投票，維持羣集未奇數投票，當發生網絡分區時，被去掉節點投票的站點，將會降低，沒有被去掉節點投票的站點繼續提供服務，咱們能夠經過2012時代的LowerQuorumPriorityNodeID，或者2016時代的PreferredSite功能來指定，讓羣集始終去掉某個節點的投票，最終達成控制站點啓動的效果，在多站點WSFC架構也能夠考慮該功能的使用，若是有多個站點，50 50節點數狀況下但願某個站點始終不要獲勝。

還有一種狀況即，少數節點數站點，當發生災難恢復時，可能會有好幾個站點，有的站點有多數節點，有的站點有少數節點，正常狀況下應該是多數節點的站點獲勝，可是咱們知道少數節點的站點纔是咱們最但願提供服務的站點，因此咱們能夠阻止多數節點啓動，強制啓動少數節點。這項功能須要事先規劃好，災難恢復後應用應該首先在那些站點啓動，若是發生意外狀況，理想站點是少數節點，我應該如何操做。

存儲

對於多站點羣集而言共享存儲放在那裏是個問題，由於咱們須要確保羣集在災難發生時能夠完整的在另一個站點啓動起來

若是羣集的共享存儲放在兩端任何一個數據中心，當這個數據中心出現災難時，另一個站點也沒辦法繼續提供服務，由於聯繫不到共享存儲

所以，要架設多站點羣集，咱們還須要考慮到共享存儲放置問題

一般狀況下，多站點的災備恢復，人們會對存儲實現複製機制

1. 基於設備級別存儲複製：直接選擇支持存儲複製的陣列，當存儲交付給羣集節點時候就是被複制的，設備會基於存儲塊級別進行復制，若是在多站點實現這種設備級別複製，最好要有專門線路，所以會花費一筆很多的費用

2. 基於主機軟件級別存儲複製：可使用相似於賽門鐵克，SteelEye DataKeeper Cluster Edition，或Windows Server 2016原生自帶的存儲複製，這類軟件會把多個節點操做系統上面的存儲構建成一個邏輯，通過複製的磁盤，交付給羣集磁盤識別，如今愈來愈多人開始使用這種方案實現跨站點存儲的複製

3. 基於應用級別存儲複製：直接使用相似於exchange dag，SQL ag等，應用能夠具有存儲複製技術

除了選擇合適的存儲複製機制，確保存儲持續可用外，咱們還須要選擇存儲複製的方法

使用同步複製或異步複製

使用同步複製，不會丟失數據，每次寫入要求會確保同時寫入兩個站點存儲，纔會完成，容易帶來應用延遲，對網絡性能要求高。

使用異步複製，有可能會丟失數據，每次寫入請求只寫入到所在站點即結束，稍後再複製到其它站點，這樣應用不會感受到延遲，複製稍後會在後臺一點一點進行，對網絡性能要求不高，但可能還沒複製過去時發生災難，而致使數據丟失。

在實際環境中，老王看到大部分企業仍是在使用同步複製，以確保數據的完整性

不少人會考慮到DFS複製，實際上，微軟的DFS複製的適用場景是信息工做組，用於存放視頻，文件，圖片，等資料，對於羣集，或者VMM的庫，DFS則並不適合，由於DFS只會複製關閉後的數據，若是咱們的羣集裏面有虛擬機，數據庫，這些不會關閉的文件，DFS是不會複製的

以上老王從網絡，仲裁，見證的角度，來爲你們講解了下WSFC多站點須要考慮的點，但願能夠爲感興趣的朋友帶來收穫