块存储、文件存储、对象存储三者之比较( 四 ) _块存储

对象存储的定义就把元数据管理和数据存储访问分开在不同的节点上，多个节点应对多并发的访问，这自然就是一个分布式的存储产品。而分布式文件系统就很多了，各种开源闭源的产品数得出几十个，在不同的领域各有应用。至于分布式的块存储产品就比较少，也很难做好。我个人认为这个产品形态有点违和，分布式的思想和块存储的设计追求其实是冲突的。前面讲过，块存储主要是图快，一上分布式肯定严重拖后腿，既然都分布开了，节点之间的通信必然增加额外负担，再加上CAP，为了保持一致性牺牲响应速度，得到的好处就是扩展性。这就像把超跑弄个铁索连环，哪里还可能跑出高速?链条比车都重了，穿起来当火车开吗?
而文件存储原来也就是集装箱货车，大家连起来扮火车还是有可行性的。
三、块存储、文件存储、对象存储的层次关系
应用的角度聊过了，我们再看看这三种存储的一些技术细节，首先看看在系统层级的分布。

文章插图

我们从底层往上看，最底层就是硬盘，多个硬盘可以做成RAID组，无论是单个硬盘还是RAID组，都可以做成PV，多个PV物理卷捏在一起构成VG卷组，这就做成一块大蛋糕了。接下来，可以从蛋糕上切下很多块LV逻辑卷，这就到了存储用户最熟悉的卷这层。到这一层为止，数据一直都是以Block块的形式存在的，这时候提供出来的服务就是块存储服务。你可以通过FC协议或者iSCSI协议对卷访问，映射到主机端本地，成为一个裸设备。在主机端可以直接在上面安装数据库，也可以格式化成文件系统后交给应用程序使用，这时候就是一个标准的SAN存储设备的访问模式，网络间传送的是块。
如果不急着访问，也可以在本地做文件系统，之后以NFS/CIFS协议挂载，映射到本地目录，直接以文件形式访问，这就成了NAS访问的模式，在网络间传送的是文件。
如果不走NAS，在本地文件系统上面部署OSD服务端，把整个设备做成一个OSD，这样的节点多来几个，再加上必要的MDS节点，互联网另一端的应用程序再通过HTTP协议直接进行访问，这就变成了对象存储的访问模式。当然对象存储通常不需要专业的存储设备，前面那些LV/VG/PV层也可以统统不要，直接在硬盘上做本地文件系统，之后再做成OSD，这种才是对象存储的标准模式，对象存储的硬件设备通常就用大盘位的服务器。
从系统层级上来说，这三种存储是按照块->文件->对象逐级向上的。文件一定是基于块上面去做，不管是远端还是本地。而对象存储的底层或者说后端存储通常是基于一个本地文件系统(XFS/Ext4..) 。这样做是比较合理顺畅的架构。但是大家想法很多，还有各种特异的产品出现，我们逐个来看看：
对象存储除了基于文件，可以直接基于块，但是做这个实现的很少，毕竟你还是得把文件系统的活给干了，自己实现一套元数据管理，也挺麻烦的。另外对象存储还能基于对象存储，这就有点尴尬了，就是转一下，何必呢?但是这都不算最奇怪的，最奇怪的是把对象存储放在最底层，那就是这两年大红的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的块存储服务，则经过了硬盘(块)->文件->对象->块，也可能是硬盘(块)->对象->块的路径;再看看对象接口(虽然用的不多)，则是经过了硬盘(块)->文件->对象或者硬盘(块)->对象的路径。