MDS 介绍

文章目录

1. 1. 1. mds 存储
2. 2. 2. mds 冷备/热备
3. 3. 3. mds 主备切换策略
4. 4. 4. 节点失效机制
5. 5. 5. 恢复过程
6. 6. 6. resolve 阶段的事件
7. 7. 7. 重建分布式缓存和锁状态

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