此文发布于2016年3月31日
在写了关于SurFS的上篇《另类分布式存储：ZFS+SAS交换已经有人在搞？》之后，原本规划有下篇内容，其间我还收到了不少同行朋友的反馈信息，感觉有更多的技术点值得进一步讨论和澄清。
再次声明，我撰文的目的不是评价该产品的好坏，只是希望让大家更全面地了解这种架构设计的特点，以及值得借鉴之处。受自身水平限制，如有理解不准确之处还望批评指正。
上篇要点
SurFS硬件：SAS交换后端确实成本低
SurFS软件：目前ZFS，未来分布式全局缓存
国外同类架构、SAS扩展限制
下面我逐步引用一些比较客观的评价，并围绕这些展开自己的评论。
分布式存储 or SAN文件系统？
“这个不是真正的分布式，颠覆SAN__文件系统了？感觉就是换了SAS__交换。”
SurFS宣称提供块、NAS和对象（未开源）三种存储形式，但其目前本质上是基于单机（或者说HA集群）文件系统ZFS。ZFS的块设备实际上就是zpool里的一个文件，而Ceph等底层为对象的数据组织方式有时也被人称作分布式文件系统，因此我觉得SurFS可以与可扩展文件系统做些架构上的对比。
上图引用自刘爱贵博士的培训资料《分布式文件系统概述》
与以GPFS为代表的共享SAN文件系统相比，SurFS在硬件上将SAN网络换成了SAS交换架构，文件系统/存储控制节点看到的不是LUN而是直接的磁盘/SSD。
除了SAN模式之外，GPFS现在也支持Network Shared Disk (NSD) Server和Shared NothingCluster (SNC) Model另外两种部署模式。目前的分布式文件系统最流行的应该数Shared Nothing集群，EMC Isilon属于其中比较有代表性的一款。
“GPFS由多个磁盘或者LUN构成单一文件系统，完全分布式的数据和元数据存储，多个节点共享存储，并行访问。”Isilon是直接管理的磁盘，号称单一卷，并且这些“集群NAS”都能提供单一命名空间。
SurFS在成本上确实比SAN文件系统有优势，但规模显然无法达到FC存储网络的水平。
下面再引用一段业内专家朋友的点评：
“多个机头不能同时访问一块数据，因为ZFS无法同时被两个机器import。Cache和incore meta无法同步。”
“我觉得不好的地方在于大家在乱讲文件系统，混淆视听。其实（泛）文件系统解决三个问题：名字空间、地址空间、incore meta和data cache的一致性。如果这三个问题都不解决，至少在我的概念里，不能叫文件系统吧。所以SurFS叫文件系统不太对，应该是个多节点的HA方案。更不应该扯上Scale-out。”
小结：SurFS的硬件部署上类似SAN文件系统，但ZFS+HA实际上就是一个主备/互备的统一存储。与真正大规模单一集群的共享SAN文件系统应该不是一回事。
另外经过官方确认，SurFS的“全局缓存池是建在全局存储池中，而不是存储控制节点的本机内存，倾向于用带电池的DRAM或SRAM。”
到这里感觉还是ZFS的思路，内存设备的延时低且稳定，但正如我在上篇中所说，其带宽多少受SAS的限制（6Gb/s理论值600MB/s）。与在存储控制节点的分布式缓存相比，将固态盘放在共享的SAS网络中实现难度应该更低。不过首先这缓存盘需要镜像保护，每个存储控制节点上的每一个存储池（zpool）应该都要配至少一对。其次SAS设备的双端口只能同时被2台主机操作，具体到ZFS等应用就是主/备的方式。所谓全局共享，应该只是像硬盘/SSD那样在控制节点故障时能够切换到余下任何一个存储控制节点。
关于文件系统先谈到这里，下面看看跟分布式块存储的对比。除了上篇中提到的VSAN之外，还有EMC ScaleIO以及一些别的。
“该跟XIV比较一下。跟VMA_这些比成本没有说服力。”
这里解释一下，我在之前先是由SurFS联想到全共享SAS后端的富士通DX8700 S2，进而提到Scale-out高端阵列的流行趋势是EMC VMAX那样的架构。从定位和成本而言，IBM XIV相对要低一些。
IBM XIV__架构图
我也听到过有人说XIV不算Scale-out，大概是由于其最大15节点和6个接口节点的限制。我觉得6个接口节点应该不是技术限制，估计当年推出时IBM觉得这样的前端接口数和带宽已经足够。由于XIV只能是单一存储池和双副本，所以上限为180个驱动器。XIV Gen3节点间采用InfiniBand互连，并且每个节点上都有对等数量和容量的硬盘、分布式缓存（利用UPS保护），并支持SSD读二级缓存。
当服务器同时连接XIV的多个接口节点时，可以使用标准MPIO多路径；戴尔EqualLogic PS家族Scale-out iSCSI阵列的最佳实践需要安装一个增强的多路径组件；ScaleIO、Ceph等有自己的客户端。而前面说过了，SurFS使用的ZFS多个机头不能同时访问一个卷。
如今XIV推出软件版本，每节点限定运行在ESXi的一个虚拟机里。节点间自然支持以太网互连，应该也可以配置为超融合。只是用户无法选择部署在KVM+OpenStack环境。
小结：无论如何，XIV还是比SurFS更符合Scale-out分布式存储。不过我觉得XIV有点生不逢时，像ScaleIO这样的产品未来前景可能会更好吧。
多端口怎么做？是什么限制了SAS交换机的发展
“对于后端总线是全交换还是点到点，熟优熟劣不可一概而论。”
上面这位朋友的评论与富士通DX8700 S2相关，我在上篇中曾经做过“点对点、无阻塞”的评价。与之相比SAS交换很大程度上减少了连接数量，降低了成本。但之所以用的人少不是没有原因，下面谈谈其扩展性、性能和成熟度。
根据SurFS官方文档（https://github.com/surcloudor...），其参考配置使用的就是上图中的LSI SAS6160交换机，目前市面公开发售的也就这一款吧。它提供了16个6Gb/s SAS x4lane接口（wide-port，SFF-8088连接器）。
LSI 6160 SAS-2 switch架构图
早在该SAS交换机刚推出时，我就向LSI了解过其核心是2颗36 lane的LSI2X36扩展器芯片，其拓扑方式只能是上面这种情况。
有啥问题呢，能达到全线速不？图中Switch芯片引出的每条线都代表一个6Gb/s SAS x4 lane连接，如果对带宽性能有要求的用户，我更倾向于建议将其当作2个8口交换机来使用，因为一旦要跨芯片中间有个瓶颈啊。
有朋友可能说了，PMC有68 lane的12Gb/s SAS Switch，做个单芯片17口的交换机不好吗？国内已经有人在这样搞了。
这种17口的SAS交换机，我不再担心性能设计。但是听说人家还计划搞40-60口，甚至68口的，每个口带宽还是48Gbps（12Gb SAS x4），只能用多芯片架构了。
_最大45口（x4 lane_）SAS交换机设想图
上面我画了一个草图，应该是最低成本的40口SAS交换机方案了。还是老问题，在每颗SAS Switch芯片自己的交换域内可以达到线速，如果跨域的话…
_最大80口（x4 lane_）SAS交换机设想图
上面我又手绘了一个相对“豪华”的，首先声明下我不是网络方面的专家。这个设想图理论上最大能支持80口SAS交换机方案，8个Switch芯片都有7条内部拓扑连接，任意两颗芯片可以在两跳以内实现7 x4 lane的连接带宽。因此整个交换机在配置超过56口（8x7 x4 lane）之后也会面临一定的性能瓶颈。
显然，按照这种思路来做40-60口的SAS交换机，估计成本不菲。这时我想起了收敛比的概念，还有以太网和FC交换机的高带宽背板了。
小结：写到这里，大家应该能理解SAS交换机为什么难于大范围普及了吧？不过，我也认同它在小规模环境下是一种性价比不错的解决方案。
未完待续…
下篇计划要点
JBOD节点间冗余利弊
SAS交换网络有无单点故障？
开源与OpenStack整合
通用模式（SAN）与聚合模式（超融合）
性能PK：应该怎么看？
推荐阅读
本文转载自企业存储技术微信公众号原文链接点这里注：本文只代表作者个人观点，与任何组织机构无关，如有错误和不足之处欢迎在留言中批评指正。 进一步交流技术可以加我的微信/QQ：490834312。
尊重知识，转载时请保留全文，并包括本行及如下二维码。感谢您的阅读和支持！《企业存储技术》微信公众号：HL_Storage，也欢迎关注企业存储技术极术专栏，定期更新。
