谁才是真正的Scale-Out?

本段文字摘自即将于4月初出版的《大话存储2》，转载请注明出处与作者

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）；而某些特定场景下，节点间通信量很少，则表现出线性增长的性能（比如小块高随机IO）。这也可以类比为将一个程序并行分解成多个执行颗粒（类比为高随机IO），颗粒间的关联性越少，则节点间通信量就越少，则并行执行的效率越高，一个道理，所以MPP自身为Share-Nothing架构，那么运行在它上面的程序颗粒之间最好也Share-Nothing。

      SMP、NUMA和MPP各有各的好处，也各有各的应用场景。比如SMP适用于扩展性要求不太高而又不想对程序改变太大的场景，而MPP则使用海量数据下的高扩展性需求场景，需要对程序有较大改变才能获得良好性能。同样对于存储也是这样，比如一旦决定用MPP架构的存储，那么就需要面对多流大块连续IO场景下性能不佳以及效率-扩展曲线的线性不佳这2个事实。或者你去修改上层应用，将大块连续IO改为高随机IO，而这显然荒唐。并且为了适应存储去修改应用，这一般是不可能被接受的。而MPP架构却被广泛用于互联网运营商的底层Key-Value分布式数据库，其高随机小块读访问场景下能获得巨量的性能以及线性的效率-扩展曲线。

本段文字摘自即将于4月初出版的《大话存储2》，转载请注明出处与作者