云网络的宏大未来：大二层网络
作者 陈怀临 | 2013-01-08 11:12 | 类型 云计算, 数据中心 | 23条用户评论 »
|
[原文可参阅：bengocloud http://bengo.blog.51cto.com/4504843/795619］ 云计算催生了更多“离奇”的客户需求，云计算技术的迅猛发展也孕育出针对这些客户需求的更多更好的解决方案。大二层网络，这个曾经看来异常理想化的构想，就是一个非常典型的例子。让我们从需求案例说起: 客户需求一：我有n个数据中心，在硅谷的数据中心有一台VM，在北京的数据中心有另一台VM，我想让这两台VM，都感觉对方和自己处于同一个二层网络。 客户需求二：我有n个数据中心，在硅谷的数据中心有编号为A、B、C的VM，在新加坡的数据中心有编号为D、E、F的VM，在上海的数据中心有编号为G、H、J的VM，我想虚拟出三个二层网络：{A，D，G}，{B，E，H}，{C，F，J}。每个虚拟二层网中的VM，觉得自己和其余两台机器就像连在同一台交换机上一样；而三个虚拟二层网彼此隔离，处于不同虚拟网络的VM在二层网络上不连通，必须通过router交互。 第一个充满野性的需求，实质是要求一张广阔无垠的二层网络，主题是二层网络在WAN范围内的按需延伸。第二个需求看起来更加常规一些，但实现起来也并不容易。出于安全和性能考虑，硕大的二层虚拟网太过于平坦，从性能上来讲，广播帧会像洪水一样吃尽资源；从安全上来讲，没有隔离机制的海量VM组成的网络，既没有必要，也难以让人信任。 产品化的解决方案： 1. Cisco的OTV 永远不要低估业界巨头对技术潮流的把握能力！ 虽然是传统的物理网络供应商，但Cisco似乎在云网络的领域一直走在最前端。早在2010年2月，Cisco就推出了自己针对云架构的产品OTV（Overlay Transport Virtualization）。通过在硬件交换机上，采用扩展链路层网络的技术，它可以使二层网跨越数据中心。最吸引人的，是很多资料中宣称，OTV安装和使用的便捷性：据说安装OTV的流程只需要5条命令，耗时仅仅5分钟！从物理网络来讲，跨数据中心肯定数据包肯定要向上进入三层网络，通过路由，再到达目的端。这也就决定了二层广播帧不可达。为了实现这一目标，隧道技术的采用是不可避免的。OTV很自然地采用了MAC in IP的封装方式。 图1是使用Cisco OTV之后的网络效果图，图中处于VLAN 1的VM，事实上分布于物理网络上不同的数据中心，仅凭物理网络，无法直接二层通信。引入OTV之后，它们彼此认为自己处于同一个VLAN标注之下的一个二层网络中，广播帧可送达任何一台VM。 图1 OTV跨数据中心二层连通示意图
那么Cisco是怎么做到这一点的呢？在图2中你肯定能找到想要的答案。 图2 OTV工作原理示意图
很显然，Cisco既然是硬件厂商，那么改改自己交换机中的转发策略还是很easy的一件事情。要实现这一功能，技术细节很多，但简要来讲，他们是通过在交换机的MAC地址转发表上动手脚实现的。对于处于同一数据中心，物理二层网络连通的机器，在转发表中，对应MAC地址转发到某交换机端口。而处于不同数据中心的机器，它的MAC地址对应的转发目的地不是端口，而是一个IP，这个IP就是对方数据中心OTV模块的三层网络地址。本地OTV模块，会将需要跨越数据中心传输的二层帧，完整地打包到一个三层数据包中。通过路由，交付到对端OTV模块进行处理。接下来的，不用我说，相信你也了然于胸了。 Cisco的官方文档，强调了几点使用OTV的好处，作为自己产品的卖点。比如，对现存网络设施无影响；操作简单，并且可以与其它Cisco设备集成管理；没有在协议上动什么大手脚，复杂性低。其实最后一条也是Cisco解决方案的一大特点，毕竟么，人家可以轻轻松松改自己硬件产品的转发逻辑。相比之下，其它软件厂商给出的方案，就只能另辟蹊径了，通过在协议上做文章，达到同样目的，这个在后面会讨论到。 2. VMware的VXLAN 看完了硬件厂商的方案，我们再来看看虚拟化领头羊的前沿产品。VMware从一开始提VXLAN，其格局就比Cisco的OTV要大很多。VXLAN不仅着眼于二层网络按需延伸，更是在安全隔离上走的更远，从某种程度上说，它也可以被认为是对SDN概念的一次尝试。云时代的数据中心，从VM接入数量来说，本来就愈加庞大，再加上大二层网络技术的推广，一个平坦的二层虚拟网络上连接百万台以上的VM也许不再是什么痴人说梦了。要对百万级别VM的接入，在二层做到很好隔离。传统的VLAN技术表示它要疯了… 为此，在2011的VMworld大会上，Cisco与VMware共同提出了VXLAN技术，在业界引发巨大反响。（怎么云网络里哪儿都有Cisco的事儿？呵呵，这也印证了上一篇博文里说的Ecosystem观点，大家都在生态圈里占地盘，Cisco为了云战略就和VMware走的很近，长期partner） 目前VXLAN已经提交了IETF草案，在努力朝着标准化的方向前进。站在这一阵营的包括VMware、Cisco、Arista、Broadcom、Citrix和Redhat，怎么样，这个团队看着还不错吧。 软件厂商没法修改硬件的转发策略，那么VXLAN就充分利用了IP多播技术。通过IP多播技术，在UDP包中，完整封装VM的二层数据包，达到跨数据中心，跨路由的目标。由此而形成的虚拟二层网络，其上的VM认为自己处在一个真实的二层网络中，但实际上，有些广播帧却是在VXLAN的协助下，通过三层网络送达远端数据中心里的VM。因此，在业界也有一个好玩的说法，称VXLAN“坐在2.5层”。 VXLAN定义了相应的协议，图3是其数据包格式图： 图3 VXLAN数据包格式
VXLAN的具体实现十分复杂，对于虚拟交换机来说，需要data plane的支持，在VMware的产品中，为了支持VXLAN，对位于ESX之上的vSwitch，vDS等kernel module模块都做了大量改动。这个问题如果展开，不是一时半会儿能讨论完的，我们这里就不做详细分析了。选择几个比较有意思的切入点分析一下： 隔离能力的扩展：传统VLAN tag只有12位，在云里，4096这个极限怎么看怎么不够用。VXLAN在网络隔离时，采用的VXLAN ID（图3中第7个字段）有24bit，可以划分出高达1600万个相互严格隔离的虚二层网络，目前看来这样的扩展性是远远足够的。 图4 VXLAN网络示意图
对跨数据中心，跨物理VLAN的热迁移提供支持：使用VXLAN之后，原来局限于同数据中心，同物理二层网，同样VLAN的vMotion，现在可以不受这些限制，按需扩展到虚拟二层网络上的任何地方。这是一个非常令人激动的进步！ 不足：由于VXLAN基于IP多播原理实现，而现实中很多路由也许不支持PIM，或者虽支持多播，但出于某种原因，路由默认情况下未配置。就会有问题。不过这个可以通过其他技术手段改善，如加入proxy机制加以解决。 3. 微软在做什么？ 在这场轰轰烈烈的大二层网战役中，哪个大厂商也不甘落后，话语权就是商业利益啊！VXLAN出来没多久，Microsoft就联合Intel, HP& Dell 提出了NVGRE标准（NetworkVirtualization using Generic Routing Encapsulation）。说白了也是一种Mac In IP的解决方案，但是与VXLAN不同，它使用GRE (Generic Routing Encapsulation) key的低24位作为二层虚拟网络标示符，进行隔离。同样是24位，同样是1600万个子网容量！我怎么看怎么觉得像VXLAN，比较好奇性能上会有大不同么？如果没有大创新，为什么搞这么些标准出来… | |
 (7个打分， 平均：5.00 / 5) |
雁过留声
“云网络的宏大未来：大二层网络”有23个回复
是否可以考虑基于MPLS的组播上运行大二层？
NvGRE相对VxLAN在load balance方面有天生的缺陷。对于传统的三层网路设备，基本都可以实现基于四层port的load balance，但是却无法实现基于GRE key的低8个bit的load balance。这也就导致了NvGRE在实际应用中的局限。如果不考虑legacy，完全用新的chip和设备，这二者可以说没有什么区别。
VXLAN and OTV use very similar packet format, so the hardware already doing OTV encapsulation (Nexus 7000) could be used to do VXLAN termination. Boy have we been suckered.
首席，我提个问题，第一个应用，不就是L2VPN么，用搞这么复杂吗？
这里要解决的无非是两个问题：
1、IP地址不变迁移问题；
2、虚拟机下用户隔离问题。
前者不是大问题，一些简单的方案就可以解决；
后者才是大问题，其关键是在最靠近服务武器的IDC设备上，最左需要多少个instance来隔离VM？如果最大也不超过4K，那么用L3VPN是可以考虑的，当然VSI可可以，为什么一定要用VLAN/QINQ，因为这个成本最低，比VRF/VSI消耗系统资源少几个数量级，所以就便宜，我们可以假定4K是分界线，有没有人知道这个值实际是多少？
用VPLS是可行的，VSI不够，可以往高放，但问题是VPLS在MPLS网络的负载分担部不够好，当然这个也有解决方案，但VPLS最大的问题还不是这个，因为VPLS不能直接到服务器的最边缘，所以就存在以太环路问题和进入VPLS前的负载分担问题。
所以综合考虑成本因素，还是不得不折腾些新协议来解决这个问题。
如果实际IDC组网，是使用超级的，比如几百至上千的GE/1OGE接口的单交换机接入，此时VPN instance可能会是个问题，但是，工程上，这样的交换机是否带来可靠性问题，比如实际工程上，接入交换机是不能超过100个端口的，因为太多服务器接入一个交换机，交换机down机带来的影响太大，即使用MC-TRUNK接入服务器，也未必好？如果有这种工程潜规则，那么前面的VSI/VRF到边缘的方案又可能活过来了。
所以这里的判断不好纸上谈兵，请做大型IDC实际设计的人给一些业界标准的工程数据和趋势，才好比较。
我对网络已经生疏了8年了，已经是外行。这里有个基本的问题请教，为何用户必须要求两个不同子网的VM在一个2层广播域里？何出此需求，本源在哪？有什么应用必须用广播通信？或者出于效率考虑？如果仅仅是为了转发效率考虑，那就自相矛盾了，虚拟一个二层网难道比用普通路由效率还要高？那就相悖了。那么原因似乎只有第一个，也就是某些应用，或者基于运维等各方面需求，必须用广播，我咋也想不出来这种需求到底为啥会出现？或者是Vmotion？迁移VM必须使用广播么？
vxlan对于多租户隔离确实有很大好处；vCloud+cisco的整体解决方案和当前开源的iaas系统确实也拉开了差距；但虚拟化后IO的性能一直是个头疼的问题？
主席，有没有了解过SR-IOV后，vxlan技术在各个厂商都是怎么玩的？
另外，SDN在这方面优势也很明确，不清楚vmware收购Nicria后，网络这块是怎么个玩法？
IP地址不变这个需求，主要的目的是为了满足 迁移后不影响业务的问题。
又为了满足 跨地域组网，又搞出 大二层组网的概念。
to 冬瓜头：
跨数据中心二层主要是解决VM跨数据中心迁移的问题，当一个VM从一个DC迁移到另外一个DC时，为了保证业务不中断，此VM应保持IP地址不变，而它与仍然在原DC的其他VM之间可能有二层连接的需求。
例如：一个DC里面10个VM在一个负载均衡的组里面，当其中的一个VM迁移到另外一个DC里面去的时候，就会出现跨数据中心二层胡同的需求。
至于说广播，以太网的广播很多啊，典型的是两种，某台交换机找不到MAC地址就要广播，ARP也要广播。
其实未来网络技术的方向是不确定的，要解决的问题有好几个，解决每个问题的办法都有好多。不同的厂商出于自身的技术优势商业利益都会选择不同的方法，其结果就是五花八门。就算思路差不多，细节上也会差一些（比如VXLAN和NVGRE），然后互相PK，赢得继续当老大，输得变成诺基亚。所以说现在是一个好玩的变革时代。
to aaa：
现在TOR是潮流，EOR/MOR都有式微的感觉。TOR模式决定了一台交换机的接入不会有成百上千的端口，但是现在厂商多合一虚拟化其实可以起到类似的效果。
J家的QFabric是最典型的代表，号称整个DC只有一台交换机。
C家的N7K/N5K当引擎，N2K当接口卡的模式也是类似的效果，可以认为是把QFabric的Director 集成进机框的方案。当然QFabric也可以认为是C家这个方案把Director从机框里面拆出来。
近期，H3也有了类似的方案，也即所谓纵向虚拟化，应该是把IRF2做了修改和延伸。
如上，其实一个多合一虚拟化之后的虚拟交换机，就是有几千个千/万兆接口的一台交换机。高级网络特性部署到边不是不可能的。
其实云计算遇到的问题，各个厂家在自己现有的产品框架里面都可以找到相应的方案，就算现在没有，未来也可以有。但是所有网络厂家在这里都遇到的一个问题是，他们无法控制物理服务器内部，多个VM之间的那个虚拟网络，他们都需要虚拟机厂家的支持。
而现实是，有一堆要逆袭的Startup们站出来了，挥舞着SDN/OF的大旗，提供纯软件的网络解决方案，解决云计算遇到的那几个问题。他们的口号是：“打倒厂商霸权，消灭暴利，把网络交给用户自己控制。”他们的方案中，传统的网络只要简单可靠、便宜傻快的互联就可以了，只需要提供最基本的二三层互通即可，不要MPLS，不要大二层，什么都不要，所有的高级网络特性都由他们来实现，而他们只卖Controller做控制，转发有开源免费的VSwtich来做。在他们的世界里，DC只需要6000块的48口千兆交换机做接入，最好不超过10万块的C65/S75E/S93做汇聚，汇聚之间跑OSPF即可，ASR/NE20E/SR66做出口，只要性能够即可，其他神马QoS，神马组播，神马MPLS，神码VSS/VPC/IRF2，不需要，统统不需要，Controller会解决一切。这些SDN/OF的Startup以革命者的姿态闯入了传统网络厂商的世界，又受到了诸如Google等早就看C/J不顺眼、什么都想自己搞的互联网公司对他们技术路线的认可，现在已经形成一股潮流，受到了资本的追捧。
总之，现在的网络市场，一方面传统的互联网公司在互掐，拿着大同小异的类似技术互相指责；一方面SDN/OF的Startup蠢蠢欲动，玩命的忽悠，而传统厂商又不敢跳出来明确的说不对，乱成了一锅粥。但抽茧拨丝，其实技术还是有脉络可循，这个脉络就是各个厂商都会最大限度的发挥自身的技术优势，而不是否定它。所以未来的技术无非是两条路：一条是传统网络厂商一定会走的“软标签、硬转发”的路，也就是通过软件打上各种标签，网络设备基于这种标签建各种隧道做各种转发；另一条路就是Startup们一定会走的“端到端软隧道”，把传统网络作为基本的IP传输和承载，在此基础之上，在DC内甚至跨DC的物理服务器之间建立各种隧道，自己做转发。当然，这两条路线也会相互妥协，会出现一堆的似软实硬，似硬实软的东西。
首席有没有调查下，HW在做什么应对？
zeroflag很强，SDN的终极目的是司马昭之心路人皆知，也是正确的网络革命之路，虽然这种革命有些像对之前传统电路交换的文艺复兴再包装。但是现实到理想之间有多远，不好说，怎么也得5-10年，当然，IT的速度和网络的速度之间是个互相依存的关系，目前看是IT快于网络，所以IT要领头网络的命，所以SDN才能成为今天网络vendor不得不关注的热点，我估计SDN在网络的商用要10年，在IDC的流行，可能不需要那么久，也许5年就可以了，但就IDC来说，是否是这种革命式风暴，还需要博弈，SDN要成为主流，应该需要做合理的妥协，比如VPLS到接入交换机就是一种可能，每个交换的转发支持VPLS，有broadcom等海量L2芯片的支持，成本是可控的，但控制层面的成本比较高，所以此时采用SDN的转发与控制分离，走集中式控制，能有效降低capex和opex，提高运维管理效率。考虑到集中式可能的风险，把集中式在分不到每个交换机的低成本CPU上，是进一步的演进。
SDN对嵌入式多核处理器是个不错的机会。可以快速实现原型验证，快速发布产品。
大二层有点扯，有了routed vmotion和overlay SDN，为什么还要大二层？
之前的评论都很不错，全是有经验的网络玩家。对大二层，我只想补充：性能也是一个考虑。传统二层运行STP/RSTP，导致50%带宽被浪费，而且无法保证最优路径。大二层希望构建Ethernet Fabirc，基本上是照搬FC Fabirc的做法。
什么是routed vmotion？？
其实我一直在想，为啥一定要IP不变？为啥一定要网络层实现这些需求？真正需要永不中断的业务掐指头也没多少吧，银行网银升级还不能办业务呢。为啥就不能由应用层的程序来解决这些问题，比如软件设置两个server，同时保持连接，server之间关键数据同步，一个down了客户端可以去找另一个server，IP变更了可以由另一个server通告变更后的地址……
为什吗一定要大二层呢？这些问题为什吗一定要有网络层来解决呢？完全可以通过应用层的设计来解决啊
问题在于，如果你是做公有云，你是没办法控制客户的，所以无法要求应用解决地址不变的问题。
to ckck:
同意你的看法，其实很多问题，应用层解决起来是最方便的。
问题的关键在于：卖东西时，需要pk掉对手，体现自己的优越性，所以 大二层网络、跨站点的虚拟机迁移的特性就都来了。
to 陆小宇
如果是公有云，真的需要虚机的无缝迁移吗？
所以我认为大二层应该不是实际业务驱动而是竞争的需求吧
to ckck，虚机无缝迁移这种事情，共享存储的主机集群里面做就可以了。麻烦的是有些客户的程序要求是二层互通的，比如hadoop的集群，和一些老式的集群软件。
To ckck
二层能解决的事情就不要让三层解决，网络本身能提供的事情就不要让应用来解决，每一层专注于自己的事情，这个是网络分层之所以能成功的原因。
就上面的硬件与软件解决方案之争，我是这么认为的：没有什么是技术解决不了的，只有代价大小与成熟度问题，如果作为局中人，看清楚自己的屁股，然后对得起自己的工资就行了。