算你能存之π百万亿位与QLC再攻主流

近来,Solidigm连搞两个大新闻——首先是StorageReview利用AMD EYPC处理器和Solidigm QLC SSD构建的服务器刷新了计算100万亿位圆周率的世界记录,总用时为59天10小时46分49.55秒。

上一个记录是在2022年,谷歌云(Google Cloud)在人类历史上第一次将圆周率计算到百万亿位,总用时为157天23小时31分7.651秒。

也就是说,这一次只用了三分之一多一点的时间。

圆周率百万亿位的最后十位数字是:

3095295560

圆周率100万亿位是一个什么样的概念的?如果一张A4纸打印1万位数字,那也需要100亿张纸,摞起来需要1000公里高;如果平铺的话,北京市海淀区的地皮肯定不够,再拉上东城区、西城区、石景山区帮忙都有点儿勉强。那存硬盘里总可以吧?讲真,一般人家里压根儿就存不下这个数。因为单单是以十进制数的文本方式存储它,就需要100TB的空间。所以,计算极高精度圆周率是一个计算密集、存储密集的任务。

谷歌云当时使用的计算节点为运行Debian Linux 11的n2-highmem-128,对应的配置为Intel Xeon 128 vCPU、864GB内存,网络接口带宽为100Gbps。存储节点为32个n2-highcpu-16,每个节点配置了2个10359GB的区域平衡持久磁盘(Zonal Balanced Persistent Disks),16 vCPU,32Gbps网络。

(图片来源:Google)

这里顺便简单介绍一下谷歌云的几种持久磁盘(PD):

☞ SSD Persistent Disks:SSD持久磁盘显然基于SSD构建,适合需要高IOPS的工作负载。

☞ Balanced Persistent Disks:平衡持久磁盘也基于SSD,平衡的是性能与成本,拥有较低的每GB成本和较低的IOPS。

☞ Standard Persistent Disks:标准持久磁盘,基于机械硬盘(HDD),价格实惠,适合顺序读/写操作。

根据谷歌云的相关介绍,平衡PD的(每实例)读写吞吐量为1200MB/s,IOPS可达80k,成本和单位容量的吞吐量(MB/s per GB)均在SSD PD的60%左右。从这个指标看上去,谷歌云当时就意识到这个任务的特点是容量比IOPS重要。

谷歌云运行整个百万亿位π运算项目使用的总容量为663TB,峰值用量515TB,处理的数据总量为82PB(读取43.5PB,写入38.5PB)。

成本方面,谷歌云内部怎么结算我们无从得知,不过我们可以通过公开数据大致算一下。一个n2-highmem-128每个月平均5000美元,一个n2-highcpu-16每月平均400美元,整个集群跑上半年大约需要10万美元。

现在回过头来看破纪录。StorageReview使用了一台(物理)服务器,具体配置为:

CPU:双路AMD EPYC 9654(96 核,基准频率2.4 GHz,加速3.7 GHz)

内存:24槽64GB DDR5 4800内存,总计1.5TB

SSD:19个Solidigm D5-P5316 30.72TB,可用530.1TB

操作系统:Windows Server 2022

基于同样的算法,这个系统使用的容量峰值为514.5TB,与谷歌云相同。数据吞吐量略有差异,为读取40.2PB,写入35.4PB,总计75.6PB。

从硬件角度看,新记录的处理器内核数量为谷歌云的3倍,192核AMD第四代EYPC对64核(128个超线程)Intel第三代至强,内存容量约为2倍。存储方面的性能看,19个本地QLC SSD的纸面带宽(写3200MB/s×19=60800MB/s)与32个存储节点(1200MB/s×2×32=76800MB/s)大致在一个数量级;IOPS方面,随机写入肯定是本地QLC SSD较弱,益企研究院曾经测试过D5-P5316,其64KB随机写IOPS大约是8K,低于平衡PD的指标,考虑到数量,总IOPS更不可比;至于读性能,则不论是顺序读还是随机读IOPS,本地QLC SSD的优势都很明显。

但是,如果考虑到网络瓶颈,那情况就不一样了。根据数据的总读写量和总时间,我们可以估算出系统平均每秒需要读或写8GB/s的数据,谷歌云计算节点的100Gbps网络带宽只能应付平均水平的吞吐量。而峰值是多少呢?StorageReview称突发写入可以达到38GB/s,这起码需要400Gbps网络才能应付。

简单说,三倍数量的处理器内核,没有瓶颈的本地存储,共同创造了新的记录。至于这样一台服务器的成本,我们的读者有很多行内人,可以在后台给我们留言。

综合来看,StorageReview的目标是以较低的成本刷新记录,构建服务器时使用了目前性价比最好的双路x86处理器,以及容量刚好够用的SSD。对于SSD而言,这一次应用并不考验随机性能,QLC的吞吐量是满足需要的,其容量和性价比优势就显得尤为突出。要知道,现在市场上30TB容量点的SSD凤毛麟角,而D5-P5316是一款2年前上市的SSD,难怪Solidigm要将百万亿位圆周率的记录视为“全村人的骄傲”了。

Solidigm的另一件大事也与QLC相关,即上周正式推出Solidigm D5-P5430,而D5-P5316的“接班人”也快要来了。这两款新品的共同点是采用192层的第四代QLC,在性能和耐用性等方面有高低之分。

耐用性向来是QLC SSD的短板,现如今也能搞出“必要耐用性”(D5-P5430)和“足够耐用性”(D5-P5316“后人”)这样的细分来,是不是真的要走向主流了?

应用是检验耐用性的第一标准,让我们回到破百万亿位圆周率世界记录的案例来分析一下写入量。计算期间,每个(D5-P5316)SSD每天大约需要写入30TB的数据,也就是1DWPD。整个项目运行下来,SSD的寿命损耗在2~3%。按照这个强度继续运行5年应该可保无虞。

(图片来源:StorageReview网站)

有趣的巧合是:同样的介质,如果设定成TLC模式,那就需要25块盘才能达到目标容量,正好比前面板24个U.2盘位多了那么一丢丢……接下来,我们可以引出几个话题,简单展开一下。

1.QLC SSD的耐久度超出许多人的预期

可能有人觉得单块D5-P5316在写入近2PB数据后,耐久度只损耗2~3%,并不可信。但根据Intel和Solidigm给的保修政策,30.72TB的D5-P5316的随机写耐久度为22.93PBW, 顺序写耐久度为104.55PBW。考虑到圆周率计算整体偏顺序写,CrystalDiskInfo判读的健康信息与厂家的保修政策是吻合的。

(图片来源:Solidigm)

对于顺序写,P5316可以承受接近2 DWPD的工作强度,这次记录中并没有把它逼到极限。

Solidigm在发布D5-P5430时也指出,根据公司内部分析,2020~2023年在全球范围出货的数据中心SSD,大约85%的额定值≤1 DWPD。多伦多大学在2020年的文件与存储技术会议(FAST ’20)发表的论文中表示,“…对大多数情况而言…,将存储系统的写入负载调整到接近QLC SSD的PE周期极限并不会有风险,因为99%的系统使用不会超过其(SSD)额定寿命的15%。”

Solidigm D5-P5430有U.2、E1.S和E3.S三种形态,用于替代M.2的E1.S体积较小,最大容量“仅”15.36TB,U.2和E3.S的最大容量均为30.72TB,追平U.2和E1.L规格的D5-P5316。

性能方面,D5-P5430顺序读写达7000/3000 MB/s,随机读写达971K/120K IOPS,基本上读性能与主流(PCIe 4.0)TLC SSD相当,写性能大约在一半上下,在读多写少的应用场景可以说是相当够用。

最后看这个“必要”的耐用性:D5-P5430随机写为0.58 DWPD,顺序写为1.83 DWPD。凭借容量上的优势,30.72TB的D5-P5430总写入量达32 PBW,也略高于1 DWPD但一半容量的主流TLC SSD。

2.如何用好QLC SSD

圆周率计算属于一次典型的“知Q(LC)用Q”的案例。有那么多顺序读写优化的应用场景给QLC SSD发挥吗?

还真有,而且不少。Intel在推广数据中心级QLC SSD时,曾用一个图表列出了QLC SSD的适用场景。

(图片来源:Intel)

从图中可以看到,AI、大数据、CDN/VoD、HPC毫无意外地成为QLC SSD的优势领域,因为基本上都是大数据块,且读多写少。然后,HCI和云存储也被看做是适合QLC SSD的场景,这就涉及到写缓存或写整形的问题了,将随机写尽量转化为顺序写入。

在上图中,还有一个重要的细节,在读写比例60/40这一列,QLC SSD的领域被划到了64KB及以上数据块大小。个中原因是因为当时Intel的最新QLC SSD就是D5-P5316,其IU(Indirection Unit)也就是SSD内部对介质最小写入单位为64KB大小,如果拿去做4KB随机写,是很不划算的。

但是,千万不要以为QLC SSD只适合64KB及以上块大小。实际上,Intel更早的数据中心级QLC SSD,如D5-P4420,就是用的4KB IU,其4KB随机写IOPS也可以达到36K。在D5-P5316上选择64KB IU是对追求极致QLC成本的尝试,以为用户提供合理成本的大容量QLC产品。就拿D5-P5316的“前任”D5-P4326来说吧,型号虽然也以6结尾,IU则是对客户更加友善的16KB,有些业务甚至可以直接用起来,不需要大改软件。

现在Solidigm的新一代QLC SSD中,D5-P5430已经回到4KB IU,4KB随机写IOPS提升到了110K——与PCIe 3.0 TLC SSD的全速性能相当,容量点涵盖7.68~30.72 TB。

随着新的QLC SSD推出,64KB IU带来的偏科问题也就成为过去式。现在Solidigm已将优势领域做了更新,变成了下面这样:

(图片来源:Solidigm)

在新的区域图中,被“64KB”断开的部分被拉平了,然后,HCI和云存储的场景有了更明确的细分,如索引、分布式存储(DSS)、联机事务处理(OLTP)等。OLTP是典型的传统关系型数据库的一种应用,提到它就顺便说一下在线分析处理(OLAP),后者的吞吐量要求比前者高得多,但总体上是读多写少,也比较适合QLC SSD。

3.SSD性能过剩

上一个话题其实蕴含了一个潜台词:许多应用对SSD的性能需求并不高。事实也确实如此。虽然现在依旧处于数据量爆炸的时代,但瓶颈主要集中在数据的处理,以及数据的存储成本上,性能相对不是那么迫切的问题。

在前面关于圆周率项目存储性能瓶颈的分析当中也可以看到:对于集群,网络带宽是多数应用瓶颈。对于机器学习这种吃性能的应用,瓶颈主要在内存墙,数据在内存、CPU、GPU、显存之间来回搬运,降低了计算效率,而不是元数据喂不饱CPU和GPU。所以用户对PCIe 5.0 SSD的需求并不迫切,甚至,PCIe 3.0 SSD的性能已经足够满足多数应用需求了。业界普遍预期PCIe 4.0 SSD的生命周期会很长。

另外,随着应用水平的提升,用户关注的价值点变得多元化,除了传输率、IOPS、时延等传统指标,还会关注能耗、可管理性、固件定制等等。对于高水平的用户,SSD也不再是传统的块存储设备,而是需要更深入其底层(如ZNS、OpenChannel等),或者转变应用形态(如内存语义SSD等)。

当然,SSD的性能也不至于到了可以故步自封的时候。除了前面提到的内存语义SSD、SCM等,机器学习对高性能、大容量SSD的需求其实就很“朴素”:用较少的PCIe通道数量达到足够的吞吐量或容量。对于机器学习、HPC等,多GPU、多网卡(含DPU)是常规操作,主板上的PCIe通道数量还是很紧张的。

4.为什么数据中心不追求单盘容量

从D5-P5316问世到现在已经两三年了,按说SSD的单盘容量早该进一步提升了,但貌似量产品的最大容量暂时停留在了30TB这个量级。为啥会停滞呢?简单说还是“有什么用”和“该怎么用”的问题。

首先,用户希望控制“爆炸半径”。最大容量如30TB级的SSD,主要客户是大型互联网和云计算公司,这些客户的特点是一台服务器要服务于多个应用和最终用户的访问,越大容量的SSD,承载的应用和用户数据也就越多,一旦(某个环节)发生故障,影响的业务和租户会比较多。如果把容量增加一倍,硬件技术上可行,但也需要在软件架构、用户信心、应用模式等方面有进一步的提升,需要云厂商和用户做出更多努力。

其次,是性能不划算。表面上,较高的单盘容量可以占用较少的空间、较低的能耗,但是,平均每单位容量的性能降低了——可以回想下谷歌云的SSD PD和平衡PD。对于同一代的SSD,容量较低的一两个型号的性能会低一些,之后各容量的性能就会大致相同。以云服务为例,虚拟机/实例的基本参数是CPU数量和存储容量,然后,根据吞吐量、IOPS提供分级的报价。如果配置大容量的SSD,那么,分配到每个实例容量所对应的IOPS可能会很低,缺乏竞争力。

当然,把接口升级到带宽加倍的PCIe 5.0可以暂时缓解单位容量性能下降的问题,但是前一个“紧箍咒”还在呢不是。

既然用户端没有强烈的愿望,那就要从技术和成本角度算算SSD进一步做大的难度了。譬如逻辑到物理的映射,容量越大,成本越高(想想TLB的占用)。前面提到的64KB IU是一种思路,但会付出应用范围变窄的代价,不具有普适性。要从根本上解决这种问题,最好还是动底层,如上一节提到的ZNS等。活跃在这个领域的是少数互联网大厂,以及全闪供应商。换句话说,这是用户的应用水平去决定的。所以,从标准化的块存储设备角度,SSD的发展恐怕还真得套用一下“公知体”:等一等软件和上层应用的发展。

上一篇
下一篇