用物理交换机取代虚拟交换机 - SDN及云计算平台中的网络性能优化

　　二、用物理交换机取代虚拟交换机？

　　云计算网络目前还处于发展的初级阶段，为了支持多租户网络和支持VM的可移动性，网络虚拟化被广泛使用，包括基于VLan的、基于VxLan和基于GRE的。

　　目 前绝大多数网络都使用虚拟交换机（vSwitch）作为网络的边缘，最著名的就是Nicira公司发起的开源虚拟交换机项目OVS。之所以vSwitch 被大量用作网络虚拟化的边缘，跟VMware等软件公司的大力推动密不可分，这涉及到他们的利益，也涉及到网络的控制权之争：究竟是数据中心的系统运维团 队控制虚拟网络还是网络运维团队控制虚拟网络？以Cisco为代表的传统硬件厂商极力反对VMware的这种做法，理由包括网络可视化（Network Visibility）以及性能都是大问题，特别是性能问题。

　　但反对归反对，很多云计算网络的管理员有了先入为主的思维模式，如果有人让他 们切换到使用物理交换机，他们会普遍提出一堆问题，包括以下几个很典型的：会不会被锁定到特定的厂商身上？物理交换机能有虚拟交换机那么灵活满足各种需求 吗？我能像控制虚拟交换机那样方便地控制物理交换机吗？会不会增加网络成本？

　　尽管如此，很多人确实也都同意，使用虚拟交换机，例如OVS，确实有很多性能问题，这是使用物理交换机的方案最吸引人的地方，顺带着还有可扩展性（云管理平台要控制的虚拟网络节点太多）。所以现在问题就变成了：我知道使用物理交换机有这样的好处，但你怎样解决上述顾虑？

　　其实OpenStack的Neutron plugin机制特别是最新版（Havana）引入的ML2 plugin已经给出了答案。前面讲过，Neutron向上提供了一套标准的编程接口，这套接口独立于任何虚拟或者物理的交换机。对管理员来说，根本不需 要关心底下用的是谁的交换机，虚拟的还是物理的。对于数据中心系统研发部门的工程师来说，他们可以通过plugin机制引入多种交换机，虚拟的或者物理 的，前提是这些交换机必须能支持Neutron向上提供出那些API来，如果无法支持，自然就不会出现在我的采购列表里面，而支持了之后，如果以后因为某 些原因想换掉了，也很简单，只要换用另外一个交换机的plugin就可以了。这样第一个厂商锁定问题就没有了。特别是Havana版本引入的ML2 plugin机制，允许一个OpenStack域内同时支持多种交换机的plugin。这样只要管理员愿意，甚至都可以有的节点使用虚拟交换机，有的节点 使用物理交换机，而且可以是不同厂家的，唯一的前提就是这些交换机必须支持通用的Neutron API，这是北向接口标准化的好处。

　　第二个问题，物理交换机能有虚拟交换机那么灵活满足各种需求吗？其实对于特定的场景，这是个很隐蔽的伪命题。一提到灵活性，谁都想要，而且最好是无限灵活。但 如果有人问管理员，我可以满足你的场景中所有的实际需求，但无法提供任意不受约束的灵活性，你要任意灵活的话，需要付出代价，你要不要？我相信绝大多数理 性的管理员都不会要求任意灵活，因为超过需求之外的灵活，是无意义的，而你要为这些无意义的事情付出代价。另外，在有了SDN的机制，交换机可以向上提供 编程接口而不是命令行之后，特别是有了OpenFlow之后，一些交换机特别是为SDN优化过的交换机已可以满足绝大多数甚至全部云计算网络的需求了。退 一步说，不能满足需求的交换机，根据上面第一点，不会进入采购列表。

　　第三个问题，我能像控制虚拟交换机那样方便地控制物理交换机吗？在 SDN控制与转发分离的架构下，管理员通过云平台控制的永远都是直接的北向接口，那是与设备无关的。设备的差异性都被底层的实现给屏蔽掉了，如前所述，只 要底层设备能够提供足够的南向接口，通过换不同的plugin，OpenStack就可以控制不同的交换机，包括物理交换机。

　　第四个问题， 会不会增加我的网络成本？无论哪种方案，TOR交换机总是需要的。现在并不需要增加新的交换机设备，而只是要让原来的TOR交换机支持SDN方式或者换用 能支持SDN的交换机充当TOR。当然，客户都有保护已有投资的需要，往往不想把现有设备替换掉，这也没关系，前面讲过，OpenStack Neutron ML2的架构允许网络中有的网络节点是虚拟交换机，有的是物理交换机，所以想保护已有投资就变得很简单了，只需要在新增节点上用云平台来控制SDN物理交 换机就行了，原有的节点仍然是控制虚拟交换机，这样就可以让整个网络平滑引入物理交换机作为云平台控制的网络节点。