云存储高可用机制2 说课一等奖

云存储高可用机制22Ceph的高可用机制

作为一个面向大规模的分布式存储系统，故障处理是作为一个常态异常处理。Ceph为了细化和保证故障发生和故障恢复的集群高可用性和一致性，在设计上将故障分为两类:临时性故障:主机升级维护，重启，掉电等等在一定时间内可以重新上线OSD的故障永久性故障:作为强一致存储系统，状态只跟存储在持久设备的数据有关，因此这类故障主要就是盘损坏或者主机损坏并无法及时转移盘到另外主机。换句话说救是一定时间内无法将原来的OSD数据重新加入集群。Ceph将所有数据域划分成若干个PG(PlacementGroup)管理，每个PG都存活在一个OSD节点上，因此PG是管理、恢复数据的主体。而Monitor节点不参与用户数据的任何操作，只提供了PG选举的协调作用。PG所属数据的处理和恢复都由PG本身进行协调。3临时性故障

首先这里考虑临时性故障的处理，Ceph引入了PGLog的概念，顾名思义，PGLog由PG维护并且记录了该PG所有的操作，其非常类似于关系型数据库领域的undolog，同时需要将PGLog与Journal概念划分清楚，Journal是底层单机存储模块用来维护事务一致性的，它是数据库领域的redolog。undolog和redolog在数据库的作用与Ceph的PGLog和Journal作用是一致的。PGLog通常只保存PG最近几千条的操作记录，但是在PG处于Degraded状态时，PGLog会保存更多的日志条目期望能在故障PG重新上线后用来恢复数据。下面来简单描述故障发生导致OSD下线的流程:某一个OSD下线如果OSD主动下线它会通知Monitor自己下线，请做好相关通知工作。如果是异常下线，那么其他OSD和Monitor会通过Heartbeat来得知OSD下线同样让Monitor知晓Monitor重新计算该OSD拥有的的PrimaryPG，并将结果主动通知这些PG所在的OSDPG将自己设为Degraded状态后，将会减小自己的副本数，并增加保存的PGLog条目数4故障流程故障发生后，如果一定时间后重新上线故障OSD，那么PG会进行以下流程:1.故障OSD上线，通知Monitor并注册，该OSD在上线前会读取存在持久设备的PGLog，2.Monitor得知该OSD的旧有id，因此会继续使用以前的PG分配，之前该OSD下线造成的DegradedPG会被通知该OSD已重新加入3.这时候分为两种情况，注意这个情况下PG会标志自己为Peering状态并暂时停止处理请求:3.1第一种情况是故障OSD所拥有的PrimaryPG3.1.1它作为这部分数据"权责"主体，需要发送查询PG元数据请求给所有属于该PG的Replicate角色节点。3.1.2该PG的Replicate角色节点实际上在故障OSD下线时期间成为了Primary角色并维护了“权威”的PGLog，该PG在得到故障OSD的PrimaryPG的查询请求后会发送回应3.1.3PrimaryPG通过对比ReplicatePG发送的元数据和PG版本信息后发现处于落后状态，因此它会合并得到的PGLog并建立“权威”PGLog，同时会建立missing列表来标记过时数据3.1.4PrimaryPG在完成“权威”PGLog的建立后就可以标志自己处于Active状态3.2第二种情况是故障OSD所拥有的ReplicatePG3.2.1这时上线后故障OSD的ReplicatePG会得到PrimaryPG的查询请求，发送自己这份“过时”的元数据和PGLog3.2.2PrimaryPG对比数据后发现该PG落后并且过时，比通过PGLog建立了missing列表3.2.3PrimaryPG标记自己处于Active状态4.PG开始接受IO请求，但是PG所属的故障节点仍存在过时数据，故障节点的PrimaryPG会发起Pull请求从Replicate节点获得最新数据，ReplicatePG会得到其他OSD节点上的PrimaryPG的Push请求来恢复数据5.恢复完成后标记自己Clean5永久性故障

上面的流程的前提故障OSD在PGLog保存的最大条目数以内加入集群都会利用PGLog恢复，那么如果在N天之后或者发生了永久故障需要新盘加入集群时，PGLog就无法起到恢复数据的作用，这时候就需要backfill(全量拷贝)流程介入。backfill会将所有数据复制到新上线的PG，这里的流程跟上述过程基本一致，唯一的差异就是在第三步PrimaryPG发现PGLog已经不足以恢复数据时，这时候同样分为两种情况:

故障OSD拥有PrimaryPG，该PG在对比PGLog后发现需要全量拷贝数据，那么毫无疑问PrimaryPG在复制期间已经无法处理请求，它会发送一个特殊请求给Monitor告知自己需要全量复制，需要将ReplicatePG临时性提升为Primary，等到自己完成了复制过程才会重新接管Primary角色

故障OSD拥有ReplicatePG，该PG的Primary角色会发起backfill流程向该PG复制数据，由于故障OSD是Replicate角色，因此不影响正常IO的处理除此之外，恢复数据还需要涉及到恢复数据的带宽控制、优先级等细节问题，这里就不一一赘述了。6小结