在災(zāi)備領(lǐng)域，一個越來越明顯的趨勢就是云提供商開始采用負(fù)載均衡數(shù)據(jù)中心而非冷熱通道型數(shù)據(jù)中心。一些企業(yè)正在部署私有云來平衡承擔(dān)災(zāi)備需求的各數(shù)據(jù)中心間的負(fù)載。假如某個數(shù)據(jù)中心遭遇災(zāi)難，其他數(shù)據(jù)中心便可接續(xù)運(yùn)營。

但是負(fù)載均衡數(shù)據(jù)中心也存在著諸多挑戰(zhàn)。例如，要跟蹤某個應(yīng)用場景基礎(chǔ)設(shè)施的各種配置就非常棘手。每個應(yīng)用都會創(chuàng)建服務(wù)器的名稱，選擇開放的IP地址，解決DNS映射，定義物理和虛擬服務(wù)器，創(chuàng)建防火墻規(guī)則，定義SAN和NAS配置，實(shí)施負(fù)載均衡規(guī)則，定義數(shù)據(jù)庫集群。

所有這些要素都存在于每一環(huán)境的每一應(yīng)用中，例如開發(fā)、測試和生產(chǎn)環(huán)境。這些應(yīng)用配置中有很多是由多個Web應(yīng)用來維護(hù)的。而這些維護(hù)型應(yīng)用均未集成，因此元數(shù)據(jù)應(yīng)用配置也自然沒有集中化。更糟糕的是，很多管理上的變更都是在產(chǎn)品實(shí)施期間出于各種急迫的理由做出的，例如SAN子系統(tǒng)的各種變更，就未曾被變更管理系統(tǒng)所捕獲。因此說，元數(shù)據(jù)庫中的配置數(shù)據(jù)往往也是過時的。

如果能有一個工具將某個數(shù)據(jù)中心的配置克隆到與其進(jìn)行負(fù)載均衡的其他數(shù)據(jù)中心那就好了。這一配置需要唯一的服務(wù)器名稱，和新的IP地址。如果其他數(shù)據(jù)中心崩潰，那么在其他數(shù)據(jù)中心所建立的對稱應(yīng)用模式也能及時提供必需的基礎(chǔ)設(shè)施服務(wù)。但考慮到需要配置的所有產(chǎn)品的有效參數(shù)排列，所以要創(chuàng)建這樣一種工具或者導(dǎo)航程序是相當(dāng)困難的。

所以，基礎(chǔ)設(shè)施配置元數(shù)據(jù)的集中管理至關(guān)重要。如果不對參數(shù)進(jìn)行集中管理，不對部署應(yīng)用的參數(shù)集進(jìn)行版本控制，那么它所支持的基礎(chǔ)設(shè)施就會隨著時間的推移而發(fā)生微小的變化。這些微小的變化都有可能會在主負(fù)載均衡數(shù)據(jù)中心和次負(fù)載均衡數(shù)據(jù)中心內(nèi)引起各種問題。如果配置數(shù)據(jù)未進(jìn)行版本控制，那么要想讓數(shù)據(jù)中心在某個變化直接導(dǎo)致生產(chǎn)失誤時再返回某個穩(wěn)定狀態(tài)就會非常困難。

另外，認(rèn)證體系架構(gòu)的各種關(guān)鍵要素也是十分必要的。企業(yè)應(yīng)制定策略，說明只有經(jīng)過測試的生產(chǎn)配置，例如在內(nèi)核軟件或操作系統(tǒng)上的虛擬機(jī)版本才可在數(shù)據(jù)中心內(nèi)進(jìn)行部署。只有特定版本的防火墻硬件才能在各種數(shù)據(jù)中心內(nèi)部署。另一個危險是缺少各種基礎(chǔ)設(shè)施組件的選項(xiàng)，例如單一來源的軟件或硬件。假如硬件存在某個常見漏洞，或者軟件存在bug，都有可能在多個數(shù)據(jù)中心引發(fā)重大失誤。

總而言之，企業(yè)可通過在負(fù)載均衡體系架構(gòu)中部署各種應(yīng)用來解決災(zāi)難恢復(fù)問題。但是這種方法無法防范人工失誤，尤其是配置失誤。企業(yè)可能會轉(zhuǎn)向一些經(jīng)過認(rèn)證的組件，例如特定的虛擬機(jī)，或者負(fù)載均衡，以避免某些因未經(jīng)測試的配置或缺少配置元數(shù)據(jù)的版本控制而出現(xiàn)的災(zāi)難。配置元數(shù)據(jù)需要以集中方式存儲，并進(jìn)行版本控制，只有這樣才能在錯誤發(fā)生時讓應(yīng)用回歸到某個可信任的配置狀態(tài)。