不可预知的问题，要解决岂不是先知。（1）全方位的监控是解决问题的问题的其中之一方法，thanos+Prometheus+grafana能同时监控很多kubenetes集群；（2）可靠高速的网络，大部分ceph问题都是由网络引起的，ceph性能不仅靠磁盘性能，更靠高速的网络。（3）kubenetes的自愈功能，kubenetes考虑了一部...

硬件层面a、 硬件规划b、SSD选择c、BIOS设置软件层面a、Linux OSb、Ceph Configurationsc、PG Number调整d、CRUSH Mape、其他因素

1、 OSD请求缓慢的主要原因是：a、 底层硬件的问题，例如磁盘驱动器，主机，机架或网络交换机。b、网络问题。这些问题通常与flapping OSD有关。c、系统负载。2、 使用 dump_historic_ops administration socket命令确定慢速请求的类型3、 使用ceph osd perf确定慢速磁盘...

all-in-kubenetes，我们公司就用Prometheus+grafana把监控全包了，监控需要统一，工具太多，未必是好事。

crushmap改变导致的Ceph rebalance，所以 整体IO的下降（磁盘IO被反复的rebalance占满），甚至是某些数据暂时不可用。所以要在业务量较少的时间段进行扩容

（1）预设Ceph集群中的PG数至关重要，公式如下:      PG 总数 = (OSD 数 * 100) / 最大副本数（2） 集群中单个池的PG数计算公式如下         PG 总数 = (OSD 数 * 100) / 最大副本数 / 池数

频繁的调整osd的权重是不可取的，必须要做好规划，对数据规模进行必要的预估。

降低recovery的I/O优先级，使得Client IO优先

缺省的水位线在85%~95%, 生产中一般将其改到70%~80%， 一旦达到一个区间，就可以考虑扩容了，节点数量要根据你一年内数据量增加的预估来计算

设置集群为维护模式， 避免有数据迁移的发生， 尽快恢复死机的机器， 重新拉起osd起来。