数据加速攻略：选择Server Flash还是全闪存阵列？
Fluid Cache for SAN是个什么样的解决方案？
它与全闪存阵列相比，有什么优势？
本文全面阐释了Fluid Cache for SAN，也为用户提供了有关两个方案如何选择的建议。
在8月的中国闪存峰会之后，另外一场围绕闪存话题的“2015中国数据加速峰会”日前在北京举行。尽管会议的名字不同，但闪存在加速数据中心应用中所扮演的重要角色没有改变，不变的还有一位演讲人，有着十几年丰富经验的存储老兵——戴尔大中华区高级存储经理张委，他的演讲重点依然是流动数据4.0和端到端闪存解决方案。
评价一个演讲是否成功，要看观众对内容的吸收程度，以及有没有进一步关注的兴趣。在这两次会议上，都有朋友向我了解、讨论戴尔Fluid Cache for SAN相关技术，而且他们还并不是专门从事传统企业存储（磁盘阵列）的工作——其中一位是分布式存储、文件系统方面的专家，另一位则是来自互联网行业的资深DBA。
除了关注技术实现之外，昨天那位朋友还向我提出了一个问题：“Fluid Cache for SAN与全闪存阵列相比，有什么优势呢？”这确实是一个好问题，也引发了我进一步的思考。如果两个方案同时放在用户手里，该如何选择？——在回答这个问题之前，我想带大家先简单回顾一下相关的产品技术。
Fluid Cache
高速、可靠、阵列整合的服务器端闪存
在外部存储阵列中使用闪存，其性能会受制于存储网络瓶颈，此外还有RAID保护、阵列本地管理等方面的抵消。因此，最终的服务器实际访问性能与SSD理论计算性能的差距很大。
如何更好地发挥闪存性能？Fluid Cache for SAN不只是把SSD/PCIe闪存卡放到服务器中那么简单。在存储介质I/O上，它利用了高效的NVMe协议；集群互连网络目前采用10GbE或者40GbE（未来换用100GbE没有难度）；在以太网上的RDMA传输还能够实现跨节点直接内存访问，避免用户态-内核态转换所造成的性能损失。
Fluid Cache集群能够从3个节点扩展到8个节点，其中“Cache贡献者服务器”限定为戴尔品牌服务器，而访问高速缓存池的“Cache客户端服务器”则不限品牌。
关于“与Compellent存储完美集成”这一点包括2个方面：和SC8000/9000阵列在Enterprise Manager界面中一体化管理；还有快照整合，也就是在阵列生成Replay回放点之前，服务器端闪存中的写Cache数据将会刷回到后端阵列，以保证数据一致性。
Fluid Cache for SAN与其它服务器闪存缓存方案相比，重要的不同点在于与阵列的无缝整合。它的缓存层对用户访问来说是透明的。
这里总结了Fluid Cache for SAN的三大优势。
1.多个服务器上的PCIe/NVMe SSD可以整合为一个闪存池。
2.不只加速读，而且还有写缓存，也就是说写策略为write-back而不是write-through。为了保证高可用，避免单点故障，写缓存中的数据会在服务器节点间镜像存储。
3.SSD高速闪存模块为2.5英寸，从机箱前端热插拔维护，戴尔是业界第一家将SFF-8639的规格引入到服务器上的。
让我们来看一下Fluid Cache for SAN的扩展性，当OLTP测试环境从3节点架构增加到8节点，并发用户数提高至7.4倍，每秒交易数增加到6.4倍，同时平均响应时间下降87%达到6ms。为什么延时也会下降呢？我觉得可能是该用例在3节点的缓存池空间只能容纳下一部分热数据，由此产生的后端阵列访问限制了性能。
混合分层
让不同闪存最大发挥价值
接下来我们再看看戴尔新发布的旗舰级SC9000阵列、经济型全闪存阵列，以及独特的混合全闪存配置。
关于存储系统的硬件形态，一直有“控制器”和“服务器”这两种路线之争，在以往，前者在以往“控制器”多代指RISC专用架构，而EMC、NetApp等则是后者——开放架构居多。早在10年前，一位在存储圈已经很资深的朋友曾经对我说，国内有些“迷信”控制器架构，而服务器架构在国外更受欢迎。
后来，随着IA架构CPU的性能不断加强，以及在低功耗/嵌入式领域的发力，“控制器”和“服务器”的界限已经模糊。比如上图中的SBB结构，里面放x86还是RISC CPU，从外面已经看不出来。这种小尺寸、盘/控一体机箱的限制是，CPU的功耗不能太高（不能超过50W）、内存容量和接口扩展能力也都有限。
相比之下，像戴尔SC8000/9000的这类高端控制器，可以采用双路多核高主频Intel Xeon处理器（存储的应用特点决定了频率比核心数更重要），支持较大的内存和较多的I/O扩展卡。在今天，“存储即软件”更大程度上决定了不同品牌阵列之间的差异性，而出现在某些采购招标参数中的“控制器架构”、“非x86 CPU”等，并非是为用户考虑，而只不过是一种商业手段罢了。
从另一个方面来看，同样在2个控制器下，SC8000/9000支持多达960个驱动器，SCv2000和SC4020不超过192个。相应地，它们基于各自定位，在性能、软件功能上也有所不同，比如只有SC4020及以上型号支持跨不同类型驱动器的自动分层存储。
总的来说，这种闪存优化的自动分层，能够让来自主机的写操作永远写入高耐久度/性能的SLC或者eMLC闪存，廉价的MLC或者TLC分层则充分发挥其读性能以及容量（性价比）优势。在不显著提高成本的情况下，兼顾了用户对“有一定比例写操作”的需求。
服务器端
缓存、全闪存阵列怎么选？
现在到了方案设计讨论部分。
首先，Fluid Cache for SAN有点像将阵列中最上层闪存移动到服务器，至少实现的功能类似，当然性能肯定是Fluid Cache更好。
那么，如果使用了Fluid Cache for SAN，后端还需要用闪存，或者分层存储吗？
这里面的关键点在于，有没有相对固定的热数据集，因为主要是未命中的读I/O会直接访问后端阵列。我个人的思路是：
1、如果是新购系统，SSD/磁盘的分层不建议与Fluid Cache混用；
2、如果绝大多数读I/O都能够在服务器闪存命中的话，后端用全磁盘即可；
3、如果读的范围较为分散且随机，此时后端可以考虑用TLC一类的廉价全闪存方案，Fluid Cache层主要保证写入速度。
以上的简要分析，希望对大家有参考意义。
流动数据架构4.0
Live Volume不只是复制保护
最后我再简单谈谈戴尔的流动数据架构4.0。上图中“T1存储内部”和“Fluid Cache for SAN”无需再交待；“T0服务器内部”缓存方案用于加速本地硬盘，无法在服务器故障时提供高可用性；最后是阵列之间流动的Live Volume，作为一个可以实现高可用和容灾的技术，大家是否关心它有哪些超越传统同步/异步复制的地方？
关于Live Volume，我们在《深入DellWorld2015：SC9000存储软硬件更新解密》一文中，介绍了最新SCOS 6.7版本支持的自动切换与VMware vMSC（vSphere Metro Storage Cluster）认证。上图引用自戴尔存储顾问李英文的一次演讲资料，主要介绍Live Volume的另一个关键点。
如果是站点级故障，应用服务器和数据存储一起切换是一种情形。另一种情况，是正在运行的本地/远程数据中心之间迁移工作负载。比如对于虚拟机迁移，希望底层看到的是同一个共享存储，也就是所谓的“双活”。按照传统阵列复制的方式，控制器和盘同时切换至远程数据中心，会有一个时间上的中断（少则数秒）；而戴尔Live Volume还支持另一种方式——先切换控制器，临时透过远程控制器访问本地阵列中的数据，再依靠Replay和同步技术将两端数据追平。
