2018-10-17 14:00

　　大家下午好，我是来自阿里巴巴基础架构事务部的刘永锋，我负责的是数据中心内部自研交换机的软件开发，今天非常高兴能有机会在ODCC数据中心网络分会场里跟大家分享，我们作为互联网的用户在自研交换机的开发落地上具体做了哪些事情，遇到了哪些问题，给大家做一个分享。

　　今天我们数据中心的规模是越来越大的，业务节点的个数是随着云和大数据的业务快速增长的。驱动增长的因素有两个：第一个因素，我们的业务规模，服务的用户在不断增大，导致网络规模、数据节点需要越来越多的业务支撑发展。同时硬件的发展也非常快，也就是说，今天随着摩尔定律或者网络速率的提升，每隔2—3年网络速率、底层服务器的性能就会翻倍。原来分布在两个、多个数据中心的业务，现在我们有能力放在一个数据中心里，就省掉了很多跨数据中心搬移的成本。

　　大规模数据中心对底层网络有有哪些具体需求呢？我归纳下来就是三点：

　　第一，需要高度稳定。 大家知道，关于自研硬件或者自研交换机、自研网络设备，国内的BAT并不是首先尝试的。北美、谷歌、亚马逊他们已经在这条路上探索了很久，我听到有一个说法，个人觉得讲得非常好，就是当一家公司非常在乎你的业务、软件的时候，你就会有定制硬件的需求。也就是说，这时候你真正在乎的是你的稳定性，因为今天我们互联网上面跑的各种业务，是和我们每个人日常生活息息相关的。

　　第二，高度可管可控。

　　能运维大规模的数据中心，运维人员必须要有能力知道你的网络时时刻刻在发生着什么，能够高效的进行扩容和容灾。

　　第三，高性能、低成本。

　　既要马儿跑得快又要马儿不吃草，高性能、低成本是网络架构师、互联网服务提供商天天需要考虑的。

　　综合下来这三点，在规模不大的时候用传统厂商的设备还能应付，但是在大规模的条件下，要能够满足这三点的需求，挑战就非常大了。

　　挑战在哪里呢？右边这几个框大家都非常熟悉，传统数据中心高大上的设备，传统来看觉得是非常核心、非常高科技的东西。在企业网络发展的过程中发挥了非常重要的作用，但是随着数据中心的普及，随着规模扩大的需求，使得这些大家伙的可扩展性变得非常差，已经满足不了我们对网络规模的需求了。

　　这个复杂性背后就隐含了它是难以扩展的，同时它又是一个黑盒子，厂商从软件到硬件是完全封闭开发的，导致维护的挑战就非常高。当稳定性要求很高的时候，运维团队很难做到快速定位和恢复故障，这给线上运维带来了非常大的挑战。

　　同时数据中心规模非常大，所以我们会采购各个大的设备厂商的设备，每个设备长得不一样，它的性能、使用方法、规格、带来的bug、以及bug的影响都不一样。你就要同时搞定所有厂商的问题，大家可以想一下挑战有多大。

　　因为这些核心设备对于厂商来说也是非常复杂的产品，也就是说，对于一个非常成熟的厂商要把设备从研发到生产上线交付给用户，需要1—2年，更多的时候是2—3年。也就是说，当用户有一个新的需求，你需要这个新的需求在盒子上可以用，是2年以后的事情，这个节奏是满足不了我们业务需求的步伐的。

　　右边的图，从网络的使用者到拿到网络设备，这个网络设备出问题给我反馈周期都是以周计、月计、年计的，我们的要求是以天计、以小时计、以秒计，矛盾就出现在这里。

　　总而言之，对于数据中心软硬件开放大家为什么会拥抱开放？就是因为基于开源的软件，加上开放的硬件，就可以让产品服务演进节奏更快，更可靠、更灵活、更高的安全性、更低的成本。

　　具体到今天说的重点，在数据中心网络里，软硬件的生态可以看到哪些东西呢？这张从底层芯片到支撑数据中心网络的硬件，和上层的应用软件做了一个梳理。今天的生态已经是非常丰富和非常健康的状态了。

　　刚才志华已经提到，阿里在自研交换机这条路上已经做了一段时间的探索，我们可以明显的感觉到3、4年之前我们能够在开源软件生态里拿到对我们真正非常有价值的开源软件，或者OEM、ODM供应商那里能够拿到满足我们需求的硬件和标准芯片的特性，其实都是非常困难的，提供给我们选项都非常少。但是今天大家的选择非常多了，已经不再是讨论温饱的问题了，今天已经可以选择我要什么样的口味了。

　　交换机OS层面都有很多选择，尤其是芯片层面，2015年之后，万兆25GB开始，有很多交换芯片厂商也给完善这个生态提供了很多选择，这对我们来说是很好的事情。

　　具体到今天我们做自研交换机，做数据中心网络设备自研，关注除了刚才讲的生态之外，我们放大设备往里看，还有哪些东西呢？有类似于我刚才讲的计算开放。就是把之前封闭的这套系统，能够通过标准芯片、软件和上下行的软硬件接口定义出来，所有的设备厂商、用户就基于已有的接口，已有的标准部件和软件，就可以定义一个符合自己的完整设备产品，不需要依赖一个厂家从头到尾帮你做一个黑盒子定制。

　　阿里巴巴在基础架构的演进上，我们在自研的整个过程中有很多探索，我们也是经历了三个阶段：

　　第一个阶段，考虑做自研的时候没有太多选择，那时候已经感觉到数据中心开放和网络开放会给我们带来好处。大家抱着因为相信可以看见的态度，就走上了这条自研的道路。第一代我们采用的是第三方的软件和白盒子硬件，就可以把它部署在数据中心里。但是限于软件的扩展性和本身我们对于白盒子这条路往前走，我们积累了更多运维的经验。在做白盒子的过程中，你要了解需求是非常非常重要的，我们不是要拿着锤子去找一个钉子，首先要了解清楚数据中心网络的需求在哪里，哪些东西是必须的，哪些东西是不需要的。

　　第二个阶段，重点放在了开源OS上，基于SONIC我们可以开发自己的阿里NOS。基于我们已有的运维经验和白盒软件经验，可以开发出满足阿里的需求部署的功能特性。前提就是你对你的网络需求有很好的了解，但是再往前走的时候会发现，当交换机部署到一定规模的时候，绝对不仅仅是一个软件功能和特性的问题。

　　第三个阶段，到大规模的时候，可能你在小规模的时候完全碰不到的问题，就会变成非常大的问题，这种问题很多时候都是硬件的稳定性导致的，这时候定制硬件就成了我们必然的选择。

　　今天不会讲太多关于SONiC和AliNOS硬件细节，想重点分享一下我们落地NOS软件做了哪些事情，区别是什么？从需求评估到研发测试、生产灰度、规模运维是一个非常大的项目周期，不是基于某个硬件把硬件bring up起来就做完了，实际上这才刚刚开始。

　　再说一下我们对于SONiC评估是怎么看的，我们两年前评估SONiC的时候，非常高兴的看到，像微软这样的大的互联网公司的看法跟我们一样。很多问题他们都考虑到了，比如说我们如何支持多厂商芯片，微软花了很多精力定了一个标准，白盒支持多芯片的话过去可能需要两年，如果目标芯片的SDK是支持SAI这套标准的话，现在花一周、一个月就把基本功能跑起来。同时SONiC是基于一个非常现代的软件思想设计出来的，有很多对于交换机来说非常关键模块的解耦，能够更好的满足数据中心网络的需求，这些都是我们想要的。

　　作为刚刚出现的开源NOS，还有一些是我们觉得需要加强的地方。比如说命令行的支持，配置如何保存、如何变更，尤其不同用户对网络架构需求不太一样的地方怎么支持，需要加以完善并满足最终的用户的要求，满足所有的上线需求才能上线部署。

　　我们基于前面的评估和社区紧密合作，我们对于SONiC的架构和社区有一些非常紧密的讨论和提出了不少改进的建议。最开始的SONiC配置管理都是基于minigraph文件去配置的，但是随着我们和社区的共同努力，对于配制管控的需求，很快分阶段支持了ConfigDB、gRPC结构化管控，取得了很好的效果。

　　除了刚才讲的管控方面的改进之外，功能需求上我们还和社区一起开发了TACACS+、LACP fallback等等。除了这些基础功能，我们还开发了阿里的定制需求，包括双上联，支持RDMA、还有INT定制开发工作。

　　接下来我再说一下，除了这些功能开发之外，我们要让它能像一个厂商设备一样上线，需要多个场景的测试回归。

　　这些非常复杂的测试工作要求我们做非常完善的代码覆盖率、功能覆盖率和具备一键回归的自动化能力。除了软件功能本身的开发，我们还要有一套多维度的测试环境。纯软件测试和基于硬件的软件测试在工作量的挑战上完全不是一个数量级的，如果所有测试都放在硬件上，因为硬件资源的限制，搭建环境，改变拓扑，效率会非常低，所有测试放在软件上做那很多地方会cover不到，所以除了纯硬和纯软的测试环境之外，我们还有软硬件混合的测试环境。在混合测试方面，SONiC在社区是有非常独特的测试理念和方法的，有兴趣的听众都可以去了解一下。

　　对于多环境的测试，要有能力让我们开发的工作尽量少，我们要能让它同时跑在多个环境下，这就借助互联网公司对大规模上线业务的部署能力，可以在这歌个方面发挥优势。

　　我们做完测试之后还要做实验室灰度、小批量灰度，然后再到大规模。还要对接运维的管控系统，解决配置生成、版本升级、模板开发的问题，还要做各种线上场景的演练，Failover场景、设备隔离操作、业务压力测试都要做，确保万无一失。

　　规模交付阶段还要有能力交付成千上万自研的设备，通过自动化批量交付，如何让运营同学对运维自营设备比对厂商设备有更好的体验，告诉他们如何管理版本、升级软件、变更配置，尤其是做故障处理的时候，我们要怎么样能比传统厂商更好，提供给运维同学什么样的接口，在故障没有影响到之前就能够识别出来，设备有告警的时候能秒级的定位原因、然后自动做隔离和恢复，这些都是非常复杂的技术体系在支撑。

　　最后做一个总结，首先我们认为自研的目的是为了更好的满足大规模对数据中心网络的要求，开放的数据中心软硬件生态为自研提供了很好的条件，作为互联网提供商要结合自己的业务需求、网络架构去评估选择一个合适的开源NOS。同时完备的测试和非常完备的引入策略才是自研设备部署的关键，最后对我们来说体会最大的，这不仅仅是一个技术的变化，而是运维模式的变革。从过去我们保证厂商设备的稳定性采取保守策略，到我们为了稳定会快速升级、快速迭代，真正的稳定性是靠敏捷、迭代做出来的，而不是靠保守升级来达到的。

　　传统满足企业网的命令行操作，会被结构化管控替代，从依赖厂商到自主开发，可以开发想要的特性，更重要的是你可以不受冗余特性带来的复杂性和负面影响。

　　我们过去很多精力、资源是耗费在处理不同厂商的差异上，同样的坑可能不同厂商要重新趟一遍。通过自研NOS可以打通上下层软硬件件技术栈，我们就可以更多的关注如何使系统软硬件更好的满足业务需求，我们软硬件的稳定性才会有本质的提升。

　　谢谢大家，我今天的演讲内容就到这里。