2.6 监控OSD
查看集群OSD状态
# ceph osd stat
osdmap e50: 3 osds: 3 up, 3 in; 256 remapped pgs
flags sortbitwise,require_jewel_osds
更详细的状态
# ceph osd tree
ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY
-1 0.54538 root default
-2 0.18179 host ceph0
0 0.18179 osd.0 up 1.00000 1.00000
-3 0.18179 host ceph1
1 0.18179 osd.1 up 1.00000 1.00000
-4 0.18179 host ceph2
2 0.18179 osd.2 up 1.00000 1.00000
2.7 查看OSD信息
1、查看OSD映射信息
ceph osd dump
2、查看最大OSD个数
ceph osd getmaxosd
3、设置OSD的个数
ceph osd setmaxosd {num}
2.8 OSD标记
1、设置标记
阻止OSD up和down
ceph osd set noup # prevent OSDs from getting marked up
ceph osd set nodown # prevent OSDs from getting marked down
阻止OSD in和out
ceph osd set noin # prevent OSDs from getting marked in
ceph osd set noout # prevent OSDs from getting marked out
2、清除标记
将 set 改为 unset 即可，命令同上。
3、查询标记
查询OSD的标记情况
ceph osd dump | grep flags
flags no-up,no-down
noup 、 noout 和 nodown 从某种意义上说是临时的，一旦标记清除了，它们被阻塞的动作短时间内就会发生；相反， noin 标记阻止 OSD 启动后进入集群，但其它守护进程都维持原样。
4、停止自动均衡（noout）
在周期性地维护集群的子系统、或解决某个失败域的问题（如一机架）时，如果不想在停机维护 OSD 时让 CRUSH 自动重均衡，提前设置 noout ：
ceph osd set noout
在集群上设置 noout 后，就可以停机维护失败域内的 OSD 了。
stop ceph-osd id={num}
在定位同一故障域内的问题时，停机 OSD 内的归置组状态会变为 degraded。
维护结束后，重启OSD。
start ceph-osd id={num}
最后，解除 noout 标志。
ceph osd unset noout
2.9 OSD故障
1、不能正常运行
- 如果有个硬盘失败或其它错误使 ceph-osd 不能正常运行或重启，一条错误信息将会出现在日志文件 /var/log/ceph/ 里。
- 如果守护进程因心跳失败、或者底层文件系统无响应而停止，查看 dmesg 获取硬盘或者内核错误。
2、硬盘没剩余空间
Ceph 不允许向满的 OSD 写入数据，以免丢失数据。在运营着的集群中，你应该能收到集群空间将满的警告。
mon osd full ratio 默认为 0.95 、或达到 95% 时它将阻止客户端写入数据。 mon osd nearfull ratio 默认为 0.85 、也就是说达到容量的 85% 时它会产生健康警告。
满载集群问题一般产生于测试 Ceph 在小型集群上如何处理 OSD 失败时。当某一节点利用率较高时，集群能够很快掩盖将满和占满率。如果你在测试小型集群上的 Ceph 如何应对 OSD 失败，应该保留足够的空间，然后试着临时降低 mon osd full ratio 和 mon osd nearfull ratio 值。
ceph health 会显示将满的 ceph-osds ：
ceph health
HEALTH_WARN 1 nearfull osds
osd.2 is near full at 85%
处理这种情况的最好方法就是增加新的 ceph-osd ，这允许集群把数据重分布到新 OSD 里。
如果因满载而导致 OSD 不能启动，你可以试着删除那个 OSD 上的一些归置组数据目录。
3、OSD速度慢或无响应
- 网络问题
Ceph 是一个分布式存储系统，所以它依赖于网络来互联 OSD 们、复制对象、恢复错误、和检查心跳。网络问题会导致 OSD 延时和打摆子。
如果集群网（后端）失败、或出现了明显的延时，同时公网（前端）却运行良好， OSD 现在不能很好地处理这种情况。这时 OSD 们会向监视器报告邻居 down 了、同时报告自己是 up 的，我们把这种情形称为打摆子（ flapping ）。
确保 Ceph 进程和 Ceph 依赖的进程连接了、和/或在监听。
netstat -a | grep ceph
netstat -l | grep ceph
sudo netstat -p | grep ceph
检查网络统计信息。
netstat -s
- 内存不足
我们建议为每 OSD 进程规划 1GB 内存。你也许注意到了，通常情况下 OSD 仅会用一小部分（如 100-200MB ）。你也许想用这些空闲内存跑一些其他应用，如虚拟机等等，然而当 OSD 进入恢复状态时，其内存利用率激增，如果没有可用内存，此 OSD 的性能将差的多。
- 驱动器配置
一个存储驱动器应该只用于一个 OSD 。如果有其它进程共享驱动器，顺序读和顺序写吞吐量会成为瓶颈，包括日志记录、操作系统、监视器、其它 OSD 和非 Ceph 进程。
Ceph 在日志记录完成之后才会确认写操作，所以使用 ext4 或 XFS 文件系统时高速的 SSD 对降低响应延时很有吸引力。相反， btrfs 文件系统可以同时读写。
给驱动器分区并不能改变总吞吐量或顺序读写限制。把日志分离到单独的分区可能有帮助，但最好是另外一块硬盘的分区。
其他如坏扇区和碎片化硬盘、监视器和 OSD 蜗居、进程蜗居、日志记录级别、恢复节流、内核版本、文件系统问题等原因详细参考OSD故障排除。