故障切換到遠(yuǎn)程站點(diǎn)是一項(xiàng)成熟的技術(shù)，云存儲也是一項(xiàng)成熟的技術(shù)。但是如果用戶們在遇到故障后想把虛擬環(huán)境切換到云端，他們就面臨獨(dú)特的挑戰(zhàn)。

雖然這兩個(gè)過程都用到復(fù)制，但云故障切換要雙將備份內(nèi)容復(fù)制到云端以便之后恢復(fù)復(fù)雜得多。故障切換過程使用云作為輔助的災(zāi)難恢復(fù)站點(diǎn)。備用服務(wù)器接手處理出現(xiàn)故障的虛擬機(jī)環(huán)境，確保應(yīng)用程序性能不受影響，然后等問題解決后，再切換回到主數(shù)據(jù)中心。出現(xiàn)故障后切換到云的過程可能是自動化，也可能是人工的，各自有其優(yōu)缺點(diǎn)。

不妨定義一些細(xì)節(jié)。我們在此談?wù)摰氖翘摂M機(jī)到虛擬機(jī)。使用裸機(jī)恢復(fù)(BMR)技術(shù)，將內(nèi)部物理服務(wù)器故障切換到云端物理服務(wù)器在技術(shù)上可行的，但是這不切實(shí)際。很少有云災(zāi)難恢復(fù)廠商支持這么做，因?yàn)樗鼈兓谔摂M服務(wù)器技術(shù)。虛擬機(jī)架構(gòu)讓用戶得以避免在輔助數(shù)據(jù)中心維護(hù)相同的硬件這個(gè)問題，這是基于云的災(zāi)難恢復(fù)解決方案的一大賣點(diǎn)。

我們還會探討公有云環(huán)境下的故障切換。雖然故障切換在公司自身擁有的私有云中肯定可行，但是它有悖于公有云提供的易于擴(kuò)展這個(gè)初衷。

你需要了解的方面

為何故障切換到遠(yuǎn)程站點(diǎn)是一項(xiàng)成熟技術(shù)，而故障切換到云端卻不是?云本身是區(qū)別所在。

毫無疑問，云因靈活擴(kuò)展、經(jīng)濟(jì)實(shí)惠而很吸引人;一旦故障切換站點(diǎn)經(jīng)過了測試，而且很全面，維護(hù)起來就比較簡單。就虛擬環(huán)境故障切換而言，你不需要像在遠(yuǎn)程站點(diǎn)那樣非要維護(hù)幾乎相同的硬件，能夠獲得近乎無限擴(kuò)展的好處。然而，將生產(chǎn)環(huán)境數(shù)據(jù)故障切換到云端也確實(shí)存在諸多挑戰(zhàn)。

保持服務(wù)級別

單單備份數(shù)據(jù)的風(fēng)險(xiǎn)相當(dāng)?shù)?。公有云的可靠性很高，可用性也很高，而且因分布式操作而在不斷提高。但是說到關(guān)鍵的業(yè)務(wù)應(yīng)用程序，備份和存儲引起的云存儲風(fēng)險(xiǎn)就會急劇加大。由于通過互聯(lián)網(wǎng)傳輸數(shù)據(jù)速度緩慢，在恢復(fù)時(shí)間目標(biāo)(RTO)和恢復(fù)點(diǎn)目標(biāo)(RPO)可以接受的情況下，將虛擬化生產(chǎn)數(shù)據(jù)遠(yuǎn)程故障切換到云端是相當(dāng)新穎的做法。

如果你有必要的帶寬，將服務(wù)器映像備份到云端相當(dāng)簡單。但是在故障切換場景下在云端運(yùn)行那些應(yīng)用程序卻完全不同。首先，VMware和Hyper-V需要各自不同的故障切換域;此外，特定的應(yīng)用程序可能需要配置不同的域，以便為故障切換的應(yīng)用程序提供合適的服務(wù)級別。

將應(yīng)用程序交給云端災(zāi)難恢復(fù)站點(diǎn)之前先要進(jìn)行測試。亞馬遜、谷歌、Azure及其他大型公有云都能滿足以較低服務(wù)提供較高性能的需要，但是你需要測試自己的帶寬和配置。

要在帶寬方面投入

帶寬在使用云端作為災(zāi)難恢復(fù)站點(diǎn)方面起到了重要作用。虛擬化數(shù)據(jù)中心會生成龐大快照，而且是大量的龐大快照。想有效地管理云端故障切換災(zāi)難恢復(fù)站點(diǎn)，有效管理快照是關(guān)鍵所在，如果你在考慮一款可以縮短數(shù)據(jù)傳輸時(shí)間的云網(wǎng)關(guān)產(chǎn)品，更是如此?？煺赵诘土髁凯h(huán)境下完全沒有問題，但是在大容量復(fù)制環(huán)境下，快照會成為瓶頸。

無論你是否使用云網(wǎng)關(guān)，只需復(fù)制變化的增量數(shù)據(jù)，并實(shí)行重復(fù)數(shù)據(jù)刪除和壓縮。如果你的服務(wù)級別允許，還需要避免不斷地復(fù)制快照。不斷或近乎不斷地復(fù)制快照會耗用以太網(wǎng)資源，更不用說耗用互聯(lián)網(wǎng)帶寬了。不管怎么樣，高效的快照算法對成功的云端故障切換而言必不可少。

安全性和可用性

另一個(gè)挑戰(zhàn)是安全性。為云端備份和歸檔數(shù)據(jù)確保安全很重要;保護(hù)及訪問生產(chǎn)數(shù)據(jù)更是重要得多。你同時(shí)需要可靠性和可用性：之所以需要可靠性，是因?yàn)槟菢釉品?wù)提供商不會丟失你的數(shù)據(jù);之所以需要可用性，是因?yàn)槟菢幽阍谛枰L問自己的數(shù)據(jù)時(shí)，可以隨時(shí)訪問。與服務(wù)提供商一起敲定服務(wù)級別。雖然你支付的費(fèi)用高于簡單的備份和恢復(fù)，但是說到應(yīng)用程序，你不希望有任何閃失。

在加密級別方面做好調(diào)查工作，并且決定要不要加密靜態(tài)數(shù)據(jù)(可能需要)和傳輸中數(shù)據(jù)(可能需要，也可能不需要)。另外要留意多租戶問題。公有云是一種大規(guī)模的多租戶環(huán)境。一個(gè)風(fēng)險(xiǎn)是，如果其他租戶突然耗用大量資源，你的性能就會下降。你最不希望看到的一幕是，就在你的應(yīng)用程序從云端災(zāi)難恢復(fù)站點(diǎn)啟動運(yùn)行時(shí)，別人的突然使用搶占了你的資源。要弄明白公有云提供商和災(zāi)難恢復(fù)廠商如何保護(hù)你，遠(yuǎn)離其他租戶及系統(tǒng)故障的影響。

另一個(gè)潛在問題出現(xiàn)在自動化故障切換上。災(zāi)難恢復(fù)自動化通常來說是關(guān)鍵災(zāi)難恢復(fù)的一個(gè)最佳實(shí)踐，但由于所謂的腦裂事件(split-brain event)，它也不是什么“靈丹妙藥”。當(dāng)虛擬機(jī)層面的錯(cuò)誤引發(fā)自動化故障切換時(shí)，盡管虛擬機(jī)實(shí)際上并未處于故障狀態(tài)，就會出現(xiàn)腦裂事件。2015年，出現(xiàn)故障后自動切換到云端在監(jiān)測路徑和事件方面有所改進(jìn)，但這仍是需要留意的一個(gè)問題。就許多情況而言，一旦虛擬機(jī)出現(xiàn)故障，立即提醒IT團(tuán)隊(duì)，這也許是比純粹自動化更合理的解決方案。

動態(tài)云

云是個(gè)動態(tài)環(huán)境，不過成功的故障切換有賴于用戶能夠找到遷移后的應(yīng)用程序及其數(shù)據(jù)。廠商提供的一種選擇就是，使用基于云的集群作為故障切換災(zāi)難恢復(fù)站點(diǎn)。

微軟Windows Server使用集群方法作為內(nèi)部站點(diǎn)與遠(yuǎn)程站點(diǎn)之間一種成熟可靠的災(zāi)難恢復(fù)技術(shù)。然而，基于Windows的集群需要訪問活動目錄。這就意味著IT人員需要將活動目錄擴(kuò)展到云端，而這又需要網(wǎng)絡(luò)活動目錄與云活動目錄不斷同步。

一種更常見的方法是，將虛擬機(jī)及其數(shù)據(jù)復(fù)制到云端，那樣萬一內(nèi)部環(huán)境出現(xiàn)故障，用戶可以被透明地重定向至云端。這種架構(gòu)的缺點(diǎn)在于需要解析IP地址和DNS記錄的變更，以便適應(yīng)出現(xiàn)變化的生產(chǎn)站點(diǎn)。

如今，大多數(shù)服務(wù)提供商和廠商為你傳輸變更內(nèi)容，或者提供更容易這么做的工具。比如說，Amazon Route 53的DNS Web服務(wù)就可以為開發(fā)人員和用戶使這兩種類型的變更實(shí)現(xiàn)自動化，因而更容易在云端執(zhí)行故障切換過程。解決地址問題的另一個(gè)辦法就是，新廠商從頭開始開發(fā)基于云的災(zāi)難恢復(fù)解決方案。Zadara公司推出了虛擬專用存儲陣列(VPSA)，在AWS及其他云服務(wù)提供商的平臺上，使用公有云提供企業(yè)級災(zāi)難恢復(fù)服務(wù)，并且使地址動態(tài)變更實(shí)現(xiàn)自動化。

　　為何操這份心?因?yàn)橹档靡蛔?/strong>