集群异常下的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。
