集群资源共享的三种方式

     最近被问到分布式系统的共享方式，结合之前学过的黄铠老师的书稍微说几句。

     各种分布式系统，不管是Hadoop，SMP，MPP还是其他巴拉巴拉的东西，共享资源的方式不外乎以下三种，见下图。该图最早来自黄铠老师的论文（K.Hwang,Z.Xu, Support of clustering and availability），我重新画了下，各部分含义如下：P/C处理器和缓存，M内存，D磁盘，NIC网卡，MIO内存-IO桥。当然图只是一个示意，实际构建系统的时候可能有变化。

     a)不共享结构。大多数集群采用这种结构，节点间通过以太网等局域网方式简单连接。最常见的例子就是Hadoop。这种结构最大的优势就是扩容的成本非常低，只需要简单增加机器并做网络连接即可，集群的可用性也非常高。缺点也非常明显，所谓的不共享不代表不交换数据，而一旦需要交换数据，计算速度必然受影响，因此在同等节点配置下，这种集群必然是最慢的。常用Hadoop的哥们估计早就被shuffle搞得仙仙欲死了，Hadoop M/R最被诟病的一点就是shuffle的巨大开销了（外加shuffle前数据还要被写回HDFS，悲剧）。之后出来的一些Hadoop上的计算框架如Spark和Impala都针对这个问题做了改进，尽量采取本地计算以减少节点间数据的交换，但交换是无法完全避免的，只要还是不共享结构，仍然还有这类的开销，多少而已。

     b)共享磁盘结构。很多商业集群采取这种架构，节点间通过I/O总线连接到一块共享存储上，这个共享磁盘除了数据外还能存储检查点文件或关键系统镜像，以便在节点失效时恢复，从而提高集群的可用性。另外由于磁盘上的数据共享，能保持很好的一致性，并且避免了节点间的数据交换。我们熟悉的Oracle RAC就是基于这种结构，一般是每个节点使用光纤通道连接到SAN存储。这种架构缺点也非常明显。首先，整个系统的瓶颈就是到共享存储的I/O，即使是用光纤（FC SAN），再引入cache fusion这样的全局缓存技术，带宽依然是不够用的。其次就是高I/O带来的难以水平扩展问题，别相信Oracle说的什么线性扩展，纯属无稽之谈，实际应用中我没见过24节点以上的RAC，存储不够了扩SAN，计算不够了升级CPU，总之往死里砸钱。再次就是可靠性问题，虽然SAN有array，能做RAID5，但是敢像hadoop那样用民用硬盘不？一次多坏几块就该去找数据恢复了，再砸钱吧。（手机阅读的哥们你们还好么？）

     c)共享内存结构。这种集群实现起来十分困难。在上图中，节点由可扩展一致性接口（Scalable Coherence Interface, SCI, 具体见IEEE1596-1992标准）环连接，SCI通过网卡连接每个节点的内存总线。实际上SCI是非统一内存访问架构 （Non Uniform Memory Access Architecture, NUMA ）的一种实现，在NUMA中，每个节点的处理器都可以访问全部的系统物理存储器，但访问时间是不一致的（这就是为何称为“非统一”），因为访问本节点的内存肯定比访问远程节点快得多。这种结构的优点，一是数据访问速度非常快，且充分利用了CPU的cache；二是其大大增加了单一操作系统管理的CPU和内存量，这对应用编程是有利的，与单机编程将非常相似。这种结构的缺点是，首先需要细致的资源配置，有些操作系统默认的内存分配策略是进程仅使用本节点内存，可能在整个集群还有大量内存时，单个节点已经需要swap了，这就是所谓的NUMA陷阱；其次是这种结构下维持高速缓存一致性的开销较大，如果牺牲高速缓存一致性，编程模型又会变得复杂。这种架构的一个例子是IBM NUMA-Q集群，俺没有用过就不乱写了。另外近几年出现的一些CPU架构也是基于NUMA，比如Intel的Ivy bridge，Haswell等（多核CPU也很像一个小集群嘛）。