作者:佚名 2018-06-27 15:49:39
云计算 为解决SDN交换机OpenFlow流表条目有限的问题,UCloud开始采用DPDK技术的网关集群来替代SDN交换机。经过实践检验的各种DPDK网关,越来越多地出现在UCloud的云平台中,为用户提供更快速的网络能力。
自2012年UCloud成立起,虚拟网络始终是IaaS产品的一个核心组件,也经过了多次演进。演进中我们始终思考的是:如何在不增加用户成本的情况下为用户提供更可靠、更快速的网络。而答案则是要求技术团队不断采用新技术,来同时满足租户隔离、转发能力、稳定性等多种需求。
[[237371]]
我们最早的SDN方案在转发面是采用Open vSwitch(以下简称OVS)来实现,控制面是自研的控制器。期间亦首先采用盛科的SDN交换机,来解决物理机(bare metal)和公有云之间的互访需求。为解决SDN交换机OpenFlow流表条目有限的问题,UCloud开始采用DPDK技术的网关集群来替代SDN交换机。经过实践检验的各种DPDK网关,越来越多地出现在UCloud的云平台中,为用户提供更快速的网络能力。
DPDK的不足
随着2017年25G网络开始迅速被采用,对UCloud的虚拟网络又提出了更高的挑战。在此背景下,DPDK也逐渐暴露出了一些不足:
两个被排除的方案
2017年中UCloud开始对新的SDN硬件卸载方案做评估。
首先进入我们视野的是基于VXLAN VTEP的解决方案。此类方案通常由交换机厂商提供包括SDN Controller在内的整套解决方案,比较适合私有云的环境部署。但缺点也很显而易见:封闭、非标准化、无法定制。通常用户只能通过北向厂商特有的API方式和此类方案进行交互。且此类方案通常只支持10w左右的虚拟网络MAC地址,很难满足UCloud的业务需要。此外UCloud对基于Ethernet Over GRE(Linux GRETAP)的Overlay封装有需求,但没有一家硬件交换机支持该Overlay协议。
接下来我们又把目光投向了支持OpenFlow 1.3协议的硬件交换机。经过一番预研和测试,我们发现支持OpenFlow 1.3协议的硬件交换机和OVS间存在着巨大的GAP。实际上不可能把我们的OpenFlow流表移植到硬件交换机上。除了同样不支持Ethernet Over GRE协议外,我们OVS上使用的Flow Based Tunneling特性也没有硬件交换机支持。
P4进入视野
2017年Q4,我们开始预研Barefoot的支持P4的可编程交换机(Tofino芯片),很快发现了它能够很好地满足我们的需求。
提到P4和Barefoot就不能不提Nick Mckeown教授。2007年Nick和伙伴们一起创立了Nicira Networks公司,也几乎标志着“软件定义网络(SDN)”这个产业的诞生。Nicira作为OpenFlow的大本营,接连发布了NOX和Open vSwitch作为OpenFlow的重要组件。
2012年VMware收购Nicira后,Nick认为SDN的第二步则是发展为它专门优化的硬件设备,又和同伴共同发起了对数据包进行处理的编程语言P4(Programming Protocol-Independent Packet Processors),帮助网络用户摆脱芯片硬件厂商各种协议的制约。
P4在设计上具备如下优点:
2013年Nick成立了Barefoot Networks公司,致力于开发基于P4的网络芯片Tofino和软件开发套件Capilano,并帮助P4社区发展壮大。
Barefoot支持P4的可编程交换机(基于Tofino芯片),具备如下优点:
相对DPDK更高的转发性能
相对其他硬件交换机,更开放
P4 Switch架构
控制面实现
最初我们准备修改Barefoot提供的switch.p4来实现我们的功能,但尝试阅读代码后发现switch.p4虽然完整的包含交换机所需要的功能,但很多特性我们并不需要,所以我们没有选择修改、裁剪switch.p4,而是自己从头开始写一个更符合自身需求的控制面。
NOS这层参考我们之前开发DPDK程序的经验,完全通过Linux来实现。P4代码会把所有非Ethernet Over GRE封装的报文当做控制报文送到CPU口。CPU口在Linux上就是一个虚拟网卡,报文再通过Kernel转发到hostif的虚拟网卡上。hostif的虚拟网卡上配置IP地址,ARP学习等功能都通过Linux Kernel来实现。Quagga等Userspace的程序就通过hostif虚拟网卡上的IP和上级路由器跑BGP,再将学习到的路由写到Kernel的路由表。我们直接开发的APP模块以bf_switchd插件的方式加载,通过netlink接口学习Kernel的ARP表、路由表,调用P4代码编译后生成的API写入Tofino芯片。
Controller这一层最早我们是通过P4编译器生成的Apache Thrift接口将数据下发到bf_switchd,然后写入Tofino芯片。但通过简单的性能测试发现,由于Apache Thrift接口设计的限制,每次RPC调用只能配置一条数据,因此需要配置大量数据时性能很不理想。为此我们在APP模块中启动了gRPC server,重新定义了批量下发配置的接口,将配置下发速度提升了8倍。未来我们计划将控制面演进到P4 Runtime和Stratum。
Sharding
P4可编程交换机的PPS或者BPS性能很强能够线速转发,对比DPDK,制约单机性能的瓶颈主要出现在交换机的DRAM和TCAM上。毕竟DPDK跑在X86服务器上内存64G起步,512G也不稀奇,而交换机芯片上的内存资源就相对要少很多。
为了突破单台交换机的资源瓶颈,我们设计了将数据按租户分片的方案,从而实现了水平扩展的目标。
首先采用64口P4可编程交换机作为接入层,主要实现数据分片和灰度发布的能力。例如采用VNI的后6位分为64个分片,为每个分片指定一个下一跳地址,从而达到整个集群的资源水平扩展的能力。
强灰度能力
传统上网络设备通常采用主备、或者主主的方式部署,当需要升级的时候将全部流量切到一半设备上,另外一半设备下线升级,升级完成后再重新加入集群分担一半的流量。这种升级方式简单粗放,在UCloud我们提出了更高的要求。我们软件行业的现状就是不论花多大的成本去测试,真正的用户行为总是不可能被穷尽的,缺陷总是会有的,这时我们***的安全网就是“灰度发布”。在现网真实环境作为***测试的同时,通过控制变更范围尽可能的减少风险;一旦真的有缺陷快速回滚,***程度的降低影响面。在UCloud我们坚定的在每个产品上采用按账号灰度发布,即使是在虚拟网络设备上。
我们将灰度发布交换机软件的能力Buildin在Access层:
通过这种传统网络设备完全不同的升级方式,在SDN软件快速迭代的背景下,有力地保障了SDN网络的可靠性。
P4 Switch应用
目前UCloud已经采用P4可编程交换机完成了新一代交换网关UXR的开发和测试工作,同时部署了一个地域并切换灰度流量进行验证。
总结
Barefoot的Tofino芯片在2018年初量产后,P4可编程交换机开始逐渐出现在市场上,但仍是一个新兴事物。不可否认目前确实还有一些不足之处,但UCloud确实看到它和之前的交换机相比,能给软件工程师***的自由度。
在6月27日Barefoot CEO Craig Barratt先生一行来UCloud总部的技术交流中,大家也认为通过紧密合作,能够产生更加贴切需求、切实解决痛点的可定制解决方案。我们相信凭借持续的技术演进,可以不断为云平台用户提供更快速更强大的网络能力,就像Barefoot主页所说,We can now finally say “Software is eating the network”。
参考链接:
标题名称:UCloud基于P4交换机的云平台网络实践
标题网址:http://www.shufengxianlan.com/qtweb/news31/434981.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联