性能与ILM的平衡:服务器闪存缓存的思考

2015-01-22 |  作者:黄亮 |  来源:cnw.com.cn

摘要本文想给大家介绍下服务器闪存缓存是如何在提供高性能、低延时的同时,实现共享、高可用以及和后端阵列整合的。

【CNW独家约稿】如果说闪存颠覆了企业存储市场,并不为过。如今PCIe SSD和全闪存阵列的关注热度都相当高,它们属于闪存位于企业存储应用中的2种形态。还有什么别的形态呢?服务器上的SAS/SATA SSD——与PCIe闪存的位置类似,只是单个组件的性能差些;混合阵列可以算一种,无论闪存在磁盘阵列中做自动分层还是缓存,都相当于是控制器上运行的一个软件调度;如果把这个调度功能移到前端服务器上运行,就是Server Flash Cache。

服务器上的PCIe SSD,由于数据路径不需要经过存储网络,通常可以发挥出闪存最好的性能。位于内存插槽上DIMM型Flash,理论上数据延时更短,但由于目前这方面的需求还没有那么迫切,以及各方面的限制,短期内还不会对PCIe SSD的地位有大的挑战。我在《破解PCIe SSD进化:从踩坑到解决方案》一文中曾经提到,无论那种服务器本地闪存,如果只是最简单的使用,都存在单点故障的问题,而且无法共享给其它服务器。

那么全闪存阵列有没有不足呢?首先,它的性能受到存储网络的影响,包括主流的10Gb iSCSI、8Gb/16Gb FC,都会增加延时并可能形成瓶颈,举例来说单个8Gb FC端口/控制芯片的IOPS上限一般在20-25万。至于40Gb或以上的InfiniBand和RoCE,在存储网络中用于主机连接还不太普及。更重要的一点是,SSD组件经过闪存阵列控制器后提供给主机时,由于RAID保护等方面性能损耗普遍较大,而其目的——可靠性和可用性又是外置共享存储所必须保证的。

那么服务器闪存缓存,可以说是一种折中的方式,本文就想给大家介绍下它是如何在提供高性能、低延时的同时,实现共享、高可用以及和后端阵列整合的。

Server Flash Cache进化、市场格局简述

在这个市场中,有EMC XtremSF/XtremSW(前者是PCIe SSD硬件,后者是缓存软件)、SanDisk (原Fusion-io )ioControl、PernixData、Proximal、QLogic FabricCache、希捷NytroXD(收购自LSI)、HGST ServerCache(收购自Virident的FlashMAX Connect/Fabric)、赛门铁克Storage Foundation 6.1中的SmartIO,还有戴尔的Fluid Cache For SAN和SanDisk Cache For DAS等。

对于另外2家传统服务器大厂,IBM有EasyTier延伸到服务器的版本,但感觉没多大动静;惠普的新闻稿中曾经出现过SmartCache,甚至硬件上都表示要与Fusion-io的SCSI Express(SCSI over PCIe)标准合作,但后来不了了之。

至于VMware VSAN,在分布式存储的基础上也包含SSD缓存技术。VMware官方建议用于VDI、测试和容灾目标端,并不是替代运行关键业务的传统一级存储。VMware也没有给出VSAN的可用性SLA是几个9(之前VSA官方说法是99.9%),个人感觉VSAN大约在99.99%的水平。

在上面这些里挑几个有特点的简单说说:

EMC的第一代服务器闪存缓存是VFCache,最初只是单机读缓存。到XtremSW 2.0版本加入了分布式缓存一致性和RAC支持。这里要强调一下,早期的Server Flash Cache软件通常不支持像Oracle RAC这样的双活集群访问,简单说就是当一台服务器向后端共享存储中写入数据时会锁定整个LUN。而Oracle RAC需要的是传统SCSI-3那样的细粒度锁机制,一个LUN上的不同LBA允许同时接受来自多个服务器的写操作。

分布式缓存一致性解决的就是协同,或者说数据一致性。如果由一台服务器改写了后端LUN内的数据,在另一台服务器上Flash Cache内也有对应的数据块,需要做过期处理,也就是说要维护一个同步的缓存元数据索引。

我们看到,XtremSW仍然只支持读缓存而没有写缓存加速。如今EMC推广的重点是XtremIO全闪存阵列和ScaleIO Server SAN(支持全闪存但不支持缓存/分层),提到XtremSW的时候已经不多。至于神秘的后备项目DSSD,则要等它揭开面纱的时候。

SanDisk的ioControl结构相对也不复杂,前端服务器上跑PCIe闪存读缓存软件,写缓存加速统一到后端混合阵列(Fusion-io收购的NexGen)上的闪存卡来解决。但如今该方案面临一些问题——SanDisk正着手将NexGen分离出去作为独立业务进行运营。

还有一家比较有特点的QLogic FabricCache,它最大的优势是与连接阵列的FC HBA卡融合在一起,无需安装专门的客户端程序(或者说filter driver),对操作系统透明。FabricCache硬件上需要以专用子卡形式的闪存模块连接HBA主卡,应该有PCIe Switch芯片还挺复杂。缺点可能有硬件配置上比较单一化,而且也不符合OEM伙伴的利益——阵列和服务器厂商似乎都没有帮他们推广。

赛门铁克Storage Foundation 6.1新增的SmartIO(参见《IDF14:全闪存VSAN、缓存Hadoop和高可用》一文)——用分布式SSD缓存来加速后端的SAN共享存储,它支持卷(块设备)上的读缓存和文件系统上的写缓存。Veritas卷管理器的一些高级功能历来需要“破坏性”地部署VxFS文件系统。

像VSAN、Nutanix那样的,属于分布式混合存储了,或者说计算存储一体化。这些产品有其擅长的应用场景,但有人说不太建议运行像Oracle高负载OLTP应用那样的关键业务。

在本文中笔者将以自己比较熟悉,也算相对成熟的戴尔Fluid Cache For SAN为例,希望能给大家介绍Server Flash Cache的一些技术特点、性能水平、配置注意事项等。当然我的了解有限,还没有亲自测试过,如有说的不对之处请多指正,不同的技术观点也欢迎大家讨论。

从Fluid Cache For SAN剖析服务器闪存缓存技术

上图中列出的几点:PCIe SSD是否可分享、高可用、读/写缓存,能否在线维护扩充等,应该说是考虑选择服务器闪存缓存的用户普遍关注的一些问题。

这里把统一的闪存Cache池也称作一个“层”。记得我曾听某大厂磁盘存储CTO说:一旦是用于读&写缓存,和分层的区别已经不大。只是数据是否最终要持久化到后端的问题,因为这时闪存中的待写入数据必须保证可靠性和高可用性。

这里RDMA的作用又是什么呢?为了缓存池中的全局访问,还有把每台服务器的的闪存写缓存镜像到其它节点以实现冗余,最好能有一个低延迟的专用高速网络。

如上图,我们看到40GbE和10GbE交换网络的物理延迟(当然不包括TCP/IP)分别只有0.6和0.8微秒,RoCE(RDMA over Coverge Ethernet)的延迟也不到1微秒(这里我理解的应该是主机到交换机)。

这里可能会有一个疑问,众所周知InfiniBand网络一向以高带宽和低延迟见长,戴尔为什么不用IB交换网络呢?

这个图供大家参考,40G RoCE和IB互有胜负,其实RoCE中正是应用了InfiniBand上的成熟技术。

S6000和S4800交换机来自戴尔收购的Force10,而InfiniBand如今基本上被Mellanox独霸,据了解开放的RoCE其实也是M公司主导。戴尔可以用自己的交换机,但网卡也没啥太多成熟的选择(这个我在后面会提到具体型号)。

Fluid Cache for SAN消除了服务器到SAN之间的单点故障,回写式高速缓存使PCIe SSD也能加速写操作,可以在线增减节点或SSD。客户端服务器和交换机可以用其他品牌,接下来说下这里的限制。

根据这个步骤,第一步先配置一个专用的低延迟高速缓存网络;第二步添加SFF-8639/NVMe的Dell Express Flash PCIe SSD;第三步安装Fluid Cache软件;第4步将Compellent的卷映射到高速缓存池。

根据上图中的注释,最少3台高速缓存贡献服务器限定为戴尔(其中2台必须配置SSD,同时也可以是客户端),同一个网络(最多8台服务器)中的客户端可以是其他品牌。

这个3台的起步,和VMware VSAN、Nutanix等相同。对于所有分布式存储(也包括写缓存)而言,都要面临一个脑裂处理的问题。当两台服务器之间的缓存网络中断时,它们之间互为镜像的数据,在有一个节点上要做放弃处理(因为无法继续保持同步了)(+微信networkworldweixin),同时开始把对应到它上面的数据镜像到别的节点(如果有的话)以维持冗余。具体是哪一个节点上的数据“被无效”,哪一个节点先抢到“存活”的权利,如果只有2台服务器是不太容易判断的。

这就是典型的第3点仲裁(vote)或者说见证机制。

上图是Fluid Cache for SAN用于Oracle RAC的架构图。其中蓝色连线是RAC集群Cache Fusion使用的私有网络,绿色连线为Fluid Cache for SAN使用的私有缓存网络(RoCE),深红色的是管理网络(包括仲裁判断,速度要求不高)。最底下的朱红色连线,代表服务器到Compellent之间的SAN存储网络。上面只是一个示意图,并没有标出交换机和网线的冗余连接,实际上每组网络最好都是2个交换机。

这里的“保护点”,我理解就是快照(SnapShot)。

Fluid Cache for SAN的后端只限使用Compellent阵列,我觉得这样做可能有推整体解决方案的商业考虑,但在技术上也有另外一层意义。由于服务器上的PCIe SSD写缓存中存在“脏数据”,如果直接在后端磁盘阵列上创建快照,将无法获得该时间点应用数据的一致性状态。这可能也是EMC和SanDisk/Fusion-io没有在服务器上做写缓存的原因之一。

为了确保阵列快照的有效执行,戴尔的做法是先发送一个刷新请求,这时尚未回写到Compellent的红色数据块会做Flush动作。

性能测试数据 & 参考架构的思考

笔者站在第三方的角度,上面戴尔公布的友商传统高端存储测试数据,并没有具体配置,仅用于一个参考。而这里的结果,只是显示全闪存阵列的表现相对更好,平均响应时间和测试总耗时都有减少,达到了用户期望。

接下来我们看看全闪存阵列(SLC+MLC)运行5000万条记录的表现,平均响应时间38ms,时间1小时6分29秒,TPS每秒交易数为12542.378。

而当换成Fluid Cache for SAN方案时,性能在全闪存阵列基础上又提升了5-6倍。

那么是否测试压力的时间还不够长?进一步增加到1亿条记录,Fluid Cache for SAN的表现并没有下降较多,仍然有着令人满意的结果。

我自己提出一个问题:Server Flash Cache这样的性能表现,有多少IO落到了后端的外部存储上?是不是绝大多数都命中到服务器上的PCIe SSD上了?

上述测试用了5节点x 800GB NVMe,需要考虑写缓存因为冗余容量利用率为50%。Oracle数据库典型的读/写IO比例通常为7:3、8:2或者9:1,闪存对读加速的效果比写更好。OLTP应用的交易量大,但在一定时间内访问的热点数据集通常有限,像历史数据这样的冷数据放在后端大容量磁盘阵列上,倒是比较符合ILM(信息生命周期管理)的目标。混合阵列中的闪存也能达到类似的效果,但性能表现我觉得不如Server Flash Cache。

我们试想一下,将来某一天7200转硬盘的大容量SAN存储,会不会也白菜价呢?

最后,看下Fluid Cache for SAN的参考架构。

最少3台戴尔PowerEdge R620作为缓存贡献服务器,其中2台必须包含至少1个PCIe SSD,也就是说另外1台可以作为见证(仲裁)节点。

Fluid Cache for SAN目前支持Red Hat企业版Linux 6.3和6.4,SLES 11.3和VMware vSphere 5.5。我记得赛门铁克的SmartIO初期只支持Linux。Windows下的难题估计在于缓存软件/客户端驱动,可能还有用户需求和稳定性的原因。

最少1个交换机,当然2个有冗余会更好。因为一旦这个专用互连网络中断的话,写缓存就失效了(不受保护,将刷新到后端阵列),此时最多也只能实现独立的本地读缓存了。

最小SSD配置是2台服务器上各1个175GB Express Flash PCIe SSD,这款应该是来自Micron的SLC型号。

3块RoCE网卡,这里列出的是Mellanox的万兆产品。

SC8000后端阵列和SC220 JBOD,单控仅可用于测试环境,生产环境不被支持哦。

Fluid Cache for SAN最大8个服务器节点,每个节点都可以作为缓存贡献服务器。

交换机这里换成了2个40GbE,还是RoCE,之前听说InfiniBand也能支持。

32个400GB NVMe SSD,每服务器4个。前面的测试配置中我看到了800GB的型号,猜测可能没有认证完毕?或者缓存池的最大可管理的物理容量就是12.8TB?

毕竟维护一个闪存缓存池,通常是需要消耗服务器内存来放元数据的。

我想对本文做个简单的总结:“没有万能的技术,只有适合的场景”。无论是服务器闪存缓存技术与其它方案比较,还是看待不同服务器闪存缓存产品之间的差异。每家的方案在设计上都有所取舍,用户选择适合自己的就ok了。

相关文章