Ceph与OpenStack在前文概况中即已提到，关注Ceph的原因之一，就是OpenStack社区对于Ceph的重视。因此，本文将对Ceph在OpenStack中的价值进行简要介绍，并且对Ceph和Swift进行对比。 1. Ceph在OpenStack中的地位对于一个IaaS系统，涉及到存储的部分主要是块存储服务模块、对象存储服务模块、镜像管理模块和计算服务模块。具体针对OpenStack而言，则分别对应为其中的Cinder、Swift、Glance和Nova四个项目。 在块存储服务部分，Ceph目前是Cinder项目的默认存储后端。前已述及，Red Hat也已经利用自己在KVM/QEMU社区中的影响力，将RBD驱动直接集成在QEMU中。这样，虚拟机访问基于RBD实现的块设备的性能将得到优化。 在对象存储部分，Swift是OpenStack自带的对象存储实现方案。但Ceph也已经成为了Swift最强有力的竞争对手。目前Swift也在考虑采用Ceph作为自己的存储后端。关于Ceph和Swift的故事将在6.2节详细展开。 在镜像管理部分，目前Glance已经支持将Ceph作为自己的本地镜像文件缓存。 在计算服务部分，United Stack目前正在推动将Ceph FS作为Nova计算节点的本地文件系统。 整体而言，Ceph事实上是目前OpenStack生态系统中呼声最高的开源存储解决方案。这一点从笔者在OpenStack 2013 HongKong Summit上的亲身体验可以得到印证。目前，以HP、Dell、Intel等为代表的企业IT领导厂商，和以Mirantis、eNovance、United Stack为代表的若干OpenStack社区新兴厂商，都将Ceph作为重要的乃至于首选的开源存储解决方案。 笔者认为，Ceph之所以在诞生多年不温不火的情况下，迅速在OpenStack社区中受到关注，除了其他一些明显优点之外，应该还是和其支持统一存储的能力有关。这一特性恰恰是OpenStack社区所需要的。 OpenStack项目设计的准则之一就是灵活可扩展。同时，其各个成员项目的背景也不尽相同。这也就导致各个项目在涉及存储系统时所采取的选择各 有差异。但是，这一现状势必导致OpenStack的部署和运维面临一定的挑战。特别是对于一些规模不大的OpenStack部署实例，如果让块存储、对 象存储、镜像缓存、计算节点本地存储等模块分别采用三四种不同的后端解决方案，则一方面其部署十分麻烦，另一方面运维人员的后续工作也很繁琐。在这种情况 下，如果能够采用Ceph作为一种统一存储后端，则确实可以有效缓解这一问题。当然，这只是笔者的一家直言。任何技术选择必然都有其复杂的背后原因，这里 的信息仅供参考。 2. Ceph与Swift：不能不说的故事，不能不作的比较首先对Swift项目的来龙去脉进行简单介绍，以便大家更好地了解这个项目的特性，及其背后隐藏的原因。此处关于Swift的信息主要引自。 Swift最早起源于2008年，本来是Rackspace公司内部开发的用于支撑其公有云对象存储业务的后端系统。当时，Amazon的S3服务 已经颇受欢迎，因此，Rackspace决定开发Swift以提供对应业务作为回应。也正是因为这个原因，Swift的设计目标十分纯粹，就是一个优秀 的、可以和S3相媲美的对象存储系统。其他要求纯属多余，因此完全不在Swift开发者的考虑之列。 Swift的开发大致历时一年，并在Rackspace成功上线运营。此后，OpenStack项目于2010年正式发布。Rackspace贡献 了Swift，而NASA贡献了Nova，二者成为了OpenStack最早的两个项目。其后，若干Swift开发团队的核心成员独立创业，成立了 SwiftStack公司，依然活跃在相关社区。 由此可见，Swift正是一个典型的起源于公司内部的、作为正式产品开发的开源项目。从这一点而言，Swift和“学院范儿”的Ceph可谓截然不 同。也正是因为这个原因，Swift获得了一个得天独厚的优势：不缺启动用户，一开始就有生产环境下的大规模部署应用案例。事实上，相对成熟、web场景 下应用案例多，是Swift社区目前依然反复强调的一个优势。 从技术上讲，Swift的特点主要体现在设计目标明确，就是要做一个纯粹的对象存储系统，因此不会考虑Ceph所强调的统一存储特性。同时，为了便于和其他项目、应用集成，Swift选择了Python语言进行开发。 与之相比，Ceph同时考虑了对象存储、块存储和文件系统存储能力，且目前在OpenStack中应用最多的场景事实上是块存储。同时，Ceph在 选择开发语言时，很可能主要考虑的是性能因素，因而选择了C++语言。而能够被用于块存储场景这一点，也部分印证了其性能确实比较优秀。 由此可见，Ceph和Swift的区别，本质上是由其产生背景和应用目标所导致的。对这二者进行对比，并进行技术上的评判，并不非常公平。 事实上，作为开源分布式存储系统中的两个优秀代表，Ceph和Swift的设计和特性之中，也有着不少的相通之处： 首先，二者都强调良好的可扩展性，因此都采用了无中心点结构。只不过Swift的架构中有元数据服务器，只是通过多节点扩展的方式尽可能解决了其可靠性和性能顾虑。 第二，二者都能提供可配置的高可靠性。在两者的集群中，数据的备份数都可以选择，在常见生产环境中，也都使用三备份的方式。 第三，二者都强调自动化的集群管理。Swift同样引入了自动化的集群维护能力。 由此可见，简单地强调这两者之中的某一个更为优秀，是不合理的，也是没有实际意义的。 当然，在实际使用中，毕竟还是需要进行方案选择。结合[3]文中的观点，笔者认为，合适的选择或许如下：
关于Ceph的若干想法本节的内容，主要是笔者在调研分析Ceph过程中产生的一些思考。因为其中的内容比较自由发散，且大多是笔者的个人见解，故此另启一文进行讨论。 1. 关于Ceph的性能目前为止，本系列的文章中没有涉及到Ceph性能的详细讨论，也没有给出任何的Ceph性能数据。原因很简单：笔者本人没有机会进行详尽的Ceph性能分析研究，也没有见到比较全面的相关数据。因此，为了避免以片面的数据误导读者，便没有提供任何信息。 以笔者个人的经验而言，探讨一个系统领域的开源项目的性能，事实上并不容易。其原因在于，影响一个实际部署中系统的性能好坏的因素太多、太复杂。硬 件配置、软件版本、参数调整、应用负载及场景设置，各个方面的因素变化都会导致性能测试结果的不同。因此，很难一言蔽之，认为某个项目的性能是好还是不 好。 举一个不直接相关的例子。在hypervisor领域，大家很可能会倾向于认为ESXi的性能优于KVM，但事实上，在SPECvirt性能测试结 果排行榜上，基于KVM的系统常有高居第一的时候。究其原因，除了硬件性能的因素之外，KVM有大量的配置参数可以调整，而调得好与不好会极其明显地影响 系统性能。 又比如常用的开源大数据工具软件Hadoop。同一个Hadoop集群用同样的应用程序处理同样的数据集，在配置参数不同的情况下，其最终运行时间长度可能相差数倍。 正是因为参数配置、硬件规格、软件版本、应用场景等因素都可能对性能产生明显影响，因此，对于Ceph这样一个部署方案多变、配置参数不少的系统，如何评测其系统性能，是需要审慎思考的 反过来讲，这倒也是开源软件引出的一个生财之道。虽然软件本身是开源的，大家都可以免费下载免费安装，但能不能用好就要依靠精深的专业技能了。类似的公司国外屡见不鲜，而国内也已经开始出现。 |
