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

集中系统最大的特点是部署结构简单。由于集中系统通常基于底层性能优异的大型主机，因此无需考虑如何在多个部分提供服务
不需要考虑多个节点之间的分布式合作。

分布式系统如何定义？这里引用一下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)故障总会发生
所有构成分布式系统的计算机都可能出现任何形式的故障。
大量工程实践的黄金定理是，在设计阶段考虑的任何异常情况都会发生在系统的实际运行中，在系统的实际运行中会遇到许多设计中没有考虑到的异常故障。因此，除非需求指标允许，否则在系统设计中不能错过任何异常情况
处理单点故障
在整个分布式系统中，如果角色或功能只由单机支撑，则该节点称为单点，其故障称为单点故障，通常称为
SPoF（Single Point of Failure）,避免单点故障的关键是将该功能从单机实现转变为集群实现。当然，这种变化通常很困难，否则
没有单点问题。如果单点不能集群实现，一般有两种选择：
(1)备份这个单点，出现问题时可以恢复，尽量自动恢复
(2)减少单点故障的影响范围
同的机房中

一般存储方案：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）该设计直接映射到文件名中，大大降低了存储元数据的内存空间；

FastDFS是中国人开发的分布式文件系统，目前社区活跃。系统中有三个节点:Client、Tracker、Storage,在底
层存储通过逻辑分组概念在同一组中配置多个Storage,从而实现软RAID10,提升并发IO性能、简单负载平衡和数据
冗余备份；同时，通过线性添加新的逻辑存储组，可以平静地实现存储容量的线性扩展。

除了支持文件下载外，文件下载还支持API目前还提供了方法apache和nginx插件支持，不能直接使用相应的插件Web静态资源
提供外部下载的方式。

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

特性
1)在上述介绍中Tracker服务器是整个系统的核心枢纽，完成了访问调度(负载均衡)、监控管理Storage由此可见服务器Tracker
的作用至关重要,也就增加了系统的单点故障,为此FastDFS支持多个备用Tracke,虽然实际测试发现备用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是一个高可用的故障容错分布式文件系统,它支持通过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是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是一个可以按对象/块/文件方式存储的开源分布式文件系统,其设计之初,就将单点故障作为首先要解决的问题,
因此该系统具备高可用性、高性能及可扩展等特点。该文件系统支持目前还处于试验阶段的高性能文件系统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/

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）

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

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是一个开源的分布式文件系统。因为它还支持块存储、对象存储，所以很自然的被用做云计算框架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 集群提供了整个存储系统的节点信息等全局的配置信息，通过 Paxos 算法保持数据的一致性。

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

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节点即为主节点，其余均为从节点。

什么是块设备？
块设备是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应用的存储。