是多个下级存储单元中的数据联合通过计算（如RAID5的校验）起来才能构成上级存储单元的数据内容（可用性是交集的关系）。两种情况下，存储单元的可用性是不同的。
同时因为不是所有数据都要求相同的可用性，而且维护可用性的代价也是很高的，存储管理系统最好能够按照数据的价值安排。
1.5.5 存储系统的层次结构
随着网络存储系统的规模不断增加，系统内包含大量的软硬部件，每种部件有具有各自的接口、规格和功能，物理部件包括网络物理线缆、以太交换机、主机等等，而软件部件更是多种多样，包括应用软件、文件系统和数据库等。作为一个存储系统设计者需要一张“地图”标明各种软硬件部件应该所处的位置，及其软硬部件之间的关系，从而能够设计出一个完整的存储系统。
存储系统在整个层次结构中包含多个软硬件模块，每个模块通过特定的接口提供存取操作，而存取路径从请求起点到数据源纵向贯穿各个模块。存储系统整体的层次结构如下图所示，总体分为文件操作层和数据块操作层，由于可以使用统一的命名空间管理文件和对象，因此对象存储设备可以通过全局命名空间层管理。
应用程序文件/对象操纵层文件记录层全局命名空间全局文件映射层本地文件映射层全局逻辑卷层逻辑卷/数据块层存储介质逻辑卷映射层SAN设备卷(包括各种形式的网络TCP/IP,FC,Infinband)FC网络层(包括各种形式的网络本地块设备（磁TCP/IP,FC,Infiniband,VI等)盘或者磁盘阵网络数据块存储设备列）本地磁盘卷存储物理介质远程文件层（NAS）对象存储设备（OSD） 图 1.13复杂存储系统的层次结构
事实上每一层都对于上层屏蔽底层的信息，从逻辑上每层都是一个逻辑存储设备，具有独立的存储空间（可以是命名空间，也可以是线性块地址空间）。多个相同抽象层可以通过横向的存储空间合并和操作集集成起来形成一个更大规模的存储系统。这也是存储系统扩展和虚拟化的一般方法。
SNIA提出的网络存储系统的逻辑参考模型，它首先明确软件部件所应该具有的功能，及其在整体系统中的位置；然后说明这些软件部件和硬件部件的关系。在如图 1.14所示的第一个版本，它把存储系统分为三个层次，分别为应用层、文件/记录层和块接口层，这和我们前面对于存储系统的接口描述是一致的；而在物理层面，主机通过网络和设备相连，主机具有较高的数据抽象（文件或者记录），而设备主要提供块设备语义。在第二个版本中，在文件接口层和块接口层引入了存储系统虚拟化模块。并通过SMI-S等管理协议对于整个存
储系统进行统一的管理，进而明确描述了管理的要求，如设备发现机制、审计和备份等。
图 1.14 SNIA提出的网络存储系统的逻辑参考模型
1.5.6 存储虚拟化
事实上，使用存储空间组织和管理的方式，能够很容易把多个存储设备或者子系统统一成为一个逻辑设备或者系统进行管理和存取。而这一个实现方式在逻辑上称为存储虚拟化。存储虚拟化就是在物理存储的基础上建立一个抽象的逻辑存储系统，现在被广泛应用于存储功能栈各层。从存储空间合并的角度看，存储虚拟化就是整合不同存储设备和子系统的存储空间为用户实现一个统一的全局存储空间。存储虚拟化将物理的存储实体与逻辑的存储实体分离开来。它在物理存储设备与访问存储设备的客户端之间加上一个抽象层，抽象层隐藏了存储设备的复杂性，提供给客户端一个简单、通用的存储池。
存储虚拟化实现了数据存储的位置无关性。虚拟化系统把用户对于数据存储逻辑空间的
存取映射到实际的物理存储设备之上。
网络级存储虚拟化是由加入到存储网络中的专用装置（Appliance）实现的，它是装有存储虚拟化管理和应用软件的服务器平台，它能够对存储网络进行管理和配置{Elizabeth, 2003 #220}。称这个对存储网络进行管理的平台为Manager(管理器、存储虚拟化控制器)。Manager的实现方式分为两种：（1）对称（Symmetric）或带内方式下的(In-band)存储虚拟化；（2）非对称（Asymmetric）或带外方式下的（out-of-band）存储虚拟化。
图 1.15对称和非对称方式的存储虚拟化
图 1.15显示了对称和非对称方式下存储虚拟化的结构。这两种实现方式的根本区别在于数据流和命令流的是否经过Manager(管理器、存储虚拟化控制器)转发。在对称结构中，数据流和命令流都要经过Manager(管理器、存储虚拟化控制器)转发。在非对称结构中，命令流经过Manager转发，而数据流在服务器和存储设备之间进行传输。
实际的映射行为依赖于实现方法。在一个SAN存储系统中，逻辑卷虚拟化的工作可以在三个层次做，第一个是在底层磁盘阵列控制器中进行；第二个是在光纤通道交换机这一层使用逻辑LUN映射到多个物理LUN上；第三个可以在服务器的HBA或者卷管理器中实现多个逻辑卷的集成。虚拟化软件或者设备维护虚拟设备的映射信息一致性，这些映射信息构成的映射表是一种元数据。
虚拟化软件或者设备使用元数据去重定向I/O。它把收到的输入请求（地址信息是逻辑存储空间的地址）转换为对于物理存储设备的请求。
1.6 设计方法
设计和优化存储系统是一个非常复杂的任务，存储系统是包含多个软硬部件的计算机系统，正是这些部件协调工作保证数据存取过程的高效和可靠。首先设计者必须努力理解系统整体结构和各个软硬件部件运行的细节，必须综合考虑软硬件部件设计和全局优化两个层面的问题。在这一过程之中，需要使用一系列方法和工具对于存储系统功能和性能进行研究和分析。
在对一个存储系统进行优化和设计的过程中，需要测试手段发现现有系统或者部件的性能瓶颈或者其他的不足之处；在此基础之上提出新的机制或者优化方法改善存储系统整体或者局部性能；之后设计与优化方案需要合理的测试方法加以评估。在这一设计循环中，测试
工具、方法和技术显然占据了重要的地位。
在讨论如何测试和评价存储系统性能之后，接下来将探讨设计和分析存储系统性能的指导原则。
1.6.1 测试方法
测试是对于存储系统的性能和功能进行评价必不可少的环节。测试发现存储系统的性能瓶颈，然后加以解决，这一研究模式一直有效推动存储技术的发展。因此本节主要讨论性能测试方法和工具。
正如前面已经讨论过，存储系统和部件最为重要的性能指标就是吞吐率和请求的响应时间。但这两个指标又极其依赖于用户的请求行为模式。事实上按照请求发生的方式可以把现有的测试工具分为三类：合成I/O测试、基准测试集和基于trace的测试。
文献{Traeger, 2008 #34}从最近9年内106篇论文中调查了415个文件系统和存储测试工具，发现没有一种测试工具能够全面的反映存储系统的实际性能。 1. 合成测试程序：
合成测试程序的I/O产生器依赖于存取模式的定义。一些研究往往能够统计真实负载的发生规律，例如请求的读写比例、大小、频率和分布等信息，在此基础之上建立相应的存取模型。然后在测试时，产生符合存取模型的I/O请求序列，通过合成测试程序产生实际的负载发送给存储系统，并统计执行情况。
这类典型程序包括IOmeter、IOzone、IOGen和Bonnie++等。
IOmeter由Intel于1998年开发用于评价I/O子系统性能的测试工具，基于客户/服务器模式，在2001年IOmeter被移交给开源实验室（Open-Source Development Lab）维护。它使用一个图形界面显示和管理多个Worker（代表一个独立的测试进程）的配置和运行。IOmeter可以定义存取模式，包括请求块大小、随机和顺序请求的分布、读写比例和突发模式等。事实上IOmeter现在也可以用于集群存储系统的测试。
FileBench是Sun Microsystems开发的使用脚本言语进行配置的测试工具。通过脚本，它能够生成模拟应用程序行为的负载，包括模拟NFS邮件服务器，文件服务器，数据库服务和web服务器等。 2. 基准测试集：
使用基准测试集测试计算机系统的性能一直是有效和精确的评价方法。针对存储系统的测试研究也大量使用基准测试集。基准测试集能够模拟应用程序的行为，相对于合成测试能够更好的反映用户的行为特征。
事务处理性能委员会（TPC, Transaction Processing Performance Council）提出了一系列基准测试集用于评价计算机系统进行事物处理的能力，包括若干测试集，TPC-App，TPC-C, TPC-E, TPC-H等。其中TPC-C是一个联机事务处理的测试集被广泛应用于测试存储系统对于基于数据库应用（银行，航空订票业务等）的支持能力，它通过每秒事务数来描述系统的性能。TPC-C定义于1992年，是一个数据密集型基准测试集，其数据仓库包括股票、订单和付款等。数据库包括9种类型的表，具有不同的记录数和大小。它的评价指标是每分钟执行的事务数。
而Postmark则是模拟大量短生成周期、小文件处理的过程，代表了包括电子邮件、新闻组和基于web的商务应用等业务对于服务器的I/O需求。Postmark产生于1997年，是一个单线程合成测试程序。Postmark可以配置文件和子目录的数量，文件大小范围和事务的个数。开始运行时，它首先按照定义的范围和大小生成一个随机文本文件池，然后执行事务操作。每个Postmark事务有两个部分，一个是文件的生成或者删除操作，另一个是文件读或者更新操作，这两个部分的比例是可以配置的。由于Postmark仅仅大致模拟文件系统的
行为，并没有真实运行实际的程序，其CPU占用率效应实际系统的处理需求。
另一个广泛使用的基准测试就是面向编译过程的测试，包括编译内核，Apache等。考虑到编译过程一直是CPU和I/O密集型应用，而且是一种典型的应用类型。因此能够通过运行编译程序，观察和分析存储系统的行为。但这个测试方法依赖于实际的系统配置，包括编译器及其参数的选择。
标准性能评价公司（Standard Performance Evaluation Corporation，SPEC)成立于1988，现在有超过60家公司参与，目标是建立标准和实际的性能测试集。在这些测试集中，SFS（SPEC SFS）测量NFSv2和NFSv3服务器的性能，包括吞吐率和响应时间。它在客户端上运行事先定义的负载脚本产生各种实际的文件和目录操作，然后统计单位时间内完成的操作数量来评价NFS的性能。
存储性能委员会（Storage Performance Council，SPC)为存储系统开发了基准测试集。目标是更多设备提供商使用工业标准的测试，并且以标准的方式发布其结果。这个测试集包括SPC-1和SPC-2。SPC-1执行典型的就有OLTP特征的商业关键应用，它包括三个测试。第一个测试成为主测试，包含三个阶段，第一个阶段在具有持续稳定吞吐率的系统稳定状态运行三个小时，第二个阶段测试10分钟使得系统保持最大吞吐率，第三个阶段执行50分钟，在不同的负载水平下，测试吞吐率和响应时间的关系，以决定在轻负载情况下系统的平均响应时间。第二个测试再次执行具有最大I/O吞吐率的负载，确认这是可重复的。第三个测试通过在存储空间随机位置写随机数据，来测量所有存储空间是否稳定和一直。相对于SPC-1的随机任务，SPC-2关注于具有大数据顺序负载的商业关键应用。
其他的标准测试集还包括NetNews，Netbench等。 3. 基于Trace的测试：
基准测试集虽然很大程度上能够模拟典型应用程序的行为，但是一些大型存储系统往往需要同时运行多应用程序，或者支持成千上万用户对于存储系统的并发访问，而基准测试集很难反映这种混合行为。
针对这种情况，一些研究者在真实系统的文件系统或者块设备层搜集所有的I/O请求信息，并按照一定格式记录在trace文件中，一般包括请求时间、请求类型和请求大小等。在测试时，重播程序按照trace文件中的记录向存储系统发出I/O请求。
从服务器中获取大量复杂的存储活动的trace，是一个非常有挑战性的任务。公开这些trace更加增加了它的难度。事实上trace是不容易获得，因为系统管理员不愿意为了跟踪记录计算机行为，而增加很多额外开销；还有就是，企业出于安全或是私人的原因而不公开他们的服务器的trace信息，所以公开有用的trace比较难以得到。
在过去近20年中，各种各样服务器的I/O的trace被收集和公开：最早1992时从加州伯克利大学在Snake文件服务器中，收集了4个月的磁盘块级trace。而HP实验室一直在其研究部门的服务器上搜集大量的trace。在Internet迅猛发展之后，大量web服务器、搜索服务器或者文件服务器的关于存储的trace被收集起来应用于研究。
从2007年开始，Microsoft公司开始利用ETW等工具跟踪、记录公司研发的系列服务器产品在各种负载下的trace，并在SINA网站中公开发布。用来支持公司内部和外部的硬件开发人员和软件开发人员的研究。例如 Windows服务器可以通过命令行或是WMI(Windows Management Infrastructure )calls选择性的增加一些扩展性的工具收集trace，一般是5-24个小时，主要包括的是文件和磁盘I/O事件，最终的目的是自动获取、核对、分析存取行为，对于trace数据模糊处理。从单个trace中提取出来各种各样的参数，对于确定识别和分析负载的一般I/O行为是至关重要的。
重播trace并不是一个容易的过程。事实上在大多数情况下，在重播前必须修改trace数据，例如遗失操作并没有记录在trace数据中，但需要在重播时猜测执行。并且，由于重