一: 概要ceph是一个开源项目,他是软件定义、统一的存储解决方案 ceph是一个可大规模扩展、高性能并且无单点故障的分布式存储系统 从一开始他就运行在通用的商用硬件上,具有高度的可伸缩性,容量可扩展至EB级别,甚至更大 备注: 1KB (Kilobyte 千字节)=1024B, CEPH应为开放、可扩展、分布式的本质在存储领域名声鹊起 如今公有云、私有云乃至混合云是提供大规模基础设施的主流方案 ceph的架构设计之初就包含如下特性:
ceph为企业提供了基础的性能,无限的扩展性,强大的并且灵活的存储产品 ceph官方网站:https:/// 产品学习网站:https://docs./start/intro
二:ceph的历史和发展
是CEPH的研究开发时期;在这期间,他的核心组件逐步形成,并且社区对项目的贡献也已经开始逐渐变大 ceph没有采用双重许可模式,也就不存在只针对企业版的特性
ceph已经越来越成熟,并开始等待孵化 此时,dreamhost(洛杉矶的一个虚拟主机和域名注册公司)参与进来
对ceph进行孵化 在这期间ceph逐渐成形,已有的组件变得更加稳定,可靠;各种新特性也已经实现,未来的路线图也已设计好 至此,ceph真正开始进入企业选择意向和路线图 在这期间,多个有名的开发者开始参与到ceph项目中,他们中包括yehuda sadeh、weinraub、gregory farnum 、josh durgin、samuel just 、wido den hollander和lo ceph这个词是宠物章鱼的一个常见绰号 ceph可以靠左cephalopod的缩写,他属于海洋软体类动物家族 ceph以章鱼作为自己的吉祥物,表达了ceph跟章鱼一样的并行行为 inktank这个词与章鱼有一定关系,渔民有时候也把章鱼称为墨鱼,因为他们可以喷涂墨汁,这就解释了为什么章鱼(ceph)跟墨鱼(inktank)有一定关系 同样,ceph和inktank有很多共同点,你可以认为inktank就是ceph的智库 sage weil是dreamhost的联合创始人之一 2007年年末ceph项目启动时,他最先由dreamhost孵化 2008年5月7日,sage发布了ceph 0.2版本,之后开发进展逐渐加快 版本发布时间间隔缩短并且现在每隔一个月都会有新版本的更新。 2012年7月3日,sage宣布到目前为止最重要的一个版本Argonaut(0.48版本)发布 下面列出了ceph发布的主要版本,包括long term support (LTS)版本。 更多的信息请访问https:///category/releases/
备注: 服务器装系统的三种方式
三:CEPH的优缺点ceph起源于2004年sage 的博士论文,最早致力于开发下一代高性能分布式文件系统的项目,现在也成为了开源社区众人皆知的明星项目 特别是随着云计算的发展,ceph搭上了openstack的春风,受到各大厂商的认可,intel、dreamhost、SanDisk、cisco、yahoo等公司都或多或少的参与其中 redhat更是一掷千金,直接以1.75亿美金将sage创建的inktank公司及其ceph团队收入囊中,将其作为iaas三大组件计算、网络、存储之一 在这一期间的发展过程中,ceph似乎越来越向着云计算的方向靠拢,最先的cephfs文件系统已不再是开发重点,甚至开发已经陷入了停滞状态 而与虚拟化相关的RBD、RGW则成了开发重点,成为发展最快的模块 但是从代码中仍然能够开到各种痕迹,似乎在告诉后来人这段绕了一个大弯的历史 3.1 优势3.1.1 crush算法
crush算法是ceph最初的两大创新之一(另一个是基于动态子树分区的元数据集群),也是整个RADOS(ceph集群)的基石,是ceph最引以为豪的地方 crush在一致性哈希基础上很好的考虑了容灾域的隔离,能够实现各类负载的副本放置规则,例如跨机房、机架感知等。 同时,crush算法支持副本和EC两种数据冗余方式,还提供了四种不同类型的bucket(存储空间)(uniform,list,tree,straw),充分考虑了实际生产过程中硬件的迭代式部署方式,虽然实际生产中大多数情况下的都只用了一种straw 另外根据sage的论文,crush算法具有相当好的可扩展性,在数千OSD的情况下仍然能保证良好的负载平衡 但这更多是理论层面的,目前还没有人给出在数PB规模的生产环境中的测试结果 总的来看,crush算法仍然是目前经过实践检验的最好的数据分布算法之一 3.1.2 统一存储架构
ceph最初设计的RADOS是为其实现一个高性能的文件系统服务,并未有考虑对于块设备、对象存储的支持,也就没有什么RBD、RADOS Gateway,更别提openstack和qemu之类的了 但谁想无心插柳柳成荫,由于RADOS出色的设计和独立简洁的访问接口,再加上sage敏锐的眼光,ceph社区果断推出了用于支持云计算的分布式块存储RBD和分布式对象储存RADOS gateway,并将开发中心全面转向云计算领域 不得不说,raods的设计还是非常的优秀。从架构上看,RBD和 RADOS Gateway实际上都只是rados的客户端而已,但得益于rados的优秀设计,RBD和RADOS Gateway的设计和实现都很简单,不需要考虑横向扩展、冗余、容灾、负载平衡的等复杂的分布式系统问题,同时能够提供足够多的特性和足够优秀的性能,因此迅速得到了社区的认可 另一方面,ceph为openstack提供了良好的支持,成为了目前最火的openstack底层存储系统 3.1.3 丰富的特性
ceph的特性不可谓不多,从分布式系统最基本的横向扩展、动态伸缩、冗余容灾、负载平衡等,到生产环境中非常实用的滚动升级、多存储池、延迟删除等,再到高大上的cephFS集群、快照、纠删码、跨存储池缓存等,不额可谓不强大 但就像大多数开源系统一样,ceph的基本特性,或者说真正在生产环境中用得上的特性还是非常靠谱的,但其他高级特性就只能打一个问号了 特别是在ceph模块,由于ceph社区目前的开发重点主要还是与云计算相关的部分,即RBD和RADOS Gateaway,导致cephFS的开发停滞了很久,相关的特性,例如元数据集群、快照等,目前都不满足生产环境的要求 3.2 缺点3.2.1 代码质量代码质量的问题,实际上是个见仁见智的问题 ceph主要使用C/C++语言编写,同时外围的很多脚本和工具用了Python。之所以要说明ceph的语言构成,是因为代码质量实际上是和语言有密切的关系 不否认用C++也能写出优雅的代码,但相比于更加“现代”的语言,要想写入具备同样可读性、结构良好、条理清晰代码,C++要困难很多 但是,由于存储作为底层系统,对效率的追求是无止境的,因此不太可能舍弃对于内存等底层系统资源的控制,而使用java/python这类的语言;而作为一个开源项目,期望所有的贡献者都是C++的高手,未免有些强人所难,这似乎成了一个死结 另一方面,Ceph广泛使用了STL,在部分核心代码中还使用了BOOST,这两者在底层核心系统代码中的可用性也一直存在争议,这更加结局了代码质量的挑战性 最关键的是,ceph似已经背负了太多的历史包袱,比如最核心的OSD模块,最初的设计包含OSD和PG类,其中PG类负责PG的通用逻辑,OSD负责管理所有的PG(placement group ,一个PG就是一组对象的集合)。然后PG的子类Peplicated PG实现了一副本作为冗余模式的PG。这里就存在了两个半类:OSD、PG及其子类ReplicatedPG,这两个半类实现了OSD模块99%的逻辑,可以想象这两个半类会有多大 在目前的master分支上,相关文件的大小分别是 OSD.h+OSD.cc = 2383行+8604行 = 10987行 PG.h+PG.cc = 2256行+7611行 = 9867行 ReplicatedPG.h+ReplicatedPG.cc = 1487行+12665行 = 14152行 需要特别注意的是,从C++继承的角度上,理解一个类,必须理解他的父类,也就是说,如果你想理解ReplicatedPG,理论上你必须同时理解PG,也就是说,要同时理解20000+行代码! 更加丧心病狂的是,这两个半类之间存在密切而复杂的调用关系,相互之间直接使用整个类,而没有什么实际上的接口隔离。严重加剧了理解代码的难度。 在EC功能以一种奇葩的方式加入到osd中之后,整个场面更加混乱。按照最初的设计,实现EC应该增加PG的一个子类,类似ErasureCodePG。但是由于ReplicatedPG包含了太多通用的代码,实际上已经和PG合二为一了,所以EC只能在ReplicatedPG的基础上改造。于是又出现了PGBackend的概念和相关的实现,这只能说是挑战人脑的极限了。 Ceph社区也曾试着梳理代码,比如添加OSDService类,作为PG与OSD通讯的接口。这样所有的PG全部调用OSDService而非OSD,相当于做了OSD与PG之间的隔离。但是似乎并没有起到足够的效果,现在已经名存实亡了。 Ceph在这样的代码质量下,还能向前走多久,委实是一件令人担忧的事情。 3.2.2 性能Ceph性能总的来说还是不错的,基本上能发挥出物理硬件的性能,但是存在以下几个隐患: 1 数据双倍写入Ceph本地存储接口(FileStore)为了支持事务,引入了日志(Journal)机制。所有的写入操作都需要先写入日志(XFS模式下),然后再写入本地文件系统。简单来说就是一份数据需要写两遍,日志+本地文件系统。这就造成了在大规模连续IO的情况下,实际上磁盘输出的吞吐量只有其物理性能的一半。 2 IO路径过长这个问题在Ceph的客户端和服务器端都存在。以osd为例,一个IO需要经过message、OSD、FileJournal、FileStore多个模块才能完成,每个模块之间都涉及到队列和线程切换,部分模块在对IO进行处理时还要进行内存拷贝,导致整体性能不高。 3 对高性能硬件的支持有待改进Ceph最开始是为HDD设计的,没有充分考虑全SSD,甚至更先进的PCIe SSD和NVRAM的情况NVRAM。导致这些硬件的物理性能在Ceph中无法充分发挥出来,特别是延迟和IOPS,受比较大的影响。 3.2.3 CephFSCephFS现在在整个Ceph系统中处于一个较为尴尬的情况,因为POSIX这种接口似乎在云计算中没有用武之地,导致了社区对这个模块的关注不足,也就没有什么进展。 CephFS作为最初Ceph的设计目标,Sage投入了巨大的精力,几乎实现了所有需要的特性,并且进行了大量工程层面的优化。 正所谓成也萧何败萧何,Ceph想把CephFS模块做到足够强大,甚至是最强大,但强大的同时也意味着不菲的代价。元数据动态子树分区、目录分片、快照、权限控制、IOPS优化、故障恢复、分布式缓存、强弱一致性控制,这些高大上的名词背后都意味着复杂的工程性任务,更不要说将这些叠加在一起。很多时候,叠加不是想加,而是相乘的关系。最终的结果就是整个MDS的工程难度已经超过了可以掌控的程度,无法做出足够成熟、稳定的系统。 目前CephFS宣称其单MDS的模式是稳定的,MDS的集群的模式是不稳定的。而快照功能默认关闭,今后也够呛会有开启的可能了。 3.2.4 业务连续性Ceph中的RADOS采用强一致性设计,即Write-All-Read-One,这种模式的好处在于读取效率较高,而且工程难度较低,比较适合与读多写少的系统。 Write-All-Read-One的特点:必须等待所有的副本全部写入完毕才算是写入成功,这实际上对系统硬件的可靠性要求较高,因为如果在写入过程中存在任意硬件故障,则写入过程都要受影响。通常表现为卡顿,一般在数秒级别,时间长短和判断故障的机制以及故障恢复过程中IO的处理策略相关。 但是当集群非常非常大时,Write-All-Read-One对于硬件可靠性的要求几乎是无法满足的。想象一下一个10PB的系统,按照最大4TB每块盘的计算,就有2500块磁盘。按照我们以往的运维经验,每周存在一块磁盘故障是完全正常的。这种场景下,如果数据分布足够分散,实际上一块磁盘可能涉及到很多数据块,也就是说一块磁盘故障会影响很多IO,而这种情况每周发生一次。这对业务连续性的影响是已经是不可忽略的。 生产环境中的场景比这个更加复杂,因为磁盘或者硬件的故障可能不仅表现为不可写,还有可能是慢或者不稳定。这些情况对于业务连续性的影响也更加严重。 3.2.5 社区Ceph社区现在已经有很多厂商实际上或者号称参入进来,其中不乏Intel、Dreamhost、SanDisk这样的大厂,也不乏UnitedStack这样的Start-Up公司,还有电信、大学、研究所这类非存储领域的公司或单位。 但实际上整个Ceph还是掌握在Inktank或者说RedHat的手中,绝大多数核心代码由他们贡献,也是他们Review和Merge。总的来说还是一个集权组织。 更加重要的是,Ceph相比OpenStack这种成熟完善的开源社区,缺乏足够的基础设施,例如成熟的单元测试、集成测试、测试环境、Reivew流程、贡献指引、代码规范等。导致整个社区仍然是人治、而非法制的过程,代码和系统的发展方向本质是由RedHat公司控制的。 对于以上这些问题,Ceph社区也非常清楚,并且正在或者将要改进。例如为了增加了对于SSD的支持,改进数据双倍写入问题以及更完善的社区建设和基础设施等。这些都增加了人们对Ceph的信心。 总的来说,Ceph瑕不掩瑜,仍然是一个优秀,甚至出色的开源存储系统。如果说分布式存储在云计算时代是风口上的猪,那么Ceph也是一直优秀的猪。未来是什么样子,我们拭目以待。 四:ceph存储架构分布式存储是相对于集中式存储来说的,在介绍分布式存储之前,我们先看看什么是集中式存储。 4.1 集中式存储架构以前,企业级的存储设备都是集中式存储。所谓集中式存储,从概念上可以看出来是具有集中性的,也就是整个存储是集中在一个系统中的。但集中式存储并不是一个单独的设备,是集中在一套系统当中的多个设备。整个存储系统可能需要几个机柜来存放. 在这个存储系统中包含很多组件,除了核心的 机头(控制器)、 磁盘阵列(JBOD) 交换机 等设备外,还有管理设备等辅助设备。如图2是一个集中式存储的基本逻辑示意图。 机头(控制器):在集中式存储中通常包含一个机头,这个是存储系统中最为核心的部件。通常在机头中有包含两个控制器,这两个控制器实现互备的作用,避免硬件故障导致整个存储系统的不可用。在该机头中通常包含前端端口和后端端口,前端端口用户为服务器提供存储服务,而后端端口用于扩充存储系统的容量。通过后端端口机头可以连接更多的存储设备,从而形成一个非常大的存储资源池。 机头中是整个存储系统的核心部件,整个存储系统的高级功能都在其中实现。控制器中的软件实现对磁盘的管理,将磁盘抽象化为存储资源池,然后划分为LUN提供给服务器使用。 这里的LUN其实就是在服务器上看到的磁盘。当然,一些集中式存储本身也是文件服务器,可以为服务器提供共享文件服务。无论如何,从上面我们可以看出集中式存储最大的特点是有一个统一的入口,所有数据都要经过这个入口,这个入口就是存储系统的机头。 分布式存储是一个大的概念,其包含的种类繁多,除了传统意义上的分布式文件系统、分布式块存储和分布式对象存储外,还包括分布式数据库和分布式缓存等。本文局限在分布式文件系统等传统意义上的存储架构,对于数据库等不做介绍。 4.2 中间控制节点架构(HDFS)分布式存储最早是由谷歌提出的,其目的是通过廉价的服务器来提供使用与大规模,高并发场景下的Web访问问题。如图3是谷歌分布式存储(HDFS)的简化的模型。 4.2.1 在该系统的整个架构中将服务器分为两种类型一种名为namenode,这种类型的节点负责管理管理数据(元数据) 一种名为datanode,这种类型的服务器负责实际数据的管理。 4.2.2 工作流程上图分布式存储中,如果客户端需要从某个文件读取数据
在该架构中namenode通常是主备部署,而datanode则是由大量节点构成一个集群。 由于元数据的访问频度和访问量相对数据都要小很多,因此namenode通常不会成为性能瓶颈,而datanode集群可以分散客户端的请求。 因此,通过这种分布式存储架构可以通过横向扩展datanode的数量来增加承载能力,也即实现了动态横向扩展的能力。 4.3 完全无中心架构—一致性哈希(Swift)与Ceph的通过计算方式获得数据位置的方式不同,另外一种方式是通过一致性哈希方式获得数据位置。 一致性哈希的方式就是将设备做成一个哈希环,然后根据数据名称计算出的哈希值映射到哈希环的某个位置,从而实现数据定位。 工作原理上图一致性哈希的基本原理,为了绘制简单,以一个服务器上的一个磁盘为例进行介绍。 为了保证数据分配的均匀性及出现设备故障时数据迁移的均匀性,一致性哈希将磁盘划分为比较多的虚拟分区,每个虚拟分区是哈希环上的一个节点。 整个环是一个从0到32位最大值的一个区间,并且首尾相接。 当计算出数据(或者数据名称)的哈希值后,必然落到哈希环的某个区间 然后以顺时针,必然能够找到一个节点。那么,这个节点就是存储数据的位置。 Swift存储的整个数据定位算法就是基于上述一致性哈希实现在Swift对象存储中,通过账户名/容器名/对象名三个名称组成一个位置的标识,通过该唯一标识可以计算出一个整型数来。 而在存储设备方面,Swift构建一个虚拟分区表,表的大小在创建集群是确定(通常为几十万),这个表其实就是一个数组。 这样,根据上面计算的整数值,以及这个数组,通过一致性哈希算法就可以确定该整数在数组的位置。而数组中的每项内容是数据3个副本(也可以是其它副本数量)的设备信息(包含服务器和磁盘等信息)。也就是经过上述计算,可以确定一个数据存储的具体位置。这样,Swift可以将请求重新定向到该设备进行处理。 上述计算过程是在一个名为Proxy的服务中进行的,该服务可以集群化部署。因此可以分摊请求的负载,不会成为性能瓶颈 4.4 完全无中心架构—计算模式(Ceph)下图是Ceph存储系统的架构,在该架构中与HDFS不同的地方在于该架构中没有中心节点。客户端是通过一个设备映射关系计算出来其写入数据的位置,这样客户端可以直接与存储节点通信,从而避免中心节点的性能瓶颈。 在Ceph存储系统架构中核心组件有Mon服务、OSD服务和MDS服务等。 对于块存储类型只需要Mon服务、OSD服务和客户端的软件即可。 其中Mon服务用于维护存储系统的硬件逻辑关系,主要是服务器和硬盘等在线信息。 Mon服务通过集群的方式保证其服务的可用性。 OSD服务用于实现对磁盘的管理,实现真正的数据读写,通常一个磁盘对应一个OSD服务。 客户端访问存储的大致流程
五:ceph基础架构5.1 简述ceph 是一种开源存储软件。底层实现了对象存储,并以此为基础 对外提供对象存储接口、块存储接口、文件级存储接口。
5.2 环境CEPH版本:Nautilus 5.3 架构图官方架构图 地址链接:https://docs./docs/master/architecture/ 简化版 RADOS:Reliable Autonomic Distributed Object Store(可靠的,自主的,分布式的对象存储)。在 ceph 中这个名词经常出现,有时会以 R 表示 RADOS。实际上这个词仅仅是对 ceph 的一个修饰词,并不代表 ceph 的组件什么的。简单的理解, RADOS = ceph 对象存储集群 即可。 RGW、RBD、CEPH FS: 这三个就是 ceph clients访问RADOS的方式 5.4 ceph基础架构CEPH组件主要分分为两部分: Ceph Node:构成Ceph集群的基础组件 Ceph Client:对外提供多种方式使用Ceph存储的组件 5.5 ceph基础组件此部分介绍构成Ceph集群的基础组件,其中包含OSD、Manager、MSD、Monitor OSD(ceph-osd)object storage daemon,对象存储进程。ceph 管理物理硬盘时,引入了OSD概念,每一块盘都会针对的运行一个OSD进程。换句话说,ceph 集群通过管理 OSD 来管理物理硬盘。OSD 一般功能为:存储数据、维护数据副本、数据恢复、数据再平衡以及对ceph monitor组件提供相关监控信息. 也就是负责响应客户端请求返回具体数据的进程。一个Ceph集群一般都有很多个OSD。 Manager(ceph-mgr)用于收集ceph集群状态、运行指标,比如存储利用率、当前性能指标和系统负载。对外提供 ceph dashboard(ceph ui)和 resetful api。Manager组件开启高可用时,至少2个。 MDS(ceph-mds)Ceph Metadata Server,元数据服务。为ceph 文件系统(cephFS)提供元数据服务(ceph 对象存储和块存储不需要MDS)。为 posix 文件系统用户提供性能良好的基础命令(ls,find等)。 Monitor(ceph-mon)一个Ceph集群需要多个Monitor组成的小集群,它们通过Paxos同步数据,用来保存OSD的元数据。 维护集群的状态,包含monitor组件信息,manger 组件信息,osd组件信息,mds组件信息,crush 算法信息。还负责ceph集群的身份验证功能,client在连接ceph集群时通过此组件进行验证。Monitor组件开启高可用时,至少3个。 ObjectCeph最底层的存储单元是Object对象,每个Object包含元数据和原始数据。 PGPG全称Placement Grouops,是一个逻辑的概念,一个PG包含多个OSD。引入PG这一层其实是为了更好的分配数据和定位数据。 RADOSRADOS全称Reliable Autonomic Distributed Object Store,是Ceph集群的精华,用户实现数据分配、Failover等集群操作。 LibradioLibrados是Rados提供库,因为RADOS是协议很难直接访问,因此上层的RBD、RGW和CephFS都是通过librados访问的,目前提供PHP、Ruby、Java、Python、C和C++支持。 CRUSHCRUSH是Ceph使用的数据分布算法,类似一致性哈希,让数据分配到预期的地方。 RBDRBD全称RADOS block device,是Ceph对外提供的块设备服务。 RGWRGW全称RADOS gateway,是Ceph对外提供的对象存储服务,接口与S3和Swift兼容。 CephFSCephFS全称Ceph File System,是Ceph对外提供的文件系统服务。 5.6 Ceph Clients此部分介绍 ceph 对外提供各种功能的组件。其中包含:Block Device、Object Storage、Filesystem。
5.7 ceph存储过程前面介绍Ceph的一些组件及对外提供的功能,这部分主要介绍Ceph的逻辑存储,这部分主要介绍Ceph的存储逻辑。在对象存储中,一切都是扁平化的,并且存储的最小单元为对象(OBJ) ceph 在对象存储的基础上提供了更加高级的思想。当对象数量达到了百万级以上,原生的对象存储在索引对象时消耗的性能非常大。ceph因此引入了 placement group (pg)的概念。一个PG就是一组对象的集合。 obj和pg之间的映射由ceph client计算得出。 讨论 pg 时,不得不提的另外一个名词:pgp。pgp决定了pg和osd 之间的映射关系。一般将 pgp_num 设置成和 pg_num 一样大小。这里还有一个名词需要提一下,在ceph中会经常见到crush算法。简单来说,crush 算法就是指 ceph 中数据如何存储、读取的过程。由于ceph集群面对许多的独立项目,因此ceph还引入了ceph pool的概念用于划分不同的项目。 pg和ceph pool的区别:
像大多数集群软件一样,ceph 也提供了缓存的概念。称之为 Cache Tier(缓存层,在具体使用时有时会称之为缓存池)。缓存池对用户来说是透明的,因此不会改变用户的原有使用逻辑。 以下缓存池的介绍,均为底层逻辑。在没有缓存池时,ceph client 直接指向存储池。在添加缓存池后,ceph client 指向缓存池,缓存池再指向存储池。 5.8 三种存储类型5.8.1 块存储rbd典型设备:磁盘阵列,硬盘 主要是将裸磁盘空间映射给主机使用的。 优点:通过Raid与LVM等手段,对数据提供了保护。 多块廉价的硬盘组合起来,提高容量。 多块磁盘组合出来的逻辑盘,提升读写效率。 缺点:采用SAN架构组网时,光纤交换机,造价成本高。 主机之间无法共享数据。 使用场景:docker容器、虚拟机磁盘存储分配。 日志存储。 文件存储。 5.8.2 文件存储fs典型设备:FTP、NFS服务器 为了克服块存储文件无法共享的问题,所以有了文件存储。 在服务器上架设FTP与NFS服务,就是文件存储。 优点:造价低,随便一台机器就可以了。 方便文件共享。 缺点:读写速率低。 传输速率慢。 使用场景: 日志存储。 有目录结构的文件存储。 5.8.3 对象存储swift ,rgw典型设备:内置大容量硬盘的分布式服务器(swift, s3) 多台服务器内置大容量硬盘,安装上对象存储管理软件,对外提供读写访问功能。 优点:具备块存储的读写高速。 具备文件存储的共享等特性。 使用场景:(适合更新变动较少的数据) 图片存储。 视频存储。 |
|