1. mds存储

• 元数据的内存缓存，为了加快元数据的访问。
• 保存了文件系统的元数据(对象里保存了子目录和子文件的名称和inode编号)
• 还保存cephfs日志journal，日志是用来恢复mds里的元数据缓存
• 重启mds的时候会通过replay的方式从osd上加载之前缓存的元数据

2. mds冷备/热备

• 冷备就是备份的mds，只起到一个进程备份的作用，并不备份lru元数据。主备进程保持心跳关系，一旦主的mds挂了，备份mds replay()元数据到缓存，当然这需要消耗一点时间。
• 热备除了进程备份，元数据缓存还时时刻刻的与主mds保持同步，当 active mds挂掉后，热备的mds直接变成主mds，并且没有replay()的操作，元数据缓存大小和主mds保持一致。

说明：

• rejoin把客户端的inode加载到mds cache。
• replay把从cephfs的journal恢复内存。

3. mds主备切换策略

• 默认每个standby都一样
• 指定后补
  • mds standby for name指定一 MDS 守护进程的名字，此进程将作为它的候补
  • mds standby for rank此 MDS 将作为本机架上 MDS 守护进程的候补
• 优先级最高standby replay

4. 节点失效机制

• 一个活跃的MDS定期向monitor发送交互信息，如果一个MDS在mds_beacon_grace(默认15s)时间内没有向monitor注册，则认为该MDS失效。

5. 恢复过程

• 失效节点的相关日志被读入内存；
• 处理有争议的子树分配问题和涉及多个MDS的transaction；
• 与client重新建立会话并重新保存打开文件的状态；
• 接替失效节点的MDS加入到MDS集群的分布式缓存中

6. resolve阶段的事件

• 恢复节点向所有MDS发送一个resolve信息，该信息中包含了当前恢复节点管理的子树、在迁移过程中出现故障的子树；
• 其他正常运行的MDS也要将这些信息发送给正在恢复的MDS；
• 恢复中的MDS根据收到的子树信息重建自己缓存中的子树层次结构。

7. 重建分布式缓存和锁状态

• 恢复节点向所有MDS发送一个rejoin信息，该信息包含了恢复节点所知道的接受节点拥有的元数据副本信息并宣称自己没有管理的恢复文件；
• 原来有效的节点向恢复节点发送信息，告诉恢复节点自己拥有的元数据副本，并且向恢复节点加入锁状态
• 恢复节点将自己原本不知道的副本信息加入到自己的缓存中