您的位置: 网界网 > 存储 > 正文

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

2015年01月22日 10:46:35 | 作者:黄亮 | 来源:cnw.com.cn

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

标签
戴尔
全闪存阵列
服务器闪存
PCIe SSD

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等相同。对于所有分布式存储(也包括写缓存)而言,都要面临一个脑裂处理的问题。当两台服务器之间的缓存网络中断时,它们之间互为镜像的数据,在有一个节点上要做放弃处理(因为无法继续保持同步了),同时开始把对应到它上面的数据镜像到别的节点(如果有的话)以维持冗余。具体是哪一个节点上的数据“被无效”,哪一个节点先抢到“存活”的权利,如果只有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阵列,我觉得这样做可能有推整体解决方案的商业考虑(+本站微信networkworldweixin),但在技术上也有另外一层意义。由于服务器上的PCIe SSD写缓存中存在“脏数据”,如果直接在后端磁盘阵列上创建快照,将无法获得该时间点应用数据的一致性状态。这可能也是EMC和SanDisk/Fusion-io没有在服务器上做写缓存的原因之一。

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

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

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

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

1 23
[责任编辑:周源 zhou_yuan@cnw.com.cn]

我也说几句