自2012年UCloud成立起,虚拟网络始终是IaaS产品的一个核心组件,也经过了多次演进。演进中我们始终思考的是:如何在不增加用户成本的情况下为用户提供更可靠、更快速的网络。而答案则是要求技术团队不断采用新技术,来同时满足租户隔离、转发能力、稳定性等多种需求。
我们最早的SDN方案在转发面是采用Open vSwitch(以下简称OVS)来实现,控制面是自研的控制器。期间亦首先采用盛科的SDN交换机,来解决物理机(bare metal)和公有云之间的互访需求。为解决SDN交换机OpenFlow流表条目有限的问题,UCloud开始采用DPDK技术的网关集群来替代SDN交换机。经过实践检验的各种DPDK网关,越来越多地出现在UCloud的云平台中,为用户提供更快速的网络能力。
随着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特性也没有硬件交换机支持。
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更高的转发性能
– 1.8T ~ 6.5T线速转发
– 更低时延
– 单线最高100G,避免单线拥塞
– 转发性能可预期,DPDK的转发性能随业务模型可能变化
– 相对其他硬件交换机,更开放
– 可编程能力强,转发面p4lang定制开发
– 完美解决Ethernet Over GRE和Flow Based Tunneling的问题
– 开发效率高
– 控制面可通过Apache Thrift、gRPC接口远程管理
– 操作系统采用 Open Network Linux(基于Debian)
– 生态圈:P4 Runtime、Stratum
1.控制面实现
最初我们准备修改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。
2.Sharding
P4可编程交换机的PPS或者BPS性能很强能够线速转发,对比DPDK,制约单机性能的瓶颈主要出现在交换机的DRAM和TCAM上。毕竟DPDK跑在X86服务器上内存64G起步,512G也不稀奇,而交换机芯片上的内存资源就相对要少很多。
为了突破单台交换机的资源瓶颈,我们设计了将数据按租户分片的方案,从而实现了水平扩展的目标。
首先采用64口P4可编程交换机作为接入层,主要实现数据分片和灰度发布的能力。例如采用VNI的后6位分为64个分片,为每个分片指定一个下一跳地址,从而达到整个集群的资源水平扩展的能力。
3.强灰度能力
传统上网络设备通常采用主备、或者主主的方式部署,当需要升级的时候将全部流量切到一半设备上,另外一半设备下线升级,升级完成后再重新加入集群分担一半的流量。这种升级方式简单粗放,在UCloud我们提出了更高的要求。我们软件行业的现状就是不论花多大的成本去测试,真正的用户行为总是不可能被穷尽的,缺陷总是会有的,这时我们最后的安全网就是“灰度发布”。在现网真实环境作为终极测试的同时,通过控制变更范围尽可能的减少风险;一旦真的有缺陷快速回滚,最大程度的降低影响面。在UCloud我们坚定的在每个产品上采用按账号灰度发布,即使是在虚拟网络设备上。
我们将灰度发布交换机软件的能力Buildin在Access层:
1. 当需要升级交换机软件时,将预留灰度交换机安装新版本软件;
2. 按照灰度账号定义新的数据分片,指定灰度交换机同步新的数据分片;
3. 按照VNI+源地址或VNI+目的地址配置灰度规则按VM的粒度将流量切换到灰度交换机处理;
4. 切换完成后立刻自动回归测试,Ping检测各种场景下的网络互通性是否正常;
5. 测试通过则逐步增加灰度的VM地址,直到整个VPC的流量全部切换到灰度交换机;
6. 再切换一个新的VPC,直到所有分片内的VPC都切换到新的交换机下;
7. 旧的交换机下线清洗,安装新版本软件,直到整个集群完成升级。
通过这种传统网络设备完全不同的升级方式,在SDN软件快速迭代的背景下,有力地保障了SDN网络的可靠性。
P4可编程交换机在UCloud规划的使用场景包括:
– 支持租户的增强交换和路由
– 物理机接入虚拟网络
– 一致性哈希ECMP负载均衡
– 流量限速与计费
– ARP代理
– 等等
目前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”。
参考链接:
P4: https://p4.org/
Barefoot: https://www.barefootnetworks.com/
Quagga: https://www.quagga.net/
DPDK: https://dpdk.org/
Open vSwitch: https://openvswitch.org/
想要获取更多技术和活动资讯,可扫描以下二维码,关注“UCloud技术公告牌”微信公众号;或搜索微信ID:ucloud_tech进行关注。