1. 简介

Ceph是一个高性能、可扩容的分布式存储系统，它提供三大功能：

对象存储：提供RESTful接口，也提供多种编程语言绑定。兼容S3、Swift
块存储：由RBD提供，可以直接作为磁盘挂载，内置了容灾机制
文件系统：提供POSIX兼容的网络文件系统CephFS，专注于高性能、大容量存储

Ceph将客户端的数据作为对象存储在它的存储池中，基于CRUSH算法，Ceph计算出每个对象应该位于那个PG，计算哪个OSD负责存储PG

Ceph集群由一系列节点（机器）组成，在这些节点上运行以下组件：

Ceph OSDs：OSD即对象存储守护程序，但是它并非针对对象存储。OSD负责存储数据、处理数据复制、恢复、回填（Backfilling）、再平衡。此外OSD还对其它OSD进行心跳检测，检测结果汇报给Monitor
Monitors：监视器，维护集群状态的多种映射，同时提供认证和日志记录服务
MDSs：元数据服务器，存储CephFS的元数据信息

1.1 架构

1.1.1 组件层次

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sAp6VL8v-1680552467828)(assets/image-20230404030601-hjsgr63.png)]

1.1.2 数据读写流程

在这里插入图片描述

1.2术语

术语	说明
RADOS	可靠的、自动化的分布式对象存储（Reliable, Autonomic Distributed Object Store）是Ceph的核心之一librados是RADOS提供的库，上层的RBD、RGW和CephFS都是通过librados访问RADOS的
RGW	即RADOS Gateway，指Ceph的对象存储API或者RGW守护进程
RBD	即RADOS Block Device，指Ceph提供的基于复制性的分布式的块设备。类似于LVM中的逻辑卷，RBD只能属于一个Pool
MDS	即Ceph元数据服务器，是CephFS服务依赖的元数据服务
CephFS	Ceph File System，是Ceph对外提供的文件系统服务
Pool	存储池是Ceph中一些对象的逻辑分组。它不是一个连续的分区，而是一个逻辑概念，类似LVM中的卷组（Volume Group）存储池分为两个类型：1. Replicated 复制型，对象具有多份拷贝，确保部分OSD丢失时数据不丢失，需要更多的磁盘空间。复制份数可以动态调整，可以置为11. Erasure-coded 纠错码型，节约空间，但是速度慢，不支持所有对象操作（例如局部写）
PG	归置组（Placement Group），PG是Pool组织对象的方式，便于更好的分配数据和定位数据，Pool由若干PG组成PG 的数量会影响Ceph集群的行为和数据的持久性。集群扩容后可以增大PG数量：5个以下OSD设置为128即可PG的特点：同一个PG中所有的对象，在相同一组OSDs上被复制。复制型Pool中PG可以有一个作为主（Primary）OSD，其它作为从OSD。一个对象仅仅属于一个PG，也就是说对象存储在固定的一组OSDs上PG在OSD的/var/lib/ceph/osd/ceph-2/current目录下，表现为目录
CRUSH	CRUSH即基于可扩容哈希的受控复制（Controlled Replication Under Scalable Hashing），是一种数据分发算法，类似于哈希和一致性哈希。哈希的问题在于数据增长时不能动态添加Bucket，一致性哈希的问题在于添加Bucket时数据迁移量比较大，其他数据分发算法依赖中心的Metadata服务器来存储元数据因而效率较低，CRUSH则是通过计算、接受多维参数的来解决动态数据分发的场景CRUSH算法接受的参数包括：1. Cluster map，也就是硬盘分布的逻辑位置，例如这有多少个机房、多少个机柜、硬盘是如何分布的等等。Cluster map是类似树的结构，子节点是真正存储数据的device，每个device都有id和权重，中间节点是bucket，bucket有多种类型用于不同的查询算法，例如一个机柜一个机架一个机房就是bucket1. Placement rules，它指定了一份数据有多少备份，数据的分布有什么限制条件（例如同一份数据不能放在同一个机柜里）。每个Rule对应一系列操作：1. take，选取一个bucket1. select，选择n个类型为t的项1. emit，提交CRUSH与一致性哈希最大的区别在于接受的参数多了Cluster map和Placement rules，这样就可以根据目前Cluster的状态动态调整数据位置，同时通过算法得到一致的结果基于此算法，Ceph存储集群能够动态的扩容、再平衡、恢复
Object	Ceph最底层的存储单元是Object，每个Object包含元数据和原始数据一个RBD会包含很多个Object
OSD	对象存储守护进程（Object Storage Daemon），负责响应客户端请求返回具体数据的进程。Ceph集群中有大量OSD一个节点上通常只运行一个OSD守护进程，此守护进程在一个存储驱动器上只运行一个 filestore
EC	Erasure Code（EC），即纠删码，是一种前向错误纠正技术（Forward Error Correction，FEC），主要应用在网络传输中避免包的丢失，存储系统利用它来提高可靠性。相比多副本复制而言，纠删码能够以更小的数据冗余度获得更高数据可靠性，但编码方式较复杂，需要大量计算。纠删码只能容忍数据丢失，无法容忍数据篡改，纠删码正是得名与此EC将n份原始数据，增加m份数据，并能通过n+m份中的任意n份数据，还原为原始数据。即如果有任意小于等于m份的数据失效，仍然能通过剩下的数据还原出来纠删码技术在分布式存储系统中的应用主要有三类：1. 阵列纠删码（Array Code: RAID5、RAID6等）：RAID是EC的特例，RAID5只支持一个盘失效，RAID6支持两个盘失效，而EC支持多个盘失效1. RS(Reed-Solomon)里德-所罗门类纠删码1. LDPC(LowDensity Parity Check Code)低密度奇偶校验纠删码：目前主要用于通信、视频和音频编码等领域，与RS编码相比，LDPC编码效率要略低，但编码和解码性能要优于RS码以及其他的纠删码

2. 组件

2.1 MON

监视器维护集群状态的多种映射—— 包monmap、OSD map、PG map、CRUSH map、MDS map，同时提供认证和日志记录服务。Ceph会记录Monitor、OSD、PG的每次状态变更历史（此历史称作epoch）。客户端连到单个监视器并获取当前映射就能确定所有监视器、 OSD 和元数据服务器的位置。依赖于CRUSH算法和当前集群状态映射，客户端就能计算出任何对象的位置，直连OSD读写数据。

Ceph客户端、其它守护进程通过配置文件发现mon，但是mon之间的相互发现却依赖于monmap的本地副本。所有mon会基于分布式一致性算法Paxos，确保各自本地的monmap是一致的，当新增一个mon后，所有现有mon的monmap都自动更新为最新版本。

2.1.1 监视器同步

使用多个mon时，每个mon都会检查其它mon是否具有更新的集群状态映射版本 —— 存在一个或多个epoch大于当前mon的最高epoch。太过落后的mon可能会离开quorum，同步后再加入quorum。执行同步时，mon分为三类角色：

Leader：具有最新版本状态映射的mon
Provider：同上，但是它的最新状态是从Leader同步获得
Requester：落后于Leader，必须获取最新集群状态映射才能重回quorum

2.1.2 时钟偏移

如果mon的时钟不同步，可能会导致：

守护进程忽略收到的消息（时间戳过时）
消息未及时收到时，超时触发得太快或太晚

2.2 OSD

2.2.1 日志

OSD使用日志的原因有两个：

速度：日志使得 OSD 可以快速地提交小块数据的写入， Ceph 把小片、随机 IO 依次写入日志，这样，后端文件系统就有可能归并写入动作，并最终提升并发承载力。因此，使用 OSD 日志能展现出优秀的突发写性能，实际上数据还没有写入 OSD ，因为文件系统把它们捕捉到了日志
一致性：OSD需要一个能保证原子化复合操作的文件系统接口。 OSD 把一个操作的描述写入日志，并把操作应用到文件系统。这确保了对象（例如归置组元数据）的原子更新。每隔一段时间（由filestore max sync interval 和 filestore min sync interval控制）， OSD 会停止写入，把日志同步到文件系统，这样允许 OSD 修整日志里的操作并重用空间。若失败， OSD 从上个同步点开始重放日志。日志的原子性表现在，它不使用操作系统的文件缓存（基于内存），避免断电丢数据的问题

注意：OSD进程在往数据盘上刷日志数据的过程中，是停止写操作的。

通常使用独立SSD来存储日志，原因是：

避免针对单块磁盘的双重写入 —— 先写日志，再写filestore
SSD性能好，可以降低延迟提升IOPS

2.2.2 OSD状态矩阵

	IN	OUT
UP	正常状态，OSD位于集群中，且接收数据	OSD虽然在运行，但是被踢出集群 —— CRUSH不会再分配归置组给它
DOWN	这种状态不正常，集群处于非健康状态	正常状态

2.3 Bluestore

在Luminous中，Bluestore已经代替Filestore作为默认的存储引擎。Bluestore直接管理裸设备，不使用OS提供的文件系统接口，因此它不会收到OS缓存影响。

使用Bluestore时，你不需要配备SSD作为独立的日志存储，Bluestore不存在双重写入问题，它直接把数据落盘到块上，然后在RockDB中更新元数据（指定数据块的位置）。

一个基于Bluestore的OSD最多可以利用到三块磁盘，例如下面的最优化性能组合：

使用HDD作为数据盘
使用SSD作为RockDB元数据盘
使用NVRAM作为RockDB WAL

2.4 PG

一些概念：

Acting Set：牵涉到PG副本的OSD集合
Up Set：指Acting Set中排除掉Down掉的OSD的子集

Ceph依赖于Up Set来处理客户端请求。如果 Up Set 和 Acting Set 不一致，这可能表明集群内部在重均衡或者有潜在问题。

写入数据前，归置组必须处于 active 、而且应该是 clean 状态。假设一存储池的归置组有 3 个副本，为让 Ceph 确定归置组的当前状态，一归置组的主 OSD （即 acting set 内的第一个 OSD ）会与第二和第三 OSD 建立连接，并就归置组的当前状态达成一致意见。

由于以下原因，集群状态可能显示为HEALTH WARN：

刚刚创建了一个存储池，归置组还没互联好
归置组正在恢复
刚刚增加或删除了一个 OSD
刚刚修改了 CRUSH 图，并且归置组正在迁移
某一归置组的副本间的数据不一致
Ceph 正在洗刷一个归置组的副本
Ceph 没有足够空余容量来完成回填操作

这些情况下，集群会自行恢复，并返回 HEALTH OK 状态，归置组全部变为active+clean。

2.3.1 归置组状态表

状态	说明
Creating	在你创建存储池时，Ceph会创建指定数量的PG，对应此状态创建PG完毕后，Acting Set中的OSD将进行互联，互联完毕后，PG变为Active+Clean状态，PG可以接受数据写入
Peering	Acting Set中的OSD正在进行互联，它们需要就PG中对象、元数据的状态达成一致。互联完成后，所有OSD达成一致意见，但是不代表所有副本的内容都是最新的
Active	互联完成后归置组状态会变为Active
Clean	主OSD和副本OSD已成功互联，并且没有偏离的归置组。 Ceph 已把归置组中的对象复制了规定次数
Degraded	当客户端向主 OSD 写入数据时，由主 OSD 负责把数据副本写入其余副本 OSD 。主 OSD 把对象写入存储器后，在副本 OSD 创建完对象副本并报告给主 OSD 之前，主 OSD 会一直停留在 degraded 状态如果OSD挂了， Ceph 会把分配到此 OSD 的归置组都标记为 degraded。只要它归置组仍然处于active 状态，客户端仍可以degraded归置组写入新对象如果OSD挂了（down）长期（ mon osd down out interval ，默认300秒）不恢复，Ceph会将其标记为out，并将其上的PG重新映射到其它OSD
Recovering	当挂掉的OSD重启（up）后，其内的PG中的对象副本可能是落后的，副本更新期间OSD处于此状态
Backfilling	新 OSD 加入集群时， CRUSH 会把现有集群内的部分归置组重分配给它。强制新 OSD 立即接受重分配的归置组会使之过载，用归置组回填可使这个过程在后台开始回填执行期间，你可能看到以下状态之一：1. backfill_wait，等待时机，回填尚未开始1. backfill_too_full，需要进行回填，但是因存储空间不足而不能完成
Remapped	负责某个PG的Acting Set发生变更时，数据需要从久集合迁移到新集合。此期间老的主OSD仍然需要提供服务，直到数据迁移完成
Stale	默认情况下，OSD每0.5秒会一次报告其归置组、出流量、引导和失败统计状态，此频率高于心跳如果：1. 归置组的主 OSD 所在的 Acting Set 没能向MON报告1. 或者其它MON已经报告，说主 OSD 已 down了则MONs就会把此归置组标记为 stale集群运行期间，出现此状态，所有PG的主OSD挂了
Inactive	归置组不能处理读写请求，因为它们在等着一个持有最新数据的 OSD 回到 up 状态
Unclean	归置组里有些对象的副本数未达到期望次数，它们应该在恢复中
Down	归置组的权威副本OSD宕机，必须等待其开机，或者被标记为lost才能继续

2.5 CRUSH

2.5.1 简介

CRUSH 算法通过计算数据存储位置来确定如何存储和检索。 CRUSH授权Ceph 客户端直接连接 OSD ，而非通过一个中央服务器或代理。数据存储、检索算法的使用，使 Ceph 避免了单点故障、性能瓶颈、和伸缩的物理限制。

CRUSH 需要一张集群的 Map，利用该Map中的信息，将数据伪随机地、尽量平均地分布到整个集群的 OSD 里。此Map中包含：

OSD 列表
把设备汇聚为物理位置的“桶”（Bucket，也叫失败域，Failure Domain）列表
指示 CRUSH 如何复制存储池中的数据的规则列表

通过CRUSH map来建模存储设备的物理位置，Ceph能够避免潜在的关联性故障 —— 例如一个机柜中的设备可能共享电源、网络供应，它们更加可能因为断电而同时出现故障，Ceph会刻意的避免把数据副本放在同一机柜。

新部署的OSD自动被放置到CRUSH map中，位于一个host节点（OSD所在主机名）。在默认的CRUSH失败域（Failure Domain）设置中，副本/EC分片会自动分配在不同的host节点上，避免单主机的单点故障。在大型集群中，管理员需要更加仔细的考虑失败域设置，将副本分散到不同的Rack、Row。

2.5.2 crush location

OSD在CRUSH map中的位置，称为CRUSH location。此Location以如下形式来描述：

# 一系列键值对，虽然是有层次结构的，但是列出的顺序无所谓
# 键必须是有效的CRUSH type。默认支持root,regin, datacenter, room, row, pod, pdu, rack, chassis, host
# 你不需要声明所有键，默认情况下Ceph自动把新OSD放在root=default host=hostname下，因此这两个键你可以不声明
root=default row=a rack=a2 chassis=a2a host=a2a1

你可以在Ceph配置文件中，用crush location选项来声明。每当OSD启动时，它会验证当前CRUSH map是否匹配crush location设置，如果不匹配会更新CRUSH map。设置下面的选项可以禁用此行为：

osd crush update on start = false

2.5.3 crush结构

CRUSH map是一个树状的层次结构，它是对存储设备物理位置松散的建模。

在这个层次结构中，叶子节点是Device，对应了OSD守护程序（通常管理一块或几块磁盘）。设备的以name.id来识别，通常是osd.N。设备可以关联一个设备类别（Device Class），取值例如hdd、ssd，CRUSH rule可以使用到设备类别。

除了叶子节点之外的，都称为桶（Bucket），每个桶都具有类型，默认支持的类型包括root,regin, datacenter, room, row, pod, pdu, rack, chassis, host。大部分集群仅仅使用一部分类型的桶。

每个节点都具有一个权重（Weight）字段，指示子树负责存储的数据的比例。权重应该仅仅在叶子节点上设置，由Ceph自动向上类加。权重的单位通常是TB。

执行命令 ceph osd crush tree可以查看CRUSH的层次，包括节点权重。

2.5.4 规则

CRUSH rule定义了数据如何跨越设备分布的规则。大部分情况下你可以通过命令行来创建CRUSH rule，少数情况下需要手工便捷CRUSH map。

2.5.5 TUNABLES

随着Ceph的发展，CRUSH算法被不断的优化。Ceph允许你自由选择新或旧的算法变体，这依赖Tunable实现。

要使用新的Tunable，客户端、服务器必须同时支持。Tunable的命名就是最初支持对应算法变体的那个Ceph版本的名称（例如jewel）。

2.6 RBD

2.6.1 缓存

用户空间的Ceph块设备实现（librbd）不能使用Linux的页面缓存，因此它自己实现了一套基于内存的LRU缓存——RBD Cacheing。

此缓存的行为类似于页面缓存，当OS发送屏障/Flush请求时，内存中的脏数据被刷出到OSD。

2.7 CephFS

这是一个POSIX兼容的文件系统，它使用Ceph的存储集群来保存数据。

一个Ceph集群可以有0-N个CephFS文件系统，每个CephFS具有可读名称和一个集群文件系统ID（FSCID）。每个CephFS可以指定多个处于standby状态的MDS进程。

每个CephFS包含若干Rank，默认是1个。Rank可以看作是元数据分片。CephFS的每个守护进程（ceph-mds）默认情况下无Rank启动，Mon会自动为其分配Rank。每个守护进程最多持有一个Rank。

如果Rank没有关联到ceph-mds，则其状态为failed，否则其状态为up。

每个ceph-mds都有一个关联的名称，典型情况下设置为所在的节点的主机名。每当ceph-mds启动时，会获得一个GID，在进程生命周期中，它都使用此GID。

如果MDS进程超过 mds_beacon_grace seconds没有和MON联系，则它被标记为laggy。

2.8 RGW

Ceph对象存储网关是基于librados构建的一套RESTful服务，提供对Ceph存储集群的访问。此服务提供两套接口：

S3兼容接口：Amazon S3的子集
Swift兼容接口： OpenStack Swift的子集

这两套接口可以混合使用。

对象存储网关由守护程序radosgw负责，它作为客户端和Ceph存储集群之间的媒介。radosgw具有自己的用户管理系统。

从firefly版本开始，对象存储网关在Civetweb上运行，Civetweb内嵌在ceph-radosw这个Daemon中。在老版本中，对象网关基于Apache+FastCGI。

2.9 Dashboard

Ceph仪表盘是一个内置的、基于Web的管理/监控工具。通过它你能够管理集群中各种资源。仪表盘作为Ceph Manager的模块实现。

3. 命令

3.1 ceph orch

包含一系列集群编排有关的命令。

3.1.1 orch ls

列出对编排器可见的服务：

ceph orch ls [<service_type>] [<service_name>] [--export] [plain|json|json-pretty|yaml] [--refresh]
 
ceph orch ls
# 守护进程类型              数量                     归置规则               使用的镜像
NAME                       RUNNING  REFRESHED  AGE  PLACEMENT             IMAGE NAME                            IMAGE ID  
alertmanager                   1/1  77s ago    2w   count:1               docker.io/prom/alertmanager:v0.20.0   0881eb8f169f  
crash                          2/3  79s ago    2w   *                     docker.io/ceph/ceph:v15               mix       
grafana                        1/1  77s ago    2w   count:1               docker.io/ceph/ceph-grafana:6.7.4     80728b29ad3f  
mds.cephfs                     2/3  79s ago    2w   ceph-1;ceph-2;ceph-3  docker.io/ceph/ceph:v15               mix       
mgr                            1/1  77s ago    2w   ceph-1                docker.io/ceph/ceph:v15               5b724076c58f  
mon                            2/3  79s ago    40m  count:3               docker.io/ceph/ceph:v15               mix       
nfs.ganesha                    1/1  78s ago    7d   count:1               docker.io/ceph/ceph:v15               5b724076c58f  
node-exporter                  2/3  79s ago    2w   *                     docker.io/prom/node-exporter:v0.18.1  mix       
osd.all-available-devices      2/3  79s ago    2w   *                     docker.io/ceph/ceph:v15               mix       
prometheus                     1/1  77s ago    2w   count:1               docker.io/prom/prometheus:v2.18.1     de242295e225  
rgw.china.zircon               2/3  79s ago    2w   count:3               docker.io/ceph/ceph:v15               mix

3.1.2 orch ps

列出对编排器可见的守护进程，守护进程是服务的实例

orch ps [<hostname>] [<service_name>] [<daemon_type>] [<daemon_id>] [plain|json|json-pretty|yaml] [--refresh] 
 
ceph orch ps
NAME                            HOST    STATUS         REFRESHED  AGE  VERSION    IMAGE NAME                            IMAGE ID      CONTAINER ID  
alertmanager.ceph-1             ceph-1  running (69m)  3m ago     2w   0.20.0     docker.io/prom/alertmanager:v0.20.0   0881eb8f169f  bef9ab4dcc98  
crash.ceph-1                    ceph-1  running (69m)  3m ago     2w   15.2.10    docker.io/ceph/ceph:v15               5b724076c58f  3bb0c129d4d4  
crash.ceph-2                    ceph-2  error          3m ago     2w   <unknown>  docker.io/ceph/ceph:v15               <unknown>     <unknown>   
crash.ceph-3                    ceph-3  running (69m)  3m ago     2w   15.2.10    docker.io/ceph/ceph:v15               5b724076c58f  f5c22d2c854b  
grafana.ceph-1                  ceph-1  running (69m)  3m ago     2w   6.7.4      docker.io/ceph/ceph-grafana:6.7.4     80728b29ad3f  17d84abdd9e6  
mds.cephfs.ceph-1.nivqqf        ceph-1  running (69m)  3m ago     2w   15.2.10    docker.io/ceph/ceph:v15               5b724076c58f  4be1504a4c6f  
mds.cephfs.ceph-2.djnipz        ceph-2  error          3m ago     2w   <unknown>  docker.io/ceph/ceph:v15               <unknown>     <unknown>   
mds.cephfs.ceph-3.cgngbk        ceph-3  running (69m)  3m ago     2w   15.2.10    docker.io/ceph/ceph:v15               5b724076c58f  7e514989bc6c  
mgr.ceph-1.adpioc               ceph-1  running (69m)  3m ago     2w   15.2.10    docker.io/ceph/ceph:v15               5b724076c58f  a66dd815c2b1  
mon.ceph-1                      ceph-1  running (69m)  3m ago     2w   15.2.10    docker.io/ceph/ceph:v15               5b724076c58f  0c87ed6da097  
mon.ceph-2                      ceph-2  error          3m ago     2w   <unknown>  docker.io/ceph/ceph:v15               <unknown>     <unknown>   
mon.ceph-3                      ceph-3  running (69m)  3m ago     2w   15.2.10    docker.io/ceph/ceph:v15               5b724076c58f  836ec2a7c34d  
nfs.ganesha.ceph-3              ceph-3  running (68m)  3m ago     7d   3.3        docker.io/ceph/ceph:v15               5b724076c58f  440a1bcef7c5  
node-exporter.ceph-1            ceph-1  running (69m)  3m ago     2w   0.18.1     docker.io/prom/node-exporter:v0.18.1  e5a616e4b9cf  26bf34b93188  
node-exporter.ceph-2            ceph-2  error          3m ago     2w   <unknown>  docker.io/prom/node-exporter:v0.18.1  <unknown>     <unknown>   
node-exporter.ceph-3            ceph-3  running (69m)  3m ago     2w   0.18.1     docker.io/prom/node-exporter:v0.18.1  e5a616e4b9cf  fb60a5b31bfd  
osd.0                           ceph-2  error          3m ago     2w   <unknown>  docker.io/ceph/ceph:v15               <unknown>     <unknown>   
osd.1                           ceph-1  running (69m)  3m ago     2w   15.2.10    docker.io/ceph/ceph:v15               5b724076c58f  49cad5daf8f8  
osd.2                           ceph-3  running (69m)  3m ago     2w   15.2.10    docker.io/ceph/ceph:v15               5b724076c58f  17ef075e16a4  
prometheus.ceph-1               ceph-1  running (69m)  3m ago     2w   2.18.1     docker.io/prom/prometheus:v2.18.1     de242295e225  7b61f27c6a0e  
rgw.china.zircon.ceph-1.dsctvb  ceph-1  running (69m)  3m ago     2w   15.2.10    docker.io/ceph/ceph:v15               5b724076c58f  b7d6166aae36  
rgw.china.zircon.ceph-2.ulzfto  ceph-2  error          3m ago     2w   <unknown>  docker.io/ceph/ceph:v15               <unknown>     <unknown>   
rgw.china.zircon.ceph-3.qjhszd  ceph-3  running (69m)  3m ago     2w   15.2.10

3.1.3 orch apply

设置某种组件（服务/守护进程）的数量或者归置规则，格式：

# 更新守护程序副本数量、归置规则，或者apply一段YAML格式的配置
orch apply [mon|mgr|rbd-mirror|crash|alertmanager|grafana|node-exporter|prometheus] [<placement>]  
 [--dry-run] [plain|json|json-pretty|yaml] [--unmanaged] 
 
# 扩缩容iSCSI服务
orch apply iscsi <pool> <api_user> <api_password> [<trusted_ip_list>] [<placement>] [--dry-run]
 [plain|json|json-pretty|yaml] [--unmanaged]  
 
# 更新指定fs_name的MDS实例数
orch apply mds <fs_name> [<placement>] [--dry-run] [--unmanaged] [plain|json|json-pretty|yaml]
 
# 扩缩容NFS服务
orch apply nfs <svc_id> <pool> [<namespace>] [<placement>] [--dry-run] [plain|json|json-pretty|
 yaml] [--unmanaged] 
 
# 创建OSD守护进程
orch apply osd [--all-available-devices] [--dry-run] [--unmanaged] [plain|json|json-pretty|yaml]
 
# 为指定的Zone更新RGW实例的数量
orch apply rgw <realm_name> <zone_name> [<subcluster>] [<port:int>] [--ssl] [<placement>] 
[--dry-run] [plain|json|json-pretty|yaml] [--unmanaged]

下面是一些简单的例子：

# 指定副本数
ceph orch apply mon 3
# 制定归置规则
ceph orch apply mon ceph-1 ceph-2 ceph-3
 
# 为所有空闲设备创建OSD
ceph orch apply osd --all-available-devices

3.1.4 orch daemon

管理守护进程。

add子命令，添加一个守护进程：

# 添加守护进程
ceph orch daemon add [mon|mgr|rbd-mirror|crash|alertmanager|grafana|node-exporter|prometheus [<placement>]
 
ceph orch daemon add iscsi <pool> <api_user> <api_password> [<trusted_ip_list>] [<placement>]
ceph orch daemon add mds <fs_name> [<placement>] 
ceph orch daemon add nfs <svc_id> <pool> [<namespace>] [<placement>]
ceph orch daemon add osd [<svc_arg>]
ceph orch daemon add rgw <realm_name> <zone_name> [<subcluster>] [<port:int>] [--ssl] [<placement>]

redeploy子命令，重新部署某个守护进程，可以指定使用的镜像：

ceph orch daemon redeploy <name> [<image>]

如果节点上的守护进程容器被意外删除，也就是 podman ps看不到对应容器，可以使用redeploy命令重新部署。

rm子命令，删除某个守护进程：

ceph orch daemon rm <names>... [--force]

你也可以启动、停止、重启、重新配置某个守护进程：

ceph orch daemon start|stop|restart|reconfig <name>

如果需要启动、停止、重启、重新配置某种服务的所有守护进程：

ceph orch start|stop|restart|redeploy|reconfig <service_name>

3.1.5 orch device

管理块设备。

显示某些主机上的块设备：

ceph orch device ls [<hostname>...] [plain|json|json-pretty|yaml] [--refresh] [--wide]

清除块设备上的内容：

ceph orch device zap <hostname> <path> [--force]

3.1.6 orch host

管理主机。

添加主机，可选的，添加标签：

ceph orch host add <hostname> [<addr>] [<labels>...]

为主机添加/移除标签：

ceph orch host label add <hostname> <label>
ceph orch host label rm <hostname> <label>

列出主机：

ceph orch host ls [plain|json|json-pretty|yaml]

检查是否可以在不损害可用性的前提下，停止主机：

ceph orch host ok-to-stop <hostname>

删除主机：

ceph orch host rm <hostname>

修改主机地址：

ceph orch host set-addr <hostname> <addr>

3.1.7 orch osd rm

删除OSD实例：

ceph orch osd rm <svc_id>... [--replace] [--force]

检查删除OSD操作的进度：

3.1.8 orch pause

暂停编排器的后台任务

3.1.9 orch resume

恢复暂停的编排器后台任务

3.1.10 orch set backend

选择编排器后端： ceph orch set backend <module_name>

3.1.11 orch status

显示使用的编排器后端，以及它的状态：

ceph orch status [plain|json|json-pretty|yaml]
 
ceph orch status
Backend: cephadm
Available: True

cephadm就是一个编排器后端，下文会有介绍。

3.1.12 orch upgrade

升级相关操作：

orch upgrade check [<image>] [<ceph_version>]    # 检查镜像可用版本
orch upgrade pause                               # 暂停升级
orch upgrade resume                              # 恢复暂停的省级
orch upgrade start [<image>] [<ceph_version>]    # 触发升级
orch upgrade status                              # 升级状态
orch upgrade stop                                # 停止进行中的升级

3.2 ceph log

查看日志：

ceph log last [<num:int>] [debug|info|sec|warn|error] [*|cluster|audit|cephadm]
 
# 查看cephadm的最新日志
ceph log last cephadm

4. 通过cephadm部署

Cephadm是最新的Ceph部署工具，他利用容器和Systemd，仅仅支持Octopus或者更新的版本。

Cephadm的外部依赖包括容器运行时（Docker或者Podman），以及Python3。

4.1 安装Cephadm

cd /tmp
curl --silent --remote-name --location https://github.com/ceph/ceph/raw/octopus/src/cephadm/cephadm
chmod +x cephadm

安装支持cephadm命令及其依赖：

./cephadm add-repo --release octopus
./cephadm install

4.2 单节点自举

cephadm bootstrap --mon-ip 10.0.2.1
cephadm shell -- ceph -s

上述命令会安装一个单MON节点的Ceph集群。该命令会：

创建MON和MGR守护进程到本机
为Ceph集群生成SSH密钥，并添加到roo用户的/root/.ssh/authorized_keys
生成最小化配置的 /etc/ceph/ceph.conf，用于和新集群通信
生成Ceph管理密钥 /etc/ceph/ceph.client.admin.keyring
复制公钥副本到/etc/ceph/ceph.pub

4.3 安装Ceph Common

 cephadm install ceph-common

这样你就可以直接使用ceph命令了：

ceph status

4.4 添加节点

你需要提前为节点安装好Python3

列出现有节点：

ceph orch host ls

orch子命令用于Ceph集群相关的编排。

将集群的公钥安装到新节点的authorized_keys：

ssh-copy-id -f -i /etc/ceph/ceph.pub root@10.0.2.2
ssh-copy-id -f -i /etc/ceph/ceph.pub root@10.0.2.3

添加节点，注意要提供主机名：

ceph orch host add ceph-2
ceph orch host add ceph-3

4.4.1 修改节点地址

ceph orch host set-addr ceph-1 ceph-1.gmem.cc

4.5 添加MON

 # 设置哪些子网中的主机可以作为MON
ceph config set mon public_network 10.0.2.0/24
 
# 确保三个MON
ceph orch apply mon 3
 
# 你也可以强制指定在哪些主机上部署MON
ceph orch apply mon ceph-1 ceph-2 ceph-3

4.6 添加OSD

使用下面的命令，可以将集群主机所有空闲设备作为OSD：

ceph orch apply osd --all-available-devices

将特定主机的特定磁盘作为OSD：

ceph orch daemon add osd ceph-1:/dev/vdb

4.7 部署CephFS

ceph fs volume create cephfs --placement="ceph-1 ceph-2 ceph-3"

4.8 部署RGW

ceph orch apply rgw china beijing '--placement=3' --port=80

4.9部署NFS

NFS Ganesha是一个用户模式的NFS，支持v3 4.0 4.1 4.2，可以同时运行这些协议。

使用下面的命令来部署NFS Ganesha网关。

# 为NFS创建存储池
ceph osd pool create nfs-ganesha 64 replicated
#                   服务ID  存储池      命名空间
ceph orch apply nfs ganesha nfs-ganesha china

5. 通过ceph-deploy部署

ceph-deploy是一个ceph部署工具，服务器只需要提供SSH、sudo、一些Python包即可完成ceph的安装部署。

准备好服务器集群后，选取一台作为管理主机，在其上执行：

wget -q -O- 'https://download.ceph.com/keys/release.asc' | sudo apt-key add -
#                                  debian-luminous
echo deb https://download.ceph.com/debian-jewel/ $(lsb_release -sc) main | sudo tee /etc/apt/sources.list.d/ceph.list
sudo apt-get update
sudo apt-get install ceph-deploy
 
 
# 也可以通过pip安装
apt install python-pip
pip install ceph-deploy
 
 
# BUG太多，直接Git最新源码安装吧
git clone https://github.com/ceph/ceph-deploy.git
cd ceph-deploy
chmod +x setup.py 
python setup.py install

5.1 安装NTP客户端

为了防止时钟不同步导致问题，建议安装NTP客户端，并保持和NTP服务器的同步。

5.2 创建部署用户

# 在所有节点上执行
ansible k8s -m raw -a 'useradd -d /home/ceph-ops -m ceph-ops'
ansible k8s -m raw -a 'echo "ceph-ops ALL = (root) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/ceph-ops'
ansible k8s -m raw -a 'chmod 0440 /etc/sudoers.d/ceph-ops'
ansible k8s -m raw -a 'echo "ceph-ops:password" | chpasswd'
 
# 在管理节点上执行
# 生成密钥对，默认生成~/.ssh下的id_rsa和id_rsa.pub
ssh-keygen
# 将公钥拷贝到被管理机，便于免密码登陆
ansible k8s -m raw -a "mkdir /home/ceph-ops/.ssh"
ansible k8s -m raw -a "scp -oStrictHostKeyChecking=no root@master-node:/root/.ssh/id_rsa.pub /home/ceph-ops/.ssh/authorized_keys"
ansible k8s -m raw -a "chown -R ceph-ops:ceph-ops /home/ceph-ops/.ssh"

5.3 安装ceph

在集群中的管理主机上，执行：

ceph-deploy install {hostname [hostname] ...} --release {code-name}
# 示例：
ceph-deploy --username ceph-ops install Carbon Radon Neon Boron Xenon --release jewel
ceph-deploy --username ceph-ops install Carbon Radon Neon Boron Xenon  --release luminous
 
 
# 如果网络速度太慢，ceph-deploy会提前退出。这种情况下手工、通过代理安装为好
export http_proxy=http://10.0.0.1:8087
export https_proxy=http://10.0.0.1:8087
 
# 实际上就是安装这些软件
apt install ceph ceph-osd ceph-mds ceph-mon radosgw

5.4 卸载ceph

# 卸载软件
ceph-deploy uninstall {hostname [hostname] ...}
# 示例：
ceph-deploy --username ceph-ops uninstall  Carbon Radon Neon
 
# 下面的命令可以在Ubuntu上执行，清除配置文件
ceph-deploy purge {hostname [hostname] ...}
# 示例：
ceph-deploy --username ceph-ops purge  Carbon Radon Neon

5.5 创建集群

5.5.1 临时配置目录

# 在管理节点上执行：
# 创建一个目录，存放ceph-deploy生成的配置文件
mkdir /tmp/ceph
cd /tmp/ceph

5.5.2 新建集群

# 创建一个新集群，host为mon节点
ceph-deploy --cluster {cluster-name} new {host [host], ...}
 
# 示例
ceph-deploy --username ceph-ops new Xenon

5.5.3 分发配置文件

# 修改好当前目录的ceph.conf，执行下面的命令，分发到所有节点的/etc/ceph目录
# ceph.conf至少要提供网络配置
# public network = 10.0.0.0/16
# cluster network = 10.0.0.0/16
 
# 示例
ceph-deploy --username ceph-ops --overwrite-conf config push Carbon Radon Neon Boron Xenon

5.5.4 配置文件示例

[client]
rbd_cache = true
rbd_cache_max_dirty = 25165824
rbd_cache_max_dirty_age = 5
rbd_cache_size = 268435456
 
[global]
fsid = 9b92d057-a4bc-473e-b6ab-462092fcf205
max_open_files = 131072
mon_initial_members = Carbon, Radon, Neon
mon_host = 10.0.0.100,10.0.1.1,10.0.2.1
osd pool default min size = 1
osd pool default pg num = 384
osd pool default pgp num = 384
osd pool default size = 2
mon_max_pg_per_osd = 256
auth_cluster_required = cephx
auth_service_required = cephx
auth_client_required = cephx
 
[mon]
mon_allow_pool_delete = true
 
[osd]
public network = 10.0.0.0/16
cluster network = 10.0.0.0/16
filestore max sync interval = 15
filestore min sync interval = 10
filestore op thread = 32
journal max write bytes = 1073714824
journal max write entries = 10000
journal queue max bytes = 10485760000
journal queue max ops = 50000
ms_bind_port_max = 7100
osd_client_message_size_cap = 2147483648
osd_crush_update_on_start = true
osd_deep_scrub_stride = 131072
osd_disk_threads = 4
osd_journal_size = 10240
osd_map_cache_bl_size = 128
osd_max_backfills = 4
osd_max_object_name_len = 256
osd_max_object_namespace_len = 64
osd_max_write_size = 512
osd_op_threads = 8
osd_recovery_op_priority = 4

5.6 初始mon

执行下面的命令，部署初始mon节点，并收集key：

ceph-deploy --username ceph-ops mon create-initial
 
# 将在当前目录生成以下文件：
# ceph.client.admin.keyring
# ceph.bootstrap-mgr.keyring
# ceph.bootstrap-osd.keyring
# ceph.bootstrap-mds.keyring
# ceph.bootstrap-rgw.keyring
# ceph.bootstrap-rbd.keyring
 
# 目标主机的/etc/ceph/ceph.conf被创建，如果此文件已经存在，你必须用--overwrite-conf选项重新运行上述命令

5.7 增减mon

# 增加
ceph-deploy mon create {host-name [host-name]...}
# 删除
ceph-deploy mon destroy {host-name [host-name]...}
 
# 示例：
ceph-deploy --username ceph-ops mon create Radon
ceph-deploy --username ceph-ops mon create Carbon

5.8 密钥收集

以ceph-deploy作为工具，将一台主机作为OSD或MDS时，需要收集MON、OSD、MDS的初始keyring：

ceph-deploy gatherkeys {monitor-host}
 
# 示例：
ceph-deploy --username ceph-ops gatherkeys Carbon Radon Neon Boron Xenon

不再使用ceph-deploy或者另外建立一个新集群时，需要删除管理主机、本地目录的密钥：

ceph-deploy forgetkeys

5.9 增加OSD

5.9.1 列出磁盘

ceph-deploy disk list {node-name [node-name]...}
# 示例：
ceph-deploy --username ceph-ops disk list Carbon Radon Neon Boron Xenon

5.9.2 擦净分区

下面的命令可以擦净（删除分区表）磁盘，以供Ceph使用：

ceph-deploy disk zap {osd-server-name} {disk-name}
# 示例（luminous）：
ceph-deploy --username ceph-ops disk zap xenial-100 /dev/vdb
ceph-deploy --username ceph-ops disk zap xenial-100 /dev/vdc
ceph-deploy --username ceph-ops disk zap Carbon     /dev/sdb
ceph-deploy --username ceph-ops disk zap Radon      /dev/sdb
ceph-deploy --username ceph-ops disk zap Neon       /dev/sdb
# 示例（jewel）：
ceph-deploy --username ceph-ops disk zap xenial-100:vdb
ceph-deploy --username ceph-ops disk zap xenial-100:vdc
ceph-deploy --username ceph-ops disk zap Carbon:sdb
ceph-deploy --username ceph-ops disk zap Radon:sdb
ceph-deploy --username ceph-ops disk zap Neon:sdb

警告：所有数据会被删除。

5.9.3 准备OSD

此命令在ceph-deploy 2.0.0中已经废除

使用prepare命令来准备磁盘，会自动创建分区。在大部分OS中，activate会随后自动执行

ceph-deploy osd prepare {node-name}:{data-disk}[:{journal-disk}]
# 示例：
ceph-deploy --username ceph-ops osd prepare --fs-type xfs xenial-100:vdb
ceph-deploy --username ceph-ops osd prepare --fs-type xfs xenial-100:vdc
ceph-deploy --username ceph-ops osd prepare --fs-type xfs Carbon:sdb
ceph-deploy --username ceph-ops osd prepare --fs-type xfs Radon:sdb

建议：将日志存储在独立磁盘中以最优化性能，如果将日志和数据存储在一起，会有损性能。

5.9.4 激活OSD

此命令在ceph-deploy 2.0.0中已经废除

很多操作系统上，不需要手工激活OSD。

ceph-deploy osd activate {node-name}:{data-disk-partition}[:{journal-disk-partition}]
# 示例
ceph-deploy --username ceph-ops osd activate xenial-100:vdb
ceph-deploy --username ceph-ops osd activate xenial-100:vdc
ceph-deploy --username ceph-ops osd activate Carbon:sdb
ceph-deploy --username ceph-ops osd activate Radon:sdb

激活之后，系统运行ceph-osd进程，OSD进入up+in状态。

5.9.5 创建OSD

即prepare + activate：

ceph-deploy osd create {node-name}:{disk}[:{path/to/journal}]
# 示例
ceph-deploy osd create osdserver1:sdb:/dev/ssd1
 
# 示例（luminous）：
ceph-deploy --username ceph-ops osd create --data /dev/vdb --bluestore xenial-100  
ceph-deploy --username ceph-ops osd create --data /dev/vdc --bluestore xenial-100  
ceph-deploy --username ceph-ops osd create --data /dev/sdb --bluestore Carbon
ceph-deploy --username ceph-ops osd create --data /dev/sdb --bluestore Radon
# 指定分区也可以
ceph-deploy --username ceph-ops osd create --data /dev/sda3 --bluestore Carbon

5.10 增加MDS

ceph-deploy --username ceph-ops mds create Carbon

5.11 部署MGR

仅仅luminous支持，否则报错Error EACCES: access denied could not create mgr

ceph-deploy --username ceph-ops mgr create Carbon

5.12 部署RGW

ceph-deploy --username ceph-ops rgw create Radon

默认情况下RGW监听7480端口，你可以验证RGW是否正常工作：

curl http://Carbon:7480

5.13 清除主机

如果只想清除 /var/lib/ceph 下的数据、并保留 Ceph 安装包，可以：

ceph-deploy purgedata {hostname} [{hostname} ...]
# 示例：
ceph-deploy --username ceph-ops purgedata Carbon Radon

如果向同时清除数据、Ceph安装包：

ceph-deploy purge {hostname} [{hostname} ...]

5.14 管理和分发

5.14.1 管理主机

要允许某些主机以管理员权限执行 Ceph 命令，可以：

ceph-deploy admin {host-name [host-name]...}
 
# 示例：
ceph-deploy --username ceph-ops admin Carbon Radon Neon Boron Xenon

上述命令执行后，当前目录中的ceph.client.admin.keyring被分发到所有指定的主机，在这些主机上可以执行ceph -s命令了。

5.14.2 分发配置文件

要将修改过的、当前目录下的配置文件分发给集群内其它主机，可以：

ceph-deploy config push {host-name [host-name]...}

5.14.3 拉取配置文件

要获取某台主机的配置文件，可以：

ceph-deploy config pull {host-name [host-name]...}

6.配置

启动Ceph服务时，初始化进程会启动一系列守护进程，这些进程至少包含两类：

ceph-mon 监控进程
ceph-osd Ceph OSD的守护进程

要使用Ceph文件系统功能，则需要额外运行：

ceph-mds Ceph元数据服务

要使用Ceph对象存储功能，则需要额外运行：

ceph-rgw RADOS网关守护进程

6.1 运行时配置

要列出当前使用的所有配置值，可以访问守护进程的管理套接字。

在节点上执行下面的命令，获得管理套接字的位置：

ceph-conf --name mon.$(hostname -s) --show-config-value admin_socket
# /var/run/ceph/ceph-mon.a.asok

调用下面的命令列出所有配置：

ceph daemon /var/run/ceph/ceph-mon.a.asok config show

对于osd或者其它守护进程，也可以使用上述方式获取运行时配置。

6.2 配置文件

所有守护进程从同一个配置文件ceph.conf中检索自己感兴趣的信息。该配置文件中包含了集群身份、认证配置、集群成员、主机名、主机 IP 地址、Keyring路径、日志路径、数据路径，以及其它运行时选项。

按照以下顺序来搜索，后面的可以覆盖前面的：

编译进二进制文件的默认值
ceph-mon的集群中心配置数据库
本机上的配置文件：
1. /etc/ceph/ceph.conf
2. ~/.ceph/config
3. ./ceph.conf
环境变量：$CEPH_CONF
命令行参数：-c path/path
管理员在运行时设置的选项

一个Ceph进程启动时，它会先从命令行、环境变量、本地配置文件收集配置项，然后连接ceph-mon读取集群中心配置信息，然后启动。

6.3 配置项格式

配置项的名称唯一，标准格式是小写字母 + 下划线

在命令行中指定配置项时，下划线_可以替换为短横线

在配置文件中指定配置项时，下划线可以替换为空格或短横线

6.4 配置项列表

配置项	说明
公共选项 [global]
host	用于指定节点的主机名
mon host	指定mon节点的地址，逗号分隔
auth cluster required	集群身份验证设置，默认值cephx。如果启用，集群守护进程之间必须相互验证身份
auth service required	服务身份验证设置，默认值cephx。如果启用，服务端需要验证客户端身份
auth client required	客户端身份验证设置，默认值cephx。如果启用，客户端需要验证服务端身份
keyring	钥匙串的位置默认值：/etc/ceph/ $c l u s t er .$ name.keyring,/etc/ceph/$cluster.keyring,/etc/ceph/keyring,/etc/ceph/keyring.bin
public network	公共网络配置，CIDR格式，多个则用逗号分隔
cluster network	集群网络配置，CIDR格式，多个则用逗号分隔如果配置了集群网， OSD 将把心跳、对象复制和恢复流量路由到集群网
fsid	存储集群的唯一标识，便于允许在同一套硬件上部署多个集群
max open files	设置操作系统级的 max open fds建议值：131072
fatal signal handlers	如果设置为true，则安装 SEGV 、 ABRT 、 BUS 、 ILL 、 FPE 、 XCPU 、 XFSZ 、 SYS 信号处理器，用于产生有用的日志信息
chdir	进程一旦启动、运行就进入这个目录。默认 /
mon选项 [mon]
mon addr	监听地址:端口，可以针对每个mon.$id段分别配置，或者在mon段下配置：10.0.0.10:6789,10.0.0.11:6789,10.0.0.12:6789
mon data	mon存储数据的路径，默认/var/lib/ceph/mon/ $c l u s t er -$ id
mon initial members	集群初始化监视器ID，逗号分隔。这些MON必须在线以建立quorum，正确设置此参数可能让集群更快的可用
mon osd full ratio	磁盘利用率总计多少认为满了，默认 .95当Ceph集群利用率达到此比率时，作为防止数据丢失的安全措施，它会阻止你读写 OSD注意：1. 删除OSD、OSD out都会导致利用率增加，甚至超过full ratio导致锁死1. 如果一些 OSD 快满了，但其他的仍有足够空间，你可能配错了CRUSH权重
mon osd nearfull ratio	磁盘利用率总计多少认为快满了，默认.85
mon sync timeout	mon从其provider获取下一个更新消息的超时
mon tick interval	监视器的心跳间隔，单位为秒。默认5
mon clock drift allowed	监视器间允许的时钟漂移量。默认.050
mon timecheck interval	和 leader 的时间偏移检查间隔。默认300秒
mon osd min down reports	OSD连续多少次向mon报告某个OSD宕掉，mon才采纳，默认3
mon osd min down reporters	类似上面，mon要求多少个OSD都报告某个OSD宕掉，才采纳，默认1
mon osd min up ratio	把 OSD 标记为 down 前，保持处于 up 状态的 OSD 最小比例。默认.3
mon osd min in ratio	把 OSD 标记为 out 前，保持处于 in 状态的 OSD 最小比例。默认.3
mon osd auto mark in	是否把任何启动中的 OSD 标记为在集群中。默认false
mon osd auto mark auto out in	是否把正在启动、且被自动标记为 out 状态的 OSD 标记为 in 。默认true
mon osd auto mark new in	是否把正在启动的新 OSD 标记为 in 。默认true
mon osd down out interval	在 OSD 停止响应多少秒后把它标记为 down 且 out。默认300
mon osd downout subtree limit	最大可以把什么级别的CRUSH单元标记为out，默认rack
osd选项 [osd]
osd data	osd存储数据的路径，默认/var/lib/ceph/osd/ $c l u s t er -$ id
osd map cache size	OSD map缓存大小，默认500M，建议1024
osd map cache bl size	OSD进程的In-Memory OSD map缓存大小，默认50，建议128
osd heartbeat interval	和其它OSD进行心跳检查的间隔，默认6秒
osd heartbeat grace	多久没有心跳，认为其它OSD宕掉
osd max write size	OSD一次写入的最大尺寸，默认90MB，建议512
osd mkfs options {fs-type}	为OSD新建文件系统时的选项
osd mount options {fs-type}	为OSD挂载文件系统时的选项
osd journal	OSD 日志路径，可以指向文件或块设备（例如SSD分区）默认 /var/lib/ceph/osd/ $c l u s t er -$ id/journal
osd journal size	日志文件的尺寸（MB），如果为0，且日志路径为块设备，则自动使用整个设备推荐最少2G，有的用户则以 10GB 日志尺寸起步。合理的值是：osd journal size = {2 * (期望吞吐量* filestore max sync interval)}期望吞吐量应考虑两个参数：硬盘吞吐量（即持续数据传输速率）、网络吞吐量，例如一个 7200 转硬盘的速度大致是 100MB/s 。硬盘和网络吞吐量中较小的一个是相对合理的吞吐量
osd client message size cap	客户端允许在内存中的最大数据量。默认524288000，建议2147483648
crush location	此OSD的CRUSH location设置
crush location hook	用于生成crush location的钩子
osd max scrubs	OSD 的最大并发洗刷操作数除了为对象复制多个副本外， Ceph 还要洗刷归置组以确保数据完整性。这种洗刷类似对象存储层的 fsck ，对于每个归置组， Ceph 生成一个所有对象的目录，并比对每个主对象及其副本以确保没有对象丢失或错配。轻微洗刷（每天）检查对象尺寸和属性，深层洗刷（每周）会读出数据并用校验和方法确认数据完整性
osd scrub begin hour	被调度的洗刷操作，允许的运行区间起点，默认0
osd scrub end hour	被调度的洗刷操作，允许的运行区间终点，默认24
osd scrub load threshold	系统负载高于该值，不进行洗刷操作，默认0.5
osd scrub min interval	系统负载不高的前提下，多久进行一次洗刷，默认每天一次，606024秒
osd scrub max interval	不论系统负载如何，最大多久进行一次洗刷，默认每周
osd deep scrub interval	深度洗刷的间隔，默认每周
osd deep scrub stride	深度洗刷允许读取的字节数。默认524288，建议131072
osd op threads	OSD 操作线程数， 0 禁用多线程。增大数量可以增加请求处理速度，默认2，建议8增加此线程数会增大CPU开销
osd disk threads	硬盘线程数，用于在后台执行磁盘密集型操作，像数据洗刷和快照修复。默认1，建议4增加此线程数会增大CPU开销
osd max backfills	当集群新增或移除 OSD 时，按照 CRUSH 算法应该重新均衡集群，它会把一些归置组移出或移入多个 OSD 以回到均衡状态。归置组和对象的迁移会导致集群运营性能显著降低，为维持运营性能， Ceph 用 backfilling 来执行此迁移，它可以使得 Ceph 的回填操作优先级低于用户读写请求单个 OSD 允许的最大回填操作数。默认10，建议4
osd backfill full ratio	OSD 的占满率达到多少时拒绝接受回填请求，默认85%
osd recovery op priority	恢复操作优先级，取值1-63，值越高占用资源越高。默认10，建议4
osd recovery delay start	当集群启动、或某 OSD 守护进程崩溃后重启时，此 OSD 开始与其它 OSD 们建立互联（Peering），这样才能正常工作如果某 OSD 崩溃并重启，通常会落后于其他 OSD ，也就是没有同归置组内最新版本的对象。这时， OSD 守护进程进入恢复模式并检索最新数据副本，并更新运行图。根据 OSD 宕掉的时间长短， OSD 的对象和归置组可能落后得厉害，另外，如果挂的是一个失效域（如一个机柜），多个 OSD 会同时重启，这样恢复时间更长、更耗资源为保持性能， Ceph 进行恢复时会限制恢复请求数、线程数、对象块尺寸，这样在降级状态下也能保持良好的性能对等关系建立完毕后， Ceph 开始对象恢复前等待的时间。默认0秒
osd recovery max active	每个OSD同时处理的活跃恢复请求最大数，增大此值能加速恢复，但它们会增加OSD的负担，甚至导致其无法提供服务
osd recovery max chunk	恢复时一次推送的数据块的最大尺寸，可以用于防止网络拥塞
osd recovery threads	数据恢复时的线程数，默认1
osd mount options xfs	OSD的xfs挂载选项，默认rw,noatime,inode64，建议rw,noexec,nodev,noatime,nodiratime,nobarrier
rbd客户端调优 [client]
rbd cache	是否启用RBD缓存，默认true用于用户空间块设备实现——librbd
rbd cache size	RBD缓存大小，默认33554432，建议268435456
rbd cache max dirty	缓存为write-back时允许的最大dirty字节数，如果为0，使用write-through。默认25165824，建议25165824
rbd cache max dirty age	在被刷新到存储盘前dirty数据存在缓存的时间，默认1秒，建议5
filestore选项[osd]**
filestore max inline xattr size	每个对象在文件系统中存储XATTR（扩展属性）的最大尺寸，不得超过文件系统限制。默认值根据底层文件系统自动设置
filestore max inline xattrs	每个对象在文件系统中存储XATTR（扩展属性）的最大数量
filestore max sync interval	filestore 需要周期性地静默（暂停）写入、同步文件系统 —— 创建了一个提交点，然后就能释放相应的日志条目了。较高的同步频率可减小执行同步的时间及保存在日志里的数据量，但是日志利用率较低较低的频率使得后端的文件系统能优化归并较小的数据和元数据写入，因此可能使同步更有效默认5秒。建议15
filestore min sync interval	从日志到数据盘最小同步间隔。默认.01秒，建议10
filestore op threads	并发文件系统操作数。默认2，建议32
filestore flusher	是否启用回写器（Flusher）。回写器强制使用sync file range 来写出大块数据，这样处理可能减小最终同步的代价，禁用回写器有时可能提高性能默认false
filestore flusher max fds	回写器的最大文件描述符数量。默认512
filestore fsync flushes journal data	在fsync时是否也回写日志数据
filestore queue max ops	文件存储在阻止新操作加入队列之前，可以接受的最大操作数。取值示例25000
filestore queue max bytes	文件存储单个操作的最大字节数。取值示例10485760
filestore queue committing max ops	文件存储单次可以提交的最大操作数
filestore queue committing max bytes	文件存储单次可以提交的最大字节数
filestore journal parallel	允许并行记日志，对 btrfs 默认开
filestore journal writeahead	允许预写日志，对 xfs 默认开
journal选项[osd]**
journal dio	启用日志的Direct I/O，要求journal block align=true。默认true
journal aio	使用libaio库进行日志的异步写，要求journal dio =true。0.61+默认true
journal block align	日志按块对齐。默认true
journal max write bytes	日志写操作单次最大字节数。建议1073714824
journal max write entries	日志写操作单次最大条目数。建议10000
journal queue max ops	排队等候日志写的操作最大数。建议50000
journal queue max bytes	排队等候日志写的最大字节数。建议10485760000
journal align min size	对于大于此尺寸的数据，进行对齐操作
journal zero on create	在创建文件系统（ mkfs ）期间用 0 填充整个日志
pool/pg/crush相关 [global]
osd pool default size	对象默认副本份数
osd pool default min size	降级情况下，默认允许写操作的最小可用副本份数
osd pool default pg num	归置组的默认数量
osd pool default pgp num	为归置使用的归置组数量，默认值等同于 mkpool 的 pgp_num 参数。当前 PG 和 PGP 应该相同
mon max pool pg num	每个存储的最大归置组数量。默认65536
mon pg create interval	在同一个 OSD 里创建 PG 的间隔秒数。默认30
mon pg stuck threshold	多长时间无响应，则认为PG卡住了
mon pg min inactive	如果大于此数量的PG处于inactive状态超过mon_pg_stuck_threshold，则显示集群为HEALTH_ERR。默认1
mon pg warn min per osd	如果每OSD平均可用PG低于此数量，则显示集群为HEALTH_WARN。默认30
mon pg warn max per osd	如果每OSD平均可用PG高于此数量，则显示集群为HEALTH_WARN。默认300
osd crush chooseleaf type	在CRUSH 规则内用于 chooseleaf 的桶类型。用序列号而不是名字，默认1
osd crush initial weight	新加入到CRUSH map中的OSD的权重默认情况下，权重是OSD的磁盘容量，单位TB
osd pool default crush rule	创建复制型池时，使用的默认CRUSH规则。默认-1，表示使用ID最低的规则
osd pool erasure code stripe unit	EC池中的对象条带尺寸
osd pool default flags	新存储池的默认标志
ms选项
ms tcp nodelay	禁用 nagle 算法，默认true
ms initial backoff	出错时重连的初始等待时间
ms max backoff	出错重连时等待的最大时间
ms nocrc	禁用网络消息的 crc 校验， CPU 不足时可提升性能
mds选项
mds cache memory limit	MDS缓存最大使用多少内存

6.5 配置变量

变量	说明
$cluster	展开为存储集群的名称，在相同硬件上运行多个集群时有用
$type	展开为守护进程类型，例如mds, osd, or mon
$id	展开为守护进程或者客户端的标识符，对于osd.0其标识符为0
$host	展开为主机名
$name	展开为 $t y p e .$ id
$pid	展开为守护进程的PID

6.6 配置段落

配置文件是INI格式的，可以分为以下段落：

段落	用途
global	这里的配置影响 Ceph 集群里的所有守护进程
osd	影响存储集群里的所有 ceph-osd 进程，覆盖global相同选项
mon	影响集群里的所有 ceph-mon 进程，覆盖global相同选项
mds	影响集群里的所有 ceph-mds 进程，覆盖global相同选项
client	影响所有客户端（如挂载的 Ceph 文件系统、挂载的块设备等等）

你还可以针对特定的实例配置段落：

[osd.1]，针对ID为1的OSD的配置
[mon.HOSTNAME]，针对名称为HOSTNAME的MON的配置

6.7 启动选项

进程连接ceph-mon、进行身份验证、抓取集群中心配置信息时需要一些配置，这些配置必须存放在本地：

选项	说明
mon_host	ceph-mon的主机列表
mon_dns_serv_name	ceph-mon的DNS名称，默认 ceph-mon
mon_data, osd_data, mds_data, mgr_data	守护进程在本地存放数据的路径
keyring, keyfile,key	连接ceph-mon进行身份验证时，使用的凭证

6.8 集群中心配置

ceph-mon集群管理了配置配置选项的数据库，用于供整个集群来消费。为了简化管理，大部分的Ceph选项应该在此数据库中管理。

集群中心配置的分段情况，和上文的配置段落一致。

6.8.1 不使用集群配置

传入命令行选项 **–no-mon-**config，可以让进程不去读取集群中心配置，使用场景：

希望所有配置信息在本地文件中管理
ceph-mon目前宕机，但是需要进行一些维护工作

6.8.2 掩码

集群中心配置的配置项，可以关联一个掩码，用于限定选项应用到哪种守护进程、哪种客户端。例如host:foo，限制foo选项仅仅应用到运行在host上的进程或客户端。

6.8.3 命令

以下命令可以用于修改集群中心配置：

命令	说明
ceph config dump	Dump出整个集群中心配置
ceph config get [who]	获取指定的客户端/守护进程存放在集群中心的配置，例如mds.a
ceph config set [who] [opt] [val]	设置指定客户端/守护进程的配置项，示例： # 启用特定OSD的调试日志ceph config set osd.123debug_osd20
ceph tell [who] config set [opt] [val]	临时设置配置项，目标重启后失效
ceph config show [who]	显示指定客户端/守护进程的当前使用的配置信息，可能和集群中心配置不一样
ceph config assimilate-conf -i -o	从-i选项读取所有配置信息，注入到集群中心配置。任何无法识别、无效的配置项存放到-o

6.9 存储池选项

在运行时，你可以使用 ceph osd pool set命令来修改这些选项：

选项	说明
size	对象副本数
min_size	I/O 需要的最小副本数
crush_rule	此存储池使用的CRUSH规则
compression_algorithm	BlueStore使用的压缩算法，可选值lz4, snappy, zlib, zstd
compression_mode	BlueStore使用的压缩模式，可选值none, passive, aggressive, force
compression_min_blob_size compression_max_blob_size	BlueStore启用压缩的阈值
hashpspool	设置或者取消HASHPSPOOL标记。1设置0取消
nodelete	设置或取消NODELETE标记。1设置0取消
nopgchange	设置或取消NOPGCHANGE标记
nosizechange	设置或取消NOSIZECHANGE标记
write_fadvise_dontneed	设置或取消WRITE_FADVISE_DONTNEED标记
noscrub	设置或取消NOSCRUB标记
nodeep-scrub	设置或取消NODEEP_SCRUB标记
hit_set_type	启用缓存存储池的命中集跟踪，设置命中集类型，生产环境仅仅支持bloom
hit_set_count	为缓存存储池保留的命中集数量。此值越高， OSD消耗的内存越多
hit_set_fpp	bloom 命中集类型的误检率（false positive probability）
cache_target_dirty_ratio	缓存存储池包含的修改（脏）对象达到多少比例时就把它们回写到后端的存储池
cache_target_dirty_high_ratio	缓存存储池内包含的已修改（脏）对象达到什么比例时，缓存层代理就会更快地把脏对象刷回到后端存储池
cache_target_full_ratio	缓存存储池包含的干净对象达到多少比例时，缓存代理就把它们清除出缓存存储池
target_max_bytes	回写（Flushing）或清除（Evicting）对象的阈值，按字节数
target_max_objects	回写（Flushing）或清除（Evicting）对象的阈值，按对象数
scrub_min_interval	在负载低时，洗刷存储池的最大间隔秒数
scrub_max_interval	不管集群负载如何，都要洗刷存储池的最大间隔秒数
deep_scrub_interval	深度洗刷存储池的间隔秒数