Ceph上容器之前的思考有哪些

小编给大家分享一下Ceph上容器之前的思考有哪些，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！

班戈ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景，ssl证书未来市场广阔！成为创新互联建站的ssl证书销售渠道，可以享受市场价格4-6折优惠！如果有意向欢迎电话联系或者加微信：028-86922220（备注：SSL证书合作）期待与您的合作！

服务的硬件资源需求

首先必须了解Ceph里面的MON、OSD、MDS、MGR、RGW各种服务的软硬件需求，知道你规划的Ceph规模是多大，当前分配给对应容器的资源是否合适，不然到了后期你需要做各种硬件资源调整而不得不重启容器的时候，你的服务可用性会可能会大打折扣。总之就是一句话，硬件资源一步到位，不要瞎折腾。别让OOM成为常态！

软件平滑升级

不要以为上了容器你就可以轻松应对软件版本升级了，Ceph理论上是可以实现小版本的软件混合部署，但是一旦你发现某个版本有坑，那你不得不全部调整到同一个版本的时候会发现一堆问题，先升级Mon还是OSD？大批量服务起不来怎么办？出现slow request怎么办？如果你天真的以为上了容器以后，通过几个简单的容器命令实现ceph版本的平滑升级，甚至是跨大版本升级，那么你自求多福吧，跨大版本升级很少有不出问题的，最关键是升级操作基本上都是起手无回，敢带着生产数据去升级的都是“真正的猛士”。而且升级过程中出现的各种奇葩问题，可能资深运维也不一定能够hold住，最后还是得求助开发去协助处理，但是你知道一个懂Ceph源码开发的工程师招聘起来有多难吗？

无状态服务？

Mon、OSD需要储存数据到本地文件系统和LevelDB(RocksDB),而且都对存储设备有一定的性能要求（特别是OSD），Ceph为了维护数据一致性内部引入了epoch机制，这意味着你每一次服务重启都会发生版本变更，这些基础数据和对应的服务都是强绑定，要想实现容器服务飘移到任意物理节点，你首先要解决容器volume数据共享，这样你又得引入一套共享文件系统，一个坑没填上又给自己挖了一个。既然做不到无状态服务，那么MON、OSD这些角色容器化之前就要斟酌清楚要不要把原本简单的问题复杂化了。最后Ceph里面唯一可以实现无状态服务的角色就是RGW，而且RGW结合容器化实现的负载均衡是一个非常适合场景，如果要实现无状态的容器化，RGW是唯一选择。

网络构架

每个Ceph服务进程都需要绑定到静态的IP（频繁变更IP会极大增加维护统一配置的管理成本），而且最好是不要将单个ceph集群的服务节点跨网段部署（跨网段也会埋下一些坑），所以你的容器网络是否支持Ceph的这些静态配置的网络需求，也需要提前考虑周详。如果你的容器网络是是三层套二层这种，一层一层封装再一层一层解封，带来的开销绝对不可低估，最最最要命的是，任何分布式系统都对时钟有着强依赖，节点之间的网络延迟过高必然导致时钟偏差，最终影响集群稳定性和数据一致性。

性能损耗

OSD能够用裸存储设备的就不要用文件系统，鉴于现在Ceph的性能差强人意，尽量缩短IO路径，绝对是明智的选择。

运维复杂度

日志管理

Ceph 各种奇葩故障都需要借助日志进行定位，能够第一时间看到故障现场是最好的，但是容器化以后查看日志就没那么轻松了，如果真的要上容器化，那还是上一套类似ELK做集中日志管理吧。（coredump也是一个坑）

服务监控

可能你原本已经写好zabbix一类的Ceph的监控插件，但是现在换到容器，原来的方案还适用吗？包括现有的MGR dashboard还有很长的路要走。

硬件故障

这个是让我吐槽最大的地方，原本OSD磁盘故障，直接几条命令就可以搞定的事情，现在引入了容器以后，换盘的操作复杂度增加了很多，虽然可以上脚本自动化去实现这些东西，但是对运维人员的技能要求更高，原本换盘的技术栈为Linux+ceph，现在是Linux+ceph+容器，无形之中提高了招人的门槛，当然给的薪水也要高了,但是最后老板们就不高兴了，特别是经济危机下的裁员，你给了老板一个充足的理由去干掉你。

以上是“Ceph上容器之前的思考有哪些”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注创新互联行业资讯频道！

文章名称：Ceph上容器之前的思考有哪些
当前地址：http://scjbc.cn/article/poocod.html