Ceph 整体状态查看
代码语言:javascript复制ceph -s #ceph状态是否正常,及配置运行状态
ceph -w #实时查看数据写入情况
ceph health detail #如果集群有问题,会详细列出具体的pg或者osd
mon mon相关状态
代码语言:javascript复制ceph quorum_status -f json-pretty
client 无法链接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检测命令:
代码语言:javascript复制ceph osd set noout
这样在停止的OSD中的PG会变为降级态。当维护操作完成后,需要先启动停止的OSD,再恢复默认设置:
代码语言:javascript复制ceph osd unset noout
老/慢 请求 如果一个OSD服务进程很慢地响应请求。它会产生一个请求耗时过久超过30秒的警告提示信息。
代码语言:javascript复制{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选项。执行命令:
代码语言:javascript复制ceph osd set nodown
ceph osd set noup
ceph osd set noout
当集群健康稳定后,执行如下命令恢复默认值:
代码语言:javascript复制ceph osd unset nodown
ceph osd unset noup
ceph osd unset noout
确认磁盘损坏 检查日志,执行如下命令:
代码语言:javascript复制dmesg | egrep sd[a]
eg:
dmesg |egrep sda
通过smartctl提取信息和执行测试检查可疑的设备:
smartctl a /dev/sda
通过观察响应时间确认。任何磁盘持续显示不常见的值可能会失败:
iostat x /dev/sda
###替换osd数据磁盘### 当集群规模比较大,磁盘出硬件故障是一个常态。为了维持集群规模稳定,必须及时的修复因硬盘故障停止的OSD。 因为Ceph采用了多个副本的策略,一般情况下,不需要恢复坏掉硬盘的数据。用一个新硬盘初始化一个OSD即可。操作步骤如下:
代码语言:javascript复制两种情况:
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都要操作
代码语言:javascript复制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 noout
PG
代码语言:javascript复制ceph health detail #正常会返回 ok
PG 状态表 正常是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:
代码语言:javascript复制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
代码语言:javascript复制ceph pg dump_stuck stale
映射pg,找到osd:
代码语言:javascript复制ceph pg map {pgname}
重启上面的osd
代码语言:javascript复制ssh {osd-node}
systemctl restart ceph-osd@{osd-number}
peering 和 down PG 找到受影响的pg
代码语言:javascript复制ceph health detail
下面命令响应结果中的 “recovery_state”部分显示peering被停止 的原因,大多数的情况都是一些OSD挂掉。
代码语言:javascript复制ceph pg {pgname} query
尝试重启上面挂掉的OSD,如果无法启动,应该为执行如下命令标记为lost,让恢复操作开始。
代码语言:javascript复制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.如果还无法恢复,你可能只有放弃丢失的对象。执行如下命令回滚或删除对象:
代码语言:javascript复制ceph pg {pgname} mark_unfound_lost revert|delete
revert选项:回滚到对象的前一个版本
delete选项:完全删除这个对象
使用这个操作时注意,因为它可能是使预期存在这个对象的程序混乱。
列出带有丢失对象的PG的名字:
ceph pg {pgname} list_missing