下一代数据中心的虚拟接入技术–VN-Tag和VEPA
下一代数据中心的虚拟接入技术–VN-Tag和VEPA数据中心的虚拟接入是新一代数据中心的重点课题，各方已经争夺的如火如荼。目前网络上的中文资料还不多，根据自己的经验写了一点对虚拟接入的理解，意在丟砖，引出真正的大佬。
一、为什么虚拟化数据中心需要一台新的交换机
随着虚拟化技术的成熟和x86 CPU性能的发展，越来越多的数据中心开始向虚拟化转型。虚拟化架构能够在以下几方面对传统数据中心进行优化：[*]提高物理服务器CPU利用率；[*]提高数据中心能耗效率；[*]提高数据中心高可用性；[*]加快业务的部署速度
正是由于这些不可替代的优点，虚拟化技术正成为数据中心未来发展的方向。然而一个问题的解决，往往伴随着另一些问题的诞生，数据网络便是其中之一。随着越来越多的服务器被改造成虚拟化平台，数据中心内部的物理网口越来越少，以往十台数据库系统就需要十个以太网口，而现在，这十个系统可能是驻留在一台物理服务器内的十个虚拟机，共享一条上联网线。http://www.tektalk.org/wp-content/uploads/2011/01/1-300x187.png
这种模式显然是不合适的，多个虚拟机收发的数据全部挤在一个出口上，单个操作系统和网络端口之间不再是一一对应的关系，从网管人员的角度来说，原来针对端口的策略都无法部署，增加了管理的复杂程度。
其次，目前的主流虚拟平台上，都没有独立网管界面，一旦出现问题网管人员与服务器维护人员又要陷入无止尽的扯皮中。当初虚拟化技术推行的一大障碍就是责任界定不清晰，现在这个问题再次阻碍了虚拟化的进一步普及。http://www.tektalk.org/wp-content/uploads/2011/01/2-e1294999388800-300x187.png
接入层的概念不再仅仅针对物理端口，而是延伸到服务器内部，为不同虚拟机之间的流量交换提供服务，将虚拟机同网络端口重新关联起来。
二、仅仅在服务器内部实现简单交换是不能的
既然虚拟机需要完整的数据网络服务，为什么在软件里不加上呢？
没错，很多人已经为此做了很多工作。作为X86平台虚拟化的领导厂商，VMWare早已经在其vsphere平台内置了虚拟交换机vswitch，甚至更进一步，实现了分布式虚拟交互机VDS（vnetwork distributed switch），为一个数据中心内提供一个统一的网络接入平台，当虚拟机发生vmotion时，所有端口上的策略都将随着虚拟机移动。
VMWare干得貌似不错，实际上在当下大多数情况下也能够满足要求了。但如果谈到大规模数据中心精细化管理，内置在虚拟化平台上的软件交换机还有很多问题没有解决。首先，目前的vswitch至多只是一个简单的二层交换机，没有QoS、没有二层安全策略、没有流量镜像，不是说VMWare没有能力实现这些功能，但一直以来这些功能好像都被忽略了；其次，网管人员仍然没有独立的管理介面，同一台物理服务器上不同虚机的流量在离开服务器网卡后仍然混杂在一起，对于上联交换机来说，多个虚拟机的流量仍然共存在一个端口上。
虚拟平台上的软件交换机虽然能够提供基本的二层服务，但是由于这个交换机的管理范围被限制在物理服务器网卡之下，它没法在整个数据中心提供针对虚拟机的端到端服务，只有一个整合了虚拟化软件、物理服务器网卡和上联交换机的解决方案才能彻底解决所有的问题。
这个方案涉及范围如此之广，决定这又是一个只有业界大佬才能参与的游戏。
三、谁在开发新型交换机？
HP，Cisco。
一个是PC服务器王者，近年开始在网络领域攻城略地，势头异常凶猛；一个是网络大佬，借着虚拟化浪潮推出服务器产品，顽强地挤进这片红海。
针对前文所说的问题，两家抛出了各自的解决方案，目的都是重整虚拟服务器同数据网络之间那条薄弱的管道，将以往交换机上强大的功能延伸进虚拟化的世界，从而掌握下一代数据中心网络的话语权。
Cisco和VN-TAG
虚拟化平台软件如VMWare ESX部署之后，会模拟出一整套硬件资源，包括CPU、硬盘、显卡，以及网卡，虚拟机运行在物理服务器的内存中，通过这个模拟网卡对外交换数据，实际上这个网卡并不存在，我们将其定义为一个虚拟网络接口VIF（Virtual Interface）。VN-tag是由Cisco和VMWare共同提出的一项标准，其核心思想是在标准以太网帧中增加一段专用的标记—VN-Tag，用以区分不同的VIF，从而识别特定虚拟机的流量。
VN-Tag添加在目的和源MAC地址之后，在这个标签中定义了一种新的地址类型，用以表示一个虚拟机的VIF，每个虚拟机的VIF是唯一的。一个以太帧的VN-Tag中包含一对这样新地址dvif_id和svif_id，用以表示这个帧从何而来，到何处去。当数据帧从虚拟机流出后，就被加上一个VN-Tag标签，当多个虚拟机共用一条物理上联链路的时候，基于VN-Tag的源地址dvif_id就能区分不同的流量，形成对应的虚拟通道，类似传统网络中在一条Trunk链路中承载多条VLAN。只要物理服务器的上联交换机能够识别VN-Tag，就能够在交换机中直接看到不同的VIF，这一下就把对虚拟机网络管理的范围从服务器内部转移到上联网络设备上。http://www.tektalk.org/wp-content/uploads/2011/01/3-300x187.png
思科针对VN-Tag推出了名为Palo的虚拟服务器网卡，Palo卡为不同的虚拟机分配并打上VN-Tag标签，上联交换机与服务器之间虽然只有一条网线，但通过VN-Tag上联交换机能区分不同虚拟机产生的流量，并在物理交换机上生成对应的虚拟接口VEth，和虚拟机的VIF一一对应，好像把虚拟机的VIF和物理交换机的VEth直接对接起来，全部交换工作都在上联交换机上进行，即使是同一个物理服务器内部的不同虚拟机之间的流量交换，也通过上联交换机转发。这样的做法虽然增加了网卡I/O，但通过VN-Tag，将网络的工作重新交回到网络设备。而且，考虑到万兆接入的普及，服务器的对外网络带宽不再是瓶颈，此外，利用Cisco Nexus 2000这种远端板卡设备，网管人员还能够直接在一个界面中管理数百台虚拟机，每个虚拟机就好象在传统的接入环境中一样，直接连接到一个交换机网络端口。http://www.tektalk.org/wp-content/uploads/2011/01/4-300x187.png
目前，思科推出的UCS服务器已经能够支持VN-tag，当Palo卡正确安装之后，会对上层操作系统虚拟出多个虚拟通道，每个通道对应一个VIF，在VMWare EXS/ESXi软件中可以将虚拟机绕过vswitch，直接连接到这些通道上，而在UCS管理界面上则能够看到对应的虚拟机，使网管人员能够直接对这些端口进行操作。
Cisco同VMWare已经将向IEEE提出基于VN-Tag的802.1Qbh草案，作为下一代数据中心虚拟接入的基础。
HP和VEPA
Cisco提出的VN-Tag，在IT业界引起的震动远远大于在客户那得到的关注，如果802.1Qbh成为唯一的标准，Cisco等于再一次制定了游戏规则，那些刚刚在交换机市场上屯下重兵的厂商，在未来数据中心市场上将追赶得异常痛苦。此外，VN-Tag是交换机加网卡的一揽子方案，还能够帮助Cisco快速切入服务器市场，对其他人来说是要多不爽有多不爽。
很容易猜到，这其中最不爽的就是HP，在交换机和服务器领域跟Cisco明刀明枪地干上之后，被这样摆上一道，换谁也不可能无动于衷。HP的应对很直接，推出一个类似的方案，替代VN-Tag。
HP的办法称为VEPA（Virtual Ethernet Port Aggregator），其目的是在部署了虚拟化环境的服务器上实现同VN-tag类似的效果，但VEPA采取了一条截然不同的思路来搭建整个方案。
简单来说，VEPA的核心机制就是两条：修改生成树协议、重用Q-in-Q。
VEPA的目标也是要将虚拟机之间的交换行为从服务器内部移出到上联交换机上，当两个处于同一服务器内的虚拟机要交换数据时，从虚拟机A出来的数据帧首先会经过服务器网卡送往上联交换机，上联交换机通过查看帧头中带的MAC地址（虚拟机MAC地址）发现目的主机在同一台物理服务器中，因此又将这个帧送回原服务器，完成寻址转发。整个数据流好象一个发卡一样在上联交换机上绕了一圈，因此这个行为又称作“发卡弯”。
虽然“发卡弯”实现了对虚拟机的数据转发，但这个行为违反了生成树协议的一项重要原则，即数据帧不能发往收到这个帧的端口，而目前虚拟接入环境基本是一个大二层，因此，在接入层，不可能使用路由来实现这个功能，这就造成了VEPA的机制与生成树协议之间的矛盾。
但是VEPA没有vPC，在接入层还是要跑生成树。HP的办法就是重写生成树协议，或者说在下联端口上强制进行反射数据帧的行为（Reflective Relay）。这个方式看似粗暴，但一劳永逸地解决了生成树协议和VEPA机制的冲突，只要考虑周全，不失为一步妙棋。
除了将虚拟机的数据交换转移到物理服务器上之外，VN-Tag还做了一项重要的工作，就是通过dvif_id和svif_id这对新定义的地址对不同虚机流量进行区分。HP在这里的搞法同样简单直接，VEPA使用Q-in-Q在基本的802.1q标记外增加了一层表示不同虚拟机的定义，这样在VLAN之外，VEPA还能够通过Q-in-Q区分不同的虚拟机，只要服务器网卡能够给数据帧打上Q-in-Q标记，上联交换机能够处理Q-in-Q帧，基本就可以将不同的虚拟机流量区分开来，并进行处理。
至此，VEPA看起来已近能够实现同VN-Tag类似的功能，因此HP也将VEPA形成草案，作为802.1Qbg的基础提交至IEEE。不得不说，VEPA是个非常聪明的设计，不管是对生成树行为的修改，还是利用Q-in-Q都不是什么不得了的创新，目前的交换机厂商只要把软件稍微改改，就能够快速推出支持802.1Qbg的产品，重新搭上数据中心这班快车，追上之前被Cisco甩下的距离。
VN-Tag和VEPA
自从Cisco祭出VN-Tag大旗后，各种争议就没停过，直到HP推出VEPA，这场口水仗达到高潮，随着2011年，802.1Qbh和802.1Qbg标准化进程的加快，围绕虚拟接入下一代标准的争夺将进入一个新的阶段。
这也不难理解，随着数据中心内虚拟机数量的不断增加，越来越多的物理网口转化为虚拟的VIF，如果一家网络厂商没法提供相应的接入解决方案，它的饼会越来越小，活得非常难受。
VN-Tag就是Cisco试图一统下一个十年数据中心的努力，HP虽然同思科正面开战时间不长，但从VEPA来看，其手法相当老辣。由于VEPA没有对以太网数据结构提出任何修改，实现成本非常低，以往被思科扫到大门之外的厂商，一下子见到了曙光，前仆后继地投靠过来，Juniper、IBM、Qlogic、Brocade等等都毫不掩饰对VEPA的期待，Extreme甚至表示，已近着手修改OS以保证对VEPA的支持。待各方站队结束，大家发现Cisco虽然有强大的盟友VMWare，但另外一边几乎集结了当今网络界的所有主流厂商，舆论也逐渐重视VEPA的优点，甚至Cisco自己也不得不松嘴说会考虑对802.1Qbg的支持。
戏演到这里，很多人幸灾乐祸地等着看Cisco怎么低头。但有一个问题，VEPA这么完美，为啥Cisco之前没有采用类似的思路？仅仅为构建一个封闭的体系架构吗？我认为不是。
回答这个问题前，我们首先要弄清楚另一个问题。以VMWare ESX/ESXi为例，由于ESX/ESXi自带的vswitch只是模拟了一台二层交换机，当一台物理服务器上两个处于不同VLAN的虚拟机之间需要交换数据时，vswitch是无能为力的。只能将数据送到上联物理交换机上，由物理交换机完成VLAN间的三层转发。听起来是不是很熟悉？这和之前提到的VN-Tag与VEPA的机制很相似，如果现有的虚拟化环境已经能够将数据交换的行为转移到上联交换机，为啥还要大费周折地提出一个新标准呢？
这是因为，当下的这种方案是利用VLAN来隔离不同虚拟机，通过TRUNK将对应多个虚拟机的VLAN送到物理交换机上。这种方式打破了数据中心内对VLAN的使用惯例，比如，网管人员通常会把负责同一业务的多台服务器放在一个VLAN内，如果VLAN标签都被用来隔离虚拟机了，则没法按照传统方式来区分不同业务，解决了一个问题，带来另外的问题，这是绝对行不通的。
现在，我们可以回答之前的问题了，新一代的虚拟接入方案是要在不影响802.1Q等原有网络行为的前提下，完成对虚拟机的接入、区分和管理。有人会说，用PVLAN不可以吗?但我们怎么保证PVLAN没有其他的用处呢？出于这样的思路，Cisco没有利用现有的任何技术，提出了一个全新的实现方案，正因为VN-Tag从出生起就“干干净净”，同谁都没有瓜葛，因此VN-Tag携带的信息就能够在整个数据中心内自由的传递，从而快速为用户搭建起一个清晰、完整的虚拟接入平台，所谓“磨刀不误砍柴工”。
HP充分利用了现有条件，VEPA的整个架构看上去简洁、高效，但是对生成树协议改动和利用Q-in-Q无疑会影响到现网的行为。生成树协议的效率和问题一直是个老大难，但无数聪明绝顶的高手琢磨了这么多年，协议的变动仍然不大，说明对这种基本协议的修改不是一蹴而就的，往往迁一发而动全局，现有的模式是各方协调、妥协的结果。VEPA要在短时间内拿出一个完美的方案，所需花费的精力也许并不比重新提一套方案少。
除了协议本身之外，摆在HP和VEPA面前还有两个难题，首当其冲就是VMWare的支持。VEPA虽然对交换机硬件改动不大，但要真正跑起来，还需要虚拟化平台软件的支持，虚拟网卡和虚拟交换机得主动把所有数据帧扔到上联交换机上，后面的故事才能续上。可是VMWare还是Cisco在VN-Tag上最大的盟友，虽然Cisco已经表示会支持802.1Qbg，但会有多及时就难说了。
时间也就是VEPA的第二个困难。目前，思科的UCS服务器已经能够提供端到端的VN-Tag部署。而HP的Virtual Connect解决方案仅实现了Q-in-Q的多链路，对“发夹弯”的支持并不好，也没有VMWare的支持，说白了，VEPA还只是图纸上的设计，没有实际产品支撑。此外，虚拟接入只是下一代数据中心组成之一，FCoE、THRILL等都非常重要，针对这些技术，HP仍拿不出成型的产品，相反，Cisco在所有领域几乎都布局完毕，留给HP的时间不多了。
这场针对数据中心接入的争夺，在2011年必将愈演愈烈，Cisco携全线产品势在必得，而HP的VEPA评价聪明的设计，得到业界广泛支持，故事结局如何，还待静观其变。
[*]http://www.tektalk.org/wp-content/plugins/sociable-30/images/default/16/facebook.png[*]http://www.tektalk.org/wp-content/plugins/sociable-30/images/default/16/twitter.png[*]http://www.tektalk.org/wp-content/plugins/sociable-30/images/default/16/live.png[*]http://www.tektalk.org/wp-content/plugins/sociable-30/images/default/16/slashdot.png[*]http://www.tektalk.org/wp-content/plugins/sociable-30/images/default/16/digg.png[*]http://www.tektalk.org/wp-content/plugins/sociable-30/images/default/16/googlebookmark.png
http://www.tektalk.org/wp-content/plugins/wp-postratings/images/stars/rating_on.gifhttp://www.tektalk.org/wp-content/plugins/wp-postratings/images/stars/rating_on.gifhttp://www.tektalk.org/wp-content/plugins/wp-postratings/images/stars/rating_on.gifhttp://www.tektalk.org/wp-content/plugins/wp-postratings/images/stars/rating_on.gifhttp://www.tektalk.org/wp-content/plugins/wp-postratings/images/stars/rating_on.gif (8个打分， 平均：5.00 / 5)
工具箱
本文链接 | 邮给朋友 | 打印此页 | 45条用户评论 »
雁过留声“下一代数据中心的虚拟接入技术–VN-Tag和VEPA”有45个回复 [*]tang ling 于 2011-01-16 5:15 下午
深入浅出，说得很清楚，佩服佩服
[*]deltali 于 2011-01-16 5:52 下午
写的不错，有理有据的。要是能把写这篇文章的参考资料也给出链接就更好了
[*]冬瓜头 于 2011-01-16 5:55 下午
想请教一下楼主，Multihop FCoE，FCoE forwarder，Fabric Extender，这些词我前阵子搜索过，一直没有找到细节的东西，不知道楼主是否了解，请指教！
[*]福尼 于 2011-01-16 7:21 下午
非常好的观点，非常清晰的思路
[*]ZC 于 2011-01-16 7:49 下午
好文，学习。
新平台/新标准的搭建不论对谁都是事关生死 的大事，就看业界怎么演绎了，呵呵。
[*]gaohl 于 2011-01-16 8:57 下午
写的非常好，学习了
[*]kernelchina 于 2011-01-16 9:49 下午
按道理，虚拟机之间的流量在vSphere内部应该更快点，为什么要跑到外面的交换机上转一圈再回来？如果把vswitch做成一个full feature的switch，会不会更好一点？
physical switch vswitch–virtual machine.
[*]冬瓜头 于 2011-01-16 10:00 下午
不懂网络内核方面，猜测如果做入那些full feature，esx上的cpu恐怕吃不消了吧。
[*]deltali 于 2011-01-16 10:03 下午
to kernelchina:
看这篇文章的意思，就是要把虚拟机当真实的机器用，让它们之间的流量也暴露在整个网络中，就像2台物理主机共用一根网线一样。
[*]陈怀临 于 2011-01-16 10:10 下午
这篇文章意义重大。。。。。。
[*]冬瓜头 于 2011-01-16 10:15 下午
http://bradhedlund.com/2010/09/15/vmware-10ge-qos-designs-cisco-ucs-nexus/
这人是思科的，他的博客偷了不少这方面的料。
[*]Panabit 于 2011-01-16 10:22 下午
这个文章好，拜读了！
[*]旁观者清 于 2011-01-16 10:29 下午
这都是过分渲染“云”计算，虚拟化的结果。
VN-tag和VEPA是虚拟接入的两个标准草案，其本质从用户的角度来看，不过是虚拟机识别和管理的技术实现手段而已。
思科推行VN-tag的市场目的就是搞垄断，就像当年的EIGRP一样；其他厂商推行VEPA就是不想这块细分市场被思科所垄断，就行OSPF一样。 这种从网络设备到服务器/网卡的端到端垄断是思科所追求的，也正是其他厂商不希望看到的。
[*]picktracy 于 2011-01-16 10:30 下午
功力啊功力，清晰易懂，好文。
[*]冬瓜头 于 2011-01-16 11:34 下午
和FCoE一样。还好有个iSCSI顶着。。
[*]kernelchina 于 2011-01-17 12:38 上午
以前看cisco的nexus 1000v和vn-link没搞明白是什么意思，现在有点明白了。把虚拟机当真实的机器用，需要各方面加倍，然后再分割，否则性能没法保证。
[*]cong 于 2011-01-17 1:14 上午
好文！
PS：冬瓜头同学也写一个吧
[*]冬瓜头 于 2011-01-17 3:38 上午
To cong:
呵呵，感谢这位的 鞭策，此文甚好，学习中，后续文章会努力提高质量！谢谢！
[*]libing 于 2011-01-17 4:36 上午
to 冬瓜头
FCoE forword和fiber channel forward一般指的都是服务器上联的交换机，FCoE的链路目前只能实现一跳，存在于服务器网卡和forward之间，FCoE的帧在forward上被拆开，并通过FC链路送到SAN上。
而要将FCoE链路延长到更远的交换机，就是Multihop FCoE，即FCoE的多跳。Multihop FCoE在FC-BB-5中已经有了对应标准，实现方式也不止一种。
Fabric Extender一般指Cisco的Nexus 2000扩展设备，相当于把机架式交换机的板卡取出来，作为一个独立设备。这样的好处是可以以ToR的方式不限，以EoR的管理。
deltali的意见很好，我找了一个FEX的说明：
http://www.networkworld.com/community/node/39236
[*]libing 于 2011-01-17 4:38 上午
to kernelchina
基本上，虚拟接入解决的不是性能问题，而是管理问题，将网络的行为重新还给网络设备。
当然，解决一个问题的方式有很多中，这只是其中一种
[*]xie 于 2011-01-17 7:04 上午
不知道CISCO针对TRILL是什么解决方案
[*]tom 于 2011-01-17 5:50 下午
好文，必须要顶
[*]tom 于 2011-01-17 5:59 下午
猜测一下结果，VEPA将会赢得胜利，一个封闭的系统没有前途，就如EIGRP一样。。。。。。
[*]cius 于 2011-01-17 6:46 下午
to 旁观者清
实际上你说的OSPF是Cisco除了BGP外贡献最大的标准协议之一。从对RFC的贡献看，Cisco从来不想做一个“垄断的协议”（这和当年IBM、DEC和HP有多么大的不同啊），Cisco只是想抢先推出一些标准，并试图放到IEEE和IETF上公开，不过想在这些领域抢得先机而已。若说垄断，凭着现在全球市场占有率，直接出私有协议不就完了，象水果公司的OS那样。
[*]cius 于 2011-01-17 6:49 下午
to libing
Palo绕过Hypervisor实现VM直接驱动的I/O，这可是大大的性能问题，想想现在那些I/O密级型的应用
[*]cius 于 2011-01-17 6:49 下午
to libing
Palo绕过Hypervisor实现VM直接驱动的I/O，这可是大大的性能改善（Hypervisor Bypass），想想现在那些I/O密级型的应用
[*]cius 于 2011-01-17 6:54 下午
to tom
现在很难说，和EIGRP最大的不同是，Cisco当年不同意公布EIGRP协议，而802.1Qbh从一开始就是开放的。而且Cisco进可攻、退可守：进，可以推行干干净净的虚拟化接入方案802.1Qbh，不增加用户部署的管理负担（Spanning Tree快在数据中心死了）；退，可以非常容易支持Qbg，和大家一样不就完了
[*]tang ling 于 2011-01-17 7:29 下午
to Cius,
关于绕过虚拟Hypervisor，直接读取I/O的技术意义，对VN-LINK等技术有重要的间接推动作用. 毕竟， “Palo卡的vNIC技术，配合VN-Link以及VMWare的Hypervisor Bypass技术，可以让网卡流量不经过CPU和Hypervisor，完全交由Palo网卡直接硬件处理。这样能带来带宽吞吐30%的性能提升”。
http://www.cisco.com/en/US/solutions/collateral/ns340/ns517/ns224/ns944/white_paper_c11-593280_ps10279_Products_White_Paper.html
但是，从实际看，包括同虚拟化厂商的沟通，坦率说，现在还没有killer级应用，必须用direct I/O；就客户而言，国内也极少有实际部署direct I/O案例。我了解只有个别类似于涉及视频编辑的应用，可能会考虑。
因此，如果你这边有关于Direct I/O在实际中的应用情况，可否分享一下~
[*]deltali 于 2011-01-17 7:48 下午
采用Direct I/O的话，首先会对live migration造成影响。这个是绝对不能接受的，不知道现在这方面的问题解决的如何了？
其次跟嵌入式设备不同，在服务器虚拟化这边，还是要尽量避免让虚拟机直接控制硬件。
[*]Da Vinci 于 2011-01-17 9:42 下午
To xie：
TRILL就是Cisco在推的，与之对应的是IEEE在推的802.1aq(SPB)。这两个方案都是为了解决STP带来的问题而提出的。感觉TRILL更正统一些，因为是Perlman大妈主导的，当年也是她搞的STP。但目前TRILL的标准里边都没有OAM相关的内容。而SPB由于完全继承QinQ和PBB，分成SPBV和SPBM两种模式，也顺理成章的继承了以太网的OAM那一套东西。但是这里又把PBB/PBT这个边缘化了的东西给弄回来了，好不热闹。现在TRILL和SPB都还是draft。
至于后边怎么发展就拭目以待啦。
[*]Fear 于 2011-01-17 10:03 下午
写得很好，但我有疑问，VN-tag如何表示虚拟机的Mac地址，从文中描述看，传到上联交换机的IP包为网卡Mac+vif_id，网卡Mac表示物理网口，vif_id表示绑定在该物理网口的虚拟网口，如果虚拟机被迁移至另一台物理机上运行，路由如何修改？IP协议修改了，虚拟机如何跟外网通信？
[*]libing 于 2011-01-18 12:00 上午
To Fear
VNTag本身是不携带MAC信息的，对现有的vMotion流程也不产生影响，VNTag解决的网络侧对虚拟机的识别和管理问题。
就我的知识范围，虚拟机迁移后，还是需要通过ARP更新来实现正确寻址。
[*]旁观者清 于 2011-01-18 12:49 上午
To Cius:
Cisco在协议标准化方面对行业的贡献非常之大，这是有目共睹的。但是，既然是商业公司，毕竟不是研究机构或者慈善机构，必定有其特定的商业目的，不会做亏本的买卖。Cisco投入大量的人力物力在标准化方面，或者说是抢得先机，目的其实再简单不过了，就是要早一步抢占这块细分市场，形成对后来者的技术垄断，如果没有反垄断法的制约，天知道会是什么样的情况，呵呵。效果很明显，Cisco也是领导行业标准化的最大贡献者，同时也是最大的受益者。
举个在中国最简单的例子，想当年中国的整个金融行业就一种路由协议，EIGRP，放眼望去，都是Cisco的设备。华为搞一个EIGRP，被Cisco给告了最后不了了之，一些其他厂商（我就不点名了），现在还私底下维护EIGRP的代码和功能，为了能在某个网点可以和Cisco的EIGRP互通。近些年，在其他厂商的集体抗议和抗争下，OSPF才得以进入到中国的金融行业网络中…
[*]旁观者清 于 2011-01-18 12:58 上午
To Xie
TRILL是Layer 2 multi-path的“标准化”实现版本，如Da Vinci所言，是Cisco主推的基于二层网络的基于Mac地址进行“路由”的协议，用了ISIS的协议扩展。Cisco私有的实现叫FabricPath，其实和TRILL几乎完全一样。
目前处于Draft状态，想法很好，感谢Cisco的不断创新，不过，至于实际可用性还有待未来市场的考验。
[*]libing 于 2011-01-18 1:07 上午
To deltali & Tanglin
Palo除了能配合ESX实现direct I/O，还有一种hypervisor pass thru模式，这种模式也能一定程度地降低CPU负载，增加I/O吞吐，同时保持vMotion等高级功能
[*]Lucifer 于 2011-01-18 1:17 上午
passthru模式其实是direct i/o的延伸，本质上是vt-d和sr-iov的配合，网卡本身提供多个logical function（就是多个小的虚拟网卡），然后通过vt-d映射到虚拟机里面。esx本身通过一个驱动模型来解决vmotion迁移到不支持这些技术的机器上的问题
[*]Jack_Wang 于 2011-01-18 5:38 上午
虚拟机里分配virtual function ，加载对应 virtual function driver， 与 vmm 中的 physical function driver 通信
[*]metal1011 于 2011-01-18 8:35 上午
关注下技术新动态
[*]Lucifer 于 2011-01-18 10:16 上午
嗯，是virtual function
[*]Lucifer 于 2011-01-18 10:22 上午
虚拟机的virtual function driver不需要和physical function driver通信，是直接和virtual function通信
[*]tom 于 2011-01-25 10:17 下午
请问类似altor，针对虚拟机安全的目前有哪几家？
[*]bigrong 于 2011-01-26 12:04 上午
libing是哪位，是我除了kenealchina、冬瓜头以外又想拜见的一位大师。好文！
09年的时候思科中国的朋友想让我写篇关于nexus的软文，给了我一堆ppt，还有一个上海的tme给我讲了一通，就觉得当时做datacenter，想搞虚拟存储融合，思科看得真的远。nexus强不在性能上，而是在内涵上。Juniper的产品更像是美国跑车，快，不会拐弯，没内涵。
当时对n1000的v和n5k的几个产品是颇有想法，想仔细研究研究，无奈犯懒，就没写。也失去了稿费啊。
早知道当时写了，即使没稿费，也能在弯曲得个头彩，再树树我在网络圈的威。
此次本文，我是服了。好文！
但是，其实我一直有个想法，我们是沿着虚拟化这么看得，复杂之复杂化。
会不会有一个简单不需要复杂的东西呢？
这样搞下去，用户使用成本更高。
[*]sclzyb 于 2011-01-26 1:55 上午
1、很奇怪IEEE的trill在05年就提出来，为啥推动得这么慢，现在draft还只是个high-level的状态，几个核心问题oam机制，isis扩展，分发树计算方案都还只是个概念，根据draft还不能做出该功能，特别是控制平面，如DRB选举之类的东西。
相反SPB这个“弃婴”反倒找到了数据中心这个应用场景，内容更新得较快。（虽然我个人很不看好SPB的对于trill的竞争）
2、关于vm迁移中的不中断业务（在线迁移）的方案（IP，mac不变，业务不断），难道只能是arp的方式来解决，是否有更好的方法，也许两个管理团队（网络管理与服务器管理）的配合能更好的解决这个问题，至少不是等网络去被动的发现迁移，不过要这两方配合太不容易：）
3、关于VEPA的实现，我更多的是担心多播或者广播的问题，看各位大虾有比现有draft更好的解决方案
[*]CCC 于 2011-01-28 8:32 上午
altor 已经被JUNIPER收购，而且J也不仅仅是快而没内涵啊？
[*]旁观者清 于 2011-01-29 6:45 下午
to bigrong:
“09年的时候思科中国的朋友想让我写篇关于nexus的软文，给了我一堆ppt，还有一个上海的tme给我讲了一通，就觉得当时做datacenter，想搞虚拟存储融合，思科看得真的远。nexus强不在性能上，而是在内涵上。Juniper的产品更像是美国跑车，快，不会拐弯，没内涵。”
原来是专业人士，而且和思科的渊源很深哦，呵呵，佩服佩服，也怪不得没有稿费还在这里帮Cisco免费打广告呢，对于您这种敬业的精神很有感触。。。
顺便请教一个小问题，您了解Nexus的历史吗，能深入解释一下为什么Nexus的内涵如此之深吗？ 我们这些局外人没有渠道，对此又非常感兴趣，希望不吝指教。。。
页:
[1]
