传统开源的ceph存储技术路线是否能满足性能需求及稳定性需求？

目前而言，大并发、稳定性要求较高的业务系统不建议使用开源CEPH，成熟的商用CEPH、充足的技术支持和服务、完善的CEPH部署架构和方案、充分的应急预案的情况下，可以少量使用试试水。

Ceph 这个技术发展至今，确实是优点和缺点都同样明显；
Ceph出现初衷是想要一种可扩展，满足业务增长导致的海量数据存储需求；比商用存储便宜，大幅降低成本；稳定，好运维的存储解决方案，但但现实比较骨感 ……
金融行业区别于其他行业对于方案的稳定可靠性有着非常高的要求，从几个方面看看 Ceph 的性能和稳定性是否满足农信互联网金融平台的要求 :
1. 扩展性
Ceph 声称是基于 CRUSH 算法可以无限扩展，无中心节点。事实上可以无限制扩展，但是扩展起来是很痛苦的。
Ceph 的所有对象，是先被 pre-hash 到了一个固定数量的桶（ PG ）当中，然后根据集群的整体物理架构 crushmap ，选择落在具体的机器磁盘上。而在扩容时需要 PG 进行调整，会导致这个 PG 里的所有对象停止对外服务，而一扩容就不能提供服务这对于金融行业来说时不太现实的。总的来说， Ceph 确实提供了无限的扩展能力，但扩容过程并不平滑，也不完全可控。农信互联网金融平台的规模是否需要为了这个无线的扩展性去冒更多的风险，个人认为是要打个问号的。
2. 稳定性
Ceph 的运维好坏是否稳定，往往取决于运维人员能力。对开源软件是否熟悉，是否有经验，会有非常大不同。同时也受开源文档质量的影响，有些国内厂家产品方案采用 ceph 或者说采用 CRUSH 算法务无中心的架构 , 服务可靠性也就只能做到个 3 个 9 、 4 个 9 ，远低于企业级阵列 6 个 9 以上的可靠性。
3. 成本考量

一般会有个先入为主概念，会觉得 Ceph 比商用存储便宜 .
虽然在硬件单价上采用服务器搭更为便宜，但需要考虑综的是合成本，包括： 1. 硬件成本； 2. 自养运维人员成本； 3. 服务质量由一般向好慢慢收敛。
这里分享一个概念集群可靠利用率：即整个集群在容量达到某个水平时不可对外服务，或者说不能保持高可用的服务；
像一线品牌的企业级如 DELLEMC PowerScale 等分布式存储容量达到甚至 98-99% ，仍能对外提供服务。
Ceph 由于去中心化带来的 tradeoff ，在集群整体使用率达到 70% 后，就有可能进入不稳定的状态。 一些朋友在使用 Ceph 经验是 集群到 50% 使用率时，就要开始准备扩容了。 这其实是挺不省钱的，因为必须空置一大批机器的存储资源。比如你要部署 50PB 存储，打个比方需要 300 台主机，这时候为了防止有什么意外你还得采购额外 200-300 台主机，还得插电，还不能用。长此以往因此 Ceph 也不一定便宜。

话说回来，技术没有绝对好坏，但是有场景是不是合适。

对你的业务做严格的测试， ceph 目前在openstack里面经常用到， 但也会有一定的io延迟，
负载不高情况下 没有性能问题，  负载过高的系统不建议使用