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多站點需要考慮的點，希望可以為感興趣的朋友帶來收獲