最近，我前往VMware位于英国的公司总部参观。我正在写一本关于VMware View的书，所以在VMware公司总部采访他们的系统工程师。我还知道其中一名开发VMware SRM的工程师也在那儿，因此我两天行程中的另一项任务就是调查能够用于虚拟桌面的灾难恢复策略。你可能知道我已经写了两本有关VMware SRM的书，而且这两款产品都是我所关注的，所以我热衷于了解这两个产品可能的交互之处。

　　由于我的客户在涉足虚拟桌面领域，所以我还有另一个关注点：为使虚拟桌面免受数据中心发生的潜在灾难而带来的损失，应该在哪些方面将相关措施落实到位？

　　正如你所了解的那样，虚拟桌面的一个关键部分就是集中化，而集中化产生了依赖性，带来了相关的风险。具有讽刺意味的是，组织常把虚拟桌面作为灾难恢复战略的一部分。他们对我说，灾难发生时用户将连接远程的虚拟桌面。但是如果整个数据中心都发生了故障，那如何使用户连接到远程的虚拟桌面呢？

你应该复制虚拟桌面吗？

　　很明显，将虚拟桌面从被保护的站点（生产中心）复制到恢复站点（灾备中心）是对带宽以及磁盘空间的浪费。大多数虚拟桌面解决方案比如VMware View已经成熟到了能够快速从模板或者“链接克隆”创建新虚拟机的程度。这么说来，我们需要关注以下问题：部署并运行500台虚拟机所产生的IOPS与1000台虚拟机所产生的IOPS完全不同。当IT部门的其他人慌张确认业务在灾难中幸存下来时，你需要了解的最后一件事就是严重的I/O问题。需要认真考虑这一过程因为这可能会影响你的RTO。

　　一旦你意识到了这一特殊问题，接下来就要考虑灾难发生时重建虚拟桌面所需要的基础设施。为了创建新虚拟桌面，你需要访问模板或者是VMware View的链接克隆或者是组成桌面池的父虚拟机。

　　如果你在被复制的存储上存放了模板/父虚拟机，那么VMware SRM就能够简化这些辅助的文件“故障切换”到灾备站点的过程。就这一点来说，VMware SRM的确增加了灾难恢复过程的价值；这意味着无论模板/父虚拟机在被保护的站点是否被配置为VLAN10，当灾难恢复计划被触发后，模板/父虚拟机将会是SRM恢复计划的一部分，在恢复站点将被配置新网络VLAN20。没有这些辅助的文件，虚拟桌面恢复计划最初就会失败，因为你缺少创建用户需要连接的虚拟桌面的源文件。

　　更多VMware灾难恢复技术请看相关技术手册《VMware灾难恢复计划&实施手册》。

　　本系列文章下半部分请看《为VMware View虚拟桌面创建灾难恢复计划：专用vs. 非固定虚拟桌面》。