浅谈爱数的存储引擎 OFS（一）

作者 | 2011-04-27 06:59 | 类型 行业动感 | 37条用户评论 »

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




爱数的备份引擎历经了Turtle引擎、Hercules引擎，现已经发展到第三代引擎—FAST引擎，如引擎名字一样，我们在着手架构和实现此引擎时，就希望能够在性能上有所突破。但在现阶段无新的理论基础以及新算法的诞生，如果希望引擎能够在备份恢复性能上取得新的突破，只能寄希望于引擎架构上的突破，这也是FAST引擎最鲜明的技术特点，在此文章中，将把FAST引擎的关键组件之一：OFS存储引擎进行初步的介绍。

一、把握趋势的关键点

当Oracle的埃里森郑重的发誓，Exadata 将会是Oracle最成功的产品，业界还对此不置可否。在完成对Sun公司的收购后，短短一年时间，Oracle就取得了近80%的增长速度，而取得此佳绩最关键的产品线，正是Exadata2，这款集成Oracle数据库、Sun服务器和存储的OLTP专用服务器，帮助用户在更低总体投资成本下获得了不凡的性能。

Exadata的成功，不仅仅体现了Oracle并购上的整合能力，更重要反应中大型系统通过集成技术架构获得更好投资回报率的技术趋势。通过集成技术架构，不仅仅可以保证系统的每一个组件（硬件模块和软件模块）的运行效率得到充分发挥，而且针对特定应用，进行系统的专用优化，从而取得了显著的性能突破。

二、OFS 是集成技术架构的产物

Object File System（简称OFS） 作为FAST引擎的存储系统，它是一个运行在用户态的文件系统，以对象为存储粒度，以 GNS（Global Namespace） 为命名路径，采用树状结构索引，可支持全局范围内对象按类别和时间点进行存储，并且内置重复数据删除、集群式、分布式存储、数据生命周期管理等一系列现代文件系统所具有的技术特点。

之所以说OFS是集成技术架构的产物，在开始设计第三代备份恢复引擎FAST之前，不仅仅集成技术架构已经成为业内普遍采用的架构，而且根据爱数的业务战略规划，也需要满足如下两个关键需求：

性能目标：伴随着用户数据量的快速膨胀，FAST引擎作为数据调度的关键组件，要能够满足PB级的数据传输和存储性能目标，而FAST引擎的性能关键部件正是后端的存储系统。

应用环境：第三代引擎FAST不仅仅要满足爱数在备份容灾业务领域的技术需求，还需要满足归档、非结构化文档存储的业务技术需求，即FAST引擎本身是一个集成应用的引擎，将用于备份容灾、数据归档、非结构化文档存储等。

正因为如上的一些背景，整个OFS是作为一个专用的存储引擎与FAST集成，通过集成技术架构实现备份容灾、数据归档、非结构化文档存储等应用领域的存储需求，并且通过与FAST集成，在Cache、Scale-out横向扩展等性能优化上将进行应用整合，从而通过更小的付出获得更优的性能目标。

三、OFS的主要特点和设计目标

1）用户态文件系统

有别于传统文件系统，OFS是驻足在已有文件系统之上的 用户态文件系统 ，并且采用专用API访问，不支持POSIX或Windows FS等标准访问接口。此技术方案可保证OFS具有更强移植性（操作系统无关）、简化开发和维护难度、便于跨网络和分布式扩展，以及基于双C技术（Cluster和Cache）来不断优化性能等。

2）全局对象存储

OFS适用于网络存储，它以GNS作为对象路径，可保存来自于全局网络环境的数据集中存储，例如备份、归档、共享等数据集中存储应用，并且以对象作为存储粒度，可支持文件、邮件、数据库、表、设备等各类结构化和非结构化的数据对象的存储。

GNS是全局名字空间 (Global Namespace)，它用于在全局范围标识一个对象的名称，这个名称可以在全局范围内唯一代表此对象。传统的命名规则，通常是单系统（一台计算机或服务器）范围的，这种情况下实现集中备份、归档、文档管理等，将面临着名称冲突，不同平台、不同协议命名规则的差异，对于一些非文件数据对象，又面临着没有可参考的命名规则，正因为诸多缺点，在整个引擎的设计中，引进GNS，如下图所示，通过GNS，可以将不同平台、不同协议、不同类型的数据对象命名统一，并且保证在全局范围内可唯一标识。

3）永远一致的文件系统

OFS采用全Journal 算法，任何时刻文件系统均处于一致性的状态，即使遇到非正常断电或不正常关机后，也不需执行硬盘检查，即可在复电后2分钟内迅速提供服务。

OFS支持自修复机制，即使OFS所存储的数据遭受到意外的破坏，也能保证数据损失降到最低。

4）无容量限制的文件系统

OFS可支持单存储介质池中介质动态增长、跨存储的多介质池扩展等，支持ZB级的数据量存储，可轻松方便地完成在线扩容和动态部署。

备注：1ZB=1024EB=1048576PB= 1073741824TB

5）高性能的文件系统

OFS针对读写操作大于合成操作、数据分类及时间点、时间线等应用特征，采用局部原理进行性能优化，在归档、备份、共享等应用中具有更好性能，并且结合集群技术，可显著提升IO整体性能。

OFS支持各种的缓冲优化机制，包括读、写缓冲，时间线预镜像（Timeline Pre-Image），提升整体访问性能。

OFS针对数据访问操作（读写、删除、合成等）的不同重要程度，将其划分为不同的执行优先级，在不同优先级操作并发访问的情形下，保证关键操作的执行性能不受影响。

6）嵌入重复数据删除

OFS内置重复数据删除，可将集中存储的重复数据进行压缩，进一步提高逻辑存储容量，并且能够与文件系统访问、集群技术等结合，且支持全局范围（全网络环境）、指定类别范围（一个或多个CID）进行重复数据删除，可保证存储系统内的整体最佳的重复数据删除性能。

7）超强快照能力的文件系统

OFS采用时间点节点内置的设计，可在瞬间创建一个快照，并且整体文件系统无快照版本限制。

8）更细粒度的配额管理

OFS可支持介质池、介质、对象的空间配额管理，包括空间配额、容量查询、容量预先防范、数据智能分布、自动精简配置(Thin Provisioning）等。

9）通用协议访问

OFS可通过与FAST内核引擎集成，将支持iSCSI、NFS、CIFS等通用数据访问协议来访问OFS所存储的对象数据，实现数据的直接读写，以满足瞬间恢复、归档在线访问等读写需求。

结束语

OFS是爱数的FAST内核引擎中所使用的核心组件，承载着爱数未来数年能够在存储备份行业脱颖而出的使命，而要实现所设定的技术目标，我想这也将会是国内存储技术的一次重要突破，在后续的时间里，我们将逐步就OFS存储引擎以及FAST内核引擎的技术详细架构、关键算法等进行阐述，希望能够继续关注。

(2个打分， 平均：3.00 / 5)

工具箱
本文链接 | | 打印此页 | 37条用户评论 »

雁过留声

“浅谈爱数的存储引擎 OFS（一）”有37个回复

  1. 我才是缓存的专家 于 2011-04-27 8:01 上午

    不错。 介绍一下联系方式可以不?

  2. 冬瓜头 于 2011-04-27 8:53 上午

    爱数也来？
    哈哈，爱数也来秀自己底层的FS了？小心哦，这里虽然不是搞存储的人士集散地，但是一不小心还是会露出马脚的：）

  3. isll 于 2011-04-27 5:31 下午

    怎么越看越像ceph呢

  4. anonymous 于 2011-04-27 5:44 下午

    先山寨再创新之路是比较不扯蛋的，爱数的技术核心并不在文件系统上，能有个不错的东西就不错了。

  5. liuben 于 2011-04-27 5:49 下午

    一般都会以某个开源文件系统为原型进行开发，比如Lustre, PVFS2, Gluster, Ceph，互联网行业公司可能更倾向于HDFS、KFS、MFS等，从无到有开发一个全新的文件系统对于国内的公司来说不是很现实。

  6. liuben 于 2011-04-27 6:12 下午

    to isll:
    仔细看了一下，应该是Google File System类似的架构，不像Ceph

  7. 冬瓜头 于 2011-04-27 6:24 下午

    哈哈，楼上几位的猜测都不太贴边。互联网公司用的FS，用到一款单一盒子设备上？再猜猜吧，我不透露。

  8. Jack_Wang 于 2011-04-27 7:21 下午

    基于fuse的吧？

  9. 聆风 于 2011-04-27 8:35 下午

    猜一下，难道是ZFS-FUS

  10. 瞎扯 于 2011-04-27 8:47 下午

    长知识了，好几个名字都没听说过。 冬瓜别卖关子了。

  11. liuben 于 2011-04-27 9:58 下午

    To 冬瓜：盒子也是可以做的，可能比较大，华赛的N8500+FileStore (VxFS + VCS)其实也可以做成一个盒子。产品有时比解决方案更吸引用户。当然，也可以是ZFS＋SUN Cluster，见过某个公司集群NAS产品，Compellent zNAS也应该是这种方式。

  12. liuben 于 2011-04-27 10:02 下午

    Btrfs和Ceph现在都是深度开发中，不大相信敢用于生产环境，胆子天大的除外，呵呵！

  13. 贺鸿富 于 2011-04-28 2:00 上午

    我是贺鸿富，感谢大家的分析，但需要跳出传统。

  14. Will Chie 于 2011-04-28 2:54 上午

    上海爱数软件有限公司总经理贺鸿富

    又来了个大佬。

  15. 冬瓜头 于 2011-04-28 4:59 上午

    我和老贺吃过饭，你绝对看不出他是老总，背个双肩包，带个眼镜，一看就是码农！哈哈，我这么说老贺绝对不会介意，因为我感觉爱数不是个官僚的公司！

  16. 冬瓜头 于 2011-04-28 5:01 上午

    至于FS是什么，我不能说，这是人家的机密。

  17. Eric 于 2011-04-28 7:54 上午

    绝对是个开源FS改的，产品宣传包装的有点过啊，无容量限制？？

  18. 贺鸿富 于 2011-04-28 8:05 上午

    大家注意，我们的介绍提到这是个存储引擎，名字叫 OFS。

  19. 马甲 于 2011-04-28 8:26 上午

    期待深入介绍OFS架构、关键算法，看看有没有干货

  20. 陈怀临 于 2011-04-28 9:06 下午

    谢谢贺总的文章。说良心话，我之前还真不认识您和不知道爱数公司。去你们网站看了一下。很不错的说。

    ”创新思考 只为更好（Rethink, to be better）“

    你们的slogan的翻译似乎有点不太贴切。个人意见啊：-）。

    我觉得这样似乎好一点：

    Be Creative; Be Better

    这样排比是否好一点。。。

  21. windstar 于 2011-04-28 9:09 下午

    咋一看以为是介绍的ZFS呢,是不是有些关系呢?

  22. 冬瓜头 于 2011-04-28 9:25 下午

    相信爱数会考虑首席建议的，和他们聊过很多，感觉就是迅速决策，迅速执行的类型。

  23. Eric 于 2011-04-28 11:22 下午

    什么叫“引擎”啊，还“存储引擎”？这里大多是码农，对市场包装那一套不是很感冒，不就是用fuse的用户态文件系统嘛，您就大胆点说具体有啥技术亮点吧，别重申那个概念了。

    具体说，我就几点疑问请教：
    1.您说无容量限制，是真的还是个噱头？
    2.这个东西支持iSCSI访问？FS上面再转成块？怎么实现，效率何在？
    3，您的Dedup是做到文件级还是块级还是字节级？我猜是文件级，那么当通过iSCSI访问的时候，Dedup就不能生效了吧？

  24. 冬瓜头 于 2011-04-29 12:03 上午

    如果我猜测没错的话，dedup是在文件和块的更底层做的，也就是对象层。所以两者兼顾。具体还是等爱数的高手来解释。

    我估计老贺和老李是有点犯嘀咕了，弯曲人的技术水平完全不像之前在chinaunix那帮混混。哈哈

  25. mousanony 于 2011-04-29 1:47 上午

    如果是在IO PIPELINE中的某个环节，在块这个层次做的话，那这个架构的”参考架构“就明确是谁了，呵呵…

  26. liuben 于 2011-04-29 2:59 上午

    Scale-Out的存储系统，理论上存储容量和性能都可以是无限的，当然实际中会受到很多方面的制约。

    Dedup现在都是块级（定长或变长）的吧，文件级SIS没有竞争力，字节级性能上估计受不了。

  27. 贺鸿富 于 2011-04-30 9:27 上午

    个人一点浅见：通用型的文件系统确实已经越来越完美了，各种新的FS也在不断地去完美着。但我们觉得在具体应用中还是有蛮多可优化的空间，所以可以借FS的思想，做特定应用范围的存储引擎，这样子会有很多架构上的优势。我们是基于这样的思路来设计的。OFS在爱数未来做信息生命周期管理将扮演极其重要的支撑作用。

    既然是（一），后面我们将会陆续公布内部的一些结构，时间不会太快，因为现在公司业务扩张得太快了，发展是硬道理。

    TO 首席：爱数这样的小公司能够得到首席一点点关注还是很高兴，同时感谢指点，我们当时也想到类似的句型来准确表达，只是内部因有点雷同“One World，One Dream”而遭到反对。这文章是我们OFS的负责人写的，我们都很喜欢弯曲，很平易近人的好地方。

  28. yunhaid 于 2011-04-30 7:11 下午

    OFS的市场在哪里？

  29. light 于 2011-04-30 9:35 下午

    备份引擎是什么啊

  30. light 于 2011-04-30 9:40 下午

    备份引擎是什么, ofs是个scale-out fs吗，
    ofs用在什么地方。下边是zfs吧

  31. tom 于 2011-05-03 8:47 下午

    是不是就是ZFS改造的？

  32. Zero 于 2011-05-04 4:37 上午

    Object File System？这个文件系统的名字不就是微软在1992年的Cairo计划提出的文件系统的名字么？爱数，你们这样真的没问题么？

  33. Shake 于 2011-05-04 9:21 上午

    这不就是对象存储吗？不会是基于Rackspace的swift来改的吧？
    估计亚马逊的S3，也不敢说，可以支撑ZB。

  34. 前Sun员工 于 2011-05-05 11:19 下午

    opensolaris+zfs无疑啊

  35. asr1k 于 2011-05-06 5:35 上午

    To 34楼

    好熟悉的zfs啊， 以前玩了很多很多年的, 很喜欢。 jumpstart定制起来很方便， 而且dtrace来做性能调优也很赞

  36. 想揍冬瓜头 于 2011-12-05 2:06 上午

    每次看到冬瓜头的发言都有一种想揍他的冲动

  37. 冬瓜头 于 2011-12-09 3:34 下午

    楼上兄弟倒是什么时候可以切磋一下。