运维问题集合

一、运维问题集合

1.1磁盘坏道

• 问题描述：ceph集群中osd处于down状态
• 排查此路：查看系统日志：

# 登录osd所在节点
# grep -ri 'osd.361' -C 5  /var/log/message
an 10 09:22:21 node-39 bash: 17: (ThreadPool::worker(ThreadPool::WorkThread*)+0xa76) [0xbb9966]
Jan 10 09:22:21 node-39 bash: 18: (ThreadPool::WorkThread::entry()+0x10) [0xbba9f0]
Jan 10 09:22:21 node-39 bash: 19: (()+0x7dc5) [0x7f8010be5dc5]
Jan 10 09:22:21 node-39 bash: 20: (clone()+0x6d) [0x7f800f6c6ced]
Jan 10 09:22:21 node-39 bash: NOTE: a copy of the executable, or `objdump -rdS <executable>` is needed to interpret this.
Jan 10 09:22:21 node-39 bash: /bin/bash: line 1:  5534 Aborted                 /usr/bin/ceph-osd -i 361 --pid-file /var/run/ceph/osd.361.pid -c /etc/ceph/ceph.conf --cluster ceph -f
Jan 10 09:22:21 node-39 systemd: ceph-osd.361.1510712687.110995314.service: main process exited, code=exited, status=134/n/a
Jan 10 09:22:22 node-39 systemd: Device dev-disk-by\x2dpartlabel-ceph\x5cx20journal.device appeared twice with different sysfs paths /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:2:14/0:2:14:0/block/sdo/sdo2 and /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:2:9/0:2:9:0/block/sdj/sdj2
Jan 10 09:22:38 node-39 bash: 2018-01-10 09:22:38.084176 7fa375338700 -1 osd.360 167456 heartbeat_check: no reply from osd.361 since back 2018-01-10 09:22:17.441618 front 2018-01-10 09:22:17.441618 (cutoff 2018-01-10 09:22:18.084169)
Jan 10 09:22:38 node-39 bash: 2018-01-10 09:22:38.550245 7fa349973700 -1 osd.360 167456 heartbeat_check: no reply from osd.361 since back 2018-01-10 09:22:17.441618 front 2018-01-10 09:22:17.441618 (cutoff 2018-01-10 09:22:18.550241)
Jan 10 09:22:39 node-39 bash: 2018-01-10 09:22:39.093160 7fa375338700 -1 osd.360 167456 heartbeat_check: no reply from osd.361 since back 2018-01-10 09:22:17.441618 front 2018-01-10 09:22:17.441618 (cutoff 2018-01-10 09:22:19.093153)
# 查看ceph-osd.log： /var/log/ceph/ceph-osd.361.log
isting 401 state standby
2018-01-10 09:22:13.246615 7f7fddea2700  0 log_channel(cluster) log [INF] : 2.1db deep-scrub starts
2018-01-10 09:22:21.656003 7f7fddea2700 -1 os/FileStore.cc: In function 'virtual int FileStore::read(coll_t, const ghobject_t&, uint64_t, size_t, ceph::bufferlist&, uint32_t, bool)' thread 7f
7fddea2700 time 2018-01-10 09:22:21.514511
os/FileStore.cc: 2854: FAILED assert(allow_eio || !m_filestore_fail_eio || got != -5)

 ceph version 0.94.6 (e832001feaf8c176593e0325c8298e3f16dfb403)
 1: (ceph::__ceph_assert_fail(char const*, char const*, int, char const*)+0x85) [0xbc9195]
 2: (FileStore::read(coll_t, ghobject_t const&, unsigned long, unsigned long, ceph::buffer::list&, unsigned int, bool)+0xc94) [0x909f34]
 3: (ReplicatedBackend::be_deep_scrub(hobject_t const&, unsigned int, ScrubMap::object&, ThreadPool::TPHandle&)+0x311) [0x9fe0e1]
 4: (PGBackend::be_scan_list(ScrubMap&, std::vector<hobject_t, std::allocator<hobject_t> > const&, bool, unsigned int, ThreadPool::TPHandle&)+0x2e8) [0x8ce8c8]
 5: (PG::build_scrub_map_chunk(ScrubMap&, hobject_t, hobject_t, bool, unsigned int, ThreadPool::TPHandle&)+0x213) [0x7def53]
 6: (PG::chunky_scrub(ThreadPool::TPHandle&)+0x498) [0x7e73a8]
 7: (PG::scrub(ThreadPool::TPHandle&)+0x21c) [0x7e89fc]
 8: (OSD::ScrubWQ::_process(PG*, ThreadPool::TPHandle&)+0x29) [0x6c2059]
 9: (ThreadPool::worker(ThreadPool::WorkThread*)+0xa76) [0xbb9966]
 10: (ThreadPool::WorkThread::entry()+0x10) [0xbba9f0]
 11: (()+0x7dc5) [0x7f8010be5dc5]
 12: (clone()+0x6d) [0x7f800f6c6ced]
 NOTE: a copy of the executable, or `objdump -rdS <executable>` is needed to interpret this.
# 怀疑是磁盘问题，执行dmesg查看：
# dmesg -l err
[    2.174875] i8042: No controller found
[    2.760829] megasas:IOC Init cmd success
[    2.841520] megasas: INIT adapter done
[    5.870202] mei_me 0000:00:16.0: initialization failed.
[4839469.414063] blk_update_request: critical medium error, dev sdj, sector 454961360
[4839469.437926] blk_update_request: critical medium error, dev sdj, sector 454961400
[4839469.441078] blk_update_request: critical medium error, dev sdj, sector 454961400

从日志可以看出sdj有磁盘坏道

• 处理方法：更换osd盘

1.2 集群提示HEALTH_WARN: OSD near full

• 问题描述：集群健康状态显示HEALTH_WARN，当磁盘使用率达到85%（默认阈值）时触发该告警，达到95%时OSD会停止写入。

• 问题排查

1. 执行 ceph health detail 查看具体是哪个osd快满了。
2. 执行ceph osd df，查看所有OSD的磁盘使用率、已用空间、剩余空间，定位使用率过高的OSD节点。
3. 确认OSD满阈值配置，执行ceph config get osd mon_osd_full_ratio、ceph config get osd mon_osd_nearfull_ratio，查看当前阈值设置。

• 处理方法

1. 清理无用数据：删除集群中过期、无用的数据（如测试数据、备份过期数据）。
2. 扩容集群：添加新的OSD节点或在现有节点添加新磁盘
3. 调整数据均衡：执行ceph osd reweight-by-utilization，让集群根据OSD使用率自动调整权重，将数据迁移至使用率较低的OSD。
4. 临时调整阈值（谨慎使用）：若暂时无法扩容或清理数据，可临时提高阈值，执行ceph config set osd mon_osd_nearfull_ratio 0.9（调整为90%）、ceph config set osd mon_osd_full_ratio 0.96（调整为96%），后续需及时扩容或清理。

1.3 集群提示HEALTH_WARN: host nearfull

• 问题描述：集群健康状态显示HEALTH_WARN，host is nearfull

• 问题排查

1. 执行 ceph health detail 查看具体是哪个节点快满了。
2. 执行 df -h 查看是哪个目录占用快满了。
3. 执行 du -sh查看目录下具体哪个文件夹占用比较多。

• 处理方法

1. 清理目标节点的文件夹中部分数据。

1.4 node23的osd一会儿up，一会儿down

• 问题描述：node23节点上的osd一会儿up，一会儿down
• 问题排查：

1. node23节点ping monitor节点和其他osd所在节点，发现不通，但是端口和上层网络设备都是ok的。
2. 检查node23节点的防火墙规则、iptables规则，发现node23节点加了一条拒接icmp的iptables规则

• 处理方法：删除该iptables规则

1.5 MON集群异常，部分MON节点down

• 问题描述：ceph status查看发现MON集群状态异常，提示“mon is down: mon.xxx”，集群无法执行配置修改、OSD管理等操作，严重时集群整体不可用。

• 问题排查

1. 查看MON节点日志，路径/var/log/ceph/ceph-mon.xxx.log，搜索“connection refused”“fail to join quorum”等关键词，定位异常原因。
2. 检查MON节点网络状态，执行ping <其他MON节点IP>、telnet <其他MON节点IP> 6789（MON默认端口），确认网络连通性，无防火墙拦截。
3. 检查MON数据目录，路径/var/lib/ceph/mon/ceph-xxx，确认目录完整、权限正确（ceph:ceph），无数据损坏。
4. 查看MON集群成员状态，执行ceph mon stat、ceph quorum_status，确认quorum集群是否正常，是否有节点退出quorum。

• 处理方法

1. 若为网络问题：检查防火墙规则（firewall-cmd –list-ports，确保6789端口开放），修复网络故障（如重启网卡、调整路由），之后重启MON进程（systemctl start ceph-mon@xxx），等待节点重新加入quorum。
2. 若为MON进程异常：重启MON进程（systemctl restart ceph-mon@xxx），若重启失败，执行ceph-mon -i xxx –reset-mon-clock，重置MON时钟后再启动。
3. 若为数据损坏：停止MON进程，删除损坏的MON数据目录（rm -rf /var/lib/ceph/mon/ceph-xxx），重新部署MON（ceph orch daemon add mon <节点名>），等待节点同步数据、加入quorum。
4. 若为quorum异常：若剩余MON节点数量不足quorum（默认需超过半数），添加新的MON节点或重启故障节点，确保quorum节点数量达标，执行ceph mon quorum force-new-election，强制触发新的选举。
5. 恢复后检查：ceph mon stat确认所有MON节点up，ceph quorum_status确认quorum正常，集群健康状态恢复HEALTH_OK。

1.6 集群提示HEALTH_ERR: PG inconsistent

• 问题描述：ceph health detail提示“PG xxx is inconsistent”，PG状态为active+inconsistent，说明PG的主副本和从副本数据不一致，可能导致数据丢失或读取异常。

• 问题排查

1. 执行ceph pg <pg-id> query，查看PG的“up”“acting”列表，确认关联的OSD节点状态，是否有OSD曾发生down、重启情况。
2. 查看PG不一致详情，执行ceph pg <pg-id> repair --dry-run，查看哪些对象数据不一致，定位异常对象。
3. 检查OSD日志，查看是否有数据写入失败、校验错误等信息，排查数据不一致的原因（如磁盘错误、网络中断导致写入不完整）。
4. 确认集群是否发生过断电、OSD异常重启等情况，此类场景易导致PG数据不一致。

• 处理方法

1. 常规修复：执行ceph pg repair <pg-id>，让集群自动对比主从副本数据，以主副本为准修复从副本，修复完成后查看PG状态是否变为active+clean。
2. 强制修复（主副本损坏时）：若主副本数据损坏，执行ceph pg <pg-id> set-primary-affinity 0（取消主副本亲和性），让集群重新选举健康的从副本作为主副本，再执行ceph pg repair <pg-id>。
3. 手动修复（修复失败时）：执行rados list-inconsistent-obj <pg-id> -p <pool名>，查看不一致的对象，手动删除损坏的对象（rados rm <对象名> -p <pool名>），再执行ceph pg repair <pg-id>。

1.7 集群提示HEALTH_WARN: Clock skew detected on mon.xxx

• 问题描述：ceph health detail提示“Clock skew detected on mon.xxx”，表示MON节点之间时钟不同步，时钟偏差超过阈值（默认0.05秒），会导致MON集群quorum异常、日志混乱，影响集群稳定性。

• 问题排查

1. 查看各MON节点时钟，执行date命令，对比所有MON节点的系统时间，确认时钟偏差情况。
2. 检查节点NTP服务状态，执行systemctl status chronyd（或ntpd），确认NTP服务是否正常运行，是否配置了正确的NTP服务器。
3. 检查集群时钟偏差阈值配置，执行ceph config get mon mon_clock_drift_allowed，查看当前阈值设置。

• 处理方法

1. 启动并配置NTP服务：若NTP服务未运行，执行systemctl start chronyd，systemctl enable chronyd，配置NTP服务器（编辑/etc/chrony.conf，添加server ntp.aliyun.com iburst），重启chronyd服务。
2. 手动同步时钟：执行chronyc -a makestep，强制同步系统时钟，之后执行date确认各MON节点时钟一致。
3. 检查网络：确保MON节点能正常访问配置的NTP服务器，执行ping ntp.aliyun.com，若网络不通，修复网络故障或更换可用的NTP服务器。
4. 验证修复：执行ceph health，确认时钟偏差告警消失，ceph mon stat确认MON集群quorum正常。

1.8 Ceph CLI命令执行失败，提示“PermissionError”或“ConnectionRefusedError”

• 问题描述：执行ceph status、ceph osd df等CLI命令时失败，提示“PermissionError: [Errno 13] Permission denied”或“ConnectionRefusedError: [Errno 111] Connection refused”，无法获取集群信息。

• 问题排查

1. 检查ceph配置文件权限，路径/etc/ceph/ceph.conf，确认权限为644，所有者为root:root，避免权限不足导致无法读取配置。
2. 检查ceph客户端密钥权限，路径/etc/ceph/ceph.client.admin.keyring，确认权限为600，所有者为root:root，密钥文件是否存在、完整。
3. 检查MON节点网络状态，确认CLI执行节点能正常访问MON节点IP和6789端口，无防火墙拦截，执行telnet <MON节点IP> 6789。
4. 检查MON集群状态，确认MON集群quorum正常，若MON集群异常，会导致CLI命令无法连接集群。

• 处理方法

1. 若为权限问题：调整配置文件和密钥文件权限，执行chmod 644 /etc/ceph/ceph.conf，chmod 600 /etc/ceph/ceph.client.admin.keyring，chown root:root /etc/ceph/*。
2. 若为密钥文件缺失/损坏：从健康的MON节点复制ceph.client.admin.keyring文件到当前节点，或重新生成admin密钥（ceph auth get-or-create client.admin mon 'allow *' osd 'allow *' mds 'allow *' > /etc/ceph/ceph.client.admin.keyring）。
3. 若为网络问题：开放CLI节点与MON节点之间的6789端口，修复网络故障，确保网络可达，之后重新执行CLI命令。