早在小A对集群NAS刚入门的时候，看到过这个略显复杂的架构。从硬件单元上来看，最底层是双控RAID阵列和扩展柜；向上SAS直连2个HA存储节点以保证对前端的可访问性；存储节点和接口节点之间通过高速InfiniBand集群网络互连（也可以使用以太网）；接口节点对用户（客户端）提供NFS、CIFS等文件访问协议。

设计复杂有复杂的考虑，不过小A却想：“集群NAS能否做得简单点，把一堆存储服务器用以太网连起来了事？”当时把这个想法告诉身边同事时，得到一句回复：“你这是想搞个山寨集群NAS啊”大家看看，像不像下面这个图？

上图引用自国内分布式存储领域专家刘爱贵博士的培训资料《L101-1 分布式文件系统概述》，右边的硬件架构图就是典型的Shared Nothing。位于每个服务器节点本地的磁盘聚合成存储池，Scale-out扩展时可以增加节点。

按照左边的文字描述，我感觉与之最匹配的应该是Isilon，其操作系统软件OneFS正是RAID

（纠删码）、卷管理和文件系统三者合一。元数据同步存放在所有节点的SSD上，并为之设计了高速InfiniBand后端网络，专门负责集群内部通信。

当初小A大概还不了解开源的GlusterFS，也是类似的Shared Nothing架构。后来了解到Gluster的元数据和数据都打散分布在所有节点上，客户端访问时用Hash计算出数据存放的位置。当然，没有IB专网时纠删码带来的开销就会显得大一些，再加上开源社区的成熟度，之前的应用还是以2-3副本居多。

我的讨论并没有局限于某些具体的产品，因为技术都是互通的，对于同类产品来说原理上有许多相似之处。

今年在美国举行的Dell EMC World大会，被有的国外媒体形容为“就像一个精简的EMC World”，毕竟在存储圈内大家都很关注EMC的动态。

除了在《超融合硬件变数、EMC对Dell SC存储表示欢迎》一文中提到的之外，我还注意到另一条新闻——“XtremIO工程师们开始研发第二代也就是X2产品，并在Dell EMC World大会上宣布，这一代具有文件服务功能，并提供了统一的文件和块访问…”

XtremIO首席技术官Itzik Reich是这样解释的：“XtremIO首先是针对事物型工作负载，其次是针对其他用例。我们将为需要横向扩展的块/文件混合型工作负载引入领先的平台。Isilon是以高性能计算为先的。”

这个回答没有问题，但我觉得可能还不完整，下面我简单介绍下FluidFS的特点就不难看出问题本质。同时，我们还看到也有一条非技术理由。

我在网上查询了相关信息，http://storage

gaga.com/xtreme-future/ 里面有提到一句话，翻译过来就是“XtremIO工程师团队两名核心之一的Shahar Frank，曾经是Exanet的首席架构师”。这样就不难理解，传闻中在Dell与EMC正式合并之前XtremIO与FluidFS的相关工作已经在秘密开展，应该不只是他们在以色列的办公地点邻近而已。

上图同样来自刘爱贵博士的培训资料，这个范围划的有些大。比如单机文件系统ZFS、BtrFS，我理解可以作为一些分布式存储的本地FS来使用；StorNext和BWFS被人们称为SAN文件系统，传统用法都是客户端访问而不提供标准协议；Hadoop大数据套件下的HDFS也符合这一点；S3、TFS（淘宝的开源项目）则属于Key-Value对象存储，不支持POSIX语义。

对于文件系统，我远没有刘博专业，所以下面还是聚焦到SAN共享文件系统（或称集群文件系统，Clustered FileSystem）这个细分类别，以Exanet为例来讨论。

上图引用自ESG报告《Dell FluidFS v5: Flexible and Secure Scale-out File System》。之所以称为集群文件系统，我有一个简单的思路——FS8600多个NAS网关节点对后端块存储设备是共享访问，在单节点故障时能够支持故障切换，这个比较像服务器HA/负载均衡集群。

至于“SAN共享文件系统”，我们看到每个NAS集群中文件系统网关和后端阵列（SC存储系统）之间采用FC或者IP SAN网络连接，二者都可以Scale-out横向扩展。

扩展方式1（左）：增加一台后端的存储系统（可以是SC4020、SC8000、SC9000、SC2080等）。此时能够提高存储性能和全局命名空间的容量，因为控制器和磁盘数量都增加了。

扩展方式2（中）：增加更多的NAS设备（每机箱内2个节点）。此时可以增强主机连接能力，并提升文件系统性能，因为集群的处理能力提高了，NAS网关上的内存也能够加速元数据和数据访问。

扩展方式3（右）：增加更多的NAS集群。此时将全局命名空间扩展到多个集群上，也能够提高文件系统的性能和容量，技术原理是利用文件夹重定向和符号链的方式。

定制硬件的价值：

PCIe缓存同步、电池保护

对于NAS网关的硬件而言，可以使用标准/非标准的x86服务器，但有一点不容忽视的就是缓存保护。为了实现高可用，需要两个节点间的写缓存数据同步（就像双控那样），以及掉电保护。最简单的办法应该是用以太网互连，以及外置UPS，但效率显然不够高。

下面我们看看FluidFS的读写原理。

再来看看读I/O流程。当一个读请求发送到引擎3时，如果对应文件（块）的FSD在另一套FS8600的引擎1上，可以分为两种情况：1、请求的数据位于引擎1的写缓存中，这时应该可以直接从缓存获取数据；2、直接从Compellent存储池读取，在FSD获取索引后数据流不需要经过引擎1。这也是SAN共享文件系统的好处之一。

如何在单位存储空间中放进更多的数据，是一个永恒的话题。文件存储相对于块存储有个好处就是更加适合策略性的后处理重复数据删除，因为每个文件都不需要额外统计修改和访问时间。由于非结构化数据对缩减过程的时效性要求也没有那么高，采用智能可变长重删技术可以获得更好的重复数据删除比率。如上图，数据切块可以在64KB-192KB之间以4KB为步进灵活调整。

FluidFS使用的重复数据删除技术来自被Dell收购的Ocarina，其另外一个分支产品就是DR系列磁盘备份设备。DR采取的是In-line在线重删，因为二者的用途不同，备份存储优先考虑的是长时间连续写入负载，通常不需要IOPS，也不需要特别优化近期访问的“热数据”性能。

首先，对于传统单/双控NAS来说，如果是32位寻址单一文件系统容量大多只能达到16TB；有些做到64-128TB的产品已经算不错了。而FS8600 with FluidFS v5已经达到4PB，再加上20PB的全局命名空间，这些都是Scale-out NAS或者集群/分布式文件系统的价值所在。

正如上文中的架构图，FS8600既提供横向扩展文件系统也属于NAS+SAN统一存储，其后端的SC阵列可同时提供块存储访问，并在统一的管理界面中呈现给用户。而这也正是XtremIO选择FluidFS而不是Isilon的原因，前面提到过Isilon都是直接管理到分布式存储服务器节点的每一块盘，自然不容易与XtremIO全闪存阵列整合。

上面图表引用了业内公认的SPECsfs文件系统性能测试数据。可以看到随着FS8600设备数、驱动器和Storage Center的扩展，文件OPS（每秒操作数）基本达到线性提升。

注：该测试采用全闪存配置的SC8000，其中SLC、eMLC分层存储的SSD数量比例为1:5。可以看出FS8600和FluidFS能够较好地发挥出闪存的性能。

价格也是一个不容忽视的因素。上面图表应该是几年前的对比了，Dell参与测试的系统在单位ops的成本上处于领先。这个可以在一定程度上做为性价比的参考。

最后引用一下FluidFS的Roadmap发展路线图。

记得当初在使用FluidFS 1.0的EqualLogic FS7500推出前夕，我曾看到林肯大叔在论坛上透露过，该集群NAS架构规划中支持到16个节点。根据以上的进度，我感觉FluidFS会按照这个方向继续发展。