VMware vCenter站点恢复管理器（SRM：Site Recovery Manager）是用于虚拟化工作环境中灾难恢复（DR：Disaster Recovery）一个非常有用的工具。SRM可以自动在数据中心和灾难恢复站点之间自动化故障转移，也可以在不中断生产的环境下测试故障转移计划。消除故障停机时间不仅仅是为了得到一个完美的关键任务工作环境，还保证应用程序正常工作时间，同时也缓解恢复计划的测试。

　　但是在部署SRM之前首先需要考虑一些关键问题，否则可能遇到无数难缠问题。事实上，安装VMware SRM通常是实施SRM的最后一个环节。最好在理解并且可以解决大量问题之后再部署SRM。TechTarget中国的特约作者Scott Lowe在本文中阐述了三个关键相关问题：虚拟机布局、应用程序相关性及综合灾难恢复计划。

　　虚拟机布局

　　把虚拟机部署在SAN上，对于VMware SRM来讲还不够。对于成功的SRM部署，虚拟机部署在存储区域网络（SAN：Storage Area Network）的具体位置也是非常重要的。至于虚拟机位置之所以重要主要有以下几点：

　　首先，虚拟机的位置决定SAN复制。VMware SRM依赖于一项受支持的SAN复制技术，但是VMware SRM自身并不管理和操作该项技术，而仅仅是要求这项技术合理配置和正常运行。许多SAN复制技术都在一个逻辑单元号（LUN：Logical Unit Number）级别进行，也就是说复制对象是整个LUN，要么复制，要么不复制。所以企业必须确保那些需要通过VMware SRM提供保护的虚拟机部署在一个可以被复制的LUN上，否则SRM就不能够提供保护。也有一些企业在初次安装和配置SAN复制时就已经很好地解决了虚拟机布局这个问题。如果没有的话，就需要在VMware SRM安装之前来做这个工作。幸运的是，可以使用VMware Storage VMotion技术帮助虚拟机在不同数据存储之间迁移，不会有任何宕机时间。

　　其次，虚拟机布局重要的另外一个原因是VMware SRM的操作是一次性移动一个完整LUN（数据存储）。在SRM宕机备份中不应该移到一起的那些虚拟机不能部署在同一个数据存储上，在灾难恢复事件中，一个数据存储中同时做宕机备份的所有虚拟机如果可以相互接受，那么这些虚拟机才可以部署在同一个数据存储中。另外，如果要求把虚拟机迁移到一个合适的数据存储中而不能发生宕机，Storage Vmotion就变得非常有用。

　　为了应对这问题，企业必须把SAN上的虚拟机位置文档化。在这些工作完成之后，一些虚拟机迁移工作就变得比较明显了，例如为了寻求使用VMware SRM保护把虚拟机迁移到一个可复制LUN上的需求等。其它一些必要的迁移可能不紧急，在后期的实施过程中完成就可以。使用这样的文档可以简化比较紧急的迁移任务。

　　应用程序相关性

　　必须完整理解和正确归档应用程序的相关性。VMware SRM可能改变一个受保护虚拟机的IP地址，但是却不能处理应用程序相关性。IT部门如果不理解应用程序相关关联性而实施VMware SRM的话，注定会失败。

　　如果对应用程序相关性没有清醒的认识，虽然可能会有部分虚拟机受到VMware SRM的保护，然而还有一些为受保护虚拟机提供主机服务的虚拟机，这些虚拟机仍然没有受到保护。因此，例如在做灾难恢复的时候，受保护虚拟机通过宕机备份到一个目的恢复站点上。但是由于没有相关性，应用程序就不能正确地运行。要么是虚拟机以错误顺序启动，相关应用程序试图在底层服务可用之前运行，这些底层服务来自其它虚拟机。通过上述两种情况，了解应用程序是如何相互影响之后，IT部门就会认真进行VMware SRM的合理部署来调整相关性。

　　有些应用程序相关性会更明显。例如，一个企业在不对底层数据库服务器做宕机备份的情况下，不会对上层应用程序或者中间件服务器做宕机备份。但是更微妙的相关性会被忽视，千万不要忘记考虑非虚拟化相关性。

　　为了解决这个问题，企业应该综合考虑应用程序相关性和相互影响的映射关系。有了这种相关性映射关系，企业可能会发现为了满足上述提到的第一个问题，还有一些虚拟机的迁移工作非常必要，需要对SAN复制的配置做些修改。但至少企业会在VMware SRM安装配置后，就准备着手通过正确次序运行的应用程序创建一个灾难恢复计划。

　　综合灾难恢复计划

　　这个问题看起来可能很明显，要知道VMware SRM仅仅处理数据中心虚拟化部分的问题。因此针对其它物理数据中心还需要一个实实在在的灾难恢复计划。虽然VMware SRM提供了非虚拟化资源整合功能，例如运行一段脚本程序来控制一段网络设备的能力，但还是要对VMware SRM有个清楚认识：VMware SRM只是一个更大灾难恢复战略的一部分。企业仍然必须定义灾难恢复事件，如一个完善的宕机备份事件的主要组成部分；企业也需要定义和处理一个灾难事件相关的各种各样的角色。另外，VMware SRM需要企业及时提供这些定义，以便对其模型化来完善灾难恢复战略。如果一个企业试图把某项技术作为战略的话，那么就会发现自身在苦苦挣扎着以达到项目的成功标准。

　　另外一个角度来看，如果企业尽力去解决上述提到的所有这些问题，那么该企业VMware SRM实施工作的进展就会比较顺利。并且在安装VMware SRM的时候，虚拟化IT部门就会发现这只是整个项目中最不复杂难懂的一项工作，其实这个工作本来也就不复杂。