【IT168 导购】最近戴尔和/或惠普对3PAR提出的收购建议让我更加留意存储行业在存储阵列设计架构上的发展方向。自从存储阵列本身成为一种设备类型以来，我们看到单片架构--有时我们称为企业存储阵列--在不断发展。Hu Yoshida在他最近的博文中谈到了这个话题。对这些形形色色的存储设备，我将阵列分成以下类型：

　　单片--这个架构的主要代表是日立USP、惠普XP和EMC DMX。这些阵列包含一个共享的记忆体架构以及多个冗余组件。

　　多节点--这些设备使用松散耦合的存储"节点"，配置高速互联连接，通过向存储"集群"增加额外节点来提供扩展性。这个类别的主要产品包括EMC VMAX和3PAR InServ。

　　紧密耦合双控制器--这是典型的"模块化"存储架构。主要代表有IBM DS8000、EMC CLARiiON、日立AMS和惠普EVA。

　　松散耦合双控制器--这种架构的技术可以进行设备故障复原，不过由于这个架构并不是紧密耦合的，因此无法像紧密耦合模式的架构那样进行单个LUN(逻辑单元号)的故障复原。这个类别的主要代表有NetApp FAS Filers和Compellent Storage Center等阵列。

　　单控制器--这种阵列是单独的产品，包括像Iomega IX4和Data Robotics Drobo系列这样的SOHO存储设备。

　　上述列表只是我自己的分类，不代表没有别的类型的阵列。我这里还没列出许多厂商的技术。此外，这些列表中没有一个类别是可以单凭自己的属性就可以称为"企业级"的。"企业级"本身也是一个争议很大的话题。

▲

　　单片架构

　　EMC DMX高层架构

　　单片阵列使用共享的高速缓存架构来连接前端存储端口和后端磁盘。这在本文图表所显示的架构中可以显示得很清楚。这张图显示了EMC DMX和日立USP存储阵列的内部连接。每个记忆体单元连接到每个前端导向器和后端磁盘导向器。日立将高速缓存分成两个部分，分别针对阵列中的集群1和集群2;EMC有多达8个高速缓存模块。这种架构有自己的优缺点。首先，将导向器连接到所有高速缓存模块确保了资源不会分散。除非高速缓存完全耗尽，否则总有到另一个高速缓存模块的连接来处理用户请求。同时，用户请求是来自哪个端口也无所谓;高速缓存模块可以处理从任意端口到任意后端磁盘的请求。这种连接方式在故障复原上有自己的优势。例如，如果一个高速缓存模块发生故障，那么只有这个模块上的高速缓存丢失;在完全部署的架构中，整体高速缓存数量会下降(在EMC的架构中会下降八分之一)，但是前端和后端连接仍将保持原状。在这种模式下，我们可以配对存储端口，并从1个或多个端口中提供单个LUN而不影响性能。存储端口和磁盘适配器之间的通道长度将始终是一致的。

　　这种任意-到-任意的模式也有自己的劣势。连接方式过于复杂，因此系统比较昂贵，需要各种开销来管理和控制各种组件之间的互动。此外，这种架构实际的可扩展性也有限。如果架构有8个FE(前端)、BE(后端)和高速缓存模块，那么这个架构会有128个连接(8×8x2)。增加一个高速缓存模块就需要增加16个连接;同样地，增加更多的前端或后端导向器也需要更多的连接。同时，单片阵列采用的是专门的组件和设计，这增加了持续维护和硬件扩展的成本。

　　另外需要注意的一点是，前端和后端导向器有自己的处理器。导向器的传输量可能是不平衡的，一些处理器可能需要处理比其他处理器更多的工作量。我看到在一些设置中，USP V FED端口由于数据块比较小而达到100%的处理器使用率。这意味着在刚开始主机设置的时候需要人工的负载均衡，同时随着传输负荷的增加也需要人工干预。我们需要注意的是，随着我们的环境变得越来越虚拟化和更多的虚拟机被创建，主机端口使用率可能会随着时间推移而大幅波动。

▲

　　日立USP高层架构

　　现在，DMX平台已经被VMAX平台所取代。看起来，日立是唯一还继续走单片架构这条路的厂商。下次，我将讨论多节点阵列是否有可能被现在的单片设备所取代。

　　以上讨论了共享存储模式架构，即我们有时所认为的企业阵列，不过我称之为单片架构。这个名词可以追溯到大型机时代(见Wiki的定义)，因此它用于描述配置单个大型高速缓存的存储阵列。在过去10年中，我们看到存储技术从单个共享高速缓存向分布式高速缓存架构转变。这种分布式架构采用多个存储引擎或节点，每个引擎或节点都有独立的处理能力，但是它们共享一个快速的网络互联。这种技术最知名的部署可能是3PAR(InServ)、IBM(XIV)和EMC(VMAX)。现在让我们仔细看看这些架构。

　　EMC VMAX

　　VMAX架构包含1个到8个VMAX引擎(存储节点)。这些引擎相互连接在一起，被称为虚拟Matrix架构。每个引擎都可以当作存储阵列，拥有自己的前端主机端口连接、后端磁盘导向器、高速缓存(内部镜像化)和处理器。VMAX引擎使用Matrix接口主板封装器(MIBE)连接在一起。MIBE有副本以备冗余。虚拟Matrix可以进行引擎之间的记忆体访问。当主机访问端口和数据不在同一个引擎上的时候需要虚拟Matrix提供连接性。在这篇文章后面有两幅图，一张显示引擎互联的逻辑视图，一张显示后端磁盘机箱如何分配给每个引擎。

　　不过我们还不太清楚虚拟Matrix架构是如何运作的。我不确定VMAX引擎是否可以直接访问其他引擎上的高速缓存，以及引擎的互联是否需要处理器。此外，一个引擎是否可以单纯为了管理逻辑主机和磁盘连接上的吞吐量而访问另一个引擎上的高速缓存?我不是很肯定。

　　3Par InServ

　　3Par由多个存储节点组成。这些存储节点汇集到一个高速连接上。3Par称之为InSpire架构。2到8个节点(按对配置)连接到一个被动背板，每个节点之间的带宽可高达1.6Gb/秒。3Par如图所示展示他们的8节点架构，连接的数量很容易就能看清楚。我还看到2节点、4节点、6节点和8节点部署下的连接是如何增加的。InServ阵列按对写入高速缓存数据，因此每个节点都有一个伴点。如果一个节点发生故障，伴点上的高速缓存可以马上写入另一个节点，从而保护高速缓存数据。

　　InServ和VMAX架构非常相似，但是它们之间有一个隐晦但非常重要的区别。3Par InServ LUN(逻辑单元号)分割成一个个小盘(Chunklet，磁盘的256KB部分)，这些小盘分散在复合体内的所有磁盘上。因此如果一个阵列得到部署和创建，阵列中的所有节点都参与到数据服务。VMAX使用Symmetrix架构，利用Hyper--磁盘的一大块--来创建LUN。例如，4个Hyper创建一个3+1 RAID(独立磁盘冗余阵列)-5 LUN。随着新的引擎加入VMAX阵列，数据不是分布到新的物理磁盘，因此VMAX引擎和物理磁盘上的数据访问是非均匀的。从这个角度来说，InServ有更好的机会来优化节点的使用，不过在VMAX内部，虚拟配置的使用可以帮助将工作负荷更均匀地分布到磁盘上。此外，一个完全设置的VMAX阵列的VMA带宽可以达到128Gb/秒，超过InServ的带宽。

　　在我看来，VMAX是通过专有节点来提高可扩展性，但是如果数据不在本地节点上，那么延迟性会增加。在3Par模式下，数据始终是跨节点访问的。在EMC模式下，只有当LUN的物理磁盘不在本地节点上的时候，节点之间才交换数据。这带来了两个问题。首先，随着节点的增加，节点<->节点之间的连接数会指数性增加。一个8节点的阵列至少有28个节点到节点的连接(还不包括为冗余所设的连接)。16节点阵列内的连接数量有120个(节点数量增加一倍而节点-节点连接数量增加近6倍)，32节点阵列的连接数量将近500个--32节点是VMAX理论上可以扩展到的节点数量。其次是投资回报率递减。随着节点的增多，需要用更多的资源来处理非本地节点上的数据。因此，额外增加的节点所得到的好处有可能不足以弥补因此而增加的成本。

　　IBM XIV

　　IBM XIV阵列采用的是另一种节点设置方式。节点直接连接到底层硬件的数据保护机制。XIV只使用RIAD-1类型的保护，采用的是1MB大小的数据块，也称为分区。数据以伪随机方式均匀分布在节点上，确保对任何LUN来说，数据都是写入在所有节点上。本文底部的XIV图片显示了这个架构。节点(在XIV中称为模块)分成接口模块和数据模块。接口模块有自己的高速缓存、处理器、数据磁盘和主机接口。数据模块没有主机接口，但是仍然有高速缓存、处理器和磁盘。每个模块有12个1TB SATA驱动器。当数据写入阵列的时候，这些1MB分区写入到所有驱动器和模块中，确保任意一个分区的两个镜像对不会都处在同一个模块上。LUN的顺序分区分布在各个模块上。这样做的结果就是所有的模块都参与服务所有的卷，且单个模块的故障不会导致数据丢失。

　　虽然XIV可能在性能上做了不少文章，但是它仍然有一些内在风险(尽管比较小)。因为所有LUN都分布在所有磁盘上，如果两个磁盘发生故障，那么有可能带来比较严重的数据丢失。此外，XIV架构要求每个写入操作必须通过以太网交换机，因为数据首先是写入主模块和次模块上的高速缓存，然后才写入主机。因此，单个模块的总带宽受限于可用的网络容量，接口节点的带宽限制是6Gb/秒，数据节点的带宽限制是4Gb/秒。如果以太网交换机发生故障，那么带宽将进一步受到限制。

　　小结

　　如今市场上的各种多节点存储阵列实施的方式各有不同。每种方式都有自己的优点和缺点。在你为数据选择平台的时候，要充分考虑它们的优缺点。它们中哪一种方式更适合"企业级"数据仍将是热门话题。在我看来，我会希望使用"1层"存储阵列来提供高水平的可用性和性能。

　　下次我会讨论模块化阵列和使用双控制器架构的好处。

▲

　　VMAX Architecture VMAX Disk<->Engine Connectivity XIV Architecture