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

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

分布式系统如何定义？这里引用一下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)减少单点故障的影响范围

百度：
分布式存储是一种数据存储技术，利用企业每台机器上的磁盘空间，将这些分散的存储资源构成虚拟存储设备，
数据分散存储在企业的各个角落.

分布式系统的意义
从单用户到单用户，再到当前的网络时代，应用系统发生了很大的变化。分布式系统仍然是一个热门的讨论话题，所以，分布式系统
公式系统给我们带来了什么，或者为什么要有分布式系统？从三个方面考虑：

ceph官方文档 http://docs.ceph.org.cn/
ceph中文开源社区 http://ceph.org.cn/

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）

什么是块设备？
块设备是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集群中的
Ceph文件系统同时挂载到了用户机1和用户机2，当往用户机1的挂载点写入数据后，远端Ceph集群中的文件系统状态结构随之更新
当从用户机2的挂载点访问数据时会去远端Ceph集群取数据，由于远端Ceph集群已更新，所有用户机2能够获取最新的数据。

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应用的存储。

块设备速度快，对存储的数据没有进行组织管理，用户数据读写不方便（以块设备位置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节点即为主节点，其余均为从节点。

准备五台机器

monitor 192.168.23.237
osd1 192.168.23.233
osd2 192.168.23.234
osd3 192.168.23.235
client 192.168.23.236

1. 在node节点上准备osd
把3个osd挂载到sdb上

继续挂在并设置开机启动

2. 在管理节点上配置对其他节点免密登录
在monitor端配置

[root@monitor ~]# ssh-copy-id osd1;ssh-copy-id osd2;ssh-copy-id osd3

3. 在管理节点上安装ceph部署工具ceph-deploy

[root@monitor ~]# vim /etc/yum.repos.d/ceph.repo
[Ceph]
name=Ceph packages for $basearch
baseurl=https://mirrors.aliyun.com/ceph/rpm-jewel/el7/x86_64/
enabled=1
gpgcheck=0
type=rpm-md
priority=1

[Ceph-noarch]
name=Ceph noarch packages
baseurl=https://mirrors.aliyun.com/ceph/rpm-jewel/el7/noarch/
enabled=1
gpgcheck=0
type=rpm-md
priority=1

[Ceph-source]
name=Ceph source packages
baseurl=https://mirrors.aliyun.com/ceph/rpm-jewel/el7/SRPMS/
enabled=1
gpgcheck=0
type=rpm-md
priority=1

[Ceph-aarch64]
name=Ceph aarch64 packages
baseurl=https://mirrors.aliyun.com/ceph/rpm-jewel/el7/aarch64/
enabled=1
gpgcheck=0
type=rpm-md

[root@monitor ~]# scp /etc/yum.repos.d/ceph.repo node1:/etc/yum.repos.d/  
[root@monitor ~]# scp /etc/yum.repos.d/ceph.repo node2:/etc/yum.repos.d/  
[root@monitor ~]# scp /etc/yum.repos.d/ceph.repo node3:/etc/yum.repos.d/  

3.2. 创建monitor服务(仅管理节点)

[root@monitor ~]# yum install -y ceph-deploy
[root@monitor ~]# mkdir /etc/ceph
[root@monitor ~]# cd /etc/ceph/
[root@monitor ceph]# ceph-deploy new monitor

[root@monitor ceph]# vim ceph.conf

4. 查看配置文件

osd_pool_default_size = 2    # 配置文件的默认副本数从3改成2，这样只有两个osd也能达到active+clean状态

5. 在所有节点安装ceph(在管理节点操作)

yum -y install ceph

6. 配置初始 monitor(s)、并收集所有密钥(仅管理节点)

[root@monitor ceph]# ceph-deploy mon create-initial
[root@monitor ceph]# ls
ceph.bootstrap-mds.keyring  ceph.bootstrap-rgw.keyring  ceph-deploy-ceph.log
ceph.bootstrap-mgr.keyring  ceph.client.admin.keyring   ceph.mon.keyring
ceph.bootstrap-osd.keyring  ceph.conf                   rbdmap

7. 激活第1步中的OSD
7.1 准备OSD(管理节点操作

[root@monitor ceph]# ceph-deploy osd prepare osd1:/mnt/osd osd2:/mnt/osd osd3:/mnt/osd

7.2 修改OSD属主属组(所有OSD节点)

7.3 激活OSD(管理节点操作)

[root@monitor ceph]# ceph-deploy osd activate osd1:/mnt/osd osd2:/mnt/osd osd3:/mnt/osd

[root@monitor ceph]# ceph-deploy osd list osd{ 
        1..3}

8.统一配置

用 ceph-deploy 把配置文件和 admin 密钥拷贝到管理节点和 Ceph 节点

这样每次执行 Ceph 命令行时就无需指定 monitor 地址和 ceph.client.admin.keyring 了

[root@monitor ceph]# ceph-deploy admin osd1 osd2 osd3 #admin是命令

检查集群的健康状况

[root@monitor ceph]# ceph health
HEALTH_OK

Ceph 块设备靠无限伸缩性提供了高性能，如向内核模块、或向 abbr:KVM (kernel virtual machines) （如 Qemu 、 OpenStack 和 CloudStack 等云计算系统通过 libvirt 和 Qemu 可与 Ceph 块设备集成）。你可以用同一个集群同时运行 Ceph RADOS 网关、 Ceph FS 文件系统、和 Ceph 块设备。

要使用 Ceph 块设备，你必须有一个在运行的 Ceph 集群

要使用 Ceph 块设备命令，你必须有对应集群的访问权限

1. 在管理节点上将 配置文件和密钥环拷贝到client

[root@monitor ceph]# scp /etc/yum.repos.d/ceph.repo 192.168.23.236:/etc/yum.repos.d
[root@monitor ceph]# yum -y install ceph
[root@monitor ceph]# ceph-deploy admin 192.168.23.236

2. 修改密钥文件的权限

[root@client ceph]# chown -R ceph.ceph /etc/ceph
[root@client ceph]# chmod +r ceph.client.admin.keyring

使用块存储
在 client 节点上操作

1. 创建存储池

语法: ceph osd pool create { 
        pool-name} { 
        pg-num}
参数说明:    
    pool-name : 存储池名称,必须唯一。
    pg-num : 存储池拥有的归置组总数。

下面是pg-num几个常用的值：
• 少于 5 个 OSD 时可把 pg_num 设置为 128
• OSD 数量在 5 到 10 个时，可把 pg_num 设置为 512
• OSD 数量在 10 到 50 个时，可把 pg_num 设置为 4096
• OSD 数量大于 50 时，你得理解权衡方法、以及如何自己计算 pg_num 取值
• 自己计算 pg_num 取值时可借助 pgcalc 工具. 随着OSD数量的增加，正确的 pg_num 取值变得更加重要，
因为它显著地影响着集群的行为、以及出错时的数据持久性(即灾难事件导致数据丢失的概率)。

2. 创建块设备映像 {pool-name}/{image-name}

# 指定 features: layering，否则 map 可能出错
# 也可以将 rbd_default_features = 1 添加到 /etc/ceph/ceph.conf 的 [global]
# 如果创建映像时不指定存储池，它将使用默认的 rbd 存储池

[root@monitor ceph]# ceph osd pool create mypool 128
pool 'mypool' created
[root@monitor ceph]# rbd create --size 1024 mypool/myimage --image-feature layering
[root@monitor ceph]# rbd create --size 2048 mypool/web --image-feature layering
[root@monitor ceph]# rbd ls mypool
myimage
web

3. 映射块设备 {pool-name}/{image-name}

[root@client ceph]# rbd map mypool/myimage --id admin   # 注：rbd0 说明这是映射的第一个块设备  
/dev/rbd0
[root@client ceph]# ls /dev/rbd
rbd/  rbd0
[root@client ceph]# ls /dev/rbd0 -l
brw-rw---- 1 root disk 252, 0 7月  11 17:12 /dev/rbd0

[root@client ceph]# rbd showmapped
id pool   image   snap device
0  mypool myimage -    /dev/rbd0

[root@client ceph]# ll /dev/rbd/mypool/
总用量 0
lrwxrwxrwx 1 root root 10 7月  11 17:12 myimage -> ../../rbd0

4. 使用块设备 /dev/rbd/{pool-name}/{image-name} 创建文件系统

[root@client ceph]# mkfs.xfs /dev/rbd0

5. 挂载

[root@client ceph]# mkdir /mnt/rdb0
[root@client ceph]# mount /dev/rbd0 /mnt/rbd0
[root@client ceph]# df -h
文件系统                 容量  已用  可用 已用% 挂载点
devtmpfs                 475M     0  475M    0% /dev
tmpfs                    487M     0  487M    0% /dev/shm
tmpfs                    487M  7.7M  479M    2% /run
tmpfs                    487M     0  487M    0% /sys/fs/cgroup
/dev/mapper/centos-root   17G  1.8G   16G   11% /
/dev/sda1               1014M  137M  878M   14% /boot
tmpfs                     98M     0   98M    0% /run/user/0
/dev/rbd0               1014M   33M  982M    4% /mnt/rbd0

在线扩容
块设备扩容

文件系统级别在线扩容