共享式和分布式集群各取所长该文中，小编对一个集群系统做成三层定义，也就是后端存储访问层、沟通协作层、前端数据访问层，如果愣是要给每个层起个
洋名以略显逼格的话，那么就叫做SAL、CL、FAL好了。这上面的三层每一层都有两种架构，SAL层有共享式和分布式，CL层有对称式
和非对称式（或者说集中管理式和分布式管理式），FAL层有串行访问和并行访问式。描述一个集群系统，必须将这三层都定义清楚，比如：HD
FS是一个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甚至100G
E或者IB，以及在软件上采用RDMA方式来降低时延，但是仍然无法弥补性能不一致所带来的影响。【数据容错方面】共享式集群可以完全利用
底层提供共享存储的设备所做的冗余设计，比如外置SAN存储，其本身已经对物理硬盘做了Raid，集群节点识别到的其实已经是虚拟化的资源
，此时无需担心单个物理部件损坏导致的数据不可用。而分布式则不然，由于数据分布存放在的集群内每个节点上，在这种架构下，如果节点整体宕
机，该节点锁存储的数据就无法被访问，因此，需要在节点间做数据冗余，也就是所谓的Rain，将Raid中的D（DIsk）替换为N（No
de），这就不得了了，如果还是采用类似Raid5的思想，那么任何一笔写IO都会引起写惩罚，节点间就需要交互传递数据，以便发起该IO
的节点计算XOR，然后再将算好的数据发送到XOR块所在的节点写入，随机小块写的性能将惨不忍睹，原因还是因为跨网络数据传送。要解决这
个问题，还要想能承载随机小块写入，那么分布式集群就不得不使用镜像的方式来做冗余，比如Raid1的方式，这种方式并不像校验型容错那样
牵一发而动全身，代价则是提升了存储成本，浪费了一半的空间（1个镜像）甚至更多空间（多个镜像）。【应用场景方面】分布式系统天生适合集
群内节点各干各的，比如典型场景VDI、日志分析、压缩、视频编辑等等。因为只有各干各的，节点间才不需要太多通信。这就像多线程在多CP
U系统里的调度一个道理，这多个线程间如果需要大量的同步，比如锁，共享变量，等等，你运行时候本地CPU读入这些变量，更改，对方运行时
候对方CPU读入这些变量，更改，这些变量会在CPU之间来回传递形成乒乓效应，性能很差。而共享式集群，数据是集中存放的，任何改变其他
节点都可以看得到而且直接访问不跨节点传输。另外，共享式集群在节点HA切换方面具有天然的优势，主要体现在能够保证IO性能的一致均衡
性，以及不需要多副本浪费空间，也不需要数据重构。而分布式集群在某个节点当掉之后，业务虽然可以在其他节点上启动，但是势必会影响数据的
局部性，比如本来VM1的image文件在A节点，image的镜像在C节点，A当掉后，由于C节点资源已经用满，不得不在B节点启动VM
1，此时VM1访问image需要跨节点在C和B之间传送。所以，如果不是各干各的，性能就下降不少，除非换ssd用高速网络。业界某家
公司就是做了这样一件事情：节点当掉后，其他节点上起业务，跨网络流量产生，于是其可以将该节点要访问的数据块动态透明后台迁移到该节点的
存储介质中，也就是数据跟着计算走，迁移完成后跨节点流量消失。而共享式集群则是业务场景通吃型的，没有跨网络流量。另外，可以将少量的
高速PCIE闪存盘作为整个集群的高速缓存，在所有节点之间共享，这样就完全不需要每个节点都增加闪存盘，会极大节约部署成本、运维成本，
同时提升资源利用率。【管理运维性方面】分布式集群有个严重问题就是资源是严格分离的，如果某个节点上的资源有过剩，那么它无法把过剩的资
源切到其他节点；同理，需要更多资源的节点也无法从其他节点动态获取资源，只能向本地节点添加资源。这样直接导致了资源浪费。而对于共享
式集群，这个动作就非常方便了。比如，某个资源可以灵活的从本来从属于某个节点，动态的分配给其他节点，因为每个节点到存储设备都有直接的
通路。这样，在某个节点宕机之后，可以手动或者自动的将资源瞬间分配给其他节点从而继续保障业务运行。同时，即便是没有宕机，共享式架构下
也可以随时将资源灵活的在节点之间动态分配。【成本方面】共享式集群一般需要一个外置的SAN存储系统以及对应的SAN交换机，每台节点也
需要安装对应的HBA从而可以共享访问SAN资源。此外，集群之间的通信流量还需要走前端网络，一般是以太网。所以共享式集群内部会有两个
网络，一个前端一个后端，而这整套部署下来成本是不低的。相对而言，分布式集群的单纯硬件成本则有所降低，每个节点只需要一个网络即可，
一般是以太网，同时承载跨节点存储访问以及前端流量，后端存储访问不需要网络，都是各个节点直接通过后端SAS/SATA控制器访问硬盘。
但是其他方面却增加了成本，比如普遍使用的两副本或者三副本镜像机制，直接将硬盘容量成本翻了对应的倍数。而共享存储型后端可以使用Rai
d5或者ErasureCode等数据冗余方式，成本大幅降低。【分布式和共享式各取所长】综上所述，共享式和分布式各有优劣。那么能否扬长避短，吸取两方面精髓而自成一派呢？比如，针对共享式集群需要利用外置SAN来提供共享存储，是不是可以不用SAN而换用另一种更廉价的方式？而对于分布式集群的资源过于隔离以及其所带来的一系列设计上的妥协，是不是又可以吸取共享式集群里的一些做法来规避？ |
|
