隨著企業(yè)IT規(guī)模的不斷擴大，各大企業(yè)開始不再僅僅考慮單個服務器節(jié)點的災難恢復，而是考慮到整個數(shù)據(jù)中心的災難恢復，一旦我整個數(shù)據(jù)中心都出現(xiàn)災難，我應該怎么去恢復，因此這兩年很多企業(yè)都意識到了這一點，開始在同城或異地建立多個數(shù)據(jù)中心，以實現(xiàn)數(shù)據(jù)中心級別的全面高可用，災難恢復，那么在制定這種災難恢復過程中會遇到的一些問題，應該如何制定災難恢復計劃，如果使用微軟WSFC作為災難恢復方式，我應該如何去考慮，有哪些需要注意的地方，就是我們今天需要討論的話題。
首先，談起災難恢復，很多企業(yè)想過要做，但是一些情況下，做了災難恢復方案，但是最終災難發(fā)生的時候，卻沒有成功，其原因大概有三
災難恢復機制未生效
沒有明確的災難恢復計劃，操作人員未進行測試，導致延遲災難恢復時間
未實現(xiàn)自動化機制，災難發(fā)生時需要手動操作，人員因為災難發(fā)生無法進行操作
總結(jié)來看，不外乎兩點，1.災難恢復計劃未經(jīng)過周密測試 2.災難恢復機制未實現(xiàn)自動化機制
自動化技術是IT運維的利器，可以幫助我們節(jié)省很大效率，一些時候我們應該去使用自動化，但也不應該全部使用自動化，不過在災難恢復領域，當我們真正去采用一個災難恢復方式時，一定要越自動化越好，就是說，我這個災難恢復方案，在恢復的時候，越少通過人為操作越好，理想情況下，我們應該是實現(xiàn)既定的一套災難恢復機制，災難發(fā)生時一切自動化執(zhí)行，應用恢復，如果災難恢復過多依賴人為操作，則這不一定是個很好的方案，因為一旦真的災難發(fā)生，人不一定能夠第一時間到現(xiàn)場恢復應用。
所以，當我們要做異地數(shù)據(jù)中心時，一定要認真的坐下來，定好災難恢復的計劃，定義災難恢復計劃 我們首先要考慮以下幾個內(nèi)容
災難發(fā)生后，我們應該做那些事，完成那些目標，如何盡快達成這些目標
這些事情的優(yōu)先級順序是怎么樣的，我應該先做那件，后做那件
這些事情應該有那些人做，是否每件事情都在由最合適的人做，每個步驟每個人是否有備崗
執(zhí)行災難恢復的具體步驟，應該是形成標準化手冊。
大體內(nèi)容想好了后，我們就可以開始制定具體的災難恢復計劃，一個完整的災難恢復計劃至少應該包含以下內(nèi)容
災難恢復的范圍：定義災難恢復的范圍，范圍越大，這里要寫的內(nèi)容就越多，數(shù)據(jù)中心，下面的服務器，上面的應用，等等。
災難恢復系統(tǒng)相依性：此處以業(yè)務系統(tǒng)級別為主，按照應用系統(tǒng)級別來看每個系統(tǒng)的依賴性，便于我們制定恢復策略流程
災難恢復策略：根據(jù)災難恢復范圍和依賴性的定義，編寫恢復策略，每一個系統(tǒng)，每一個組件，災難發(fā)生時應該如何恢復，使用什么方式，應該按照怎么樣的順序，如何操作，操作完成后如何驗證，如何規(guī)避風險。
災難恢復方式：具體災難恢復策略執(zhí)行時要使用的方式：可以是手動，高可用群集，復制副本，備份，等等，盡可能采用業(yè)務系統(tǒng)支持的，人員熟悉的，自動化的方式。
緊急聯(lián)絡方式：災難恢復干系人，領導負責人，災難恢復操作人員，應用驗證人員的聯(lián)系方式，確?？梢缘谝粫r間聯(lián)系到
災難定期演練 : 災難恢復一大部分沒有成功的原因就是因為缺少定期演練，導致災難發(fā)生時，既定的災難恢復計劃失效，不能得到執(zhí)行，因此災難定期演練事關重要，建議最少每年執(zhí)行一次災難演練
災難重現(xiàn) ：如果能做到這一點最好，每次災難恢復演練后，或?qū)嶋H的災難恢復后，要求操作人員，或災難恢復小組，將此次災難恢復過程進行記錄，事后回看，是否按照計劃執(zhí)行，還有那些可以優(yōu)化的地方，作為寶貴的知識。
以上，老王結(jié)合自己的一點學習，為大家總結(jié)的災難恢復基本理論，之所以要寫這些呢，是因為老王看到很多企業(yè)明明想要做多地數(shù)據(jù)中心，想要做雙活數(shù)據(jù)中心，災備數(shù)據(jù)中心，但是一拍腦袋就做了，沒有事先規(guī)劃好，也就沒有意義，希望看到的朋友可以有所收獲，在制定災備數(shù)據(jù)中心的時候可以帶來一些幫助。
那么，我們今天主要談的是災難恢復的方式，微軟對于災難恢復的方式有很多，hyper-v復制，備份，WSFC群集，ASR，等等，都可以做災難恢復的方式
其中我們今天關注的就是WSFC群集，WSFC用于多站點數(shù)據(jù)中心群集，它有一個好處，就是WSFC系統(tǒng)本身，是可以實現(xiàn)完全自動化的故障轉(zhuǎn)移機制的，只要群集得到正確的配置，故障發(fā)生時，WSFC會自動的進行切換，不需要人為干預，除非你WSFC群集上面跑的應用，需要故障轉(zhuǎn)移后額外做配置。
WSFC真正開始對于多站點數(shù)據(jù)中心支持的是WSFC 2008，在2008時代，WSFC開始支持多子網(wǎng)的群集架構(gòu)，即是說，你可以北京兩個節(jié)點是10網(wǎng)段，上海兩個節(jié)點是20網(wǎng)段，也可以允許你創(chuàng)建一個群集，北京節(jié)點崩潰時候，應用也可以漂移到20網(wǎng)段的上海上面繼續(xù)工作，而在2003則不可以，2003時代所有群集節(jié)點必須是同一子網(wǎng)。
實現(xiàn)多子網(wǎng)技術，最關鍵的是2008時代WSFC開始支持群集組網(wǎng)絡名稱依賴關系自定義了，對于一個群集組，我們可以讓網(wǎng)絡名稱對應很多個子網(wǎng)的IP地址，這些不同子網(wǎng)IP地址可以是OR關系，只要其中一個能夠聯(lián)機注冊，那么應用就可以正常提供服務。當故障轉(zhuǎn)移之后，在另外子網(wǎng)地址聯(lián)機注冊名稱，應用切換到另外子網(wǎng)地址提供服務。
在WSFC 2008時代，雖然WSFC本身實現(xiàn)了對于多子網(wǎng)的支持，但是一些群集上面的應用卻并不能很好的支持多子網(wǎng)，例如SQL 2005，SQL 2008，Hyper-V 2008實時遷移 ，雖然我們部署了多子網(wǎng)的群集，但是這些應用卻并不支持多子網(wǎng)，依然也沒有意義，SQL2008R2，Hyper-V 2012后，一切都得到了改善。
在我們考慮WSFC多站點時，我們主要可以從以下幾個方面來看
網(wǎng)絡
仲裁
存儲
網(wǎng)絡
對于WSFC多站點網(wǎng)絡，我們首先要思考，整個多站點環(huán)境采用什么樣的網(wǎng)絡架構(gòu)
多子網(wǎng)
不同站點的節(jié)點，是否要使用不同子網(wǎng)，如果使用不同子網(wǎng)，上層應用是否支持，是否會帶來額外的手動操作，多子網(wǎng)是對外網(wǎng)絡多子網(wǎng)，還是心跳網(wǎng)絡也要多子網(wǎng)，如果心跳網(wǎng)絡多子網(wǎng)如何通訊，是否需要添加靜態(tài)路由。
2.延伸VLAN，網(wǎng)絡打通
不同站點的節(jié)點，網(wǎng)絡已經(jīng)打通，不需要各節(jié)點使用不同子網(wǎng)，所有節(jié)點都在一個子網(wǎng)，這種方案，對于群集，應用來講最為省事，支持度最好，但是可能網(wǎng)絡人員會需要額外進行一些配置。
多站點群集網(wǎng)絡環(huán)境下的思考
跨站點心跳檢測閥值
由于群集部署為多站點，其間網(wǎng)絡肯定會多或少會有一些延遲，如何調(diào)整心跳檢測閥值為最合適，這里的心跳檢測閥值為最關鍵，一旦由于網(wǎng)絡延遲，或網(wǎng)絡質(zhì)量，導致心跳檢測閥值達到，將會觸發(fā)故障轉(zhuǎn)移，因此務必要確保網(wǎng)絡質(zhì)量可靠，并根據(jù)實際的網(wǎng)絡延遲情況調(diào)整最為合適，最能準確反應故障的檢測閥值，如果多站點網(wǎng)絡架構(gòu)使用延伸VLAN的方式，可以使用WSFC 2016里面的跨站點閥值定義功能
2.跨站點群集通訊是否加密
默認情況下同一子網(wǎng)內(nèi)節(jié)點群集通信，將會被簽名，通常情況下不需要更改此內(nèi)容，如果說您的群集架構(gòu)是跨站點，會經(jīng)過internet，您可以把群集通信安全級別改為加密，這樣群集間通信會通過加密，更為安全，如果您的跨站點架構(gòu)，是通過單獨的安全通道構(gòu)建，那么您也可以取消簽名和加密，需要注意的是取消群集通信簽名和加密會帶來性能提高，如果采用群集通信加密，會帶來一點點的性能下降，因為節(jié)點每次收發(fā)流量都會多一個加密解密的過程，如需更改，建議事先做好測試，確認加密后性能帶來的下降可以接受，再更改為加密
3.多子網(wǎng)環(huán)境下VM如何連接
如果我們在多子網(wǎng)的環(huán)境下部署了虛擬機，那么虛擬機的網(wǎng)絡連接是個問題，如果虛擬機在北京站點配置的靜態(tài)IP，是通過北京虛擬交換機出去的，到了上海子網(wǎng)不同，虛擬機原有IP將無法通信
因此，對于多站點環(huán)境下的VM，我們通常有以下幾種辦法
針對虛擬機使用DHCP IP地址
針對虛擬機使用靜態(tài)IP，但是在虛擬機內(nèi)部編寫腳本，一旦檢測到網(wǎng)絡環(huán)境發(fā)生改變，即切換為目標靜態(tài)IP
針對多站點環(huán)境使用延伸VLAN網(wǎng)絡架構(gòu)，虛擬機接入同一個子網(wǎng)
針對虛擬機使用網(wǎng)絡虛擬化功能，讓虛擬機帶著IP遷移到不同站點
在Hyper-V復制中和ASR中又更好的解決方案，可以實現(xiàn)災難恢復后自動設置虛擬機為目標IP，因此對于虛擬化的災難恢復，如果考慮到多子網(wǎng)WSFC不太方便，您也可以選擇Hyper-V復制，或ASR。
4.多站點環(huán)境下客戶端連接延遲的問題
所謂客戶端連接延遲，即是說，群集完成了故障轉(zhuǎn)移，但是客戶端卻還是不能訪問應用的這段時間，通常情況下，有兩種原因，1.群集故障轉(zhuǎn)移完成后應用需要額外配置才可以提供訪問 2.DNS客戶端延遲
這里我們主要談的是DNS客戶端延遲的問題，什么是DNS客戶端延遲，以下圖為例，如果我們使用多站點多子網(wǎng)的網(wǎng)絡架構(gòu)，就會面臨這樣的問題，VCO在 SiteA是10網(wǎng)段IP，注冊到DNS，DNS把這條記錄復制到SiteB，SiteB客戶端訪問VCO以為地址就是10網(wǎng)段，當發(fā)生故障轉(zhuǎn)移，群集從SiteA轉(zhuǎn)移到SiteB，VCO的地址發(fā)生了改變，修改后的記錄復制到DNS Server 2，雖然群集完成了故障轉(zhuǎn)移，DNS記錄也得到了復制，但是SiteB的客戶端在1200秒內(nèi)還是沒辦法訪問轉(zhuǎn)移后的服務，因為DNS服務器上每個記錄都會有一個HostRecordTTL時間，這段時間內(nèi)，客戶端將使用緩存的地址，而不再請求新的地址，因此，這是我們需要考慮的地方。
要解決DNS客戶端延遲問題，有幾種辦法
使用延伸VLAN的網(wǎng)絡架構(gòu)，都是同一個子網(wǎng)，不需要修改地址，不涉及到DNS緩存
使用網(wǎng)絡抽象設備，讓群集網(wǎng)絡名稱始終注冊到一個抽象的網(wǎng)絡設備上面，然后網(wǎng)絡設備在把一個抽象的地址注冊到DNS，不論是Site A或是Site B，DNS Server始終面對抽象網(wǎng)絡設備的地址，不涉及到DNS緩存
使用優(yōu)先本地轉(zhuǎn)移方案，配置應用的選所有者未本地節(jié)點，本地所有者失敗后，再轉(zhuǎn)移至跨站點
優(yōu)化多子網(wǎng)下的DNS緩存時間和機制：2008時代WSFC針對于多站點，新增兩個屬性，分別是HostRecordTTL和RegisterAllProvidersIP，HostRecordTTL屬性可以修改DNS緩存的時間，默認是1200秒客戶端再和DNS請求新的地址，我們修改某個群集網(wǎng)絡名稱的這個時間為300秒，這樣客戶端就會更頻繁的和DNS服務器請求新的地址。微軟建議最短不要超過300秒，否則會帶來DNS服務器性能問題。RegisterAllProvidersIP屬性可以讓一個網(wǎng)絡名稱，同時注冊多個子網(wǎng)的地址，默認情況下網(wǎng)絡名稱對應多個OR關系IP，同一個時間只會注冊一個地址，如果這個網(wǎng)絡的地址不可用，切換到另外站點，再注冊另外一個，而RegisterAllProvidersIP則是直接支持注冊所有站點的DNS記錄，但此功能要求應用支持，SQL 2012之后開始支持此功能，應用實際上會先嘗試連接一個IP，如果嘗試連不到，自動連另外一個地址。
仲裁
對于多站點群集來說，仲裁也是個值得思考的問題
見證應該放在那
對于多站點群集而言，見證最好不要放在多站點本身，因為這樣會存在一定的偏袒效應，當發(fā)生網(wǎng)絡分區(qū)時，只要獲得見證的一方將會啟動提供服務
因此，建議對于多站的見證仲裁，最好放在第三個站點的文件見證，磁盤見證，或使用WSFC 2016的云見證功能，這樣不存在偏袒效應，那個站點可以正常與第三個站點或云連接，即存活。
2.見證網(wǎng)絡應該如何設計
一個失敗的見證網(wǎng)絡設計是和心跳網(wǎng)絡，對外網(wǎng)絡設計在一起，例如，如果多站點的對外網(wǎng)絡線路徹底癱瘓，而見證連接網(wǎng)絡和對外網(wǎng)絡使用相同網(wǎng)絡鏈路，那么見證連接網(wǎng)絡也將會癱瘓，災備站點可能因此沒辦法正常啟動，因此見證的連接一定要做到單獨使用一個網(wǎng)絡，防止因為網(wǎng)絡故障，而導致見證失去效果。
3.是否要搭建冷備站點
一些企業(yè)可能會有冷備站點的需求，即一個正常情況下，不對外提供服務的站點，只有當出現(xiàn)重大災難時才會將其啟動，例如北京一個站點，天津一個站點，上海一個站點，我希望正常情況北京壞了，只要轉(zhuǎn)移到天津就好了，只有萬不得已的情況下才轉(zhuǎn)移到上海，這時候您就可以搭建一個冷備站點，操作有兩種選擇 1.取消上海站點的投票資格，這樣上海站點將無法獲得爭取資格，除非您再強制啟動上海站點，并為其賦予投票。 2.設置應用可能所有者只有北京和天津，這樣也可以實現(xiàn)類似的效果，但是如果群集應用少還可以，群集應用過多，到時操作起來會有所麻煩，需要一個一個改。
4.是否要優(yōu)先本地站點轉(zhuǎn)移
當災難發(fā)生時，如果未滿足一定閥值，我們其實沒必要啟動數(shù)據(jù)中心級別的災難恢復的計劃，可以在數(shù)據(jù)中心內(nèi)部主機級別實現(xiàn)災難恢復，這時可以配置應用選所有者為本地，本地沒辦法轉(zhuǎn)移再轉(zhuǎn)移至跨站點，或如果使用WSFC 2016可以利用應用站點感知功能，實現(xiàn)應用多主站點運作。
或者說數(shù)據(jù)中心內(nèi)部，針對于重要應用，架設幾臺冷備機，平時關機，應急時候開機使用，強制啟動，賦予投票，加入群集，但前提是見證磁盤存活，冷備機可以獲得最新群集配置數(shù)據(jù)庫。
5.腦裂或少數(shù)站點情況如何處理的操作規(guī)范
在2008R2時代，如果我們部署多站點架構(gòu)，很容易碰見網(wǎng)絡問題而導致群集出現(xiàn)腦裂，2012開始，微軟新增動態(tài)仲裁功能，在動態(tài)仲裁情況下，我們很少可以看見腦裂的情況，一般如果出現(xiàn)腦裂情況，我們會根據(jù)業(yè)務需要，選擇最合適的一個站點，強制啟動它，其它站點稍后啟動時需要經(jīng)過阻止啟動，以和強制啟動站點同步最新群集數(shù)據(jù)庫，因此，多站點架構(gòu)需要考慮腦裂情況下，如何評定那方為權(quán)威站點，應該如何操作啟動權(quán)威站點。
WSFC 2012時×××始推出動態(tài)仲裁功能，即是說當群集為偶數(shù)節(jié)點，沒有見證的情況下，群集會始終自動去掉一個節(jié)點的投票，維持群集未奇數(shù)投票，當發(fā)生網(wǎng)絡分區(qū)時，被去掉節(jié)點投票的站點，將會下降，沒有被去掉節(jié)點投票的站點繼續(xù)提供服務，我們可以通過2012時代的LowerQuorumPriorityNodeID，或者2016時代的PreferredSite功能來指定，讓群集始終去掉某個節(jié)點的投票，最終達成控制站點啟動的效果，在多站點WSFC架構(gòu)也可以考慮該功能的使用，如果有多個站點，50 50節(jié)點數(shù)情況下希望某個站點始終不要獲勝。
還有一種情況即，少數(shù)節(jié)點數(shù)站點，當發(fā)生災難恢復時，可能會有好幾個站點，有的站點有多數(shù)節(jié)點，有的站點有少數(shù)節(jié)點，正常情況下應該是多數(shù)節(jié)點的站點獲勝，但是我們知道少數(shù)節(jié)點的站點才是我們最希望提供服務的站點，所以我們可以阻止多數(shù)節(jié)點啟動，強制啟動少數(shù)節(jié)點。這項功能需要事先規(guī)劃好，災難恢復后應用應該首先在那些站點啟動，如果發(fā)生意外情況，理想站點是少數(shù)節(jié)點，我應該如何操作。
存儲
對于多站點群集而言共享存儲放在那里是個問題，因為我們需要確保群集在災難發(fā)生時可以完整的在另外一個站點啟動起來
如果群集的共享存儲放在兩端任何一個數(shù)據(jù)中心，當這個數(shù)據(jù)中心出現(xiàn)災難時，另外一個站點也沒辦法繼續(xù)提供服務，因為聯(lián)系不到共享存儲
因此，要架設多站點群集，我們還需要考慮到共享存儲放置問題
通常情況下，多站點的災備恢復，人們會對存儲實現(xiàn)復制機制
基于設備級別存儲復制：直接選擇支持存儲復制的陣列，當存儲交付給群集節(jié)點時候就是被復制的，設備會基于存儲塊級別進行復制，如果在多站點實現(xiàn)這種設備級別復制，最好要有專門線路，因此會花費一筆不少的費用
基于主機軟件級別存儲復制：可以使用類似于賽門鐵克，SteelEye DataKeeper Cluster Edition，或Windows Server 2016原生自帶的存儲復制，這類軟件會把多個節(jié)點操作系統(tǒng)上面的存儲構(gòu)建成一個邏輯，經(jīng)過復制的磁盤，交付給群集磁盤識別，現(xiàn)在越來越多人開始使用這種方案實現(xiàn)跨站點存儲的復制
基于應用級別存儲復制：直接使用類似于exchange dag，SQL ag等，應用可以具備存儲復制技術
除了選擇合適的存儲復制機制，確保存儲持續(xù)可用外，我們還需要選擇存儲復制的方法
使用同步復制或異步復制
使用同步復制，不會丟失數(shù)據(jù)，每次寫入要求會確保同時寫入兩個站點存儲，才會完成，容易帶來應用延遲，對網(wǎng)絡性能要求高。
使用異步復制，有可能會丟失數(shù)據(jù)，每次寫入請求只寫入到所在站點即結(jié)束，稍后再復制到其它站點，這樣應用不會感覺到延遲，復制稍后會在后臺一點一點進行，對網(wǎng)絡性能要求不高，但可能還沒復制過去時發(fā)生災難，而導致數(shù)據(jù)丟失。
在實際環(huán)境中，老王看到大部分企業(yè)還是在使用同步復制，以確保數(shù)據(jù)的完整性
很多人會考慮到DFS復制，實際上，微軟的DFS復制的適用場景是信息工作組，用于存放視頻，文件，圖片，等資料，對于群集，或者VMM的庫，DFS則并不適合，因為DFS只會復制關閉后的數(shù)據(jù)，如果我們的群集里面有虛擬機，數(shù)據(jù)庫，這些不會關閉的文件，DFS是不會復制的
以上老王從網(wǎng)絡，仲裁，見證的角度，來為大家講解了下WSFC多站點需要考慮的點，希望可以為感興趣的朋友帶來收獲
另外有需要云服務器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。
重慶分公司
重慶分公司
