正文
Mon、OSD需要储存数据到本地文件系统和LevelDB(RocksDB),而且都对存储设备有一定的性能要求（特别是OSD），Ceph为了维护数据一致性内部引入了epoch机制，这意味着你每一次服务重启都会发生版本变更，这些基础数据和对应的服务都是强绑定，要想实现容器服务飘移到任意物理节点，你首先要解决容器volume数据共享，这样你又得引入一套共享文件系统，一个坑没填上又给自己挖了一个。既然做不到无状态服务，那么MON、OSD这些角色容器化之前就要斟酌清楚要不要把原本简单的问题复杂化了。最后Ceph里面唯一可以实现无状态服务的角色就是RGW，而且RGW结合容器化实现的负载均衡是一个非常适合场景，如果要实现无状态的容器化，RGW是唯一选择。
四、网络构架
每个Ceph服务进程都需要绑定到静态的IP（频繁变更IP会极大增加维护统一配置的管理成本），而且最好是不要将单个ceph集群的服务节点跨网段部署（跨网段也会埋下一些坑），所以你的容器网络是否支持Ceph的这些静态配置的网络需求，也需要提前考虑周详。如果你的容器网络是是三层套二层这种，一层一层封装再一层一层解封，带来的开销绝对不可低估，最最最要命的是，任何分布式系统都对时钟有着强依赖，节点之间的网络延迟过高必然导致时钟偏差，最终影响集群稳定性和数据一致性。
五、性能损耗
