VMware vCenter站点恢复管理器(SRM)可以作为实施虚拟化环境灾难恢复(DR)计划的一个有效工具它可以在数据中心和灾难恢复站点之间实现自动化故障转移，在不中断生产环境的情况下对故障转移计划进行测试。
对于关键业务环境必不可少：它可以保证应用程序的正常运行时间并减少灾难恢复计划的测试 但是如果在实际部署SRM之前没有对一些关键因素进行考虑，你可能会遇到各种各样的问题事实上，安装VMware SRM是实施SRM的最后一步，在你理解和解决各种各样的问题之后，才应该进行部署。
这篇文章列出了三个特别注意事项：虚拟机(VM)布置、应用程序依赖关系和全面的灾难恢复计划第一部分我们先来看虚拟机布置 虚拟机布置 对于VMware SRM，简单地将所有的虚拟机存储在一个SAN当中是远远不够的。
对于成功的SRM部署，虚拟机在存储区域网络(SAN)中的位置也是十分重要的 为什么虚拟机位置十分重要?首先，虚拟机位置可以影响SAN的复制VMware SRM依赖于SAN提供的复制技术VMware SRM不能管理或者提供这种技术;它需要的只是其可用、恰当配置和可操作性。
大多数SAN复制技术在逻辑单元号(LUN)层进行复制，意味着只能以整个LUN决定是是否复制这样的结果是，组织必须确保需要通过VMware SRM 保护的虚拟机被存放于同一个可被复制的LUN当中(否则SRM将不能提供保护)。
一些组织可能会在第一次安装和配置SAN复制时考虑解决虚拟机放置问题如果没有，就需要在安装SRM之前解决这个问题幸运的是，你可以使用VMwareStorage VMotion实现在没有宕机的情况下将虚拟机在数据存储间进行迁移。
其次，虚拟机位置重要的原因是VMware SRM在操作时需要同时移动整个LUN(或者 数据存储)在SRM故障转移过程中，有些虚拟机不能同时进行移动，就需要将它们放置于不同的 数据存储当中只有当灾难恢复过程中，位于同一个 数据存储的所有虚拟机可以同时进行故障转移的情况下，才可以将虚拟机放置于同一个 数据存储当中。
同样，Storage VMotion可以在没有产生宕机的情况下将虚拟机移动到恰当的 数据存储之中 为了解决这个注意事项，组织需要在文档中明确规定虚拟机在SAN中的存储位置一旦位置被确定下来，就需要对一些虚拟机进行迁移，比如将虚拟机移动到可复制的LUN之中，实现通过VMware SRM进行保护。
直到SRM实施过程中才会进行另一部分必要的迁移拥有这些文档可以简化之后的迁移过程 应用依赖关系 必须完全理解应用程序的依赖关系并且将其记载在文档之中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时，虚拟化部门会发现这个过程不再复杂，项目当中也不会包含太多的任务，其实原本就应该这样。