从ServerSwitch到SONiC Chassis：数据中心交换机技术的十年探索历程
编者按：微软交换机操作系统开源项目SONiC (Software for Open Networking in the Cloud) 在微软Azure数据中心里已经大规模部署，但如何在高层的Chassis Switch上部署SONiC仍然是一个挑战。为此，微软亚洲研究院和Azure网络产品部门合作，成功构建了第一个SONiC Chassis原型系统，它的背后蕴藏着研究者们历经十年的不懈探索。
随着云计算时代的到来，各大公司在全球不断建设数据中心，来支撑飞速增长的云计算业务。2011年，由 Facebook等公司发起了一个非营利组织——开放计算项目（Open Compute Project, OCP），旨在通过开源的方式，重构数据中心的下一代硬件，发展面向下一代数据中心的服务器、存储、网络、基础设施等创新硬件。OCP是目前世界上计算基础硬件方向覆盖范围最广、影响力最大的组织之一，成员包括Facebook、微软、谷歌、英特尔、AMD、阿里巴巴、腾讯、百度和华为等公司。
在数据中心里，数以万计的服务器由无数的交换机连接起来，构成了一个高带宽、低延迟的网络。众所周知，云计算业务对于可靠性有非常高的要求，这要求网络的运维人员，必须对交换机做到高度的可控制、可管理，能够时刻了解网络发生了什么，在出现故障的时候必须快速定位和排除故障。此外，新的云计算业务，也对交换机不断提出新的功能需求，这就要求网络的开发人员能在短时内实现新的交换机功能并部署上线。在这些新的挑战和要求面前，传统交换机厂商的设备已经显得越来越力不从心，因此，各大云计算厂商纷纷开始了自己的交换机自研之旅。
作为OCP合作项目的一部分，微软在2016年OCP峰会上发布了交换机操作系统开源项目SONiC (Software for Open Networking in the Cloud)。该项目利用交换机抽象接口（Switch Abstraction Interface, SAI）为不同的交换芯片提供了统一的管理和操作接口，并将交换机软件分解为多个容器模块，来加速软件的迭代开发，如图1。SONiC得到了很多云计算、交换机和芯片厂商的响应，目前的开源社区成员包括微软、阿里巴巴、腾讯这样的云计算厂商以及Mellanox、思科、Arista这样的交换机和芯片厂商。
目前，SONiC在微软Azure数据中心里已经得到了大规模的部署（如图2所示）。然而，目前SONiC的部署局限在T0和T1这两层的交换机（Switch）上，如何在高层（T2/T3）的Chassis Switch上部署SONiC仍然是一个巨大的挑战。因此，微软Azure网络产品部门和微软亚洲研究院系统与网络组于2018年9月启动了SONiC Chassis的合作研究项目，来设计支持SONiC的Chassis Switch。
图2: SONiC在微软的数据中心内的部署情况
传统的Chassis Switch架构其实是由多个交换机芯片构成的（见图3示例）。前端芯片和后端芯片是靠一个特殊的基于Cell（交换机芯片内部一种固定长度的数据单元）交换（Cell Switching）的无损（Lossless）网络连接起来的。目前，Chassis Switch内部的Cell网络并没有公开的拓扑和路由标准。不同芯片厂商的Chassis Switch内部Cell网络的实现也不尽相同，且细节并不公开，可以说是不折不扣的黑盒子。在这种不透明的情况下，网管们很难用SONiC来管理Chassis Switch，也无法发现和诊断Chassis内部出现的网络问题。
图3: 传统Chassis Switch的内部架构
为了让SONiC能够运行在Chassis Switch上，我们首先要把Chassis Switch变成网管们熟悉的白盒子。和传统Chassis Switch一样，SONiC Chassis依然由多块交换芯片构成。但不同的是，我们用标准的（二层）Clos以太网（Ethernet Network）来连接这些芯片（如图4所示）。Clos以太网是当今数据中心的标准架构。这样，网管们可以轻松地把数据中心网络的大量成熟技术（比如控制平面协议、流控机制和故障诊断技术）和运维管理经验直接移植到Chassis内部网络上来。
图4: SONiC Chassis的内部网络拓扑
在拓扑决定了后，下一个挑战是Chassis内部的控制平面（Control Plane）。SONiC Chassis的每个芯片上都运行了一个SONiC实例（Instance），并采用了BGP-EVPN作为控制平面协议。前端芯片上的SONiC通过BGP-EVPN直接互相交换外部的路由信息，而不涉及后端芯片上的SONiC。这样，我们仅需要在前端采用比较昂贵的大路由表芯片，而可以在后端芯片的选择上拥有更多的选择。比如，后端可以选择高端口密度（High Port Density）小路由表的芯片，来提升整个SONIC Chassis Switch的端口密度。为了配合BGP-EVPN，SONiC Chassis内部采用一种标准的网络虚拟化技术 — VXLAN（Virtual eXtensible Local Area Network） 。每一个前端芯片都是一个VXLAN隧道节点（VXLAN Tunnel End Point, VTEP），进出Chassis的数据包会被前端芯片添加/挪走VXLAN头。在不知道外部的路由信息的情况下，后端芯片只需要根据数据包的VXLAN头部信息，将数据包转发至正确的前端芯片即可，如图5所示。
图5: SONiC Chassis的控制平面，在这个例子里，VTEP1上的SONiC直接把10.0.1.0/24的路由信息发送给了VTEP6上的SONiC。
经过历时近半年的紧密合作，微软亚洲研究院和Azure网络产品部门在今年2月联合构建了第一个SONiC Chassis的原型系统，并且在3月的OCP全球峰会上进行了展示，得到了工业界的广泛关注。
目前，我们正在继续解决SONiC Chassis中的一些关键技术问题（比如Chassis内部的拥塞控制以及故障监控诊断机制），争取早日将SONiC Chassis部署到微软的数据中心中。
图6: SONiC Chassis的原型系统，展示于2019年3月OCP全球峰会上
“在SONiC Chassis项目的背后，其实是我们在数据中心交换机技术上十年的曲折探索历程。”已经在微软亚洲研究院工作了16年的资深研究员熊勇强介绍道。“早在十年前，我们希望为BCube和DCell这样以服务器为核心的数据中心架构实现高性能的转发引擎，所以我们启动了ServerSwitch项目。”
图7: ServerSwitch架构
ServerSwitch将商用的交换机芯片和服务器通过高带宽的PCI-E接口连接起来，充分挖掘了交换机芯片和CPU的可编程能力，实现了一个高性能可编程的平台。在2011年，ServerSwitch论文发表在计算机系统和网络的顶级会议USENIX Symposium on Networked Systems Design and Implementation (NSDI) 上，并获得最佳论文奖。
然而，这样一个在学术界大受欢迎的工作，在微软内部的落地却几经波折。“我们虽然基于ServerSwitch做了一些新颖的应用，比如利用主机的大内存来缓存交换机芯片无法吸收的数据包，但是离生产环境的需求还是有不小的距离。”熊勇强不无感慨地说。“在2012年和2013年的时候，我们希望可以把Azure网络的Generic Flow Table (GFT) 卸载到ServerSwitch平台上，并且做了很多努力，设计并实现了40G ServerSwitch系统。然而由于交换机芯片的流表资源的限制以及功耗问题，产品部门最终还是选择了FPGA”。
转机发生在2013年，ServerSwitch的核心开发者吕国晗（现微软SONiC项目首席开发经理）加入了Azure网络产品部门。于是微软亚洲研究院和Azure网络产品部门开启了Azure Cloud Switch（ACS）的合作项目，旨在设计一个跨平台模块化的交换机操作系统。这可能也是微软在自研交换机操作系统上最早的尝试。
图8: ServerSwitch
就在大家满心欢喜的时候，命运却开了一个不大不小的玩笑。ACS最初是基于微软公司的Windows平台开发的，就在ACS Windows原型系统即将大功告成之际，微软开始积极拥抱Linux和开源系统，而Windows并非是开源网络系统中的主流操作系统，因此Azure网络产品部门的负责人Albert Greenberg立刻叫停ACS Windows开发，转向Linux，也就是今天的SONiC项目。“那个时候，大家在ACS Windows上已经投入了巨大的心血，突然知道项目被叫停，都十分无奈和沮丧。”熊勇强回忆到。“但是不得不说，投身Linux确实是一个十分明智的决定。Linux的开源生态对于SONiC来说是至关重要的。”
目前，SONiC的合作伙伴生态系统涵盖了业界主流的软硬件厂商。其开放性让用户有了多样性的选择，合作伙伴可以根据网络需求自由选择硬件和软件。而合作伙伴的加入，也进一步推动了SONiC生态的完善。
回顾过去十年的探索历程，微软亚洲研究院的网络研究者们经历了顶级会议上荣获最佳论文的兴奋，技术落地受挫的懊恼，项目最后一刻被叫停的无奈，直到今天获得阶段性成果的欣喜。他们的探索之旅依然在继续。
你也许还想看：
感谢你关注“微软研究院AI头条”，我们期待你的留言和投稿，共建交流平台。来稿请寄：msraai@microsoft.com。