浅谈闪存阵列的市场机遇 – 性能篇

    EMC在2012年5月10日收购了闪存阵列制造商XtremIO。全闪存，听起来就很带劲，在性能上一定非常强悍。那XtremIO是否就是插满SSD的传统存储？如果是这样，EMC把自家存储上的机械硬盘全部换成SSD不就成了“全闪”嘛，为什么还要大费周章特意去买一家公司？今天我从性能的角度谈一下这个问题。

为什么传统存储设计不适合承载“All SSD”？

    磁盘阵列的根本依然是硬盘，硬盘的特征是存在机械移动部件，所以特别讨厌随机I/O，过多的寻道会影响性能。因此，针对基于硬盘的阵列，设计者一开始的想法就是尽可能的让阵列处理顺序I/O，即便跑在服务器上的App生成的是随机I/O，存储系统也应该极力将其转化为顺序I/O来处理。一个简单的例子就是缓存，思路是先将incoming I/O囤积在缓存，然后通过【Coalescing】尽可能的将【地址临近的I/O】合并以顺序的大I/O方式写入磁盘，减少寻道带来的延迟。

    再来看控制器，有试过把你目前存储上的硬盘全部换成等额数量的SSD（假设有一定数量规模）并以给定的压力来测试性能吗？我相信CPU很快就会100% UT -> system down，why? 我们通常都是以IOPS为标准去测试存储性能，而IOPS暗指了随机、小I/O，比起带宽，IOPS更吃CPU。给定系统的瓶颈通常不是CPU，而是磁盘。在保证磁盘不过载（是否过载通常是看磁盘队列）的前提下所生成的工作负载一般不足以榨干CPU的性能，但换成等额数量的SSD后，IOPS暴增，所以通常CPU会先于SSD达到极限。要说带宽也行，但是SSD相对传统SAS/FC磁盘在处理顺序大I/O方面并没有太大优势，所以带宽的瓶颈通常在PCIe总线，IOH，SAS/FC后端控制器。为什么换了一套驱动器系统（磁盘 -> SSD）就瞬间抵挡不住了呢？因为在设计上没有考虑到如此大的后端I/O能力。

    归根结底，如果用favoring sequential I/O的系统来host favoring random read I/O的SSD，那么所有这些设计优化对于SSD来讲，相关性很小，这种mismatch的结果一定不会如你预期的那么好。

    所以系统需要重新设计，无论是硬件还是软件架构，必须重建，为SSD专门设计。XtremI/O就是做了这样一件事情，然后EMC就给收了。当然，性能只是系统需要重新构建的考虑因素之一，其它存储系统功能，比如快照、克隆、去重、精简资源调配和复制原本也都是基于底层磁盘管理引擎所构建的，应用了同样的规则和限制，而且favoring sequential I/O。虽然为传统存储插满SSD不会破坏这些功能，但你同样看不到给它们带来的增强。

    一句话，新系统的设计要符合SSD的胃口，而SSD的特质就是random access without performance penalty。

为什么全闪存存储会有市场？

    CPU/RAM的性能近年来飞跃式增长，而问题是存储子系统却无法跟上脚步，换句话说，存储系统所能提供的I/O无法“喂饱”CPU这只怪兽，浪费了CPU time。尤其是在数据中心内，一台存储通常连接许多服务器，很多时候一个LUN并不是给单个App使用的，在这种情况下，即便多个App本身是Sequential I/O，但当多个sequential data stream冲向同一个LUN时，最终存储看到的都是random I/O。虽然存储设计为尽可能对后端磁盘做sequential I/O，但在这种情况下sequential I/O是做不到的，这种情况称为I/O Randomization。下图是以前最为常见的服务器使用存储的方式，为什么说“以前”？因为现在是Virtualization的天下。



    如果三个data stream还不够多的话，那是什么加速了data stream的增加？一个最直接的答案就是：more CPU power + Virtualization -> increased VM density -> more pressure on storage -> I/O Blender

    解释一下上面的这段话。CPU原本是通过增加晶体管和时钟频率来提升性能的，但近年来的一个转变是【multi-core + multithreading】，这本身就助长了I/O Randomization。考虑这样一个服务器配置【dual socket, 6 cores/socket, 2 threads/core】 -> 2*6*2 = 24 unique data streams。如此强悍的服务器只承载单个App是否过于浪费了（Map-Reduce style data-intensive workload除外）？所以人们开始采用Server Virtualization来host multi-VM，再一次加剧了I/O Randomization。如果多台这样的物理服务器连接同一台存储，来自成百上千的混合流量立刻会使得存储的workload变得completely random，这就是所谓的I/O Blender。

    再简单一点，Massive Consolidation + Intensive Randomization -> I/O Blender。下图是我们目前服务器使用存储的常见情况，虽然服务器依旧只有三台，但对于存储来说，已不仅仅是三个workload，而是一堆。

    所以I/O Blender给尽可能顺序化I/O的设计初衷带来了挑战，但人类总喜欢master complexity，所以会继续面对挑战，目前的对策有如下这些：

• 增加存储缓存容量：支持TB级别的缓存对于企业级存储来讲已经不稀奇了，更大的Cache加大了聚合分散随机I/O的可能性。缺点也显而易见，cache memory贵啊，而且read performance依然是个问题，random reads导致cache miss，从而不得不访问后端磁盘。
• 把流量分散到更多的磁盘：如果workload越来越随机化，那么我们就需要更多的盘来增加IOPS。缺点也很多，cost + space + power consumption + inefficient capacity UT，而且东西多了，规划自然也就更复杂。
• 添加flash tier or flash cache：添加SSD的确加速了性能，不过本质问题依旧，设计不匹配，SSD一不小心就会overload整个存储，适得其反。值得注意的是，用于cache之后，flash将经常遭遇write cycle（promotion <->write back），所以需要耐久度（endurance）更高的SLC闪存。另外，caching和tiering的效率取决于App，即便只有10%的I/O go to backend disk，App的serialization transaction通常都会受到响应时间的限制。所以要维持一个始终可预测的高性能对于caching/tiering这种方案来说并不总是可行的。

    虽然可以通过这些方案来应对I/O Blender，但CPU性能的增长势头也预示着海啸般的流量冲垮caching/tiering是迟早的事情，大量的活跃数据要求more memory + more flash as cache，这种无限增长是不可能的。再者，即便caching/tiering防线守住了，为机械硬盘所设计的控制器可能根本挡不住这么大的流量，这也是为什么我们在VNX/CLARiiON上会考虑如何不让FAST Cache冲垮CPU和back end bus的问题了（虽然VNX SAS的24Gbps后端抵抗力要强很多）。

    其实很多问题都是相同的，一种架构不可能服务到永远，master complexity也只会导致更为复杂的系统，带来新的问题。解决方案只有一个，推到重来。最近SDN的概念其实如出一辙，Internet架构是几十年前的设计了，之所以还能建在是因为人类的伟大，无数牛人绞尽脑汁来master complexity，6K多个RFC/IEEE protocol解决了无数问题，同时也把网络系统变得极为复杂，是时候back to simplicity了。