CEPH状态检查-故障定位
常见故障定位诊断的手段：
监视器
运行日志
套接字管理
诊断信息
监视器
检查集群状态：
ceph -s
cluster:
id: f60e6370-14ff-44cc-b99c-70b17df8549c
health: HEALTH_OK
services:
mon: 1 daemons, quorum ecos75r018-meijia-31-161 (age 2w)
mgr: ecos75r018-meijia-31-161(active, since 4w)
osd: 3 osds: 3 up (since 100m), 3 in (since 17h)
data:
pools: 2 pools, 192 pgs
objects: 47.70k objects, 184 GiB
usage: 552 GiB used, 2.5 TiB / 3.0 TiB avail
pgs: 192 active+cleanceph health or ceph health detail
HEALTH_OK
HEALTH_OK表示集群状态健康，出现HEALTH_WARN甚至HEALTH_ERR表示集群处于非正常状态
检查osd节点状态：
ceph osd tree or ceph osd status
ceph osd tree:
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 3.00000 root default
-7 1.00000 host ecos75r018-meijia-31-161
2 hdd 1.00000 osd.2 up 1.00000 1.00000
-3 1.00000 host ecos75r018-meijia-31-162
0 hdd 1.00000 osd.0 up 1.00000 1.00000
-5 1.00000 host ecos75r018-meijia-31-163
1 hdd 1.00000 osd.1 up 1.00000 1.00000ceph osd status:
+----+--------------------------+-------+-------+--------+---------+--------+---------+-----------+
| id | host | used | avail | wr ops | wr data | rd ops | rd data | state |
+----+--------------------------+-------+-------+--------+---------+--------+---------+-----------+
| 0 | ecos75r018-meijia-31-162 | 183G | 840G |0 | 0 |3 | 0 | exists,up |
| 1 | ecos75r018-meijia-31-163 | 183G | 840G |0 | 0 |0 | 0 | exists,up |
| 2 | ecos75r018-meijia-31-161 | 183G | 840G |0 | 0 |0 | 0 | exists,up |
+----+--------------------------+-------+-------+--------+---------+--------+---------+-----------+
状态为UP表示正常，为down表示异常
运行日志
如果没有改默认路径，可以在/var/log/ceph/下找到运行日志
ls /var/log/ceph
如果设置了日志路径，在log_file参数指定的路径下查看运行日志
套接字管理
通过套接字管理可以检索运行时的信息，套接字列表：
ls /var/run/ceph
[root@ecos75r018-meijia-31-163 ceph]# ls /var/run/ceph/
ceph-osd.1.asok
列出所有可查看的运行信息：
ceph daemon osd.1 help
or
ceph daemon {socket-file} help
例如查看运行时的配置参数：
ceph daemon osd.1 config show
ceph daemon osd.1 config show | grep mon_osd_full_ratio
诊断信息
要查看诊断信息，配合less、more、grep或tail使用dmesg，例如：
dmesg | grep scsi
故障处理前置操作
停止自动重均衡
在你周期性地维护集群的子系统、或解决某个失败域的问题（如一机架）。如果你不想在停机维护OSD时让CRUSH自动重均衡，需提前设置noout：
ceph osd set noout
在集群上设置noout后，你就可以停机维护失败域内的OSD了
stop ceph-osd id={num}
Note：在定位同一故障域内的问题时，停机 OSD 内的归置组状态会变为 degraded
维护结束后，重启OSD
start ceph-osd id={num}
最后，解除 noout 标志
ceph osd unset noout
OSD没运行
通常情况下，简单的重启ceph-osd进程就可以重回集群并恢复数据
systemctl restart ceph-osd@{osd-id}.service
or
systemctl restart ceph-osd@{hostname}.service
OSD启动失败
如果你重启了集群，但其中一个OSD起不来，依次检查：
配置文件：如果你新装的 OSD 不能启动，检查下配置文件，确保它合理性（比如host而非hostname，等等）；
检查路径：检查你配置的路径，以及它们自己的数据和日志路径。如果你分离了 OSD 数据和日志、而配置文件和实际挂载点存在出入，启动 OSD 时就可能出错。如果你想把日志存储于一个块设备，应该为日志硬盘分区并为各 OSD 分别分配一分区。
检查最大线程数：如果你的节点有很多 OSD ，也许就会触碰到默认的最大线程数限制（如通常是32k个），尤其是在恢复期间。你可以用 sysctl 增大线程数，把最大线程数更改为支持的最大值（即 4194303），看看是否有用。例如：
sysctl -w kernel.pid_max=4194303
如果增大最大线程数解决了这个问题，你可以把此配置 kernel.pid_max 写入配置文件 /etc/sysctl.conf，使之永久生效，例如：
kernel.pid_max = 4194303
内核版本：确认你在用的内核版本以及所用的发布版。Ceph 默认依赖一些第三方工具，这些工具可能有缺陷或者与特定发布版和/或内核版本冲突（如 Google perftool ）。检查下操作系统推荐确保无内核问题。
OSD服务挂掉
ceph-osd 挂掉时，监视器可通过活着的 ceph-osd 了解到此情况，且通过 ceph health 命令报告：
ceph health
HEALTH_WARN 1/3 in osds are down
而且，有 ceph-osd 进程标记为 in 且 down 的时候，你会得到警告，你可以用下面的命令得知哪个 ceph-osd 进程挂了：
ceph health detail
HEALTH_WARN 1/3 in osds are down
osd.0 is down since epoch 23, last address 192.168.106.220:6800/11080
如果是硬盘问题或其它错误使 ceph-osd 不能正常运行或重启，查看日志文件/var/log/ceph/中的错误信息。
如果守护进程因心跳失败、或者底层文件系统无响应而停止，查看dmesg获取硬盘或者内核错误。
磁盘没有剩余空间
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 health
HEALTH_ERR 1 nearfull osds, 1 full osds
osd.2 is near full at 85%
osd.3 is full at 97%
处理这种情况的最好方法就是增加新的ceph-osd，这允许集群把数据重分布到新OSD里。
如果因满载而导致OSD不能启动，你可以试着删除那个OSD上的一些归置组数据目录
如果你准备从填满的OSD中删除某个归置组，注意不要删除另一个OSD 上的同名归置组，否则你会丢数据。必须在多个OSD上保留至少一份数据副本。
OSD龟速或无响应
一个容易反复出现的问题是OSD龟速或无响应。在深入性能问题前，你应该先确保不是其他故障。例如，确保你的网络运行正常、且OSD在运行，还要检查 OSD 是否被恢复流量拖住了
网络问题
Ceph 是一个分布式存储系统，所以它依赖于网络来互联OSD、复制对象、恢复错误、和检查心跳。网络问题会导致OSD延时和FLapping(反复地被标记为down,然后又up)
确保Ceph进程和Ceph依赖的进程连接了或在监听
netstat -a | grep ceph
netstat -l | grep ceph
sudo netstat -p | grep ceph
检查网络统计信息。
netstat -s
驱动器配置
一个存储驱动器应该只用于一个OSD。如果有其它进程共享驱动器，顺序读和顺序写吞吐量会成为瓶颈，包括日志记录、操作系统、监视器、其它 OSD 和非Ceph进程。
Ceph在日志记录完成之后才会确认写操作，所以使用ext4或XFS文件系统时高速的SSD对降低响应延时很有吸引力。相反，btrfs文件系统可以同时读写。
给驱动器分区并不能改变总吞吐量或顺序读写限制。把日志分离到单独的分区可能有帮助，但最好是另外一块硬盘的分区
坏扇区和碎片化硬盘
检修下硬盘是否有坏扇区和碎片。这会导致总吞吐量急剧下降。
监视器和OSD并存
监视器是普通的轻量级进程，但它们会频繁调用fsync() ，这会妨碍其它工作量，特别是监视器和 OSD 共享驱动器时。另外，如果你在OSD主机上同时运行监视器，遭遇的性能问题可能和这些相关：
运行较老的内核（低于3.0）
v0.48 版运行在老的 glibc 之上
运行的内核不支持 syncfs(2) 系统调用
在这些情况下，同一主机上的多个OSD会相互拖垮对方。它们经常导致爆炸式写入。
进程共存
共存于同一套硬件、并向Ceph写入数据的进程（像基于云的解决方案、虚拟机和其他应用程序）会导致OSD延时大增。一般来说，我们建议用一主机跑 Ceph 、其它主机跑其它进程，实践证明把Ceph和其他应用程序分开可提高性能、并简化故障排除和维护。
日志记录级别
如果你为追踪某问题提高过日志级别、但结束后忘了调回去，这个OSD将向硬盘写入大量日志。如果你想始终保持高日志级别，可以考虑给默认日志路径挂载个硬盘，即 /var/log/ceph/$cluster-$name.log 。
恢复节流
根据你的配置，Ceph可以降低恢复速度来维持性能，否则它会不顾OSD性能而加快恢复速度。检查下OSD是否正在恢复。
内核版本问题
检查下你在用的内核版本。较老的内核也许没有包含能提高Ceph性能的功能。
内核与SYNC FS问题
试试在一主机上只运行一个OSD，看看能否提升性能。老内核未必支持有 syncfs(2) 系统调用的glibc 。
文件系统问题
推荐基于xfs或ext4部署集群，btrfs有很多诱人的功能，但文件系统内的缺陷可能导致性能问题。
内存不足
建议为每OSD进程至少规划1GB内存。你也许注意到了，通常情况下OSD仅会用一小部分（如 100-200MB）。你也许想用这些空闲内存跑一些其他应用，如虚拟机等等，然而当OSD进入恢复状态时，其内存利用率激增，如果没有可用内存，此OSD的性能将差的多。
