超算和智能网卡

AWSre:Invent2019显示AWS市场占用率达到45%,相比2018年营收增长29% 。使用专用芯片构建用于加速特定场景的战略更加清晰,除去IntelAMD的X86和NvidiaGPU,还有通过其AnnapurnaLabs部门推出的基于Arm的Graviton的定制芯片,并承诺基于Graviton2(7纳米)的新型EC2实例的性能是第一代Graviton的7倍 。
早在摩尔定律失效之前,一个逐渐达成的共识就是通用处理器的算力应该专注于复杂的商业逻辑,而简单重复的工作则由专用芯片完成更加合适 。
超算和智能网卡
早在20年以前,基于异构计算的智能网卡就已经应用于超算(HPC)领域 。从1993年开始TOP500就以每年两次的频率,基于Linpackbenchmark负载模型来统计地球上运行最快的超级计算集群 。
2003年,弗吉尼亚理工学院暨州立大学创建一个InfiniBand集群,在当时的TOP500排名第三;
2009年,世界500强超级算机中,152个使用InfiniBand,并提供38.7%的算力;
超算和智能网卡
文章插图
2020年11月,根据最新的第56版,155个使用InfiniBand,并提供40%的算力,排名前10的超算集群有8个由InfiniBand构建,更是占据了前5的4席位置 。
超算和智能网卡
文章插图
在构建高速网路时,争论主要是把网络功能Onload到CPU上,还是把这些功能Offload到专用硬件:
常用Onloading,TCP/IP技术在数据包从网卡到应用程序的过程中,要经过OS,数据在主存、CPU缓存和网卡缓存之间来回复制,给服务器的CPU和主存造成负担,也加剧网络延迟 。
Offloading基于RDMA实现远程内存直接访问,将数据从本地快速移动到远程主机应用程序的用户空间,通过Zero-copy和Kernelbypass来实现高性能的远程直接数据存取的目标 。
下图可以直观的看到两者在访问路径的区别:
超算和智能网卡
文章插图
当然,Offloading需要将RDMA协议固化于硬件上,所以依赖于网卡的算力是否可以满足运行RDMA协议的开销,这实际上就是专用芯片和网卡的结合 。用更性感的说法是
SmartNICsareanexampleofDPU(DataProcessingUnit)technology
AWS和Nitro
云计算催生超大规模数据中心,也同时放大通用算力的不足和异构计算的优势 。就好比研发团队规模变大的同时必然走向专业化 。AWSEC2早期由纯软(也意味着需要消耗CPU)的Xen对CPU、存储和网络完成虚拟化 。基于这种实现方式,一个EC2实例的虚拟化管理开销高达30% 。
超算和智能网卡
文章插图
30%相当可观,最重要的是并没有为客户提供直接价值 。按照WernerVogels(AWSCTO)的说法
想为客户显著提高性能、安全性和敏捷性,我们必须将大部分管理程序功能迁移到专用硬件上 。
2012年,AWS开始构建Nitro系统,也正是这,登纳德缩放定律(严格说是预测)几乎消失:
超算和智能网卡
文章插图
2013年,Nitro应用于C3实例,其网络进程卸载到硬件中;
2014年,推出了C4实例类型,将EBS存储卸载到硬件中,并开始和AnnapurnaLabs合作;
2015年,收购AnnapurnaLabs;
此时,Nitro系统已经包含三个主要部分:Nitro卡、Nitro安全芯片和Nitro管理程序 。主要卸载和加速IO,虚拟私有云(VPC)、弹性块存储(EBS)和实例存储,从而让用户可以使用100%的通用算力 。
超算和智能网卡
文章插图
对客户而言,意味更好的性能和价格,下图可以看到基于Nitro的C5和I3.metal的延时明显降低:
超算和智能网卡
文章插图
计算型存储和数据库
从AWS的营收看,网络、存储、计算和软件是收入的四驾马车,数据库毫无疑问是存储领域的关键场景 。随着云计算带来基础环境的改变,也直接加速云原生技术的发展和成熟,程序员不会再写出单体(Monolithic)应用,也再也不会在应用中只使用一种数据库 。还是借用WernerVogels的话
Aonesizefitsalldatabasedoesn'tfitanyone.
从AWS提供的数据库服务也应证了一点(国内的云计算巨头也类似) 。
超算和智能网卡
文章插图
不同的数据库针对不同的场景,比如Airbnb使用Aurora替代MySQL,Snapchat使用DynamoDB承载起最大的写负载,麦当劳将ElastiCache应用于低延时高吞吐的工作负载,旅游网站expedia.com使用ElasticSearch实时优化产品价格 。当然,对于存储介质,更快速和更大容量的需求普遍存在 。从下面数据库的工程实践看,压缩是实现这一目标的共识:
DB-EnginesDBMS数据压缩特性

压缩率依赖于数据本身,1948年由美国数学家克劳德·香农(ClaudeShannon)在经典论文《通信的数学理论》中首先提出信息熵,理想情况下,不管是什么样内容的数据,只要具有同样的概率分布,就会得到同样的压缩率 。
在实现时,常常要在压缩吞吐,解压吞吐,和牺牲压缩率之间做取舍,这也是产生诸多压缩算法的原因 。下图是基于Silesiacompressioncorpus不同压缩算法之间的差异 。

从一个常见的场景出发,应用多次写入压缩率各不相同的数据,逻辑写入量为36KB,如下图所示:
超算和智能网卡
文章插图
按照前面所示的压缩率,最理想的情况是压缩后占用15.2KB 。
超算和智能网卡
文章插图
但现有的空间管理实践会占用更多的物理空间,首先写入时需要按照文件系统页对齐写入(假设4KB),占用物理空间为48KB,数据存储分布如下图所示:
超算和智能网卡
文章插图

超算和智能网卡
文章插图
但因为压缩后数据依然需要按照文件系统页大小(4KB)对齐,数据存储分布如下图所示:
超算和智能网卡
文章插图
所以实际占用的物理空间是36KB离预期的压缩率相去甚远 。
超算和智能网卡
文章插图
【超算和智能网卡】为进一步提升压缩效率,通常会进一步压实(compaction)空间,压实后数据存储分布如下:
超算和智能网卡
文章插图
这时占用的物理空间是16KB,才接近15.2KB 。
可见在工程实践时,要想在应用场景中获得可观的压缩收益,仅关注数据结构和压缩算法是不够的,还要考虑压实(Compaction)效率,如果还要兼顾算力消耗、IO延时和代码复杂度等指标,工程难度将指数级提升 。
针对这个场景,支持透明压缩的计算型存储CSD2000,将压缩解压缩算法offload到盘内FPGA,使计算更靠近数据存储的地方(“in-situcomputing”),进一步缩短数据路径,从而提升数据处理的效率 。
对比“软”压缩(基于CPU)和硬压缩(基于FPGA)两者的收益并不复杂,下面以MySQL为例,将MySQL页压缩,MySQL表压缩和CSD2000透明压缩三者进行对比,采用TPC-C和TPC-E数据集和负载模型,以压缩率和数据库性能(TPS和时延)为指标衡量压缩效率 。
先看压缩率,计算型存储CSD2000提供更高的压缩率,几乎是MySQL自带压缩的2倍以上,如下所示:
超算和智能网卡
文章插图
再看性能,使用sysbench测试1/4/16/64/256/512并发下性能表现,可以观察到(如下图所示):
≥64并发时,CSD2000QPS/TPS平均提高~5倍,最高提高~12倍,99%平均时延降低68%以上;
<64并发时,CSD2000 QPS/TPS普遍高于普通NVMe SSD 20%~50%,99%平均时延降低8%~45%;
说明:为了便于对比,以普通NVMeSSD指标为基线做归一化 。
超算和智能网卡
文章插图

超算和智能网卡
文章插图
MarkCallaghan(FacebookDistinguishedEngineer)曾经吐槽在数据库中实现透明页压缩并应用在生产环境,工程实现过于复杂,难怪JensAxboe(Linux内核代码主要贡献者之一,FIO和IO_URING的作者)建议他把这些工作丢给计算型存储公司ScaleFlux 。而从计算型存储带来的压缩及性能(详见:可计算存储:数据压缩和数据库计算下推)收益来看已经超额完成任务 。
超算和智能网卡
文章插图
计算型存储和文件系统
压缩同时减少数据写入量(NandWritten)和写放大(WriteAmplification),但实际的情况会更复杂一些,大多数情况下数据库运行在文件系统之上 。
超算和智能网卡
文章插图
以日志型文件系统ext4为例,设计以下测试验证日志写入量与数据库数据写入量的比例及透明压缩对于减少写入量的收益:
选用MySQL和MariaDB;
200GB数据集;
3种负载模型:Insert/Update-Index/Update-Non-Index;
两种数据访问方式:热点集中(Non-uniformKeyDistribution)和全随机(UniformKeyDistribution);
最终测试结果如下:
因为文件系统的WAL(WriteAheadLog)机制,加上日志的稀疏结构,日志写入量占整体写入量20%~90%,可见文件系统日志写入量可能大于上层应用(数据库)的数据写入量;
透明压缩对于减少数据库数据量的写入效果明显,对于减少日志系统写入量的效果更加显著,全部测试场景减少日志写入量约4~5倍;
说明:以普通NVMeSSD指标为基线做归一化,直方图面积越小,数据写入量越少 。
超算和智能网卡
文章插图

超算和智能网卡
文章插图
人类的智慧注定都要在山顶相遇
亚马逊经常谈论单向(one-way)和双向(two-way)门决策 。双向门决策容易逆转,例如A/Btest,这类决策可以快速采取行动,即使失败,成本也不高 。单向门决策大多数时候不可撤销,必须”大胆假设,小心求证“ 。Nitro显而易见是一个单向(one-way)门决策,即便是2012年开始,AWS也花了足足7年时间才完整落地 。
在异构计算领域,头部云计算厂已经达成共识,相关产品也加速推出,包括支持计算下推的阿里云PolarDB(详见:可计算存储:数据压缩和数据库计算下推),以及AWSre:Invent2020再次提到的基于AUQA(AdvancedQueryAccelerator)节点加速的Redshift 。
风物长宜放眼量,人类的智慧注定都要在山顶相遇 。
责任编辑:lq
.dfma {position: relative;width: 1000px;margin: 0 auto;}.dfma a::after {position: absolute;left: 0;bottom: 0;width: 30px;line-height: 1.4;text-align: center;background-color: rgba(0, 0, 0, .5);color: #fff;font-size: 12px;content: "广告";}.dfma img {display: block;}
超算和智能网卡
文章插图

    推荐阅读