戴尔专线客服
您好，我们的在线客服人工咨询时间为工作日的 8:30-17:30，感谢您的咨询！ 请留下您的联系方式，我们会在下个工作日第一时间与您取得联系，祝您生活愉快，工作顺利~
{{item.lebal}}
{{item.errorText}}
小A是一名存储爱好者，第一次听说集群存储的概念大约是在10年前，当时觉得这个高大上的东东是不是像HPC那样的服务器集群呢？
就在那段时间，有次小A接到一个用户的需求——他们想要4PB容量的存储。心里暗想：“是4TB吧？会不会听错了…”后来，小A想起有位Isilon的朋友（那时还没被EMC收购），电话那边的第一句话至今还清楚地记得：“他们是要NAS吧？”
集群NAS这个词在随后几年里出镜率还是蛮高的，尽管它涉及的范围略宽，似乎又没有特别严格的定义。而近几年大家开始用更“科学”的名词，比如Scale-out、分布式文件系统，以及同样针对非结构化数据的对象存储等。如果还有不够熟悉的同学，希望能通过本文对它们的定义、技术特点和涉及的产品有一个大致的了解。
一个“山寨”集群NAS的设想
早在小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副本居多。
我的讨论并没有局限于某些具体的产品，因为技术都是互通的，对于同类产品来说原理上有许多相似之处。
XtremIO全闪存阵列将有
NAS,文件系统要用…
今年在美国举行的Dell EMC World大会，被有的国外媒体形容为“就像一个精简的EMC World”，毕竟在存储圈内大家都很关注EMC的动态。
除了在《超融合硬件变数、EMC对Dell SC存储表示欢迎》一文中提到的之外，我还注意到另一条新闻——“XtremIO工程师们开始研发第二代也就是X2产品，并在Dell EMC World大会上宣布，这一代具有文件服务功能，并提供了统一的文件和块访问…”
接下来还有这段话：“事实证明，借助戴尔在以色列的FluidFS中心Exanet团队的帮助，以及戴尔收购了EMC，该团队成为XtremIO的内部资源，而不是类似于Project-F的项目。新增的文件服务将提供X-Brick上的一个文件部分…”
据报道，戴尔在2010年以1200万美元收购了Exanet的资产，后者是一家开发横向扩展NAS技术的以色列初创公司。而EMC在与Dell合并之前已拥有多项成熟的文件系统技术，除了Isilon之外，还有Unity、VNX统一存储上的文件系统，那么为什么在XtremIO上要用FluidFS呢？
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为例来讨论。
集群NAS网关的3种扩展方式
上图引用自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，但效率显然不够高。
这时定制硬件的价值就体现出来了。以Dell FS8600 NAS节点为例，在2U机箱中放置了2个可抽换的双CPU节点，一方面节点间有内部PCIe高速连接专门用于缓存镜像，此外还有电池来保护系统内存中的数据。
读写机制和重复数据删除
下面我们看看FluidFS的读写原理。
当一份数据被写入到引擎1的高速缓存时，会同步镜像到与之成对的引擎2，此时即可返回给前端主机。写缓存中数据被整合为1MB的单位再“落盘”至后端Compellent（SC）阵列。Dell SC的自动分层存储功能在这里也可以发挥作用。
再来看看读I/O流程。当一个读请求发送到引擎3时，如果对应文件（块）的FSD在另一套FS8600的引擎1上，可以分为两种情况：1、请求的数据位于引擎1的写缓存中，这时应该可以直接从缓存获取数据；2、直接从Compellent存储池读取，在FSD获取索引后数据流不需要经过引擎1。这也是SAN共享文件系统的好处之一。
如何在单位存储空间中放进更多的数据，是一个永恒的话题。文件存储相对于块存储有个好处就是更加适合策略性的后处理重复数据删除，因为每个文件都不需要额外统计修改和访问时间。由于非结构化数据对缩减过程的时效性要求也没有那么高，采用智能可变长重删技术可以获得更好的重复数据删除比率。如上图，数据切块可以在64KB-192KB之间以4KB为步进灵活调整。
FluidFS使用的重复数据删除技术来自被Dell收购的Ocarina，其另外一个分支产品就是DR系列磁盘备份设备。DR采取的是In-line在线重删，因为二者的用途不同，备份存储优先考虑的是长时间连续写入负载，通常不需要IOPS，也不需要特别优化近期访问的“热数据”性能。
Scale-out NAS的价值与
统一存储
根据资料，我再下面列出Dell FS8600 with FluidFS v5的部分参数供大家参考：
1. 在一个NAS集群中支持扩展到4个FS8600设备（8个NAS控制器）、8套Storage Center系统（双控SC阵列）；
2. 每NAS集群最大4PB可用文件容量；20PB全局命名空间（多套FS8600系统）；
3. 每NAS集群最大卷数量1024，最大NAS卷大小与文件系统相同（4PB）；
4. 并发活动SMB连接：单设备最大30,000；4设备集群最大120,000；
5. 最大文件大小：16TB；每套设备最大文件数无限；单目录最大文件数：100万；
6. 每套设备最大目录数：32 billion（320亿）；4设备集群最大目录数：128 billion （1280亿）。
首先，对于传统单/双控NAS来说，如果是32位寻址单一文件系统容量大多只能达到16TB；有些做到64-128TB的产品已经算不错了。而FS8600 with FluidFS v5已经达到4PB，再加上20PB的全局命名空间，这些都是Scale-out NAS或者集群/分布式文件系统的价值所在。
除了性能和容量之外，NAS网关的扩展还能够提高并发连接支持，以及最大目录数等，这也是传统Active/Standby或者Active/Active双控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发展路线图。
2010
收购Exanet相关资产；
2011
FluidFS 1.0，命名空间500TB，支持4个NAS控制器；
2012
FluidFS 2.0，将上述两个数字翻了一倍，即1PB命名空间和8个NAS控制器；
2013
FluidFS 3.0，命名空间提高到2PB，同时加入重删/压缩和精简配置/克隆功能；
2015
FluidFS 4.0，命名空间4PB，增加SMB3、目录配额、VAAI和vSphere管理插件等支持；
2016
FluidFS 5.0，全局命名空间达到数十PB，增加2-way NDMP、审计和管理API支持。
2017
记得当初在使用FluidFS 1.0的EqualLogic FS7500推出前夕，我曾看到林肯大叔在论坛上透露过，该集群NAS架构规划中支持到16个节点。根据以上的进度，我感觉FluidFS会按照这个方向继续发展。
上图引用自国内分布式存储领域专家刘爱贵博士的培训资料《L101-1 分布式文件系统概述》，右边的硬件架构图就是典型的Shared Nothing。位于每个服务器节点本地的磁盘聚合成存储池，Scale-out扩展时可以增加节点。
按照左边的文字描述，我感觉与之最匹配的应该是Isilon，其操作系统软件OneFS正是RAID
（纠删码）、卷管理和文件系统三者合一。元数据同步存放在所有节点的SSD上，并为之设计了高速InfiniBand后端网络，专门负责集群内部通信。
当初小A大概还不了解开源的GlusterFS，也是类似的Shared Nothing架构。后来了解到Gluster的元数据和数据都打散分布在所有节点上，客户端访问时用Hash计算出数据存放的位置。当然，没有IB专网时纠删码带来的开销就会显得大一些，再加上开源社区的成熟度，之前的应用还是以2-3副本居多。
我的讨论并没有局限于某些具体的产品，因为技术都是互通的，对于同类产品来说原理上有许多相似之处。
XtremIO全闪存阵列将有
NAS,文件系统要用…
今年在美国举行的Dell EMC World大会，被有的国外媒体形容为“就像一个精简的EMC World”，毕竟在存储圈内大家都很关注EMC的动态。
除了在《超融合硬件变数、EMC对Dell SC存储表示欢迎》一文中提到的之外，我还注意到另一条新闻——“XtremIO工程师们开始研发第二代也就是X2产品，并在Dell EMC World大会上宣布，这一代具有文件服务功能，并提供了统一的文件和块访问…”
接下来还有这段话：“事实证明，借助戴尔在以色列的FluidFS中心Exanet团队的帮助，以及戴尔收购了EMC，该团队成为XtremIO的内部资源，而不是类似于Project-F的项目。新增的文件服务将提供X-Brick上的一个文件部分…”
据报道，戴尔在2010年以1200万美元收购了Exanet的资产，后者是一家开发横向扩展NAS技术的以色列初创公司。而EMC在与Dell合并之前已拥有多项成熟的文件系统技术，除了Isilon之外，还有Unity、VNX统一存储上的文件系统，那么为什么在XtremIO上要用FluidFS呢？
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为例来讨论。
集群NAS网关的3种扩展方式
上图引用自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，但效率显然不够高。
这时定制硬件的价值就体现出来了。以Dell FS8600 NAS节点为例，在2U机箱中放置了2个可抽换的双CPU节点，一方面节点间有内部PCIe高速连接专门用于缓存镜像，此外还有电池来保护系统内存中的数据。
读写机制和重复数据删除
下面我们看看FluidFS的读写原理。
当一份数据被写入到引擎1的高速缓存时，会同步镜像到与之成对的引擎2，此时即可返回给前端主机。写缓存中数据被整合为1MB的单位再“落盘”至后端Compellent（SC）阵列。Dell SC的自动分层存储功能在这里也可以发挥作用。
再来看看读I/O流程。当一个读请求发送到引擎3时，如果对应文件（块）的FSD在另一套FS8600的引擎1上，可以分为两种情况：1、请求的数据位于引擎1的写缓存中，这时应该可以直接从缓存获取数据；2、直接从Compellent存储池读取，在FSD获取索引后数据流不需要经过引擎1。这也是SAN共享文件系统的好处之一。
如何在单位存储空间中放进更多的数据，是一个永恒的话题。文件存储相对于块存储有个好处就是更加适合策略性的后处理重复数据删除，因为每个文件都不需要额外统计修改和访问时间。由于非结构化数据对缩减过程的时效性要求也没有那么高，采用智能可变长重删技术可以获得更好的重复数据删除比率。如上图，数据切块可以在64KB-192KB之间以4KB为步进灵活调整。
FluidFS使用的重复数据删除技术来自被Dell收购的Ocarina，其另外一个分支产品就是DR系列磁盘备份设备。DR采取的是In-line在线重删，因为二者的用途不同，备份存储优先考虑的是长时间连续写入负载，通常不需要IOPS，也不需要特别优化近期访问的“热数据”性能。
Scale-out NAS的价值与
统一存储
根据资料，我再下面列出Dell FS8600 with FluidFS v5的部分参数供大家参考：
1. 在一个NAS集群中支持扩展到4个FS8600设备（8个NAS控制器）、8套Storage Center系统（双控SC阵列）；
2. 每NAS集群最大4PB可用文件容量；20PB全局命名空间（多套FS8600系统）；
3. 每NAS集群最大卷数量1024，最大NAS卷大小与文件系统相同（4PB）；
4. 并发活动SMB连接：单设备最大30,000；4设备集群最大120,000；
5. 最大文件大小：16TB；每套设备最大文件数无限；单目录最大文件数：100万；
6. 每套设备最大目录数：32 billion（320亿）；4设备集群最大目录数：128 billion （1280亿）。
首先，对于传统单/双控NAS来说，如果是32位寻址单一文件系统容量大多只能达到16TB；有些做到64-128TB的产品已经算不错了。而FS8600 with FluidFS v5已经达到4PB，再加上20PB的全局命名空间，这些都是Scale-out NAS或者集群/分布式文件系统的价值所在。
除了性能和容量之外，NAS网关的扩展还能够提高并发连接支持，以及最大目录数等，这也是传统Active/Standby或者Active/Active双控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发展路线图。
2010
收购Exanet相关资产；
2011
FluidFS 1.0，命名空间500TB，支持4个NAS控制器；
2012
FluidFS 2.0，将上述两个数字翻了一倍，即1PB命名空间和8个NAS控制器；
2013
FluidFS 3.0，命名空间提高到2PB，同时加入重删/压缩和精简配置/克隆功能；
2015
FluidFS 4.0，命名空间4PB，增加SMB3、目录配额、VAAI和vSphere管理插件等支持；
2016
FluidFS 5.0，全局命名空间达到数十PB，增加2-way NDMP、审计和管理API支持。
2017
记得当初在使用FluidFS 1.0的EqualLogic FS7500推出前夕，我曾看到林肯大叔在论坛上透露过，该集群NAS架构规划中支持到16个节点。根据以上的进度，我感觉FluidFS会按照这个方向继续发展。
热门评论
暂无相关评论
删除回复
回复
删除回复
更多回复
查看全部条评论
{{dataFromApi ? '您是否在找' : '其他企业都在看'}}
取消发送
取消发送
热门评论
删除回复
回复
删除回复
更多回复
暂无相关评论
发表评论...
发送
删除该评论，是否确认操作？
取消
确认
