对于远距离vMotion以及相关的traffic trombones，我并不是特别痴迷，但是我非常肯定一些应用程序开发者或服务器管理员他们坚信把一个数据中心中正在工作的虚拟机迁移至另一个数据中心，对提高系统的灵活性以及服务质量来说都非常的重要。但是他们却没有考虑远距离数据中心桥接对潜在网络带来的巨大风险和威胁。

　　在一个关于《二层数据中心互连》的播客上，虚拟化专家Scott Lowe仍然没能改变我对于远距离数据中心桥接的看法。Scott所能给出的关于远距离数据中心桥接的唯一一个比较好的理由就是——灾难避免，即它可以从即将停机的数据中心中迁移所需的工作流量。

　　但是，如果你有关键应用，而且它还很可能运行在多个服务器上（用于数据冗余），那很希望你已经为这些服务器做好了负载均衡。如果是这样的话，在新的数据中心中启用新实体（使用新数据中心的新IP地址），关闭原数据中心中的实体，使用负载均衡缓慢地转换DC互连的链路就会安全的多。除非你把所有的互连服务器和主要的LUN都迁移至次级数据中心，否则你仍然会遇到traffic trombones问题，但是至少你不用在去处理数据中心内部桥接的麻烦事儿。

　　使用负载均衡避免远距离数据中心桥接

　　像F5的 BIG-IP 这种虚拟系统感知负载均衡器能够基于vCenter信息自动地调整负载均衡池的情况。在这些情况中，没有远距离桥接，或一些新奇的未经测试的新技术，起作用的只是一些从前常用的方法和一些常见的组合方式。

　　如果实际情况是你没有负载均衡器，或者预算不足无法购买，那你如何保证你的重要应用，如何保证它们完整的迁移？或者这有可能是十几年前的老应用只能在单一服务器上运行。之前我听说，80%的服务失效都是由软件和人为误操作而引起的，另外的20%是因为硬件问题。就算是这样，仍然有人敢说那个只能在单一服务器上运行的应用是关键的应用之一。而这种说法只是应用程序开发者在不测试或更改旧环境的情况下就在数据中心之间移动重要应用的理由。

　　如果你遇到过类似的这种情况（我肯定你一定会遇到），你一定要坚定自己的立场：远距离桥接是有潜在危险的，它甚至可能会导致不止一个数据中心的崩溃。所以，是短暂的应用程序故障时间，还是潜在的网络基础设置宕机时间，这两种风险，CIO们需要自己决定更愿意承担哪种？