Ceph基本原理介绍

Ceph基本原理介绍目录•WhyCeph•CephCluster的基本结构•Ceph的几个重要概念•CephCluster中的关键流程WhyCeph?•大数据时代企业级存储产品需求WhyCeph•Ceph的定位基本结构•模块架构基本结构•底层Rados模块是Ceph分布式存储的根本–Reliable,Automatic,Distributed,ObjectStore–Rados提供对象存储接口；–Rados负责维护集群状态及数据分发。•Ceph底层采用对象存储，其它存储接口基于对象存储接口进行二次封装。Rados基本组件•Rados由两类组件构成–OSD（ObjectStorageDevice）负责数据的存储和维护。–Monitor负责集群状态的维护及检测。为消除单点故障，monitor组件也是集群形式。OSD的逻辑结构•系统部分（ObjectStorageDevice）本质上是安装了操作系统及文件系统的计算机，并带有存储介质。•守护进程（OSDDaemon）OSD系统平台的守护进程，主要负责存储和查找对象，并且负责向该对象的复制节点分发和恢复。重要概念•Pool–每个cluster可创建多个pool；–Pool是逻辑上的隔离单位，不同的pool可以具有完全不同的数据处理方式，如replicasize，PGnumbers，CRUSHrules，Snapshots，ownership等配置均通过pool进行隔离；–Ceph中的任何操作必须先指定pool，无论是块存储或对象存储；–Pool具体的OSD没有mapping的对应关系；重要概念•OSDMap–Cluster所有osd的信息，包括拓扑、状态等信息；–OSD加入和退出或者节点权重的变化会引起osdmap的变化；–Monitor,cephclient以及osd均存有OSDMap信息，且彼此版本可能不同，monitor维持最新的权威版本的OSDMap。•OSDMap的同步——慢传播–Monitor随机的挑选一些OSD更新OSDMap；–Monitor仅直接通知需要了解该变化的节点，如一个新的OSD加入会导致一些PG的迁移，那么这些PG的OSD会得到通知；–同一个PG中的OSD进行通信时会附带osdmap的epoch，若版本不一致，则具有更高版本osdmap的osd会将其拥有的osdmap信息push到低版本osdmap的osd；–在集群空闲时，很有可能需要更长的时间完成新Map的更新。重要概念•PG(Placementgroup)–Pool内部的虚拟概念，无实体对应，Pool中的PGnumber是可配置的；–Object与osd的中间逻辑分层，object固定属于某个PG（由crush算法决定），PG与osd存在对应关系；–PG和OSD之间是多对多的对应关系，即一个PG对应多个OSD，同时一个OSD可能对应不同的PG；–每一个PG都有一个primaryOSD和多个SecondaryOSD，object会被分发到这些osd上进行存储；–PG中primaryosd负责写操作，读操作可由replicaosd完成；–PG中primaryosd默认为pg中第一个osd，当OSD发生故障时(意外crash或者存储设备损坏)，Monitor会将该OSD上的所有角色为Primary的PG的Replicated角色的OSD提升为PrimaryPG，这个OSD所有的PG都会处于Degraded状态；–PG中处于degraded状态的PG若无法恢复，该OSD会被踢出集群，这些PG会被Monitor根据OSD的情况分配到新的OSD上–PG作为Object的拥有者，负责维护Object的信息；–PG的数据和相关故障恢复、迁移所必须的记录都是由每个PG自己维护，也就是存在于每个PG所在的OSD上。重要概念•PGMap–PGMap是由Monitor维护的所有PG的状态；–OSD仅维护自己所拥有的PG状态；–Monitor会根据所掌握的所有PG的状态确定是否需要进行PG迁移，即rebalance；–当monitor根据cluster配置值及集群状态决定对某个PG进行迁移时，首先会更新其对应的PGMap，并将该PGMappush到相关的OSD；–OSD启动并加入OSDMap后，Monitor会通知这个OSD需要创建和维护的PG，当存在多个副本时，PG的PrimaryOSD会主动与Replicated角色的OSD通信并且沟通PG的状态，其中包括PG的最近历史记录，新的OSD会得到其他PG的全部数据然后逐渐达成一致，或者OSD已经存在该PG信息，那么PrimaryPG会比较该PG的历史记录然后达成PG的信息的一致（peering）；–对于新加入集群的osd，没有pg需要同步（peering），monitor决定pg的迁移。重要概念•PGLog–PGLog主要设计用户osd临时故障恢复后pg的恢复；–PGLog由PG维护并且记录了该PG所有的操作，其非常类似于关系型数据库领域的undolog；–PGLog与Journal概念不同，Journal是底层单机存储模块用来维护事务一致性的，它是数据库领域的redolog；–PGLog通常只保存PG最近几千条的操作记录，但是在PG处于Degraded状态时，PGLog会保存更多的日志条目期望能在故障PG重新上线后用来恢复数据。关键处理流程•新osd的加入–OSD会向Monitor申请加入，Monitor验证其信息后会将其加入OSDMap并标记为IN；–同时monitor将申请加入的osd放在PendingProposal中，并会在下一次Monitor“讨论”中提出；–OSD在得到Monitor的回复信息后发现自己仍然没在OSDMap中会继续尝试申请加入；–接下来Monitor会发起一个Proposal，申请将这个OSD加入OSDMap并且标记为UP；–按照Paxos的流程，从proposal-accept-commit到最后达成一致，OSD最后成功加入OSDMap，OSD状态变为UP；–新的OSD获得最新OSDMap发现其已经在其中时，不再向Monitor发起加入申请；–OSD开始建立与其他OSD的连接，Monitor开始给其分配PG，进入PG迁移即rebalance流程。关键处理流程•OSD临时故障的恢复–某一个OSD下线；–如果OSD主动下线它会通知Monitor自己下线，请做好相关通知工作；–如果是异常下线，那么其他OSD和Monitor会通过Heartbeat来得知OSD下线同样让Monitor知晓；–Monitor重新计算该OSD所属PG的PrimaryOSD，并将结果主动通知这些PG所在的OSD；–PG将自己设为Degraded状态后，将会减小自己的副本数，并增加保存的PGLog条目数。关键处理流程•OSD临时故障恢复故障发生后，如果一定时间后重新上线故障OSD，那么PG会进行以下流程:–故障OSD上线，通知Monitor并注册，该OSD在上线前会读取存在持久设备的PGLog；–Monitor得知该OSD的旧有id，因此会继续使用以前的PG分配，之前该OSD下线造成的DegradedPG会被通知该OSD已重新加入；–这时候分为两种情况，注意这个情况下PG会标志自己为Peering状态并暂时停止处理请求；–第一种情况是故障OSD所拥有的PrimaryPG•它作为这部分数据“权责”主体，需要发送查询PG元数据请求给所有属于该PG的Replicate角色节点；•该PG的Replicate角色节点实际上在故障OSD下线时期间成为了Primary角色并维护了“权威”的PGLog，该PG在得到故障OSD的PrimaryPG的查询请求后会发送回应；•PrimaryPG通过对比ReplicatePG发送的元数据和PG版本信息后发现处于落后状态，因此它会合并得到的PGLog并建立“权威”PGLog，同时会建立missing列表来标记过时数据；•PrimaryPG在完成“权威”PGLog的建立后就可以标志自己处于Active状态；–第二种情况是故障OSD所拥有的ReplicatePG•这时上线后故障OSD的ReplicatePG会得到PrimaryPG的查询请求，发送自己这份“过时”的元数据和PGLog；•PrimaryPG对比数据后发现该PG落后并且过时，比通过PGLog建立了missing列表；•PrimaryPG标记自己处于Active状态。–PG开始接受IO请求，但是PG所属的故障节点仍存在过时数据，故障节点的PrimaryPG会发起Pull请求从Replicate节点获得最新数据，ReplicatePG会得到其他OSD节点上的PrimaryPG的Push请求来恢复数据–恢复完成后标记自己Clean关键处理流程•OSD临时故障的恢复–在恢复过程中，PG的PrimaryOSD出现故障且未重新选举出新的PrimaryOSD的时候，是PG唯一不处理请求的阶段，但这个阶段通常会在1s内结束；–在恢复期间故障OSD会维护missing列表，如果IO正好是处于missing列表的数据，那么PG会进行恢复数据的“插队”操作，主动将该IO涉及的数据从ReplicatePG拉过来，提前恢复该部分数据，此种情形的延时一般在几十毫秒。关键处理流程•OSD永久故障处理–若OSD故障无法短期，Ceph将其视为永久性故障；–对于永久性故障的OSD，Ceph会将其从OSDMap中剔除，并利用CRUSH算法对落在其上的PG重新进行数据分布的计算，包括重新为PG分配OSD以及计算PrimaryOSD；–新加入的OSD将从同PG的其它节点pull数据，恢复自己的PG信息。关键处理流程•Rebalance(PG迁移)–新加入的OSD会导致OSDMap的更新；–OSDMap的更新传播采用按需和慢传播两种模式；–Ceph会根据集群的当前负载情况选择是否进行PG的迁移，决策依据是空间利用率、带宽负载以及集群闲忙状况等；–若选择迁移的OSD是PrimaryOSD，Monitor会首先将其它Replicated且不做迁移的OSD设为PrimaryOSD；–更新PGMap信息，并将更新后的PGMap直接push到相关的OSD（包括迁移出的OSD）；–新加入的从PG的其它节点获取PG中objects数据；–迁移出PG的OSD将删除不属于自己所拥有的PG中的objects；–迁移过程会造成IO性能的下降。关键处理流程•块设备数据写流程–librbd根据imageid、dataoffset和datalength，以及striping配置参数，计算数据快对应的objectset；–Rados对计算得到的object将其映射到PG，得到pgid；–Rados利用CRUSH算法计算得到object所在PG的osdupset；–Client直接与upset中的primaryosd通信，发起写入操作（对于读操作，可以采用replicatedosd）；–PrimaryOSD收到写请求后，分别向其余的replicatedOSD发起写操作；–ReplicatedOSD各自完成写操作向primaryOSD发送确认消息；–PrimaryOSD收到所有的replica的写完成后，自己也完成数据写入后，向client确认object写操作完成；–Objectset中所有object完成下操作，则此数据块写操作完成。关键处理流程•块设备的snapshot管理–Ceph中的snap分为两类，两类实现基本相似，仅使用方式上的区分•PoolSnapshot:对整个Pool打一个Snapshot，该Pool中所有的对象都会受影响•SelfManagedSnapshot:用户管理的Snapshot，简单的理解就是这个Pool受影响的对象是受用户控制的。–Snapshot利用pool进行隔离，Pool都有一个snap_seq字段，该字段可以认为是整个Pool的GlobalVersion；–Object也都带有snap_seq，而每个Object会