加载中…
正文 字体大小:

块存储,文件存储,对象存储的层次关系

(2017-05-12 21:44:42)
标签:

it

分布式存储

应用的角度聊过了,我们再看看这三种存储的一些技术细节,首先看看在系统层级的分布。
块存储,文件存储,对象存储的层次关系
      我们从底层往上看,最底层就是硬盘,多个硬盘可以做成RAID组,无论是单个硬盘还是RAID组,都可以做成PV,多个PV物理卷捏在一起构成VG卷组,这就做成一块大蛋糕了。接下来,可以从蛋糕上切下很多块LV逻辑卷,这就到了存储用户最熟悉的卷这层。到这一层为止,数据一直都是以Block块的形式存在的,这时候提供出来的服务就是块存储服务。你可以通过FC协议或者iSCSI协议对卷访问,映射到主机端本地,成为一个裸设备。在主机端可以直接在上面安装数据库,也可以格式化成文件系统后交给应用程序使用,这时候就是一个标准的SAN存储设备的访问模式,网络间传送的是块。
如果不急着访问,也可以在本地做文件系统,之后以NFS/CIFS协议挂载,映射到本地目录,直接以文件形式访问,这就成了NAS访问的模式,在网络间传送的是文件。
如果不走NAS,在本地文件系统上面部署OSD服务端,把整个设备做成一个OSD,这样的节点多来几个,再加上必要的MDS节点,互联网另一端的应用程序再通过HTTP协议直接进行访问,这就变成了对象存储的访问模式。当然对象存储通常不需要专业的存储设备,前面那些LV/VG/PV层也可以统统不要,直接在硬盘上做本地文件系统,之后再做成OSD,这种才是对象存储的标准模式,对象存储的硬件设备通常就用大盘位的服务器。

从系统层级上来说,这三种存储是按照块->文件->对象逐级向上的。文件一定是基于块上面去做,不管是远端还是本地。而对象存储的底层或者说后端存储通常是基于一个本地文件系统(XFS/Ext4..)。这样做是比较合理顺畅的架构。但是大家想法很多,还有各种特异的产品出现,我们逐个来看看:
对象存储除了基于文件,可以直接基于块,但是做这个实现的很少,毕竟你还是得把文件系统的活给干了,自己实现一套元数据管理,也挺麻烦的,目前我只看到Nutanix宣称支持。另外对象存储还能基于对象存储,这就有点尴尬了,就是转一下,何必呢?但是这都不算最奇怪的,最奇怪的是把对象存储放在最底层,那就是这两年大红的Ceph。
     块存储,文件存储,对象存储的层次关系
Ceph是个开源的分布式存储,相信类似的架构图大家都见过,我把底层细节也画出来,方便分析。

底层是RADOS,这是个标准的对象存储。以RADOS为基础,Ceph 能够提供文件,块和对象三种存储服务。其中通过RBD提供出来的块存储是比较有价值的地方,毕竟因为市面上开源的分布式块存储少见嘛(以前倒是有个sheepdog,但是现在不当红了)。当然它也通过CephFS模块和相应的私有Client提供了文件服务,这也是很多人认为Ceph是个文件系统的原因。另外它自己原生的对象存储可以通过RadosGW存储网关模块向外提供对象存储服务,并且和对象存储的事实标准Amazon S3以及Swift兼容。所以能看出来这其实是个大一统解决方案,啥都齐全。
上面讲的大家或多或少都有所了解,但底层的RADOS的细节可能会忽略,RADOS也是个标准对象存储,里面也有MDS的元数据管理和OSD的数据存储,而OSD本身是可以基于一个本地文件系统的,比如XFS/EXT4/Brtfs。在早期版本,你在部署Ceph的时候,是不是要给OSD创建数据目录啊?这一步其实就已经在本地文件系统上做操作了(现在的版本Ceph可以直接使用硬盘)。

现在我们来看数据访问路径,如果看Ceph的文件接口,自底层向上,经过了硬盘(块)->文件->对象->文件的路径;如果看RBD的块存储服务,则经过了硬盘(块)->文件->对象->块,也可能是硬盘(块)->对象->块的路径;再看看对象接口(虽然用的不多),则是经过了硬盘(块)->文件->对象或者硬盘(块)->对象的路径。
是不是各种组合差不多齐全了?如果你觉得只有Ceph一个这么玩,再给你介绍另一个狠角色,老牌的开源分布式文件系统GlusterFS最近也宣布要支持对象存储。它打算使用swift的上层PUT、GET等接口,支持对象存储。这是文件存储去兼容对象存储。对象存储Swift也没闲着,有人在研究Swift和hadoop的兼容性,要知道MapReduce标准是用原生的HDFS做存储的,这相当是对象存储去兼容文件存储,看来混搭真是潮流啊。

    虽说现在大家都这么随便结合,但是这三种存储本质上还是有不同的,我们回到计算机的基础课程,从数据结构来看,这三种存储有着根本不同。块存储的数据结构是数组,而文件存储是二叉树(B,B-,B+,B*各种树),对象存储基本上都是哈希表。
块存储,文件存储,对象存储的层次关系

   
数组和二叉树都是老生常谈,没有太多值得说的,而对象存储使用的哈希表也就是常听说的键值(KeyVaule型)存储的核心数据结构,每个对象找一个UID(所谓的“键”KEY),算哈希值(所谓的“值Vaule”)以后和目标对应。找了一个哈希表例子如下:
关键字
内部编码
内部编码的平方值
H(k)关键字的哈希地址
KEYA
11050201
122157778355001
778
KYAB
11250102
126564795010404
795
AKEY
01110525
001233265775625
265
BKEY
02110525
004454315775625
315

    键值对应关系简单粗暴,毕竟算个hash值是很快的,这种扁平化组织形式可以做得非常大,避免了二叉树的深度,对于真.海量的数据存储和大规模访问都能给力支持。所以不仅是对象存储,很多NoSQL的分布式数据库都会使用它,比如Redis,MongoDB,Cassandra 还有Dynamo等等。顺便说一句,这类NoSQL的出现有点打破了数据库和文件存储的天然屏障,原本关系数据库里面是不会存放太大的数据的,但是现在像MongoDB这种NoSQL都支持直接往里扔大个的“文档”数据,所以从应用角度上,有时候会把对象存储,分布式文件系统,分布式数据库放到一个台面上来比较,这才是混搭。

    当然实际上几个开源对象存储比如swift和ceph都是用的一致性哈希,进阶版,最后变成了一个环,首首尾相接,避免了节点故障时大量数据迁移的尴尬,这个几年前写Swift的时候就提过。这里不再深入细节。 

    今天先写到这里,改天再聊聊分布式存储,软件定义存储和云存储啥的。


0

阅读 评论 收藏 转载 喜欢 打印举报
已投稿到:
  • 评论加载中,请稍候...
发评论

    发评论

    以上网友发言只代表其个人观点,不代表新浪网的观点或立场。

      

    新浪BLOG意见反馈留言板 电话:4006900000 提示音后按1键(按当地市话标准计费) 欢迎批评指正

    新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

    新浪公司 版权所有