Ceph存储

集中式存储

所谓集中式系统就是指由一台或多台主计算机组成中心节点,数据集中存储于这个中心节点中,并且整个系统的所有业务单元都集中
部署在这个中心节点上,系统所有的功能均由其集中处理。也就是说,集中式系统中,每个终端或客户端仅仅负责 数据的录入和
输出,而数据的存储与控制处理完全交由主机来完成。

集中式系统最大的特点就是部署结构简单,由于集中式系统往往基于底层性能卓越的大型主机,因此无需考虑如何对服务进行多个节
点的部署,也就不用考虑多个节点之间的分布式协作问题。

分布式存储

分布式系统如何定义？这里引用一下Distributed Systems Concepts and Design(Third Edition)中的一句话：“A distributed system is one in which components located at networked computers communicate and coordinate their actions only by passing messages”。从这句话里面
我们可以看到几个重点：
1、组件分布在网络计算机上
2、组件之间仅仅通过消息传递来通信并协调行动
严格讲,同一个分布式系统中的计算机在空间部署上是可以随意分布的,这些计算机可能被放在不同的机柜上,也可能在不甚至分布在不同的城市。无论如何,一个标准的分布式系统在没有任何特定业务逻辑约束的情况下,都会有以下几个特征：
1)、分布性
分布式系统中的多台计算机都会在空间上随意分布,同时,及其的分布情况也会随时变动
2)、对等性
分布式系统中的计算机没有主/从之分,既没有控制整个系统的主机,也没有被控制的从机,组成分布式系统的所有节点都是对等的。副
本（Replica）是分布式系统最常见的概念之一,指的是分布式系统对数据和服务提供的一种冗余方式。在 常见的分布式系统中,为了对
外提高可用的服务,我们往往会对数据和服务进行副本处理。数据副本是指在不同的节点上持久化同一份数据,当某一个节点上存储的
数据丢失时,可以从副本上读取到该数据,这是解决分布式系统数据丢失问题最为有效的手段。另一类副本是服务副本,指多个节点提
供同样的服务,每个节点都有 能力接收来自外部的请求并进行相应的处理
3)、并发性
在一个计算机网络中,程序运行过程中的并发性操作是非常常见的行为,例如同一个分布式系统的多个节点,可能会并发地操作一些共享
的资源,诸如数据库或分布式存储等,如何准确并高效地协调分布式并发操作也成为了分布式系统架构与设计中最大的挑战之一
4)、缺乏全局时钟
一个典型的分布式系统是由一系列空间上随意分布的多个进程组成的,具有明显的分布性,这些进程之间通过交换消息来进行相互通信。
因此,在分布式系统中,很难定义两个事件究竟谁先谁后,原因就是因为分布式系统缺乏一个全局的时钟控制序列
5)、故障总是会发生
组成分布式系统的所有计算机,都有可能发生任何形式的故障。
一个被大量工程实践过的黄金定理是：任何在设计阶段考虑到的异常情况一定会在系统实际运行中发生,并且,在系统实际运行中还会遇到很多在设计时未考虑到的异常故障。所以,除非需求指标允许,在系统设计时不能放过任何异常情况
6)、处理单点故障
在整个分布式系统中,如果某个角色或者功能只有某台单机在支撑,那么这个节点称为单点,其发生的故障称为单点故障,也就是通常说的
SPoF（Single Point of Failure）,避免单点故障的关键就是把这个功能从单机实现变为集群实现,当然,这种变化一般会比较困难,否则就
不会有单点问题了。如果不能把单点变为集群实现,那么一般还有两种选择：
（1）给这个单点做好备份,能够在出现问题时进行恢复,并且尽量做到自动恢复
（2）降低单点故障的影响范围
同的机房中

分布式系统的意义
从单机单用户到单机多用户,再到现在的网络时代,应用系统发生了很多的变化。而分布式系统依然是目前很热门的讨论话题,那么,分布
式系统给我们带来了什么,或者说是为什么要有分布式系统呢？从三方面考虑：
1、升级单机处理能力的性价比越来越低
摩尔定律：当价格不变时,每隔18个月,集成电路上可容纳的晶体管数目会增加一倍,性能也将提升一倍。这个定律告诉我们,随着时间
的推移,单位成本的支出所能购买的计算机能力在提升。不过,如果我们把时间固定下来 ,也就是固定在某个具体时间点来购买单颗不同
型号的处理器,那么所购买的处理器性能越高,所要付出的成本就越高,性价比就越低。那么,也就是说在一个确定的时间点,通过更换
硬件做垂直扩展的方式来提升性能会越来越不划算
2、单机处理能力存在瓶颈
某个固定时间点,单颗处理器有自己的性能瓶颈,也就说即使愿意花更多的钱去买计算能力也买不到了
3、出于稳定性和可用性的考虑
如果采用单击系统,那么在这台机器正常的时候一切OK,一旦出问题,那么系统就完全不能用了。当然,可以考虑做容灾备份等方案,而
这些方案就会让系统演变为分布式系统了,传统的网络存储系统采用集中的存储服务器存放所有数据,存储服务器成为系统性能的瓶颈,也是可靠性和安全性的焦点,不能满足大规模存储应用的需要。分布式网络存储系统采用可扩展的系统结构,利用多台存储服务器分担存储负荷,利用位置服务器定位存储信息,它不但提高了系统的可靠性、可用性和存取效率,还易于扩展。

主流分布式存储对比

普通存储方案：DAS(IDE/SATA/SAS/SCSI等块)、NAS(NFS、CIFS、SAMBA等文件系统)、SAN(FibreChannel, iSCSI, FoE存储网络块),Openfiler、FreeNas(ZFS快照复制)
由于生产环境中往往由于对存储数据量很大,而SAN存储价格又比较昂贵,因此大多会选择分布式存储来解决以下问题：
1. 海量数据存储问题
2. 数据高可用问题(冗余备份)问题
3. 较高的读写性能和负载均衡问题
4. 支持多平台多语言问题
5. 高并发问题

主流分布式存储对比：

主流分布式存储介绍

开源协议说明
GPL: 不允许修改后和衍生的代码做为闭源的商业软件发布和销售,修改后该软件产品必须也采用GPL协议；
GPLV2：修改文本的整体就必须按照GPL流通,不仅该修改文本的源码必须向社会公开,而且对于这种修改文本的流通不准许附加
修改者自己作出的限制;
GPLV3：要求用户公布修改的源代码,还要求公布相关硬件;
LGPL：更宽松的GPL

TFS
TFS（Taobao File System）是由淘宝开发的一个分布式文件系统,其内部经过特殊的优化处理,适用于海量的小文件存储,目前
已经对外开源；
TFS采用自有的文件系统格式存储,因此需要专用的API接口去访问,目前官方提供的客户端版本有：C++/JAVA/PHP。

特性
1）在TFS文件系统中,NameServer负责管理文件元数据,通过HA机制实现主备热切换,由于所有元数据都是在内存中,其处理效
率非常高效,系统架构也非常简单,管理也很方便；
2）TFS的DataServer作为分部署数据存储节点,同时也具备负载均衡和冗余备份的功能,由于采用自有的文件系统,对小文件会采
取合并策略,减少数据碎片,从而提升IO性能；
3）TFS将元数据信息（BlockID、FileID）直接映射至文件名中,这一设计大大降低了存储元数据的内存空间；

优点
1）针对小文件量身定做,随机IO性能比较高；
2）支持在线扩容机制,增强系统的可扩展性；
3）实现了软RAID,增强系统的并发处理能力及数据容错恢复能力；
4）支持主备热切换,提升系统的可用性；
5）支持主从集群部署,其中从集群主要提供读/备功能；
缺点
1）TFS只对小文件做优化,不适合大文件的存储；
2）不支持POSIX通用接口访问,通用性较低；
3）不支持自定义目录结构,及文件权限控制；
4）通过API下载,存在单点的性能瓶颈；
5）官方文档非常少,学习成本高；

应用场景
1）多集群部署的应用
2）存储后基本不做改动
3）海量小型文件
根据目前官方提供的材料,对单个集群节点,存储节点在1000台以内可以良好工作,如存储节点扩大可能会出现NameServer的性能
瓶颈,目前淘宝线上部署容量已达到1800TB规模（2009年数据）

源代码路径：http://code.taobao.org/p/tfs/src/

FastDFS

FastDFS是国人开发的一款分布式文件系统,目前社区比较活跃。系统中存在三种节点：Client、Tracker、Storage,在底
层存储上通过逻辑的分组概念,使得通过在同组内配置多个Storage,从而实现软RAID10,提升并发IO的性能、简单负载均衡及数据的
冗余备份；同时通过线性的添加新的逻辑存储组,从容实现存储容量的线性扩容。

文件下载上,除了支持通过API方式,目前还提供了apache和nginx的插件支持,同时也可以不使用对应的插件,直接以Web静态资源
方式对外提供下载。

目前FastDFS(V4.x)代码量大概6w多行,内部的网络模型使用比较成熟的libevent三方库,具备高并发的处理能力。

特性
1）在上述介绍中Tracker服务器是整个系统的核心枢纽,其完成了访问调度（负载均衡）,监控管理Storage服务器,由此可见Tracker
的作用至关重要,也就增加了系统的单点故障,为此FastDFS支持多个备用的Tracker,虽然实际测试发现备用Tracker运行不是非常
完美,但还是能保证系统可用。
2）在文件同步上,只有同组的Storage才做同步,由文件所在的源Storage服务器push至其它Storage服务器,目前同步是采用Binlog方式
实现,由于目前底层对同步后的文件不做正确性校验,因此这种同步方式仅适用单个集群点的局部内部网络,如果在公网上使用,
肯定会出现损坏文件的情况,需要自行添加文件校验机制。
3）支持主从文件,非常适合存在关联关系的图片,在存储方式上,FastDFS在主从文件ID上做取巧,完成了关联关系的存储。

优点
1）系统无需支持POSIX(可移植操作系统),降低了系统的复杂度,处理效率更高
2）支持在线扩容机制,增强系统的可扩展性
3）实现了软RAID,增强系统的并发处理能力及数据容错恢复能力
4）支持主从文件,支持自定义扩展名
5）主备Tracker服务,增强系统的可用性

缺点
1）不支持断点续传,对大文件将是噩梦（FastDFS不适合大文件存储）
2）不支持POSIX通用接口访问,通用性较低
3）对跨公网的文件同步,存在较大延迟,需要应用做相应的容错策略
4）同步机制不支持文件正确性校验,降低了系统的可用性
5）通过API下载,存在单点的性能瓶颈

应用场景
1）单集群部署的应用
2）存储后基本不做改动
3）小中型文件根据
目前官方提供的材料,现有的使用FastDFS系统存储容量已经达到900T,物理机器已经达到100台（50个组）

源码路径：https://github.com/happyfish100/fastdfs

MooseFS

MooseFS是一个高可用的故障容错分布式文件系统,它支持通过FUSE方式将文件挂载操作,同时其提供的web管理界面非常方便
查看当前的文件存储状态。

特性
1）从下图中我们可以看到MooseFS文件系统由四部分组成：Managing Server 、Data Server 、Metadata Backup Server 及Client
2）其中所有的元数据都是由Managing Server管理,为了提高整个系统的可用性,MetadataBackup Server记录文件元数据操作日
志,用于数据的及时恢复
3）Data Server可以分布式部署,存储的数据是以块的方式分布至各存储节点的,因此提升了系统的整体性能,同时Data Server
提供了冗余备份的能力,提升系统的可靠性
4）Client通过FUSE方式挂载,提供了类似POSIX的访问方式,从而降低了Client端的开发难度,增强系统的通用性

元数据服务器（master）:负责各个数据存储服务器的管理,文件读写调度,文件空间回收以及恢复
元数据日志服务器（metalogger）:负责备份master服务器的变化日志文件,以便于在master server出问题的时候接替其进行工作
数据存储服务器（chunkserver）:数据实际存储的地方,由多个物理服务器组成,负责连接管理服务器,听从管理服务器调度,提
供存储空间,并为客户提供数据传输；多节点拷贝;在数据存储目录,看不见实际的数据

优点
1）部署安装非常简单,管理方便
2）支持在线扩容机制,增强系统的可扩展性
3）实现了软RAID,增强系统的 并发处理能力及数据容错恢复能力
4）数据恢复比较容易,增强系统的可用性5）有回收站功能,方便业务定制

缺点
1）存在单点性能瓶颈及单点故障
2）MFS Master节点很消耗内存
3）对于小于64KB的文件,存储利用率较低

应用场景
1）单集群部署的应用
2）中、大型文件

GlusterFS

GlusterFS是Red Hat旗下的一款开源分布式文件系统,它具备高扩展、高可用及高性能等特性,由于其无元数据服务器的设计,
使其真正实现了线性的扩展能力,使存储总容量可轻松达到PB级别,支持数千客户端并发访问；对跨集群,其强大的Geo-Replication
可以实现集群间数据镜像,而且是支持链式复制,这非常适用于垮集群的应用场景

特性
1）目前GlusterFS支持FUSE方式挂载,可以通过标准的NFS/SMB/CIFS协议像访问本体文件一样访问文件系统,同时其也支持
HTTP/FTP/GlusterFS访问,同时最新版本支持接入Amazon的AWS系统
2）GlusterFS系统通过基于SSH的命令行管理界面,可以远程添加、删除存储节点,也可以监控当前存储节点的使用状态
3）GlusterFS支持集群节点中存储虚拟卷的扩容动态扩容；同时在分布式冗余模式下,具备自愈管理功能,在Geo冗余模式下,文件
支持断点续传、异步传输及增量传送等特点

优点
1）系统支持POSIX(可移植操作系统),支持FUSE挂载通过多种协议访问,通用性比较高
2）支持在线扩容机制,增强系统的可扩展性
3）实现了软RAID,增强系统的 并发处理能力及数据容错恢复能力
4）强大的命令行管理,降低学习、部署成本
5）支持整个集群镜像拷贝,方便根据业务压力,增加集群节点
6）官方资料文档专业化,该文件系统由Red Hat企业级做维护,版本质量有保障

缺点
1）通用性越强,其跨越的层次就越多,影响其IO处理效率
2）频繁读写下,会产生垃圾文件,占用磁盘空间

应用场景
1）多集群部署的应用
2）中大型文件根据目前官方提供的材料,现有的使用GlusterFS系统存储容量可轻松达到PB

术语：
brick：分配到卷上的文件系统块；
client：挂载卷,并对外提供服务；
server：实际文件存储的地方；
subvolume：被转换过的文件系统块；
volume：最终转换后的文件系统卷。

Ceph

Ceph是一个可以按对象/块/文件方式存储的开源分布式文件系统,其设计之初,就将单点故障作为首先要解决的问题,
因此该系统具备高可用性、高性能及可扩展等特点。该文件系统支持目前还处于试验阶段的高性能文件系统BTRFS(B-Tree
文件系统),同时支持按OSD方式存储,因此其性能是很卓越的, 因为该系统处于试商用阶段,需谨慎引入到生产环境

特性
1）Ceph底层存储是基于RADOS（可靠的、自动的分布式对象存储）,它提供了LIBRADOS/RADOSGW/RBD/CEPHFS方式
访问底层的存储系统
2）通过FUSE,Ceph支持类似的POSIX访问方式；Ceph分布式系统中最关键的MDS节点是可以部署多台,无单点故障的
问题,且处理性能大大提升
3）Ceph通过使用CRUSH算法动态完成文件inode number到object number的转换,从而避免再存储文件metadata信息,
增强系统的灵活性

优点
1）支持对象存储（OSD）集群,通过CRUSH算法,完成文件动态定位, 处理效率更高
2）支持通过FUSE方式挂载,降低客户端的开发成本,通用性高
3）支持分布式的MDS/MON,无单点故障
4）强大的容错处理和自愈能力
5）支持在线扩容和冗余备份,增强系统的可靠性

缺点
1）目前处于试验阶段,系统稳定性有待考究

应用场景
1）全网分布式部署的应用
2）对实时性、可靠性要求比较高. 官方宣传,存储容量可轻松达到PB级别

源码路径：https://github.com/ceph/ceph
参考： http://ceph.com/

Ceph分布式存储

1、概述
Ceph是可靠的、可扩展的、统一的、开源分布式的存储系统。
Ceph是一个统一的分布式存储系统，设计初衷是提供较好的性能、可靠性和可扩展性。
Ceph项目最早起源于Sage就读博士期间的工作（最早的成果于2004年发表）,并随后贡献给开源社区。
在经过了数年的发展之后,目前已得到众多云计算厂商的支持并被广泛应用。RedHat及OpenStack都可与Ceph整合以支持虚拟机镜像
的后端存储。

不管你是想为云平台提供Ceph 对象存储和/或 Ceph 块设备,还是想部署一个 Ceph 文件系统或者把 Ceph 作为他用,所有 Ceph 存储
集群的部署都始于部署一个个 Ceph 节点、网络和 Ceph 存储集群。

Ceph 存储集群至少需要一个 Ceph Monitor 和两个 OSD 守护进程。运行Ceph文件系统客户端时,则必须要有元数据服务器（ MDS ）。

Ceph可提供以下三种功能:
• 对象存储RADOSGW（Reliable、Autonomic、Distributed、Object Storage Gateway）
• 块存储RBD（Rados Block Device）
• 文件系统存储Ceph FS（Ceph Filesystem）

2、Ceph 优点

• 统一存储 - 虽然ceph底层是一个分布式文件系统，但由于在上层开发了支持对象和块的接口。所以在开源存储软件中，能够一统江湖。
• 高扩展性 - 扩容方便、容量大。能够管理上千台服务器、EB级的容量。
• 可靠性强 - 支持多份强一致性副本。副本能够垮主机、机架、机房、数据中心存放, 安全可靠。
存储节点可以自管理、自动修复。无单点故障，容错性强。
• 性能高 - 因为是多个副本，因此在读写操作时候能够做到高度并行化。理论上，节点越多，整个集群的IOPS和吞吐量越高。
ceph客户端读写数据直接与存储设备(osd) 交互。

3、Ceph应用场景

Ceph可以提供对象存储、块设备存储和文件系统服务，其对象存储可以对接网盘（owncloud）应用业务等；
其块设备存储可以对接（IaaS），当前主流的IaaS运平台软件，如：OpenStack、CloudStack、Zstack、Eucalyptus等以及kvm等。

4、Ceph的核心组件

Ceph的核心组件包括Ceph OSD、Ceph Monitor和Ceph MDS。

Ceph OSD
OSD的英文全称是Object Storage Device,它的主要功能是存储数据、复制数据、平衡数据、恢复数据等,与其它OSD间进行心跳
检查等, 并将一些变化情况上报给Ceph Monitor。一般情况下一块硬盘对应一个OSD,由OSD来对硬盘存储进行管理,当然一个
分区也可以成为一个OSD。

Ceph OSD的架构实现由物理磁盘驱动器、Linux文件系统和Ceph OSD服务组成,对于Ceph OSD Deamon而言,Linux文件系统显
的支持了 ,其拓展性,一般Linux文件系统有好几种,比如有BTRFS、XFS、Ext4等,BTRFS虽然有很多优点特性,但现在还没达到
生产环境所需的稳定性,一般比较推荐使用XFS。

当 Ceph 存储集群设定为有2个副本时，至少需要2个OSD守护进程，集群才能达到 active+clean 状态(Ceph 默认有3个副本，但你可以调整副本数)

Ceph Monitor
由该英文名字我们可以知道它是一个监视器,负责监视Ceph集群,维护Ceph集群的健康状态,同时维护着Ceph集群中的各种Map
图,比如OSD Map、Monitor Map、PG Map和CRUSH Map,这些Map统称为Cluster Map,Cluster Map是RADOS的关键数据结构,管
理集群中的所有成员、关系、属性等信息以及数据的分发,比如当用户需要存储数据到Ceph集群时,OSD需要先通过Monitor获取
最新的Map图,然后根据Map图和object id等计算出数据最终存储的位置。

Ceph MDS
全称是Ceph MetaData Server,主要保存的文件系统服务的元数据,但对象存储和块存储设备是不需要使用该服务的。
Ceph 元数据服务器（ MDS ）为 Ceph 文件系统存储元数据（也就是说，Ceph 块设备和 Ceph 对象存储不使用MDS ）。
元数据服务器使得 POSIX 文件系统的用户们，可以在不对 Ceph 存储集群造成负担的前提下，执行诸如 ls、find 等基本命令。

Ceph存储

Ceph是一个开源的分布式文件系统。因为它还支持块存储、对象存储，所以很自然的被用做云计算框架openstack或cloudstack整个存储后端。
当然也可以单独作为存储，例如部署一套集群作为对象存储、SAN存储、NAS存储等。

块设备速度快，对存储的数据没有进行组织管理，用户数据读写不方便（以块设备位置offset + 数据的length来记录数据位置，读写数据）。
在块设备上构建了文件系统后，文件系统帮助块设备组织管理数据，数据存储对用户更加友好（以文件名来读写数据）。
Ceph文件系统接口解决了“Ceph块设备+本地文件系统”不支持多客户端共享读写的问题，但由于文件系统结构的复杂性导致了存储性能较Ceph块设备差。
对象存储接口是一种折中，保证一定的存储性能，同时支持多客户端共享读写

ceph在开源社区还是比较热门的，但是更多的是应用于云计算的后端存储。
所以大多数在生产环境中使用ceph的公司都会有专门的团队对ceph进行二次开发，ceph的运维难度也比较大。
但是经过合理的优化之后，ceph的性能和稳定性都是值得期待的。

服务端 RADOS (Reliable, Autonomic Distributed Object Store) 集群主要由两种节点组成：
• 一种是为数众多的、负责完成数据存储和维护功能的OSD（Object Storage Device）
• 另一种则是若干个负责完成系统状态检测和维护的monitor。

Monitor

Monitor 集群提供了整个存储系统的节点信息等全局的配置信息，通过 Paxos 算法保持数据的一致性。

OSD

OSD是负责物理存储的进程,一般配置成和磁盘一一对应,一块磁盘启动一个OSD进程

Pool, PG(placement group)

Pool - 存储池, 存储对象的逻辑分区,它规定了数据冗余的类型和对应的副本分布策略
支持两种类型：副本（replicated）和 纠删码（ Erasure Code）
PG - 归置组, 是一个放置策略组,它是对象的集合,该集合里的所有对象都具有相同的放置策略；
相同PG内的对象都会放到相同的硬盘上； PG是 ceph的核心概念, 服务端数据均衡和恢复的最小粒度就是PG

下面这张图形象的描绘了它们之间的关系：

• 一个Pool里有很多PG,
• 一个PG里包含一堆对象；一个对象只能属于一个PG；
• PG有主从之分,一个PG分布在不同的OSD上

无论使用哪种存储方式（对象、块、挂载），存储的数据都会被切分成对象（Objects）。Objects size大小可以由管理员调整，通常为2M或4M。
每个对象都会有一个唯一的OID，由ino与ono生成，虽然这些名词看上去很复杂，其实相当简单:
ino即是文件的File ID，用于在全局唯一标示每一个文件，而ono则是分片的编号。
比如：一个文件FileID为A，它被切成了两个对象，一个对象编号0，另一个编号1，那么这两个文件的oid则为A0与A1。
Oid的好处是可以唯一标示每个不同的对象，并且存储了对象与文件的从属关系。
由于ceph的所有数据都虚拟成了整齐划一的对象，所以在读写时效率都会比较高。

但是对象并不会直接存储进OSD中，因为对象的size很小，在一个大规模的集群中可能有几百到几千万个对象。
这么多对象光是遍历寻址，速度都是很缓慢的。
如果将对象直接通过某种固定映射的哈希算法映射到osd上，当这个osd损坏时，对象无法自动迁移至其他osd上面（因为映射函数不允许）。

为了解决这些问题，ceph引入了归置组的概念，即PG。
PG是一个逻辑概念，我们linux系统中可以直接看到对象，但是无法直接看到PG。
每个对象都会固定映射进一个PG中，所以当我们要寻找一个对象时，只需要先找到对象所属的PG，然后遍历这个PG就可以了，无需遍历所有对象。
而且在数据迁移时，也是以PG作为基本单位进行迁移，ceph不会直接操作对象。

对象时如何映射进PG的？
还记得OID么？首先使用静态hash函数对OID做hash取出特征码，用特征码与PG的数量取模，得到的序号则是PGID。

由于这种设计方式，PG的数量多寡直接决定了数据分布的均匀性，所以合理设置的PG数量可以很好的提升CEPH集群的性能并使数据均匀分布。
PG会根据管理员设置的副本数量进行复制，然后通过crush算法存储到不同的OSD节点上（其实是把PG中的所有对象存储到节点上），第一个osd节点即为主节点，其余均为从节点。

Ceph块存储

什么是块设备？
块设备是i/o设备中的一类，是将信息存储在固定大小的块中，每个块都有自己的地址，还可以在设备的任意位置读取一定长度的数据。
看不懂？那就暂且认为块设备就是硬盘或虚拟硬盘吧。

查看下Linux环境中的设备：
[root@ceph ~] ls /dev/
/dev/sda /dev/sda1 /dev/sda2 /dev/sdb /dev/sdb1 /dev/hda
/dev/rbd1 /dev/rbd2 …

上面的/dev/sda、/dev/sdb和/dev/hda都是块设备文件，这些文件是怎么出现的呢？
当给计算机连接块设备（硬盘）后，系统检测的有新的块设备，该类型块设备的驱动程序就在/dev/下创建个对应的块设备设备文件
用户可以通过设备文件使用该块设备

它们怎么有的叫 sda？有的叫 sdb？有的叫 hda？
以sd开头的块设备文件对应的是SATA接口的硬盘，而以hd开头的块设备文件对应的是IDE接口的硬盘。

那SATA接口的硬盘跟IDE接口的硬盘有啥区别？
你只需要知道，IDE接口硬盘已经很少见到了，逐渐被淘汰中，而SATA接口的硬盘是目前的主流。

而sda和sdb的区别呢？
当系统检测到多个SATA硬盘时，会根据检测到的顺序对硬盘设备进行字母顺序的命名。
PS：系统按检测顺序命名硬盘会导致了盘符漂移的问题。

怎么还有的叫 rbd1 和 rbd2 呢?
被你发现了，rbd就是我们压轴主角了。rbd就是由Ceph集群提供出来的块设备。
可以这样理解，sda和hda都是通过数据线连接到了真实的硬盘，而rbd是通过网络连接到了Ceph集群中的一块存储区域，往rbd设备文件写入数据，最终会被存储到Ceph集群的这块区域中。

针对多种多样的使用场景，衍生出了很多的文件系统。有的文件系统能够提供更好的读性能，有的文件系统能提供更好的写性能。
我们平时常用的文件系统如xfs、ext4是读写性能等各方面比较均衡的通用文件系统。

然而，很多应用往往并不需要这种均衡，而需要突出某一方面的性能，如小文件的存储性能。
此时，xfs、ext4等通用文件系统如果不能满足应用的需求，应用往往会在裸设备上实现自己的数据组织和管理方式。
简单的说，就是应用为了强化某种存储特性而实现自己定制的数据组织和管理方式，而不使用通用的文件系统。

Ceph块设备接口怎么使用？
在Ceph集群中创建块设备：
rbd create -s 1G myrbd # 保证/etc/ceph目录下有Ceph集群的配置文件ceph.conf和ceph.client.admin.keyring

在用户机上挂载该Ceph块设备，可以理解为往用户机上插入硬盘：
rbdmap myrbd # 输出: /dev/rbd1

将Ceph块设备格式化成文件系统并挂载：
mkfs.xfs /dev/rbd1
mkdir -p /mnt/ceph_rbd
mount /dev/rbd1 /mnt/ceph_rbd

通过/mnt/ceph_rbd读写数据，都是在读写Ceph集群中该块设备对应的存储区域

总结一下，块设备可理解成一块硬盘，用户可以将其格式化成特定的文件系统，由文件系统来组织管理存储空间，从而为用户提供丰富而友好的数据操作支持。

文件系统存储

还记得上面说的块设备上的文件系统吗，用户可以在块设备上创建xfs文件系统，也可以创建ext4等其他文件系统。
Ceph集群实现了自己的文件系统来组织管理集群的存储空间，用户可以直接将Ceph集群的文件系统挂载到用户机上使用。
下图为ceph三种存储的对比:

Ceph有了块设备接口，在块设备上完全可以构建一个文件系统，那么Ceph为什么还需要文件系统接口呢？
主要是因为应用场景的不同，Ceph的块设备具有优异的读写性能，但不能多处挂载同时读写，目前主要用在OpenStack上作为虚拟磁盘
Ceph的文件系统接口读写性能较块设备接口差，但具有优异的共享性。

PS：想了解更多？快去查查SAN和NAS。

为什么Ceph的块设备接口不具有共享性，而Ceph的文件系统接口具有呢？
对于Ceph的块设备接口，如下图, 文件系统的结构状态是维护在各用户机内存中的
假设Ceph块设备同时挂载到了用户机1和用户机2，当在用户机1上写入数据后，更新了用户机1的内存中文件系统状态，最终数据存储到了Ceph集群中
但此时用户机2内存中的文件系统并不能得知底层Ceph集群数据已经变化而维持数据结构不变，因此用户无法从用户机2上读取用户机1上新写入的数据。

Ceph的文件系统接口使用方式?
将Ceph的文件系统挂载到用户机目录
mkdir -p /mnt/ceph_fuse
ceph-fuse /mnt/ceph_fuse

大功告成，在/mnt/ceph_fuse下读写数据，都是读写远程Ceph集群

总结一下，Ceph的文件系统接口弥补了Ceph的块设备接口在共享性方面的不足，Ceph的文件系统接口符合POSIX标准，用户可以像使用本地存储目录一样使用Ceph的文件系统的挂载目录。还是不懂？这样理解吧，无需修改你的程序，就可以将程序的底层存储换成空间无限并可多处共享读写的Ceph集群文件系统。

对象存储

首先，通过下图来看下对象存储接口是怎么用的
简单了说，使用方式就是通过http协议上传下载删除对象（文件即对象）。

老问题来了，有了块设备接口存储和文件系统接口存储，为什么还整个对象存储呢?
往简单了说，Ceph的块设备存储具有优异的存储性能但不具有共享性，而Ceph的文件系统具有共享性然而性能较块设备存储差
为什么不权衡一下存储性能和共享性，整个具有共享性而存储性能好于文件系统存储的存储呢? 对象存储就这样出现了。

对象存储为什么性能会比文件系统好？
原因是多方面的，主要原因是对象存储组织数据的方式相对简单，只有bucket和对象两个层次（对象存储在bucket中），对对象的操作也相对简单。
而文件系统存储具有复杂的数据组织方式，目录和文件层次可具有无限深度，对目录和文件的操作也复杂的多，因此文件系统存储在维护文件系统的结构数据时会更加繁杂，从而导致文件系统的存储性能偏低。

存储空间（Bucket）所谓的桶
存储空间是用于存储对象（Object）的容器，所有的对象都必须隶属于某个存储空间。
您可以设置和修改存储空间属性用来控制地域、访问权限、生命周期等，这些属性设置直接作用于该存储空间内所有对象
可以通过灵活创建不同的存储空间来完成不同的管理功能。
​
同一个存储空间的内部是扁平的，没有文件系统的目录等概念，所有的对象都直接隶属于其对应的存储空间。
每个用户可以拥有多个存储空间
存储空间的名称在 OSS 范围内必须是全局唯一的，一旦创建之后无法修改名称。
存储空间内部的对象数目没有限制。
​
存储空间的命名规范如下：
只能包括小写字母、数字和短横线（-）。
必须以小写字母或者数字开头和结尾。
长度必须在3-63字节之间

Ceph的对象存储接口怎么用呢？
Ceph的对象接口符合亚马逊S3接口标准和OpenStack的Swift接口标准，可以自行学习这两种接口。

总结一下
文件系统存储具有复杂的数据组织结构，能够提供给用户更加丰富的数据操作接口，而对象存储精简了数据组织结构，提供给用户有限的数据操作接口，以换取更好的存储性能。对象接口提供了REST API，非常适用于作为web应用的存储。