云时代,本地部署的企业级软件在不扩容的情况下,能做到短期内十倍的性能提升的确是一件令人侧目的成绩。
众所周知,x86的性能已经被压榨到了极致,带着种种疑问SegmentFault思否社区采访了云杉网络研发总监向阳。访谈中,向阳详细谈了在企业数据中心网络场景下各种时序数据库的表现,并解释了云杉网络如何从工程的角度实现x86软件十倍性能的提升。
向阳:云杉网络研发总监、网络架构师。负责云杉研发团队的管理和DeepFlow的架构设计和核心功能实现。
年获清华大学计算机科学与技术博士学位,师从吴建平教授并独立实现了世界上第一个基于关联分析的BGP劫持检测系统,因此摘得InternetMeasurementConference(IMC,网络测量领域国际顶级会议)社区贡献奖。年获得清华大学博士后证书,主要研究方向为云数据中心网络架构,获得了多项网络安全、云数据中心相关专利。
思否:能否请您先介绍一下主要工作经历,专注的技术研究方向,以及目前所负责的工作。
向阳:我的工作经历其实比较简单,在加入云杉之前,我在清华大学读博。师从吴建平院士做一些包括域间路由的算法和结构、域间路由的安全等等方面的工作。毕业后,我接触到SDN的领域,也就顺理成章地加入云杉,然后一直做SDN的研发工作直到现在。现在我在公司是研发团队的负责人和DeepFlow产品线的负责人。
思否:随着业务需求的提升以及云计算等相关技术的发展,企业开始建立自己的云数据中心,其中网络是云数据中心的重要组成部分之一。您认为现代企业的云数据中心在网络架构的搭建上通常有哪些痛点?企业应当如何应对这些挑战?
向阳:我们能看到的企业在去做这一块的时候,主要的一个挑战其实可以分为两个方面,一个方面就是说怎么去建设,另外一个方面,其实还要去考虑到怎么样去维护它。
建设主要解决两个痛点:一个是网络连通性的问题,一个是网络服务化的问题。
为了支撑业务,首先要把异构的资源、混合云这些场景下做一个打通和互联;然后在此之上提供丰富的网络服务,包括像应用交付服务、安全服务等等。
与上述问题平行展开的,是复杂网络的运营维护问题。因为现在网络会相当的复杂,一般来讲IT基础设施会同时在公有云、在私有云不同的资源池上,此外还有虚拟化的一个容器资源池。在这样一套IT基础设施上要打通一个统一的网络,才能支撑业务的灵活需求。
比如说一个业务要想在容器的资源池里面去拿到几个POD,在虚拟机资源池里面拿到一些虚拟机,在裸机资源池里面拿到几个物理机来实现一个业务需求,这个时候实际上这些资源池是互相独立的,但是从网络的视角看(这个业务)是一个整体,要将上述资源池的这些网络打通、做统一的编排,这是一个挑战。
在此基础之上,如果说我们把网络做了打通,那么这个网络维护的难度也是非常高的,不可能再由人工去做维护——如果说这张网增加了10倍的复杂度,那就意味着至少要投入10倍的人力,这件事难以为继。
思否:云杉网络为了帮助企业解决网络运维管理上的挑战,早在年的时候就推出了云网分析产品DeepFlow,能否请您先介绍一下DeepFlow的核心组件、功能特点以及应用场景?
向阳:实际上我们把DeepFlow的一个解决方案划分成两个场景,一个是采集分发,另外一个是分析。那也就对应着DeepFlow的整个产品中的三个核心的组件:采集器、分析器和控制器。
从组件的角度来讲,控制器负责中央的管控和大规模(采集器)的管理,因为我们的采集器会运行在很多异构的环境里面——KVM虚拟化、VMware虚拟化、公有云的环境、私有云的环境、容器的环境、Linux的环境以及windows的环境——这时采集器的特点是运行的环境异构,另一个特点就是采集器的数量非常大。
控制器它需要做的就是一个集中的大规模的管控;而采集器需要做的就是刚才对于这些异构环境的一个全网覆盖,包括物理的、虚拟的等等,做一个全网的覆盖;以及我们需要有一个高性能的策略匹配的算法。
因为如果对所有的流量数据全部做处理,这个时候的资源开销将会非常大。有的流量我们可能只是希望看一看,有的流量我们希望把它的一些counter记录下来,还有的流量会进入它的pcap文件,进入它的一些详细的数据包,以及把一些流量直接分发出去。
不同的流量需求,我们就需要通过一个策略的体系去对它做一个相当于编排。通过匹配,把符合某意图的一些流量,给到后端对应的消费工具里面。这样的话我们在采集这一侧是需要有一个较强的策略匹配引擎,再到后面我们的流量除了去分发给第三方的分析工具,传统的NMP、DPI以外,我们还能自己做一些分析,这就是我们的分析器。
我们的分析器主要一个特点,就是通过一个分布式的时序数据库,来将网络中的所有的状态和统计数据存储下来。这相当于对网络的全景视图做一个刻画。客户再去做混合云场景下的一个网络排障的时候,能把所有的这些关联点,不同的网络、不同的层面,不同的Overlay、不同的Underlay——比如说在容器的场景下可能是双层的Overlay——把它们都联系起来。
再回到应用场景。第一个是混合云上流量的采集和分发。这种应用场景一般是针对于客户已经有了很多传统的分析设备,比如说DPI的设备、NPM设备等等,但是他们苦于无法拿到虚拟网络、容器网络里面的流量。
在虚拟网络的场景下,网络的规模非常大,现在一个服务器可以虚拟出来10个虚拟机,一个虚拟机可能又有10个POD,这个数量是非常庞大。因此在虚拟网络里你不能像传统物理网络那样通过分光、镜像直接拿流量。我们能做到全网覆盖,按需的把流量拿出来给到后端的分析工具。
另一个场景就是混合云的网络诊断,这实际上是网络分析的场景。因为我们看到现在的云的网络是充分复杂的,这里面有异构的资源池,有不同层级的Overlay,我们怎样在这样一个复杂的网络环境下去做故障的诊断定位?这需要我们有一个全网流量数据的分析能力,即网络分析。
思否:DeepFlow自5.0版本之后的每次更新都对性能进行了改善,尤其是5.5.6版本后核心组件的性能再次大幅提升,这是如何实现的?是否与编程语言和数据库有关?云杉为什么如此看重性能上的提升?
向阳:首先来谈一谈这些性能的提升是如何实现的,其实总的来讲包括几个方面。采集这一侧,我们是对于新技术有一些引入,像DPDK以及像Linux内核高版本的XDP的技术,XDP对于客户的环境的依赖是比DPDK要低,并且流量的采集性能比我们上一代的技术能有10倍的提升。
另外补充说明一下我们对新技术的引入,我们其实是走在了社区的前面,年发布的CentOS8使用的内核版本对于XDP的支持其实并不好,我们也从内核的层面对XDP的支持做了一些提升,使得我们能在低版本的Linux环境里面将我们的采集器的性能提升上来。
另外一个方面是分析侧,主要我们是基于数据结构和算法的一个优化。我们整个DeepFlow平台,绝大部分的组件都是基于Golang,稍后再讲我们为什么会去选择Go。我们对它原生的数据结构——像map这样一些数据结构——做了一些非常关键的算法和数据结构上的改变,使得其性能都提升了10倍。
这里面我们有一些专利存在,比如说我们对于Go的对象资源池、内存池的一些改进,对于map的一些改进,这是在分析侧的优化。
然后就是在存储侧的优化,我们是基于InfluxDB数据库,对它的内核做了全新的开发,实现了10倍读写性能的提升,以及具有一个水平扩展的能力,更重要的是使它更适合网络的场景。
回过头来说Golang,其实和语言的关系还不是太大,如果说我们需要去追求一个极致的性能,我们可能会去选择比如说像C这样的语言。但这里还有另外一个问题,就是我们的开发效率和适配性。如果我们用C的话,可能对于环境(比如说glibc的版本)的依赖会比较严重。
Go其实是一个云时代的语言,像Docker这样的技术,就是构建在Go之上的,其依赖是非常小。我们选择Go能够在依赖性和开发效率上获得优势,此外我们也会去克服它的缺点,像它的GC带来的缺点、它的数据结构带来的性能问题,这些方面我们都做了提升。
最后说说我们为什么如此