最近，云提供商利用负载平衡的方法替代冷热数据中心来处理数据中心灾难恢复的趋势正日益增长。企业部署私有云，需要特别注意考虑其数据中心灾难恢复的需求与负载平衡。必须保证即使一家数据中心遭受灾难，其他数据中心仍将正常经营，尽管其运营能力可能会有所下降。

但仍然存在挑战。跟踪一款应用程序在各种基础设施的配置是很困难的。每一款应用程序都会创建服务器名称、选择开放的IP地址、DNS地址域名映射、定义物理和虚拟服务器、创建防火墙规则、定义SAN与NAS配置，实现负载平衡规则，定义数据库集群。

一款应用程序的所有这些元素都存在于每一个环境，如开发环境、测试环境及生产环境。许多应用程序的配置均由多个网络应用程序维护。维护应用程序并不集中，因此元数据应用程序配置也不集中。更糟的是管理的改变是基于产品实施时间的紧迫性，如SAN子系统，这没有反映在变化管理系统中。因此，数据往往是是过时的。

如果能够有一款工具将配置在一家数据中心的负载平衡复制到另一家数据中心将是好的。配置需要单独的服务器的名称、新的IP地址。其可以将模型的对称性的应用到其他数据中心，同时，如果其他数据中心失败，提供必要的基础设施。但考虑到所有可配置产品的有效置换，创建一个工具或向导将是很困难的。

所以，基础设施的配置元数据的集中是至关重要的。没有集中的参数和部署应用程序的版本，其配套设施将随时间推移变小。小型配置的变化可能会导致数据中心首级和次级的负载平衡问题。如果没有配置数据版本，当变化导致即时操作失误，要返回数据中心到稳定状态可能是非常困难的。

其还指出认证体系结构的关键要素。企业应该有一个政策，规定只测试产品的配置，如虚拟机的内核软件或操作系统的版本可在数据中心内部署。只有特定版本的防火墙硬件可以部署在不同的数据中心。另一个危险是缺乏选择，如各种基础设施组件只有单一来源的软件或硬件。如果硬件或软件错误有一个共同的缺陷，则可能会导致多个数据中心的戏剧性失败。

总之，企业可以通过部署在负载平衡架构的应用程序解决灾难恢复问题。但是，这并不能防止人为的错误，特别是配置错误。企业可以转向认证的零组件，如特定的虚拟机或负载平衡器，以避免一些由于一个未经测试的配置或缺乏配置元数据的版本造成灾害。配置元数据需要存储在一个集中的方式和版本中，使应用程序可以回落到一个值得信赖的配置，以防出现错误。