虚拟机军团来了

　　云计算(严格说是IaaS)的核心诉求就是向用户提供虚拟机。为了尽可能地提高CPU、内存的利用率，一台物理服务器中往往支撑着数十台甚至上百台虚拟机。接入是虚拟机联网的第一跳，接入做不好，什么大二层这些说法都是白扯。于是，虚拟机的接入成为了云网络变革中的头等大事。

　　1)VEB

　　传统接入网络中，一台主机通过一块物理网卡加上一条网线连接到接入交换机的一个物理端口上(不考虑网卡绑定)。可是面对庞大的虚拟机军团，传统的接入网络可傻了眼。物理服务器上的那几块网卡可哪够这些虚拟机分啊，另外网络的布线，交换机的端口密度也都难以满足大规模的虚拟机接入。

　　硬件的资源矛盾难以调和，那么解决这一问题自然而然的思路就是将接入网络的位置下移，延伸到物理服务器中。这种思路自虚拟化诞生的那一天起就有了，做法就是在HyperVisor中加一个软交换模块VEB(Virtual Ethernet Bridge)，通过虚拟端口关联虚拟机，用于虚拟机的接入和本地交换，通过一块物理网卡上联物理交换机(不考虑网卡绑定)，如果通信目标不在本地就交给上游的物理交换机。上游的交换机也全然意识不到它是个软件交换机，一切都跟传统以太网没什么两样。

　　VEB在技术上没什么难点，商用如VMware的VDS和Cisco的Nexus 1000V，开源如Linux Bridge和Open vSwitch，产品已经十分成熟。如果单纯从功能实现的角度来看，软件交换机的功能可以比物理交换机更为强大，升级起来也灵活的多，比如VxLAN这种延伸到服务器中的端到端隧道就能够很好地与VEB配合着做接入。可是由于软件交换机毕竟是通过CPU和通用内存来做交换的逻辑，其性能自然与基于ASIC的物理交换机有着巨大的差距。当然，这个差距可以通过多分配CPU和内存来填补，但是这就意味着服务器中能够给虚拟机分配的资源变少了，属于典型的丢了西瓜，捡了芝麻的做法。

　　解决这一问题，可以将服务器网卡进行改造，以具备接入交换机的功能，不过这种思路实现起来难度极大——把ASIC芯片、TCAM和总线资源都要集成在小小的网卡中，想一想都觉得头疼。因此，这种思路并没有得到广泛的研究与应用。不过，其衍生技术——虚拟化网卡，却得到了一定程度的发展，虚拟化网卡直接为虚拟机提供虚拟化的总线通道，而旁路调了VEB，模拟了传统接入网络中网线的角色，其代表技术为SR-IOV。

　　另外一种思路是VEB只保留接入端口和一些简化的转发功能，复杂的接入策略则转移给上游物理交换机。除了能够提升性能，这种思路还有另外一个非技术方面的驱动因素——网络复杂的功能分离到了服务器外面，使得服务器团队和网络团队的管理边界变得十分明确，避免了很多不必要的麻烦事儿。其代表技术为Cisco阵营的VN-TAG和非Cisco阵营的VEPA。

　　2)VN-TAG

　　VN-TAG是Cisco的私有标准，利用一个全新的标签实现了完整的数据中心接入方案，主要包括VN-Link技术和FEX技术。VN-Link部署在服务器的交换组件上，负责虚拟机的接入，而FEX部署在接入层的物理交换机上，负责虚拟机间的互通。两者配合在一起实现了虚拟机的实时感知和分布式接入，接入配置和策略的集中式分发保证了虚拟机的无缝迁移。

　　老规矩，帧格式先行。VN-TAG将6个字节的新字段插入到VLAN的前面，这些字节只在VN-TAG设备中出现，现有的协议(包括VLAN的使用)不会受到任何的影响。其中，DVIF_ID/SVIF_ID是目的/源虚拟机被分配的唯一标识，各有12位，通过Port Profile的配置与虚拟机接入端口进行一对一的通道绑定，VN-TAG物理交换机将根据这个标识来识别虚拟机，实现网络接口虚拟化。其他的标志位用于FEX系统中，D位标识报文的走向，P位标识报文是否需要复制，L位标识源主机和目的主机是否连接在同一台物理交换机上，R位作为保留。

　　通信流程概括如下：服务器中的交换组件不进行MAC寻址，它接受源虚拟机的流量，封装好VN-TAG(标记SVI_ID)，然后直接交给上游的物理交换机，上游的交换机完成SVI_ID对源MAC地址、VLAN和入端口的学习，根据目的MAC地址标记DVI_ID，然后转发给目标服务器，目标服务器根据DVI_ID进行通道转发，剥掉VN-TAG后转发给目标虚拟机。借用《腾云——云计算和大数据时代网络技术揭秘》中的一张图来表达上述过程，同时对该书作者表示感谢。

　　图中，Port Extender向下为VN-Link技术，向上为FEX技术。VN-Link由支持VN-TAG的网卡实现，如Cisco UCS刀片服务器中集成的Palo，该网卡只负责VN-TAG的封装/解封装，不做任何策略相关的工作。FEX技术由Cisco的N2K/N5K组合实现，支持以级联方式组网，其中N5K负责寻址转发和策略的制定，N2K则作为N5K的远端板卡部署在ToR实现分布式接入，N5K通过VIC协议分发给N2K，实现分布式转发。以作者目前的理解，VN-TAG体系将数据中心的接入网络虚拟成了一个大的接入交换机，由VN-Link充当网线，由N2K充当分布式线卡，N5K充当主控板，处于任何物理位置的虚拟机都好像连接在这个大的接入交换机上。高带宽、无阻塞和低时延的优良特性使得N2K/N5K间网络连接能够与单机内总线相当，保证了分布式接入的性能。在N5K上可以基于虚拟机对应的SVI_ID/DVI_ID制定ACL，QoS和流控等高级接入策略，支持网络策略随虚拟机任意的漂移。

　　VN-TAG是Cisco的野心之作，其产品线已然非常完善，其目标直指统一整个数据中心的接入网络。不过由于VN-TAG是Cisco私有标准，而且新的字段必然要新的芯片来支持，所以其它的厂家没有一个能玩得转。虽然Cisco贵为数通领域的江湖老大，但是估计也不愿意做孤家寡人，于是按照着VN-TAG的思路，Cisco提了802.1Br的开放标准(其前身为802.1Qbh)给IEEE，平复了一众小弟们的情绪。

　　当然了，也不是所有人都对老大言听计从。作为网络界的带头大哥，Cisco的想法自然是把网络延伸到服务器当中去，于是搞了块新的芯片支持VN-TAG，“顺便”集成在了UCS刀片服务器中，想用VN-TAG的话，OK，先买我的刀片。HP作为服务器界的龙头，对Cisco这种行为不爽的很，靠着网络虚拟化就想用UCS做掉我的服务器?作为回应，HP振臂一呼扯开VEPA的大旗，和Cisco叫上了板。

　　3)VEPA

　　VEPA(Virtual Ethernet Port Aggregator，802.1Qbg)是HP提出的虚拟机接入方案，设计目标就是尽量避免服务器上的大幅度改动。前面提到，无论是VN-TAG还是VEPA，都是为了解决VEB消耗大量服务器资源的问题。HP没办法搞定芯片来支持新字段，那么做不了加法就只好在原有的基础上动脑筋。VEPA对以太网帧格式没有任何的修改，而是通过对以太网转发规则的巧妙修改，同样卸载了服务器的负担。

　　802.1Qbg中，服务器中的VEPA组件间与虚拟机间运行VDP(Virtual Station Interface Discovery Protocol)协议，以识别虚拟机接入位置，同时支持对虚拟机迁移的感知。标准VEPA中，服务器的VEPA组件在虚拟机端口接收到的流量，不做任何处理，一律扔给上游的VEPA物理交换机。上游交换机正常做自学习，其改动之处在于VEPA修改了STP以允许入端口泛洪/转发，如果发现目的MAC地址在同一台服务器中，就再交给该服务器的VEPA组件，VEPA组件对于从上游交换机收到的流量进行MAC寻址转发，完成虚拟机间的通信。这个过程如下图所示，本地流量被强行绕弯通过上游交换机，俗称harpin，十分粗暴却简单有效。

　　VEPA的优势在于不需要对芯片做改动，交换机和服务器网卡的软件和驱动升级后就能支持VEPA了。但是，简单也往往意味着功能较弱。由于不带任何新的标签，所有流量都混在一起，上游VEPA交换机上的控制策略就很难做了。

　　在数通网络里，想要标识流量，肯定是要使用特定的字段来做的。HP没法另起炉灶，只能用已有的协议字段。VLAN是不行的，因为往往要用它来区分业务，于是HP看中了QinQ(802.1ad)，在标准VEPA的基础上使用QinQ的S-TAG来标识虚拟机流青浦区网站建设量，形成了增强型VEPA(802.1Qbg Multi- Channel)。有人可能要问了，虚拟机MAC地址不是唯一的吗，用来做策略不行吗?行，但是很麻烦，而且做不了分组策略。

　　在Multi- Channel中，一些S-TAG的流量可以在本地直接进行转发，而不用hairpin。另外对于广播/组播流量的处理，VEPA也做了一定的完善，允许在合理的位置进行复制，而VN-TAG只允许在N2K上进行复制。这两点也算是一个对标准VEPA的完善吧。

　　抛开一些细节不谈，Multi- Channel与VN-TAG没有本质上的区别，服务器为上行流量打标记，上游交换机做寻址、定策略，下行流量服务器上做通道转发。相比于VN-TAG使用FEX作为分布式接入技术，Multi- Channel因为用了QinQ，使得其接入的规模受到了一定的限制——S-TAG无法在传统的以太网设备上透传，只能在第一跳VEPA交换机终结。

不过这并不影响VEPA在虚拟机接入的市场上与VN-TAG分庭抗礼，毕竟市场这么大，大家谁也不好新媒体企业危机公关策略一口吃掉谁。另外，OpenStack+SDN+VxLAN这几年的兴起也向虚拟机接入市场注入了新的势力，不过隧道的封装终归也还是要OffLoad到物理交换机上的，服务器里的接入还得是VN-TAG和VEPA的二人转。

这就是小编今天的分享。