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

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

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

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

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

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

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