本文作者为Howard Marks，他目前正在参与到EMC和NetEX公司有关虚拟机迁移和远程灾备的项目中。
过去几个月中，我对WAN（广域网）Vmotion（虚拟机迁移）比较关注。这很大程度上是因为一位客户问我如何衡量他们的产品使流程改善了多少。我不是唯一一个关注这方面的人，因为思科的OTV和EMC的VPLEX直接针对的就是将虚拟机从一个地方迁移到另一个地方。灾难恢复解决方案的目的是最小化灾难发生后服务中断概率和数据丢失概率，而WAN Vmotion和/或带Hyper-V的WAN Live Migration（WAN实时迁移）可以帮助规避灾难。
例如，如果预计未来两天内有飓风来袭，IT部门可以将虚拟机（VM）从他们的Mobile数据中心迁移到Hattiesburg（密西西比州哈德斯堡）数据中心。
我认为WAN Vmotion要想实用化就必须解决三个不同但相互关联的问题。第一个就是用户和/或相连的服务器所在的互联网网络必须同时存在于两个地点。过去20年来，互联网的专家将所有WAN连接予以路由化，以便防止广播和生成树传输挤占真正的数据所需要的空间。MPLS（多协议标记交换）和OTV等技术可以在桥接子网的同时过滤掉我们不希望在WAN上传输的内容，并确保生成树不会关闭高速WAN连接。第二个问题是如何压缩vMotion以便使其不超过可用的带宽。Riverbed、F5、NetEx等公司可以通过TCP删除和压缩等方式来解决这个基本的WAN优化问题
存储这边的问题是最复杂的。虽然你可以将虚拟机的磁盘从Mobile迁移到Hattiesburg，但是这是GB/TB级的数据，而且如果你要迁移全部关键数据的话，那么天气预报所提供的两天预警时间可能是不够用的。此外，我们在此前还要将一些数据复制到Hattiesburg，因为有一些灾难是我们无法预测的。我们真正需要的是两个不同地点的存储系统在VMware主机面前提供的是同样的ID（WWN（全局名）等），这样当VM从一个地方迁移到另一个地方的时候，它可以从本地存储系统访问数据。Compellent Live Volume和HDS（日立数据系统）的HAM可以部分解决这种问题，而EMC的VPLEX采用的方式是最正确的。
通过VPLEX Metro，两个数据中心的VPLEX设备给它们所管理的LUN（逻辑单元号）提供的是同样的ID。它们还可以在两个地方提供一致的高速缓存，在两个站点之间传送更新。由于VM不共享VMDK（虚拟磁盘文件），而且每个VM只存在于一个数据中心，因此每个VMDK，或这些VM所占用的磁盘块，在每个时点上只会被写入一个数据中心。VPLEX Metro采用的是同步功能，因此它需要限制在60英里的连接范围内，否则它无法处理更长的连接所带来的延迟性。
我希望出现异步的VPLEX Geo，这种产品可以工作于更长的距离，这样你就可以将虚拟机从Mobile迁移到亚特兰大，因为没有人真正愿意在这么近的Hattiesburg兴建另一座数据中心。然后，我们可以将虚拟机迁移到亚特兰大，让VPLEX来缓冲写入，直到异步复制赶上来为止，然后我们可以强行使两个阵列之间的复制关系倒过来，比如从生产阵列变成灾难恢复阵列，或者反过来，这样的过程甚至都不需要用户注意到。EMC承诺会提供这种技术，即使针对的不是EMC自己的磁盘阵列。
