Ceph对象存储的实战兵法介绍

　　前面的文章里，已经介绍了一些Ceph对象存储的实战兵法，接下来的文章里，小编想给大家介绍一下基于Ceph对象存储的实战兵法，一起来看看吧!

　　凡事预则立，不预则废

　　硬盘有价数据无价，处理数据的存储系统一定要保持一点敬畏。有些高风险的操作，一定要小心，不要养成在测试环境下轻易重启删除数据的习惯，上线后也许一个习惯性的动作会让你终身难忘。此外上线前一定要做好各种测试，否则等到网上出了问题再去临时抱佛脚可能已经回天乏术了。测试以下几点是必须的：

　　故障演练和恢复:使用Cosbench进行读写操作，模拟各种拔盘、断网、机柜断电等。，从而测试你的crushmap故障区域设计能力和运维人员的基本水平，无法克服这个障碍。系统上线后，运维人员只能自求多福。

　　性能压力测试必须准备独立的客户端机器，尽量不要将客户端和服务端混合在一起。同时，压力测试产生的所有网络流量网络隔离，以免影响在线环境。

　　NTP服务的重要性确实值得我单独拿出来，一定要做好所有节点的时钟检查再上线，那些增加mon_clock_drift_allowed延迟的方法纯属掩耳盗铃，最后要提醒大家，所有的硬件更新维修(如停机换主板和内存，CPU，RAID卡)，一定要先检查时钟是否正确，再恢复业务，否则足够你喝一壶了。

　　功能覆盖测试取决于你的QA基础。说实话，无论是官方用例还是Cosbench，都很难达到你的预期。让我们自己来这个测试用例。各种语言有条件的SDK都准备好了，可能有一天会踩坑。上线时一定要制定一个API兼容列表，避免后期临时抱佛脚验证界面的可用性。 

　　运筹帷幄，决胜千里之外

　　熬到系统上线后，如何让运维工作省心省力又是一门很大的学问。聪明的运维，七分靠工具，三分靠经验。面对各种运维工具，傻傻的写脚本造轮子显然是不可取的。况且规模大了，单纯用脚本管不了，后续人员交替，脚本管理的成本会越来越高。所以我推荐一个适合中小型运维团队的运维框架方案。

　　·部署工具

　　建议使用ansible，为什么不是puppet，为什么不是saltstack，puppet说实话ruby语法对运营维护真的不友好，而且puppet太重，维护时要单独部署客户端，虽然在生产中被大规模采用，但对于运营维护ceph还是有杀鸡用牛刀的感觉。至于saltstack，虽然python语法对运维基本熟悉，但ceph的calamari团队和saltstack因为版本兼容而两败俱伤，最终calamari项目成为烂尾楼，所以对saltstack持保留态度。像ceph一样，ansible被RedHat收购，而ansible也是ceph官方推广的部署工具，SSH免代理与Ceph-deploy基本相似，但ansible更倾向于工程实践，ceph-deploy可以小规模使用，向正规化方向使用ansible是可靠的。

　　·收集和管理日志

　　第一推ELK，ELK的基本功能就不介绍了，开源日志管理第一推方案，如果要吐槽缺点，那就是学GROK正则实在是有点恶心，不过慢慢也就适应了，把MON/OSD/RGW/MDS的日志丢进ELK里面，接下来就是看你好好积累Ceph的运维经验，熟悉Ceph日志，同时不断完善各种异常和报警触发条件，将日常磁盘、RAID卡等常见硬件故障日志也结合起来，基本上通过日志就能快速诊断出OSD磁盘故障，再也不用傻傻OSD还不知道怎么回事，只要通知机房给你换盘就行了。 

　　·异步任务调度

　　为何要有异步任务调度这个东西，因为前端ELK虽然诊断分析了故障原因，但最终故障还是需要有人登陆特定的机器进行处理，引入Celery这个分布式任务调度中间件后，运维人员将相应的故障处理操作封装成ansibleplaybook，例如ELK发现磁盘故障，调用运维人员的playbook将相应的磁盘out掉，然后umount，用megacli等工具点亮磁盘故障灯，最后一封邮件告诉XX机房XX柜的IP是XX机需要更换硬盘，剩下的就是等机房更换完盘再恢复数据。

　　·消息通知

　　微信等通讯工具极大地方便了内部人员的沟通，尤其是当你不上班时，通过操作机器人触发ansibleplaybook脚本来处理故障，这种感觉让你感觉到运维真的很酸!机房学生换完盘子，把操作后的消息发给微信机器人。机器人会建立OSD恢复任务，并向运维人员发送相应的执行请求。运维学生只需要向机器人确认操作，剩下的就是让机器人随时通过消息告诉你恢复进度。泡妞一边处理故障绝对不是奢望。

　　上面就是基于Ceph对象存储的实战兵法的介绍了，希望可以帮到你的学习，后面小编会继续分享相关的知识点，敬请关注!

  　　>>>>>>点击进入云计算专题