兴汉张旸:协同合作构建最佳白盒设备

在昨天的《2020网络数据平面峰会》上,兴汉网际系统软件工程师张旸给大家分享了主题演讲《协同合作构建最佳白盒设备》。

北京兴汉作为网络通信设备制造商,目前产品主要聚焦在云互联和网络安全这两大领域,同时也提供基础软件的服务,包括BSP的整合、系统固件的开发。张旸主要从系统软件工程师的角度出发,对白盒硬件平台的设计提出一些自己的看法和建议。

为了让演讲更有针对性,张旸选择了一个很典型的白盒的应用场景——中阶MEC,多接入云边缘计算平台。MEC的概念是将数据中心的业务扩展到网络边缘,让服务更靠近用户,这样带来的好处是网络传输延迟小、对用户请求响应快、同时又能减少网络回传的一个负荷。随着5g时代的到来,用户数越来越密集,对数据量的吞吐、时延都有一定的要求,MEC很可能成为组网中非常关键的组成部分。所以张旸就MEC设备硬件规格的制定,从系统分析的角度来做一个初步的探讨。针对MEC这样的设备,张旸建议从几大方面来做考虑。

产品设计开发

之前提到MEC是部署在网络边缘的数据处理平台,可以认为是一个小的边缘云,需要具备一定的计算能力、存储能力、网络转发的能力。MEC可以部署在网络的接入端,放在基站的后面,这种部署方式更靠近用户,主要针对的是超低时延的业务,比如说自动驾驶、机器人协作等。MEC也可以部署在网络的边缘端,把它放在本地网的汇聚机房里,部署在基站的汇聚点之后,用来提供低延迟、高带宽的服务,比如高清视频、视频监控、AR/VR等业务。

所以从MEC应用的部署规划中,要计算出设备承载的业务量有多大?每一台设备需要承载的工作负载是多少?这也基本决定了底层应用平台需要提供什么等级的计算处理能力。同时在VNF架构下面,MEC大多是以虚拟化的方式对上层提供应用服务,有可能是虚拟机,也有可能是管理器,该选择一个什么样的虚拟化的环境,也会直接影响到底层硬件资源的配置。软件开发者对于工作负载和虚拟化的考量可能比较多,这部分的分析结果对硬件品牌的选择是非常重要的依据。

接下来就是设备核心的组件,包括CPU、网卡,CPU和网卡的选择主要还是根据设备需要提供的计算能力跟网络处理能力来评估。接下来一个非常重要的方面就是运维的需求,尤其是针对像MEC这样大量分布式部署的设备,其管理跟维护让服务提供商非常头疼,怎么样去强化设备自身的稳定性,而且要让设备自己具备一定的运维能力,也是产品设计时务必要考虑的一个问题。

经过这几方面的综合评估之后,可以得到一个初步的硬件规格的版本,针对一些主要的性能指标,也要做一个初步的验证。可以利用开源的系统,模拟客户应用的测试环境,然后来评估硬件方案。根据评测的结果,然后再来修正、完善硬件规格设计。

应用系统分析

对于工作负载的计算,主要涉及到应用服务的规划,当前的服务量是多少?将来有可能发展的服务量是多少?服务链是如何部署的?是如何串联的?平台需要提供的承载力不仅要保证当下的用户数跟业务量,同时也要做一定的预留,预留给未来有可能扩展的用户数跟服务的数量。

对于系统虚拟化环境的规划,是选用容器还是选用管理器?管理器相对于虚拟机来说会更加的轻量,也更节约系统的资源,本身启动很快,集成性也比较好,业务容易做扩展。有人做过对比的测试,在同样的一台服务器上面,用Docker提供计算力,它基本上等同于物理机本身能够提供的计算力,但是虚拟机就会损失将近50%。另外一方面Docker也有弱点,比如说其隔离性跟安全性比较弱。所以在有多用户的应用场景下,服务商如果需要隔离不同的用户,就有必要采取虚拟机技术,但同时也要相应的配置足够的硬件系统资源,比如说磁盘和内存,我们知道一个Docker的OS系统大约会占用100M左右,但一个虚拟机的操作系统可能会占用到10G以上。

基础平台定义

MEC的部署是有虚拟化环境的,服务链会在虚拟机之间,或者说管理器之间去串接。虚拟机跟虚拟机之间,也就是常说的东西向数据平面传输的效能,它会直接影响到整体的应用系统的效能。东西向平面很常用的一个架构就是SR-IOV,SR-IOV是指在物理网卡上划分出多个虚拟功能,这些虚拟功能在操作系统中会以独立网卡的形式来呈现,这些VF之间数据流的转发,可以通过集成到网卡芯片内部的vSwitch直接转发。vSwitch的性能基本上跟原生网卡的性能是相当的。

但是使用SR-IOV也有一定的局限性,它需要pcie网卡、bios、host的支持,而且物理网卡上能够支持的VF的个数也是有限制的。虽然理论上SR-IOV声称可以支持256个VF,但是在实际应用中,网卡是受物理资源的限制的。使用SR-IOV的话,好处就是能够解放CPU的核心,把更多的CPU计算力性能让出来给应用程序来使用,数据传输就交由网卡自己来做处理。但是也有应用场景,假如是对跨主机的东西向流量有要求的话,这个时候就会比较适合使用vSwitch、oVs加DPDK的方式。Ovs over DPDK的性能和SR-IOV是差不多的,在4核的情况下可以达到35Mpps ,但高性能也是以牺牲CPU的核心数为代价的。

接下来是CPU跟网卡的选择,对CPU的选择,主要是根据计算出来的设备需要具备的计算力,来考虑CPU的工作频率、核心数、对虚拟化的支持。说到网卡,网卡除了要满足基本的Througput的要求以外,本身offloading的能力也是需要考虑的。它能不能对vxlan 做offloading?支不支持SR-IOV?网卡上做更多的offloading可以减轻CPU的负担,也可以让CPU把更多的计算力提供给应用服务。

运维需求

SDN集中控制的网络架构,会为网络运维带来一定的优势。网络管理员可以对设备做集中式的网络管理,而不再需要手动的现场做配置,但这时候也会要求设备本身有统一的管理接口,并且自己也要具备一定的自动化运维的能力。所以关于运维,张旸主要提了两个方面,一个是关于系统的升级,包括系统软件的升级和系统固件的升级,另一个是系统加固。

软件/固件更新

随着现在应用的快速发展,软件系统的升级会来得更加频繁,管理员通过远程集中控制设备做系统升级会有一定的隐患,系统升级失败了怎么办?如果造成网络的瘫痪,造成用户服务的中断,都是非常严重的事故,在电信网络里面是不允许发生的一个状况,这个时候远程管理员也基本上没有办法处理。针对这种高可靠性的用户需求,兴汉有一套系统保护方案,能够实现在这种异常的情况下系统的自我恢复,保证在系统升级失败的时候,至少能让系统正常启动。这个方案涉及到从上层系统软件到固件逻辑到底层硬件的应用设计,其核心思想是当系统能够侦测到异常之后,系统能够自动去提取备份区域存储的系统镜像文件,来做完整系统的恢复。

关于固件的升级,主要是说BIOS的升级,BIOS的升级需要预先定义好升级方式和接口。 Linux下面有BIOS升级的工具,可以在系统下本地升级,也很方便实施。但是主机上Linux系统的应用环境会比较复杂,如果在升级过程中被其他的应用打断,造成的后果将是无法修复的。所以设计时也可以考虑旁挂子系统,比如说BMC子系统对固件做升级,这样可靠性更高,但同时硬件上就需要增加BMC,系统的设计成本也会更高。

系统加固

举一个例子,异常断电的情况,客户的设备有些是放在机房,有一些会放在企业的办公室,有可能员工直接拔电,造成这种非正常关机,这种直接断电的操作就非常容易造成文件系统被破坏,严重的话可能会造成存储介质的物理损坏。在软件层面上会建议,在安装系统的时候对文件系统做一个规划,使用日志的方式来安装文件系统,从文件系统级别提高数据一致性的保护,或者也可以采用overlay的方式,将重要的系统文件系统目录做成只读,另外划分数据分区保存用户数据。第三种方式就是系统级别上面的,就像刚才提到的利用多重分区来做备份保护,在有必要的时候对系统做一个完整的镜像恢复。这些软件层面上的保护程度越高,相应的配置管理也会更加的复杂,所以也有从硬件设计上来提供改进的措施,用Dying gasp配合上一个加大断电保持的时间,这样让主机能完成读写后正常关闭系统,从根本上去解决突然断电这种异常情况的发生。

以上是兴汉在白盒产品设计的一些建议跟看法,也是这些年在项目开发过程中积累下来的思考跟经验,兴汉设计制造的白盒产品目前已经实现了从云端到边到端的全覆盖。

随着云服务的不断发展、5G时代的到来,传统网络的网元封闭且专用,很大程度上限制了新业务的创新,网络服务商升级服务的复杂度会比较高,设备的成本也高,而且会受制于专用的设备的提供商,这种网络实现方式被通用硬件平台加软件业务逻辑组成的开放式网络架构所取代是必然的趋势。但是软件和硬件的解耦,并不代表着硬件平台设计跟上层软件系统需求的完全脱离。相反的,好的硬件设计方案一定是来自对产品应用跟系统需求的充分理解跟分析,兴汉也是秉着这样的理念和想法尽可能的去分享其在白盒产品上的开发经验,希望以后有机会在实际开发的过程中,有更深入、具体的探讨。


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/24259.html
分享到:
相关文章
条评论

登录后才可以评论

大脸肥飞猫 发表于20-07-02
0