openEuler结合ebpf提升ServiceMesh服务体验的探索
服务网格的前世今生
早期的微服务架构上存在着服务发现、负载均衡、授权认证等各种各样的难题与挑战。起初微服务践行者们大多自己实现这么一套分布式通信系统来应对这些挑战,但这无疑造成了业务功能的冗余,解决此问题的方法就是将共有的分布式系统通信代码提取出来设计成一套框架,以框架库的方式供程序调用。但这个看似完美的方法却存在着几个致命的弱点:
-
框架大部分对业务来说是侵入式修改,需要开发者学习如何使用框架 -
框架无法做到跨语言使用 -
处理复杂项目框架库版本的依赖兼容问题非常棘手,框架库的升级经常导致业务的被迫升级。
随着微服务架构的发展,以 Linkeerd/Envoy/NginxMesh 为代表的 sidecar 代理模式应运而生,这就是第一代的 serviceMesh。它作为一个基础设施层,与业务进程完全解耦,和业务一起部署,接管业务件之间的通信,将网络数据收发单独抽象出一层,在这层集中处理了服务发现、负载均衡、授权认证等分布式系统所需要的功能,实现网络拓扑中请求的可靠传输,较为完美的解决了微服务框架库中的问题。
但在软件开发领域没有万能的银弹。ServiceMesh 带来了这么多便利的同时,也不可避免的存在着一些问题。传统方式下,客户端到服务端的消息仅需进出一次内核协议栈即可完成消息传递,但在 sidecar 模式中,一般选择使用内核的 iptables 能力劫持业务流量,这就造成了业务数据需要多次进出内核协议栈,导致业务时延增大,吞吐量变低。
openEuler 21.03 版本下进行 sidecar(envoy)模式基准测试发现,with-envoy 与 non-envoy 模式下,时延有大幅增加
利用 ebpf 能力加速 ServiceMesh
有没有什么方法可以在享受 ServiceMesh 提供便利服务的基础上同时降低并消除网络时延带来的影响呢?在这里就不得不说下 ebpf 技术,ebpf 是在 kernel 中的一项革命性技术,旨在提供不修改内核代码或加载内核模块的基础上更加安全有效的扩展内核的能力。使用 ebpf 能力短接内核网络协议栈来降低网络时延,提升 ServiceMesh 的使用体验,这是目前业界通用的做法。
为了实现短接内核网络协议栈的目标,我们需要使用到 ebpf 提供的两种能力,分别是:sockops 与 socket redirection,openEuler 使用的 kernel 版本为 5.10,已经支持了 ebpf 的这两种能力。
-
sockops 提供了在 tcp socket 创建连接时将 socket 使用 key(一般是四元组)标识后保存在 sockmap 数据结构中的能力 -
socket redirection 在传输 tcp 数据时支持使用 key 去 sockmap 中引用 socket,命中后可直接将数据转发到此 socket 中 -
对于未在 sockmap 中找到的 socket,正常将数据包通过内核网络协议栈发送出去
将这些能力结合在一起,就可以在不经过内核网络协议栈的前提下直接将数据包转发到对应的 socket 上,完成数据的一次传输,降低在内核网络协议栈上的时间消耗。
在 tcp socket 建立连接的过程中,实际上有两次连接建立的过程,我们通常称之为正向连接与反向连接。因正反向连接在建连过程中均需要通过 iptables 信息来获取实际的 ip 地址与端口号,openEuler 在 iptables 的工作原理上新增 helper 函数,将获取对端信息的能力下沉到内核中,可以在 ebpf 函数中主动获取到 iptables 转换过的地址。这样我们可以建立一个辅助 map 用于存放正反向连接的对应关系并在 socket redirection 转发时先从辅助 map 中寻找到对端的连接信息,成功找到对端的连接信息后再进行 socket 转发动作。原理如下图
通过 sockops 能力的加速,我们在 openEuler21.03 上实测的结果如下:
-
测试环境:openEuler-21.03 / 5.10.0-4.17.0.28.oe1.x86_64 -
组网:fortio-envoy-envoy:80-fortio_server:80 -
qps 提升约为 18%,平均时延提升 15%
下一步的工作:彻底消除 ServiceMesh 性能损耗
从 openEuler21.03 实际测试中可以看出,sockmap 对于 ServiceMesh 可以进行加速,但是加速的结果与不使用 ServiceMesh 相比仍然有较大差距。仔细分析,sockmap 并没有消耗 socket buff 之间的数据拷贝,也没有消耗 app/envoy 之间通信时的上下文切换,那问题可能仍然出在 ServiceMesh 架构上。有没有一种方法,既有 ServiceMesh 易管理、易部署的能力,又能消除其带来的性能劣化影响?目前 openEuler sig-high-performance-network 正在尝试这方面的工作,已经有了初步进展。有兴趣加入我们一起完成这个目标吗?可以订阅以下邮件列表或添加微信联系我们~
-
high-performance-network@openeuler.org -
dev@openeuler.org
本文分享自微信公众号 - openEuler(openEulercommunity)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
干货分享!边云融合的时序时空数据库实践详解
随着物联网、车联网、工业互联网和智慧城市快速发展,时序数据库成为数据架构技术栈的标配,面对海量时空数据,随之而来是数据存储、处理问题,也对时序数据库高效读写、快速查询能力提出了更高要求。本文将和大家分享物联网商业应用场景下时序数据库(Time Series Database)的能力要求和技术核心点,以及时序数据库赋能各领域应用场景落地实践。 01 关于时间序列数据 时间序列数据是指某一指标在不同时间上的不同数值,按照时间先后顺序排列而成的数列。这类数据库在日常生活中十分常见,像环境温度的监控数据,直播房间的监控数据,无人车的运行数据等都是时序数据。 它们通常都有以下的特点: 结构特性:时序数据一般都具有单向递增的时间戳,并且对于数据批量或特定删除的场景较少,数据清理一般基于时间窗口。 场景特性:由于在时间维度上的累计,时序数据的数据量通常较大且往往写多读少、读写正交。时序数据通常按照固定频率不断写入,写入数据流量具有平稳可预测的特点,且读和写一般发生在不同时刻,。和关系型数据库相比,因为应用场景的不同,通常不会涉及太多的事务性原则。 应用特性:时序数据在应用上大多进行聚合趋势分析...
- 下一篇
由IDC余热回收的创新技术实践与跨界合作探讨
1 背景 2020年国家正式宣布了双碳战略目标:“力争2030年前二氧化碳排放达到峰值,努力争取2060年前实现碳中和。” 数据中心作为耗电大户,其耗电量已经超过全国总耗电量的2%,预计2025年总耗电占比将达到4.05%。但随着信息技术的发展,社会对于算力的要求越来越高,IT设施的单位电力所能提供的算力极限也逐渐逼近,这就意味着想要多产出算力,就只能多供给能源。对数据中心而言,这无异于带着脚镣跳舞,既要提供大量算力又要符合国家双碳战略。 随着相关部门出台大量相关政策规范数据中心的用能情况,各家大厂和相关上下游企业都在寻找各种节能减排的解决方案,余热回收技术就是其中之一。 2 余热回收是什么 余热回收是指将受历史、技术、理念等因素的局限性,在已投运的工业企业耗能装置中,原始设计未被合理利用的显热和潜热进行回收利用的技术。 服务器运算的本质是电力输送至设备,产出算力与热量。数据中心作为用电大户,其计算产生的废热也非常多,如何回收利用这些废热,是一个比较重要的议题。 图1 数据中心产生废热理论基础 暖通系统作为数据中心机电系统中耗电最多的一部分,其冷却水环路的回水温度仅有38~40摄氏度,...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8安装Docker,最新的服务器搭配容器使用
- Windows10,CentOS7,CentOS8安装Nodejs环境
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- Linux系统CentOS6、CentOS7手动修改IP地址
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- MySQL8.0.19开启GTID主从同步CentOS8
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装