如何极度压榨网络性能：揭秘 UCloud 的物理云网关
近些年来，云计算蓬勃发展，上云成为现在软件开发落地的首选。但随着企业业务的不断增长和扩大，传统云计算的劣势也暴露出来：单体硬件性能不够，只能堆集群；租户隔离不够彻底，时有新闻爆出问题。因此，物理机服务器又再一次的被提上了台面。
创立于 2012 年的 UCloud，从 2013 年伊始就面向市场同时提供了基于虚拟化服务器的公有云产品和基于裸金属服务器的物理云产品。不过，和绝大多数人想象中的不同，物理云服务器并非直接帮你上架一个服务器就行的，其背后也有不少复杂的技术难点需要 UCloud 及合作伙伴们去攻关。这其中最为艰难的，可能就是虚拟网络相关特性的研发。
物理云产品和公有云产品最大的不同就在于客户可以独占并完全控制整台物理服务器，UCloud 作为服务商并不会在服务器上运行任何虚拟化的软件。这使得想要让物理云产品和公有云产品的网络互通、让物理云产品享受到公有云产品所享有的网络优势变得十分困难。特别是一些有状态的特性比如安全组等实现起来更加困难。
UCloud 踩过的那些坑
从 2013 年开始，UCloud 开始使用 Open vSwitch 来构建基于 Openflow 技术的公有云 SDN 虚拟网络。也因此，同年， UCloud 提供物理云产品的时候，选用了支持 OpenFlow 的 SDN 交换机，以实现物理云产品和公有云 VPC 网络的互通。
2014 年，随着 UCloud 业务的扩大和快速发展，已有的交换机所提供的 OpenFlow 流表有限的条目已经无法支撑实际物理云产品业务的需求。
2015 年，已经在 DPDK 技术上做了两年研究储备的 UCloud 领先在产品环境推出了采用 DPDK 技术的服务器集群，从而替代硬件 SDN 交换机，满足业务层面的需求。
但随着以太网技术的发展，人工智能、大数据等应用的落地，网络技术的发展得到了爆发般的发展，25G、100G 的网络迅速得到普及， DPDK 网关集群的转发性能和成本问题逐渐成为业务发展的瓶颈。
时间来到了 2019 年， UCloud 开始使用智能网卡（Smart NIC）来替代原有的 DPDK 网关集群。UCloud 采用的智能网卡方案采用了 16 核 ARM CPU 运行 OVS 作为 SlowPath，采用 Linux TC Flower 卸载技术将网卡芯片作为 FastPath，通过 SRIOV 技术和用户系统集成，很好地解决了性能问题，但与此同时，其所带来的高昂采购成本造成了成本的提升。此外，由于所采用的智能网卡的转发面尚不可编程，也使得任何新的特性都需要网卡芯片厂商修改固件来实现。甚至一些比较复杂的特性也不能实现。比较典型的例子就是为了让智能网卡支撑 UCloud 使用的 Overlay 封装格式，就花费了半年时间才在和网卡芯片厂商反复沟通协调下完成，而类似带宽控制、硬件卸载的特性却难以实现。
痛定思痛的深度思考
六年的艰辛探索，让 UCloud 调研试验了几乎市面上所有的各种网络网关方案。而这些年来踩的坑，也让 UCloud 看到了这一代网关产品的问题和不足。作为战斗在云计算网络技术一线的团队，UCloud 基于实践经验，总结出了下一代物理云网关应该满足的一些需求：
- 全功能：能够提供和公有云一样的网络特性，比如有状态服务安全组等。
- 高性能：能够满足从 25G 网络到 100G 网络的需求。
- 低成本：比 DPDK 网关和智能网卡网关有更低的拥有成本。
- 可定制：能够满足定制需求，可以基于此进行进一步的演进。
基于 Jericho2 芯片的下一代物理云网关 —— BCM88690
在使用现有的智能网卡解决方案的同时， UCloud 也在积极的在技术市场上寻找合适的下一代物理云网关，以替换现有的产品解决方案。
首先进入 UCloud 视线的是某公司的一款高性能交换机。它和智能网卡一样可以运行 Linux 和 Open vSwitch，更加难得的是，其通过 Switchdev 支持 OVS TC Flower 卸载，并使用交换机芯片作为 OVS 的 FastPath。遗憾的是交换芯片对 TC Flower 卸载的支持仍然不好，造成很多功能无法卸载。并且交换芯片不支持用户编程，UCloud 无法修改交换芯片的管线来满足自己实际的业务需求。
而在这时，博通正在研发 Jericho2 可编程交换芯片相关的产品，于是 UCloud 与博通一拍即合，与博通合作利用 Jericho2 可编程交换芯片研究开发物理云网关，并基于研究的成果，开发出了能够完美满足 UCloud 需求的物理云网关。
在技术层面上，UCloud 通过在 Jericho2 可编程交互芯片上定制了管线来作为 TC Flower 的 FastPath，并在交换机控制面运行 Linux + OVS 作为 SlowPath ，并通过 TC Flower Offload 将两者集成在一起，从而实现硬件的加速。
当报文进入交换芯片，首包未命中时通过可编程交换机的虚拟网卡进入交换机的 Linux 内核，通过 OVS 的 Datapath 触发 ovs-vswitchd 下发新的 Openflow 流表。UCloud 通过对 OVS 做了尽量少的改动，将原先通过 Netlink 发送到内核去的 TC Flower 卸载消息通过 UNIX 套接字发送到运行在用户态的 Jericho2 Agent，它再将消息转化为对应的可编程交换机的消息下发给交换芯片。后续报文将直接命中交换机管线中的流表，由交换芯片转发。
Jericho2 提供了业界独一无二的可编程架构，除了管线节点可编程外，还可以进行管线延展，在增加了处理流程的同时而没有损失任何转发性能。其基于 C++ 的编程工具链，成熟且直观，使 UCloud 可以轻松的基于现有芯片添加功能、在线升级，并轻松的根据实际需求进行定制和实施。得益于 Jericho2 灵活的可编程能力，UCloud 和博通合作在交换芯片上实现了 OVS 的 TC Flower 卸载转发面，可以实现和智能网卡同样的 OVS 卸载功能，但达到了 4.8T 的转发性能，相当于 48 块 100G 智能网卡。并且还保留了进一步扩展定制的能力，以实现 UCloud 使用的 Overlay 封装格式 GRETAP 为例，可以完全自行开发、灵活修改，一周的工作就能完成。
另外 Jericho2 真正的模块化表项结构，所有表项共享同一块物理缓存，极大增加了片上资源的使用效率。管线上所有处理节点可以并行访问，根据不同的应用场景进行逻辑表项的灵活划分，使得同样的硬件可以应用在完全不同的使用场景。丰富的表项资源使得新一代的网关能够完全满足用户现有甚至未来可见数年的规格需求。
最终， UCloud 实现了一个完全和公有云特性兼容，转发能力高达 4.8T ，并且可以自由定制，成本也非常有竞争力的物理云网关。这满足了对于下一代物理云网关所定义的四大需求：全功能、高性能、低成本、可定制。
总结
UCloud 作为国内公有云市场的大玩家，更是如今国内的公有云第一股，在国内风起云涌、巨头林立的大环境下，稳稳的占据了属于自己的市场， 实属不易。而 UCloud 能做到这一点，得益于其始终坚持“客户为先”的价值观，及时响应客户需求，快速解决客户问题，不断推出超出客户预期的创新产品和服务。也正是这样对于客户为先的价值观，让 UCloud 不仅能做好服务，更能打造出卓越的产品。