SurFS:共享式和分布式集群各取所长

http://www.ccidnet.com/2016/0811/10168835.shtml

一个集群系统可以做成三层定义，也就是后端存储访问层、沟通协作层、前端数据访问层，如果愣是要给每个层起个洋名以略显逼格的话，那么就叫做SAL、CL、FAL好了。

这上面的三层每一层都有两种架构，SAL层有共享式和分布式，CL层有对称式和非对称式（或者说集中管理式和分布式管理式），FAL层有串行访问和并行访问式。描述一个集群系统，必须将这三层都定义清楚，比如：HDFS是一个SAL共享式、CL非对称式、FAL并行访问式集群文件系统；GPFS是一个SAL同时支持共享和分布式、CL对称式、FAL串行访问式集群文件系统。

正因为描述一个集群文件系统有3个维度而不仅仅是一个维度，导致了之前业界的定义那可谓是鱼龙混杂，各说各话，混乱不堪。比如下面的场景：

A君：这是个分布式文件系统（冬瓜哥：他想说的是SAL层是分布式的）

B君：扯淡呢你，这分明是个并行文件系统

C君：我同意A君，这就是个分布式管理的分布式文件系统。（冬瓜哥：其实这哥们是想说CL层对称式）。

A君：对对，C君是对的。

B君：哦，原来是这样，好吧。（冬瓜哥：被误导了，并传播给其他人）

冬瓜哥旁白：这仨其实都是在盲人摸象，分明是只看到了某个层面却认为这就是整体了。而A和C更是阴差阳错的达成了 “一致”，其实他俩说的根本就不是一回事。所以，很多概念就是这样被以讹传讹，越发让人摸不着头脑的。所以，冬瓜哥一直认为，概念上的东西，必须总结清楚，真正达成一致。前提是必须描述清晰无矛盾。比如CL层的协作方式如果是对称式的，那么其元数据也的确是在每个节点上共同分布式管理的，而不是使用集中的元数据管理节点，那么按理说将其定义为“分布式文件系统”是没问题的了？非也，因为在SAL层也存在分布式的概念，两个层都有这个概念，那么就必须将其中一个换用另外一个名字并且习惯成自然，避免误导。所以，CL层的分布式元数据管理，将其起个名字叫做对称式协作，这样更好。

在本文中，冬瓜哥想更加详细的给大家对比分析一下SAL层的这两种架构。共享式指的是集群中的每个节点都能访问到相同的底层存储介质，而分布式则是每个节点只能访问连接到自己机器上的存储介质并独占该介质的访问。但是二者都不影响集群内所有节点看到所有的数据，只不过共享式的话每个节点可以直接看到并读写数据，而分布式的话访问自己这里的可以直接访问而访问他人那里的数据需要跨网络传送。

【IO性能方面】很显然，共享式集群在IO性能上拥有着天然的一致性，任何节点访问任何数据都是一跳直达，不需要任何其他节点的转发。这也是为什么大家一开始都自然想到用共享式来搭建集群的原因之一。而分布式在这方面颇有劣势，其性能并不一致而且不可预估，某笔IO到底落在本地还是其他节点的存储上应用端并不能预先判断，完全取决于分布式系统内查表或者Hash之后决定，一旦垮了网络，时延大增，很不利于同步IO场景的应用性能体验。因为此，分布式系统不得不利用高速互联网络比如10G/40G甚至100GE或者IB，以及在软件上采用RDMA方式来降低时延，但是仍然无法弥补性能不一致所带来的影响。

【数据容错方面】共享式集群可以完全利用底层提供共享存储的设备所做的冗余设计，比如外置SAN存储，其本身已经对物理硬盘做了Raid，集群节点识别到的其实已经是虚拟化的资源，此时无需担心单个物理部件损坏导致的数据不可用。而分布式则不然，由于数据分布存放在的集群内每个节点上，在这种架构下，如果节点整体宕机，该节点锁存储的数据就无法被访问，因此，需要在节点间做数据冗余，也就是所谓的Rain，将Raid中的D（DIsk）替换为N（Node），这就不得了了，如果还是采用类似Raid5的思想，那么任何一笔写IO都会引起写惩罚，节点间就需要交互传递数据，以便发起该IO的节点计算XOR，然后再将算好的数据发送到XOR块所在的节点写入，随机小块写的性能将惨不忍睹，原因还是因为跨网络数据传送。要解决这个问题，还要想能承载随机小块写入，那么分布式集群就不得不使用镜像的方式来做冗余，比如Raid1的方式，这种方式并不像校验型容错那样牵一发而动全身，代价则是提升了存储成本，浪费了一半的空间（1个镜像）甚至更多空间（多个镜像）。

【应用场景方面】分布式系统天生适合集群内节点各干各的，比如典型场景VDI、日志分析、压缩、视频编辑等等。因为只有各干各的，节点间才不需要太多通信。这就像多线程在多CPU系统里的调度一个道理，这多个线程间如果需要大量的同步，比如锁，共享变量，等等，你运行时候本地CPU读入这些变量，更改，对方运行时候对方CPU读入这些变量，更改，这些变量会在CPU之间来回传递形成乒乓效应，性能很差。而共享式集群，数据是集中存放的，任何改变其他节点都可以看得到而且直接访问不跨节点传输。

另外，共享式集群在节点HA切换方面具有天然的优势，主要体现在能够保证IO性能的一致均衡性，以及不需要多副本浪费空间，也不需要数据重构。而分布式集群在某个节点当掉之后，业务虽然可以在其他节点上启动，但是势必会影响数据的局部性，比如本来VM1的image文件在A节点，image的镜像在C节点，A当掉后，由于C节点资源已经用满，不得不在B节点启动VM1，此时VM1访问image需要跨节点在C和B之间传送。所以，如果不是各干各的，性能就下降不少，除非换ssd用高速网络。

业界某家公司就是做了这样一件事情：节点当掉后，其他节点上起业务，跨网络流量产生，于是其可以将该节点要访问的数据块动态透明后台迁移到该节点的存储介质中，也就是数据跟着计算走，迁移完成后跨节点流量消失。而共享式集群则是业务场景通吃型的，没有跨网络流量。

另外，可以将少量的高速PCIE闪存盘作为整个集群的高速缓存，在所有节点之间共享，这样就完全不需要每个节点都增加闪存盘，会极大节约部署成本、运维成本，同时提升资源利用率。

【管理运维性方面】分布式集群有个严重问题就是资源是严格分离的，如果某个节点上的资源有过剩，那么它无法把过剩的资源切到其他节点；同理，需要更多资源的节点也无法从其他节点动态获取资源，只能向本地节点添加资源。这样直接导致了资源浪费。

而对于共享式集群，这个动作就非常方便了。比如，某个资源可以灵活的从本来从属于某个节点，动态的分配给其他节点，因为每个节点到存储设备都有直接的通路。这样，在某个节点宕机之后，可以手动或者自动的将资源瞬间分配给其他节点从而继续保障业务运行。同时，即便是没有宕机，共享式架构下也可以随时将资源灵活的在节点之间动态分配。

【成本方面】共享式集群一般需要一个外置的SAN存储系统以及对应的SAN交换机，每台节点也需要安装对应的HBA从而可以共享访问SAN资源。此外，集群之间的通信流量还需要走前端网络，一般是以太网。所以共享式集群内部会有两个网络，一个前端一个后端，而这整套部署下来成本是不低的。

相对而言，分布式集群的单纯硬件成本则有所降低，每个节点只需要一个网络即可，一般是以太网，同时承载跨节点存储访问以及前端流量，后端存储访问不需要网络，都是各个节点直接通过后端SAS/SATA控制器访问硬盘。但是其他方面却增加了成本，比如普遍使用的两副本或者三副本镜像机制，直接将硬盘容量成本翻了对应的倍数。而共享存储型后端可以使用Raid5或者Erasure Code等数据冗余方式，成本大幅降低。

【分布式和共享式各取所长】

综上所述，共享式和分布式各有优劣。那么能否扬长避短，吸取两方面精髓而自成一派呢？比如，针对共享式集群需要利用外置SAN来提供共享存储，是不是可以不用SAN而换用另一种更廉价的方式？而对于分布式集群的资源过于隔离以及其所带来的一系列设计上的妥协，是不是又可以吸取共享式集群里的一些做法来规避？

业界有一个名为SurFS的集群文件系统，其本质上是一个分布式文件系统，但是却通过特殊的设计，将共享式架构的优点引入了进来。比如，其并没有采用固定盘位配置的服务器来容纳固定数量的硬盘，而是通过将存储资源变为全局可灵活分配的存储池的方式，通过SAS Switch+JBOD，可以将任意硬盘分配给任意节点，而且这个过程中不需要重启，不影响业务。

?  这个架构的另外一个优点是，可以抛弃传统分布式集群极度浪费空间的多副本冗余机制，只需要使用传统的Raid或Erasure Code等容错机制即可。因为当某个节点宕机之后，其原先挂载的硬盘并不像传统分布式系统那样变得完全不可访问，而是可以通过对SAS Switch的配置，瞬间将其原先挂载的硬盘全部分配给任意一台其他节点，从而继续提供服务。这在效果上与多副本分布式集群接近，但是却大大节省成本。

与传统固定配置服务器节点的分布式集群相比，这种架构可以极大简化服务器节点的设计复杂度，甚至可以不设计任何硬盘槽位，这样就可以提升节点密度。

SurFS这种独特设计，使得分布式系统能在享受共享式架构带来的各种优点的同时避免了使用外置SAN存储，避免了浪费空间的多副本冗余机制，扬长避短。不失为一种很好的可行方案。对于云计算环境下的存储系统，无疑需要分布式集群所带来的良好的扩展性，但是SurFS独创了一种“共享存储池型分布式集群”架构，冬瓜哥在此为SurFS点个赞！

据悉，后续SurFS会在后端存储层引入更多共享式思想的优势，比如将集群文件系统的元数据放置在一个共享的SSD上，所有节点均可以共享式读写，而抛弃传统分布式系统那样的通过IO节点上的agent与元数据控制器通信来获取元数据并读写数据块，后者需要通过前端的慢速网络，来回多个round trip，会导致很高的时延，而共享式读写则是每个节点通过后端高速SAS网络一跳直达，并且通过锁的形式来保证一致性。