数据加速攻略:选择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高速、可靠、阵列整合的服务器端闪存


数据加速攻略:选择Server Flash还是全闪存阵列?

引用自张委在2015中国数据加速峰会上的演讲资料,以下同

如上图,在外部存储阵列中使用闪存,其性能会受制于存储网络瓶颈,此外还有RAID保护、阵列本地管理等方面的抵消。因此,最终的服务器实际访问性能与SSD理论计算性能的差距很大。


数据加速攻略:选择Server Flash还是全闪存阵列?

如何更好地发挥闪存性能?Fluid Cache for SAN不只是把SSD/PCIe闪存卡放到服务器中那么简单。在存储介质I/O上,它利用了高效的NVMe协议;集群互连网络目前采用10GbE或者40GbE(未来换用100GbE没有难度);在以太网上的RDMA传输还能够实现跨节点直接内存访问,避免用户态-内核态转换所造成的性能损失。


数据加速攻略:选择Server Flash还是全闪存阵列?

正如上面的架构图,Fluid Cache集群能够从3个节点扩展到8个节点,其中“Cache贡献者服务器”限定为戴尔品牌服务器,而访问高速缓存池的“Cache客户端服务器”则不限品牌。

关于“与Compellent存储完美集成”这一点包括2个方面:和SC8000/9000阵列在Enterprise Manager界面中一体化管理;还有快照整合,也就是在阵列生成Replay回放点之前,服务器端闪存中的写Cache数据将会刷回到后端阵列,以保证数据一致性。

Fluid Cache for SAN与其它服务器闪存缓存方案相比,重要的不同点在于与阵列的无缝整合。它的缓存层对用户访问来说是透明的。


数据加速攻略:选择Server Flash还是全闪存阵列?

这里总结了Fluid Cache for SAN的三大优势。1.多个服务器上的PCIe/NVMe SSD可以整合为一个闪存池。2.不只加速读,而且还有写缓存,也就是说写策略为write-back而不是write-through。为了保证高可用,避免单点故障,写缓存中的数据会在服务器节点间镜像存储。3.SSD高速闪存模块为2.5英寸,从机箱前端热插拔维护,戴尔是业界第一家将SFF-8639的规格引入到服务器上的。


数据加速攻略:选择Server Flash还是全闪存阵列?

让我们来看一下Fluid Cache for SAN的扩展性,当OLTP测试环境从3节点架构增加到8节点,并发用户数提高至7.4倍,每秒交易数增加到6.4倍,同时平均响应时间下降87%达到6ms。为什么延时也会下降呢?我觉得可能是该用例在3节点的缓存池空间只能容纳下一部分热数据,由此产生的后端阵列访问限制了性能。

混合分层

让不同闪存最大发挥价值接下来我们再看看戴尔新发布的旗舰级SC9000阵列、经济型全闪存阵列,以及独特的混合全闪存配置。


数据加速攻略:选择Server Flash还是全闪存阵列?

关于存储系统的硬件形态,一直有“控制器”和“服务器”这两种路线之争,在以往,前者在以往“控制器”多代指RISC专用架构,而EMC、NetApp等则是后者——开放架构居多。早在10年前,一位在存储圈已经很资深的朋友曾经对我说,国内有些“迷信”控制器架构,而服务器架构在国外更受欢迎。


数据加速攻略:选择Server Flash还是全闪存阵列?

上图引用自《戴尔SCv2000:入门级阵列硬件设计功力》一文,中端的SC4020在硬件外型上也与之相仿。

后来,随着IA架构CPU的性能不断加强,以及在低功耗/嵌入式领域的发力,“控制器”和“服务器”的界限已经模糊。比如上图中的SBB结构,里面放x86还是RISC CPU,从外面已经看不出来。这种小尺寸、盘/控一体机箱的限制是,CPU的功耗不能太高(不能超过50W)、内存容量和接口扩展能力也都有限。

相比之下,像戴尔SC8000/9000的这类高端控制器,可以采用双路多核高主频Intel Xeon处理器(存储的应用特点决定了频率比核心数更重要),支持较大的内存和较多的I/O扩展卡。在今天,“存储即软件”更大程度上决定了不同品牌阵列之间的差异性,而出现在某些采购招标参数中的“控制器架构”、“非x86 CPU”等,并非是为用户考虑,而只不过是一种商业手段罢了。

从另一个方面来看,同样在2个控制器下,SC8000/9000支持多达960个驱动器,SCv2000和SC4020不超过192个。相应地,它们基于各自定位,在性能、软件功能上也有所不同,比如只有SC4020及以上型号支持跨不同类型驱动器的自动分层存储。


数据加速攻略:选择Server Flash还是全闪存阵列?

戴尔除了率先推出“重新定义存储经济性”的TLC 3D NAND企业级SSD的全闪存阵列之外,还将多年来的存储技术精华——读写分离自动分层存储技术引入全闪存配置。其具体技术特点我们在《向Gartner全闪存魔力象限说“不”》一文中有过介绍,在这里就不详细展开了。

总的来说,这种闪存优化的自动分层,能够让来自主机的写操作永远写入高耐久度/性能的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.0Live Volume不只是复制保护


数据加速攻略:选择Server Flash还是全闪存阵列?

最后我再简单谈谈戴尔的流动数据架构4.0。上图中“T1存储内部”和“Fluid Cache for SAN”无需再交待;“T0服务器内部”缓存方案用于加速本地硬盘,无法在服务器故障时提供高可用性;最后是阵列之间流动的Live Volume,作为一个可以实现高可用和容灾的技术,大家是否关心它有哪些超越传统同步/异步复制的地方?


数据加速攻略:选择Server Flash还是全闪存阵列?

关于Live Volume,我们在《深入DellWorld2015:SC9000存储软硬件更新解密》一文中,介绍了最新SCOS 6.7版本支持的自动切换与VMware vMSC(vSphere Metro Storage Cluster)认证。上图引用自戴尔存储顾问李英文的一次演讲资料,主要介绍Live Volume的另一个关键点。

如果是站点级故障,应用服务器和数据存储一起切换是一种情形。另一种情况,是正在运行的本地/远程数据中心之间迁移工作负载。比如对于虚拟机迁移,希望底层看到的是同一个共享存储,也就是所谓的“双活”。按照传统阵列复制的方式,控制器和盘同时切换至远程数据中心,会有一个时间上的中断(少则数秒);而戴尔Live Volume还支持另一种方式——先切换控制器,临时透过远程控制器访问本地阵列中的数据,再依靠Replay和同步技术将两端数据追平。

作者:唐僧
来源:51CTO
上一篇:pip官方源再遭投毒,阿里云安全及时响应


下一篇:《个保法》施行 | 阿里云APP隐私合规工具上线