最近，云提供商利用負載平衡的方法替代冷熱數(shù)據(jù)中心來處理數(shù)據(jù)中心災難恢復的趨勢正日益增長。企業(yè)部署私有云，需要特別注意考慮其數(shù)據(jù)中心災難恢復的需求與負載平衡。必須保證即使一家數(shù)據(jù)中心遭受災難，其他數(shù)據(jù)中心仍將正常經(jīng)營，盡管其運營能力可能會有所下降。

但仍然存在挑戰(zhàn)。跟蹤一款應用程序在各種基礎設施的配置是很困難的。每一款應用程序都會創(chuàng)建服務器名稱、選擇開放的IP地址、DNS地址域名映射、定義物理和虛擬服務器、創(chuàng)建防火墻規(guī)則、定義SAN與NAS配置，實現(xiàn)負載平衡規(guī)則，定義數(shù)據(jù)庫集群。

一款應用程序的所有這些元素都存在于每一個環(huán)境，如開發(fā)環(huán)境、測試環(huán)境及生產(chǎn)環(huán)境。許多應用程序的配置均由多個網(wǎng)絡應用程序維護。維護應用程序并不集中，因此元數(shù)據(jù)應用程序配置也不集中。更糟的是管理的改變是基于產(chǎn)品實施時間的緊迫性，如SAN子系統(tǒng)，這沒有反映在變化管理系統(tǒng)中。因此，數(shù)據(jù)往往是是過時的。

如果能夠有一款工具將配置在一家數(shù)據(jù)中心的負載平衡復制到另一家數(shù)據(jù)中心將是最好的。配置需要單獨的服務器的名稱、新的IP地址。其可以將模型的對稱性的應用到其他數(shù)據(jù)中心，同時，如果其他數(shù)據(jù)中心失敗，提供必要的基礎設施。但考慮到所有可配置產(chǎn)品的有效置換，創(chuàng)建一個工具或向?qū)�將是很困難的。

所以，基礎設施的配置元數(shù)據(jù)的集中是至關重要的。沒有集中的參數(shù)和部署應用程序的版本，其配套設施將隨時間推移變小。小型配置的變化可能會導致數(shù)據(jù)中心首級和次級的負載平衡問題。如果沒有配置數(shù)據(jù)版本，當變化導致即時操作失誤，要返回數(shù)據(jù)中心到穩(wěn)定狀態(tài)可能是非常困難的。

其還指出認證體系結構的關鍵要素。企業(yè)應該有一個政策，規(guī)定只測試產(chǎn)品的配置，如虛擬機的內(nèi)核軟件或操作系統(tǒng)的版本可在數(shù)據(jù)中心內(nèi)部署。只有特定版本的防火墻硬件可以部署在不同的數(shù)據(jù)中心。另一個危險是缺乏選擇，如各種基礎設施組件只有單一來源的軟件或硬件。如果硬件或軟件錯誤有一個共同的缺陷，則可能會導致多個數(shù)據(jù)中心的戲劇性失敗。

總之，企業(yè)可以通過部署在負載平衡架構的應用程序解決災難恢復問題。但是，這并不能防止人為的錯誤，特別是配置錯誤。企業(yè)可以轉向認證的零組件，如特定的虛擬機或負載平衡器，以避免一些由于一個未經(jīng)測試的配置或缺乏配置元數(shù)據(jù)的版本造成災害。配置元數(shù)據(jù)需要存儲在一個集中的方式和版本中，使應用程序可以回落到一個值得信賴的配置，以防出現(xiàn)錯誤。