阿里巴巴庞俊英：OpenFlow与VxLAN在云网络的应用

ZDNET网络频道 05月19日 综合消息：今日，在“2015全球未来网络暨SDN技术大会”的“NFV技术专场”上，有一个亮点不得不提，唯一的一位女嘉宾，来自阿里巴巴的首席架构师庞俊英，为我们介绍了OpenFlow与VxLAN在云网络的应用。

以下是演讲速录：

我叫庞俊英，来自阿里巴巴技术保障部，我们部门负责整个阿里集团所有业务如蚂蚁、淘宝、阿里云等等业务部门的基础设施。两年前我来过这里，去年没来，因为觉得去年没什么可讲的，所以这次我向大家汇报内容的是有一个连续性的，就是我前年提了哪些问题，这些问题现在解决了吗？然后还有哪些问题还需要解决，我希望业界帮我们做什么，我会是这样一个思路来向大家汇报。

我是个工程师，所以我的PPT里面如果有很漂亮的图，一定是盗图，如果有横的竖的拓朴图一定是我画的,所以看到熟悉的漂亮图请原谅我。

来看这张PPT,今年的这些问题是不是还是存在的？第一个网络的复杂性带来网络一直的停滞不前，是不是还存在？原来像计算、存储这20年里已经从原始人进化到拿着IPAD，但网络的运维和配置是不是只从telnet进入到SSH? 今年是不是真有了变化？ 第二个，很多复杂的东西，今天是不是还是这么用呢？第三个，提了这么些年弹性，是不是解决这个问题了。大家从前讲的SDN交换机这个会不会真便宜？我在阿里巴巴差不多五年前就在做了自研交换机，很多人问这个问题。 所以想跟大家汇报一下上次这些问题的进展。还有一个问题，这张图也是两年前大家见到的，大家说不清楚SDN是什么，说不清OPENFLOW是什么，后来又说SDN和NFV是什么关系，有个天才画出这么一张图，大家各说各话。这个答案是什么呢？我的回答是：半信半疑。因为能看到的东西，看到了，所以我们相信了，没看到的东西还是没看到，所以我们怀疑。这没关系。 我今天跟大家汇报的是一个真正的case，它正在发生的一个网络的变化，你说是变革也好，继承也好，但是它的的确确在发生着质的变化，通过我向大家的汇报，希给大家一个信心，也是给产业链一个信心，这件事情是可以做的，我们自己也是有收益的，我们自己还是满意的虽然还有很多不完美。在很早之前大家就一直在争论在数据中心内部OPENFLOW是不可以用的，那我们也在思考，就是这个东西能不能用，我们会遇到哪些问题。 这里简单的列了几点，我们考虑在数据中心网络里面用OPENFLOW和VxLAN做驱动力有哪些，这些动东西是不是今天成为了现实。

第一个是大规模的部署的问题。在规模小的时候，二层就解决了，当到了一定的规模就会有人提到大二层的各种技术，当然我们也是一步一步走过来的。现在一出门都是万台服务器或者几万台服务器规模，任何一种纯大二层技术都不能好好地工作。还有很现实的一个问题，就是VM一定要迁移，怎么办？那这就是我们必须从传统的二层技术向这个Overlay变迁，那我们该选择哪种技术？VXLAN/NVGRE/TRILL? 第二个是扩展性的问题，第一个问题是大规模后带来的扩展性的问题，如果采用一个一个小集群那么的池化的能力一定会被降低，因此选择是Underlay与Overlay的分离。公有云的规模交付如同流水线方式的制造虚拟机，管理成本体现在供应链的能力、交付能力等等。网络的弹性能力也成为了刚性需求，如何做自动交付和变更。最后一个需求要面对的一个问题，就是混合云的存在，有的物理服务器就是不能够虚拟化，但是这个物理服务器跟你的云之间一定要连通的，所以混合云是一个很刚性的需求。网络隔离对弹性的要求也是刚需，要求分钟级变换overylay完成isolation的不同业务。

这张图说明具体实现。左边是Overlay和右边的Underlay，其实它们在物理是在一起，在上面有阿里云的管控系统，原理是这样的，当一个VM创建的时候，云管控系统通过北向通知SDN Controller一个VM要构建了，当这个VM被点亮时，第一个转发面的报文是ARP，TOR交换机截获ARP，通过openflow的packet in上送controller, controller将北向和南向数据匹配后，通过packet out向Hybrid switch下发转发表项。Unerlay和Overlay的部署交付全部是通过自动化方式完成，网络工程师不用配置一条CLI，交付通过python的script，更变通过Netconf。再看下Overlay这一层，大家可以看一下，这里画的有蓝色的，有绿色的，有橙色的，这表示是一个二层域，用VxLAN隔成的二层域。网关是放在最上面的Spine switch。在这里标记出来用到提Openflow Hybrid switch。它们用Openflow接口与Controller交互。

总结一下，在这个网络方案的几个重要Feature说明。第一个，所用的芯片，全部是商用芯片，没有任何定制。Openflow hybrid switch是商用交换机。Overlay这个平面与物理拓朴无关，这里只是象征性在中间画一个节点，大家一定见过facebook最新发布的立体的Fabric，物理网络拓朴无论CLOS还是传统的树状架构，Overlap对物理架构无关。只要一头一尾是一定要能够支持Overlay的，我们的Overlay选择了VxLAN。物理网络集群我们由于流量吞吐及集群规模要求是比较高的，因此我们选择多平面超大规模CLOS架构并且是BGP到边，即TOR switch开始一路向上全是EBGP。在管理这一块，很清楚的大家可以看到，就是用一个API去做部署、管理。关于VM的迁移域，北向云控制系统。南向有Openflow和Netconf同时也支持OVSDB。我后面也会讲控制器的一些取舍。整体网络的考量是通过Controller管理及下发ARP和MAC，去掉由于自学习所带来的二层网络里天生BUM问题。
SDN的全景图是我心里的一个愿景。虚拟的网络层在IDC内部已经搞的比较清楚了，但在不同的区域之间，比如北京、上海、广州之间的WAN的虚拟化层还没有想清楚用哪种方式实现。在这张图里刻意画出的蓝色部分，它表示支持overlay的标准协议和openflow协议， 我们看到无论是一个物理服务器，比如说IBM的主机，它是无法支持虚拟化技术的，我们通过TOR交换机支持VXLAN来提供类似IBM主机类型的服务器与虚拟机互通。同时对数据库的支持也是相同的。还有NFV和Service Chain是通过x86服务器的同样也可以与虚拟机互通。路由器通过PCEP或BGP-LS也可以实现SDN化，光这一层也可以SDN化，IP网、传输网做一个统一调度，统一视图和流量管理。所以从SDN的全景图来说，任何的网络设备，都可以实现转发面与控制面的分离，以达到统一调度、全貌视图、自动交付和弹性。

在这张图对应一个混合云的网络架构里面，可以通过VxLAN做租户的隔离，这里有蓝色的租户，有红色的租户。这个黑色的点是我们今天的用法，用的是Openflow hybrid switch。 它可以很好地支持embedded 在x86服务器里的softswitch作为VTEP，也可以用TOR switch做VTEP，支持NFV的服务器做VTEP, 支持Spine switch做VTEP，这些隧道非常灵活。同时任何配置的变化都是通过Controller自动下发完成。
这是我们所倡导的P+V的理念和体系架构，路由器、交换机，基于x86服务开发的网关型服务， 纯软件的Software switch，统一归属于Farbric这个框里。这一层网络设备只要能够支持VxLAN这个协议，支持OPENFLOW的接口，或是OVDB甚至是私有协议都可以实现我前面那张图讲的灵活并按需构建自己的虚拟的网络层。

再往上，因为NFV是介于业务和基础架构之间的特殊的一层，所以把它放在夹层，NFV可以基于SDN架构提供很灵活的vRouter/vFB/vLB等等业务。在上面我们看到的业务系统，云的业务系统，流量调度系统等。这是我们倡导的P+V的虚拟网络架构的这样一个框架。

在我们的实践里面，解决了哪些问题，大家也可以看到，通过overlay和underlay两层的分离后，网络对业务的支撑变得很灵活，今天可以提供一个整网，一个二层域，也可以把它拆分成不同大小的租户的隔离的虚拟网。原来在网络运维里，链路的探测都是非常非常难做的，通常的作法是端到端通过在两台服务器之间发ping或是特定类型的流，但仍不能很好地迅速查出哪个交换机的哪个端口出现了silence drop并主动隔离这个端口，而且这些动作是不需要人工干预的。现在我们的网络里非常容易就能实现这个从前想都不想的动作。

最后一条打叉的是SDN并没有省钱，我是这么来看待这件事情的，前面五条好外都得到了，网络建设成本并没有提高，那就算是省了钱，当然这只是现在的情况，我还是希望通过这个real cast推动行业的里的产业链上合作伙伴通过更好的抽象层和统一接口的定义共同将SDN网络架构向更低建设成本前进。

这一页列出仍然存在的问题，今天我跟大家开放的讲这个架构和case，是希望产业链的同仁们，还有其他的用户来共同倡导这样的开放、标准、具有很好抽象的SDN网络架构理念，我们已经看到原来大家都不相信OPENFLOW，然后到承认OPENFLOW有问题，到现在有了Realcase。当然，我们也是觉得OPENFLOW是有问题的。但是我们觉得这条路是可以走下去的，产业的这么多同仁都来做，真的可以把这个事情做的很好的。如果那一天发生的话，单一厂家锁定去掉的话，成本自然而然可以便宜下来。 由于在转发面，我们还是用了传统的方式。在控制面做了一些调整。所以并不能实现真正的不中断交换机软件升级，在SDN标准框架里面讲的Purely switch的这点好处我们没得到，原因就是openflow现在芯片的能力还达不到全SDN化，这一层还没有完全做到，这点要是能够做到的话，需要在芯片公司的芯片Openflow的能力。当然未来它不叫OPENFLOW，我们也不用纠结，这个产业会往前走，就有看到希望统一的。而我们今天的确在用OPENFLOW这个接口，并且是用于数据中心网络上。

我还想提下南向的标准化，其实南向和北向的标准化都有这个问题，南向还好，但是今天的北向，大家都说用户不一样，业务不一样，没法统一接口API， Controller的标准化、北向接口的标准化、更好的抽象层都将是助力SDN更大规模落地的重要因给。还有一点是我们现在使用的交换机openflow hybrid交换机，一旦走到Purely openflow交换机、网络管理、运维、调度、弹性等等想象空间会更大。

最后我列的一点是关于Peopole，我发现我们的网络界，真的是软件太软，硬件太硬。前段时间参加培训，跟很多小孩在一起的时候，发现他们对网络的理解非常非常少，做网络开发的的人不理解网络，那么传统网络工程如何能认同他们开发出来的东西呢？同样，传统网络工程也常常质疑SDN控制器的可用性、可靠性等等，但又无法将网络思想向开发同学表达。在网络界，我们缺少一个全栈的架构师。

最后因为时间也到了，通过最后一张图，表达网络的SDN化是我非常Belive的，它可以根本性地提高网络的可运维性、更弹性、可视性。我也会在行业里面和在我的同事去倡导这样一个思想，网络的SDN化一定会促成NETops会向DEVTops转型,谢谢大家。