苏州建网站的公司哪家公司好,电子商务营销策略分析,怎么知道别人网站是谁做的优化,怎样换网站logo摘要#xff1a;开源技术的学习和采用确实存在着一定门槛#xff0c;然而学习各种开源项目已经成为许多开发者不可回避的工作内容。那么#xff0c;对于类似OpenStack的大型开源项目#xff0c;开发者该如何着手#xff0c;这里我们看章宇的分享。 【编者按】在 上一届O…摘要开源技术的学习和采用确实存在着一定门槛然而学习各种开源项目已经成为许多开发者不可回避的工作内容。那么对于类似OpenStack的大型开源项目开发者该如何着手这里我们看章宇的分享。 【编者按】在 上一届OpenStack Summit报道中我们有提过OpenStack已得到IBM、HP、RedHat等公司的鼎力支持而截至2013年底 在短短不到4年的时间其社区已遍及全球132个国家13504人参与开发者人数更接近6000人298家的支持场上和机构拥有8个白金会员、19个黄金会员、54个赞助公司、217个支持机构北京更成为OpenStack开发者最多的城市。 毫无疑问在得到了广泛的支持后OpenStack在飞快的成熟。然而作为1个内容丰富、涉及众多技术的开源IaaS平台就像【CSDN在线培训】第三期中张小斌的分享 开源并不意味着免费丰富的插件并不一定最优。 OpenStack看似给我们提供了非常多的选项但是如此多的选项往往让企业眼花缭乱。 人人DIY固然可以集思广益但却无法避免踩入陷阱。不深入了解总会有意想不到的惊喜如网络不通系统崩溃性能低下需求如何满足等。 开源技术的学习和采用确实存在着一定门槛然而坐拥宝山绝无空手而归的道理这里我们为大家分享 张宇的技术Blog 从开源项目学习到Ceph浅析。 博主资料章宇于2002年及2007年分别于清华大学电子工程系获得学士及博士学位其后一直从事计算机系统领域的研究与开发工作目前供职于华为技术有限公司云操作系统部门从事OpenStack相关工作。出于工作原因和个人兴趣作者陆续关注了一些开源项目主要包括KVM/QEMUlibvirtvirt-mamagerOpenStackOpen vSwitchCephZabbix等。 开源项目学习方法 学习各种开源项目已经成为很多朋友不可回避的工作内容了。笔者本人也是如此。在接触并学习了若干个开源项目之后笔者试图对自己工作过程中的若干体会加以总结以期对一些希望借鉴的朋友有所裨益。 需要说明的是笔者本人接触的开源项目大多属于计算机系统领域例如Linux kernelKVMQEMUOpenStack等。因此此处介绍的经验必定也有些局限。请读者们自行分辨区别对待。 1. 学习分层和目标管理 对于一个开源项目可以将与之相关的各种知识和技能的学习大致划分为如下五个层次 第一层次了解项目的基本概念、基本用途、逻辑结构、基本原理、产生背景、应用场景等基本知识。 这个层次的基本定位其实就是“科普”。如果对于一个项目只需要有些基本了解且短期内并不需要上手进行实际技术工作则学习到这个层次也就可以先应付一下了。 第二层次掌握项目的基本安装流程和使用方法。 这个层次的基本定位是“入门”以便对这个项目获得直观认识对其安装和使用获得亲身体验。如果只是需要以as-is方式使用这个项目则初步学习到这个层次即可。 第三层次了解代码的组织找到各个主要逻辑/功能模块与代码文件之间的对应关系通过代码分析走通几个关键的、有代表性的执行流程。 这个层次的基本定位是“深入”开始理解这个项目的实际实现能够真正将项目的功能、工作原理和代码实现对应起来获得对这个项目工作过程的直观认识。这个层次是学习开源项目代码的真正开始。如果希望基于这一项目进行应用开发或者针对与这一项目密切相关的其他项目进行工作时则对项目本身的代码进行这一层次的理解会很有帮助。 第四层次了解该项目所有代码模块、程序文件的作用走通所有主要执行流程。 这个层次的基本定位是“掌握”能够比较全面、系统地理解这个项目的设计和实现并且熟悉项目各个部分的代码。如果希望对项目进行深度定制修改或者对社区有所贡献则应当以达到这个层次作为目标。 第五层次钻研、领悟该项目的各种设计思想与代码实现细节。 这个层次的基本定位是“精通”精益求精学无止境。这是大神们追求的境界。如果希望成为项目社区的重要贡献者乃至核心贡献者则应当以这个层次作为努力的目标。 综上对于一个开源项目的学习过程可以大致分为五个层次。至于到底要学习到什么阶段投入多少相关精力则完全取决于学习的目的。 2. 知识基础 学习一个开源项目需要的知识基础主要包括 1该项目涉及的技术领域的背景知识 举例而言分析Linux Kenrel则应该了解操作系统原理学习OpenStack则应该知道什么是云计算。如果没有这些背景知识作为基础上来就死磕源代码只能是事倍功半。 2 该项目开发使用的语言及其各种开发调试工具 这个就无需多言了。 3 英语 很遗憾目前为止真正流行的开源项目大部分不是起源于国内。因此除了学习个别极其流行、文档完备的项目之外大家还是需要自行搜集阅读英文资料参考。学好英语很重要。 当然到底需要准备多少知识基础完全取决于学习的目的和层次。如果只是想科普一下也就不必太过麻烦了。 3. 学习思路 学习一个项目的过程其实就是由表及里了解分析它的过程。上述提及的五个学习层次便组成了这样一个逐渐深入的过程。在此基础之上学习、分析代码的过程也可以尝试做到由表及里、逐渐深入。 在刚开始接触一个项目的时候我们看到的其实就是一个黑盒子。根据文档我们一定会发现盒子上具有若干对外接口。通常而言这些接口可以被分为三类 配置接口用于对盒子的工作模式、基本参数、扩展插件等等重要特性进行配置。这些配置往往是在盒子启动前一次性配好。在盒子的工作过程中这些配置或者不变或者只在少数的情况下发生改变。 控制接口用于在盒子的工作过程中对于一些重要的行为进行操纵。这是盒子的管理员对盒子进行控制命令注入和状态信息读取的通路。 数据接口用于盒子在工作过程中读取外部数据并在内部处理完成后向外输出数据。这是盒子的用户真正关心的数据通路。 因此在分析一个开源项目的代码时可以围绕重要的配置、控制、数据接口展开分析工作特别应该注意理解一个关键的接口背后隐藏的操作流程。例如针对数据接口至少应当走通一条完整的数据输入输出流程也即在代码中找到数据从输入接口进入盒子后经过各种处理、转发步骤最终从输出接口被传输出去的整个执行过程。一旦走通了这样一条流程则可以将与数据处理相关的各个主要模块、主要步骤贯穿起来并将逻辑模块图上和文档中的抽象概念对应到代码实现之中可以有效推进对于项目的深入理解。 在实践这一思路的过程中笔者建议可以优先从控制接口和数据接口中各自选择一二重要者进行背后的执行流程详细分析力争找到其中每一步的函数调用及数据传递关系对于一些系统、应用库提供的底层函数可以先行跳过以节省时间。这一工作完成之后则第1节中第三层次的学习目标即可初步达成。 配置接口在不同的项目中的重要程度不同。对于一些架构极为灵活、配置空间甚大的项目如OpenStack的Ceilometer则可以适当多花些时间加以研究否则简单了解即可。 对于这个学习思路下文中还将结合实例进行进一步的说明。 4. 若干小建议 以下是笔者的一些零散建议供大家参考。 1做好记录 在刚刚入手开始学习某个项目的源代码时其实很有点破译密码的感觉。大量的数据结构和函数方法散落在代码的各个角落里等待着学习者将它们贯穿到一个个重要的执行流程中。因此在分析学习的过程中无论有什么零散收获都值得认真记录下来。珍珠自然会串成项链的。 2不要过分纠缠于细节 立志搞懂一个项目的每行源代码是值得尊敬的但至少在刚刚入手的时候是没有必要的。如果过于纠缠于代码的实现细节则可能很快就被搞得头晕眼花不胜其烦了看英文资料的时候每遇到一个不认识的词都要立刻查词典么。不妨避免细节上的过度纠缠还是先尽快走通关键的执行流程将项目的骨干框架搭起来然后再以此为参照就可以清晰判断什么代码值得深入分析什么地方可以简单略过了。 3想像和联想很重要 如前所述从零开始搞懂一个项目的代码就像破译密码。因此不妨展开合理的想象和联想将各个零散的发现和理解联系起来并加以分析印证。在这个过程中对项目所在领域的背景知识、对项目本身的逻辑框架和工作原理等方面的理解都是想像和联想的参照与指导。此外一些关键的函数名、变量名等等都是联想的hint。本质上编程语言也是语言而程序代码就是说明文。在分析代码时一定要超越语言和代码的细节去理解被说明的事物本身。 4该搜就搜 分析代码的时候很容易出现的情况就是一个执行流程走到半截找不到下一步了。。。在这种情况下当然首先还是推荐采用各种调试工具的单步执行功能加以跟踪。如果暂时不会或者种种原因只能进行静态代码分析那么该搜就搜吧。各种IDE工具的文本搜索都能用哪怕是grep也行。至于到底以什么为搜索关键词就需要琢磨琢磨了。 5外事不决问google内事不决问百度 如题不解释。 5. 一个例子OpenStack Cinder分析 此处将以OpenStack Cinder为例并结合KVM/Qemu和Ceph说明如何参考上述思路对一个开源项目进行分析。 可能有朋友奇怪为什么选这么个东东做例子。这个吧。。。写文章时忽发起想举例子是随手抓来。木有原因。。。 首先想对Cinder进行分析一定要了解若干相关的基础知识。什么是云计算什么是块存储什么是OpenStackCinder在OpenStack里的作用等等等等。如果对这些东西没有概念则后续学习是很难开展下去的。 在此基础上如果有条件则最好能够亲自部署和实际操作一下Cinder包括必要的其他OpenStack组件以便对Cinder获得一个直观的认识和体验为后续分析提供一些参考。此处假定Cinder使用的后端是Ceph而OpenStack上运行的虚拟机是KVM。 然后应该从概念上对我们要分析的系统的逻辑框架有个理解。从总体的范畴上讲应该了解Horizon和Nova各自的逻辑模块结构以及它们和Cinder的协同工作方式、关系。这部分与Cinder的控制接口及执行路径分析密切相关。此外还应该了解Cinder和KVM/QEMU、Ceph之间的相互关系。这对于真正理解Cinder很有帮助。从Cinder自身而言应该了解其内部逻辑模块构成、各自的功能、相互间的控制、数据连接关系等。 在完成上述准备之后则可以开始对Cinder的代码进行分析了。如前所述应该考虑在控制接口和数据接口中各自选择一两个关键的、有代表性的加以分析。至于配置接口假定其实现了某一配置即可暂时不需要过多花费时间。 Cinder的核心功能其实是OpenStack上的volume管理。至少在CinderCeph方案中Cinder自身并不在数据传输关键路径上。因此控制接口的分析就是Cinder源代码分析的重中之重。就入手阶段而言则有两个接口及其对应执行流程可以作为Cinder分析的起点即volume的create和attach操作。如果能够彻底打通这两个操作的执行流程至少要看到Cinder与Ceph通过librbd交互的层面则对于真正理解Cinder的功能与实现大有帮助。 虽然基于KVM的虚拟机在通过QEMU访问Cinder创建的、Ceph提供的volume时并不通过Cinder也即这一部分的源代码其实已经超出了Cinder源代码学习的范畴但是如果希望真正彻底地理解Cinder则对于这一部分知识还是应该有所涉猎至少应该有概念上的了解。 在达到上述阶段之后则可以根据自身的需求决定后续计划了。 psCeph概况、设计思想、结构、工作原理及流程、与OpenStack关系等请访问下一页 以“  云计算大数据 推动智慧中国 ”为主题的  第六届中国云计算大会 将于5月20-23日在北京国家会议中心隆重举办。产业观察、技术培训、主题论坛、行业研讨内容丰富干货十足。票价优惠马上  报名  摘要开源技术的学习和采用确实存在着一定门槛然而学习各种开源项目已经成为许多开发者不可回避的工作内容。那么对于类似OpenStack的大型开源项目开发者该如何着手这里我们看章宇的分享。 作为OpenStack的人气存储技术之一Ceph与Swift和GlusterFS一样有着各自的优势GlusterFS更适合Hadoop类型的服务Swift适合更多人访问Ceph的未来更被看好并已得到许多知名机构的支持比如CERN和天河2。 在之前我们已经分享过张宇Ceph系列博文的前两部分“ Ceph浅析上概况与设计思想”与“ Ceph浅析中结构、工作原理及流程”这里我们将分享该系列博文的最后一部分 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]文中的观点笔者认为合适的选择或许如下  如果需要一个纯粹的对象存储系统则选择Swift如果需要一个纯粹的块存储系统则只能选择Ceph 如果是一个小规模的、希望控制系统复杂度的OpenStack部署方案则选择Ceph如果是一个规模较大的系统块存储和对象存储分别有较大的业务需求则可以考虑将二者分离分别采用Ceph和Swift。  关于Ceph的若干想法 本节的内容主要是笔者在调研分析Ceph过程中产生的一些思考。因为其中的内容比较自由发散且大多是笔者的个人见解故此另启一文进行讨论。 1. 关于Ceph的性能 目前为止本系列的文章中没有涉及到Ceph性能的详细讨论也没有给出任何的Ceph性能数据。原因很简单笔者本人没有机会进行详尽的Ceph性能分析研究也没有见到比较全面的相关数据。因此为了避免以片面的数据误导读者便没有提供任何信息。 以笔者个人的经验而言探讨一个系统领域的开源项目的性能事实上并不容易。其原因在于影响一个实际部署中系统的性能好坏的因素太多、太复杂。硬件配置、软件版本、参数调整、应用负载及场景设置各个方面的因素变化都会导致性能测试结果的不同。因此很难一言蔽之认为某个项目的性能是好还是不好。 举一个不直接相关的例子。在hypervisor领域大家很可能会倾向于认为ESXi的性能优于KVM但事实上在SPECvirt性能测试结果排行榜上基于KVM的系统常有高居第一的时候。究其原因除了硬件性能的因素之外KVM有大量的配置参数可以调整而调得好与不好会极其明显地影响系统性能。 又比如常用的开源大数据工具软件Hadoop。同一个Hadoop集群用同样的应用程序处理同样的数据集在配置参数不同的情况下其最终运行时间长度可能相差数倍。 正是因为参数配置、硬件规格、软件版本、应用场景等因素都可能对性能产生明显影响因此对于Ceph这样一个部署方案多变、配置参数不少的系统如何评测其系统性能是需要审慎思考的 反过来讲这倒也是开源软件引出的一个生财之道。虽然软件本身是开源的大家都可以免费下载免费安装但能不能用好就要依靠精深的专业技能了。类似的公司国外屡见不鲜而国内也已经开始出现。 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的硬件平台。 3. Ceph与软件定义存储 “软件定义”这四个字可谓是目前最炙手可热、也最让人糊涂的概念之一。软件定义计算、软件定义网络、软件定义存储、软件定义数据中心以上几个可能是目前最为常见的相关名词了。 到底什么是“软件定义”现在还没有形成完全一致的见解。并且参考技术发展史上的若干先例以后也未必能形成所谓的一致见解。在这种情况下以一个具体实例入手可能更容易获得直观认识并由此建立起更系统的观点。 笔者认为对于任何一个系统而言“软件定义”的概念更多体现在这里这个系统的哪些特性比如功能或者性能以前是固定的或者只能进行有限的配置而现在则可以进行方便灵活地定义和改变。 例如对于一台物理服务器一旦其硬件配置如CPU、内存、硬盘等连接好则这台服务器的规格和性能就确定了能够通过BIOS配置等方式调整的性能和功能范围是很有限的。但是对于一台虚拟机而言即便在虚拟机已经创建并安装了操作系统之后其CPU核数及处理能力、逻辑物理内存大小及真实物理内存大小、硬盘数量容量及读写性能、网卡型号数量及网络带宽等等特性都是可以方便灵活地通过软件方式进行控制和改变的其中部分配置操作需要对虚拟机进行重启才能生效且这种配置可以由应用层软件进行控制。两相对比则虚拟机的这种可定义性就是软件定义计算的一个直观实例。 下面再具体到存储领域加以讨论。一般而言一个存储系统的主要特性大致包括存储类型文件系统块存储对象存储存储容量存储性能访问带宽、访问延迟等等存储策略备份策略、访问安全性策略、对数据的高级处理功能等等。参考上面所举出的软件定义计算的例子可以想见对于一个软件定义存储系统而言这些特性至少是其中的大多数都应该是可以通过软件方式加以定义的。 具体到Ceph而言其最为符合软件定义存储的特性无疑是Ceph的存储类型是可以通过软件方式定义的。同样的一个RADOS集群可以通过安装不同的上层软件和对应的客户端程序实现块存储、对象存储和文件系统存储功能这一特性对于传统的存储系统难以想象。除此之外Ceph的存储策略如备份策略、后台数据处理功能等也都可以方便地通过软件方式加以定义或扩展。因此从这个角度出发Ceph也可以被认为是软件定义存储的真实案例之一。 4. Ceph与数据中心计算 传统意义上计算系统的设计是以计算为中心的。数据从存储、网络或其他设备流入处理器经过处理后再流向存储、网络或其他设备。然而随着待处理的数据量以爆炸式的速度增大也随着计算能力提高的速度超过存储和传输能力这一处理方式可能变得不再经济因为针对大量的数据进行频繁硬盘存取和网络传输的代价都是非常可观的。 数据中心计算这一概念也就是在这种背景下被提出的。其核心思想也就是让计算在数据所在的地方发生。数据在哪里就把计算任务发送到哪里去执行而不要再为了使用“强大”的计算能力把数据搬来搬去传来传去。事实上Hadoop的出现就是这种数据中心计算思想的现实反映。 数据中心计算的另一实例是目前OpenStack社区中出现的一种叫做ZeroVM的轻量级虚拟化技术。ZeroVM的思想就是让计算发生在数据所在的地方。基于其官方提供的信息目前已经实现了ZeroVM和Swift的整合可以让处理任务直接运行在Swift的服务器端。 事实上Ceph也提供了同样的能力。Ceph的整个设计都是基于Sage的一个基本思想充分发挥存储器件自身的计算能力。这种思想不仅使得OSD可以相互配合完成数据访问操作和集群维护功能更允许OSD将富余的计算能力提供出来用于运行数据处理任务。 目前RADOS提供的机制允许在OSD上直接运行可动态加载的数据处理程序插件以便在服务器端进行数据处理工作例如对图片存储系统中的图片进行自动加水印、尺寸和格式自动转换等后台操作。事实上基于这种能力也完全可以实现类似于Hadoop的大数据处理系统。 对于大数据而言存储和处理是其两个关键的技术领域。由于Ceph自身就是优秀的存储系统又具备直接承载计算任务的能力因此面向大数据的数据中心计算很可能是Ceph的潜在应用方向之一。 5. Ceph在实际应用中可能存在的问题 到目前位置本系列文章基本上都是在介绍Ceph的各种优势与特长。但是任何系统都不可能是十全十美的本着鸡蛋里挑骨头、吹毛求疵的精神还是要在这里吐槽几句。 从非技术角度出发Ceph的最大问题是火起来的时间不够长因此可以参考的文档还不是很多中文的尤其如此。但这个没有办法只能众人拾柴火焰高一点一滴作贡献。 此外对Ceph诟病最多的可能还是不够成熟云云。但一个开源项目总是用得人多了才会成熟的而Ceph目前正在这个过程中所以需要的还是时间和参与。 另外以笔者的感觉Ceph的高度自动化可能也是个双刃剑。好处固然是很多的但弊端就是系统的运行状态不完全在管理员控制之下系统中会有若干自动触发而不是管理员触发的操作。这个特点可能会给系统状态的监测和控制带来一些复杂度需要管理员去适应。 6. 基于Ceph的产业需求和可能的商业机会 特此声明这一节的内容纯属crazy idea不构成投资建议:-) 首先Ceph的安装部署和性能优化必然成为突出的需求。因此将Ceph和商用服务器整合成易于部署、性能出色的各类存储解决方案应该是可以考虑的方向之一。 同时由于Ceph自身对于OSD硬件平台的特殊假设以及由此导致的优化空间则在成本合理的前提下开发更加适用于Ceph OSD的定制硬件平台类似于micro-server或者IP硬盘等并突出存储的高密度、低功耗、高可维护性等特点也可能成为一种选择。 此外针对Ceph集群的专用集群监控、性能分析等工具软件也可能会有一定的需求。 最后基于Ceph的后台数据处理软件工具包也值得考虑。 总结 之所以花这么多时间在这些文章上归根结底还是因为Ceph是个有意思的东西多看一看多想一想总能有些新收获很有趣。即便Ceph最终不能大红大紫凭着其精彩的设计思想和巧妙的技术实现应该还是会在存储技术领域留下一笔的。如果Ceph能够借着OpenStack的东风逐渐走向成熟并受到更为广泛的接受和应用则更是研究、工程、应用相互贯通的一个经典案例值得认真研究。因此无论从哪个角度出发关注Ceph都是值得的。 原文连接 “Ceph浅析”系列之六——Ceph与OpenStack “Ceph浅析”系列之七——关于Ceph的若干想法 开源项目学习方法ABC责编/仲浩 以“  云计算大数据 推动智慧中国 ”为主题的  第六届中国云计算大会 将于5月20-23日在北京国家会议中心隆重举办。产业观察、技术培训、主题论坛、行业研讨内容丰富干货十足。票价优惠马上  报名