本篇文章的内容,主要是笔者在调研分析Ceph过程当中产生的一些思考。由于其中的内容比较自由发散,且大可能是笔者的我的看法,故此另启一文进行讨论。安全
7.1 关于Ceph的性能性能优化
目前为止,本系列的文章中没有涉及到Ceph性能的详细讨论,也没有给出任何的Ceph性能数据。缘由很简单:笔者本人没有机会进行详尽的Ceph性能分析研究,也没有见到比较全面的相关数据。所以,为了不以片面的数据误导读者,便没有提供任何信息。服务器
以笔者我的的经验而言,探讨一个系统领域的开源项目的性能,事实上并不容易。其缘由在于,影响一个实际部署中系统的性能好坏的因素太多、太复杂。硬件配置、软件版本、参数调整、应用负载及场景设置,各个方面的因素变化都会致使性能测试结果的不一样。所以,很难一言蔽之,认为某个项目的性能是好仍是很差。网络
举一个不直接相关的例子。在hypervisor领域,你们极可能会倾向于认为ESXi的性能优于KVM,但事实上,在SPECvirt性能测试结果排行榜上,基于KVM的系统常有高居第一的时候。究其缘由,除了硬件性能的因素以外,KVM有大量的配置参数能够调整,而调得好与很差会极其明显地影响系统性能。架构
又好比经常使用的开源大数据工具软件Hadoop。同一个Hadoop集群用一样的应用程序处理一样的数据集,在配置参数不一样的状况下,其最终运行时间长度可能相差数倍。ide
正是由于参数配置、硬件规格、软件版本、应用场景等因素均可能对性能产生明显影响,所以,对于Ceph这样一个部署方案多变、配置参数很多的系统,如何评测其系统性能,是须要审慎思考的。工具
反过来说,这倒也是开源软件引出的一个生财之道。虽然软件自己是开源的,你们均可以避免费下载免费安装,但能不能用好就要依靠精深的专业技能了。相似的公司国外家常便饭,而国内也已经开始出现。oop
7.2 Ceph的架构与硬件平台之间的适应性性能
Ceph自2006年正式发布以来,其基础架构(RADOS)部分并无发生大的变化。本质上,这仍是由于RADOS的设计确实优秀,有其前瞻性,所以没有必要大动筋骨。但这并不意味着没有必要对其进行适当反思。测试
如前所述,2006年的时候,商用处理器的主流仍为单核,单条内存和单块硬盘的容量也都远小于如今的主流水平。可是,OSD的基本硬件资源要求并无发生变化。这也就意味着,在目前的典型部署方案中,一台物理服务器上极可能有数十个处理器硬件线程、数十块硬盘,因而也就承载着数十个OSD同时运行。然而,RADOS结构的基本假定是,集群是由大量的、相互独立运行的OSD组成的,则目前的典型硬件方案有可能影响这种假定的有效性。例如,若是一台服务器出现故障,必须关机进行维修,则意味着数十个OSD一块儿忽然下线。由此受到影响的PG则可能多达成千上万个。这种突发性的事件对系统的自动化维护机制可能会形成必定的压力。
由此,笔者想到,Sage设计Ceph时面对的硬件平台,事实上应该是处理能力不须要过强、硬件规格比较简单的系统。而这种系统可能与目前的ARM架构或者Intel Atom架构的micro-server更为类似。或许,基于micro-server部署Ceph集群,会是一种值得尝试的方向。
此外,华为和希捷合做推出了IP硬盘产品。虽然还缺少更进一步的了解,但直观上推测,这种全新的、轻量级、智能化的存储设备,可能也是一种很是近似于Sage当年设想中的OSD的硬件平台。
7.3 Ceph与软件定义存储
“软件定义”这四个字可谓是目前最煊赫一时、也最让人糊涂的概念之一。软件定义计算、软件定义网络、软件定义存储、软件定义数据中心,以上几个多是目前最为常见的相关名词了。
到底什么是“软件定义”,如今尚未造成彻底一致的看法。而且,参考技术发展史上的若干先例,之后也未必能造成所谓的一致看法。在这种状况下,以一个具体实例入手,可能更容易得到直观认识,并由此创建起更系统的观点。
笔者认为,对于任何一个系统而言,“软件定义”的概念,更多体如今这里:这个系统的哪些特性,好比功能或者性能,之前是固定的,或者只能进行有限的配置,而如今则能够进行方便灵活地定义和改变。
例如,对于一台物理服务器,一旦其硬件配置,如CPU、内存、硬盘等链接好,则这台服务器的规格和性能就肯定了,可以经过BIOS配置等方式调整的性能和功能范围是颇有限的。可是,对于一台虚拟机而言,即使在虚拟机已经建立并安装了操做系统以后,其CPU核数及处理能力、逻辑物理内存大小及真实物理内存大小、硬盘数量容量及读写性能、网卡型号数量及网络带宽等等特性都是能够方便灵活地经过软件方式进行控制和改变的(其中部分配置操做须要对虚拟机进行重启才能生效),且这种配置能够由应用层软件进行控制。两相对比,则虚拟机的这种可定义性就是软件定义计算的一个直观实例。
下面再具体到存储领域加以讨论。通常而言,一个存储系统的主要特性大体包括:存储类型(文件系统?块存储?对象存储?),存储容量,存储性能(访问带宽、访问延迟等等),存储策略(备份策略、访问安全性策略、对数据的高级处理功能等等)。参考上面所举出的软件定义计算的例子,能够想见,对于一个软件定义存储系统而言,这些特性(至少是其中的大多数)都应该是能够经过软件方式加以定义的。
具体到Ceph而言,其最为符合软件定义存储的特性无疑是,Ceph的存储类型是能够经过软件方式定义的。一样的一个RADOS集群,能够经过安装不一样的上层软件和对应的客户端程序,实现块存储、对象存储和文件系统存储功能,这一特性对于传统的存储系统不可思议。除此以外,Ceph的存储策略,如备份策略、后台数据处理功能等,也均可以方便地经过软件方式加以定义或扩展。所以,从这个角度出发,Ceph也能够被认为是软件定义存储的真实案例之一。
7.4 Ceph与数据中心计算
传统意义上,计算系统的设计是以计算为中心的。数据从存储、网络或其余设备流入处理器,通过处理后再流向存储、网络或其余设备。然而,随着待处理的数据量以爆炸式的速度增大,也随着计算能力提升的速度超过存储和传输能力,这一处理方式可能变得再也不经济,由于针对大量的数据进行频繁硬盘存取和网络传输的代价都是很是可观的。
数据中心计算这一律念,也就是在这种背景下被提出的。其核心思想,也就是让计算在数据所在的地方发生。数据在哪里,就把计算任务发送到哪里去执行,而不要再为了使用“强大”的计算能力把数据搬来搬去,传来传去。事实上,Hadoop的出现,就是这种数据中心计算思想的现实反映。
数据中心计算的另外一实例,是目前OpenStack社区中出现的一种叫作ZeroVM的轻量级虚拟化技术[1]。ZeroVM的思想就是让计算发生在数据所在的地方。基于其官方提供的信息,目前已经实现了ZeroVM和Swift的整合,可让处理任务直接运行在Swift的服务器端。
事实上,Ceph也提供了一样的能力。Ceph的整个设计,都是基于Sage的一个基本思想:充分发挥存储器件自身的计算能力。这种思想不只使得OSD能够相互配合完成数据访问操做和集群维护功能,更容许OSD将富余的计算能力提供出来,用于运行数据处理任务。
目前,RADOS提供的机制容许在OSD上直接运行可动态加载的数据处理程序插件,以便在服务器端进行数据处理工做,例如,对图片存储系统中的图片进行自动加水印、尺寸和格式自动转换等后台操做。事实上,基于这种能力,也彻底能够实现相似于Hadoop的大数据处理系统。
对于大数据而言,存储和处理是其两个关键的技术领域。因为Ceph自身就是优秀的存储系统,又具有直接承载计算任务的能力,所以,面向大数据的数据中心计算极可能是Ceph的潜在应用方向之一。
7.5 Ceph在实际应用中可能存在的问题
到目前位置,本系列文章基本上都是在介绍Ceph的各类优点与特长。可是,任何系统都不多是十全十美的,本着鸡蛋里挑骨头、吹毛求疵的精神,仍是要在这里吐槽几句。
从非技术角度出发,Ceph的最大问题是火起来的时间不够长,所以能够参考的文档还不是不少,中文的尤为如此。但这个没有办法,只能众人拾柴火焰高,一点一滴做贡献。
此外,对Ceph诟病最多的可能仍是不够成熟云云。但一个开源项目老是用得人多了才会成熟的,而Ceph目前正在这个过程当中,因此须要的仍是时间和参与。
另外,以笔者的感受,Ceph的高度自动化可能也是个双刃剑。好处当然是不少的,但弊端就是系统的运行状态不彻底在管理员控制之下,系统中会有若干自动触发而不是管理员触发的操做。这个特色可能会给系统状态的监测和控制带来一些复杂度,须要管理员去适应。
7.6 基于Ceph的产业需求和可能的商业机会
特此声明:这一节的内容纯属crazy idea,不构成投资建议:-)
首先,Ceph的安装部署和性能优化必然成为突出的需求。所以,将Ceph和商用服务器整合成易于部署、性能出色的各种存储解决方案,应该是能够考虑的方向之一。
同时,因为Ceph自身对于OSD硬件平台的特殊假设,以及由此致使的优化空间,则在成本合理的前提下,开发更加适用于Ceph OSD的定制硬件平台(相似于micro-server或者IP硬盘等),并突出存储的高密度、低功耗、高可维护性等特色,也可能成为一种选择。
此外,针对Ceph集群的专用集群监控、性能分析等工具软件也可能会有必定的需求。
最后,基于Ceph的后台数据处理软件工具包也值得考虑。
说明:转载请注明出处。谢谢。