对象存储：提供RESTful接口，也提供多种编程语言绑定。兼容S3、Swift

块存储：由RBD提供，可以直接作为磁盘挂载，内置了容灾机制

文件系统：提供POSIX兼容的网络文件系统CephFS，专注于高性能、大容量存储

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

Ceph OSDs：OSD即对象存储守护程序，但是它并非针对对象存储。OSD负责 存储数据、处理数据复制、恢复、回填（B ackfilling）、再平衡 。此外OSD还对其它OSD进行心跳检测，检测结果汇报给Monitor

Monitors：监视器，维护集群状态的多种映射 ，同时提供认证和日志记录服务

MDSs：元数据服务器，存储CephFS的元数据信息

Ceph将客户端的数据作为对象存储在它的存储池中，基于CRUSH算法，Ceph 计算出每个对象应该位于那个PG，计算哪个OSD负责存储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 ，每个d evice都有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

对象存储守护进程（Object Storage Daemon），负责响应客户端请求返回具体数据的进程。Ceph集群中有大量OSD

一个节点上通常只运行一个OSD守护进程，此守护进程在 一个存储驱动器上只运行一个 filestore

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分为三类角色：

Leader：具有最新版本状态映射的mon

Provider：同上，但是它的最新状态是从Leader同步获得

Requester：落后于Leader，必须获取最新集群状态映射才能重回quorum

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

守护进程忽略收到的消息（时间戳过时）

消息未及时收到时，超时触发得太快或太晚

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

速度： 日志使得 OSD 可以 快速地提交小块数据的写 入， Ceph 把小片、随机 IO 依次写入日志 ，这样，后端文件系统就有可能 归并写入动作 ，并最终提升并发承载力。因此，使用 OSD 日志能 展现出优秀的突发写性能 ，实际上数据还没有写入 OSD ，因为文件系统把它们捕捉到了日志

一致性：OSD需要一个能 保证原子化复合操作的文件系统接口 。 OSD 把一个 操作的描述写入日志，并把操作应用到文件系统 。这确保了对象（例如归置组元数据）的原子更新。每隔一段时间（由filestore max sync interval 和 filestore min sync interval控制 ）， OSD 会停止写入，把日志同步到文件系统，这样允许 OSD 修整日志里的操作并重用空间。若失败， OSD 从上个同步点开始重放日志。 日志的原子性表现在，它不使用操作系统的文件缓存（基于内存） ，避免断电丢数据的问题

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

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

避免针对单块磁盘的双重写入 —— 先写日志，再写filestore

SSD性能好，可以降低延迟提升IOPS

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

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

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

使用HDD作为数据盘

使用SSD作为RockDB元数据盘

使用NVRAM作为RockDB WAL

一些概念：

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。

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，需要进行回填，但是因存储空间不足而不能完成

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。

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

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存储集群的访问。此服务提供两套接口：

S3兼容接口：Amazon S3的子集

Swift兼容接口： OpenStack Swift的子集

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

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

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

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

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

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

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

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

创建MON和MGR守护进程到本机

为Ceph集群生成SSH密钥，并添加到roo用户的/root/.ssh/authorized_keys

生成最小化配置的 /etc/ceph/ceph.conf，用于和新集群通信

生成Ceph管理密钥 /etc/ceph/ceph.client.admin.keyring

复制公钥副本到/etc/ceph/ceph.pub

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

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

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

编译进二进制文件的默认值

ceph-mon的集群中心配置数据库

本机上的配置文件：

/etc/ceph/ceph.conf

~/.ceph/config

./ceph.conf

环境变量：$CEPH_CONF

命令行参数：-c path/path

管理员在运行时设置的选项

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

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

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

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

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，正确设置此参数可能让集群更快的可用

日志文件的尺寸（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 tcp nodelay 禁用 nagle 算法，默认true ms initial backoff 出错时重连的初始等待时间

ms max backoff

出错重连时等待的最大时间 ms nocrc 禁用网络消息的 crc 校验， CPU 不足时可提升性能 mds选项 mds cache memory limit MDS缓存最大使用多少内存

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

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

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

希望所有配置信息在本地文件中管理

ceph-mon目前宕机，但是需要进行一些维护工作

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

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

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

命令格式：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

创建 client.admin 密钥：

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

# 下面的输出时安装后最初的状态，没有任何OSD

{

# 设备列表，最初为空

"devices" : [ ] ,

# 桶类型定义列表

"types" : [

{

"type_id" : 0 ,

"name" : "osd"

} ,

{

"type_id" : 1 ,

"name" : "host"

} ,

{

"type_id" : 2 ,

"name" : "chassis"

} ,

{

"type_id" : 3 ,

"name" : "rack"

} ,

{

"type_id" : 4 ,

"name" : "row"

} ,

{

"type_id" : 5 ,

"name" : "pdu"

} ,

{

"type_id" : 6 ,

"name" : "pod"

} ,

{

"type_id" : 7 ,

"name" : "room"

} ,

{

"type_id" : 8 ,

"name" : "datacenter"

} ,

{

"type_id" : 9 ,

"name" : "region"

} ,

{

"type_id" : 10 ,

"name" : "root"

}

] ,

# 桶列表，可以形成树状结构

"buckets" : [

{

"id" : - 1 ,

"name" : "default" ,

"type_id" : 10 ,

"type_name" : "root" ,

"weight" : 0 ,

"alg" : "straw2" ,

"hash" : "rjenkins1" ,

"items" : [ ]

}

# 加入一个OSD节点（基于目录），自动生成如下两个Bucket：

{

"id" : - 2 ,

"name" : "k8s-10-5-38-25" ,

"type_id" : 1 ,

"type_name" : "host" ,

"weight" : 55050 ,

"alg" : "straw2" ,

"hash" : "rjenkins1" ,

"items" : [

{

"id" : 0 ,

"weight" : 55050 ,

"pos" : 0

}

]

} ,

{

"id" : - 3 ,

"name" : "k8s-10-5-38-25~hdd" ,

"type_id" : 1 ,

"type_name" : "host" ,

"weight" : 55050 ,

"alg" : "straw2" ,

"hash" : "rjenkins1" ,

"items" : [

{

"id" : 0 ,

"weight" : 55050 ,

"pos" : 0

}

]

} ,

] ,

# 规则列表

"rules" : [

{

"rule_id" : 0 ,

"rule_name" : "replicated_rule" ,

# 所属规则集

"ruleset" : 0 ,

# 此规则是否用于RAID，取值replicated 或 raid4

"type" : 1 ,

# 如果Pool的副本份数不在此范围内，则CRUSH不会使用当前规则

"min_size" : 1 ,

"max_size" : 10 ,

"steps" : [

{

# 选择一个桶，并迭代其子树

"op" : "take" ,

"item" : - 1 ,

"item_name" : "default"

} ,

{

# 在上一步的基础上，确定每个副本如何放置

"op" : "chooseleaf_firstn" ,

# 取值0，此Step适用pool-num-replicas个副本（所有）

# 取值>0 & < pool-num-replicas，适用num个副本

# 取值<0，适用pool-num-replicas -num个副本

"num" : 0 ,

"type" : "host"

} ,

{

"op" : "emit"

}

]

}

] ,

# 可微调参数，以及一些状态信息

"tunables" : {

"choose_local_tries" : 0 ,

"choose_local_fallback_tries" : 0 ,

"choose_total_tries" : 50 ,

"chooseleaf_descend_once" : 1 ,

"chooseleaf_vary_r" : 1 ,

"chooseleaf_stable" : 1 ,

"straw_calc_version" : 1 ,

"allowed_bucket_algs" : 54 ,

# 使用的Profile，执行ceph osd crush tunables hammer后此字段改变，连带其它tunables字段自动改变

"profile" : "jewel" ,

"optimal_tunables" : 1 ,

"legacy_tunables" : 0 ,

"minimum_required_version" : "jewel" ,

"require_feature_tunables" : 1 ,

"require_feature_tunables2" : 1 ,

"has_v2_rules" : 0 ,

"require_feature_tunables3" : 1 ,

"has_v3_rules" : 0 ,

"has_v4_buckets" : 1 ,

"require_feature_tunables5" : 1 ,

"has_v5_rules" : 0

} ,

"choose_args" : { }

}

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

# begin crush map

tunable choose_local _ tries 0

tunable choose_local_fallback _ tries 0

tunable choose_total _ tries 50

tunable chooseleaf_descend _ once 1

tunable chooseleaf_vary _ r 1

tunable straw_calc _ version 1

tunable allowed_bucket _ algs 54

# devices

# types

type 0 osd

type 1 host

type 2 chassis

type 3 rack

type 4 row

type 5 pdu

type 6 pod

type 7 room

type 8 datacenter

type 9 region .Values .storageclass .fsType

type 10 root

# buckets

root default {

id - 1 # do not change unnecessarily

# weight 0.000

alg straw2

hash 0 # rjenkins1

}

# rules

rule replicated_rule {

id 0

type replicated

min _ size 1

max _ size 10

step take default

step chooseleaf firstn 0 type host

step emit

}

# end crush map

1

2

3

4

5

6

7

8

9

# 你需要移除当前设置的设备类型，才能重新设置

ceph osd crush rm - device - class < osd - name > [ . . . ]

# 示例

ceph osd crush rm - device - class osd . 3 osd . 4 osd . 5 osd . 6 osd . 7 osd . 8 osd . 0 osd . 10 osd . 1 osd . 12 osd . 2 osd . 13

ceph osd crush set - device - class < class > < osd - name > [ . . . ]

# 示例

ceph osd crush set - device - class ssd osd . 3 osd . 4 osd . 5 osd . 6 osd . 7 osd . 8 osd . 0 osd . 10 osd . 1 osd . 12 osd . 2 osd . 13

1

2

3

4

5

6

7

8

9

10

11

12

rule < rulename > {

ruleset < ruleset >

type [ replicated | erasure ]

min_size < min - size >

max_size < max - size >

# 根据桶名称来选取CRUSH子树，并迭代，可限定设备类型

step take < bucket - name > [ class < device - class > ]

# choose：选择指定数量、类型的桶

# chooseleaf：选择指定数量、类型的桶，并选择每个这些桶的一个叶子节点

step [ choose | chooseleaf ] [ firstn | indep ] < N > < bucket - type >

step emit

}

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

rule ssd - primary - affinity {

ruleset 0

type replicated

min _ size 2

max _ size 3

# 选择名为SSD的桶

step take ssd

# 在上述桶中的host类型的子树中选择叶子节点，存储1个副本（第一个）

step chooseleaf firstn 1 type host

# 执行

step emit

# 选择名为HDD的桶

step take hdd

# 在上述桶中的host类型的子树中选择叶子节点，存储N-1个副本（所有其它副本）

step chooseleaf firstn - 1 type host

step emit

}

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

# SSD主机

host ceph - osd - ssd - server - 1 {

id - 1

alg straw

hash 0

item osd . 0 weight 1.00

item osd . 1 weight 1.00

}

# HDD主机

host ceph - osd - hdd - server - 1 {

id - 3

alg straw

hash 0

item osd . 4 weight 1.00

item osd . 5 weight 1.00

}

# HDD的根桶

root hdd {

id - 5

alg straw

hash 0

item ceph - osd - hdd - server - 1 weight 2.00

}

# SSD的根桶

root ssd {

id - 6

alg straw

hash 0

item ceph - osd - ssd - server - 1 weight 2.00

}

# 仅仅使用HDD的规则

rule hdd {

ruleset 3

type replicated

min _ size 0

max _ size 10

step take hdd

# 选择

step chooseleaf firstn 0 type host

step emit

}

# 仅仅使用SSD的规则

rule ssd {

ruleset 4

type replicated

min _ size 0

max _ size 4

step take ssd

step chooseleaf firstn 0 type host

step emit

}

# 在SSD上存储主副本，其它副本存放在HDD

rule ssd - primary {

ruleset 5

type replicated

min _ size 5

max _ size 10

step take ssd

step chooseleaf firstn 1 type host

step emit

step take hdd

step chooseleaf firstn - 1 type host

step emit

}

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

# 默认4K，可以--io-size定制

# 默认16线程，可以--io-threads定制

# 随机读

rbd bench - p rbd - hdd -- image benchmark -- io - total 128M -- io - type read -- io - pattern rand

# elapsed: 25 ops:  32768 ops/sec:  1284.01  bytes/sec: 5259316.53

# elapsed: 15 ops: 327680 ops/sec: 20891.46  bytes/sec: 85571410.91

# HDD差20倍

# 顺序读

rbd bench - p rbd - hdd -- image benchmark -- io - total 64M -- io - type read -- io - pattern seq

# elapsed: 46 ops:  163840 ops/sec:   3528.06  bytes/sec: 14450938.87

# elapsed: 45 ops: 1638400 ops/sec:   35672.87 bytes/sec: 146116057.32

# HDD差10倍

# 随机写

rbd bench - p rbd - hdd -- image benchmark -- io - total 128M -- io - type write -- io - pattern rand

# elapsed: 85  ops:  32768 ops/sec: 383.24  bytes/sec: 1569743.22

# elapsed: 111 ops: 327680 ops/sec: 2936.78 bytes/sec: 12029055.24

# HDD差7倍

# 顺序写

rbd bench - p rbd - hdd -- image benchmark -- io - total 128M -- io - type write -- io - pattern seq

# elapsed: 3  ops: 32768  ops/sec:  9382.16 bytes/sec: 38429334.91

# elapsed: 17 ops: 327680 ops/sec: 18374.69 bytes/sec: 75262749.05

# HDD差1倍

1

2

3

4

5

6

# 临时修改所有OSD和恢复相关的选项

ceph tell osd . * injectargs '--osd-max-backfills 1' # 并发回填操作数

ceph tell osd . * injectargs '--osd-recovery-threads 1' # 恢复线程数量

ceph tell osd . * injectargs '--osd-recovery-op-priority 1' # 恢复线程优先级

ceph tell osd . * injectargs '--osd-client-op-priority 63' # 客户端线程优先级

ceph tell osd . * injectargs '--osd-recovery-max-active 1' # 最大活跃的恢复请求数

1

2

3

4

5

6

7

8

9

10

rbd status kubernetes - dynamic - pvc - 22d9e659 - 6e31 - 11e8 - 92e5 - c6b9f35768f0

# Watchers:

#         watcher=10.0.3.1:0/158685765 client.3524447 cookie=18446462598732840965

# 添加到黑名单

ceph osd blacklist add 10.0.3.1 : 0 / 158685765

# blacklisting 10.0.3.1:0/158685765 until 2018-08-21 18:04:31.855791 (3600 sec)

rbd status kubernetes - dynamic - pvc - 22d9e659 - 6e31 - 11e8 - 92e5 - c6b9f35768f0

# Watchers: none

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

# 列出池

rados lspools

.rgw .root

default .rgw .control

default .rgw .meta

default .rgw .log

rbd

rbd - ssd

rbd - hdd

# 创建池pool-name，使用auid 123，使用crush规则4

mkpool pool - name [ 123 [ 4 ] ]

# 复制池的内容

cppool pool - name dest - pool

# 移除池

rmpool pool - name pool - name -- yes - i - really - really - mean - it

# 清空池中对象

purge pool - name -- yes - i - really - really - mean - it

# 显示每个池的对象数量、空间占用情况

rados df

# 列出池中对象

rados ls - p rbd

# 将池的所有者设置为auid 123

rados chown 123 - p rbd

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

# 读对象

rados get object - name / tmp / obj - p rbd

# 使用指定的偏移量写对象

rados put object - name / tmp / obj -- offset offset

# 附加内容到对象

rados append < obj - name > [ infile

# 截断对象为指定的长度

rados truncate < obj - name > length

# 创建对象

rados create < obj - name >

# 移除对象

rados rm < obj - name > . . . [ -- force - full ]

# 复制对象

rados cp < obj - name > [ target - obj ]

1

2

3

4

5

6

7

8

9

# 创建用户

radosgw - admin user create -- uid = rgw -- display - name = rgw -- system

# 设置access_key和secret_key

ceph dashboard set - rgw - api - access - key - i - <<< "$(radosgw-admin user info --uid=rgw | jq -r .keys[0].access_key)"

ceph dashboard set - rgw - api - secret - key - i - <<< "$(radosgw-admin user info --uid=rgw | jq -r .keys[0].secret_key)"

# 禁用SSL校验

ceph dashboard set - rgw - api - ssl - verify False

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

# debug {subsystem} = {log-level}/{memory-level}

[ global ]

debug ms = 1 / 5

[ mon ]

debug mon = 20

debug paxos = 1 / 5

debug auth = 2

[ osd ]

debug osd = 1 / 5

debug filestore = 1 / 5

debug journal = 1

debug monc = 5 / 20

[ mds ]

debug mds = 1

debug mds balancer = 1

debug mds log = 1

debug mds migrator = 1

public和cluster网络必须一样

如果Storage的用户不是admin，你需要在Ceph集群中手工创建用户，并在K8S中创建对应的Secrets

ceph-mgr只能运行单副本

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

ceph-mon=enabled，部署mon的节点上添加

ceph-mgr=enabled，部署mgr的节点上添加

ceph-osd=enabled，部署基于设备、基于目录的OSD的节点上添加

ceph-osd-device-NAME=enabled。部署基于设备的OSD的节点上添加，其中NAME需要替换为上面 ceph-overrides.yaml中的OSD设备名，即：

ceph-osd-device-dev-vdb=enabled

ceph-osd-device-dev-vdc=enabled

对应的K8S命令：

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

Provisioner： https://git.gmem.cc/alex/helm-charts/src/branch/master/ceph-provisioners

安装脚本： 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对应了它的一个子目录。

监控节点对于集群的正确运行非常重要，应当为其分配独立的硬件资源。如果跨数据中心部署，监控节点应该分散在不同数据中心或者可用性区域

日志可能会让集群的吞吐量减半 。理想情况下，应该 在不同磁盘上运行操作系统、OSD数据、OSD日志 。对于高吞吐量工作负载， 考虑使用SSD进行日志存储

纠删编码（Erasure coding）可以用于存储大容量的 一次性写、非频繁读、性能要求不高 的数据。纠删编码存储消耗小，但是IOPS也降低

目录项（Dentry）和inode缓存可以提升性能，特别是存在很多小对象的情况下

使用 缓存分层（Cache Tiering）可以大大提升集群性能 。此技术可以在热、冷Tier之间自动的进行数据迁移。为了最大化性能，请 使用SSD作为缓存池、并且在低延迟节点上部署缓存池

部署奇数个数的监控节点，以便仲裁投票（Quorum Voting），建议使用3-5个节点。更多的节点可以增强集群的健壮性，但是mon之间需要保持数据同步，这会影响性能

诊断性能问题的时候，总是从最底层（磁盘、网络）开始，然后再检查块设备、对象网关等高层接口

在大型集群里用 单独的集群网络（Cluster Newwork）可显著地提升性能和安全性

限制最大文件大小，创建极大的文件会导致删除过程很缓慢

避免在生产环境下使用试验特性。你应该使用 单个活动MDS、不使用快照（默认如此）

避免增大max_mds，可能导致大于1个的MDS处于Active

客户端选择：

FUSE，容易使用、容易升级和服务器集群保持一致

内核，性能好

不同客户端的功能并不完全一致，例如FUSE支持客户端配额，内核不支持

对于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：

最好不要使用RAID

如果有RAID卡，并且磁盘数量太多，而对应的内存数量不足（每个OSD大概需要2G内存），可以RAID0

不要使用RAID5，因为随机IO的性能降低

关于filestore：

建议使用SSD存储日志，以减少访问时间、读取延迟，实现吞吐量的显著提升

可以为创建SSD分区，每个分区作为一个OSD的日志存储，但是最好不要超过4个

启用超线程Hyper-Threading技术

关闭NUMA

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

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

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

XFS 、 btrfs 和 ext4 都是日志文件系统

XFS很成熟

btrfs相对年轻，他是一个写时复制（COW）文件系统，因而支持可写文件系统快照。此外它还支持透明压缩、完整性校验

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

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

对于小于5个OSD的集群：设置为128

5-10个OSD的集群：设置为512

10-50个OSD的集群：设置为1024

超过50个OSD的集群，需要自己权衡，利用pgcalc来计算适合的PG数量

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

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

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

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

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

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

直接管理裸设备的 BlueStore到达稳定并且作为默认选项

纠删码池完全支持overwirte，可以和CephFS/RDB一起使用

引入 组件ceph-mgr ，如果该组件停止，则指标不会更新，某些依赖于指标的请求，例如ceph df，无法工作

可扩容能力提升，可部署10000OSD的集群

每个 OSD支持关联一个设备类 （例如hdd/ssd），允许CRUSH规则将数据简单地映射到系统中的设备的子集。通常不需要手动编写CRUSH规则或手动编辑CRUSH

支持优化CRUSH权重，以保持OSD之间数据的近乎完美的分布

OSD可以根据后端设备是HDD还是SSD来调整其默认配置

RGW引入了上传对象的服务器端加密 ，用于管理加密密钥的三个选项有：自动加密（仅推荐用于测试设置），客户提供的类似于Amazon SSE-C规范的密钥，以及通过使用外部密钥管理服务

RGW具有初步的类似AWS的存储桶策略API支持。现在，策略是一种表达一系列新授权概念的方式。未来，这将成为附加身份验证功能的基础，例如STS和组策略等

RGW通过使用rados命名空间合并了几个元数据索引池

引入组件 rbd-mirror，负责RBD卷的镜像复制

rbd trash命令支持延迟的镜像删除

镜像可以通过rbd mirroringreplay delay配置选项支持可配置的复制延迟

多Active MDS到达稳定状态

引入一个新的、全功能和美观的 仪表盘 Dashboard V2

RADOS：配置选项可被mon中心化存储和管理

RADOS：在恢复和再平衡时，mon使用的磁盘大大减小

RADOS：引入一个异步恢复特性，减少在OSD从错误恢复期间，请求的tail latency

RGW：支持将一个Zone（或者Buckets的子集）复制到外部云服务，例如S3

RGW：支持S3多因子身份验证

RGW：前端Beast到达stable

CephFS：使用多MDS时快照功能到达stable

RBD：镜像克隆不需要显式的protect/unprotect步骤

RBD： 镜像支持深克隆 （包含parent镜像、关联快照的数据的克隆）到新池，支持修改数据布局

仪表盘：增加很多新功能 ，全方位的查看各种指标，对Ceph进行管理

RADOS：每个 池的PG数量 ，现在可以随时减小 了。集群可以根据用量和管理员的提示，自动优化PG数量

RADOS：v2 wire protocol支持传输加密

RADOS：mon/osd使用的物理设备的健康指标（例如SMART）可以得到跟踪，并且在预期出现磁盘失败前进行警告

RADOS：在recovery/backfill时，OSD更有效的优先恢复重要的PG、对象

RADOS：例如磁盘失败后的恢复，这样长期运行的后台操作的进度，在ceph status中报告

RGW： Beast替换civetweb作为默认Web前端

CephFS：MDS稳定性得到很大优化，特别是针对大缓存、长时间运行的具有大内存的客户端

CephFS：在Rook管理的环境下， CephFS可以通过NFS-Ganesha集群暴露出去

CephFS：支持查询进行中的 针对MDS的scrub的进度

RBD：镜像可以在最小宕机时间内进行迁移，这可以支持在池之间迁移镜像、修改镜像布局

RBD：rbd perf image iotop 以及 rbd perf image iostat命令可以 提供iostat风格的、针对所有RBD镜像的监控

RBD：ceph-mgr的Prometheus Exporter支持暴露所有RBD镜像的IO监控指标

RBD：在一个池中，可以 使用命名空间来隔离RBD ，实现多租户

新的工具cephadm，用于支持容器化部署

Health警告可以被临时/永久的静默

Dashboard：UI增强、安全性增强

管理功能的增强

RADOS：从N版引入的PG括缩，默认启用

RADOS：Bluestore包含了多项改进和性能增强

RBD：镜像支持一种新的，基于快照的模式，不再依赖于journaling特性

RBD：克隆操作保持源镜像的稀疏性（sparseness）

RBD：改进了rbd-nbd 工具，可以使用新的内核特性

RBD：缓存性能增强

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

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

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

没有获得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左右大量出现：

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

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

然后，运行下面的工具：

恢复完成之前，osd.2宕机，或者被移除

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

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

问题现象：

此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，执行命令：

可以发现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-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即可。

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

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

报错信息：

报错信息：

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

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

卷提供，原本由控制平面负责，controller-manager中需要包含rbd命令，才能在Ceph集群中创建供K8S使用的镜像。目前这个职责由 external_storage 项目的rbd-provisioner完成

卷依附/分离，由使用卷的Pod所在的Node的kubelet负责完成。这些Node需要安装rbd命令，并提供有效的配置文件

解决方案：

报错信息：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监听地址：

报错原因，可能情况：

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行：

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日志：

报错信息：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：

如果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已经删除：

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状态：

可能是由于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段即可。

可能原因：

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

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

Leave a Reply Cancel reply