Swift云存储环境下基于I／O负载均衡的读取策略

蒋 溢，孙雪涛，杨 川

（1.重庆邮电大学 计算机科学与技术学院，重庆400065；2.中国电信股份有限公司泸州分公司，四川 泸州646000）

0 引 言

云存储通过集群技术、网格技术或分布式文件系统等，将网络中不同类型的存储设备协同起来，共同对外提供数据存储和业务访问服务。云存储提出后，得到了众多厂商的支持和关注。Amazon推出了EC2［1］（弹性计算云）云存储产品S3［2］，旨在为用户提供互联网服务形式同时提供更强的存储和计算功能。随后微软也已经推出了提供网络移动 硬 盘 服 务 的 Windows Live SkyDrive［3］。Apache 根 据Google的 GFS［4］和 Bigtable［5］也 先 后 推 出 了 HDFS［6］和HBase［7］，为云计算环境提供计算和存储的支持。

本文基于开源Openstack［8］的对象存储环境，首先分析了Openstack的Swift［9］对象存储架构，针对其对象存储没有元数据中心节点、系统数据读写通过哈希一致性算法［10］完成，并没有充分利用对象存储系统的备份机制来改善系统数据读取速度的现状，给出了一种能够均衡存储设备I／O负载的策略，并在文章最后给出了相关实验过程，实验结果验证了本文给出的策略的有效性。

1 Swift对象存储架构

1.1 swift简介

OpenStack Object Storage （Swift）是 OpenStack开 源云计算项目的子项目之一，被称为对象存储。Swift适用于永久类型的静态数据的长期存储，尤其适合存储虚拟机镜像、图片存储、邮件存储和存档备份等类型的数据。

1.2 Swift架构概述

Swift主要有4个组成部分：Proxy Server（代理服务）、Storage Server （存储服 务）、Consistency Server （一致性服务）、Ring（环状结构）文件，结构如图1所示。

图1 Swift组件结构

其中，Proxy Server是提供Swift API的服务器进程，负责Swift其余组件间的相互通信；Storage Server提供了磁盘设备上的存储服务；Consistency Servers是保持一致性的服务器，其目标是查找并解决由数据损坏和硬件故障引起的不一致性；Ring文件是它整个Swift中最重要的组件，其主要作用是用于记录存储对象与物理位置间的映射关系，Ring使用域 （Zone）、设备 （Device）、分区 （Partition）和副本 （Replica）来维护这些映射信息。

2 Swift对象存储文件读取策略

Swift中存储对象通过3个逻辑层次来实现的，分别是Account（账户）、Container（容器）、Object（对象）。一个Account包含多个Container，而一个Container又包含多个Object。所有每个对象的逻辑路径都是／Account name／Container name／Object name。Swift中对对象 （Object）的读写是通过Ring文件来完成的。Ring文件的作用就是将上面的对象逻辑路径和实际对象存储的物理位置的映射。

2.1 哈希一致性算法

哈希一致性算法是1997年由麻省理工学院提出的一种分布式哈希 （DHT）实现算法，其基本原理是将机器节点和key值都按照一样的hash算法映射到一个0～2＾32的圆环上。当有一个写／读的请求到来时，计算Key值k对应的哈希值Hash（k），如果该值正好对应之前某个机器节点的Hash值，则直接写／读该机器节点，如果没有对应的机器节点，则顺时针查找下一个节点，进行写／读，如果超过2＾32还没找到对应节点，则从0开始查找 （因为是环状结构）。如图2所示。

在Swift中为了系统的扩展性在哈希环上对应的不再是真实的硬盘或者分区，而是采用了虚拟节点，然后再由虚拟节点对应到真实的节点 （多对一）。这里的虚拟节点即是上文中提到的Ring中的Partition，Device则对应真实的节点。

图2 哈希一致性算法

2.2 Swift中基于哈希一致性算法的读取策略

首先，当系统接受到客户发来的请求，先进行用户身份的验证，当验证成功后，再将请求传给Proxy Server。其次，Proxy Server通过Ring来将对象的逻辑路径通过哈希一致性算法进行处理，将生成的哈希字符串的前一部分与Ring文件中的partition列表中的partition哈希值进行对比，如果值相等，则该对象在这个partition中。再通过Devices表读取该Partition所存在的物理位置，最后读取数据对象本身，并将读取数据通过Proxy Server返回给用户。其读取流程如图3所示。

图3 读策略流程

由此可见，文件读取的时候非常容易出现磁盘利用率不平衡的情况，如果某一个磁盘I／O请求队列中有大量请求，而受硬盘串行工作机制的限制，读写文件的速度会大幅降低，这是由于磁盘臂会频繁地寻道。并且当并发请求量越大，读写的速度会越低。例如IDE 7200转的硬盘读写速度一般能达到30M／S左右，但是当同时读取两个文件时，硬盘读写速度只有10M／s左右。

由于读取负载不均衡问题极大地限制了系统整体I／O性能，所以设法均衡各个磁盘的I／O请求，实现并行的读取成为必要。

3 基于I／O负载均衡的读取策略

3.1 策略分析

由于Swift为了数据的存储安全每个partition都有2个副本，也就是说一个系统中将有3份同样的数据存在。这两个副本的作用是用来做数据安全备份的，一旦当swift数据损坏时，可以用这两个副本进行恢复。但是当进行文件读取的时候，这两个备份文件一般情况下去没有起到作用。Swift还有一个特性，那就是为了数据的安全，这3份数据每两份都不能存在于系统的同一个Zone中。（zone可以是一个硬盘，一个服务器，一个机架，一个交换机，甚至是一个数据中心）。所以可以得出不同的Zone肯定不在同一块硬盘上，如果能利用3个备份在不同硬盘上的特点，使读取的请求更加平均的分布在不同的硬盘上，将提高swift的读取效率。本文仍然基于原有的哈希一致性算法实现数据的读写，采用添加加权法来使读取负载更加均衡。

本文策略的核心在于使文件读取的请求尽可能平均地分布在各个硬盘上，并为每个存储的partition维护一个权值，文件读取的时候总是选择权值最小的硬盘中的那个partition去读取。

策略实现通过在Ring的Devices列表中添加相应字段，并记录每一个Device当前的读写请求量。当proxy收到客户已验证过的请求后，先在Ring中通过哈希一致性算法找到存储该对象的partition。然后再通过Ring查找该partition的备份，根据这三份数据在Devices列表中找到设备表中对应的设备。最后，根据存储设备的负载按照一定的方法计算权值，并按权值进行排序，实现负载小的device中的partition优先被选择。如果3个备份的负载量相同那么就选取列表中的第一个，当选择完成后，更新List of Devices中的负载权值。

基于I／O负载均衡的读取策略理论分析如下：

设系统的平均读取速率为P，Rs为系统读取请求的数量，Ci为某硬盘的I／O读取极限速率，Rci为某块硬盘上的请求数量，θci为该块硬盘I／O极限速率和多个并行读取请求时的速率之比

假如我们所有使用的硬盘都是同样的，在Ci是相同的。则该式可简化为

因为硬盘的串行工作机制的限制，当我们并行读写多个文件时，速度比串行读写多个文件还要慢，多文件并行操作时，时间都花在磁头摆动上了，所以θci随着Rci的增加会迅速下降。由上面的公式中可以得出，当Rci之间的值越接近，则P的值越大。

3.2 策略实现

对3.1描述的策略采用如图4所示的实现流程：

首先当系统接收到用户的读请求后。根据逻辑路径的哈希值在列表中找到对应的partition，然后在通过partition，找到该partition的备份replica。接着从一个partition和两个replica所对应的Device中找到负载最小的一个进行读操作，并将对应的Device的Load值加1。读操作执行完毕之后将该Device的Load值在减1。

图4 策略流程

4 仿真实验

4.1 实验环境及方法

实验采用Unix／Linux下提供的iostat来观察物理磁盘的活动时间及其平均传输速度，并将结果写入到监测文件中。选择1G字节大小的文件进行读取实验，原因在于大文件有利于查看测试数据并进行比对，便于对平均硬盘I／O数据进行分析。

实验分为两组。第一组是采用原有策略进行读取实验，第二组是采用基于I／O负载均衡的读取策略进行实验。两组实验中都分别对，1个、10个、50个、100个、500个、1000个、2000个文件同时读取进行测试。

测试环境的物理架构图如图5所示，Auth Node作为身份验证主机Proxy Node作为接收和转发客户的读写请求，3个Storage Node作为3个Zone。

系统配置见表1。

图5 实验物理架构

表1 系统配置

4.2 实验结果

通过iostat监测原有策略及本文基于I／O负载均衡策略的数据读取速率，见表2。

表2 改进前策略数据平均读取速率

通过iostat监测更改算法后的读取速率数据见表3。

将监测到的数据在两种策略下对比，并绘制成图表如图6所示。

表3 改进后策略数据平均读取速率

图6 数据平均速率对比

4.3 结果分析

由图6可见，对单个文件进行读取时，不存在并行读取多文件，所以两种算法速率一样，且都接近硬盘的极限I／O速率。当文件的读取任务请求为10时。此时原有策略不会将读取请求负载均衡到各个存储设备上，所以整体读取效率比较基于I／O负载均衡的读取策略低。

随后的两组数据随着读取文件的数量逐渐上升，基于I／O负载均衡的读取策略由于更好地均衡了读取请求，所以速度下降的较慢。

实验结果表明，原有策略随着读取请求负载的上升，读取请求分配不均的现象会变得比较明显，从而导致系统整体吞吐量下降。而改进后的算法，由于更好地分散了负载，所以能够获取更好的系统吞吐量。

5 结束语

云存储集群具有即时并行读取量大的特点，因此如何能将这些请求更加合理地平均的分配到各个硬盘上，对于提高整个系统的吞吐量尤为重要。本文主要通过改进数据读取策略，均衡系统读取负载，将读取请求平均分配到各个存储设备上，使得各个设备之间的I／O负载更加均衡，实现了并行读取，提高了存储平台的整体读取性能，文章通过实验验证了本文策略的有效性。

［1］Amazon Elastic Compute Cloud（Amazon EC2）［EB／OL］.［2012－11－18］.http：／／aws.amazon.com／cn／ec2／.

［2］Amazon Simple Storage Service （Amazon S3）［EB／OL］.［2012－11－18］.http：／／aws.amazon.com／cn／s3／.

［3］MicrosoftSkyDrive ［EB／OL］.［2012－11－18］.http：／／zh.wikipedia.org／zh－cn／Microsoft＿SkyDrive.

［4］Ghemawat S，Gobioff H，Leung S T.The Google file system［J］.ACM SIGOPS Operating Systems Review.ACM，2003，37 （5）：29－43.

［5］Hall K B，Gilpin S，Mann G.MapReduce／Bigtable for distributed optimization ［C］／／NIPS LCCC Workshop，2010.

［6］Tom Wbite.Hadoop the definitive guide ［M］.Tsang Tairan，ZHOU Aoying，transl.Beijing：Tsinghua University Press，2010 （in Chinese）.［Tom Wbite.Hadoop权威指南 ［M］.曾大冉，周傲英，译.北京：清华大学出版社，2010.］

［7］Hbase Development Team.HBase：Bigtable－like structured storage for Hadoop HDFS ［EB／OL］.［2012－11－18］.http：／／wiki.a－pache.orglhadoop／Hbase.

［8］Open source software for building private and public clouds［EB／OL］.［2012－11－18］. http：／／www.openstack.org／http：／／www.chinacloud.cn／show.aspx？id＝766＆cid＝30.

［9］Swift1.7.6－dev documentation ［EB／OL］. ［2012－11－18］.http：／／docs.openstack.org／developer／swift／.

［10］Lewin D.Consistent hashing and random trees： Algorithms for caching in distributed networks ［D］.Cambridge， Massachusetts： Massachusetts Institute of Technology，Department of Electrical Engineering and Computer Science，1998.