Ceph的原理的描述

Ceph原理描述HYPERLINKCeph原理描述 1HYPERLINKCEPH的介绍 2HYPERLINKCEPH的优缺点 4HYPERLINKceph如何存取对象文件 5HYPERLINK（1） File->object映射 6HYPERLINK（2） Object->PG映射 7HYPERLINK（3） PG->OSD映射 7HYPERLINKCeph的强一致写入 8HYPERLINKCeph的读取 9HYPERLINKCephCRUSH数据分布算法 9HYPERLINKCeph网络配置参考 11HYPERLINKCEPH支持的主要功能 12HYPERLINKCeph的Journal功能 12HYPERLINKCephPools 12HYPERLINK分层缓存 12HYPERLINK条带化 14HYPERLINK数据的重新平衡 16HYPERLINK数据恢复 16HYPERLINK数据清洗 17HYPERLINK扩展Ceph 17HYPERLINKCEPH测试性能（初级版本） 18HYPERLINKCEPH的Roadmap 18HYPERLINK关于bluestore 18HYPERLINK关于RBDMirror 19HYPERLINK关于压缩 20HYPERLINK关于加密 20HYPERLINK关于去重 20HYPERLINK关于Qos 21CEPH的介绍Ceph是一个软件分布式存储平台。在2004年，由SageWeil开发了Ceph，并于2006年，基于开源协议开源了Ceph。2012年，Ceph的发布了第一个稳定版本。2016年4月16号，cephv10.2.1Jewel版本发布。Ceph通过统一的底层RADOS向上支持统一存储,目前支持3类存储接口，分别是“对象存储（RADOSGW）”，“块存储（RBD）”，“文件系统（CEPHFS）”Ceph的总体框架图如下示：LIBRADOS主要解决多语言与RADOS（可靠，自主分布式对象存储）间的互访问题，目前支持C,C++,java,python,Ruby及PHP语言RADOSGW主要解决与RESTAPI的交互问题，当前支持S3,Swift定义的APIRBD主要面向QEMU/KVM提供块设备存取CEPHFS则是一种POSIX兼容的文件，并且支持FUSE(FilesysteminUserspace:用户空间文件系统）RADOS则是整个系统的底层，实现统一的存取。RADOS由主要由三部分组成：Monitor:常称之为MON,是ceph中的监控进程，它主要负责：收集所有OSD的状态并与其它MON一起维护集群的映射信息支持通过启用多个MON保证服务高可用响应其它client对集群映射信息的请求。OSD：ObjectStorageDevice与逻辑磁盘进行交互，完成数据的读写，恢复，校验,重新平衡等。检测自已的状态，及检查其它OSD的状态，并主动上报给MonitorMDS:MDS是CEPHFS使用的元数据（metadata）服务守护进程，如果不使用CEPHFS,则MDS没有存在的必要，依据官方文档：/docs/master/rados/deployment/ceph-deploy-mds/说明，当前不建意在生产环境中部署多个MDS。CEPH的优缺点优点：统一存储架构(Block/File/Object)，易于与openstack进行整合，整合后Nova,Glance,Cinder之间没有数据传输，快速创建虚拟机，运维方面只需要管理一个统一存储。目前此方案在openstack社区目前呼声较高。支持快照，配额，动态伸缩，数据负载均衡。无中心化，扩展性好。monitor维护的数据信息并不多，故大规模部署时，osd可以变得很大,达到上千的osd时,monitor维护的信息也不会很多。且越大规模，条带化效果越好。目前Ceph最大的用户案例是Dreamhost的ObjectService，目前总容量是3PB，可靠性达到99.99999%，数据存放采用三副本，它的价格比S3还便宜。自管理。恢复不需要人工介入，在恢复期间，可以保持正常的数据访问。当组件发生故障时，自动进行数据的重新复制。当组件发生变化时(添加/删除)，自动进行数据的重分布经过调优后的性能不错，按照和有云交流获得的数据，基本可以达到SSD的物理速度。社区比较成熟（/会列出截止当天的统计信息，从图中可以看出自2015年8月至今下载量比较大）Ceph被下载的统计Ceph提交及开发人员数目缺点：代码实现比较复杂，引入了STL及boost库,学习成本较高。Ceph本身提供的安装版本，效率并不高，但其拥有非常丰富的可调参数（这也是学习成本的一部分），利用这些参数不断调优，可以达到高效率。调优在没有外部培训的情况下，只能是一个摸索的过程。IO路径比较复杂，一次IO处理需要经历多个线程处理。CephFS目前不太成熟，MDS无法大规模部署。（见官方：/docs/master/rados/deployment/ceph-deploy-mds/）。J版本发布时，CephFS被宣称稳定并且生产就绪。ceph如何存取对象文件ceph的三次映射如上图示：File——file就是用户需要存储或者访问的文件。对于一个基于Ceph开发的对象存储应用而言，这个file也就对应于应用中的“对象”，也就是用户直接操作的“对象”。Ojbect——object是RADOS所看到的“对象”。Object与上面提到的file的区别是，object的最大size由RADOS限定（通常为2MB或4MB），以便实现底层存储的组织管理。当上层应用向RADOS存入size很大的file时，需要将file切分成统一大小的一系列object（最后一个的大小可以不同）进行存储。PG（PlacementGroup）——PG的用途是对object的存储进行组织和位置映射。一个PG负责组织若干个object（可以为数千个甚至更多），但一个object只能被映射到一个PG中，即，PG和object之间是“一对多”映射关系。同时，一个PG会被映射到n个OSD上，而每个OSD上都会承载大量的PG，即，PG和OSD之间是“多对多”映射关系。在实践当中，n至少为2，如果用于生产环境，则至少为3。一个OSD上的PG则可达到数百个。OSD——即objectstoragedevice，前文有说明，用于实现object的存放读写等工作，是具体干活的。在实现对象存取时，一个文件一般要经过三次映射File->object映射为了方便RADOS存取,需要将用户可操作的file映射为object。处理上就是按照object的最大size对file进行切分。每一个切分后产生的object将获得唯一的编号，常称之为oid，即objectid。图中的ino是待操作file的元数据，可以简单理解为该file的唯一id（目前未分析这一数据存储的具体位置）。ono则是由该file切分产生的某个object的序号。从元组（ino,ono）到oid的映射比较简单（实际上在ceph中随处可见这样的映射处理）,直接将ino及non连接起来，就构成了oid.Object->PG映射接下来需要将object映射到PG，这一步映射公式大致如下示：hash(oid)&mask->pgid首先是使用Ceph系统指定的一个静态哈希函数计算oid的哈希值，然后，将这个伪随机值和mask按位相与，得到最终的PG序号（pgid）。由于同一个Pool(关于pool的概念下文叙述，目前仅需要知道pool抽象了一组PG)内PG给定的PG总数为m（m应该为2的整数幂），则mask的值为m-1。PG->OSD映射第三次映射就是要决定把这个PG内需要存取object的任务交给哪个OSD来进行处理。如图所示，RADOS采用一个名为CRUSH的算法，将pgid代入其中，然后得到一组共n个OSD。这n个OSD即共同负责存储和维护同一个PG中的所有object。N的数量在这里就是副本的数量。注意CRUSH算法的结果不是绝对不变的，一般它会受几个因素影响：系统状态变化，例如osd数量发生了增减，为了保持数据的平衡，PG与OSD之间的映射会发生变化。存储策略配置变化，例如管理员修改了CRUSHrule（当然，在实际的生产系统中，策略一般不需要轻易进行改变）。Ceph的强一致写入client经过上面的三次映射，就获得了如下信息：要存放的object数据数据需要存放的osd数据需要存放的pg如上图示，client依据CRUSH算法的返回的osd信息，取第一个osd，命名为primaryosdclient将直接和PrimaryOSD通信，发起写入操作,如步骤（1）PrimaryOSD收到请求后，分别向SecondaryOSD和TertiaryOSD发起写入操作，如步骤（2，3）当SecondaryOSD和TertiaryOSD各自完成写入操作后，将分别向PrimaryOSD发送确认信息（步骤4、5）当PrimaryOSD确信其他两个OSD的写入完成后，则自己也完成数据写入，并向client确认object写入操作完成（步骤6）。Ceph的读取 与写入类似，client依据CRUSH算法返回的osd信息，取第一个osd,命名为Primaryosd,并直到于primaryosd进行通信，primaryosd收到信息后，直接将信息读取到，并返回给client.注意，目前的Ceph设计中，被读取的数据仅由PrimaryOSD提供。但目前也有分散读取压力以提高性能的讨论。CephCRUSH数据分布算法CRUSH是ceph的一个模块，它本身是可扩展的伪随机（确定性的）数据分布算法，主要解决可控、可扩展、去中心化的数据副本分布问题。CRUSH算法有以下几个优点任何组件都可以独立计算出每个object所在的位置(去中心化)。只需要很少的元数据(clustermap)，只要当删除添加设备时，这些元数据才需要改变。如上文提到的一样，CRUSH算法用于依据PG获取到一组OSD列表。CRUSH算法主要有两个内容定义clustermapCeph可以将系统的所有硬件资源描述成一个树状结构（例如不同区域，不同的机架，不同的主机等等，ceph预定义了10种类型），然后再基于这个结构按照一定的容错规则生成一个逻辑上的树形结构作为Crushmap。Crushmap的叶子节点就是OSD.如下图示定义crush规则有了树形的Crushmap，如何一步一步从中选出最终的叶子节点OSD,这个就是由rule来定义。一个合法的rule的定义是这样的：rulereplicated_ruleset{ruleset0#rulesetid,表明这个rule属于哪个rulesettypereplicated#表示此rule在哪可使用，像本例，在副本模式下使用。min_size1#与max_size一起限定rule使用范围，#即当副本大于等于1，并且小于等于10时适用本规则max_size10steptakedefault#如果本规则适用，自crushmap的哪个#节点开始查找合适的osd,像本例，将从default位置开始查找。stepchoosefirstn0typeosd#表示自节点中选择多少个type指定的节点，#本例指的是选出副本数目的osd节点。stepemit#标明输出结果。也可以配置为#跳转到另一条规则继续匹配。}Ceph网络配置参考建议用两个网络运营Ceph存储集群：一个公共网（前端）和一个集群网（后端）。为此，各节点配备多网卡采用上面的部署主要有以下几方面考虑将client的流量不良隔离在publicnetwork，防止其进入clusternetworkOSD为客户端处理数据复制，复制多份时OSD间的网络负载势不影响到客户端和Ceph集群的通讯。OSD恢复及重新平衡时，不影响publicnetworkCEPH支持的主要功能Ceph的Journal功能为了提高速度并保证必要的一致性，ceph在写操作时，可以选择启用journal功能，journal功能的实现比较简单,当执行写操作时，数据首先被写入到日志文件，然后在合适的时机会被刷新到磁盘。在上图中我们计论“ceph的强一致写入”时，提到了osd在写入完成后，会回复ack.在开启journal时，ack的回复将被提前到一旦写入日志就直接回复ack.CephPoolsCeph支持术语Pool,Pool是一种对多个Object进行逻辑分组的机制。目前来看，其主要目的是支持多租户，异地容灾及其它细节管理方面的考虑，Pool主要有以下几个方面：基于Pool可以划分了对象所有权、访问权设置Pool类型，目前支持2种（1）多副本类型(2)ErasureCode（纠删码）类型设置Pool对应的CRUSHruleset,通过此规则集，我们可以指导CRUSH如何存取PG定义快照的最小单位。提供必要的强性，例如增加pg数目，变化Pool对应的副本数。注意,在RADOS层面，Poolname是由上层传输下来的，我们通过Poolname可以找到pool-id,然后，将pool-id及pg-id组织成pool-id.pg-id格式发送给相应的primaryOSD分层缓存分层缓存需要创建一个由高速存储设备（如SSD）组成的存储池作为cache层，并创建相对低速设备组成的后端存储池作为存储层。Ceph的Objecter会依据前端cache层配置的不同模式来决定往哪里存储对象，及何时把cache层的对象刷回到后端存储层。cache层和后端存储层对Ceph客户端来说是完全透明的。目前代码中共有6种cache模式：回写方式（CACHEMODE_WRITEBACK）如果是写操作，先写入到cache,等合适的时间或者cache为满时刷至后端。如果是读操作，cache中存在，则直接返回。Cache中如果不存在，则加载入cache并返回。转发方式（CACHEMODE_FORWARD）如果cache的模式被变更为此模式，所有由客户端来的对此cache的请求，将被回复ENOENT，并指明重定向到后端的cache.客户端收到此消息，将由osdc模块代为换地址重新请求。这一模式常常在删除cachetier时使用。可以辅助解决新的对象，旧的对象都刷新至后端tier.注意：这种情况下，缓存实际上是不起作用的。只读方式（CACHEMODE_READONLY）正如其名称所指明的一样，在本cache中不包含此对象时，如果是读操作，则自后台拉取此对象，并缓存到本cache中，如果是写操作，则直接采用“转发方式”处理。注意：前端的数据失效由策略规定，故读的时候，不会考虑后端是否有变化，会出现旧版本情况，故不能用于易变的对象。读转发方式（CACHEMODE_READFORWARD）如果是写操作，则检查cache是否为满，如果满则阻塞本操作直到cache被刷入后端。否则写入缓存。如果是读操作，则直接采用“转发方式”处理。注意：读不会被缓存。读代理方式（CACHEMODE_READPROXY）如果是写操作，则检查cache是否为满，如果满则阻塞本操作直到cache被刷入后端，否则写入缓存。如果是读操作，则执行do_proxy_readdo_proxy_read详细描述：变更tier为后端tier在当前处理流程中，直接模拟osdc构造请求，并向后端请求数据。后端消息后，构造Message向客户端进行消息（finish_proxy_read）注意：读不会被缓存。代理方式（CACHEMODE_PROXY）代理读写方式对EC类pool进行cache处理，对非EC类，对写操作执行cache处理，对读操作进行“读代理方式”条带化 Ceph本身在RADOS层没有条带化的概念。Ceph的条带化是在osdc模块中实现的，主要通过以下三个配置项完成条带化配置：ObjectSize必须容纳一个或者多个条带单元(默认4M)Stripeunitsize一个stripe单元的大小StripeCount条带单元在多少个Object间存取。注意：由于条带化后，会导致数据的存取方式发生变化，故参数一旦设置即不可改变，需要提前做好性能测试技术细节 条带化原理图（注：灰色区域是为了说明方便加的标注，不含数据）条带化写：如上图，在写一个文件时，文件会按stripeunit划分为多个unit进行写入，按上图共有31个unit，(另外上图也指出了一个Ojbect中可以包含4个stripeunit),由于stripecount被配置为4，故每4个object称之为一个objectset,写入时，stripeunit按红色线条的方向，从上向下依次排开。当这4个object被划分到不同的osd上时，相当于吞吐被增大了4倍。条带化读：与条带化读正好相反，略。数据的重新平衡如果一个空的osd上线，它会主动联系monitor,monitor会据此更新cephcluster的映射信息。Monitor重新指定PG的位置分配，此时新加入的osd将获得一些PG(如何分配PG受CRUSH规则控制)。在整个平衡过程中，cephcluster的映射信息是稳定的（因此不会影响前端的写入读取操作），直到新的osd完成了所有的pg，monitor会更新cephcluster的映射信息，旧的osd会在相应的pg映射信息中被移除掉。下面是个平衡后的示例：数据恢复Ceph处理两种故障临时性故障:主机升级维护，重启，掉电等等在一定时间内可以重新上线OSD的故障永久性故障:一定时间内无法将原来的OSD数据重新加入集群。Ceph在处理采用PGLog机制处理临时故障，采用backfill机制处理永久性故障。临时性故障处理osd上线后，首先读取自已的pglog数据发送自已的pglog给primarypg,使其针对自身的pglog产生出一组missing列表。Osd针对missing列表发送pull操作，拉取相应的数据。注在执行第3步之前，此osd不能对外提供服务，但在（3）时，可以对外提供服务，如果要求服务的pg恰好位于missing列表内部，则请求会被挂起，同时此pg对应的信息会被优先拉取。永久性故障处理Osd上线后，首先读取自已的pglog数据发送自已的pglog给Primarypg,使其针对自身的Pglog产生一组missing列表，primarypg无法产生此missing列表，通知osd需要进行backfill恢复。Primarypg会在后端启动backfill流程向故障osd推送数据。数据清洗 为了捕获cephbugs或者文件系统错误来确保object正常，ceph在pg上会执行一个类似fsck的工具。每个pg中的object会产生一个结果，然后用这个结果与其它复本进行比对，以确保对象间是一致的，数据清洗有轻量级及重量级之分.软量级的检查主要是object的大小及属性（建意一天一次），重量级的检查是按object的位进行检查的（建意一周一次）扩展CephCeph提供了相应的插件机制来支持对ceph的扩展，Ceph可