标签：缓存 恢复 ceph 子树 mds MDS 节点 分布式

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

标签：缓存,恢复,ceph,子树,mds,MDS,节点,分布式
来源： https://blog.51cto.com/u_15174006/2718958

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。