Please enable JS

“杉岩两语”如何优雅的解决SSD的写入放大问题

/2017-3-30 16:08:51

SSD的出现在存储界具有里程碑的意义,尤其是在软件定义存储方兴未艾的当下,你要是不在存储中加上几块SSD,你都不好意思和友商打招呼。

Gartner报告显示,全闪存阵列市场的整体规模将以年均37%的复合增长率持续拓展,而2020年数据中心单纯利用全闪存阵列技术进行主数据的存储比例将会达到25%,闪存技术正在收到越来越多用户的青睐。

不过,金无足赤、人无完人,如此牛逼的SSD缺因为自身的运行机制,却也具有了一个先天的不足,即写入放大的问题。在9年前,Intel公司和SiliconSystems公司(2009 年被西部数字收购)第一次提出了“写入放大”(Write Amplification,简称WA),并在公开稿件里用到这个术语。

要了解写入放大就要先从SSD的写入机制说起:

机械硬盘写入机制:

老司机发车,如何优雅的解决SSD的写入放大问题

SSD写入机制:

老司机发车,如何优雅的解决SSD的写入放大问题

SSD的设计完全不同于机械磁盘,甚至可以认为SSD就是一个五脏俱全的小型PC。首先,因为没有写磁头,在读写数据的时候就少了磁头在磁道之间的寻道过程,所以也就能提供较高的IOPS性能。这里插一句,很多人认为因为少了机械磁头的搬来搬去,会减少电量的使用,但这一点其实并不绝对,比如有的NVMe类型的SSD在耗电量上并不比机械硬盘低。

但当SSD被写满一遍后,再写入数据就需要对原有的数据进行擦除(注:一般擦除的单位要比最小写入单位大,比如常见的写入单位,即页大小是4K,但常见的擦除单位,即块大小是512K或者更高),这就额外增加了一个步骤,所以整体的速度就下来了。就像一张纸,频繁的用橡皮擦除,纸就自燃变薄了,而写入放大增加了SSD整体写入的数据量,自然也就减少了SSD的使用寿命。

那到底什么是写放大呢?

让我们举个例子来进行说明,假设要写入一个4KB的数据,可是一个块里已经没有干净空间了,但是有失效的数据可以擦除,所以主控就把所有的数据搬到缓存或者OP空间,然后擦除块,再加上这个4KB新数据写回去,这个操作就造成了写入放大,即本来是写4K的数据,却造成了整个块(以512KB为例)的写入操作,也就是128倍放大(当然,真实世界的SSD内部主控不会这么“傻”,但写入放大却是真实存在的)。

同时,原本只需要简单的写4KB的操作变成读取(512KB),擦(512KB),改写(512KB),造成了延迟大大增加,写的速度自然就慢了。当这样的擦除过多时,也就影响了SSD的使用寿命。

所以一个有效的方法就是可以通过修改OP预留空间,以及及时清理固态硬盘中的无用数据,留出更多的空白空间,以减少多余的擦除和写入,从而降低固态的写入放大值,提升固态寿命,但这种方式最大的问题是对SSD造成了浪费。

老司机发车,如何优雅的解决SSD的写入放大问题

除此之外,正如我们前文说的,SSD可以看作是一个迷你型的PC,在设计SSD的时候,写入放大问题也是主控芯片设计要考虑的主要问题之一。

SSD发展至今,本身已经演绎出了很多具体的功能来解决写入放大的问题,比如对齐写、追加写、Trim命令、垃圾回收、磨损均衡等功能机制,进而提升自身的使用寿命。

而在目前流行的软件定义理念的趋势下,则是通过软件定义的方式,在主机端通过软件控制自己的访问行为,使之更符合SSD的特性,进而解决SSD自身硬件上的“不理性”。很多老司机喜欢称这种方式为Host Based(别翻译,翻译显得不专业),而传统使用SSD的方式,是把SSD完全当机械硬盘一样用的,即 Device Based的方式。

这里以仅以杉岩数据在追加写方面的改进为例:

常见的随机写入(Random writes)会写入很多非连续的LBA(Logical Block Address),将会大大提升写入放大。

所以在使用SSD作为cache时,利用软件定义的方式,将发往SSD的随机IO变成顺序IO,使得写入SSD的数据都是追加写,而不是原地更改的写,这样就减少了SSD的写入放大,而对于被覆盖写的数据,使用Trim命令以及智能的垃圾回收机制,保证了用户数据空间的及时高效回收。

在测试中,我们往往会遇到很多这样的情况:在硬件配置相同的情况下,不同的软件性能会相差很多。这其中最主要的原因就是写放大的问题,写得多不如写的准!所以,一款好的存储软件一定需要一个好的算法,一个好的算法一定需要尽可能的减少写入放大。对于减少写放大的问题还有一些其它的方法,比如静动数据分离等等,由于篇幅有限,这里不再赘述。

在可预见的未来,搞定写入放大者得SSD,得SSD者,得天下。