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