上半部分《为VMware View虚拟桌面创建灾难恢复计划：你应该复制虚拟桌面吗？》帮助用户判定是否需要复制虚拟桌面，请继续看如何制定灾难恢复计划。

专用vs. 非固定虚拟桌面

　　如果你从灾难恢复的角度看待虚拟桌面，这会影响你选择最终用户将使用的虚拟桌面的类型以及最终用户体验。大多数虚拟桌面系统允许管理员为用户提供“专用”桌面（总是返回同一个桌面而且能够对桌面进行定制）或者“非固定”桌面（从不返回同一个桌面，而且桌面甚至会被破坏或者在使用后被重置）。

　　如果我们认为复制虚拟桌面的组成文件不是一个合理的策略，那么，就很难证明配置专用桌面的观点是合理的。这不过是给灾难恢复计划增加了一层复杂性；你必须包括用户配置以及用户数据。了解了这一情况后，我建议用户以如下方式构建最终用户环境，那就是不要把用户的配置以及数据保存在虚拟桌面中。虚拟桌面越是没有用户的特定数据就越好。

　　确实有一些高级用户需要定制的虚拟桌面，而且他们会多次使用定制的虚拟桌面。考虑到这些桌面无法运营会对业务带来很大影响，我们可能会区别对待这些虚拟桌面，将它们单独复制到灾难恢复站点。大多数情况下没有必要这么做，由于数据应该被放置在虚拟桌面系统的外部，而且万一发生灾难，只有数据才有价值——能够有效地对数据进行访问就可以了。

　　下一个问题关注虚拟桌面运行所需要的基础设施服务器。在VMware View环境中，包括了两个主要的服务器——连接服务器以及安全服务器。连接服务器扮演代理角色，用于查找用户虚拟桌面，而安全服务器为数据通过公司的防火墙提供帮助。

　　乍一看要做的最简单的事儿似乎就是将这些角色复制到恢复站点，但是由于各种原因，这么做可能存在问题。每个连接的服务器私下嵌入到了现有的vCenter以及vSphere环境中。硬路径位于被保护站点vCenter的对象中而且是唯一的。只在灾难恢复站点开启连接服务器实际上无法实现任何目的，因为你所拥有的只是指向孤立vCenter（在灾难中已经丢失了）的连接服务器，以及已经被破坏的虚拟桌面池。

　　考虑到上述情况，看来“镜像”受保护站点View服务器的配置，在灾难发生时，保证连接服务器的复制集合处于运行就绪状态更为明智。这么做的不利因素是在受保护站点执行的所有的管理操作都会在恢复站点执行——这增加了管理负担。此时除了恢复所有重要的模板以及父虚拟机之外，VMware SRM不会为VMware View环境的自动化恢复带来帮助。

VMware View以及SRM未来会整合吗？

　　VMware View以及VMware SRM在未来几年将会走向何方以应对上述挑战？位于VMware View中心的是微软活动目录应用模式（ADAM，然而最近重命名为了微软活动目录轻量级目录服务，也就是AD LDS）。AD LDS/ADAM将在一台连接服务器上执行的所有管理任务复制到连接服务器“replica”。展望下未来，我认为我们可能会看到VMware依赖该系统来为VMware View制定类似VMware SRM的灾难恢复计划。

　　它的工作方式类似于：VMware View Server位于同一个组中，但是却位于两个站点—被保护站点以及恢复站点。将会专门创建新的View角色来接收来自被保护站点的View服务器更新。简单来讲，将会有一台热备份的View服务器，但是只有在运行VMware SRM恢复计划时才是可见的。

　　与此同时，如果你有vSphere 4/View 4环境而且关注虚拟桌面的灾难恢复，那么可以参考各类存储厂商提供的有关详细描述灾难恢复蓝图的文章。到目前为止，最为吸引人的是由EMC在2009年8月所编写的《针对VMware View的EMC业务连续性》方案。