如果你近期有建设虚拟数据中心的打算，那么你一定会同意这一说法，想要创建可扩展的2层网络区域以支持私有云中的动态虚拟机是十分困难的。当所有网络和虚拟化设备供应商都在宣称他们的 “高端”、“灵敏”、“绿色”、“下一代”数据中心网络时，大家就开始期盼一种高可用的虚拟网络解决方案的出现。但是事实上，我们所看到的情形是却是鱼龙混杂。

　　其问题源于VMware，它需要在它的ESX管理程序中实现交换功能，以确保相同物理服务器之间的虚拟机连接。虽然公司可以架设3层交换设备，但是公司一般都会选择标准以下的交换设备，这是由于在若干年之后，如果需要都可以在Office Depot买到，如SMB产品等。

　　但是，同样地物理服务器中嵌入的第三方2层交换设备不能当成是虚拟网络的解决方案。自从服务器不再被认为是最终主机端，物理交换机就得在主干连接中同样为服务器做交换工作。我们知道，大规模桥接环境都是非常脆弱的，当服务器担当起整个VMware配置的工作时，系统部署和故障排除也将会让人非常头疼。

　　现有虚拟网络解决方案不够给力

　　VMware试图用vCloud Director处理虚拟网络中的各种问题，vCloud Director可实现信息交换、路由、防火墙、NAT甚至是VMware框架中的DHCP服务器等各种作用。如果不是VMware决定使用其专有的协议实现虚拟设备中的各种网络功能，那么可以说vCloud会是一个相当不错的产品。比如说，除了两年前发布的802.1ah标准（特别是MAC-in-MAC封包），其MAC-in-MAC封包就并不符合任何一个业界所认同的标准。

　　VMware的GUI确实满足了各方面纷繁的需求（大多数的需求看起来都十分不可思议），但是vCloud在解决重要的系统问题时却终于败北：VM移动性需建立在桥接的基础上；相比于之前的vCloud，桥接的扩展性也不值一提，还有流量在数据中心中循环传送等各种问题。

　　与其同时，Cisco也打算在虚拟化网络领域一显身手，并发布了Nexus 1000V(它也是VN-Link/VN-Tag 策略的一部分)，Nexus 1000V还附带有信息控制反馈功能。而其他网络供应商都急于研发 虚拟以太网端口适配器 (VEPA)，VEPA这种技术可以很好地从管理程序中输出信息流，并过滤出重要的适配器信息流交付给首个交换机做处理，包括了桥接、VLAN、路由、QoS以及安全性。Cisco的VN-Tag，以及VEPA标准 (802.1Qbg)都已经通过了IEEE的评定。VEPA供应商将会告诉你采用VEPA你所能够获得的良好体验，但是对于VEPA中的一个重要细节却显得底气不足，这就是VEPA需要管理程序的支持。虽然VMware支持Nexus 1000V，但是我怀疑在公司有了完备的系统之后，将会欣然接受在vSwitch中再实现VEPA。

　　而且VEPA也无力解决前面提及到的任何一个问题；VEPA其实也只是交付于你一个与众不同的GUI/CLI，这意味着在配置虚拟NIC时是在物理交换机上，而并非是在vCenter/vCloud上。

　　由于供应商所提供的只是一些混乱或者不成熟的解决方案，所以大家对当前的混乱态势感到疑惑，其实，问题的解决方法非常简单：都归结于有限的预算。

　　如果VMware使用体验不佳，而不得不把系统迁移至vCloud，那么你就需要最基本的，低成本交换机，这些交换机需要能够实现ESX服务器之间基本的桥接功能。如果网络供应商向你销售VEPA，你就无需购买vCloud或vShield许可，但是你得购买一些智能交换机。

　　但是在市场竞争最激烈的时候，供应商已经忘记了客户最初的需求，比如客户非常需要一个易于扩展，易于管理，能够解决系统问题的解决方案。简易的端到端结合的解决方案虽然过于强大但我们还是先把它归于解决方案的发展方向之一。也许它过于庞大，过于大材小用，但是供应商是否会走这样一条道路，还请我们拭目以待。