云网络的宏大未来：大二层网络

云计算催生了更多“离奇”的客户需求，云计算技术的迅猛发展也孕育出针对这些客户需求的更多更好的解决方案。大二层网络，这个曾经看来异常理想化的构想，就是一个非常典型的例子。让我们从需求案例说起:
客户需求一：我有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，比较好奇性能上会有大不同么？如果没有大创新，为什么搞这么些标准出来...

时间关系，今天就先覆盖这两种比较主流的方案，对NVGRE仅作简单介绍。谢谢大家关注！欢迎回帖讨论！本文出自 “BengoCloud_bibo” 博客，转载请与作者联系！