ceph 笔记整理

ceph 查看、修改 crushmap

直接通过 ceph 命令

1、创建对应的root
ceph osd crush add-bucket ssd root
ceph osd crush add-bucket sas root
2、创建对应的host
ceph osd crush add-bucket node-4-sata host
ceph osd crush add-bucket node-5-sata host
ceph osd crush add-bucket node-4-ssd host
ceph osd crush add-bucket node-5-ssd host
3、移动host到对应的root下
ceph osd crush move node-4-sas root=sas
ceph osd crush move node-5-sas root=sas
ceph osd crush move node-4-ssd root=ssd
ceph osd crush move node-5-ssd root=ssd
4、将osd移到host下
ceph osd crush move osd.3 0.88 host=node-4-sas
ceph osd crush move osd.4 0.88 host=node-4-sas
ceph osd crush move osd.6 0.88 host=node-5-sas
ceph osd crush move osd.7 0.88 host=node-5-sas
ceph osd crush move osd.1 0.97 host=node-4-ssd
ceph osd crush move osd.2 0.88 host=node-4-ssd
ceph osd crush move osd.0 0.97 host=node-5-ssd
ceph osd crush move osd.5 0.88 host=node-5-ssd

查看 ceph osd 节点结构。层级结构：root bucket > host bucket > osd bucket

ceph osd tree

导出 crush

ceph osd getcrushmap -o crushmap.txt

反编译

crushtool -d crushmap.txt -o crushmap-decompile

修改 rule （修改 ruleset 和 step take）

rule ssd {
ruleset 1
type replicated
min_size 1
max_size 10
step take ssd
step chooseleaf firstn 0 type host
step emit
}
rule sas {
ruleset 0
type replicated
min_size 1
max_size 10
step take ssd
step chooseleaf firstn 0 type host
step emit
}

重新编译

crushtool -c crushmap-decompile -o crushmap-compiled

应用到集群

ceph osd setcrushmap -i crushmap-compiled

创建一个新的 pool

ceph osd pool create ssd 1024

设置 ssd pool 使用 rules 1 （ceph 新版本集群没有 crush_ruleset，只有 crush_rule）

#ceph osd pool set ssd crush_ruleset 1
ceph osd pool set ssd crush_rule ssd

检查 、查看 cursh_rule

ceph osd pool get ssd crush_rule

测试在 ssd 中写入数据是否都散落到 osd.0、osd.5、osd.1、osd.2

在 ssd pool 中创建 testing 快

rbd create ssd/testing -s 1024

查看 pg 的散落情况

ceph osd map ssd testing

ps: 忘了 copy 哪篇博客，看到了希望能提醒一下

ceph map

Monitor Map： 包含集群的 fsid、位置、名字、地址和端口、创建时间，最近修改时间

[root@ansible002 ceph-te]# ceph mon dump

OSD Map： 包含集群 fsid、创建时间、最近修改时间、存储池列表、副本数量、pg_num、osd 列表及其状态

ceph osd dump

PG Map：包含 pg(placement group) 版本、其时间戳、最新的 osd 运行图版本、占满率、pg 详情（id、up set、acting set、pg 状态和各存储池的数据使用状况）

ceph pg dump
ceph pg dump_json

CRUSH Map： 包含存储设备列表、故障域树状结构和存储数据规则

ceph osd getcrushmap -o crushmap.txt
crushtool -d crushmap.txt -o crushmap-decompile
cat crushmap-decompile

MDS Map： 包含当前 MDS 图的版本、创建时间、最近修改时间，还包含了存储元数据的存储池、元数据服务器列表及状态

ceph mds dump

理解Cluster Map

cluster map由monitor维护，用于跟踪ceph集群状态

当client启动时，会连接monitor 获取cluster map副本，发现所有其他组件的位置，然后直接与所需的进程通信，以存储和检索数据

monitor跟踪这些集群组件的状态，也负责管理守护进程和客户端之间的身份验证

cluster map实际是多种map的集群，包含：monitor map、osd map、pg map、mds map、mgr map

monitor map：包含集群ID、monitor节点名称、IP以及端口号以及monitor map的版本号

ceph mon dump

ceph mgr dump
ceph service dump

OSD map：包含集群ID、自身的版本号以及存储池相关的信息，包括存储池名称、ID、类型、副本级别和PG。还包括OSD的信息，比如数量、状态、权限以及OSD节点信息

ceph osd dump
ceph osd  crush dump

PG map：包含PG的版本、时间戳、OSD map的最新版本号、容量相关的百分比。还记录了每个PG的ID、对象数量、状态、状态时间戳等

ceph pg dump|more

MDS map：包含MDS的地址、状态、数据池和元数据池的ID

ceph fs dump

CRUSH Map: 包含存储设备，故障域层次结构（例如，设备，主机，机架，行，房间等）的列表，以及在存储数据时遍历层次结构的规则

ceph osd getcrushmap -o {filename}
crushtool -d {comp-crushmap-filename} -o {decomp-crushmap-filename}

copy 自 015 Ceph的集群管理_1

PG的状态

​ Creating：PG正在被创建。通常当存储池被创建或者PG的数目被修改时，会出现这种状态

​ Active：PG处于活跃状态。可被正常读写

​ Clean：PG中的所有对象都被复制了规定的副本数

​ Down：PG离线

​ Replay：当某个OSD异常后，PG正在等待客户端重新发起操作

​ Splitting：PG正在初分割，通常在一个存储池的PG数增加后出现，现有的PG会被分割，部分对象被移动到新的PG

​ Scrubbing：PG正在做不一致校验

​ Degraded：PG中部分对象的副本数未达到规定数目

​ Inconsistent：PG的副本出现了不一致。如果出现副本不一致，可使用ceph pg repair来修复不一致情况

​ Peering：Perring是由主OSD发起的使用存放PG副本的所有OSD就PG的所有对象和元数据的状态达成一致的过程。Peering完成后，主OSD才会接受客户端写请求

​ Repair：PG正在被检查，并尝试修改被发现的不一致情况

​ Recovering：PG正在迁移或同步对象及副本。通常是一个OSD down掉之后的重平衡过程

​ Backfill：一个新OSD加入集群后，CRUSH会把集群现有的一部分PG分配给它，被称之为数据回填

​ Backfill-wait：PG正在等待开始数据回填操作

​ Incomplete：PG日志中缺失了一关键时间段的数据。当包含PG所需信息的某OSD不可用时，会出现这种情况

​ Stale：PG处理未知状态。monitors在PG map改变后还没收到过PG的更新。集群刚启动时，在Peering结束前会出现该状态

​ Remapped：当PG的acting set变化后，数据将会从旧acting set迁移到新acting set。新主OSD需要一段时间后才能提供服务。因此这会让老的OSD继续提供服务，直到PG迁移完成。在这段时间，PG状态就会出现Remapped

管理stuck的状态PG

​如果PG长时间（mon_pg_stuck_threshold，默认为300s）出现如下状态时，MON会将该PG标记为stuck：

​inactive：pg有peering问题

unclean：pg在故障恢复时遇到问题

​stale：pg没有任何OSD报告，可能其所有的OSD都是down和out

​undersized：pg没有充足的osd来存储它应具有的副本数

​默认情况下，Ceph会自动执行恢复，但如果未成自动恢复，则集群状态会一直处于HEALTH_WARN或者HEALTH_ERR

​如果特定PG的所有osd都是down和out状态，则PG会被标记为stale。要解决这一情况，其中一个OSD必须要重生，且具有可用的PG副本，否则PG不可用

​Ceph可以声明osd或PG已丢失，这也就意味着数据丢失。

​需要说明的是，osd的运行离不开journal，如果journal丢失，则osd停止

copy 自 016 Ceph的集群管理_2

ceph 集群标准

​noup：OSD启动时，会将自己在MON上标识为UP状态，设置该标志位，则OSD不会被自动标识为up状态

​nodown：OSD停止时，MON会将OSD标识为down状态，设置该标志位，则MON不会将停止的OSD标识为down状态，设置noup和nodown可以防止网络抖动

​noout：设置该标志位，则mon不会从crush映射中删除任何OSD。对OSD作维护时，可设置该标志位，以防止CRUSH在OSD停止时自动重平衡数据。OSD重新启动时，需要清除该flag

​noin：设置该标志位，可以防止数据被自动分配到OSD上

​norecover：设置该flag，禁止任何集群恢复操作。在执行维护和停机时，可设置该flag

​nobackfill：禁止数据回填

​noscrub：禁止清理操作。清理PG会在短期内影响OSD的操作。在低带宽集群中，清理期间如果OSD的速度过慢，则会被标记为down。可以该标记来防止这种情况发生

​nodeep-scrub：禁止深度清理

​norebalance：禁止重平衡数据。在执行集群维护或者停机时，可以使用该flag

​pause：设置该标志位，则集群停止读写，但不影响osd自检

​full：标记集群已满，将拒绝任何数据写入，但可读

集群flag操作

只能对整个集群操作，不能针对单个osd

设置为noout状态

 ceph osd set noout

 ceph osd unset noout

ceph osd set full
rados -p ssdpool put testfull /etc/ceph/ceph.conf

ceph osd unset full
 rados -p ssdpool put testfull /etc/ceph/ceph.conf