戴尔叶毓睿：戴尔Fluid Cache for SAN实现500万IOPS

2014年12月2日，由中国软件行业协会、中国计算机学会、武汉国家光电实验室和国防科技大学大力支持，DOIT传媒和存储在线联合主办的中国数据存储年度盛会—— 2014(第十届)中国存储峰会今天在北京盛大开幕。作为中国存储产业的十年盛会，峰会以“掌控数据经济·重塑商业价值”为主题，邀请超过1500位学术界顶级学者、产业精英和企业用户出席，围绕数据经济和商业价值两大话题，从云计算、大数据、软件定义和闪存等四个技术方面举行一系列主题演讲和圆桌会议。

在下午的闪存分论坛上，戴尔架构师 叶毓睿发表了题为《为应用提速!戴尔Fluid Cache for SAN实现500万IOPS!》的主题演讲，从应用的角度出发探讨实现500万IOPS这一惊人话题。以下是文字实录：

叶毓睿：首先简单介绍一下我自己，我叫Peter Ye，我之前是在一家Compellent存储，公司在2011年被戴尔收购，现在是在戴尔的渠道部任职存储顾问，支持戴尔的合作伙伴，去做一些培训或者技术支持。

10月23号参加中国的闪存论坛，当时听了一下有各个解决方案里面，比如说在全闪存阵列里，据说有50万的、90万的、100万的、200万的，实际当这个性能到100万的时候，单纯靠磁盘阵列内的已经很难支撑了，而且成本非常高。所以现在我们用了新的方式去突破这个瓶颈，就是Fluid Cache for SAN的解决方案。

今天我要给大家介绍的这个纲要在这里，在介绍之前我们可以先看一下什么是Fluid Cache for SAN，它的优势以及它的场景。然后我会结合我们的实际的案例，也就是在最近的一个月的时间，由我本人亲自参与的一个非常大的项目的一个POC(验证)测试，一个很大的用户，他也在旁边观察，看着测试结果。

首先我想请大家配合一下，就是今年的淘宝双十一没有在网上购物的请举手。大部分都有，今年的淘宝的双十一突破了去年，达到了571亿的人民币，我观察了一下，它这个高峰时期的交易数在每秒8万笔，这是最高峰期的时候。待会儿我会介绍一个实际用户的测试案例是每秒大约在6万5千多，虽然可能不是对等的比较，但是从量级几乎可以达到这样的程度。

我们在进行购物的时候可能最不能忍受是什么呢?就是当你去点页面半天没有出来，或者点提交的时候又在那里停止，其实这个就是它的延时过长。这样的一个性能的问题会使客户体验大大降低，客户有可能不再访问这个网站或者去别的地方，这样也意味着生意的流失。我们看到在这个当中会有哪些因素导致?比如低效的代码，还有可能是基础架构的原因，基础架构最可能成为瓶颈的往往是存储。为什么?我们可以看一下。这是我们看到在过去二三十年里面CPU的发展以几千万倍的速度发展，而存储我们看到从原来的7200转到15000转，它的延时始终是在毫秒这一级，这当中有一个巨大的差距，这样的差距就意味着存储的性能实际上和CPU去相比较是它的一百万分之一，怎么弥补这个差距呢?我们可以看一下。

实际上已经有一些手段和方案去弥补这样的延时差距，比方说我们用像戴尔的存储SC系列里面有一个很好的功能，就是频繁访问数据集中在外圈，不频繁访问的历史数据集中在内圈，这样就可以减少机械臂的摆动，仅此一个功能就可以使得像SATA(改成:SAS)盘等等可以提升20%的性能。还有一种方式就是一个IO写进来，分散到所有的磁盘阵列，显示灯同闪同灭，它突破了以前的局限性，可以使得性能随着磁盘增加而提升。再就是自动分级，后面还会详细讲自动分级。

所以看到有一些相应的对症下药的方案，接下来我们可以看一下在后方存储部署快速的闪存盘，早些时候我们需要300多块盘才能堆出9000个IOPS，当我们把SSD用起来，放到我们的磁盘阵列里，像全闪存这样的阵列。一块盘有读有写的情况下大概到8000个IOPS，这个性能已经提升了很多，能耗降低了很多。但是这还不够，那么这样的方式我们需要注意什么呢?那么它的成本到底多高，寿命怎么样，现在出现了很多SSD，但是市场主流使用的是SLC和MLC，一个是写密集型，一个是读密集型的盘。写密集型SLC的寿命可以达到30万次的全擦写，读密集型MLC可以达到3万次。基于这样的一些东西，戴尔的存储SC系列采取了一个非常好的办法叫做读写分离，怎么做呢?我们可以让这些新写入的数据或者修改的数据都存放在写密集型盘，然后定期会迁移到读密集型盘，这上面的数据只能被读，这样就使得读密集型盘只有3万次的寿命的局限性被规避了，写都是在写密集型盘完成，这个也是存储界，仅仅戴尔的SC系列才有。

比如像6块400G的SLC，加上6块1.6TB的MLC，我们可以提供12TB的SSD性能，但是比纯粹用SLC的方式大概下降到三分之二甚至二分之一。这些都是我们考虑的对症下药的一些手段。

实际我们这边给出一个案例，就是应该是在上半年，我们已经成功落单了一个案例，我们和SAP HANA的集成案例。最早的时候它原有的系统要做分析，做BI分析需要两个小时才能出结果，然后在计算过程中经常发生中断，但是全闪存阵列以后20秒以内就可以出来了。

前面讲的三个技术还不够，只是部分解决了从存储到CPU的鸿沟。现在来看一下我们还有什么方式，我们探讨一下为什么会出现这种情况，其实在后面讲有一个好处，之前都已经介绍了，就是因为IO延迟比较长。我们可以看到一个IO从服务器产生写到磁盘阵列里，要经过内存CPU，还有光纤，还有前端卡到内存，再到存储的后端的SAS卡等等，经历10个环节甚至更多，所以IO延迟非常长，即使吞吐的带宽大，但还是帮助不了，还是要走这些环节，延迟一定在毫秒级。

PCIe SSD性能很高，延迟更是能缩短到微秒级。但是PCIe SSD也面临挑战，比如这个服务器插了几块PCIe SSD，如果没有用完，其他的服务器又没有PCIe SSD的时候可以共享使用它的空间吗?当PCIe SSD的服务器出了问题，或者就是PCIe SSD的设备本身出了问题，那么你的数据是不是能够很好的保护起来?你的业务是不是能够不中断?还有你的方式是只为写入进行加速和只为读进行加速，或者两者都可以进行加速吗?再一个我现在已经把PCIe SSD插好了，比如有两块总共800G的容量，如果容量不够可不可以在线扩容，应对应用规模不断增长。

实际上我们有一个很好的方式来解决，就是我们会创建一个高速的共享闪存层，叫做FAN(Flash Area Network)，这个高速共享闪存层简单讲就是我们的PCIe SSD能够把各个服务器所内嵌的PCIe SSD纳入到一个全局的虚拟缓存池里面，而且在这个缓存池里面去做数据的保护，而且这个缓存池可以共享使用，可以动态的扩容。但是这个还不是最重要的，最重要是什么?我们这个数据放在服务器里总觉得数据不够安全，还是觉得数据写到磁盘阵列才是最安全。所以我们和后端的存储机紧密集成在一起，数据最后会到磁盘阵列上的。这里就提到了前面也有一些朋友提到的技术，为什么要提到PCIe SSD呢?其实也是因为有了RDMA，才帮助到我们在虚拟缓存池做这样的数据保护。戴尔网络交换机S4800就是0.8微秒，我们写到服务器的PCIe SSD，我们的PCIe SSD会立刻复制到另外一个服务器的PCIe SSD，就是用的RDMA的技术，这样一来一回反复确认，总的延迟不会超过5微秒，这样的延迟会使前端服务器感觉好象就是在本地进行读写，本地就进行反馈确认了，非常快，把整个的IO延迟从毫秒缩短到微秒级。

那么我们这个Fluid Cache for SAN解决方案的特点是什么?首先它主要是针对OLTP在线交易和VDI，重点是提供低延迟，非常小的延迟。然后通过数据靠近计算，同时做到什么呢?从服务器一直到后端存储都没有单点故障，可以有效把数据保护起来，在任何一个时刻都至少会有两份数据。而且不只是说读加速，我们还可以为写进行加速，因为我们支持回写(也即Write Back)的缓存技术，就是IO不是一定写到磁盘阵列才反回去。我们使用单个界面，可以把Fluid Cache管理起来，可以动态的在线增减SSD设备，或者在线增减服务器节点。通过这样同样的单一界面也可以把后端的存储管理起来，只需一个界面就可以管理，也不会因为多家的厂商的整合需要找不同的维护人员。我们还是一个开放性平台，可以兼容其他的硬件，比如在我们这个PCIe SSD里面实际有两种角色，一个是高速缓存服务器贡献者，就是插了SSD盘的一些服务器节点，还有一些没有插SSD的叫高速缓存服务器客户端，对高速缓存服务器客户端这样的角色可以不用戴尔品牌的服务器，可以用其他品牌的服务器。最近的测试就把华为的服务器放进去测试，同样也可以为它的数据库进行提速。包括网络交换机也可以支持其他品牌。

我们来看一下它的拓扑图，常规状况下我们的使用就是前端有各种各样的服务器，有些可能是做集群，这些服务器都集中去访问我们的共享存储的逻辑卷，原来是直接访问。如果是Fluid Cache for SAN一开始我们会先架设一个专有的高速的网络，这个网络通常就是由比如说前面提到的S6000或者S4800的交换机，还有服务器里插Mellanox网卡，一起就构成了一个私有的高速网络，在这个网络利用RDMA的技术使得一个服务器可以很快读写另外一个服务器节点上SSD的数据。如果服务器作为贡献者，需要配置PCIe SSD。其他品牌的服务器，尽管它不能成为贡献者，但它同样能享用高速缓存池来提升性能，我注意到前面一个讲座也提到了，大概是10：9，就是如果有贡献者可能可以跑到100万，那客户端可以跑到90万，因为它的延迟确实非常短，只有微秒的延迟。

再来看一下，这时候我们就安装这个流动缓存的软件，接下来做的是什么?就是单一管理界面里面，把原来我的服务器和存储映射的逻辑卷，把这个逻辑卷映射到高速缓存池，经过映射完之后，这些逻辑卷就会被迅猛地提速，而且它提供灵活性，不是说你存储的一百个逻辑卷都提速，而是有选择的，那些逻辑卷希望被提速的，才通过映射放到高速缓存池上，有很大的方便。

我们这个方式和其他的解决方案的最大区别在哪呢?首先其他解决方案到目前为止通常还是停留在这个阶段，虽然在服务器可以支持PCIe SSD，但都是各自为政，没有形成一个Cache Pool。但我们可以，Cache Pool可以被大家共享使用。即便没有插PCIe SSD的节点，比如华为或浪潮的服务器，或者可能原来老旧服务器，也可以利用这个Cache Pool为应用提速。

最后我们这些数据是和磁盘阵列紧密结合在一起的。数据都会每隔一段时间会Flush(刷新)到磁盘阵列上，让它真正落地，形成数据保护。它有什么优势?我们总结一下。

比如说我们可以灵活的去组织多个服务器，构成不同的高速缓存池，一个存储可以支持多个不同的缓存池，或者一个缓存池可以有多个存储。一个缓存池(也即Cache Cluster)里的多个服务器节点，可以规划出不同的子集群，为不同的应用或者应用集群提速。不仅为读进行加速，还可以为写进行加速，第一次写就加速。现在这个，是戴尔的服务器带来的一个独特的优势，我们可以在服务器的前面板通过独有的技术把2.5寸的PCIe SSD进行热插拔，后面的案例分享就有，在线增减SSD设备。

第四个优势也是很独特的，当我的后端的磁盘阵列要创建一个保护点的时候，为了确保数据的一致性会发出一个请求，告诉流动缓存软件，让它把尚未刷新到磁盘阵列的虚拟页先刷新到磁盘阵列，刷完之后再创建保护点，这样在那个时间创建的确实是你要的数据，没有数据丢失或者一致性的问题。这个也是目前为止我们独一无二的优势。

2013年12月的时候迈克尔.戴尔亲自演示了这个解决方案，他可以冒这么大勇气也是因为很自信，因为那么多参会的用户和媒体记者，当时演示就是8台的普通的两路服务器R720，每个都插PCIe SSD，然后后面接SC8000，稳定地跑到了517万IOPS，延时不到6毫秒。我们经过测试8台的服务器的集群可以使得原来的Oracle延时缩短到1%，如果是SQL缩短到14%，提升是很可观的。那使用场景包括OLTP和ERP等等。包括在一些基础架构云平台里面，这是所列出来的一些行业，如金融、政府、医疗、教育、制造、零售等。

接下来是最近我们做的测试，给一个超级大的用户，他想观察我们的流动缓存，首先我们测试一个节点的情况下，可以跑到42万IOPS，这个跟刚才我们前面Intel介绍的都差不多，就是400多K左右，一个节点只看一块PCIe SSD盘，如果一个节点放两块还可以提升，大概可以提升到60多万个IOPS，延时不到0.3毫秒。再增加一个节点可以线性增加到85万IOPS，延时仍然不到0.3毫秒，再增加一个节点可以达到122万IOPS，延时大概在0.3毫秒。如果放两块SSD，每个节点就是60万的IOPS。这个可能大家觉得不够信服，现在来给你们看一个模拟用户实际应用的场景。

用户的需求是做大规模的并发定发，比方说他希望在2000万条，这怎么分配?是200个并发用户，每个用户执行10万次提交，就是先查A表，这个A表是十多亿条记录的表，B表是二十多亿条记录的表。每一次查就是一个10多亿的表，相当于全表扫描，然后再插入到B表。这里比一次性5000条记录提交或者10000条记录再提交的要求更苛刻，这种情况下用户当时期望是什么?就是时长不要超过一个小时，延时平均响应时间不要超过40毫秒。在这里，我特别强调延时，这是因为，用户的使用场景有点类似网上购物，需要买到各个设备是测试之后延时最短的，因为他要保障他的IO从CPU产生到最后落地到盘里，再返回确认给CPU，整个延时要非常短，各个环节要尽量的压缩延时，又为了确保数据的真实，所以提出了200个并发用户，查10万次，而不是一个用户。所以我们看到友商的高端存储是用了75分钟，延时是85毫秒。那我们没有用流动缓存，仅仅用戴尔的一个两级闪存技术，就是读写分离的这种方式，我们测到2000万只用了47分钟，27毫秒。所以对这个成绩我们很受鼓舞，就继续加大它的量，5000万条，我们用了500个并发用户，用户要求并发运行，这时候我们只用了66分钟，时间稍微超一点，但延时是在40毫秒以内，每秒钟的交易是12500，这个是我们用的业内知名的Benchmark Factory的工具，这是工具截图，延时仅38毫秒。后来我们起用流动缓存，我们用的5个节点的，非常惊人，用户大受鼓舞，延时才6毫秒，时间仅仅是12分钟。可以看到每秒的交易数可以达到6万5千多笔。前面提过，淘宝是每秒8万多笔，虽然不是对等的比较，但是数量级相差不大。我们还没用到8个节点，只用了5个节点。我们算了一下和我们自己全闪存比较都提升了五六倍，无论从时间还是延时，刚才的毫秒是38，到这里只剩下6毫秒，提升了6倍以上，IOPS从一万多到六万多，时间从66分钟到12分钟。

我们想乘胜追击，继续考虑一亿条的记录，这时候用的更多并发用户了，1000个并发用户。要知道，这么多用户，IO争用会导致延时的增加。但是也还不错，半个小时，延时只有16毫秒，TPS稍微低一点，但也有5万多，所以用户已经决定购买我们的存储。

除了刚才看到的惊人的IOPS值和延时缩短外，还有很多特点我们做了测试。比如在线增加SSD设备，我们在线增加了第二个SSD设备，除了Cache Pool有动态扩大外，IOPS从44.2万提升到了60.9万，而且延时还减小了，从0.29毫秒降到了0.2毫秒。包括在线增加节点，这里特意找了一个异构服务器，就是一台华为服务器，从合作伙伴那里借了一台华为服务器，这里显示的这个空间给Cache Pool贡献的都是0，因为它只是做为客户端。我们动态的增加进去，也增加了一些戴尔服务器，作为贡献者服务器增加，也即含有SSD设备，都可以让Cache Pool容量增加。相应我们仍然测了很多数据，当时用了200个用户并发跑在这个服务器上，这个其他品牌的服务器仍然享有被提速的好处，达到两万多的TPS的值。

实际上流动缓存是戴尔现在非常先进的技术方案，到目前为止还没有其他的解决方案可以比这个方案更先进，由于我们采用的是自己的服务器、网络交换机以及存储，所以当用户选用的时候不会因为不同方案的组合出现售后问题扯皮现象，而且一个界面可以管理，非常简便。

流动缓存也是属于戴尔的软件定义存储的众多方案之一，为什么这么说呢?首先戴尔其实它的一个理念是什么?没有说一个软件定义存储的软件或者产品可以适用于所有的场景，而是根据用户不同需求推荐。像这种超高性能一定是推我们自己的知识产权的，然后在一些虚拟化场景有可能推PS系列，或者PowerVault MD等等这些方案。但是在高性能这部分一定是这个方式，而且流动缓存的未来的潜力还非常巨大，因为之前它是通过我们收购的一个RNA演进过来的，RNA可以兼容所有的服务器，它甚至可以全局虚拟化每一个服务器的内存，只是说现在出于成本考虑有没有必要现在就做。而且它还能够虚拟化每一个服务器节点的SAS盘，所以它未来的发展潜力还很巨大，很有软件定义存储的特征的。

我们大致做了一个分类，现在进入到全闪存时代，大家听说过比如两年以后单位GB的固态盘可能低于SAS盘，这样一个时代怎么应对不同的性能负载的需求?比如5万以内IOPS，戴尔存储MD系列或PS系列可以考虑，或者是IOPS在数千个到数十万个，我们会推荐戴尔存储的SC系列。当然在数十万以上的IOPS还有一个选择就是流动缓存，与其在磁盘阵列里堆几百个固态盘，还不如去结合前端的PCIe SSD的技术，这样的话有可能单位IOPS的价格会更低，这是在这个区间的处理，这是戴尔的解决方案。

额外再提一句，我们经常听到两年以后单位的GB的固态盘价格可能低于单位GB的SAS盘。但如果使用戴尔的解决方案，现在就能实现。为什么?我们对全闪存阵列的有不同的看法，我们认为全闪存阵列现在很好，可能很多用户需要，但是用户买的时候就觉得成本很高，怎么办?应该是可以支持混合阵列的方式，全闪存可以和客户端的一万多转或者7000转的盘有机融合，数据可以流动。你全闪存的话是在这，如果是读写分离系列价格可能会降到三分之二或者二分之一，很多历史数据显示没有必要放全闪存盘，再结合7200转的盘就可以变成这个绿色的线，可以比纯粹的15000转的配置还要便宜，而且性能是全15000转SAS盘的几十倍。现在就可以以磁盘价格获取闪存性能，前提是全闪存可以支持与后端机械盘做混合，否则就变成两个孤岛了。

再来看一下我们的闪存最近在几个月里的捆绑的销售包，比如说戴尔存储PS系列，我们如果是用它的PS6210XS，是用的9个800G的，17个1万转的SAS盘。这个价格可能在几十万，二三十万，具体要跟销售联系。如果是像能够采用流动缓存的只有10%的用户，剩下90%的用户如果想用高性能负载，考虑预算控制的时候可以考虑SC 4000这个产品，比方用6个400GB的SLC加6个1.6TB的MLC，支持三千个虚拟桌面的用户，达到95000个IOPS，如果需要扩容还可以增长12块，仍然是2U高，里面双控和24块盘全都包括了。当然还能继续扩展到更多盘箱。如果纯粹是6+6价格不会超过60万人民币，所以相比其他友商的全闪存常常超过100万的成本来讲，戴尔SC4000是非常好的选择。

最后总结一下就是我们的流动缓存的优势，数据靠近计算，不存在单点故障。不仅对读加速，还对写加速。还有一个就是使用单个界面，可以在线增加节点，比如从5个到8个节点，或者在线增加SSD设备，而且配制灵活，可以选择某些卷加速，某些卷不加速。都可以统统在一个大的Cache Pool里提速，而且我们兼容其他的硬件。

今天我这部分就到这里，谢谢大家!