写在前面
最近好忙，整理环境，大批池子排队上线...
最近在环境中遇到一个情况，有一个2PB的存储池在测试完成后进行上线前的处理，主要是清除测试数据、扩容和修改配置，一顿操作后，居然宕机了
环境描述
先别怕，设备不会随便宕机，先看下这个环境：
1、处理器为单路8核16线程Xeon Silver 4110
2、内存64GB，swap为32GB
3、每个节点有36个osd，每个osd单独的一块8T HDD
4、一共5个节点，radosgw和mon、mgr均分布在9台不同的设备上
5、仅使用对象存储，策略为EC 3+2
低配的环境，光是节点上36个8T的osd全部跑起来就够呛。。。
操作实录
首先，要求将测试时候写入的接近四千万个对象删除，然后将另外4台一样的节点加入到集群中，扩容完成后，指定策略为EC 6+2
考虑到删除这么多的对象要很长时间，业务催得紧，急着要上线，省时间的方案是
1、备份s3用户的key，保持业务接入配置不改变
2、删掉全部池子，这样的话新加入的osd避免了数据重分布
3、扩容+++
4、重建池子，重建用户并修改配置
然鹅，操作到第二步就翻车了。
使用下面的命令删除所有的池子，结果半分钟不到全部osd节点连不上，一会就全部宕机了
for x in sudo ceph osd pool ls;do sudo ceph osd pool delete $x $x --yes-i-really-really-mean-it;done
为什么呢
首先这些节点的配置很低，尤其是内存，仅有64GB，要跑38个8T的osd本身已经捉襟见肘，正常运行时内存使用已经过半(通过参数限制了osd使用的内存最大使用量，但是这个限制不能压得太低，否则性能很差)，系统本身的运行也需要有足够的内存和cpu资源
其次是计算资源cpu太少，主频低核数也少，平均一个osd都分不到0.5个core，用EC就更加不够用
最后swap实在不太够，多分点的话系统卡点还好，太少用完就没机会了，只能宕机
当执行上述删除所有存储池的命令后，集群所有的osd收到更新，清除其管辖的全部pg及数据，这个操作非常耗性能，实际观察到这种处理下osd平均需要120%左右的cpu资源及数GB的内存，这就是说单节点上所有osd同时作业直接把节点的全部资源用尽，不宕机才怪
怎么处理
联系机房的同事手动重启机器，然后在系统启动后立马连上，执行systemctl stop ceph-osd.target
停掉全部的osd，再检查系统中有哪些osd，手动systemctl start ceph-osd@x.service
启动osd，像这种机器配置，起8个后负载就明显比较大了，所以要慢慢来～
总结
出于成本考虑，不少环境的节点机器配置会比较低，盘又多，这种场景风险还是比较高的，不出故障还好，一旦有osd挂掉，数据恢复引发的高负载容易危及系统安全，像本篇这种情况，处理集群问题的时候一定要慎重
