文章目录

• • 分布式存储ceph
  • • 一、ceph介绍
    • • 1.1、ceph是什么
      • 1.2什么是块存储、文件存储、对象存储
      • • 1.2.1 备知识: 块级与文件级
        • 1.2.2 块存储、文件存储、对象存储
        • (1)简述块存储、文件存储，对象存储
        • (2)块存储、文件存储、对象存储的关系
        • (3)细说块存储、文件存储、对象存储
      • 1.3为何要用ceph
    • 二、Ceph系统的层次结构
    • 三、基础存储系统RADOS（ceph集群）
    • • 3.1引入
      • 3.2 RADOS的子集群
      • 3.3rados的网络结构
    • 四、Ceph集群的逻辑结构
    • • 4.1核心逻辑概念总览
      • 4.2 pool
      • • 4.2.1 ceph pool介绍
        • 4.2.2ceph的pool有四大属性
        • 4.2.3 ceph的pool有两种类型
        • 4.2.4 ceph的pool提供如下能力
      • 4.3 pg
      • • 4.3.1pg的概念
        • 4.3.2pg的特点
        • 4.3.3 PG的创建过程
        • 4.3.4 PG 数目的确定(非常非常非常重要!!!)

分布式存储ceph

一、ceph介绍

1.1、ceph是什么

ceph一个统一的、分布式的存储系统，设计初衷是提供较好的性能、可靠性和可扩展性。
“统一的”:意味着我们可以仅凭ceph这一套存储系统，同时提供对象存储、块存储和文件系统存储三种功能，这极大地简化了不同应用需求下的部署和运维工作。

“分布式”:ceph实现了真正的去中心化，理论上可以无限扩展集群系统的规模
传统集群架构：集群规模增大，mysql数据库的集群规模必然也会随之增大，这完全就是集中式思想带来的弊端
ceph内部集群的数据共享，完全通过crush算法算出来的，根本不需要数据库这个组件，完全分布式的，ceph分布式的缺点：1、耗费CPU、内存

拓展：

任何集群追求的三大特点：
性能：减少io次数
可靠性：没有单点故障
可扩展性：未来可以无限扩展集群规模

#致敬作者:
 Ceph项目最早起源于Sage就读博士期间的工作(最早的成果手2004年发表)，并随后贡献给开源社区。在经过了数年的发展之后，目前已得到众多云计算厂商的支持并被广泛应用。RedHat及OpenStack都可与Ceph整合以支持虚拟机镜像的后端存储。

1.2什么是块存储、文件存储、对象存储

1.2.1 备知识: 块级与文件级

1、#块级
磁盘的最小读写单位为扇区，1个或多个连续的扇区组成一个block块，也叫物理块，是操作系统读写硬盘的单位。可以通过命令查看block块大小
blockdev --getbsz /dev/sda1

2、#文件级
文件是文件系统提供的功能，单个文件可能由于一个或多个逻辑文件块组成，且逻辑块之间是不连续分布。逻辑块大于或等于物理块整数倍
物理块与文件系统之间的映射关系为:
扇区+物理块+逻辑块+文件系统
注意:这么多层转换，肯定是需要耗费效率的，如果操作的是对象，则可以直接省去这么多层映射关系，效率自然是高

1.2.2 块存储、文件存储、对象存储

(1)简述块存储、文件存储，对象存储

#块存储：
如果存储设备提供给客户端的是一块裸盘，需要客户端自己分区格式化制作文件系统，则称之为块存储
#特点：
客户端可定制性强，可以自己制作文件系统，然后挂载使用，或者直接把操作系统安装在块存储里
#用途：
主要用于VM的本地硬盘

#文件存储：
如果存储设备提供给你的是一个文件夹，你自己直接操作文件，则称之为文件存储
#特点：
1、客户端定制性差，不能自己制作文件系统，文件系统是在存储设备中制作好的，客户端使用的就是一个文件夹。
2、文件检索与存储设备中完成的，意味着随着客端数目的增多，存储设备的压力会越来越大，所以文件存储会限制集群的扩展规模
#用途：
中小规模集群的多服务器之间共享数据，并且保证一致

#对象存储
如果你只需要提供文件的元数据与真实数据，存储设备负责帮你生成文件，然后存到硬盘中，这就称之为对象存储
#特点：
1、没有文件检索的压力，服务端不会随着客端数目的增多压力成倍增大

(2)块存储、文件存储、对象存储的关系

块存储是最低级，最直接的，如果多个客户端共用一个块存储，客户端会把数据先缓存在本地，然后再写入块存储(详见6.3)，这就会导致多个客户端数据不一致的问题，所以，通常一个块存储只给一个客户端用

为了让多个客户端共享数据、并保证一致，于是诞生了文件存储，例如nfs，客户端挂载的都是服务端的同一个文件夹，数据是完全一致的，但是随着客户端数量越来越多，nfs服务器检索文件信息的压力会越来越大，最后不堪重负，一旦挂掉，则影响整个集群的工作，所以nfs严重影响了集群的扩展

为了能够满足无限扩展的需求，诞生了对象存储，客户端无需操作文件，而是只需要提供文件相关的各部分信息即可，这些信息称之为一个个的对象，存储设备接收到对象后负责完成后续操作

(3)细说块存储、文件存储、对象存储

#块存储:
1客户端主要操作对象是磁盘，客户端可以自己格式化制作文件系统
2、块存储设备中划分出的是一块裸磁盘空间映射给客户端主机使用
3、例如SCSI
4、可应用于虚拟机的本地硬盘

以SCSI为例，主要接口有Read/dite/Read Capacity/Inquiry等等。FCiscsI，也是块存储协议。和文件存储相比，没有文件和目录树的概念，一般协议也不会定义磁盘的创建和删除操作。协议更注重传输控制。

#文件存储：
1、客户端主要操作的是文件和文件夹，客户端无法格式化制作自己的文件系统，使用的是现成的文件系统。
2、文件储中已经做好了文件系统然后共享给客户端主机使用
3、例如NFS

文件存储支持 POSIX协议，以 NFS 为例，文件相关的接口包括:
 LOOKUP/ACCESS/READ/WRITE/CREATE/REMOVE/RENAME等等，文件夹相关的接口包括:MKDIR/RMDIR/READDIR等等。同时也会有FSSTAT/FSINFO 等接口用于提供文件系统级别的信息。 POSIX,SAMBA 等也是文件存储协议。协议更注重接口的灵活，以及访问权限控制

#对象存储:
1、客户端主要操作对象是对象(Object)
2、对象存储使用一个统一的底层存储系统，把文件和底层介质的组织结构都管理好，然后给每个文件一个唯一的标识，客户端需要访问某个文件，直接提供文件的标识就可以了。此时存储系统可以用更高效的数据组织方式来管理这些标识以及其对应的存储介质上的块。
当然对干不同的软件系统来说一次访问需要获取的不一定是单个我们传统意义上的文件，根据不同的需要可能只是一个/组值，某个文件的一部分，也可能是多个文件的组合，甚至是某个块设备，统称为对象。这就是对象存储。
3、例如S3

以S3为例，主要接口有 PUT/GET/DELETE等。和对象储相比，没有随机读写的接口。和文件存储相比没有目录树的概念。协议更注重简洁

#总结
1/块存储:是和主机打交道的,如插一块硬盘 文件存储: NAS, 网络存储，用于多主机共享数据
2/对象存储:跟你自己开发的应用程序打交道如网盘它们的层级是越来越高的

关于ceph的块存储、文件存储、对象存储
Block(块):支持精简配置、快照、克隆。
File(文件系统):Posix接口，支持快照。
Object(对象):有原生的API，而且也兼容Swift和S3的AP。

1.3为何要用ceph

Ceph本身确实具有较为突出的优势，ceph追求用最廉价的设备做最牛逼的存储。其先进的核心设计思想，概括为八个字一“无需查表，算算就好"。

详细地讲，可以总结为以下四点：
1高性能：a.摒弃了传统的集中式存储元数据寻址的方案，采用CRUSH算法，数据分布均衡，并行度高。b.考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架感知等。。能够支持上千个存储节点的规模，支持TB到PB级的数据。

2、高可用：a.副本数可以灵活控制。b.支持故障域分隔，数据强一致性。c. 多种故障场景自动进行修复自愈。d.没有单点故障，自动管理。高可扩展性。

3、去中心化：b.扩展灵活。c.随着节点增加而线性增长。

4、特性丰富 ：a.支持三种存储接口：块存储、文件存储、对象存储。b.支持自定义接口，支持多种语言驱动。

二、Ceph系统的层次结构

#自下向上，可以将Ceph系统分为四个层次:
基础存储系统RADOS(ReliableAutonomicDistributed Object Store，即可靠的、自动化的、分布式的对象存储)
基础库LIBRADOS

#高层应用接口:包括了三个部分
1、对象存储接口:RADOS GW(RADOS Gateway)
2、块存储接口:RBD(Reliable Block Device)
3、文件存储接口:Ceph FS(Ceph File Svstem)

应用层:基于高层接口或者基础库librados开发出来的各种APP，或者主机、VM等诸多客户端

提示：rados集群是ceph的服务端，依据高层接口封装的应用则是客户端。

三、基础存储系统RADOS（ceph集群）

3.1引入

为了更好地理解RADOS的组成，我们从单块盘说起

#单块硬盘的指标
1、IO速度
2、容量

#单块硬盘的限制，单块硬盘就好像是一个矿泉水瓶
1、IO速度受限在于瓶口，容量受限在于瓶体
2、把长江的水倒入瓶子，首先瓶口太窄IO太慢，其次容量不够空间太小装不下长江水

#解决方案:
1/纵向扩展---->不可能实现一瓶装下长江水
2/横向扩展---->n盘做raid,相当于一块大盘，在本机使用，但是单台机器可插硬盘的总数也是有限的，仍然会受到限制

如果能通过网络通信，那么就可以打破单台机器的限制:一堆硬盘+软件控制起来
做成硬盘的集群，相当于一个大的网络raid，这就是分布式存储，比如ceph

3.2 RADOS的子集群

ceph的底层是RADOS，而RADOS由多个子集群构成
若干个数据盘:一个Ceph存储节点上可以有一个或者多个数据盘，每个数据盘上部署有特定的文件系统，比如xfs，ext4或者btrfs。可以是一个分区当一个disk，可以是一个raid当一个 disk，也可以是一整块盘当一个disk，但依据本人在公司中的实际架构经验看还是一整块盘当一个disk效率高更稳定。

#1.btrfs(B-tree 文件系统):功能强大，但耗费资源也高
 btrfs是个很新的文件系统(oracel在2014年8月发布第一个稳定版)，它将会支持许多非常高大上的功能，比如透明压缩( transparent compression)，可写的cow 快照(writable oopy-on-write snapshots)、去重(deduplication)和加密(encryption) 。因此，Ceph 建议用户在非关键应用上使用该文件系统。


#2、xfs(推荐）
 xfs和 btrfs 相比较ext3/4而言，在高伸缩性数据存储方面具有优势。


#OSD （Object Storage Device) 集群：一个做好文件系统的disk由一个OSD Daemon管理，

#OSDDaemon负责

1、负责控制数据盘上的文件读写操作，与client通信完成各种数据对象操作等等。
2、负责数据的拷贝和恢复
3、每个OSD 守护进程监视它自己的状态 以及别的OSD的状态，并且报告给 Monitor
在一个服务器上，一个数据对应一个OSD Daemon，而一个服务器上可以有多块数据盘，所以仅在一台服务器上，就会运行多个OSD Daemon，该服务称之为OSD节点，一个CEPH集群中有n个OSD节点，综合算下来，OSD集群由一定数目的(从几十个到几万个)OSD Daemon组成。

#MON(Montior)集群:
MON集群由少量的、数目为奇数个的Monitor守护进程(Daemon)组成，负责ceph所有集群中所有OSD状态的发现与记录。理论上来讲，一个MON就可以完成这个任务，之所以需要一个多个守护进程组成的集群的原因是保证高可靠性。每个Ceph node上最多只能有一个 Monitor Daemon。

要使用CephFS 还需要MDS集群，用于保存CephFS的元数据
要使用对象存储接口，还需要 RADOS Gateway，它对外提供REST接口，兼容S3和Swift的API

#问题1:monitor集群如何实现对ceph所有集群的状态检测和维护的？

OSD集群和monitor集群之间相互传输节点状态信息，共同得出系统的总体工作状态，并形成一个记录 ceph系统全局状态数据结构，即所谓的cluster map。
cluster map与RADOS提供的特定算法相配合，便实现了Ceph“无需查表，算算就好”的核心机制以及若干优秀特性，保证了数据的安全性
Cluster map包括:1、mon map 2、osd map 3、pg map 4、crush map





#问题2：monitor为何为奇数个---->paxos算法
#需知:集群状态是不断变化的，所以cluster map也是不断变化的
为了标记最新的cluster map，monitor持有的每个cluster map都有一个视图版本号(Epoch)，并且 Epoch是单调递增的、伴随着cluster map的更新而更新，随着集群的运行，一些monitor节点的epoch可能会出现周期性落后的情况，那如何保持集群中所有monitor节点持有的clustermap是一致的呢，这就用到了paxos分布式强一致性算法
(详解:https://ww.cnblogs.com/linhaifeng/articles/14685438.html)

#Paxos算法下所有monitor分为三种角色，通常应为奇数个
1、leader:mon集群通过paxos算法选取出的主节点，主节点拥有最新版本号
2、provider:正常的mon节点会找leader同步最新的版本号
3、requester：请求者，down掉的mon节点准备恢复中（找leader同步信息，但是leader会交给provider处理）
简单地讲就一句话:mon集群会依据paxos算法互相通信发现有大的epoch存在，便会更新自已的视图版本





#问题3:monitor与OSD daemon是否可以在同一个节点上
可以，但不好，最好还是分布式，杜绝集中式
并且需要再次强调一点:一个节点只能有一个monitor进程，但可以有多个OSD daemon




#问题4monitor节点的个数应该为多少?如果有3个，挂掉2个，集群还能工作吗?
一般来说，在实际运行中，ceph monitor的个数是2n+1(n>=0)个，在线上至少3个，只要正常的节点数>=n+1,ceph的paxos算法能保证系统的正常运行。所以，对于3个节点，同时只能挂掉一个。一般来说，同时挂掉2个节点的概率比较小，但是万一挂掉2个呢?如果ceph的monitor节点超过半数挂掉，paxos算法就无法正常进行仲裁(quorum)，此时，ceph集群会阻塞对集群的操作，直到超过半数的monitor节点恢复。

3.3rados的网络结构

rados作为ceph最核心的部分，是整个ceph的大后端，应该如何架设呢???
首先:Ceph使用以太网连接内部各存储节点以及连接client 和rados集群。
然后:Ceph推荐使用两个网络，这么做，主要是从性能(OSD节点之间会有大量的数据拷贝操作)和安全性(两网分离)考虑。
前端(北向)网络(apublic(frontside)network)连接客户端和集群
后端/东西向网络(acluster(back-side)network)来连接Ceph各存储节点
你可以在Ceph配置文件的[global]部分配置两个网络

public network =(public-network/netmask}
cluster network ={cluster-network/netmask}


#提示
与客户通信的数据流为纵向，所以称之为北向网络，或称南北网络。
集群内通信的数据流为横向，所以称之为东西网络。

南北的含义是数据可以往外走，客户端是集群外的节点，其余为集群内节点
东西的含义是数据流是横向的，数据流会在集群内节点通信，与外界无关

四、Ceph集群的逻辑结构

4.1核心逻辑概念总览

#rados构建完毕后，为客户端提供存储服务，需要。

1、创建存储池poo1，存储池中包含100个pg
ceph osd pool create rbdtest 1oo 

2、设置poo池的副本数，即一个的包含多少个OSD Daemon，往某一个pg中存的数据会在其包含的osd中都保存一份
 ceph osd pool set rhatest size 3

3、在存储池rdbtest中创建一个镜像给客户端用，一个image用的是存储池中的pg(并非指定的pg，而是只要是存在与pool中的pg都可能会用到)，相当于一个配额
rbd create -p rdbtest --size 10000 yzl # image名为yzl，大小为10000M

#在客户端文件会被以4M为单位切成3块，
每块对应一个object
object多对一pg
pg多对多osd daemon
一个pool中有多个pg
从pool中划分出image给用户用，image只是一个配额

#写入数据流程大致如下:
librbd
crush算法
file ----->object ------>pool中划分出来的image(一堆pg)------->osd daemon

ceph存储小文件效率不高
底层osd daemon越多，存大文件效率越高
ceph是伪数据平衡，如果只有一个PG，一个PG里副本数为3，永远只有一块盘被用到



#ceph的逻辑结构与Ivm有点像
pv->osd
vg > pool
lv ->image

4.2 pool

4.2.1 ceph pool介绍

在rados集群构建完毕后、使用ceph时，需要用到诸多逻辑概念/结构，我们才能理解一个文件到底是如何写入到ceph中。ceph集群的逻辑结构主要由Pool与PG(Placement Group)来定义，本节我们先来介绍一下Pool.

#对比LVM逻辑卷
pv:把一系列的盘都做好标记，由LVM管理起来
vg:是把一系列的pv给归类到一起，相当于一块大磁盘
lv:相当于从vg这个 磁盘"中分出的一个"分区”
ceph的l逻辑结构与lvm有点像，其对应关系如下

4.2.2ceph的pool有四大属性

1、所有性和访问权限
2、对象副本数目，默认pool池中的一个pg只包含两个osd daemon，即一份数据交给pg后会存下2个副本，生产环境推荐设置为3个副本
3、PG数目，PG是pool的存储单位，pool的存储空间就由pg组成
4、CRUSH 规则集合

4.2.3 ceph的pool有两种类型

#Replicated pool(默认）：
#拷贝型pool通过生成对象的多份拷贝
默认的存储池类型，把每个存入的对象(Object)存储为多个副本，其中分为主副本和从副本,从 副本相当于备份副分，从而确保在部分OSD丢失的情况下数据不丢失。这种类型的 pool 需要更多的裸存储空闻，但是它支持所有的pool 操作。
如果客户端在上传对象的时候不指定副本数，默认为3个副本。在开始存数据之前会计算出该对象存储的主副本与从副本的位置，首先会将数据存入到主副本，然后主副本再将数据分别同步到从副本。主副本与从副本同步完毕后，会通知主副本，这时候主副本再响应客户端，并表示数据上传成功。所以如果客户端收到存储成功的请求后，说明数据已经完成了所有副本的存储。

#Erasure-coded pool:
此类型会将数据存储为K+M，其中K数据块数量。每个对象存储到Ceph集群的时候会分成多个数据块分开进行存储。而M为编码块，也代表最多容忍可坏的数据块数量。类似于磁盘阵列RAID5，在最大化利用空间的同时，还能保证数据丢失可恢复性，相比副本池更节约磁盘的空间。因为副本池很浪费存储空间，如果Ceph集群总容量为100T，如果使用副本池，那么实际可用空间按3个副本算，那么只有30T出头。而使用纠删码池就可以更大化的利用空间的，但纠删码池更浪费计算资源。如存储一个100M的资源，如果使用副本池，按3副本计算实际上要使用300M的空间。而使用纠删码池，如果将100M资源分为25块，如果将M指定为2，那么总共只需要108M空间即可，计算公式为100+100/25*2。注意:如果存储RBD镜像，那么不支持纠删码池。关于此类型存储池使用不多，不做过多介绍。

4.2.4 ceph的pool提供如下能力

#1.Resilience(弹力):
即在确保数据不丢失的情况允许一定的OSD失败，这个数目取决于对象的拷贝(copy/replica)份数或称副本数。对拷贝型pool来说，Ceph中默认的拷贝份数是这意味着除了对象自身外，它还有一个另外的备份，你可以自己决定一个Pool中的对象的烤贝份数。生产环境推荐为3，副本数越多数据越安全、真正可以使用的空间越少



#2.PG（placement group，放置组）：
ceph用pg把存放相同副本的osd daemon归为一组。
客户端的文件会被切成多个object然后交给ceph存储，ceph中真正负责存储的是osd daemon守护进程，在存储时，ceph需要找到n个osd daemon、归类好哪些osd daemon存放的是同一个副本、然后把object交给它们，为了降低查找与归类成本，于是引入了pg的概念，将存放相同副本的 osd daemon归为一个pg组

#3.CRUSH Rules(CRUSH规则):
数据映射的策略。系统默认提供"reolicated_ruleset"。用户可以自定义策略来灵活地设置object存放的区域。比如可以指定po011中所有objecst放置在机架1上，所有objects的第1个副本放置在机架1上的服务器A上，第2个副本分布在机架1上的服务器B上。pool2中所有的object分布在机架上，所有Object的第1个副本分布在机架2的服务器上，第2个副本分布在机架3的服器上，第3个副本分布在机架4的服务器上。后续小猿会详细介绍 crush rules.

#4.Snapshots(快照):
你可以对pool 做快照。


#5.Set Ownership:
设置pool的owner的用户ID。


#6.Ceph集群创建后，默认创建了data metadata 和 rbd 三个存储池。

4.3 pg

4.3.1pg的概念

#PG英文全称 Placement group，中文称之为归置组。
#PG的作用:
PG相当于一个虚拟组件，出于集群伸缩，性能方面的考虑。Ceph将每个存储池分为多个PG，如果存储池为副本池类型，并会给该存储池每个PG分配一个主OSD和多个从OSD，当数据量大的时候PG将均衡的分布行不同集群中的每个OSD上面。

#PG概念非常复杂，主要有如下几点:
PG也是对象的逻集合，pool中的副本数设置为3，则一个pg中包含3个osd daemon,同一个PG接收到的所有object在这3个osddaemon上被复制。
Epoch:PG map的版本号，它是一个单调递增的序列。


Peering:见下文的状态描述。
Acting set:支持一个PG的所有osd daemon的有序列表，其中第一个OSD 是主OSD，其余为次。acting set 是 CRUSH 算法分配的，但是不一定已经生效了。
Up set:某一个PG map历史版本的acting set。在大多数情况下，acting set 和 up set 是一致的，除非出现了 pg_temp。

Current Interval or Past Interval:若干个连续的版本号，这些版本中acting和 up set 保持不变。



#PGtemp:
一个PG组里有三个组员/OSD daemon，三个组员第一个是组长，组长负责对外提供服务，组员负责备份，一旦组长挂掉后，相当于公司中一个部门的项目经理挂了，公司会招聘一个新的项目经理，但新的项目经理刚来的时候还什么都不知道(即新加进来的osd daemon是没有任何组内数据的)，此时公司会让某个组员先临时接替一下组长的职务、对外提供服务，一旦新来的组长了解了业务(即新加进来的osd daemon已经同步好数据了)，那么就可以让新组长出山了，详解如下

在Ceph正在往主OSD回填数据时，这个主0SD是不能提供数据服务的，这时候，它会向MON申请一个临时的 acting set，这就是 PG temp。举个例子，现在 acting set 是[0,1,2],出现了一点事情后，它变为[3,1,2]，此时osd.3还是空的因此它无法提供数据服务因此它还需要等待backfilling过程结束，因此，它会向MON 申请一个临时的 set 比如 [1,2，3]，此时将由 osd.1 提供数据服务。回填过程结束后，该临时 set 会被丢弃，重新由osd.3g提供服务。

#主(primary)OSD:
在actingset中的首个OSD，负责接收客户端写X数据;默认情况下，提供数据读服务，但是该行为可以被修改。它还负责peering过程，以级在需要的时候申请 PG temp。

#次(replica)OSD:
在actingset中的除了第一个以外的其余OSD。


#流浪(stray)OSD:
已经不是actingset中了，但是还没有被告知去删除数据的OSD。 PG的acting set 是由CRUSH 算法根据 CRUSH Rulles 动态地计算得出的。

4.3.2pg的特点

#基本特点
1)Ceph引入PG的目的主要是为了减少直接将对象object映射到OSD的复杂度，即PG 确定了pool中的对象object和pSD之间的映射关系，一个object只会存在于一个 PG 中，但是多个object可以在同一介PG内。PG-Object-OSD的关系如下图所示: object与PG是多对一的关系

2)PG与OSDdaemon是多对多的关系 OSD daemon与disk是一对一的关系
一个OSD上的PG则可达到数百个。事实上，PG数量的设置牵扯到数据分布的均匀性问题。PG 和 OSD 之间的映射关系由CRUSH 决定，而它做决定的依据是CRUSH 规则
(rules)。CRUSH将所有的存储设备(OSD)组织成一个分层结构，该结构能区分故障域(failure domain)，该结构中每个节点都是一个CRUSH bucket。

3)对象的副本数目，也就是被拷贝的次数，是在创建Pool时指定的。该分数决定了每个PG会在几个 OSD 上保存对象。如果一个拷贝型 Pool 的size(拷贝份数)为2，它会包含指定数目的PG，每个PG使用两O其中，第一个为主OSD(primary)，其它的为从OSD(secondary)。不同的PG可能会共享一个 OSD。

4)PG也是Ceph集群做清理(scrubbing)的基本单位，也就是说数据清理是一个一个PG来做的。
PG和 OSD 的关系是动态的
ofibrbd
object- >pool中划分出来的image(一堆pg)
Tiieod daemon

``````bash
1)一开始在PG被创建的时候，MON根据CRUSH算法计算出PG所在的OSD。这是它们之间的初始关系。
2)Ceph集群中OSD的状态是不断变化的，它会在如下状态之间做切换
up:守护进程运行中，能够提供1O服务; down:守护进程不在运行，无法提供1O服务; in:包含数据;
out:不包含数据
3)部分PG和OSD的关系会随着OSD状态的变化而发生变化
当新的OSD被加入集群后，已有OSD上部分PG将可能被挪到新OSD上;此时PG和 OSD的关系会发生改变。
当已有的某OSDdown了并变为out后，其上的PG会被挪到其它已有的OSD上。但是大部分的PG和OSD的关系将会保持不变，在状态变化时，Ceph 尽可能只挪动最少的数据。
。4)客户端根据Cluster map 以及CRUSH Ruleset 使用CRUSH算法查找出某个PG所在的 OSD 列表。

4.3.3 PG的创建过程

Pool的PG数目是创建pool时候指定的，Ceph官方有推荐的计算方法。其值与OSD的总数的关系密切。当Ceph集群扩展OSD增多时，根据需要，可以增加pool的PG 数目。

306
1)MON节点上有PGMonitotor，它发现有pool被创建后，判断该pool 是否有PG。如果有 PG，则逐一判断这些PG是否已经存在，如果不存在，则开始下面的创建PG的过程。

2)创建过程的开始，设置PG状态为Creating，并将它加入待创建PG队列 creatingpgs，等待被处理。

3)开始处理后，使用CRUSH算法根据当前的OSDmap 找出来up/acmgset，确定哪些osd属于哪些pg，然后加入队列 creating_pgs_by_osd, 等待被处理

4)队列处理函数将该OSD上需要创建的PG合并，生成消息MOSDPGCreate，通过消息通道发给OSD。

5)OSD收到消息字为 MSG_OSD_PG_CREATE的消息，得到消息中待创建的 PG 信息，判断类型，并获取该PG的其它OSD，加入队列creating_pgs似乎是由主 OSD 负责发起创建次 OSD上的PG)，再创建具体的PG。 K
6)PG 被创建出来以后，开始 Peering 过程。

4.3.4 PG 数目的确定(非常非常非常重要!!!)

创建pool 时需要确定其 PG的数目，在 poo被创建后也可以调整该数字，但是增加池中的PG数是影响ceph集群的重大事件之一，生成环境中应该避免这么做，因为pool中pg的数目会影响到