IBM XIV之我见

首先了解存储管理的复杂性

如想找到存储管理问题的解决方案，我们首先需要了解管理传统的存储系统为何如此困难。从本质上说，问题的根源在于传统存储系统需要人工控制系统资源，进而需要开展大量的手动规划和调优工作：

• 映射逻辑卷到物理磁盘驱动器。这是现今管理存储系统所面临的最大问题。系统管理员需要慎重决定如何建立磁盘驱动器RAID组以及如何基于这些驱动器组定义逻辑卷。这是一个乏味冗长的过程，需要占用大量的管理时间，并且会不可避免地带来存储空间闲置问题(进而提高了系统的单位成本)，而且满足这些供给请求的响应速度也令人无法接受。

• 性能调试。对于集中式存储系统而言，尤其是1级(Tier-1)系统，始终如一的提供高性能是必须具备的基本素质之一。传统系统要想实现这个性能目标并不容易。如果想实现全面的投资回报，您必须开展大量的手动工作来确保充分的、均衡的利用系统组件。这实际上意味着您必须持续监控性能的统计数据、分析系统性能、隔离热点、并且在磁盘驱动器之间迁移卷。每当定义新逻辑卷，卷的大小变更，添加新容量，或者应用访问模式发生变化时，都必须确保新的配置能够满足性能要求。这是一项永无休止的工作，注定无法取得全面成功。

• 性能 vs. 空间资源的分配。如果使用传统的存储系统，系统管理员在为应用或应用组分配资源时，是按照磁盘容量模块或磁盘驱动器来分配，以确保为主机应用分配更多容量，实现更高性能。遗憾的是，性能和容量的需求并不是对等的。例如，典型的归档应用虽然需要大的容量，但对系统性能的要求并不高。如果使用传统的存储架构，您根本不可能单独分配性能和容量，无论在任何情况下，这都将是一项极为艰巨甚至无法完成的任务。

• 快照管理。对于任何集中存储环境而言，创建和使用快照都是关键需求。遗憾的是，存储管理员在创建快照时必须加倍小心。传统的存储系统支持差分快照或全拷贝。差分快照会降低性能水平，因此，您在使用时必须密切注意系统性能和需求。而全拷贝的创建过程极为复杂，需要考虑到和应用协调。无论在哪种情况下，创建和使用快照都需要资深的存储管理专家提供支持。

• HSM和ILM。面对飞速增长的存储成本，企业经常部署层级存储管理(HSM)和信息生命周期管理(ILM)。实际上，这些方案只不过是涉及到如何对数据进行分类的一系列解决方案，并且通过不同的存储解决方案为每类数据提供服务，每类方案以相应的成本支持相关的功能。有时会使用多个不同的存储平台面向不同的数据分类(常见的是1级和2级系统)，并且将不同类型的数据分配到不同平台上。

迎接上述挑战的另一个解决方案是部署单一系统，这个系统中包含成本和性能级别各异的多类磁盘。第三种方法是使用虚拟化解决方案，将多个存储系统虚拟化成一个逻辑系统。无论使用哪类解决方案，结果都是相同的：管理员必须监控性能、对卷进行分类、并且在不同的存储层级之间迁移逻辑卷。

在IBM XIV存储系统的架构中集成了多种功能，XIV可以有计划、有规律的分发数据，保证这些数据穿插在系统内部，实现对关键内部资源的使用。XIV存储系统的这种独特的数据分配方法与传统的存储系统数据分配方法有着根本的区别，因此系统本身的物理和逻辑实现原理都具备更高的可用性、更高的性能和管理的好处。

从最小的处理单元“数据模块”说起

为了更好的描述XIV存储系统的基本概念和系统架构，我们根据一个示意图来讲解XIV的体系结构特征。

XIV存储系统的主要部分的被称为modules（模块）。模块提供处理单元、缓存、主机接口和基于标准的和Linux系统。它们通过一个内部的以太网交换机实现冗余连接。所有模块在一起形成一个网格体系结构的工作模式，因此，该系统可以提供本身具有的并行方式，其强大计算能力能够适用于很多的并行分布式计算环境。


IBM XIV 存储系统主要硬件组件：
XIV体系结构概览：

数据模块

在概念层面上，数据模块的功能是系统构建数据块的基本元素，提供物理容量空间、处理电源和缓存，除了先进的系统管理服务之外，还包括系统的内部操作环境。各数据模块间是均等的，他们共享和管理系统的软件，共享服务。

接口模块

从根本上说，接口模块其实和数据模块的结构基本相同，但是承担的功能不同，此外采用的磁盘，缓存和处理资源不一定与数据模块一致，接口模块的设计包括光纤通道和iSCSI接口的主机系统的连接以及远程镜像。在接口模块上，系统服务和软件的功能与管理外部I/O接口是相关联的。

以太网交换机

XIV存储系统包含一个冗余的交换以太网络结构，负责进行数据和元数据之间的通信模块。包括两个接口模块之间的数据交换；接口模块和数据模块之间的数据交换；以及两个数据模块之间的数据交换。重要的是要认识到，数据模块和接口模块不是以同样的方式连接到以太网交换机。

与传统存储架构进行对比

并行的概念贯穿与XIV存储系统各个方面，这种架构提供了一个平衡的手段，采用分布式的冗余数据和分布的计算资源池（或网格）。为了更深层次的解释这种并行的原理，我们先了解一下传统存储体系架构的特点。

从理论上说，虽然传统的存储架构和XIV的网格架构都能够完成相同任务，但是二者间却有着根本不同的拓扑结构定义。

我们首先搞清楚计算资源的概念，计算资源是我们界定为一个独立的实体的标准，它包含了所有必要的组成部分，如处理能力、存储、传输和接收数据。

传统存储架构的特点是：一般是具备单一的强大功能、综合的、完整的并有个性化的，稍昂贵的计算资源。但是整体架构不易于采用新的或外部的技术，同时当整个系统扩展到一定程度之后，他们需要仔细的匹配计算的当前系统资源，不能非常容易的实现整个系统的整体扩展。


我们需要注意的是：一些存储群集的拓扑结构，实际上也没有组成一个单一的整体系统，而是各自独立的单片系统。因此它也不同于XIV的网格体系结构，XIV的网格体系能够从整体上为一些特定的工作任务制定一些独立的计算资源。

网格体系架构利用“横向”的分布式方式，通过复杂的算法，把相关，相同（或非常相似）的计算资源捆绑在一起。能够把一个特定的工作任务是进行战略性的分离。通过许多计算资源在这些任务形成一个产品之前对其执行并行的运算操作。系统的整体性能会通过增加更多的模块（如执行类似的工作任务）使总的工作量分布在更多个模块上。

网格存储架构的优势

传统的存储子系统通常利用专有的、定制设计的硬件组件（而不是普遍提供的硬件组件）和互连接口，是专门设计集成在一起的，以实现目标设计的性能和可靠性目标。传统存储系统采用的复杂高性能冗余单片系统体系架构，往往存在一个或多个以下特点：

开放性问题：组件的更换常常导致系统故障或者硬件的升级，这些组件通常是由制造商指定的一些固件，专门用于此系统。所以这个系统不能轻易的利用市场上新的硬件设计或部件。

性能问题：即使在一个N+1方式的群集系统中，如果集群发生失效，那么不仅可能对链路产生重大影响，而且也会影响生产主机和应用程序的性能。

升级和扩展性问题：传统存储系统升级的过程中系统资源的使用有可能影响性能和可用性。升级一般需要非常小心，并且要注意潜在的时间消耗和管理成本，甚至在某些情况下可能需要某种程度的系统中断。

此外，传统存储系统的升级很有可能导致一个不平衡的资源调配，例如，一个磁盘子系统可能升级驱动器的数量，而处理器却不能，从而导致整体系统的性能潜力受到限制。系统整体不能充分利用升级带来的资源优化。

XIV则能很好的规避这些传统存储架构带来的问题：

成比例扩展：在XIV存储系统里，每个模块都是一个离散的计算资源，包含自己的容量单元，和网格拓扑计算结构所需要的一切相关硬件基础。所有的模块都通过一个可扩展的网络进行连接。这种网格体系架构的突出特点就是在你增加或者删减模块的时候，都可以按照比例的增加或者减少缓存、处理能力、磁盘和带宽，以维持资源最优。

线性缓存增长：总系统缓存大小和缓存带宽随着磁盘容量的增加而呈线增加，因为每个模块是一个独立的计算资源，都拥有自己独立的缓存。请注意，缓存带宽的衡量包括两方面，一个是主机到缓存的吞吐量，另一个是缓存到磁盘的吞吐量，要尽量使缓存、处理器、和磁盘之间的带宽维持平衡。

按照比例的接口扩展：接口模块包含iSCSI和光纤通道主机接口，通过这些接口不仅可以访问一个模块中的数据，还可以访问整个系统。在系统中按比例的添加接口模块，其访问内部资源的带宽也将同步增长。

持续交换能力：随着系统的增长其内部交换能力也是按比例增加的，无论系统内部使用多少个模块，都要防止瓶颈的出现。这种能力可以确保内部吞吐量可以按比例的增长。

嵌入式处理能力：由于每个模块都有自己的处理单元、缓存和磁盘组件，所以该系统有能力处理密集型任务，如缓存预读取、高速缓存更新、快照管理和数据分发，不管系统容量如何，始终保持该系统的运算能力。   

 

虽然，XIV有这以上这些优点。但是，我们需要考虑的一个问题。如果我们的存储越来越大，从几十个磁盘驱动器到上百个磁盘驱动器的时候，当我们的驱动器出现故常的时候，在重建数据的时候，当我们几十块磁盘驱动器同时坏多个驱动器和上百块磁盘驱动器同时坏多个驱动器的几率呢？虽然，XIV承诺在30分钟内就可以重建数据，但是这么多的磁盘驱动器，真的不可能发生这样的事情吗?

   现在，我看到了一个真正让我感到很有兴趣的事情。新的IBM XIV。我不知道你有没有从IBM那里听到过这个新的存储平台，但是我已经遇到许多人已经在认真考虑XIV，或已经购买或部署这个系统。XIV吸引人之处有：

1 它确实很便宜。我早就听说为了让客户购买设备，IBM在价格上几乎是能让步就让步。

2 用SATA设备提供相当于光纤通道的性能。我猜这可能是IBM保持低价的手段之一。

3 低价格，但是可以提供第一层存储的性能和可靠性

但是，天底下没有免费的午餐。当然，我也不喜欢做这种分析，但是你确实不能免费获得好处。问题是，XIV是否太过于美好以至于不真实？答案是：是的，它确实是不真实的。

不过，我想，一旦你了解这个"几乎免费"的XIV将给你的事业（至少是你的工作）带来多大的实际代价，你就会开始同意我的观点了。在大部分情况下，如果你购买的存储阵列最终导致关键系统发生多天故障，那你的饭碗就很危险了。这就是XIV给你带来的危险。

读者可能会反问：你在说什么呢？！IBM说XIV是"自我修复"的，而且XIV可以在30分钟内重新构建故障磁盘所丢失的数据。所以你说的情况怎么可能会发生呢？下面是IBM不想让你知道的XIV的阴暗面。由于XIV架构本身的原因，如果你的整个机箱中（不是机架，也不是独立磁盘冗余阵列组，而是包含180个驱动器的整个机箱）有两个驱动器在30分钟内接连发生故障，那么，那么你就会丢失整个阵列的数据。你的所有的第一层应用程序都会停止运作，而你必须从磁带中重新载入它们。这个流程会让你花很多时间，即使不是要花好几个星期，也会花好几天时间。比如说，SAP会一整个星期无法工作，Exchange会瘫痪3天。如果你给公司带来这样的设备，那你在公司的位置将岌岌可危。

IBM会告诉你说这种情况的发生概率非常小，几乎可以忽略不计。他们是对的，但是这个概率绝不是零，因此你还是要冒这个风险。还有一个需要记住的事情。大型数据中心所做的研究表明磁盘阵列在发生故障的时候并不是随机发生的。实际上，它们是往往是整个集群发生故障，因此，在第一个驱动器发生故障之后，第二个驱动器在30分钟内发生故障的可能性要远远高于IBM向你所说的。不过，我们还有RAID（独立磁盘冗余阵列）保护对吗？但是，问题是XIV数据丢失的范围太大了。如果我的4+1 RAID-5组发生故障，我可能会丢失一些LUN（逻辑单元号），而且我可能需要从磁带中重新载入数据。但是，我绝不会丢失整个阵列！所以我的第一层应用程序所受到的影响会比较小，而且恢复的时间也会比较短。而如果我是用XIV，我的所有的第一层应用程序都瘫痪掉，而且必须从磁带中重新载入所有数据。

不过你不要认为我是完全反对XIV的，我只是反对将XIV用于第一层应用程序，甚至将XIV用于第二层应用程序也不好。如果你是在第三层应用程序（比如，数据归档）上使用XIV，那是比较合理的。你的归档流程即使停滞一两个星期，也不会对你的业务产生多大的负面影响。我所能想到的唯一的例外就是VTL（虚拟磁带库）。我绝对不会在VTL后面使用XIV磁盘。如果你的VTL丢失了所有的数据，你能想象是什么情景吗？如果这样，只能寄希望于你还有第二个数据副本了。

最后,我想IBM的回复之一是"如果你有这担心，只要将XIV再复制一次就好了"。他们是对的，但这样做也会使存储的成本增加一倍，不是吗？