在部署VMware vCenter站点恢复管理器时需要注意三大事项：虚拟机布置、应用程序依赖关系和全面的灾难恢复计划。第一部分《部署VMware vCenter SRM时的三大注意事项：虚拟机布置》我们介绍了虚拟机在存储区域网络（SAN）中的位置的重要性。这里继续介绍另外两个注意事项。

应用依赖关系

必须完全理解应用程序的依赖关系并且将其记载在文档之中。VMware SRM可能会改变被保护虚拟机的IP地址，但是其不能解决应用程序依赖关系的问题。计划实施VMware SRM的IT部门如果没有对应用程序依赖关系进行理解，那么注定是要失败的。

在完全了解应用程序的依赖关系之后，一些虚拟机可以由VMware SRM进行保护，但是其他一些为被保护虚拟机提供服务的机器仍然处于没有保护的状态。所以，如果当灾难恢复发生时，被保护的虚拟机虽然被移动到了指定的故障转移站点，但是由于失去依赖的服务，应用程序运行时还是会发生错误。或者，虚拟机以错误的顺序启动了，在从其他虚拟机需要的底层服务启动之前，具有依赖性的应用程序就尝试启动了。在这两种情况下，了解应用程序间如何相互作用可以帮助IT部门恰当地部署VMware SRM来修复依赖性问题。

一些应用程序的依赖性更加明显。比如在一个组织当中，通常情况下应用程序或者中间件服务器通常要和底层数据库服务器同时进行故障转移。但是更加微小的依赖关系容易被忽视。不要忘记考虑非虚拟化环境中的依赖关系。

为了解决这个顾虑，组织应该详细地列出应用程序间的依赖关系和相互作用图，拥有了依赖关系图之后，组织可能会发现为了满足第一个注意事项，可能需要将其他的虚拟机进行迁移。组织可能还需要改变SAN的复制配置。但是完成VMware SRM的安装和配置之后，至少组织可以准备创建灾难恢复计划，而保证应用程序能够以正确的顺序进行启动了。

详尽的灾难恢复计划

尽管这可能是显而易见的，但是仍然要注意SRM只能用于数据中心的虚拟化部分。所以你仍然需要一个为数据中心余下的物理机器制定一个完善的灾难恢复计划。VMware SRM可以为非虚拟化资源提供集成特性——比如运行脚本来控制网络设备——VMware SRM的正确定位为：灾难恢复策略中的一个组成部分。组织仍然必须定义灾难恢复事件，比如怎样才能构成一个合格的灾难恢复事件，组织仍然必须定义多个角色来表明灾难事件中的任务分配。VMware SRM不能替换这些角色，但是VMware SRM需要组织这些定义来使得这项技术可以适用于灾难恢复策略。寻求以技术作为策略的组织最后会发现很难达到项目的成功准则。

另一方面，如果一个组织能够认真地检查所有这些注意事项，那么其VMware SRM的实施过程将会十分顺利。安装VMware SRM时，虚拟化部门会发现这个过程不再复杂，项目当中也不会包含太多的任务，其实原本就应该这样。