为什么软件定义存储 长时间 Peering 问题和 EIO 处理

随风_YA2H2

　　这是Ceph开发每周谈的第九十五篇文章，为什么软件定义存储记录从17年10月09号到17年10月16号的社区开发情况。笔者从前年开始做Ceph的技术模块分析到今年中告一段落，想必有挺多人期待下一篇Ceph技术分析。考虑到Ceph的发展已经从前年的一穷二白到现在的如火如荼，但对于社区的方向和实况仍有所脱节，笔者考虑开始Ceph开发每周谈这个系列。每篇文章都会综述上周技术更新，围绕几个热点进行深度解析，如果正好有产业届新闻的话就进行解读，最后有读者反馈问题的话并且值得一聊的话，就附上答疑部分。

　　潜在的长时间 Peering 和 EIO 处理

　　在大多数场景下，RADOS 会按序处理所有请求，不管是读，写还是删除。即使在一个 OSD 存在故障退出然后再上线后，所有的“遗失”操作对应的对象都会去通过其他权威 OSD 处得到，然后恢复回来。当然这些恢复操作都是后台异步进行的。对于读写操作来说，这些都没有问题，但如果是删除操作，那么在 Peering 完成之前就需要把这些对象同步删除，可想而知，当存在大量对象需要删除时，在这个过程中会出现严重的 Peering 卡住问题。

　　在 Luminous 发布的版本中，Josh Durgin 实现了在 Peering 过程中可以异步删除对象的特性，使得说能把删除操作放在 Recovery 过程中执行，跟其他读写操作一样。这个问题实际上在对象存储，以及 backfill 时候出现故障容易发生，形成大规模的 IO 中断。

　　另外，在 BlueStore 中，由于以前有一层文件系统来处理一些潜在的逻辑错误，在 BlueStore 中发现比以前更容易出现 EIO。因此，在版本中增加里 EIO recovery 的能力，就是通过副本技术，当发送 EIO 时，可以通过其他副本来走恢复流程来恢复出现 EIO 的对象。目前在 EC 后端中，这个行为仍然未实现。

　　需要注意的是，当在 Luminous 使用 SSD 和 HDD 时，OSD 会自动识别然后采用对应介质的配置，解决用户调优问题。