隨著企業(yè)IT規(guī)模的不斷擴大，各大企業(yè)開始不再僅僅考慮單個服務(wù)器節(jié)點的災(zāi)難恢復(fù)，而是考慮到整個數(shù)據(jù)中心的災(zāi)難恢復(fù)，一旦我整個數(shù)據(jù)中心都出現(xiàn)災(zāi)難，我應(yīng)該怎么去恢復(fù)，因此這兩年很多企業(yè)都意識到了這一點，開始在同城或異地建立多個數(shù)據(jù)中心，以實現(xiàn)數(shù)據(jù)中心級別的全面高可用，災(zāi)難恢復(fù)，那么在制定這種災(zāi)難恢復(fù)過程中會遇到的一些問題，應(yīng)該如何制定災(zāi)難恢復(fù)計劃，如果使用微軟WSFC作為災(zāi)難恢復(fù)方式，我應(yīng)該如何去考慮，有哪些需要注意的地方，就是我們今天需要討論的話題。

目前創(chuàng)新互聯(lián)公司已為近千家的企業(yè)提供了網(wǎng)站建設(shè)、域名、網(wǎng)站空間、綿陽服務(wù)器托管、企業(yè)網(wǎng)站設(shè)計、上蔡網(wǎng)站維護等服務(wù)，公司將堅持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。

首先，談起災(zāi)難恢復(fù)，很多企業(yè)想過要做，但是一些情況下，做了災(zāi)難恢復(fù)方案，但是最終災(zāi)難發(fā)生的時候，卻沒有成功，其原因大概有三

1. 災(zāi)難恢復(fù)機制未生效

2. 沒有明確的災(zāi)難恢復(fù)計劃，操作人員未進行測試，導(dǎo)致延遲災(zāi)難恢復(fù)時間

3. 未實現(xiàn)自動化機制，災(zāi)難發(fā)生時需要手動操作，人員因為災(zāi)難發(fā)生無法進行操作

總結(jié)來看，不外乎兩點，1.災(zāi)難恢復(fù)計劃未經(jīng)過周密測試 2.災(zāi)難恢復(fù)機制未實現(xiàn)自動化機制

自動化技術(shù)是IT運維的利器，可以幫助我們節(jié)省很大效率，一些時候我們應(yīng)該去使用自動化，但也不應(yīng)該全部使用自動化，不過在災(zāi)難恢復(fù)領(lǐng)域，當我們真正去采用一個災(zāi)難恢復(fù)方式時，一定要越自動化越好，就是說，我這個災(zāi)難恢復(fù)方案，在恢復(fù)的時候，越少通過人為操作越好，理想情況下，我們應(yīng)該是實現(xiàn)既定的一套災(zāi)難恢復(fù)機制，災(zāi)難發(fā)生時一切自動化執(zhí)行，應(yīng)用恢復(fù)，如果災(zāi)難恢復(fù)過多依賴人為操作，則這不一定是個很好的方案，因為一旦真的災(zāi)難發(fā)生，人不一定能夠第一時間到現(xiàn)場恢復(fù)應(yīng)用。

所以，當我們要做異地數(shù)據(jù)中心時，一定要認真的坐下來，定好災(zāi)難恢復(fù)的計劃，定義災(zāi)難恢復(fù)計劃 我們首先要考慮以下幾個內(nèi)容

1. 災(zāi)難發(fā)生后，我們應(yīng)該做那些事，完成那些目標，如何盡快達成這些目標

2. 這些事情的優(yōu)先級順序是怎么樣的，我應(yīng)該先做那件，后做那件

3. 這些事情應(yīng)該有那些人做，是否每件事情都在由最合適的人做，每個步驟每個人是否有備崗

4. 執(zhí)行災(zāi)難恢復(fù)的具體步驟，應(yīng)該是形成標準化手冊。

大體內(nèi)容想好了后，我們就可以開始制定具體的災(zāi)難恢復(fù)計劃，一個完整的災(zāi)難恢復(fù)計劃至少應(yīng)該包含以下內(nèi)容

災(zāi)難恢復(fù)的范圍：定義災(zāi)難恢復(fù)的范圍，范圍越大，這里要寫的內(nèi)容就越多，數(shù)據(jù)中心，下面的服務(wù)器，上面的應(yīng)用，等等。

災(zāi)難恢復(fù)系統(tǒng)相依性：此處以業(yè)務(wù)系統(tǒng)級別為主，按照應(yīng)用系統(tǒng)級別來看每個系統(tǒng)的依賴性，便于我們制定恢復(fù)策略流程

災(zāi)難恢復(fù)策略：根據(jù)災(zāi)難恢復(fù)范圍和依賴性的定義，編寫恢復(fù)策略，每一個系統(tǒng)，每一個組件，災(zāi)難發(fā)生時應(yīng)該如何恢復(fù)，使用什么方式，應(yīng)該按照怎么樣的順序，如何操作，操作完成后如何驗證，如何規(guī)避風(fēng)險。

災(zāi)難恢復(fù)方式：具體災(zāi)難恢復(fù)策略執(zhí)行時要使用的方式：可以是手動，高可用群集，復(fù)制副本，備份，等等，盡可能采用業(yè)務(wù)系統(tǒng)支持的，人員熟悉的，自動化的方式。

緊急聯(lián)絡(luò)方式：災(zāi)難恢復(fù)干系人，領(lǐng)導(dǎo)負責(zé)人，災(zāi)難恢復(fù)操作人員，應(yīng)用驗證人員的聯(lián)系方式，確?？梢缘谝粫r間聯(lián)系到

災(zāi)難定期演練: 災(zāi)難恢復(fù)一大部分沒有成功的原因就是因為缺少定期演練，導(dǎo)致災(zāi)難發(fā)生時，既定的災(zāi)難恢復(fù)計劃失效，不能得到執(zhí)行，因此災(zāi)難定期演練事關(guān)重要，建議最少每年執(zhí)行一次災(zāi)難演練

災(zāi)難重現(xiàn) ：如果能做到這一點最好，每次災(zāi)難恢復(fù)演練后，或?qū)嶋H的災(zāi)難恢復(fù)后，要求操作人員，或災(zāi)難恢復(fù)小組，將此次災(zāi)難恢復(fù)過程進行記錄，事后回看，是否按照計劃執(zhí)行，還有那些可以優(yōu)化的地方，作為寶貴的知識。

以上，老王結(jié)合自己的一點學(xué)習(xí)，為大家總結(jié)的災(zāi)難恢復(fù)基本理論，之所以要寫這些呢，是因為老王看到很多企業(yè)明明想要做多地數(shù)據(jù)中心，想要做雙活數(shù)據(jù)中心，災(zāi)備數(shù)據(jù)中心，但是一拍腦袋就做了，沒有事先規(guī)劃好，也就沒有意義，希望看到的朋友可以有所收獲，在制定災(zāi)備數(shù)據(jù)中心的時候可以帶來一些幫助。

那么，我們今天主要談的是災(zāi)難恢復(fù)的方式，微軟對于災(zāi)難恢復(fù)的方式有很多，hyper-v復(fù)制，備份，WSFC群集，ASR，等等，都可以做災(zāi)難恢復(fù)的方式

其中我們今天關(guān)注的就是WSFC群集，WSFC用于多站點數(shù)據(jù)中心群集，它有一個好處，就是WSFC系統(tǒng)本身，是可以實現(xiàn)完全自動化的故障轉(zhuǎn)移機制的，只要群集得到正確的配置，故障發(fā)生時，WSFC會自動的進行切換，不需要人為干預(yù)，除非你WSFC群集上面跑的應(yīng)用，需要故障轉(zhuǎn)移后額外做配置。

WSFC真正開始對于多站點數(shù)據(jù)中心支持的是WSFC 2008，在2008時代，WSFC開始支持多子網(wǎng)的群集架構(gòu)，即是說，你可以北京兩個節(jié)點是10網(wǎng)段，上海兩個節(jié)點是20網(wǎng)段，也可以允許你創(chuàng)建一個群集，北京節(jié)點崩潰時候，應(yīng)用也可以漂移到20網(wǎng)段的上海上面繼續(xù)工作，而在2003則不可以，2003時代所有群集節(jié)點必須是同一子網(wǎng)。

實現(xiàn)多子網(wǎng)技術(shù)，最關(guān)鍵的是2008時代WSFC開始支持群集組網(wǎng)絡(luò)名稱依賴關(guān)系自定義了，對于一個群集組，我們可以讓網(wǎng)絡(luò)名稱對應(yīng)很多個子網(wǎng)的IP地址，這些不同子網(wǎng)IP地址可以是OR關(guān)系，只要其中一個能夠聯(lián)機注冊，那么應(yīng)用就可以正常提供服務(wù)。當故障轉(zhuǎn)移之后，在另外子網(wǎng)地址聯(lián)機注冊名稱，應(yīng)用切換到另外子網(wǎng)地址提供服務(wù)。

在WSFC 2008時代，雖然WSFC本身實現(xiàn)了對于多子網(wǎng)的支持，但是一些群集上面的應(yīng)用卻并不能很好的支持多子網(wǎng)，例如SQL 2005，SQL 2008，Hyper-V 2008實時遷移 ，雖然我們部署了多子網(wǎng)的群集，但是這些應(yīng)用卻并不支持多子網(wǎng)，依然也沒有意義，SQL2008R2，Hyper-V 2012后，一切都得到了改善。

在我們考慮WSFC多站點時，我們主要可以從以下幾個方面來看

1. 網(wǎng)絡(luò)

2. 仲裁

3. 存儲

網(wǎng)絡(luò)

對于WSFC多站點網(wǎng)絡(luò)，我們首先要思考，整個多站點環(huán)境采用什么樣的網(wǎng)絡(luò)架構(gòu)

1. 多子網(wǎng)

不同站點的節(jié)點，是否要使用不同子網(wǎng)，如果使用不同子網(wǎng)，上層應(yīng)用是否支持，是否會帶來額外的手動操作，多子網(wǎng)是對外網(wǎng)絡(luò)多子網(wǎng)，還是心跳網(wǎng)絡(luò)也要多子網(wǎng)，如果心跳網(wǎng)絡(luò)多子網(wǎng)如何通訊，是否需要添加靜態(tài)路由。

 2.延伸VLAN，網(wǎng)絡(luò)打通

不同站點的節(jié)點，網(wǎng)絡(luò)已經(jīng)打通，不需要各節(jié)點使用不同子網(wǎng)，所有節(jié)點都在一個子網(wǎng)，這種方案，對于群集，應(yīng)用來講最為省事，支持度最好，但是可能網(wǎng)絡(luò)人員會需要額外進行一些配置。

多站點群集網(wǎng)絡(luò)環(huán)境下的思考

1. 跨站點心跳檢測閥值

由于群集部署為多站點，其間網(wǎng)絡(luò)肯定會多或少會有一些延遲，如何調(diào)整心跳檢測閥值為最合適，這里的心跳檢測閥值為最關(guān)鍵，一旦由于網(wǎng)絡(luò)延遲，或網(wǎng)絡(luò)質(zhì)量，導(dǎo)致心跳檢測閥值達到，將會觸發(fā)故障轉(zhuǎn)移，因此務(wù)必要確保網(wǎng)絡(luò)質(zhì)量可靠，并根據(jù)實際的網(wǎng)絡(luò)延遲情況調(diào)整最為合適，最能準確反應(yīng)故障的檢測閥值，如果多站點網(wǎng)絡(luò)架構(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)絡(luò)連接是個問題，如果虛擬機在北京站點配置的靜態(tài)IP，是通過北京虛擬交換機出去的，到了上海子網(wǎng)不同，虛擬機原有IP將無法通信

因此，對于多站點環(huán)境下的VM，我們通常有以下幾種辦法

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

2. 針對虛擬機使用靜態(tài)IP，但是在虛擬機內(nèi)部編寫腳本，一旦檢測到網(wǎng)絡(luò)環(huán)境發(fā)生改變，即切換為目標靜態(tài)IP

3. 針對多站點環(huán)境使用延伸VLAN網(wǎng)絡(luò)架構(gòu)，虛擬機接入同一個子網(wǎng)

4. 針對虛擬機使用網(wǎng)絡(luò)虛擬化功能，讓虛擬機帶著IP遷移到不同站點

在Hyper-V復(fù)制中和ASR中又更好的解決方案，可以實現(xiàn)災(zāi)難恢復(fù)后自動設(shè)置虛擬機為目標IP，因此對于虛擬化的災(zāi)難恢復(fù)，如果考慮到多子網(wǎng)WSFC不太方便，您也可以選擇Hyper-V復(fù)制，或ASR。

4.多站點環(huán)境下客戶端連接延遲的問題

所謂客戶端連接延遲，即是說，群集完成了故障轉(zhuǎn)移，但是客戶端卻還是不能訪問應(yīng)用的這段時間，通常情況下，有兩種原因，1.群集故障轉(zhuǎn)移完成后應(yīng)用需要額外配置才可以提供訪問 2.DNS客戶端延遲

這里我們主要談的是DNS客戶端延遲的問題，什么是DNS客戶端延遲，以下圖為例，如果我們使用多站點多子網(wǎng)的網(wǎng)絡(luò)架構(gòu)，就會面臨這樣的問題，VCO在 SiteA是10網(wǎng)段IP，注冊到DNS，DNS把這條記錄復(fù)制到SiteB，SiteB客戶端訪問VCO以為地址就是10網(wǎng)段，當發(fā)生故障轉(zhuǎn)移，群集從SiteA轉(zhuǎn)移到SiteB，VCO的地址發(fā)生了改變，修改后的記錄復(fù)制到DNS Server 2，雖然群集完成了故障轉(zhuǎn)移，DNS記錄也得到了復(fù)制，但是SiteB的客戶端在1200秒內(nèi)還是沒辦法訪問轉(zhuǎn)移后的服務(wù)，因為DNS服務(wù)器上每個記錄都會有一個HostRecordTTL時間，這段時間內(nèi)，客戶端將使用緩存的地址，而不再請求新的地址，因此，這是我們需要考慮的地方。

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

1. 使用延伸VLAN的網(wǎng)絡(luò)架構(gòu)，都是同一個子網(wǎng)，不需要修改地址，不涉及到DNS緩存

2. 使用網(wǎng)絡(luò)抽象設(shè)備，讓群集網(wǎng)絡(luò)名稱始終注冊到一個抽象的網(wǎng)絡(luò)設(shè)備上面，然后網(wǎng)絡(luò)設(shè)備在把一個抽象的地址注冊到DNS，不論是Site A或是Site B，DNS Server始終面對抽象網(wǎng)絡(luò)設(shè)備的地址，不涉及到DNS緩存

3. 使用優(yōu)先本地轉(zhuǎn)移方案，配置應(yīng)用的首選所有者未本地節(jié)點，本地所有者失敗后，再轉(zhuǎn)移至跨站點

4. 優(yōu)化多子網(wǎng)下的DNS緩存時間和機制：2008時代WSFC針對于多站點，新增兩個屬性，分別是HostRecordTTL和RegisterAllProvidersIP，HostRecordTTL屬性可以修改DNS緩存的時間，默認是1200秒客戶端再和DNS請求新的地址，我們修改某個群集網(wǎng)絡(luò)名稱的這個時間為300秒，這樣客戶端就會更頻繁的和DNS服務(wù)器請求新的地址。微軟建議最短不要超過300秒，否則會帶來DNS服務(wù)器性能問題。RegisterAllProvidersIP屬性可以讓一個網(wǎng)絡(luò)名稱，同時注冊多個子網(wǎng)的地址，默認情況下網(wǎng)絡(luò)名稱對應(yīng)多個OR關(guān)系IP，同一個時間只會注冊一個地址，如果這個網(wǎng)絡(luò)的地址不可用，切換到另外站點，再注冊另外一個，而RegisterAllProvidersIP則是直接支持注冊所有站點的DNS記錄，但此功能要求應(yīng)用支持，SQL 2012之后開始支持此功能，應(yīng)用實際上會先嘗試連接一個IP，如果嘗試連不到，自動連另外一個地址。

仲裁

對于多站點群集來說，仲裁也是個值得思考的問題

1. 見證應(yīng)該放在那

對于多站點群集而言，見證最好不要放在多站點本身，因為這樣會存在一定的偏袒效應(yīng)，當發(fā)生網(wǎng)絡(luò)分區(qū)時，只要獲得見證的一方將會啟動提供服務(wù)

因此，建議對于多站的見證仲裁，最好放在第三個站點的文件見證，磁盤見證，或使用WSFC 2016的云見證功能，這樣不存在偏袒效應(yīng)，那個站點可以正常與第三個站點或云連接，即存活。

 2.見證網(wǎng)絡(luò)應(yīng)該如何設(shè)計

一個失敗的見證網(wǎng)絡(luò)設(shè)計是和心跳網(wǎng)絡(luò)，對外網(wǎng)絡(luò)設(shè)計在一起，例如，如果多站點的對外網(wǎng)絡(luò)線路徹底癱瘓，而見證連接網(wǎng)絡(luò)和對外網(wǎng)絡(luò)使用相同網(wǎng)絡(luò)鏈路，那么見證連接網(wǎng)絡(luò)也將會癱瘓，災(zāi)備站點可能因此沒辦法正常啟動，因此見證的連接一定要做到單獨使用一個網(wǎng)絡(luò)，防止因為網(wǎng)絡(luò)故障，而導(dǎo)致見證失去效果。

3.是否要搭建冷備站點

一些企業(yè)可能會有冷備站點的需求，即一個正常情況下，不對外提供服務(wù)的站點，只有當出現(xiàn)重大災(zāi)難時才會將其啟動，例如北京一個站點，天津一個站點，上海一個站點，我希望正常情況北京壞了，只要轉(zhuǎn)移到天津就好了，只有萬不得已的情況下才轉(zhuǎn)移到上海，這時候您就可以搭建一個冷備站點，操作有兩種選擇 1.取消上海站點的投票資格，這樣上海站點將無法獲得爭取資格，除非您再強制啟動上海站點，并為其賦予投票。 2.設(shè)置應(yīng)用可能所有者只有北京和天津，這樣也可以實現(xiàn)類似的效果，但是如果群集應(yīng)用少還可以，群集應(yīng)用過多，到時操作起來會有所麻煩，需要一個一個改。

4.是否要優(yōu)先本地站點轉(zhuǎn)移

當災(zāi)難發(fā)生時，如果未滿足一定閥值，我們其實沒必要啟動數(shù)據(jù)中心級別的災(zāi)難恢復(fù)的計劃，可以在數(shù)據(jù)中心內(nèi)部主機級別實現(xiàn)災(zāi)難恢復(fù)，這時可以配置應(yīng)用首選所有者為本地，本地沒辦法轉(zhuǎn)移再轉(zhuǎn)移至跨站點，或如果使用WSFC 2016可以利用應(yīng)用站點感知功能，實現(xiàn)應(yīng)用多主站點運作。

或者說數(shù)據(jù)中心內(nèi)部，針對于重要應(yīng)用，架設(shè)幾臺冷備機，平時關(guān)機，應(yīng)急時候開機使用，強制啟動，賦予投票，加入群集，但前提是見證磁盤存活，冷備機可以獲得最新群集配置數(shù)據(jù)庫。

5.腦裂或少數(shù)站點情況如何處理的操作規(guī)范

在2008R2時代，如果我們部署多站點架構(gòu)，很容易碰見網(wǎng)絡(luò)問題而導(dǎo)致群集出現(xiàn)腦裂，2012開始，微軟新增動態(tài)仲裁功能，在動態(tài)仲裁情況下，我們很少可以看見腦裂的情況，一般如果出現(xiàn)腦裂情況，我們會根據(jù)業(yè)務(wù)需要，選擇最合適的一個站點，強制啟動它，其它站點稍后啟動時需要經(jīng)過阻止啟動，以和強制啟動站點同步最新群集數(shù)據(jù)庫，因此，多站點架構(gòu)需要考慮腦裂情況下，如何評定那方為權(quán)威站點，應(yīng)該如何操作啟動權(quán)威站點。

WSFC 2012時×××始推出動態(tài)仲裁功能，即是說當群集為偶數(shù)節(jié)點，沒有見證的情況下，群集會始終自動去掉一個節(jié)點的投票，維持群集未奇數(shù)投票，當發(fā)生網(wǎng)絡(luò)分區(qū)時，被去掉節(jié)點投票的站點，將會下降，沒有被去掉節(jié)點投票的站點繼續(xù)提供服務(wù)，我們可以通過2012時代的LowerQuorumPriorityNodeID，或者2016時代的PreferredSite功能來指定，讓群集始終去掉某個節(jié)點的投票，最終達成控制站點啟動的效果，在多站點WSFC架構(gòu)也可以考慮該功能的使用，如果有多個站點，50 50節(jié)點數(shù)情況下希望某個站點始終不要獲勝。

還有一種情況即，少數(shù)節(jié)點數(shù)站點，當發(fā)生災(zāi)難恢復(fù)時，可能會有好幾個站點，有的站點有多數(shù)節(jié)點，有的站點有少數(shù)節(jié)點，正常情況下應(yīng)該是多數(shù)節(jié)點的站點獲勝，但是我們知道少數(shù)節(jié)點的站點才是我們最希望提供服務(wù)的站點，所以我們可以阻止多數(shù)節(jié)點啟動，強制啟動少數(shù)節(jié)點。這項功能需要事先規(guī)劃好，災(zāi)難恢復(fù)后應(yīng)用應(yīng)該首先在那些站點啟動，如果發(fā)生意外情況，理想站點是少數(shù)節(jié)點，我應(yīng)該如何操作。

存儲

對于多站點群集而言共享存儲放在那里是個問題，因為我們需要確保群集在災(zāi)難發(fā)生時可以完整的在另外一個站點啟動起來

如果群集的共享存儲放在兩端任何一個數(shù)據(jù)中心，當這個數(shù)據(jù)中心出現(xiàn)災(zāi)難時，另外一個站點也沒辦法繼續(xù)提供服務(wù)，因為聯(lián)系不到共享存儲

因此，要架設(shè)多站點群集，我們還需要考慮到共享存儲放置問題

通常情況下，多站點的災(zāi)備恢復(fù)，人們會對存儲實現(xiàn)復(fù)制機制

1. 基于設(shè)備級別存儲復(fù)制：直接選擇支持存儲復(fù)制的陣列，當存儲交付給群集節(jié)點時候就是被復(fù)制的，設(shè)備會基于存儲塊級別進行復(fù)制，如果在多站點實現(xiàn)這種設(shè)備級別復(fù)制，最好要有專門線路，因此會花費一筆不少的費用

2. 基于主機軟件級別存儲復(fù)制：可以使用類似于賽門鐵克，SteelEye DataKeeper Cluster Edition，或Windows Server 2016原生自帶的存儲復(fù)制，這類軟件會把多個節(jié)點操作系統(tǒng)上面的存儲構(gòu)建成一個邏輯，經(jīng)過復(fù)制的磁盤，交付給群集磁盤識別，現(xiàn)在越來越多人開始使用這種方案實現(xiàn)跨站點存儲的復(fù)制

3. 基于應(yīng)用級別存儲復(fù)制：直接使用類似于exchange dag，SQL ag等，應(yīng)用可以具備存儲復(fù)制技術(shù)

除了選擇合適的存儲復(fù)制機制，確保存儲持續(xù)可用外，我們還需要選擇存儲復(fù)制的方法

使用同步復(fù)制或異步復(fù)制

使用同步復(fù)制，不會丟失數(shù)據(jù)，每次寫入要求會確保同時寫入兩個站點存儲，才會完成，容易帶來應(yīng)用延遲，對網(wǎng)絡(luò)性能要求高。

使用異步復(fù)制，有可能會丟失數(shù)據(jù)，每次寫入請求只寫入到所在站點即結(jié)束，稍后再復(fù)制到其它站點，這樣應(yīng)用不會感覺到延遲，復(fù)制稍后會在后臺一點一點進行，對網(wǎng)絡(luò)性能要求不高，但可能還沒復(fù)制過去時發(fā)生災(zāi)難，而導(dǎo)致數(shù)據(jù)丟失。

在實際環(huán)境中，老王看到大部分企業(yè)還是在使用同步復(fù)制，以確保數(shù)據(jù)的完整性

很多人會考慮到DFS復(fù)制，實際上，微軟的DFS復(fù)制的適用場景是信息工作組，用于存放視頻，文件，圖片，等資料，對于群集，或者VMM的庫，DFS則并不適合，因為DFS只會復(fù)制關(guān)閉后的數(shù)據(jù)，如果我們的群集里面有虛擬機，數(shù)據(jù)庫，這些不會關(guān)閉的文件，DFS是不會復(fù)制的

以上老王從網(wǎng)絡(luò)，仲裁，見證的角度，來為大家講解了下WSFC多站點需要考慮的點，希望可以為感興趣的朋友帶來收獲