谁才是真正的Scale-Out?

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




本文摘自即将于2011年4月份出版的《大话存储2》的第15章-集群存储系统,著作权所有,转载请注明出处与作者

IBM自从亮相了XIV之后,EMC接着出了V-Max,接着HDS也推出了VSP。这三者都宣称自己是Scale-Out架构,在业界也引发了一些讨论,有人认为只有XIV才是真正的Scale-Out,而V-Max与VSP则不算Scale-Out。对于这个问题,我是这么看的。

大家知道服务器多CPU架构变迁过程,一开始是单CPU,后来发展到双CPU或者多CPU的SMP架构,也就是多CPU共享相同的内存、总线、操作系统等资源,每个CPU访问全局内存任何地址耗费的时间都是相等的。还有一类AMP架构,即不同CPU做的事情是不同的。但是由于共享访问冲突,SMP架构扩展性-效率曲线已经达到瓶颈。为了消进一步提高CPU数量的同时保证效率,NUMA架构出现了,也就是将多个SMP进行松一点的耦合,多个SMP之间通过CrossBar Switch高速交换矩阵互联,每个SMP都有各自自己的内存,一个SMP内部的CPU访问自己的内存时与之前没什么两样,但是要访问其他SMP处的内存,就需要走交换矩阵,导致延迟增加,所以,NUMA通过牺牲了内存访问的时延来达到更高的扩展性,比如可以将数百个CPU组成NUMA架构。SMP和NUMA架构对于软件程序方面的影响不大,同一台主机内都使用单一操作系统。但是由于NUMA访问远端内存时的时延问题,导致NUMA架构下的效率也不能随着CPU数量的增加而线性增长,只是比SMP要好罢了。此时,MPP架构就出现了。MPP可以说已经与CPU已经关系不大了,MPP说白了就是将多台独立的主机使用外部网络来组成一个集群,显然MPP架构下,每个节点都有各自的CPU、内存、IO总线和操作系统,属于最送的耦合,而且运行在MPP集群中的软件程序的架构也需要相应改变,变为大范围并行化,并尽量避免节点之间的消息传递。由于软件程序发生了变化,那么MPP的效率随节点数量的增长就可以呈线性关系了。其实,如果在NUMA架构下,软件也可以避免尽量少读取远端内存的话,那么NUMA效率也会线性增长,但是NUMA架构下的操作系统仍然是同一个,内存仍然是全局均匀的,而程序架构又尽量保持不变,那么就不可避免的时不时访问远端内存了。MPP相当于把内存强制分开,把操 作系统强制分开,把程序架构也强制改变从而保持海量计算下的效率线性增长。

那么再说回到存储系统。与服务器CPU架构演进相同,可以把存储系统的控制器类比为CPU,而后端磁盘柜类比为一条条的内存。一开始的单控,后来的双控互备份(传统双控存储),一直到双控并行处理(目前只有HDS的AMS2000存储系统为双控并行架构),到这个阶段就类似于AMP(双控互备)和SMP(双控并行)架构,后来则有多控并行对称处理架构,Oracle的RAC集群也可以视作一种多点SMP,各种共享底层存储的集群文件系统及基于这种文件系统所构建的存储系统也属于多点对称SMP。同属多点对称SMP架构的还有华为赛门铁克的VIS以及S8100和N8000存储系统。

同样,由SMP到NUMA的过度也出现在了存储系统中,比如EMC的V-Max,相当于多个SMP(一对控制器组成一个Director等价于一个SMP矩阵)利用高速交换矩阵(RapidIO)来共享访问每个SMP上掌管的内存。

由NUMA到MPP的过度一样也出现在存储系统中,IBM的XIV就属于松耦合MPP架构,多个节点之间彻底松耦合,各自都有各自的CPU/内存/总线/磁盘/IO接口,使用外部以太网交换机,使用TCPIP协议互相通信。而HDS的VSP则更像是一个紧耦合的MPP,MPP对软件架构变化很大,所以传统存储厂商很难将之前的架构演变到MPP上来。另外一种属于MPP架构的存储系统就是各种分布式文件系统(注意,并非共享存储的集群文件系统)。

至于谁才是真正的Scale-Out,这个是个无定论的问题了。SMP/NUMA/MPP其实都算Scale-Out,只不过程度和形态都不同罢了。有人说MPP才是真正的Scale-Out,可能是基于MPP流行的原因。但是不能一概而论。MPP架构的存储,例如XIV,由于特定场景下,由于单路IO就可能导致整个MPP集群中的磁盘资源全部牵动(每磁盘同一时刻只能执行一个IO),在多路大块连续IO并发的情况下,反而效率很差(比如多流大块连续地址IO);而某些特定场景下,多路IO之间牵制很少,则表现出线性增长的性能(比如小块高随机IO)。这也可以类比为将一个程序并行分解成多个执行颗粒(类比为高随机IO),颗粒间的关联性越少,则并行执行的效率越高,一个道理,所以MPP自身为Share-Nothing架构,那么运行在它上面的程序颗粒之间最好也Share-Nothing。SMP、NUMA和MPP各有各的好处,也各有各的应用场景。比如SMP适用于扩展性要求不太高而又不想对程序改变太大的场景,而MPP则使用海量数据下的高扩展性需求场景,需要对程序有较大改变才能获得良好性能。同样对于存储也是这样,比如一旦决定用MPP架构的存储,那么就需要面对多流大块连续IO场景下性能不佳以及效率-扩展曲线的线性不佳这2个事实。或者你去修改上层应用,将大块连续IO改为高随机IO,而这显然荒唐。并且为了适应存储去修改应用,这一般是不可能被接受的。而MPP架构却被广泛用于互联网运营商的底层Key-Value分布式数据库,其高随机小块读访问场景下能获得巨量的性能以及线性的效率-扩展曲线。

本文摘自即将于2011年4月份出版的《大话存储2》的第15章-集群存储系统,著作权所有,转载请注明出处与作者

(3个打分, 平均:3.00 / 5)

雁过留声

“谁才是真正的Scale-Out?”有59个回复

  1. 陈怀临 于 2011-03-10 5:44 下午

    确实是大冬瓜头。还好意思反复提醒人家注明作者和出处:-)。

    一点小观点。

    × 你其实可以加一点ccNUMA的讨论,例如RMI的832系统,和clue-less或者clue logic的QPI或者HT互联的机器(群)
    × MPP主要是一种紧耦合(Tighly Coupled)的系统。很难相信除了科学技术还能干个啥。例如MPI,PVM,OpenMP的一些应用。
    ×确实,MPP与ccNUMA有融合的趋势。主要是Interconnect的高速化。

  2. 冬瓜头 于 2011-03-10 7:17 下午

    哈哈。
    发上来希望看到大家评论,学习一下!

  3. Mansfield 于 2011-03-10 10:05 下午

    ccNUMA是属于SMP还是NUMA?

  4. Hui Liu 于 2011-03-10 10:50 下午

    属于NUMA吧,每个core都直接通过内存控制器连接属于自己的内存。不同于X86以前所有的core都通过FSB来访问内存的结构。

  5. westermann 于 2011-03-11 1:02 上午

    求教:对于华赛来说,是不是主要还是x86为主流?那么他们是不是也是主要用intel的方案.我的意思是说对于相对底层的东西(包括性能方面的)都是用intel的turn-key了,自己主要做业务?这么理解对不对?

  6. Lucifer 于 2011-03-11 3:52 上午

    发烧了……思考能力有所降低,讲下一些我的看法吧

    @Mansfield……ccNUMA顾名思义就是NUMA的一种

    @冬瓜头 SMP和NUMA并不是互斥的概念……还有MPP的概念可能网上也没有很好地解释

    一:
    SMP和AMP对应,就和名字一样,指的是系统内的处理器架构是否对称,而不是“每个CPU访问全局内存任何地址耗费的时间都是相等的”,例如,先出现的AMP架构,一个处理器专门运行操作系统,另外的处理器专门运行应用程序,他们的规格可以不同。后来发现运行操作系统的处理器很容易成为瓶颈,就搞出了SMP;我们现在还可以看到,多核机器(可算是SMP)在启动的时候,总是只使用其中一个处理器,叫做BP(引导处理器),其他的叫做AP(辅助处理器),通常在引导操作系统kernel之后才可以使用

    SMP还有一个要素是,对于IO也要求是对称的,例如,前期的Opteron就不是这样,下一代Sandy Bridge-EP也不是这样;总有一个处理器是更靠近北桥/IOH的,如果操作系统不能感应(aware)这个情况,那么它的性能就可能会出问题,这种机器严格来说应该算是AMP……当然,现代对其区分可能没这么严格

    还有一点是,SMP并没有规定其互联总线是crossbar,例如,早期的Xeon是单个FSB上挂N个cpu,后来是每个FSB挂一个CPU,然后在北桥芯片上内部做个crossbar提供多个FSB,再后来……就变成Nehalem的QPI点对点了

    二:
    关于NUMA,是和UMA对应的,UMA——统一内存架构或者一致内存架构——恰好是你SMP里面说的“每个CPU访问全局内存任何地址耗费的时间都是相等的”,NUMA则不同,这个大概都能很直观的了解

    总之:SMP和AMP的基础是后面的P:处理器,NUMA和UMA的基础是中间的M:内存,它们是不同的分类方式

    利:老的使用北桥自带内存控制器的Xeon:SMP、UMA,新的Nehalem-EP/Westmere-EP Xeon:SMP、NUMA,最新的Sandy Bridge-EP Xeon:AMP、NUMA(要说它是SMP大概也可以,只是我们要清楚其中的区别)

    重发……

  7. Lucifer 于 2011-03-11 6:27 上午

    三:
    MPP,Massively Parallel Processor或Massively Parrallel Processing,大规模并行处理(机),它本质上是单台计算机,只是处理器器规模比较大

    例如,超级计算机的三个发展阶段:向量机、MPP、Cluster集群,当然,每一个阶段都可以包含前一个阶段的技术,例如现在的超级计算机主流就是Cluster,当然也用到了MPP和向量。集群本质上是多计算机

    MPP的典型有Intel Paragon和曙光1000、SGI Origin2000(256个CPU),其中,SGI Origin2000按前面的分法还属于SMP、NUMA

  8. 冬瓜头 于 2011-03-11 6:51 上午

    经过Lucifer的解释,更加清晰了。
    请教,cache cosistent NUMA,与非ccNUMA,细节的区别能否阐释一下?非ccNUMA如何处理缓存一致性问题?或者说根本就不一致?

  9. 老韩 于 2011-03-11 6:54 上午

    楼上两位完全可以坐下来聊一聊,胜过各自躲在电脑前码字。

  10. Lucifer 于 2011-03-11 6:58 上午

    ccNUMA与nccNUMA区别就是前者缓存一致性由硬件进行,后者由软件处理,因为比较麻烦……所以商用系统很少,都是ccNUMA为主

  11. Lucifer 于 2011-03-11 7:02 上午

    码字也有码字的好处

  12. processor 于 2011-03-11 8:36 下午

    To 10.Lucifer:
    关于ncc-NUMA,典型的系统是Cray的T3D/T3E,该机是Shared Memory的,即共享统一的物理地址空间,但不支持cache coherence protocol,硬件不支持,软件也不支持。实际上,其处理器仅仅缓存本地结点内存的数据,当访问远端结点内存的数据时,数据直接被访存指令处理,而数据并不进入cache,所以并不存在cache coherence问题。具体可见:ASPLOS‘96 “Synchronization and communication in the T3E multiprocessor”
    http://portal.acm.org/citation.cfm?id=237144
    印象中Tilera早期版本的Tile 64核心处理器也是这么做的。

  13. Lucifer 于 2011-03-12 2:24 上午

    NUMA本身就意味着共享存储。Cray的T3D每个结点都有Cache,本地节点可以Cache远程存储器的内存。只是T3D规定了共享的数据不进入Cache,也就是说Cache中的内容都是独一无二的

    有Cache就有一致性的问题,必然的,这个一致性维护的问题交给了操作系统或者编译软件来完成

    T3D根本的困难就在于准确预测出实际共享的数据块,以降低维护一致性的开销

  14. processor 于 2011-03-12 2:45 上午

    To 13.Lucifer:

    以下摘自ASPLOS‘96 “Synchronization and communication in the T3E multiprocessor”一文:

    “Only local memory is cached in the T3E. The on-chip caches are
    kept coherent with local memory through an external backmap,
    which filters memory references from remote nodes and probes
    the on-chip cache when necessary to invalidate lines or retrieve
    dirty data.“

    由于处理器中的cache仅仅缓存本地结点的数据,所以并不需要类似目录的结构记录哪些结点缓存了本地结点的数据,也即并不需要硬件逻辑维护结点间的cache coherence。对于结点内,处理器的接口逻辑(FSB)可以保证一致性。

    我不理解你说的:
    “这个一致性维护的问题交给了操作系统或者编译软件来完成”
    操作系统或编译器或程序员需要具体作些什么逻辑来维护一致性?flush cache?(由于cache并不缓存远端结点的数据,所以并不需要类似flush cache的动作。)

    还是你要说的是用软件实现cache coherence,类似software DSM(软件虚拟共享存储)?

    欢迎讨论,哈哈。

  15. Lucifer 于 2011-03-12 4:27 上午

    我说的是t3d,你说的是t3e,它们是不同的。就在你引出来的那段话中:The on-chip caches are
    kept coherent with local memory through an external backmap,
    which filters memory references from remote nodes and probes
    the on-chip cache when necessary to invalidate lines or retrieve
    dirty data,这就是一个很简单的硬件一致性维护机构

    在t3d上,本地节点内存被远程节点改变之后,本地节点要读取新的数据就需要先手动flush cache才行。这个通过编译器在编译的时候加入
    在t3e上,硬件的backmap来完成了这个工作。t3e是ccNUMA

    有在t3d上实现的操作系统,通过在不同节点的内存上维护一个directory-based cache来完成模拟ccNUMA的工作,这就是操作系统的实现,性能还和硬件实现各有优劣

  16. Lucifer 于 2011-03-12 4:27 上午

    这些偏门的东西……意义不算太大,没啥事就别讨论了

  17. 冬瓜头 于 2011-03-12 4:46 上午

    敢问,为何T3D节点本地内存被远程修改之后,本地读取对应的新数据需要先flush再读出呢?为何不能直接缓存命中?

  18. processor 于 2011-03-12 5:54 上午

    To 15.Lucifer:

    Cray T3E是经典的nccNUMA,而非ccNUMA。

    你说:
    “有在t3d上实现的操作系统,通过在不同节点的内存上维护一个directory-based cache来完成模拟ccNUMA的工作,这就是操作系统的实现,”
    有没有相关的参考文献?

  19. Lucifer 于 2011-03-12 6:11 上午

    @冬瓜头 其实就是本地不知道被修改了,这个要软件来解决。硬件能解决的,就不叫ncc

    @processor 很明显T3E有硬件机构来维护cache的一致性,还是你自己copy出来的,没啥好谈的了

    “Software Cache Coherence for Large Scale Multiprocessors”

  20. processor 于 2011-03-12 6:24 上午

    To 19.Lucifer:

    Cray T3E是nccNUMA,与SGI Origin、HP Superdome、IBM pSeries等这种ccNUMA机器是不同的。

    你提到的文章是大学的研究人员在提出的针对nccNUMA的一种软件一致性协议方案,而非Cray T3D原本设计,该scheme对Cray T3E也是适用的。

  21. Lucifer 于 2011-03-12 6:46 上午

    很明显的事情……你怎么认为就怎么认为吧

    你说的东西和我有关系么?

  22. 陈怀临 于 2011-03-12 10:34 上午

    我对ccNUMA能否做大型通讯系统也是没有一点底。就这个问题专门请教过xiaodong zhang和YY Zhou。他们作为学术界的大鳄鱼,也基本上很难说yes or no。

    从理论上,当然可以。但这年头,理论与实践相差比较远。

    我感觉XLR 832会是个东东。如果我来做832的系统,就会来试验一把。

    还有,就是在Sandy Bridge这样的系统上,直接上QPI互联。

  23. Lucifer 于 2011-03-12 8:20 下午

    首席,我觉得……在行业普通的几个多核都觉得这么难搞的情况下,比ccNUMA更复杂甚至复杂的ccNUMA就暂时不要想了

    xlr832的耦合比通常的qpi互联还要紧一些,所以现在有人上了……

  24. Mansfield 于 2011-03-13 1:12 上午

    听lucifer一言,真是豁然开朗

  25. Mansfield 于 2011-03-13 1:14 上午

    对于这些基本概念地阐述,网上的资料太少了

  26. Lucifer 于 2011-03-13 3:05 上午

    我觉得……网上的资料不是太少而是太多,良莠不齐,有时候还互相矛盾……所以,人与人会有纷争

    对基本概念阐述,大多数教科书也靠不住,权威的好些,不过我认为,还是掌握基本的原理更为重要些

  27. 冬瓜头 于 2011-03-13 8:22 上午

    在这请教一下Lucifer,vSphere中所使用的vLockstpe技术,把本地的cpu执行在远端系统中做回放,通过1Gb的以太网就能同步,本地点右键,远端也点右键,其底层原理是什么?总不能把本地cpu指令一条一条复制过去执行吧,只有1Gb的带宽,cpu和内存间的带宽可是跟高的数量级啊。

  28. Lucifer 于 2011-03-13 8:53 上午

    vSphere容错的vLockstep吧……它文档中说了,只是每隔一段时间就复制可以决定程序走向的事件:(A few examples of non-deterministic events include user inputs,
    network packets sent to the Primary VMs, and disk I/O.)发送到影子虚机当中……这个间隔是可以设置的,通常是0.5s……这个可用不了多少带宽吧,此外,它们的存储是共享的

  29. Lucifer 于 2011-03-13 8:57 上午

    = =不知道你的大话存储2会不会在第二版修改前面谈到的CPU方面的内容呢

  30. 冬瓜头 于 2011-03-13 9:06 上午

    我才疏学浅,能否烦请lucifer通俗的类比的啰嗦的赐教一下这个所谓程序事件走向,是什么东西。。。

    已经排版接近印刷了,不允许再改了,这个作为第一条勘误,非常感谢。下一版同步刷入。

  31. Lucifer 于 2011-03-13 9:10 上午

    就是那个Secondary VM也是和Primary VM一样在跑程序的,需要input才能执行下去的东西就要从Primary VM打包传送过来,0.5秒一次并不需要多么大的带宽啊,因为没有说是指令级的Lockstep

  32. 冬瓜头 于 2011-03-13 9:15 上午

    如果算一个super π,cpu和内存之间大概需要吞吐多少数据量?此时如果把input数据打包到对方的话还行么? 对方是不是需要os内部专门处理这种协议,cpu在硬件上又做了哪些改动呢,针对这个vlockstep?

  33. Lucifer 于 2011-03-13 9:20 上午

    算super π不需要input数据啊……吞吐量不详,vLockstep是Hypervisor实现的,不需要特别的硬件,也不需要特别的软件

  34. 冬瓜头 于 2011-03-13 9:26 上午

    你是说外部IO数据?难道算super派不是要cpu大量的从内存读取数据然后输出数据到内存?

    hypervisor将指令绕过guest os直接执行,执行完后透明的反映在guest os里?这部正像nccNUMA那样了么,远端直接跨过本地写了本地的内存,而本地却不能同步刷入,必须有backtrack table?

  35. Lucifer 于 2011-03-13 9:34 上午

    super pi的算法都是已知的啊……只需要指定位数就开始算了

    Hypervisor就是一个同步机构,让影子虚拟机认为自己就是主虚拟机

    = =

  36. 冬瓜头 于 2011-03-13 9:37 上午

    但是hypervisor不会管你算的是super排还是在运行桌面麻将啊。算super排的时候毕竟伴随着大量的cpu与内存间的数据吞吐吧,这些数据难道不需要同步到对方?

  37. Lucifer 于 2011-03-13 9:40 上午

    不需要啊……为什么需要……内存之间的数据吞吐算外部IO?就像两台机器用光盘安装操作系统,只需要将用户输入的注册码之类的同步过去就行,其他东西都是一模一样的

  38. 冬瓜头 于 2011-03-13 9:44 上午

    哦,那就是说secondary vm也需要从外存读取数据?也就是底层存储还是需要被sec vm读的,但是不能写?

  39. Lucifer 于 2011-03-13 9:46 上午

    外部数据可以从主虚拟机传过来,也可以自己读共享存储……写自然是不能了

  40. 冬瓜头 于 2011-03-13 9:47 上午

    靠谱么?。。。这方面真得找点系统教材学习一下。。

  41. Lucifer 于 2011-03-13 9:57 上午

    自己看文档么= =里面写了不少,不过更细节的东西,我想网上是没有的

  42. 冬瓜头 于 2011-03-14 6:55 上午

    被你忽悠了。。。看了文档,磁盘读io以及进入的网络流量,均需要通过网络同步到备机。。。这样的话,如果遇到高吞吐量的机器,吃不消了,除非用10Gb网络。

  43. Lucifer 于 2011-03-14 7:55 上午

    冬瓜,28楼写的是什么?28楼写的是什么?我已经无语了,真是浪费我时间

  44. 冬瓜头 于 2011-03-14 8:27 上午

    28楼“用不了多少带宽”,就是被这一句忽悠了,disk io, network io,吞吐量很大的时候当然很占带宽啊

  45. Lucifer 于 2011-03-14 8:48 上午

    你很有主见啊,何必问别人,能network io进主机的东西network io不了虚机?

  46. 冬瓜头 于 2011-03-14 6:03 下午

    呵呵,我估计你是误会了。

  47. Lucifer 于 2011-03-14 7:51 下午

    呵呵,呵呵

  48. 张麻子 于 2011-03-19 8:00 上午

    冬瓜头,我对你没弄懂东西就敢放到教材去出版误导千万技术人员的行径表示非常敬佩。

  49. 冬瓜头 于 2011-03-21 6:37 上午

    谁都有不懂的东西,尽信书不如无书。凡是都要看两面。已经作为第一条勘误了。

  50. 张麻子 于 2011-03-23 5:24 上午

    你的回答更彪悍。幸亏你不是学术界的。

  51. 冬瓜头 于 2011-03-23 6:17 上午

    是的,我很庆幸我不是学术界的。学术界很多人都在装学术。

  52. carry.chen 于 2011-03-28 1:56 上午

    无语!!

  53. Siri 于 2011-10-19 9:21 下午

    同无语
    给首席提个建议:你就不怕这种民科文砸了弯曲的牌子么?

  54. 冬瓜头 于 2011-10-19 10:12 下午

    首席比你有数。小丑角色。

  55. arsane 于 2011-10-19 10:24 下午

    内容本身是否有问题不说,语言组织能力本身就非常的有问题。意思表述不清,过分口语化。

  56. billy 于 2011-10-19 10:32 下午

    冬瓜头,借用近期最流行的一句话:“Stay hungry. Stay foolish. (求知若饥、虛怀若愚)”

  57. 冬瓜头 于 2011-10-19 10:51 下午

    对喷子没有虚怀,我还达不到藏污纳垢的胸怀的级别。

  58. billy 于 2011-10-19 11:18 下午

    1. 哪里来的污…哪里来的垢…哪里来的喷子…定义的标准是什么?

    2. 就事论事的辩论不好么…何必要归类定性…

    3. 打个圆场而已…希望我不要被你定义…

  59. 冬瓜头 于 2011-10-20 7:32 上午

    这就是“大话”风格,习惯成自然。老八股风格不可取。