Ceph组件的状态
Ceph 整体状态查看
ceph -s #ceph状态是否正常，及配置运行状态
ceph -w #实时查看数据写入情况
ceph health detail #如果集群有问题，会详细列出具体的pg或者osdmon mon相关状态
ceph quorum_status -f json-prettyclient 无法链接mon的可能原因 1.连通性和防火墙规则。在MON主机上修改允许TCP 端口6789的访问。 2.磁盘空间。每个MON主机上必须有超过5%的空闲磁盘空间使MON和levelDB数据库正常工作。 3.MON没有工作或者离开选举，检查如上命令输出结果中的quorum_status和mon_status或者ceph -s 的输出来确定失败的MON进程，尝试重启或者部署一个新的来替代它。
MON 状态表
时钟偏移警告 MON可能被MON节点之间的重要的时钟偏移激烈的影响。这经常会转变为没有明显原因的诡异的行为。为了避免这种问题，应该在MON节点上运行一个时间同步的工具。默认最大容忍的时钟偏移为0.05s，虽然可以修改，但不建议修改，这是官方开发和QA认可的值。私自未经测试修改虽然无数据丢失风险，可能会对MON集群和总体集群健康导致意外的作用。 如果遇到这个告警，同步时钟，在MON上运行NTP的客户端会有帮助。如果经常遇到这个问题，可能是因为使用了远端的NTP服务器，请考虑在内网部署NTP服务器。
OSD OSD 状态表
常见问题 1.硬盘失败。可以通过系统日志或SMART活动确认。有些有缺陷的硬盘因为密集的有时限的错误修复活动变的很慢。 2.网络连接问题。可以使用ping、iperf等普通网络工具进行调试。 3.OSD文件存储的磁盘空间不足。 磁盘到85%将会触发HEALTH_WARN告警。磁盘到95%会触发HEALTH_ERR告警，OSD为了避免填满磁盘会停止。 4.超过系统资源限制。系统内存应该足够主机上所有的OSD进程，打开文件句柄数和最大线程数也应该是足够的。 OSD进程处理心跳的限制导致进程自杀。默认的处理和通信超时不足以执行IO饥饿型的操作，尤其是失败后的恢复。这经常会导致OSD闪断的现象出现。
暂时关闭pg重新平衡 在维护操作或解决问题时，不希望在停止一些OSD后，超时的OSD被标记为out后，CRUSH算法自动进行重新平衡操作。需要执行集群关闭out检测命令：
ceph osd set noout这样在停止的OSD中的PG会变为降级态。当维护操作完成后，需要先启动停止的OSD，再恢复默认设置：
ceph osd unset noout老/慢 请求 如果一个OSD服务进程很慢地响应请求。它会产生一个请求耗时过久超过30秒的警告提示信息。
{date} {osd.num} [WRN] 1 slow requests, 1 included below; oldest blocked for > 30.005692 secs
{date} {osd.num} [WRN] slow request 30.005692 seconds old, received at {date-time}: osd_op(client.4240.0:8 benchmark_data_ceph-1_39426_object7 [write 0~4194304] 0.69848840) v4 currently waiting for subops from [610]1.可能的原因和修复方法包括： 2.硬盘故障（检查dmesg的输出信息）；替换为正常的硬盘 3.内核文件系统bug（检查dmesg的输出信息确）；升级内核 4.集群负载过高（检查系统负载、iostat等）；机器扩容，尝试降低系统负载 5.ceph-osd服务进程的的bug；升级ceph或重启OSD
OSD 闪断 OSD重启或恢复中后，OSD在peering状态一直闪断。因为IO密集型的任务导致影响心跳检测异常，你可以暂时为集群通过打开nodown noup选项。执行命令：
ceph osd set nodown
ceph osd set noup
ceph osd set noout当集群健康稳定后，执行如下命令恢复默认值：
ceph osd unset nodown
ceph osd unset noup
ceph osd unset noout确认磁盘损坏 检查日志，执行如下命令：
dmesg | egrep sd[a]
eg:
dmesg |egrep sda
通过smartctl提取信息和执行测试检查可疑的设备:
smartctl a /dev/sda
通过观察响应时间确认。任何磁盘持续显示不常见的值可能会失败：
iostat x /dev/sda###替换osd数据磁盘### 当集群规模比较大，磁盘出硬件故障是一个常态。为了维持集群规模稳定，必须及时的修复因硬盘故障停止的OSD。 因为Ceph采用了多个副本的策略，一般情况下，不需要恢复坏掉硬盘的数据。用一个新硬盘初始化一个OSD即可。操作步骤如下：
两种情况：
a. 如果磁盘坏掉osd会标记为down，默认300秒osd会被标记为out，数据会开始迁移。所以我们替换osd数据磁盘，确保数据迁移完成，集群状态是ok。
b. 如果磁盘将要损坏，但还没有坏，仍然是up&in的，则需要先把该osd 设置为out: ceph osd out osd.0,这样集群会把osd.0的数据 rebalancing and copying到其他机器上去。直到整个集群编程active+clean，再进行后续操作
1. 关闭 osd.0的进程
systemctl stop ceph-osd@0
2. 删除旧osd信息(osd.0为例)：
ceph osd crush remove osd.0
ceph auth del osd.0
ceph osd rm 0
3. 创建新osd
a. ceph osd create #会自动生成uuid和osd-number
b. ssh {new_osd_host}
c. sudo mkdir /var/lib/ceph/osd/ceph-{osd-number} #上一步生成的osd-number
d. 分区 通过parted把osd的磁盘分区为一个分区
e. sudo mkfs -t xfs /dev/{drive} # 上一步分区
f. sudo mount /dev/{sdx} /var/lib/ceph/osd/ceph-{osd-number}
g. ceph-osd -i {osd-number} --mkfs --mkkey # 初始化osd数据目录
目录必须为空
h. ceph auth add osd.{osd-number} osd 'allow *' mon 'allow rwx' -i /var/lib/ceph/osd/ceph-{osd-number}/keyring #注册认证key
i. ceph osd crush add osd.{osd-number}# 添加osd到crush map，则该osd可以接受数据了，这个时候osd的状态为 down & in。ceph osd crush add osd.0 1.0 host=bj-yh-ceph-node2
j. systemctl start ceph-osd@{osd-number} # 启动osd进程，数据会rebalancing and migrating 到新的osd上替换ssd日志磁盘 由于我们使用过程中，一块ssd分4个区，给4个osd使用，所以如果ssd日志磁盘坏掉，需要给对应的osd都要操作
1. 设置OSD状态为noout，防止数据重新平衡
ceph osd set noout
2. 停止osd进程
ssh {ssd所在节点}
systemctl stop ceph-osd@x #ssd所对应的osds
3. 日志数据落盘到数据盘
ceph-osd -i {osd-number} --flush-journal #该ssd日志分区所对应的所有osd-number
4. 删除日志链接
rm -rf /var/lib/ceph/osd/{osd-number}/journal # #该ssd日志分区所对应的所有osd-number
5. 创建日志链接
ln -s /dev/disk/by-partuuid/{uuid} /var/lib/ceph/osd/ceph-{osd-number}/journal # 注意别把使用中的分区给绑定错了
chown ceph:ceph /var/lib/ceph/osd/ceph-{osd-number}/journal
echo {uuid} > /var/lib/ceph/osd/ceph-{osd-number}/journal_uuid #前面/dev/disk/by-partuuid/{uuid} uuid
6. 创建日志
ceph-osd -i {osd-number} --mkjournal
7. 启动osd进程
systemctl start ceph-osd@{osd-number}
如果所有osd进程都起来了
8. 去除noout的标记
ceph osd set nooutPG
ceph health detail #正常会返回 okPG 状态表 正常是active+clean
PG 长时间卡在一些状态 遇到失败后PG进入如 “degraded” 或 “peering”的状态是正常的。通常这些状态指示失败恢复处理过程中的正常继续。然而，一个PG长时间保持在其中一些状态可能是一个更大问题的提示。因此，MON当PG卡在一个非正常态时会警告。 我们特别地检查：
1.inactive : PG太长时间不在active态，例如PG长时间不能处理读写请求，通常是peering的问题。 2.unclean : PG太长时间不在clean态，例如PG不能完成从上一个失败的恢复，通常是unfound objects导致。 3.stale : PG状态未被OSD更新，表示所有存储PG的OSD可能挂掉，一般启动相应的OSD进程即可。
在MON节点执行如下命令，可以明确列出卡住的PG：
ceph pg dump_stuck stale
ceph pg dump_stuck inactive
ceph pg dump_stuck unclean
Ceph清理和深度清理后到PG处于inconsistent态：
清理操作被用来检查对象的可用性和健康状态。当集群没有IO密集型（例如恢复）的操作时PG被清理，已经执行清理操作再执行IO密集操作，然而清理操作继续。如果清理任务发现任何对象有损坏或者不匹配的数据（校验和检测），它将标记这个对象为不能使用并且需要手动介入和恢复。OSD执行写操作时计算校验和，Ceph并不能武断地决定副本中的哪个校验和是正确的。例如有3个副本的校验和，有1个不同，很容易猜出应该修复的错误副本（从其他副本恢复），但是当有3个不同的校验和或者一些比特错误，我们不能武断的说哪个是好的。这不是一个端到端的数据修正检查。
手动修复损坏的pg
1. 找到有不一致对象的PG， 执行如下命令 ceph pg dump | grep inconsistent 或者 ceph health detail
2. 当主副本是正确数据时，执行修复命令。或者通过在OSD的硬盘上手动复制正确的文件覆盖掉错误的文件。 ceph pg repair {pgnum}
注意：如果主副本错误，应该使用手动修复，如果通过命令修复则会把主副本的错误数据复制到其他副本。incomplete PG 这个告警是因为实际副本数少于min_size。可能是由于PG对应的OSD挂掉导致。尝试启动挂掉的OSD。
stale PG 简单地重启受影响的OSD。当一个OSD不能映射它持有所有的对象时这个问题发生,执行如下操作：
找到PG
ceph pg dump_stuck stale映射pg，找到osd：
ceph pg map {pgname}重启上面的osd
ssh {osd-node}
systemctl restart ceph-osd@{osd-number}peering 和 down PG 找到受影响的pg
ceph health detail下面命令响应结果中的 “recovery_state”部分显示peering被停止 的原因,大多数的情况都是一些OSD挂掉。
ceph pg {pgname} query尝试重启上面挂掉的OSD，如果无法启动，应该为执行如下命令标记为lost，让恢复操作开始。
ceph osd lost {osd-number}unfound objects 在特殊的失败组合下Ceph会警告unfound objects。这意味着存储集群知道有些对象存在，但是却无法找到它的副本。下面的例子说明这是怎么发生的，有1个PG他映射的的OSD是 1和2：
1.OSD 1挂掉 2.OSD 2单独处理一些请求 3.OSD 1运行 4.OSD 1和2重新peering，1上丢失的对象在队列中等待恢复 5.在新对象之前被复制之前，OSD2挂掉 现在OSD 1知道一些对象存在，但是没有这个副本活的OSD。 这种情况下，到这些对象的IO将被阻塞，集群希望失败的OSD快速地回来。这时假设返回一个IO错误给用户是适当的。 修复建议： 6.启动停止的osd 7.如果还无法恢复，你可能只有放弃丢失的对象。执行如下命令回滚或删除对象：
ceph pg {pgname} mark_unfound_lost revert|delete
revert选项：回滚到对象的前一个版本
delete选项：完全删除这个对象
使用这个操作时注意，因为它可能是使预期存在这个对象的程序混乱。
列出带有丢失对象的PG的名字：
ceph pg {pgname} list_missing