OSD的状态可能在ceph集群内（in）或集群外（out），也可能处于运行中（up）或者不运行中（down）。
OSD处于UP状态时，可能处于集群内（in）或集群外（out）。当他是UP状态且在集群中（in），则可以向这个OSD读写数据。如果处于UP状态的OSD最近out了（以前是in），ceph会把其上的PG迁移到其他处于UP&in状态的OSD上，CRUSH也就不再分配PG给他了。
如果一个OSD处于down状态，其也应处于集群外（out）。如果一个OSD 处于 out&in状态，则说明整个ceph集群处于非健康状态。
当ceph集群启动并运行时，所有的OSD应处于 up&in 状态。
如果ceph集群中处于UP状态的OSD数量小于处于in状态的OSD 数量，则需要查看是哪些ceph-osd守护进程没有运行。如果有OSD处于down状态，则应把他启动起来（systemctl start ceph-osd@OSD实例）。
CRUSH会根据ceph设定的存储持副本数将PG分配到不同的OSD上。
Acting set ：一组涉及到某个PG 的OSD。
Up set :实际处理读写请求的OSD集合。（CEPH依靠UP SET 处理客户端请求，大多数情况下 up set 和 acting set 是相同的。）如果up set 和 acting set 不相同，则说明某个OSD正在恢复或集群中的OSD数量发生了变化导致CEPH正在迁移数据或者集群中的OSD故障有其他OSD正在接管故障OSD的工作。
获取PG列表：ceph pg dump
查看指定PG的acting set 或up set涵盖的OSD：ceph pg map PG编号
查看PG的状态：ceph pg stat
查看pool或PG编号信息：ceph osd lspools，它会输出“pool-编号.pg-编号”
查询某个PG：ceph pg pool-编号.pg-编号 query
找出卡住的PG组：ceph pg dump_stuck 状态类型
向CEPH中写数据前必须取保PG处于active & clean 状态。
CEPH确认当前PG的状态：PG的主OSD与其从OSD建立连接并确认当前PG状态。
OSD会向CEPH-MON报告自己的状态。
CEPH集群健康检查结果为 HEALTH_WARN，原因有二：一是OSD未运行或运行异常；二是PG状态异常。导致PG状态异常的原因有：新建了pool，此时PG未协商一致；PG正在恢复；OSD发生了增减；PG的副本间的数据不一致；PG副本正在被洗刷；ceph中没有足够的容量进行回填操作；修改了crushmap导致PG正在迁移。
存储对象数据：rados put 对象名 数据文件路径 —pool=存储池
查看ceph对象存储中的文件：rados -p 存储池 ls
定位对象数据的位置：ceph osd map 存储池 对象名
删除对象存储数据：rados rm 对象名 —pool=存储池
列出ceph集群中的全部用户：ceph auth list
CEPH管理员创建或删除普通用户是会把keys发给客户端。
CEPH中使用“TYPE.ID”的个是表示用户，比如“client.admin”表示用户为client类型且其ID是admin。
获取某个用户的信息：ceph auth get 用户类型.用户ID
CEPH 新增用户：
ceph auth add
ceph auth get-or-create
ceph auth get-or-create-key
查看某个用户的当前授权信息：ceph auth get 用户类型.用户ID
变更某个用户的授权信息：ceph auth caps用户类型.用户ID
删除某个用户：ceph auth del 用户类型.用户ID
打印某个用户的授权密钥：ceph auth print-key 用户类型.用户ID
倒入用户及其密钥：ceph auth import -i 密钥文件路径
CEPH客户端本地保存的keyring文件路径：/etc/ceph/集群名.keyring或/etc/ceph/keyring。也可以在ceph.conf中指定keyring路径。
创建客户端的keyring使用 ceph-authtool —create-keyring 。当需要创建一个包含多个用户的keyring文件时，建议使用“集群名.keyring”作为文件名保存与目录“/etc/ceph/”下。创建仅包含一个用户的keyring文件时，建议使用“集群名.用户类型.用户名.keyring”作为文件名保存与目录“/etc/ceph/”下。
获取某个用户的keyring文件：ceph auth get 用户类型.用户名 -o 用户的keyring文件
向已存在的keyring文件中导入某个用户：ceph-authtool 目标keyring文件 —import-keyring 被导入的keyring文件
Ceph的Monitor建议部署成不少于3个的奇数个。后续如需增加，建议每次增加2个Monitor。
通过ceph-deploy工具增加Monitor节点：
1 登陆 ceph-deploy所在的admin节点，并进入ceph-deploy的工作目录；
2 执行 ceph-deploy mon create MONITOR主机
手工添加Monitor节点：
1 登录到待操作主机，新建MONITOR的工作目录 /var/lib/ceph/mon/ceph-节点主机名
2 新建一个临时目录用于存储该节点的keyring文件和集群的mon-map文件，假定这个临时目录为 /temp/
3 获取 mon.admin 的 keyring 文件：ceph auth get mon.admin -o /temp/集群名.mon.admin.keyring
4 获取ceph集群的mon-map文件：ceph mon getmap -o /temp/集群名.monap
5 格式化MONITOR的工作路径：ceph-mon -i MON-ID —mkfs —monmap /temp/集群名.monmap —keyring /temp/集群名.mon.admin.keyring
6 启动该节点上的Monitor进程（它会自动加入Ceph集群）：ceph-mon -i MON-ID —public-addr IP:PORT
通过ceph-deploy工具删除Monitor节点：
1 登陆 ceph-deploy所在的admin节点，并进入ceph-deploy的工作目录；
2 执行 ceph-deplou mon destroy MONITOR主机
手工删除Monitor节点：
1 登录到控制节点主机，停止全部的ceph-mon
2 确认还存活的Monitor并登陆到存活的Monitor节点
3 提取Ceph集群的mon-map：ceph-mon -I ‘MON-ID’—extract-monmap /temp/monmap
4 删除mon-map中有故障或处于非存活状态的Monitor：monmaptool /temp/monmap —rm 待删除的MONITOR
5 向存活的Monitor注入修改后的mon-map：ceph-mon -i 存活的MONITOR —inject-monmap /temp/monmap
6 启动存活的Monitor
7 确认当前集群中的Monitor达到了预定数量（ceph -s）
8 酌情备份或删除剔除掉的Monitor节点数据目录 /var/lib/ceph/mon
通过ceph-deploy工具添加OSD：
1 登陆 ceph-deploy所在的admin节点，并进入ceph-deploy的工作目录；
2 列举出目标节点上的磁盘；
3 格式化目标磁盘（也就是删除了目标磁盘上的分区表）
4 准备目标磁盘（实质是创建磁盘分区）
5 激活准备好的磁盘并把它启动为OSD
手工增加OSD：
1 创建OSD，并记录OSD编号
2 登录到新增主机创建数据目录
3 把用于做OSD的磁盘挂载到新建的数据目录
4 初始化OSD的数据目录
5 向Ceph集群添加OSD的keyring密钥
6 把新的OSD添加到 crushmap 中
7 启动新增的这个OSD
手工删除OSD：
1 停止待删除的OSD进程
2 将待删除的OSD标记为out状态，并等待ceph集群恢复到HEALTH_OK状态；
3 从crushmap中删除对应的osd记录
4 删除该OSD 的keyring信息
5 删除这个OSD
6 卸载掉OSD的数据目录挂载点
7 登录主管理节点，修改ceph.conf，删除其中的osd对应条目
8 将修改后的ceph.conf同步到ceph集群中的其他主机上
Ceph默认使用 存储池RBD存放数据，默认存放1个数据对象及其1个副本。默认给一个OSD分配100个PG。
新部署好的ceph集群中默认只有一个名为RBD的存储池。
新建存储池需要指明存储池的PG数量和PGP数量，以及存储池类型。
为了保证I/O正常，建议给存储池设置最小副本数。
删除存储池时，最好也删除其对应的规则集及其涉及的用户。
Crushmap确定了数据应如何存储及检索。它会尽量把数据随机地、平均地分不到集群的OSD中。Crushmap规则规定了如何放置数据对象副本。默认情况下，每个存储池都有一条规则，一般不需要修改默认规则。
手动管理crushmap需要在配置文件中设置“osd crush update on start = false”。
编辑crushmap需要：
1 获取当前集群的crushmap并保存为本地文件；
2 使用crushtool反编译保存的crushmap；
3 修改设备、桶、规则的信息；
4 重编译crushmap；
5 把新编译好的crushmap注入到Ceph集群。
Ceph中的权重与设备容量：1.00表示1TB的设备容量；0.5表示500GB设备容量。
使用 osd primary-affinity 设置的主OSD亲和性。
增加集群里OSD所对应的crushmap条目：ceph osd crush set ...
把集群里的某个OSD剔除出crushmap：ceph osd crush remove ...
调整某个OSD的crush权重：ceph osd crush reweight ...
在crushmap中建立两个树，一个用于让存储池映射到大容量的SATA硬盘构成的OSD上、一个用于让存储池映射到高速读写的SSD硬盘构成的OSD上。然后设置ssd-primary规则让存储池内的各归置组使用SSD型的OSD创建虚拟机的启动卷。
Monitor之间通过mon-map发现彼此。
修改一个Monitor的IP必须先增加一个新的Monitor以确保Ceph集群中的mon形成法定人数。而后删除旧的mon并更新ceph.conf中的mon信息。
修改Ceph集群的配置信息：
1 修改 /etc/ceph/ceph.conf 文件，并重启ceph各进程；
2 使用daemon或者tell的形式在运行的集群中修改（当时生效，重启ceph集群后失效，常用于调试或者调优或者排障）
***********************************************************
Monitor不能正常服务，则Ceph集群 不可用。
Monitor故障时的排查顺序：
Mon进程在运行吗？（检查本地磁盘空间足不足）
Mon Server可链接吗？（防火墙是否拦截）
执行“ceph -s”是否有响应？（Monitor没有形成法定人数时会输出大量fault信息，此时可用Unix套接字和mon进程交互获取信息；如果收到status信息，则说明已经形成了法定人数、且集群在运行着）
Unix套接字用于直接和守护进程交互。Monitor的socket在其节点的目录/run/下，默认位于 /var/run/ceph/ceph-mon.ID.asok 。
Probing状态意味着当前主机的Monitor还在根据monmap搜索其他Monitor。在多个Monitor环境中，未达到mon预定的法定人数前都会处于该状态。卡在probing状态的原因有三：主机的链接问题、节点间时钟不同步和monmap中的某个MonitorIP地址与试试IP地址不相符合。
Electing状态意味着当前主机的Monitor处于选举状态。如果卡在electing状态，原因一般是Monitor节点间时钟不同步。
Synchronizing状态意味着正在与其他Monitor进行同步。Monitor的数据库越小，同步越快。
如果Monitor的状态在Synchronizing和Electing之间反复，则说明集群状态更新速度超过了同步速度。
Leader或peon状态，通常和集群内各节点的时钟不同步有关。Ceph中允许的最大时钟偏移量是0.05秒。
修复受损的Monitor的monmap：
1 从剩余的Monitor中抓取monmap；
2 停止以受损的Monitor；
3 把抓取到的的monmap注入到目标Monitor；
4 启动目标Monitor
修复受损的Monitor的数据库store.db：
方法一：用幸存的Monitor的store.db覆盖已损坏的store.db
方法二：使用OSD上存储的信息恢复Monitor的数据库
1 从所有的OSD主机上搜集monmap信息；
2 使用ceph-monstore-tool重建store.db；
3 用重建的store.db替换已损坏的store.db；
4 重新导入相应的keyring、重新设置PG信息、重新打入MDS-map。
本地磁盘空间不足时Monitor服务会down掉。
停止CRUSH自动均衡：给集群设置 noout 标签。
OSD启动失败：
1 配置文件是否合规；
2 配置的数据和日志路径是否正确；
3 OSD的最大线程数是否超出了系统内核限制；
4 OSD是不是写满了（Ceph不允许向满的OSD中写入数据）
某个OSD挂了：
1 通过 ceph health detail 查看是哪个osd进程
2 登录到目标osd进程主机查看日志，一般是硬盘损坏的情况居多。
3 OSD是不是写满了（Ceph不允许向满的OSD中写入数据）
OSD响应慢：
1 网络问题导致OSD演示或震荡
2 磁盘没有独占用于OSD，有其他共享进程在进行顺序读写
3 磁盘存在坏的扇区
4 monitor进程和osd进程共享了磁盘
5 文件系统不恰当（推荐使用xfs）
6 内存不足（推荐为每个OSD进程规划1GB内存）
OSD震荡：public网（ceph管理网）运行正常、但Cluster网（ceph集群网）出现了网络连接失败或者明显延时。
***********************************************************
正常的PG状态应该是：active+clean。PG状态一直无法达到此状态，应该检查pool、pg、crush的配置。
允许把不同的数据副本分不到同一个host的OSD上：把cepf.conf中的 osd crush chooseleaf type 值改为 0。
OSD处于up&in状态、但PG未处于active+clean状态：给存储池的默认size设置了较大的值，需要恰当修改。Crushmap错误到最后PG不能映射到正确的OSD也是一个原因。
PG卡在stale状态可以通过重启OSD进程修复；
PG卡在inactive状态一般是osd进程互联失败了，重启对应的osd进程即可；
PG卡在unclean状态通常是未找到对象副本造成I/O阻塞，应及早恢复down的节点。
只有几个OSD在接受数据：PG数量比较少，未能均衡分布到整个集群的OSD上。
不能向Ceph集群写入数据：OSD启动的数量是否满足存储池PG要求的最小数量。
PG处于inconsistent状态：PG的数据清洗发生了错误，建议检查硬盘是否有损坏。剔除掉坏的硬盘、移除掉不一致的对象后，对集群进行 pg repair 修复。
每个OSD中有太多PG：OSD较少、但存储池较多，常见于测试环境。Ceph默认的是每个OSD上最多300个PG。可以通过调整monitor节点上的ceph.conf中的警告值规避。
每个OSD中有太少PG：OSD较多、但存储池较少。一般不需要理会，等到建立了存储池后该警告就会消失。
Ceph集群的上电启动步骤：
1 确认ceph的客户端作业已经停止；
2 先给MonitorServer上电；
3 确认节点间的时钟同步；
4 确认ceph服务已正常运行；
5确认OSD全部UP且集群的OSD仍处于noout状态；
6 解除集群的OSD noout状态；
7 执行 ceph -w 和 ceph -s 确认集群状态为 HEALTH_OK状态
从ceph集群中移除某个OSD节点：
1 登录Monitor节点查询集群状态；
2 把故障节点上的OSD全部设定为out；
3 从crushmap中移除目标osd；
4 删除 osd的keyring认证；
5 删除目标osd
***********************************************************
增加PG相当于在OSD上新建了PG目录，会引起对象数据分裂。
增加PGP会引起PG的分布变化。
PG制定了存储池中对象数据的目录有多少个；PGP决定了PG的分布组合个数。
备份恢复Monitor：
1 备份mon的store.db数据库
2 备份mon节点的 /etc/ceph/ 目录
3 把备份好的文件传送到新的目标操作主机并修改ceph.conf中的mon_initial_members角色为新的目标操作主机
4 在新的目标操作主机使用monmaptool新建一个monmap
5 在新的目标操作主机注入新建的monmap
6 启动新的目标操作主机上的mon进程
7 将新的目标操作主机上的ceph.conf推送到其他节点并重启ceph集群
OpenStack的cinder和glance都配置了Ceph存储。
在OpenStack上无法删除卷，发现有个cinder-volume状态为down；查看cinder-volume日志发现同一个时间点里有的删除成功、有的删除失败，怀疑是RBD存储卷卡死了。打开ceph.conf中的RBD Client日志，发现是进程打开的文件过多会引起的。这个环境进行过OSD扩容，RDB Client删除卷是需要和全部的OSD建立连接，超出了cinder-volume进程允许打开的最大文件数。修改cinder-volume进程的配置文件中的 limit nofile 值即可。
恢复OSD的分区表：
1 给集群设置 noout 标签
2 停止目标OSD进程
3 查看其它正常OSD 的分区信息，并记录data和journal分区的起始位置
4 使用parted工具完成分区表的创建
5 检查新建的分区表
6 把目标OSD挂载回数据目录
7 重建目标OSD 的journal日志
8 启动OSD
PG卡在active+remapped 状态，是因为对OSD做了reweight，导致PG无法映射到对应的OSD上。