集群异常下的IO

问题

集群出现非致命性故障后，CEPH如何处理IO。

出于对问题的简化，假设分析场景为size为2的情况下rbd的写。

思考

首先，确定有哪些故障情况（非致命性情况）：

• OSD故障
• 网络故障
• rbd客户端故障

梳理一下粗略的IO流程

client
 | 
 |1
 ↓
master-osd → 3 → complete → 6 → reply
 |    ↑
 |2   |5
 ↓    | 
slave-osd  → 4 → complete

client表示客户端，master-osd单指一次写操作的主OSD，slave-osd指一次操作的副本OSD，reply表示主OSD对client的应答。

client发起一个写请求，通过网络，发送到master-osd，master-osd于是发送写副本请求道slave-osd，两者并行将数据写入到磁盘中，当slave-osd完成写副本后，回应master-osd。master-osd在主副本都完成写入后回应client，本次写请求结束。

对照上图，不论是哪种情况的故障，都可以表示为某个路径中断。

更详细的故障情况：

• 1.client与cluster连接异常，表现为1或6路径中断
• 2.master-osd与slave-osd连接异常，表现为2或5路径中断
• 3.osd与disk异常，表现为3、4路径中断

故障1

路径1中断的情况很常见，可以是client节点断点，或者是网络问题。
如果是网络出现异常，则client会等待网络畅通后，下发写操作。

故障2

该情况相对复杂，考虑这几种情况：

• master-osd的写副本请求到达slave-osd，slave-osd未给与回应
• master-osd的些副本请求到达slave-osd，master-osd故障，导致无法接收回应
• master-osd的写副本请求未到达slave-osd，slave-osd出现故障
• master-osd的写副本请求未到达slave-osd，master-osd出现故障

第1种情况和第3种情况是相似的，master-osd在无法收到slave-osd的回应时，无从得知slave-osd的具体情况。
master-osd会一直等待，直到crush map表发生改变，master-osd退出等待，将写请求重新放入处理队列中，直到PG再次恢复后，这个写请求才会再次被处理。假如在crush map表发生变化前，master-osd已经将数据写入磁盘，那么恢复后再次处理写请求时，流程直接跳到完成步骤。
这么做的原因，PG恢复的时候，是通过主向副本拷贝数据和日志，所以恢复流程结束后，副本PG已经拥有写请求的数据，master-osd不需要再发送写副本请求，直接回应client即可。

第2种情况，如果master-osd长时间不上线，slave-osd会变成master-osd，crush map改变后，slave-osd之后的过程和前面相同。在这一过程中，slave-osd转变为新的master-osd。

第4中情况，在PG迁移完毕后，client会重新发送写请求到新的master-osd中。

故障3

进程与对应的磁盘出现问题，一般情况下，多为磁盘故障。

这里罗列两种可能性：

• 磁盘坏道
• 磁盘被拔

遇到磁盘问题，OSD选择断言崩溃处理，crush map表改变，原本分发到故障OSD上的IO会一句crush map分散到其他OSD。