分类: 系统运维
2011-01-17 23:01:52
一、为什么虚拟化数据中心需要一台新的交换机
随着虚拟化技术的成熟和x86 CPU性能的发展,越来越多的数据中心开始向虚拟化转型。虚拟化架构能够在以下几方面对传统数据中心进行优化:
正是由于这些不可替代的优点,虚拟化技术正成为数据中心未来发展的方向。然而一个问题的解决,往往伴随着另一些问题的诞生,数据网络便是其中之一。随着越 来越多的服务器被改造成虚拟化平台,数据中心内部的物理网口越来越少,以往十台数据库系统就需要十个以太网口,而现在,这十个系统可能是驻留在一台物理服 务器内的十个虚拟机,共享一条上联网线。
这种模式显然是不合适的,多个虚拟机收发的数据全部挤在一个出口上,单个操作系统和网络端口之间不再是一一对应的关系,从网管人员的角度来说,原来针对端口的策略都无法部署,增加了管理的复杂程度。
其次,目前的主流虚拟平台上,都没有独立网管界面,一旦出现问题网管人员与服务器维护人员又要陷入无止尽的扯皮中。当初虚拟化技术推行的一大障碍就是责任界定不清晰,现在这个问题再次阻碍了虚拟化的进一步普及。
接入层的概念不再仅仅针对物理端口,而是延伸到服务器内部,为不同虚拟机之间的流量交换提供服务,将虚拟机同网络端口重新关联起来。
二、仅仅在服务器内部实现简单交换是不能的
既然虚拟机需要完整的数据网络服务,为什么在软件里不加上呢?
没错,很多人已经为此做了很多工作。作为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,这一下就把对虚拟机 网络管理的范围从服务器内部转移到上联网络设备上。
思科针对VN-Tag推出了名为Palo的虚拟服务器网卡,Palo卡为不同的虚拟机分配并打上VN-Tag标签,上联交换机与服务器之间虽然只有一条网 线,但通过VN-Tag上联交换机能区分不同虚拟机产生的流量,并在物理交换机上生成对应的虚拟接口VEth,和虚拟机的VIF一一对应,好像把虚拟机的 VIF和物理交换机的VEth直接对接起来,全部交换工作都在上联交换机上进行,即使是同一个物理服务器内部的不同虚拟机之间的流量交换,也通过上联交换 机转发。这样的做法虽然增加了网卡I/O,但通过VN-Tag,将网络的工作重新交回到网络设备。而且,考虑到万兆接入的普及,服务器的对外网络带宽不再 是瓶颈,此外,利用Cisco Nexus 2000这种远端板卡设备,网管人员还能够直接在一个界面中管理数百台虚拟机,每个虚拟机就好象在传统的接入环境中一样,直接连接到一个交换机网络端口。
目前,思科推出的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评价聪明的设计,得到业界广泛支持,故事结局如何,还待静观其变。
chinaunix网友2011-03-09 09:16:21
很好的, 收藏了 推荐一个博客,提供很多免费软件编程电子书下载: http://free-ebooks.appspot.com