Swift中大对象(大于5GB)的处理

本文翻译整理自swift官方文档《OpenStack Object Storage Administration Manual》中的“Managing Large Objects (Greater than 5 GB)”一节,并实测,验证文档中的内容。点这里可以看到在线文档。

 

默认情况中,Swfit上传的最大单个对象的大小为5GB。然而,对于下载对象的大小却是没有限制的,这种“下载无限制”的概念是通过将分段对象组织起来模拟实现的。大对象的每个分段被分别上传,然后再创建一个清单文件(manifest file)指明这个对象所包含的分段,下载时,清单所指示所有分段会被组织成一个单独的对象进行下载。这种实现方式同时页提高了上传的速率,因为我们可以将一个对象的多个分段进行并行的上传。

 

使用swift命令管理分段对象

尝试这种特性的最快捷的方式,是使用OpenStack对象存储客户端工具。上传对象时,你可以使用-S选项来指明每个分段的大小,例如:

# swift upload test_container -S 1073741824 large_file

这条命令会将large_file分成一组1G大小的分段,然后并行的上传这些分段。一旦所有的分段都上传完毕了,swift客户端工具就会为这些分段创建一个manifest文件,以保证这些分段可以作为一个对象large_file被下载。

以下命令将会下载整个大对象:

swift download test_container large_file

swift命令行工具采用一种严格的转换方式来实现对分段对象的支持。在上面的例子中,swift命令行工具会首先将所有的分段上传到另一个容器(test_container_segments)中,这些分段被命名为类似large_file/1290206778.25/21474836480/00000000, large_file/1290206778.25/21474836480/00000001等 这样的名字。

使用一个分离的容器存储分段的主要的好处是,当我们对主容器进行listings操作时,将不会把所有的分段名称都展示出来。使用 <name>/<timestamp>/<size>/<segment> 这种格式明明对象的分段,是因为如果用户上传了一个拥有相同名称的新对象,将会不覆盖前一个对象,知道清单文件被更新。

swift命令行工具会帮你管理这些分段文件,在删除、覆盖的时候删除这些老的分段。如果需要的话,你可以使用-leave-segments选项来覆盖这些行为。在你希望对大对象进行多版本管理时,s这将会非常有用。

 

直接使用API管理大对象

你可以直接使用HTTP请求而非swift客户端工具来操作分段和清单。你可以像上传其他文件一样直接上传分段、清单文件,其中清单文件只是一个拥有 X-Object-Manifest 头的大小为0字节的普通文件。

一个对象的所有分段必须存储在同一个容器中,拥有共同的对象名称前缀,并按照他们应有的顺序排序命名。它们可以和清单文件不在同一个容器中,这可以将容器中的对象列表保持的比较干净。

清单文件只是一个大小为0字节、拥有 X-Object-Manifest: <container>/<prefix> 头的普通文件。其中<container>是对象分段所在的容器名称,<prefix>是这些分段的公共前缀。

最好的方式是,先上传所有的分段,再创建/更新清单文件。在这种情况下,在对象完全上传成功前,该对象是不会被下载请求访问到的。你也可以上传一堆新的分段到另外一个位置,然后更新清单文件指向新的位置。在这些新分段上传的过程中,原来的清单文件还是可以被访问的,即在新分段上传的过程中,对该清单文件的下载请求,还是返回原来的分段对象。

这里有一个使用curl执行1个字节的小分段上传的范例:

# 首先,上传所有的分段

$ curl -X PUT -H 'X-Auth-Token: <token>' http://<storage_url>/container/
myobject/1 --data-binary '1'
$ curl -X PUT -H 'X-Auth-Token: <token>' http://<storage_url>/container/
myobject/2 --data-binary '2'
$ curl -X PUT -H 'X-Auth-Token: <token>' http://<storage_url>/container/
myobject/3 --data-binary '3'

# 然后,创建清单文件

curl -X PUT -H 'X-Auth-Token: <token>' -H 'X-Object-Manifest: container/myobject/' http://<storage_url>/container/myobject --data-binary '' 

# 现在我们可以将这些分段当做一个对象进行下载

curl -H 'X-Auth-Token: <token>' http://<storage_url>/container/myobject

 

大对象的额外注意点

对清单文件执行一个GET或HEAD请求,X-Object-Manifest: <container>/<prefix> 头会联通串联后的对象一起返回,因此你可以根据 X-Object-Manifest 判断是从哪里获取的分段。

对清单文件执行GET或HEAD请求,响应头 Content-Length 的值为其指向的所有分段的大小总和,因此这个值是动态的。因此,当你在创建清单文件后,继续上传了额外的分段,将会使串连对象变得更大,但无需重新构造清单文件。

对清单文件执行GET或HEAD请求,响应头 Content-Type 的值与使用PUT请求创建该清单时指定的 Content-Type 相同。因此,你可以通过重新发送PUT请求来改变 Content-Type 的值。

对清单文件执行GET或HEAD请求,响应头 ETag 的值将为其指向的每个分段的ETag串联字符串的MD5值,因此这个值是动态的。通常,swift中对象的ETag值是对象内容的MD5值,这对每个单独的分段也是成立的。但是,清单文件本身不会产生这样的一个ETag值,因此这个方法至少可以用于判断文件的改变。

 

大对象存储的历史和背景

在当前版本的实现方式之前,大对象的支持已经经历了若干次迭代实现。

在swift中限制单个对象的大小的最主要原因是为了平衡ring上的不同分区。为了保证集群中的磁盘可以被均匀的利用,很显然我们需要将大文件分解成更小的分段,然后在读操作的过程中将小分段合并。

在提出大对象的支持之前,一些应用已经在客户端将它们要上传的对象分解成一些独立的段,然后再对这些分段进行重组。这种设计使得客户端可以支持备份并归档大数据集,然而由于网络中断等问题,却不能很好的提高性能、减少错误。采用这种方法最主要的缺点是,由于需要原始的划分信息来重组对象,因此在一些场景(如CDN源)中这种方法就不太实际。

为了消除客户端对于存储大于5GB对象需求的障碍,我们最初设计了一种对大对象上传完全透明的支持方式。为了实现完全透明的大对象上传,proxy server将会在对象上传的过程中负责将这个大对象分段,而不需要修改任何的API。因此所有的分段都被完全隐藏在了客户端API之后。

然而,这种实现方式将引起一些问题:它不支持客户端并行的上传一个对象,并且没有错误恢复机制。相较于完全透明的分段方式带来的益处,它的复杂性还是显得太高了。

我们当前使用的“user manifest”设计时为了给客户端提供一个透明的大对象下载方式,同时也可以支持分段上传,并保持客户端API的干净、整洁。

另一种“显示的”user manifest实现方式也被讨论过的,它需要预先定义列出已上传分段的格式。虽然这种方式可以提供一些潜在的优点,但是为了实现一个更简单的API,我们应避免将负担推到客户端(实际上,就是决定“X-Object-Manifest”的格式)。

在开发的过程中,我们注意到,这种基于公共路径前缀的“隐式的”user manifest方法将被会被最终一致性窗口的大小影响,理论上会产生这种情况:在上传了一个对象很短的时间内,对清单文件执行GET操作,将会返回一个无效的对象。事实上,除非你的swift运行在一个并发上传度非常高的测试环境中,你将不太可能会遇到这种情况(在并发上传非常高的测试环境中不运行object-updaters和container-replicators)。

像所有的OpenStack对象存储中的特性一样,支持大对象是一个发展中的特性,它将继续改善,并可能随时间而改变。

 

实测结果1. swift CLI 进行大文件上传、下载

测试文件repost_backup2.sql的大小为12.3G。

1)直接上传,会报错,文件太大。 

2)指定分段上传,每段5G。swift CLI工具将文件分成3段,并创建了清单文件。

3)上传成功后,查看容器,发现新增了docs_segments容器。

4)目标容器中只有repost_backup2.sql清单文件,并没有分段对象;docs_segments容器中存储分段对象。

5)下载时,将分段对象作为一个大对象下载。

 

实测结果2. curl 进行分段上传、合并下载

1)分别上传3个1字节大小的文件,公共前缀为"myobject/"

2)创建清单文件,指定X-Object-Manifest的值为公共前缀"docs/myobject/",并命名为用户知晓的myobject。

3)查看上传结果,可以看到3个分段对象和1个清单文件。

4)下载myobject对象,可以看到返回结果将3个分段文件进行了串联,并只返回一个myobject对象。

 

此外,通过仔细观察HTTP的头信息,我们也可以应正“大对象的额外注意点”小节中阐述的内容。 

 

一些思考

至此,想到了一些在开发API时需要注意的问题:

  1. Object的类型定义。由于伪目录的存在,需要为object增加subdir属性,用于区别伪目录和真实的对象;由于清单文件的存在,object的属性应增加对X-Object-Manifest元数据的过滤,用于判断清单文件;
  2. 容器的listing操作。为了对用户隐藏分段过程,在执行listing操作的时候怎样才能足够“干净”?模仿swift CLI为每个容器创建一个“容器_segments”的分段容器,并限制用户不能创建/访问“_segments”结尾的容器?
  3. 根据2,想到对象版本的管理,类似的为具有版本的容器创建“容器_versions”的历史版本容器,并限制用户不能创建/访问“_versions”结尾的容器?
  4. 对象可以并行上传,是否也可以并行下载?
  5. 大对象的更新操作,可以对其每个分段进行检测,只更新有变动的分段?

这些都是可以做的工作点,前3个属于API层的约束问题,较好实现;后2个应权衡swift的实现机制,做一些测试进行验证。

 

更新更新 

为了给自己和看文的你更多的思考空间,我就不在上面每条问题的下面直接给出目前的想法了,更新在这里=D:

1. 关于Object的类型定义问题。

确实需要增加一个 X-Object-Manifest 属性,虽然分段的过程我们是希望对SDK使用者透明,但也不排除人家也有这个权利知道某个清单文件的真实身份。做了测试,在对Container中的对象进行listing操作时,以JSON格式获取详情为例,以下为返回内容:

[
{"hash": "c4ca4238a0b923820dcc509a6f75849b", "last_modified": "2013-03-21T13:51:18.917260", "bytes": 1, "name": "1", "content_type": "application/x-www-form-urlencoded"}, {"hash": "c81e728d9d4c2f636f067f89cc14862c", "last_modified": "2013-03-21T13:51:41.530770", "bytes": 1, "name": "2", "content_type": "application/x-www-form-urlencoded"}, {"hash": "eccbc87e4b5ce2fe28308fd9f2a7baf3", "last_modified": "2013-03-21T13:51:59.653640", "bytes": 1, "name": "3", "content_type": "application/x-www-form-urlencoded"}, {"hash": "d41d8cd98f00b204e9800998ecf8427e", "last_modified": "2013-03-21T13:55:33.353110", "bytes": 0, "name": "myobject", "content_type": "application/x-www-form-urlencoded"}, {"hash": "c4ca4238a0b923820dcc509a6f75849b", "last_modified": "2013-03-21T13:54:19.956880", "bytes": 1, "name": "myobject/1", "content_type": "application/x-www-form-urlencoded"}, {"hash": "c81e728d9d4c2f636f067f89cc14862c", "last_modified": "2013-03-21T13:54:32.005000", "bytes": 1, "name": "myobject/2", "content_type": "application/x-www-form-urlencoded"}, {"hash": "eccbc87e4b5ce2fe28308fd9f2a7baf3", "last_modified": "2013-03-21T13:54:42.420390", "bytes": 1, "name": "myobject/3", "content_type": "application/x-www-form-urlencoded"}, {"hash": "d41d8cd98f00b204e9800998ecf8427e", "last_modified": "2013-03-21T13:27:49.747290", "bytes": 0, "name": "repost_backup2.sql", "content_type": "application/x-sql"}, {"hash": "b2cfa4183267af678ea06c7407d4d6d8", "last_modified": "2013-03-21T13:16:14.842310", "bytes": 10, "name": "testFile", "content_type": "application/octet-stream"}
]

标红的两个对象实际上都是清单文件,但是在列表中却与其他普通对象没有任何区别:除了长度为0。但需要知道的是,就是一个普通对象也可以是长度为0的呀。所以 X-Object-Manifest 在这里几乎用不到。

然而,对清单文件执行HEAD或GET操作,我们就可以看到 X-Object-Manifest 了,并且对象的长度也不再是0,而是分段对象的总和,即大对象的真正长度。因此,我们为Object对象添加manifest属性的用武之地就是“对清单文件执行HEAD或GET操作”。

2. 容器的listing操作。

Swift CLI 将分段对象单独存在另一个容器中的方式蛮好的,这样可以避免对目标容器listing时出现很多诡异的分段对象(分段对象的属性和普通对象无区别,所以很难做过滤)。

然而,swift CLI 创建的容器也与普通容器没差别,因此在对Account做listing操作的时候会多出一些xxx_segments容器,这样也是不好的。

一种想法是限制用户容器命名,以“_segments”结尾的名称不得用于容器;

另一种想法是保留一个 X-Container-Meta-Segment 属性,类似编程语言里的保留字,属性值为分段对象的清单文件所在的容器名称(不同容器公用一个分段容器时,可以考虑设置其他的值,总之是需要这个属性来做区别)。这样可以在SDK层根据X-Container-Meta-Segment过滤,从而在account listing时隐藏分段对象。

可是,以上两种基于API层的过滤改进还是存在问题,即对account进行HEAD操作时显示的容器数量还是包含分段容器的,因此如果要很完美的做到“透明”,则不可避免的需要动到源码,而容器在ring上的分布也因此受到影响。

感觉上还是没有完美的方案,所以根据需求权衡吧,或者直接放弃“透明”的想法,让SDK使用者自己也做一些业务约束。

 

 

posted @ 2013-03-21 19:58  YUKI小糖  阅读(3252)  评论(0编辑  收藏  举报