IDC研究表明，全球信息总量将以惊人的速度增长^[1]，现有的存储区域网络等架构已难以满足信息快速扩展的需求，于是具有按需使用和高扩展性特点的云存储应运而生。目前的云存储系统可以提供多种访问接口，在丰富的接口支持下，出现了多种基于云存储系统的互联网应用。作为基础设施即服务(IaaS)的重要部分，云存储的性能对其上的应用性能有重大的影响。云存储系统的应用方面存在的2个关键问题是：①如何确定某个云存储系统的应用场景；②如何准确定位云存储系统的性能瓶颈。

第一个问题发生在云存储应用部署之前，之所以要首先确定其最佳适用场景，主要是因为合适的应用场景才能够充分发挥云存储系统的性能优势，为企业节约成本，增加效益；反之，部署不合适的应用会浪费云存储系统的资源，使得投入的成本无法产生期望的收益，并且还会由于性能发挥不佳而损失用户，从而对企业的发展造成不良影响。由于在现有的云存储系统上应用繁多，通过一项项试验来找出云存储上的最佳应用几乎是不可能的，并且这样会消耗大量成本，导致系统长时间无法上线。因此需要有一种更为简单有效的方法来确定云存储系统的具体适用场景。

第二个问题发生在云存储系统运行过程中，在部署完应用之后，随着负载的变化，云存储系统可能会出现一些性能瓶颈，如何准确定位这些性能瓶颈并进行相应的优化是非常关键的问题。瓶颈定位的准确有效，就能够迅速地对负载的变化作出反应，及时解决系统中存在的问题，拓展系统性能；否则，就难以找出问题发生的真实所在，只能凭经验进行估计，这样就有可能陷入不断修改却无法优化的循环。

要解决上述2个问题，需要对云存储系统进行持续的性能监测，通过性能数据的分析来发现问题。在这一方面，目前国内外针对特定接口的用户性能评价进行了一些研究^{[2, 3, 4]}，而对系统级性能的研究不足。由于云存储系统的复杂性，现有的面向用户的性能评价工具无法得到稳定的结果，不能够反映云存储系统的整体性能，因此需要有面向系统指标的分析方法。这方面研究较少，主要包括：

卡内基梅隆大学提出了一种通过日志分析进行系统性能瓶颈检测并进行性能优化的方法^[5]。伯克利大学和Netapp公司也对实际环境中的Trace进行了分析，通过面向对象和多尺度的统计方法，得出了网络访问负载规律，并将其用于数据管理优化和Cache性能优化^[6]。微软公司设计了Oktopus，通过增加一层抽象的网络层，监测多租户和云环境下的数据中心网络性能^[7]。Amazon的CloudWatch，Hyperic的CloudStatus可对Amzon的EC2和S3进行测量。Google的Dapper^[8]是根据其自身业务特点和需求开发的一个大规模分布式系统监控框架，实现了广泛可部署性和不间断监控2个设计目标，可以对几乎所有的Google后台服务器进行监控，并在新服务部署、定位长尾延时、推断服务间的依存关系等方面，为开发者和系统管理人员提供了重要的技术支持。

此外，也有一些开源项目可以对云存储系统性能进行监测。Chukwa^[9]是建立在开源云计算平台Hadoop基础上的数据收集系统，用于大规模云计算平台的监测和分析。Monalytics^[10]是一个集成云计算平台监测和数据分析2个关键功能的监测系统，能够实现数据中心的性能感知负载均衡、实时异常检测、异常放大分析等功能。CloudBeacon^[11]可以实现云计算平台中网络性能的测量和预测。

但是，现有的方法多针对云存储系统的某一方面或者某一层次进行性能监测，以一种类似于“黑盒”的方式评估系统性能。由于云存储系统是一个较为复杂的系统，其中包含多个软硬件层次，且不同层次上的性能指标有所不同，涉及的度量和采集方法也不同，并且不同层次的性能指标之间存在一定的关系，所以单纯地对系统的某个层次进行性能监测实际上仅能得出一个粗略的评估结果，缺乏对系统的深度剖析，无法解决前面提到的2个关键问题。

基于上述背景，本文提出了一种云存储系统分层性能监测和采集框架，通过对云存储的各个系统层次性能进行持续地监测和采集，并对这些数据进行综合分析，得出了各系统层次的性能关系以及变化规律，确定系统的适用场景以及准确定位系统瓶颈。最后在ceph云存储系统上进行了实验，验证了该方法的可用性。

云存储系统的分层架构如图 1所示。其中：存储层、基础管理层位于服务端，属于云存储的系统层；而应用接口层与应用访问层联系紧密，并且与客户端的环境密切相关，所以在这里将其归于用户层。用户层的性能不能够反映云存储系统的整体性能，还需要关注云存储的系统层的性能，所以下面将集中讨论存储层和基础管理层的性能监测和采集。

图 1 云存储系统的分层架构

图选项

目前有一些方法和工具可以对云存储的单个系统层次进行监测和数据采集，下面分层次讨论这些方法。

存储层提供数据的存储服务，为用户提供一块超大容量的“虚拟磁盘”，其主要性能指标是IO吞吐率以及IOPS。

现有的性能评估方法，一部分侧重于存储层的性能测试而非监控，如文献[12]所示，但难以对存储层的真实负载做持续地性能监测和采集；另一部分则需修改特定的虚拟化平台，如施杨斌等人^[13]通过在Xen的Dom0 IO设备模拟程序中，嵌入IO请求监听模块来实现存储层IO特征数据的获取，但系统侵入性大且不具有通用性。

目前还没有一种通用的、系统侵入性小并且能够监测和采集系统在真实负载下的性能的方法，上述方法都不满足需求。事实上，主流云存储系统的存储层操作系统使用的基本都是linux，通过linux系统的自带工具(例如iostat)可以分别统计各系统管理磁盘设备的IO性能信息，包括IOPS、吞吐率等，然后进行汇总分析，就可以得出云存储系统存储层的性能信息。由于这些工具是系统自带的，可以直接使用，所以系统侵入性小，而且能够实时监测系统的性能，满足存储层的监测需求。

由于云存储的基础管理层主要关注分布式文件系统，所以此处的性能监测与数据采集的指标也主要针对分布式文件系统，主要指标是IOPS和读写吞吐率。由于不同的分布式文件系统的具体实现方式不同，所以基本没有通用的监测方法，目前只有针对某一种或某一类系统的具体监测方法：

1) ceph-dash 是用Python开发的一个ceph监控面板，用来监控ceph的运行状态，可通过 REST API或者Web页面访问性能数据。该工具是开源的，其配置及使用也很简单。其应用范围仅限于ceph，但是由于ceph目前在云存储系统中的应用比较广泛，所以仍然具有很好的实用价值。

2) Ganglia^[14]是UC Berkeley发起的一个开源集群监视项目，主要是用来监控系统性能，如：cpu 、内存、硬盘利用率、 I/O负载、网络流量情况等，通过曲线很容易看到每个节点的工作状态，对合理调整、分配系统资源，提高系统整体性能有重要作用。其收集到的数据通过RRDTool工具进行处理，并生成相应的图形，以Web方式直观地提供给客户端，可以用于监测ceph文件系统以及Hadoop文件系统的性能指标。

3) Hadoop在云存储中应用也非常广泛，其对应的文件系统HDFS(hadoop distributed file system)是当前最流行的云存储系统之一。Apache Ambari 是一个基于web的工具，可用于配置、管理和监控Hadoop集群以及监测HDFS的性能指标。

分布式文件系统是云存储基础管理层中的核心，在实际对云存储进行监测时，需要针对特定的分布式文件系统选择合适的监测方法。

本文根据云存储系统的分层架构，提出了一个分层性能监测和采集框架(如图 2所示)，监测框架整体上是传统的客户端-服务器架构，各组成部分概述如下：

图 2 分层监测与采集框架

图选项

1) 监测代理

监测代理作为框架中的客户端，运行在存储层的各个节点以及分布式文件系统层上。由于存储层节点的操作系统基本是Linux，所以监测代理可以使用Linux的系统工具，例如iostat。而在分布式文件系统层，由于不同的分布式系统所提供的接口不同，需要针对特定的分布式文件系统来实现监测代理，例如ceph的分布式文件系统层可以使用ceph-dash作为监测代理。

监测代理的作用是，接收监测服务器的监测命令，命令中包括监测的指标、数据采集的间隔(例如10 s)以及采样次数，然后以规定的间隔采集性能信息，将数据先保存到本地，达到采样次数要求后，再以异步的方式将其发送给监测服务器。之所以采用异步的方式是为了防止阻塞，减小监测程序对于云存储系统本身的影响。

2) 监测服务器

监测服务器是监测框架中的服务端，负责向各个层次的监测代理发送监测命令，并接收来自各个监测代理采集到的性能数据，然后对各个系统层的性能信息进行综合处理，汇总得出各个层次的指定性能指标的变化曲线以及比值变化曲线，并将其展示给监测用户。用户通过这些曲线的对比，分析不同层次之间的性能关系，从而定位性能瓶颈，为下一步的性能优化提供依据。

根据图 2所示的分层性能监测与数据采集框架，对典型的云存储系统ceph进行了性能数据的采集和综合分析，以验证本文方法的可用性。

本文实验包括7个linux节点，这7个节点的配置见表 1，实验系统的架构如图 3所示。

图 3 实验系统架构

图选项

实验中使用6个linux节点搭建ceph云存储系统，另外1个linux节点作为系统的客户端；每个节点各有一个硬盘，各个节点之间使用千兆网络连接。在客户端挂载ceph集群，使用Linux下的fio命令为ceph集群添加一定负载。同时，存储层监测代理是我们实验室开发的linux性能采集工具LinuxGather；分布式文件系统层的监测代理是ceph监测工具ceph-dash。最后将整个存储层的总体性能数据与分布式文件系统层的性能数据作对比分析。

云存储系统中主要包含3种读写模式：顺序读、顺序写以及随机读写。其中多数是顺序读操作，一般发生在用户进行大文件下载的时候；其次是顺序写操作，一般发生在用户上传大文件的时候；最后是随机读写，一般发生在用户操作小文件的时候。在实验中，fio读写记录的块大小分别设置为16kB，32kB，…，4MB，8MB一共10组。在不同块大小配置下，生成上述3种模式的负载。由于云存储中读操作占多数，所以在随机读写模式中，设置读比例为70%。然后通过存储层和分布式文件系统层的监测代理，监测对应的IOPS和读写吞吐率，监测间隔为10 s，采样次数为200次。最后，统计这些结果并进行分析。

根据上一节的实验配置进行实验，监测服务器接收到各个系统层次的性能数据并汇总之后，得到了各种模式之下，分布式文件系统层和存储层的IOPS和吞吐率指标值，以及二者的比值(文件系统层/存储层)，结果如下：

由图 4~图 6，可以观察到以下现象：

图 4 存储层IOPS

图选项

图 5 文件系统层IOPS

图选项

图 6 IOPS比值(文件系统层/存储层)

图选项

随着读写记录块的增大，存储层IOPS基本保持稳定，文件系统层顺序读IOPS随着记录块的增大成指数型下降，并且在块大小达到64kB时，与存储层顺序读IOPS相等。文件系统层顺序写IOPS在块大小达到64kB之前保持稳定，在块大小超过64kB以后，块大小每增加一倍，IOPS就大约下降一倍。随机读写的规律与顺序写的类似，但是IOPS性能最差。

通过对上述现象进行分析可以得出：

1) ceph的文件系统层默认块大小为64kB，也就是说文件系统层向其底层的存储层进行读写操作的单位是64kB，这使得存储层所操作的块大小一直保持不变，所以存储层的IOPS基本保持不变，并且使得文件系统层的顺序读IOPS与存储层的顺序读IOPS在块大小为64kB的时候达到相同值。

2) 文件系统层在顺序读的情况下，第一次读取64kB数据后将其缓存起来，当文件系统层读取的块小于64kB时就直接从缓存读取并返回，而在此过程中还在源源不断的从存储层预读取数据。操作的块越小，能够预读的块就越多，所以在文件系统层看来，顺序读IOPS随着块的增大以2的幂次减小，在块大小等于64kB的时候，文件系统层与存储层的IOPS值持平(比值为1)，验证了ceph云存储系统的默认块操作单位为64kB。

3) 文件系统层在顺序写的情况下，如果记录块小于64kB，则会先将若干个记录块在缓存中拼接为64kB，再往下层的存储层写，一个单位块写完之后才算一次IO完成。所以，在块大小没有超过64kB的时候，文件系统层的IOPS是基本不变的，即都相当于64kB顺序写，而当块大于64kB之后，需要将记录块先拆分为64kB的单位，然后以64kB为单位向存储层写，只有所有的子记录块写完，才会通知文件系统层1次IO完成。所以，在这种情况下，基本上文件系统层的记录块大小每增加1倍，其IOPS就下降1倍。

4) 对于随机读写，由于其随机性使得文件系统层的记录块预读以及磁盘顺序读写的优势无法发挥，所以不论在存储层或在文件系统层其IOPS性能都是最低的。但是在随机读写的时候，依然是按照64kB单位进行，所以块大小达到64kB之前，其IOPS基本不变，超过64kB之后IOPS有下降趋势，原因与顺序写类似。另外随机读写的吞吐率增加是因为随着记录块的增大，随机读写的模式逐渐靠近顺序读写，顺序写的吞吐率增大的趋势使得随机读写的吞吐率也有增大的趋势。

由图 7~图 9可以看出，存储层的顺序读吞吐率整体上保持不变，文件系统层的顺序读吞吐率有微小的增长趋势，而其他读写模式的吞吐率基本保持线性增长，在块大小达到4MB的时候停止。文件系统层与存储层的性能比值大致保持稳定，其中顺序读的比值约为0.5，随机读写的比值约为0.2，而顺序写的比值约为0.1。这说明，ceph云存储系统从文件系统层到存储层进行操作时存在比较严重的读写放大问题，特别是写操作，很大程度上浪费了存储层的性能资源。

图 7 存储层吞吐率

图选项

图 8 文件系统层吞吐率

图选项

图 9 吞吐率比值(文件系统层/存储层)

图选项

综合各个系统层的性能数据，通过对比分析可以得出以下结论：

1) ceph云存储系统具有良好的顺序读写性能，其中顺序读操作最能够充分利用底层存储层的性能，顺序写操作对底层存储层性能的利用率较低(吞吐率比值只有0.1左右)，随机读写的性能最差，对底层存储层的利用率介于上述二者之间，但是由于存储层本身的随机读写性能本身较差，所以造成上层的随机读写性能无法有效提高。因此，ceph云存储系统最佳应用场景是大文件顺序读占绝大多数的应用，如视频分享网站等，而不适合小文件随机读写，例如一般的数据库操作。

2) 总体上ceph存储层的性能越高则分布式文件系统层性能越高，2个层次上的读写吞吐率比值基本保持稳定，但是在块大小为4MB时遇到了瓶颈。如果以传统的经验分析，则一般会认为系统瓶颈就是存储层性能瓶颈，也就是磁盘性能瓶颈，换性能更高的磁盘或者使用SSD、内存盘等即可改善系统性能。这样做虽然能一定程度上优化系统，但代价较高，且会引入其他棘手的问题(如SSD的写寿命问题)。通过分层性能监测和采集的方法，综合分析可以判断，本实验中ceph系统在用于大文件读写时存在的系统性能瓶颈实际上在于文件系统层，即文件系统默认块大小的限制以及读写放大问题的限制。要真正改善系统，就要针对这2个具体的瓶颈入手，一是设置大一些的默认块(如128kB或更大)，二是对系统的读写算法进行修改，减小读写放大。

本文提出了一种云存储系统分层性能监测和采集的框架及对各系统层性能信息进行综合分析的方法，能够简便地确定云存储系统的应用场景以及定位系统性能瓶颈，并在开源云存储系统ceph上进行了实验，验证了本文所提出方法的可用性。

就目前查到的资料来看，通过对云存储系统进行分层的性能监测和采集，然后进行整体分析来确定其应用场景和定位性能瓶颈，是一种新的思路。本文提出的方法目前只在ceph云存储系统上进行了验证，未来还需要在其他类型的主流云存储系统上(例如Hadoop云存储)进行实验，以完善和改进分层采集框架和分析方法。另外，本文所提出的分析方法目前还没有实现完全的自动化，未来可以考虑实现分层性能数据的自动处理，为评估人员提供最终的报表以作进一步分析。