Ceph学习笔记

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

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

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

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

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

术语	说明
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） 存储池分为两个类型： Replicated 复制型，对象具有多份拷贝，确保部分OSD丢失时数据不丢失，需要更多的磁盘空间。复制份数可以动态调整，可以置为1 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算法接受的参数包括： Cluster map，也就是硬盘分布的逻辑位置，例如这有多少个机房、多少个机柜、硬盘是如何分布的等等。Cluster map是类似树的结构，子节点是真正存储数据的device，每个device都有id和权重，中间节点是bucket，bucket有多种类型用于不同的查询算法，例如一个机柜一个机架一个机房就是bucket Placement rules，它指定了一份数据有多少备份，数据的分布有什么限制条件（例如同一份数据不能放在同一个机柜里）。每个Rule对应一系列操作： take，选取一个bucket select，选择n个类型为t的项 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份的数据失效，仍然能通过剩下的数据还原出来 纠删码技术在分布式存储系统中的应用主要有三类： 阵列纠删码（Array Code: RAID5、RAID6等）：RAID是EC的特例，RAID5只支持一个盘失效，RAID6支持两个盘失效，而EC支持多个盘失效 RS(Reed-Solomon)里德-所罗门类纠删码 LDPC(LowDensity Parity Check Code)低密度奇偶校验纠删码：目前主要用于通信、视频和音频编码等领域，与RS编码相比，LDPC编码效率要略低，但编码和解码性能要优于RS码以及其他的纠删码

监视器维护集群状态的多种映射—— 包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都自动更新为最新版本。

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 使用HDD作为数据盘
2. 使用SSD作为RockDB元数据盘
3. 使用NVRAM作为RockDB WAL

一些概念：

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

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

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

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

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

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

状态	说明
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 立即接受重分配的归置组会使之过载，用归置组回填可使这个过程在后台开始 回填执行期间，你可能看到以下状态之一： backfill_wait，等待时机，回填尚未开始 backfill_too_full，需要进行回填，但是因存储空间不足而不能完成
Remapped	负责某个PG的Acting Set发生变更时，数据需要从久集合迁移到新集合。此期间老的主OSD仍然需要提供服务，直到数据迁移完成
Stale	默认情况下，OSD每0.5秒会一次报告其归置组、出流量、引导和失败统计状态，此频率高于心跳 如果： 归置组的主 OSD 所在的 Acting Set 没能向MON报告 或者其它MON已经报告，说主 OSD 已 down了 则MONs就会把此归置组标记为 stale 集群运行期间，出现此状态，所有PG的主OSD挂了
Inactive	归置组不能处理读写请求，因为它们在等着一个持有最新数据的 OSD 回到 up 状态
Unclean	归置组里有些对象的副本数未达到期望次数，它们应该在恢复中
Down	归置组的权威副本OSD宕机，必须等待其开机，或者被标记为lost才能继续

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

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

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

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

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

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

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

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的层次，包括节点权重。

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

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

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

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

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

这是一个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。

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

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

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

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

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

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

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

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

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

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

下面是一些简单的例子：

管理守护进程。

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

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

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

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

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

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

管理块设备。

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

清除块设备上的内容：

管理主机。

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

为主机添加/移除标签：

列出主机：

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

删除主机：

修改主机地址：

删除OSD实例：

检查删除OSD操作的进度：

暂停编排器的后台任务

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

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

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

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

升级相关操作：

查看日志：

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

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

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

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

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

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

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

列出现有节点：

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

即prepare + activate：

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

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

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

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

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

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

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

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

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

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

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

1. ceph-mds Ceph元数据服务

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

1. ceph-rgw RADOS网关守护进程 

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

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

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

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

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

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

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

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

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

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

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

配置项	说明
公共选项 [global]
host	用于指定节点的主机名
mon host	指定mon节点的地址，逗号分隔
auth cluster required	集群身份验证设置，默认值cephx。如果启用，集群守护进程之间必须相互验证身份
auth service required	服务身份验证设置，默认值cephx。如果启用，服务端需要验证客户端身份
auth client required	客户端身份验证设置，默认值cephx。如果启用，客户端需要验证服务端身份
keyring	钥匙串的位置 默认值：/etc/ceph/$cluster.$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/$cluster-$id
mon initial members	集群初始化监视器ID，逗号分隔。这些MON必须在线以建立quorum，正确设置此参数可能让集群更快的可用
mon osd full ratio	磁盘利用率总计多少认为满了，默认 .95 当Ceph集群利用率达到此比率时，作为防止数据丢失的安全措施，它会阻止你读写 OSD 注意： 删除OSD、OSD out都会导致利用率增加，甚至超过full ratio导致锁死 如果一些 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/$cluster-$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/$cluster-$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	系统负载不高的前提下，多久进行一次洗刷，默认每天一次，60*60*24秒
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缓存最大使用多少内存

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

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

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

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

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

进程连接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进行身份验证时，使用的凭证

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

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

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

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

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

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

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

在运行时，你可以使用 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	深度洗刷存储池的间隔秒数

Ubuntu系统下，基于ceph-deploy部署集群后，可以用这种方法来操控集群。

列出节点上所有Ceph进程：

启动节点上所有Ceph进程：

启动节点上特定类型的Ceph进程： 

启动特定类型的Ceph进程的某个实例：

停止特定类型的Ceph进程的某个实例：

在 CentOS 、 Redhat 、 Fedora 和 SLES 发行版上可以通过传统的 sysvinit 运行 Ceph ， Debian/Ubuntu 的较老的版本也可以用此方法。

命令格式：

执行 ceph status或则 ceph -s可以查看集群的状态：

1. active+clean：说明集群健康运行
2. undersized+degraded：如果有OSD节点宕机，可能进入此状态。降级后还是可以正常读写数据
3. undersized+degraded+peered：如果超过min size要求的OSD宕机，则不可读写，显示为此状态。min size默认2，副本份数默认3。执行下面的命令可以修改min size：
   
   Shell

   1	ceph osd pool set rbd min_size 1

   peered相当于已经配对（PG - OSDs），但是正在等待OSD上线

4. remapped+backfilling：默认情况下，OSD宕机5分钟后会被标记为out状态，Ceph认为它已经不属于集群了。Ceph会按照一定的规则，将已经out的OSD上的PG重映射到其它OSD，并且从现存的副本来回填（Backfilling）数据到新OSD

执行 ceph health可以查看简短的健康状态。

执行 ceph -w可以持续的监控发生在集群中的各种事件。

执行命令 ceph df可以查看集群的数据用量及其在存储池内的分布情况：

通过PG这个中间层，Ceph确保了数据不会被绑死在某个特定的OSD。要追踪错误根源，你需要检查归置组、以及底层的OSD。

执行下面的命令，获取最简短的OSD状态：

执行 ceph osd dump则可以获得详细信息，包括在CRUSH map中的权重、UUID、是in还是out：

执行 ceph osd tree可以在OSD树中打印各OSD的位置、状态、权重。如果OSD的in数量大于up数量，可以通过此命令快速定位：

执行命令 ceph pg stat可以查看全局性的PG统计信息。

可以获取PG列表：

执行下面的命令可以查看PG到OSD的映射关系：

执行 ceph status也可以看到PG的统计性信息。

执行 ceph pg 1.13d query可以查看某个PG的非常细节的信息。

导出monmap：

打印monmap的内容：

从monmap中删除一个MON：

添加一个MON到monmap中：

导入monmap到MON节点：

一旦启动了 OSD ，其状态就变成了 up+in ，此时可以通过ceph -w来观察数据迁移。归置组状态会变为active, some degraded objects，最终变回active+clean

删除OSD之前，应该评估集群容量，保证操作之后，集群不会到达 near full 比率

踢出OSD后，Ceph会进行数据迁移，达到再平衡。归置组状态会变为active, some degraded objects，最终变回active+clean。

对于某些小型测试集群，踢出一个OSD即导致CRUSH进入临界状态，某些归置组一直卡在active+remapped状态。如果遇到这种情况，你可以：

等待数据迁移完毕后，再将OSD踢出。 

你可能需要更新CRUSH map才能让新进入的OSD接受数据：

标记OSD为lost，可能导致数据丢失，谨慎：

Ceph不允许向满的 OSD 写入数据，以免丢失数据。在运营着的集群中，你应该能收到集群空间将满的警告。mon osd full ratio 默认为 0.95 ，也就是说达到 95% 时它将阻止客户端写入数据； mon osd backfillfull ratio 默认为 0.90 ，也就是说达到容量的 90% 时它会阻塞，防止回填启动； OSD 将满比率默认为 0.85 ，也就是说达到容量的 85% 时它会产生健康警告。

使用下面的命令临时修改设置，否则你可能没有机会清理不需要的RBD以腾出空间：

首先，在/var/lib/ceph/mds/mds.N创建一个数据挂载点。N是MDS的ID，通常就是主机名。

然后，修改Ceph配置，添加一个mds段。修改完毕后进行配置分发：

 如果启用了CephX，需要创建认证密钥：

执行下面的命令将目标mds标记为宕机：

移除MDS的/var/lib/ceph/mds/ceph-NAME下对应目录，然后，删除/etc/systemd/system/ceph-mds.target.wants/下的对应项目：

如果服务是通过/etc/init.d/ceph加载的，则：

查看守护进程的简短状态：

你可以使用多种方式来引用一个MDS守护进程：

和MDS进程的Standby行为相关的配置项包括：

如果不进行任何配置，没有持有Rank的那些MDS进程，可以作为任何Rank的Standby。

配置示例：

标记当前活动MDS为失败，触发故障转移：

要创建一个文件系统，你至少需要两个存储池，一个存放数据，另外一个存放元数据。注意：

1. 元数据池的副本份数要设置的高，因为任何元数据的丢失都会导致整个文件系统不可用
2. 元数据池应该使用高速存储，例如SSD，因为这对客户端操作的延迟有直接影响

示例：

创建了文件系统之后，在Luminous版本中，集群状态中显示：

查看CephFS的详细状态，包括MDS列表、Rank列表等：

要获取某个文件系统的信息，可以：

如果集群中有多个文件系统，而客户端在挂载时没有明确指定使用哪个，则使用默认文件系统：

EC池可以作为Ceph的数据池，但是需要启用overwirte：

注意：EC池不能用来存储元数据。

CephFS支持对任何一个子目录进行配额。但是，需要注意以下限制：

1. 需要客户端协作，因此被篡改过的客户端可以突破配额
2. 配额不是非常精确的
3. 内核客户端，仅仅在4.17+才支持配额。用户空间客户端fuse、libcephfs都支持配额

设置配额（设置为0则移除配额）：

查看配额：

你可以直接使用Linux内核提供的驱动来挂载CephFS：

如何启用了CephX，需要指定访问密钥，否则会报22错误：

如果报can't read superblock，说明客户端内核不支持。

要实现自动挂载，你需要修改fstab：

要在用户空间挂载CephFS，你需要：

1. 将Ceph配置文件拷贝到客户端，命名为/etc/ceph/ceph.conf
2. 将Keyring拷贝到客户端，命名为/etc/ceph/ceph.keyring：
   
   Shell

   1	sudo scp -i ~/Documents/puTTY/gmem.key root@xenon.gmem.cc:/etc/ceph/ceph.client.admin.keyring /etc/ceph/ceph.keyring

3. 执行挂载：
   
   Shell

   1 2 3 4

   sudo ceph-fuse -m 10.0.1.1:6789 /mnt/cephfs # ceph-fuse[847]: starting ceph client                                                                                                                                                     # 2018-06-07 19:18:25.503086 7fa5c44e1000 -1 init, newargv = 0x7fa5cd643b40 newargc=9                                                                                                       # ceph-fuse[847]: starting fuse

如果有多个CephFS，你可以为ceph-fuse指定命令行选项--client_mds_namespace，或者在客户端的ceph.conf中添加client_mds_namespace配置。

要实现自动挂载，你需要修改fstab：

创建存储池之后，在管理节点上，使用rbd工具来初始化池：

要取消配额，设置为0即可。 

镜像就是块设备，所谓块是一系列连续的字节序列（例如512KB）。基于块的存储接口，是磁盘、CD、软盘、甚至磁带都使用的，是存储对象最广泛使用的方式。

Ceph的块设备具有以下特点：thin-provisioned（精简配备）、可改变大小、跨越多OSD存储。

如果不指定池名称，则列出默认池中的镜像。

下面的命令可以列出池中延迟删除的镜像：

注意：rbd info输出的是thin provisioning的大小，不是实际磁盘空间占用。

除了上面的命令，还可以：

可以看到什么客户端在使用（watch）镜像：

如果不指定存储池，则在默认池中创建镜像。

从Jewel开始，RBD镜像可以异步的跨越两个集群进行镜像（Mirroring）。通过配置，你可以镜像池中的所有、或者一部分镜像。

mode取值：

1. pool，池中所有启用了journaling特性的镜像都被复制
2. image，只有明确配置的镜像才进行复制 

Dump出所有PG：

Dump出卡在指定状态中的PG的统计信息：

参考官网的算法进行计算。

执行调整之前，必须保证集群处于健康状态。

为避免调整PG数量导致业务性能受到严重影响，应该调整一些参数：

其它相关的参数还包括：

按照2的幂进行翻倍增长，例如原来32个，可以先调整为64个。

注意：不要一下子把PG设置为太大的值，这会导致大规模的rebalance，影响系统性能。

等到上一步操作后，集群变为Active+Clean状态后，再将pgp_num设置的和pg_num一致。 

推送修改后的配置文件后，重启RGW服务：

RGW在index_pool池中存放桶（Bucket）索引数据，此池默认名为.rgw.buckets.index。

从0.94版本开始，支持对桶索引进行分片，避免单个桶中对象数量过多时出现性能瓶颈：

你可以在global段配置上面的选项。 

要使用RGW的RESTful接口，你需要：

1. 创建初始的S3接口的用户
2. 创建Swift接口的子用户
3. 验证用户可以访问网关

要创建S3接口用户，需要在网关机上执行：

access_key、secret_key会打印在屏幕上，要访问网关，客户端必须提供这两个key：

要创建Swift子用户，需要在网关机上执行：

你需要为Swift子用户创建secret key：

现在，你可以用自己熟悉的语言的S3、Swift客户端来验证用户是否可用。 

要创建桶，你需要使用合法的User ID + AWS Access Key发起请求，Ceph没有提供对应的命令行。需要注意以下约束：

1. 桶名称必须唯一
2. 桶名称不能格式化为IP地址
3. 桶名称在3-63字符之间
4. 桶名称不得包含大写字母、下划线，但是可以包含短横线
5. 桶名称必须以小写字母或数字开头
6. 桶名称必须由一系列的标签组成，每个标签用点号.分隔

我们可以使用MinIO客户端创建桶：

现在通过Rgw命令行可以看到这个桶：

Ceph默认开启了cephx协议，加密认证需要消耗少量的资源。

启用cephx后，Cephe会自动在包括/etc/ceph/ceph.$name.keyring在内的位置寻找钥匙串，你可以指定keyring选项来修改默认路径，但是不推荐。

在禁用了cephx的集群上，启用它的步骤为：

1. 创建 client.admin 密钥：
   
   Shell

   1 2	# 如果你使用的自动部署工具已经生成此文件，切勿执行此命令，会覆盖 ceph auth get-or-create client.admin mon 'allow *' mds 'allow *' osd 'allow *' -o /etc/ceph/ceph.client.admin.keyring

2. 创建mon集群所需的钥匙串、密钥：
   
   Shell

   1	ceph-authtool --create-keyring /tmp/ceph.mon.keyring --gen-key -n mon. --cap mon 'allow *'

3. 将上述钥匙串复制到所有mon的mon data目录，例如：
   
   Shell

   1	cp /tmp/ceph.mon.keyring /var/lib/ceph/mon/ceph-a/keyring

4. 为每个OSD生成密钥：
   
   Shell

   1	ceph auth get-or-create osd.{$id} mon 'allow rwx' osd 'allow *' -o /var/lib/ceph/osd/ceph-{$id}/keyring

5. 为每个 MDS 生成密钥：

   Shell

   1	ceph auth get-or-create mds.{$id} mon 'allow rwx' osd 'allow *' mds 'allow *' -o /var/lib/ceph/mds/ceph-{$id}/keyring

6. 添加以下内容到配置文件的global段：

   Shell

   1 2 3

   auth cluster required = cephx auth service required = cephx auth client required = cephx

7. 启动或重启Ceph集群：  

   Shell

   1 2 3

   # 停止当前节点上的所有Ceph守护进程 sudo stop ceph-all sudo start ceph-all

修改配置文件global段：

然后重启Ceph集群。 

任何时后你都可以Dump、反编译、修改、编译、注入CURSH map。如果要完全基于手工方式管理，不使用自动生成的CRUSH map，可以设置：

执行命令 ceph osd crush dump，可以将整个CRUSH导出为可读形式：

执行下面的命令，导出当前Map：

然后，需要反编译为文本：

源文件内容示例：

我们可以根据实际需要，对源文件进行修改，例如将算法改为straw，解决CentOS 7上CEPH_FEATURE_CRUSH_V4 1000000000000特性不满足的问题：

修改源文件完毕后，执行下面的命令编译：

最后，注入最新编译的Map：

默认情况下，Ceph自动根据硬件类型，设置OSD的设备类型为hdd, ssd或nvme。你可以手工进行设置：

列出集群中的CRUSH rule：

Dump出规则的内容：

创建一个规则，仅仅使用指定类型的设备：

为存储池指定所使用的规则：

CRUSH rule的语法如下：

示例一，将主副本存放在SSD中，第二副本存放在HDD中：

 示意二，在第一个机架上存储两个副本，第二个机架上存储一个副本：

如果要添加OSD到CRUSH map中，执行：

使用CRUSH rule，可以限定某个Pool仅仅使用一部分OSD：

前提条件：

1. 集群处于OK状态
2. 所有PG处于active+clean状态

步骤，针对每个需要改变尺寸的OSD，一个个的处理：

1. 修改Cephe配置，设置 osd_journal_size = NEWSIZE
2. 禁止数据迁移（防止OSD进入out状态）： ceph osd set noout
3. 停止目标OSD实例
4. 刷出缓存： ceph-osd -i  OSDID --flush-journal
5. 删除日志：
   
   Shell

   1 2 3

   # 基于Helm部署时，需要到宿主机上的osd_directory下寻找对应目录 cd /var/lib/ceph/osd/ceph-osd.OSDID rm journal

6. 创建一个新的日志文件： ceph-osd --mkjournal -i OSDID
7. 启动OSD
8. 验证新的日志尺寸被使用：
   
   Shell

   1 2	# Helm安装的情况下，需要在OSD容器中执行 ceph --admin-daemon /var/run/ceph/ceph-osd.OSDID.asok config get osd_journal_size

9. 确保集群处于OK状态，所有PG处于active+clean状态 

处理完所有OSD后，执行：  ceph osd unset noout，清除noout标记

要动态、临时（重启后消失）的修改组件的参数，可以使用tell命令。

可以将RBD上的Watcher加入黑名单，这样可以解除RBD的Watcher，再其它机器上挂载RBD：

注意：详尽的日志每小时可能超过 1GB ，如果你的系统盘满了，这个节点就会停止工作。

可以为各子系统定制日志级别：

子系统列表：

子系统	日志级别	内存日志级别
default	0	5
lockdep	0	1
context	0	1
crush	1	1
mds	1	5
mds balancer	1	5
mds locker	1	5
mds log	1	5
mds log expire	1	5
mds migrator	1	5
buffer	0	1
timer	0	1
filer	0	1
striper	0	1
objecter	0	1
rados	0	5
rbd	0	5
rbd mirror	0	5
rbd replay	0	5
journaler	0	5
objectcacher	0	5
client	0	5
osd	1	5
optracker	0	5
objclass	0	5
filestore	1	3
journal	1	3
ms	0	5
mon	1	5
monc	0	10
paxos	1	5
tp	0	5
auth	1	5
crypto	1	5
finisher	1	1
reserver	1	1
heartbeatmap	1	5
perfcounter	1	5
rgw	1	5
rgw sync	1	5
civetweb	1	10
javaclient	1	5
asok	1	5
throttle	1	1
refs	0	0
compressor	1	5
bluestore	1	5
bluefs	1	5
bdev	1	3
kstore	1	5
rocksdb	4	5
leveldb	4	5
memdb	4	5
fuse	1	5
mgr	1	5
mgrc	1	5
dpdk	1	5
eventtrace	1	5

如果磁盘空间有限，可以配置/etc/logrotate.d/ceph，加快日志滚动：

然后设置定时任务，定期检查并清理： 

 

为了将Ceph部署到K8S集群中，可以利用ceph-helm项目。 目前此项目存在一些限制：

1. public和cluster网络必须一样
2. 如果Storage的用户不是admin，你需要在Ceph集群中手工创建用户，并在K8S中创建对应的Secrets
3. ceph-mgr只能运行单副本

执行下面的命令把ceph-helm添加到本地Helm仓库：

可用值的说明如下：

Ext4文件系统上基于目录的OSD配置，覆盖值示例：

为Ceph创建名字空间：

创建RBAC资源：

为了部署Ceph集群，需要为K8S集群中，不同角色（参与到Ceph集群中的角色）的节点添加标签： 

1. ceph-mon=enabled，部署mon的节点上添加
2. ceph-mgr=enabled，部署mgr的节点上添加
3. ceph-osd=enabled，部署基于设备、基于目录的OSD的节点上添加
4. ceph-osd-device-NAME=enabled。部署基于设备的OSD的节点上添加，其中NAME需要替换为上面 ceph-overrides.yaml中的OSD设备名，即：
   1. ceph-osd-device-dev-vdb=enabled
   2. ceph-osd-device-dev-vdc=enabled

对应的K8S命令：

确保所有Pod正常运行：

其中MDS、RGW的Pod处于Pending状态，这是由于没有给任何节点添加标签：

现在从监控节点，检查一下Ceph集群的状态：

如果K8S集群没有默认StorageClass，可以设置：

这样没有显式声明StorageClass的PVC将自动通过ceph-rbd进行卷提供。 

可以先使用ceph命令尝试创建RBD并挂载：

确认Ceph RBD可以挂载、读写后，创建一个PVC：

查看PVC是否绑定到PV：

需要在其它命名空间中使用此存储池时，拷贝一下Secret：

此外，如果要重新安装，一定要把所有节点的一下目录清除掉：

只需要安装相应的Provisioner，配置适当的StorageClass即可。示例：

1. Provisioner：https://git.gmem.cc/alex/helm-charts/src/branch/master/ceph-provisioners
2. 安装脚本：https://git.gmem.cc/alex/k8s-init/src/branch/master/4.infrastructure/0.ceph-external.sh

Kubernetes卷的动态Provisioning，目前需要依赖于external-storage项目，K8S没有提供内置的Provisioner。此项目存在不少问题，生产环境下可以考虑静态提供。

Provisioner会自动在Ceph集群的默认CephFS中创建“卷”，Ceph支持基于libcephfs+librados来实现一个基于CephFS目录的虚拟卷。

你可以在默认CephFS中看到volumes/kubernetes目录。kubernetes目录对应一个虚拟卷组。每个PV对应了它的一个子目录。

1. 监控节点对于集群的正确运行非常重要，应当为其分配独立的硬件资源。如果跨数据中心部署，监控节点应该分散在不同数据中心或者可用性区域
2. 日志可能会让集群的吞吐量减半。理想情况下，应该在不同磁盘上运行操作系统、OSD数据、OSD日志。对于高吞吐量工作负载，考虑使用SSD进行日志存储
3. 纠删编码（Erasure coding）可以用于存储大容量的一次性写、非频繁读、性能要求不高的数据。纠删编码存储消耗小，但是IOPS也降低
4. 目录项（Dentry）和inode缓存可以提升性能，特别是存在很多小对象的情况下
5. 使用缓存分层（Cache Tiering）可以大大提升集群性能。此技术可以在热、冷Tier之间自动的进行数据迁移。为了最大化性能，请使用SSD作为缓存池、并且在低延迟节点上部署缓存池
6. 部署奇数个数的监控节点，以便仲裁投票（Quorum Voting），建议使用3-5个节点。更多的节点可以增强集群的健壮性，但是mon之间需要保持数据同步，这会影响性能
7. 诊断性能问题的时候，总是从最底层（磁盘、网络）开始，然后再检查块设备、对象网关等高层接口
8. 在大型集群里用单独的集群网络（Cluster Newwork）可显著地提升性能和安全性

1. 限制最大文件大小，创建极大的文件会导致删除过程很缓慢
2. 避免在生产环境下使用试验特性。你应该使用单个活动MDS、不使用快照（默认如此）
3. 避免增大max_mds，可能导致大于1个的MDS处于Active
4. 客户端选择：
   1. FUSE，容易使用、容易升级和服务器集群保持一致
   2. 内核，性能好
   3. 不同客户端的功能并不完全一致，例如FUSE支持客户端配额，内核不支持
5. 对于Ceph 10.x，最好使用4.x内核。如果必须使用老内核，你应该使用FUSE作为客户端

OSD需要消耗CPU资源，可以将其绑定到一个核心上。如果使用纠删码，则需要更多的CPU资源。此外，集群处于Recovery状态时，OSD的CPU消耗显著增加

MON不怎么消耗CPU资源，几个G内存的单核心物理机即可。

MDS相当消耗CPU资源，考虑4核心或更多CPU。如果依赖于CephFS处理大量工作，应当分配专用物理机

MON/MDS需要不少于2G内存。OSD通常需要1G内存（和存储容量有关）。此外，集群处于Recovery状态时，OSD的内存消耗显著增加，因此配备2G内存更好

最好具有万兆网络，公共网络、集群网络需要物理隔离（双网卡连接到独立交换机）。对于数百TB规模的集群，千兆网络也能够正常工作

集群网络往往消耗更多的带宽，此外，高性能的集群网络对于Recovery的效率很重要。

如果交换机支持，应当启用Jumbo帧，可以提升网络吞吐量。

在生产环境下，最好让OSD使用独立的驱动器，如果和OS共享驱动，最好使用独立的分区。

通常使用SATA SSD作为日志存储，预算足够可以考虑PCIE SSD。Intel S3500的4K随机写 IOPS可达10K+

关于RAID：

1. 最好不要使用RAID
2. 如果有RAID卡，并且磁盘数量太多，而对应的内存数量不足（每个OSD大概需要2G内存），可以RAID0
3. 不要使用RAID5，因为随机IO的性能降低

关于filestore：

1. 建议使用SSD存储日志，以减少访问时间、读取延迟，实现吞吐量的显著提升
2. 可以为创建SSD分区，每个分区作为一个OSD的日志存储，但是最好不要超过4个

1. 启用超线程Hyper-Threading技术
2. 关闭节能
3. 关闭NUMA

底层文件系统的稳定性和性能对于Ceph很重要。在开发、非关键部署时可以使用btrfs，这也是未来的方向。关键的生产环境下应该使用XFS。

在高可扩容性的存储环境下，XFS和btrfs相比起ext3/4有很大优势。XFS和btrfs都是日志式文件系统，更健壮，容易从崩溃、断电中恢复。日志文件系统会在执行写操作之前，把需要进行的变更记录到日志。

OSD依赖于底层文件系统的扩展属性（Extended Attributes，XATTRs），来存储各种内部对象状态和属性。XFS支持64KB的XATTRs，但是ext4就太小了，你应该为运行在ext4上的OSD配置：

关于文件系统的一些知识：

1. XFS 、 btrfs 和 ext4 都是日志文件系统
2. XFS很成熟
3. btrfs相对年轻，他是一个写时复制（COW）文件系统，因而支持可写文件系统快照。此外它还支持透明压缩、完整性校验

PG的数量应当总是和PGP相同。PGP是为了实现定位而创建的PG。再平衡仅仅再pgp_num被修改后才会触发，仅仅修改pg_num不会触发。

随着OSD数量的变化，选取适当的PG数量很重要。因为PG数量对集群行为、数据持久性（Durability，灾难性事件发生时保证数据堡丢失）有很大影响。此外，归置组很耗计算资源，所以很多存储池x很多归置组会导致性能下降。建议的取值：

1. 对于小于5个OSD的集群：设置为128
2. 5-10个OSD的集群：设置为512
3. 10-50个OSD的集群：设置为1024
4. 超过50个OSD的集群，需要自己权衡，利用pgcalc来计算适合的PG数量

《Ceph分布式存储学习指南》一书中建议的PG数量算法：

每个池的PG数量 = OSD总数 * 100 / 最大副本数 / 池数

计算结果需要向上舍入到2的N次幂。此外该书倾向于让所有池具有相同的PG数量。

1. 加入新的OSD后，考虑设置权重为0，然后逐渐增加权重，这样可以避免性能下降

DigitalOcean开源了Ceph的Exporter，本文使用gmemcc的fork版本。Ceph Exporter和MON节点通信，所有信息都通过rados_mon_command()调用获得。

此Exporter可以在任意Ceph客户端节点上运行，和任何形式的Ceph客户端一样，你需要提供ceph.conf、ceph.USER.keyring两个配置文件。

选项	说明
telemetry.addr	监听的地址和端口，示例：*:9100
telemetry.path	查询指标的URL路径，示例：/metrics
ceph.config	Ceph配置文件路径
ceph.user	使用的Ceph用户，示例：admin
exporter.config	Ceph Exporter配置文件的位置，示例：/etc/ceph/exporter.yml
rgw.mode	是否收集RGW的指标：0禁用，1启用，2后台

你可以直接使用预构建好的镜像： digitalocean/ceph_exporter:2.0.1-luminous

或者，从源码构建：

对于Luminous12.2或者Mimic13.2版本，MGR已经内置了Prometheus模块，不再需要ceph_exporter了。

执行下面的命令启用Prometheus模块：

然后，你就可以访问任意MGR节点的http://MGR_HOST:9283/metrics，抓取指标了。Prometheus配置示例：

Grafana仪表盘可以参考这个示例：https://grafana.com/dashboards/7056

R表示必须支持的特性，S表示该版本内核可以支持，-*-表示从这个版本开始支持。

Feature	OCT	3.8	3.9	3.10	3.14	3.15	3.18	4.1	4.5	4.6
CEPH_FEATURE_NOSRCADDR	2	R	R	R	R	R	R	R	R	R
CEPH_FEATURE_SUBSCRIBE2	10									-R-
CEPH_FEATURE_RECONNECT_SEQ	40			-R-	R	R	R	R	R	R
CEPH_FEATURE_PGID64	200		R	R	R	R	R	R	R	R
CEPH_FEATURE_PGPOOL3	800		R	R	R	R	R	R	R	R
CEPH_FEATURE_OSDENC	2000		R	R	R	R	R	R	R	R
CEPH_FEATURE_CRUSH_TUNABLES	40000	S	S	S	S	S	S	S	S	S
CEPH_FEATURE_MSG_AUTH	800000						-S-	S	S	S
CEPH_FEATURE_CRUSH_TUNABLES2	2000000		S	S	S	S	S	S	S	S
CEPH_FEATURE_REPLY_CREATE_INODE	8000000		S	S	S	S	S	S	S	S
CEPH_FEATURE_OSDHASHPSPOOL	40000000		S	S	S	S	S	S	S	S
CEPH_FEATURE_OSD_CACHEPOOL	800000000				-S-	S	S	S	S	S
CEPH_FEATURE_CRUSH_V2	1000000000				-S-	S	S	S	S	S
CEPH_FEATURE_EXPORT_PEER	2000000000				-S-	S	S	S	S	S
CEPH_FEATURE_OSD_ERASURE_CODES***	4000000000
CEPH_FEATURE_OSDMAP_ENC	8000000000					-S-	S	S	S	S
CEPH_FEATURE_CRUSH_TUNABLES3	20000000000					-S-	S	S	S	S
CEPH_FEATURE_OSD_PRIMARY_AFFINITY	20000000000					-S-	S	S	S	S
CEPH_FEATURE_CRUSH_V4 ****	1000000000000							-S-	S	S
CEPH_FEATURE_CRUSH_TUNABLES5	200000000000000								-S-	S
CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING	400000000000000								-S-	S

代码	版本
Luminous	12
Jewel	10
已归档版本
argonaut	0.48
bobtail	0.56
Cuttlefish	0.61
Dumpling	0.67
Emperor	0.72
Firefly	0.80
Giant	0.87
Hammer	0.94
Infernalis	9.2.0
Kraken	11.0.2

1. Ceph From Scratch
2. CEPH CONTROL COMMANDS

1. 纠删码支持
2. 缓存分层
3. 键/值 OSD后端
4. 独立的RadosGW（使用civetweb）

1. LRC纠删码
2. CephFS日志恢复，诊断工具

1. RGW对象版本化
2. 对象桶分片
3. Crush straw2算法

1. 纠删码到达稳定，支持很多新特性
2. 支持Swift API新特性，例如对象过期设置

1. CephFS到达稳定
2. RGW多站点可达（支持主/主配置）
3. AWS4兼容
4. RBD镜像（mirroring）
5. 引入BlueStore

1. BlueStore到达稳定
2. AsyncMessenger
3. RGW：通过ES来索引元数据
4. S3桶生命周期API支持
5. RGW：支持导出为NFS v3接口
6. Rados支持在基于纠删码的池上进行overwrite操作
7. 基于纠删码池的RBD卷

1. 集成Web仪表盘Ceph Dashboard
2. 直接管理裸设备的BlueStore到达稳定并且作为默认选项
3. 纠删码池完全支持overwirte，可以和CephFS/RDB一起使用
4. 引入组件ceph-mgr，如果该组件停止，则指标不会更新，某些依赖于指标的请求，例如ceph df，无法工作
5. 可扩容能力提升，可部署10000OSD的集群
6. 每个OSD支持关联一个设备类（例如hdd/ssd），允许CRUSH规则将数据简单地映射到系统中的设备的子集。通常不需要手动编写CRUSH规则或手动编辑CRUSH
7. 支持优化CRUSH权重，以保持OSD之间数据的近乎完美的分布
8. OSD可以根据后端设备是HDD还是SSD来调整其默认配置
9. RGW引入了上传对象的服务器端加密，用于管理加密密钥的三个选项有：自动加密（仅推荐用于测试设置），客户提供的类似于Amazon SSE-C规范的密钥，以及通过使用外部密钥管理服务
10. RGW具有初步的类似AWS的存储桶策略API支持。现在，策略是一种表达一系列新授权概念的方式。未来，这将成为附加身份验证功能的基础，例如STS和组策略等
11. RGW通过使用rados命名空间合并了几个元数据索引池
12. 引入组件rbd-mirror，负责RBD卷的镜像复制
13. rbd trash命令支持延迟的镜像删除
14. 镜像可以通过rbd mirroringreplay delay配置选项支持可配置的复制延迟
15. 多Active MDS到达稳定状态

1. 引入一个新的、全功能和美观的仪表盘 Dashboard V2
2. RADOS：配置选项可被mon中心化存储和管理
3. RADOS：在恢复和再平衡时，mon使用的磁盘大大减小
4. RADOS：引入一个异步恢复特性，减少在OSD从错误恢复期间，请求的tail latency
5. RGW：支持将一个Zone（或者Buckets的子集）复制到外部云服务，例如S3
6. RGW：支持S3多因子身份验证
7. RGW：前端Beast到达stable
8. CephFS：使用多MDS时快照功能到达stable
9. RBD：镜像克隆不需要显式的protect/unprotect步骤
10. RBD：镜像支持深克隆（包含parent镜像、关联快照的数据的克隆）到新池，支持修改数据布局

1. 仪表盘：增加很多新功能，全方位的查看各种指标，对Ceph进行管理
2. RADOS：每个池的PG数量 ，现在可以随时减小了。集群可以根据用量和管理员的提示，自动优化PG数量
3. RADOS：v2 wire protocol支持传输加密
4. RADOS：mon/osd使用的物理设备的健康指标（例如SMART）可以得到跟踪，并且在预期出现磁盘失败前进行警告
5. RADOS：在recovery/backfill时，OSD更有效的优先恢复重要的PG、对象
6. RADOS：例如磁盘失败后的恢复，这样长期运行的后台操作的进度，在ceph status中报告
7. RGW：Beast替换civetweb作为默认Web前端
8. CephFS：MDS稳定性得到很大优化，特别是针对大缓存、长时间运行的具有大内存的客户端
9. CephFS：在Rook管理的环境下，CephFS可以通过NFS-Ganesha集群暴露出去
10. CephFS：支持查询进行中的针对MDS的scrub的进度
11. RBD：镜像可以在最小宕机时间内进行迁移，这可以支持在池之间迁移镜像、修改镜像布局
12. RBD：rbd perf image iotop 以及 rbd perf image iostat命令可以提供iostat风格的、针对所有RBD镜像的监控
13. RBD：ceph-mgr的Prometheus Exporter支持暴露所有RBD镜像的IO监控指标
14. RBD：在一个池中，可以使用命名空间来隔离RBD，实现多租户

1. 新的工具cephadm，用于支持容器化部署
2. Health警告可以被临时/永久的静默
3. Dashboard：UI增强、安全性增强
4. 管理功能的增强
5. RADOS：从N版引入的PG括缩，默认启用
6. RADOS：Bluestore包含了多项改进和性能增强
7. RBD：镜像支持一种新的，基于快照的模式，不再依赖于journaling特性
8. RBD：克隆操作保持源镜像的稀疏性（sparseness）
9. RBD：改进了rbd-nbd 工具，可以使用新的内核特性
10. RBD：缓存性能增强

创建新CephFS报错Error EINVAL: pool 'rbd-ssd' already contains some objects. Use an empty pool instead，解决办法：

断电后出现此问题。MDS进程报错： Error recovering journal 0x200: (5) Input/output error。诊断过程：

通常可以认为属于Ceph的Bug。这些Bug可能因为数据状态引发，有些时候将崩溃OSD的权重清零，可以恢复：

如果创建一个存储池后，其所有PG都卡在此状态，可能原因是CRUSH map不正常。你可以配置osd_crush_update_on_start为true让集群自动调整CRUSH map。

ceph -s显示如下状态，长期不恢复：

此案例中，使用此PG的Pod呈Known状态。

检查卡在inactive状态的PG：

输出其中一个PG的诊断信息，片断如下：

没有获得osd-12阻塞Peering的明确原因。 

查看日志，osd-12位于10.0.0.104，osd-3位于10.0.0.100，后者为Primary OSD。

osd-3日志，在18:26开始出现，和所有其它OSD之间心跳检测失败。此时10.0.0.100负载很高，卡死。

osd-12日志，在18:26左右大量出现：

直到18:44分仍然无法进行心跳检测，重启osd-12后一切恢复正常。 

检查无法完成的PG：

查询PG 17.30的诊断信息：

可以看到17.30期望到osd.11寻找权威数据，而osd.11已经永久丢失了。这种情况下，可以尝试强制标记PG为complete。

首先，停止PG的主OSD： service ceph-osd@16 stop  

然后，运行下面的工具：

最后，重启PG的主OSD： service ceph-osd@16 start  

不做副本的情况下，单个OSD宕机即导致数据不可用：

如果OSD的确出现硬件故障，则数据丢失。此外，你也无法对这种PG进行查询操作。

定位出问题PG的主OSD，停止它，刷出日志，然后修复PG：

持有对象权威副本的OSD宕机或被剔除，会导致该问题出现。例如两个配对的OSD（共同处理某个PG）：

1. osd.1宕机
2. osd.2独自处理了一些写操作
3. osd1开机
4. osd.1+osd2配对，由于osd.2独自的写操作，缺失的对象排队等候在osd.1上恢复
5. 恢复完成之前，osd.2宕机，或者被移除

在上面这个事件序列中，osd.1知道权威副本存在，但是却找不到，这种情况下针对目标对象的请求会被阻塞，直到权威副本的持有者osd上线。

执行下面的命令，定位存在问题的PG：

进一步，定位存在问题的对象：

如果丢失的对象太多，more会显示为true。

执行下面的命令，可以查看PG的诊断信息：

上面输出中的osd.11，先前已经出现硬件故障，被移除了。这意味着unfound的对象已经不可恢复。你可以标记：

/usr/lib/python2.7/dist-packages/ceph_deploy/osd.py第376行，替换为：

应该安装ceph-deploy的1.5.39版本，2.0.0版本仅仅支持luminous：

在我的环境下，是因为MON节点识别的public addr为LVS的虚拟网卡的IP地址导致。修改配置，显式指定MON的IP地址即可：

在我的环境下部署，出现一系列和权限有关的问题，如果你遇到相同问题且不关心安全性，可以修改配置：

如果需要保证集群安全，请参考下面几个案例。

问题现象：

此Pod一直无法启动，查看容器日志，发现：

timeout 10 ceph --cluster ceph auth get-or-create mgr.xenial-100 mon 'allow profile mgr' osd 'allow *' mds 'allow *' -o /var/lib/ceph/mgr/ceph-xenial-100/keyring

0 librados: client.admin authentication error (1) Operation not permitted

问题分析：

连接到可以访问的ceph-mon，执行命令：

发现报同样的错误。这说明client.admin的Keyring有问题。登陆到ceph-mon，获取Keyring列表：

而当前使用的client.admin的Keyring内容为：

内容不一致。使用auth list获得的client.admin的Keyring，可以发现是有效的：

检查一下各Pod的/etc/ceph/ceph.client.admin.keyring，可以发现都是从Secret ceph-client-admin-keyring挂载的。那么这个Secret是如何生成的呢？执行命令：

可以发现Job ceph-storage-keys-generator负责生成该Secret。 查看其Pod日志可以生成Keyring、创建Secret的记录。进一步查看Pod的资源定义，可以看到负责创建的脚本/opt/ceph/ceph-storage-key.sh挂载自ConfigMap ceph-bin中的ceph-storage-key.sh。

解决此问题最简单的办法就是修改Secret，将其修改为集群中实际有效的Keyring：

此外Secret pvc-ceph-client-key中存放的也是admin用户的Key，其内容也需要替换到有效的：

原因和上一个问题类似，还是权限问题。

查看无法绑定的PVC日志：

rbd-provisioner需要读取StorageClass定义，获取需要的凭证信息：

可以看到牵涉到两个Secret：pvc-ceph-conf-combined-storageclass、pvc-ceph-client-key，你需要把正确的Keyring内容写入其中。

症状：PVC可以Provision，RBD可以通过Ceph命令挂载，但是Pod无法启动，Describe之显示：

auth: unable to find a keyring on /etc/ceph/keyring: (2) No such file or directory
monclient(hunting): authenticate NOTE: no keyring found; disabled cephx authentication
librados: client.admin authentication error (95) Operation not supported

解决办法：把ceph.client.admin.keyring拷贝一份为 /etc/ceph/keyring即可。

原因和上一个问题一样。查看无法启动的容器日志：

进一步查看，可以发现/var/lib/ceph/bootstrap-osd/ceph.keyring挂载自ceph-bootstrap-osd-keyring下的ceph.keyring：

获得实际有效的Keyring：

修改Secret： kubectl -n ceph edit secret ceph-bootstrap-osd-keyring 替换为上述Keyring。

报错信息：

对应的配置文件内容： 

可以看到，fsid不一致。修改一下ConfigMap中的fsid即可解决此问题。  

报错信息：

describe pod报错：timeout expired waiting for volumes to attach/mount for pod
kubelet报错：executable file not found in $PATH, rbd output

原因分析：动态提供的持久卷，包含两个阶段：

1. 卷提供，原本由控制平面负责，controller-manager中需要包含rbd命令，才能在Ceph集群中创建供K8S使用的镜像。目前这个职责由external_storage项目的rbd-provisioner完成
2. 卷依附/分离，由使用卷的Pod所在的Node的kubelet负责完成。这些Node需要安装rbd命令，并提供有效的配置文件

解决方案：

应用上述方案后，如果继续报错：rbd: map failed exit status 110, rbd output: rbd: sysfs write failed In some cases useful info is found in syslog。则查看一下系统日志：

对照本文前面的特性表，可以发现内核版本必须4.5+才可以（CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING）。 

最简单的办法就是升级一下内核：

或者，将tunables profile调整到hammer版本的Ceph：

报错信息：ERROR: osd init failed: (36) File name too long

报错原因：使用的文件系统为EXT4，存储的xattrs大小有限制，有条件的话最好使用XFS

解决办法：修改配置文件，如下：

报错信息：Fail to open '/proc/0/cmdline' error No such file or directory

报错原因：在CentOS 7上，将ceph-mon和ceph-osd（基于目录）部署在同一节点（基于Helm）报此错误，分离后问题消失。此外部署mon的那些节点还设置了虚IP，其子网和Ceph的Cluster/Public网络相同，这导致了某些OSD监听的地址不正确。

再次遇到此问题，原因是一个虚拟网卡lo:ngress使用和eth0相同的网段，导致OSD使用了错误的网络。

解决办法是写死OSD监听地址：

报错信息：Input/output error，结合dmesg | tail可以看到更细节的报错

报错原因，可能情况：

1. CentOS7下报错，提示客户端不满足特性CEPH_FEATURE_CRUSH_V4（1000000000000）。解决办法，将Bucket算法改为straw。注意，之后加入的OSD仍然默认使用straw2，使用的镜像的标签为tag-build-master-luminous-ubuntu-16.04。

external storage中的CephFS可以正常Provisioning，但是尝试读写数据时报此错误。原因是文件路径过长，和底层文件系统有关，为了兼容部分Ext文件系统的机器，我们限制了osd_max_object_name_len。

解决办法，不使用UUID，而使用namespace + pvcname来命名目录。修改cephfs-provisioner.go，118行：

重新编译即可。 

describe pod发现：

说明有其它客户端正在占用此镜像。如果尝试删除镜像，你会发现无法成功：

要知道watcher是谁，可以执行：

可以发现10.5.39.12正在占用镜像。

另一种获取watcher的方法是，使用rbd的header对象。执行下面的命令获取rbd的诊断信息：

字段block_name_prefix的值rbd_data.134474b0dc51，将data换为header即为header对象。然后使用命令：

既然知道10.5.39.12占用镜像，断开连接即可。 在此机器上执行下面的命令，显示当前映射的rbd镜像列表：

此机器上的rbd0虽然映射，但是没有挂载。解除映射：

再次检查rbd镜像状态，发现没有watcher了：

kubectl describe报错Unable to mount volumes for pod... timeout expired waiting for volumes to attach or mount for pod...

检查发现目标rbd没有Watcher，Pod所在机器的Kubectl报错rbd: map failed signal: aborted (core dumped)。此前曾经在该机器上执行过rbd unmap操作。

手工 rbd map后问题消失。

报错信息：journal do_read_entry(156389376): bad header magic......FAILED assert(interval.last > last)

这是12.2版本已知的BUG，断电后可能出现OSD无法启动，可能导致数据丢失。

RGW实例无法启动，通过journalctl看到上述信息。

要查看更多信息，需要查看RGW日志：

可以发现是和身份验证有关的问题。

通过 systemctl status ceph-radosgw@rgw.$RGW_HOST得到命令行，手工运行：

发现报错和上面一样。尝试增加--keyring参数，问题解决：

看来是Systemd服务没有找到keyring导致。 

报错信息：Unhandled exception from module 'prometheus' while running on mgr.master01-10-5-38-24: error('No socket could
be created',)  

解决办法： ceph config-key set mgr/prometheus/server_addr 0.0.0.0

原因是时钟不同步警告阈值太低，在global段增加配置并重启MON：

或者执行下面的命令即时生效：

或者检查ntp相关配置，保证时钟同步精度。

深度清理很消耗IO，如果长时间无法完成，可以禁用：

问题解决后，可以再启用： 

使用CFQ作为IO调度器时，可以调整OSD IO线程的优先级：

如果上述措施没有问题时，可以考虑配置以下参数：

如果Watcher被黑名单，则尝试Unmap镜像时会报错：rbd: sysfs write failed rbd: unmap failed: (16) Device or resource busy

可以使用下面的命令强制unmap： rbd unmap -o force ... 

部分PG状态卡死，可能原因是OSD允许的PG数量受限，修改全局配置项mon_max_pg_per_osd并重启MON即可。

此外注意：调整PG数量后，一定要进入A+C状态后，再进行下一次调整。

下面第二个镜像对应的K8S PV已经删除：

但是对应的RBD没有删除，手工删除：

报错：

2018-04-23 13:37:25.559444 7f919affd700 -1 librbd::image::RemoveRequest: 0x5598e77831d0 check_image_watchers: image has watchers - not removing
Removing image: 0% complete...failed.
rbd: error: image still has watchers
This means the image is still open or the client using it crashed. Try again after closing/unmapping it or waiting 30s for the crashed client to timeout.

查看RBD状态：

到10.0.0.101这台机器上查看：

重启Kubelet后可以删除RBD。

可能是由于PG总数太大导致，降低PG数量后很快Active+Clean 

报错信息：Orphaned pod "a9621c0e-41ee-11e8-9407-deadbeef00a0" found, but volume paths are still present on disk : There were a total of 1 errors similar to this. Turn up verbosity to see them

临时解决办法：

rm -rf /var/lib/kubelet/pods/a9621c0e-41ee-11e8-9407-deadbeef00a0/volumes/rook.io~rook/

可能原因是OSD使用的keyring和MON不一致。对于ID为14的OSD，将宿主机/var/lib/ceph/osd/ceph-14/keyring的内容替换为 ceph auth get osd.14的输出前两行即可。

在没有停止OSD的情况下执行ceph-objectstore-tool命令，会出现此错误。

通过ceph-deploy添加MON节点时出现此错误，将public_network配置添加到配置文件的global段即可。

可能原因：

1. 对应的PVC没有删除，还在引用此PV。先删除PV即可

OSD无法启动，报上面的错误，可以配置：