1. 問題：

ceph集群警告信息如下：

ceph -s
health HEALTH_WARN
mds0: Client xxx-online00.gz01 failing to respond to cache pressure

2. 分析問題過程

2.1 官方解釋

2.2 查看客戶端session

$ ceph daemon mds.ceph-epnfs-mds01.gz01 session ls
[
    {
        "id": 4746087,
        "num_leases": 9,
        "num_caps": 57368,
        "state": "open",
        "replay_requests": 0,
        "completed_requests": 1,
        "reconnecting": false,
        "inst": "client.4746087 10.1.7.1:0\/1700679012",
        "client_metadata": {
            "entity_id": "admin",
            "hostname": "test-hostname00",
            "kernel_version": "3.10.0-514.16.1.el7.x86_64"
        }
    }
]

2.3 查看客戶端inode

跟蹤代碼發(fā)現(xiàn)num_caps就是統(tǒng)計(jì)的客戶端的inode數(shù)量, 大概統(tǒng)計(jì)了下已經(jīng)打開的inode數(shù)量酒繁。

image.png

2.4 嘗試mds主從切換

2.4.1 執(zhí)行過程如下

主從切換流程：

• handle_mds_map state change up:boot --> up:replay
• handle_mds_map state change up:replay --> up:reconnect
• handle_mds_map state change up:reconnect --> up:rejoin
• handle_mds_map state change up:rejoin --> up:active

2.5. 主從mds切換結(jié)論

成功切換主從角色

2.6. 主從mds切換問題

• mds在切換過程中滓彰，導(dǎo)致繁忙cpu很高捉蚤，在mds_beacon_grace(默認(rèn)15s)時(shí)間內(nèi)沒有向monitor注冊猴贰，沒有及時(shí)匯報(bào)心跳給mon，導(dǎo)致mds自殺婚被。
• mds主從切換open inode并沒有釋放

3. 深入問題分析

3.1 mds切換過程導(dǎo)致mds自殺

問題：mds在切換過程中稳析，導(dǎo)致繁忙cpu很高洗做，在mds_beacon_grace(默認(rèn)15s)時(shí)間內(nèi)沒有向monitor注冊，沒有及時(shí)匯報(bào)心跳給mon彰居，導(dǎo)致mds自殺诚纸。

mds存儲：

• 元數(shù)據(jù)的內(nèi)存緩存，為了加快元數(shù)據(jù)的訪問陈惰。
• 保存了文件系統(tǒng)的元數(shù)據(jù)(對象里保存了子目錄和子文件的名稱和inode編號)
• 還保存cephfs日志journal畦徘，日志是用來恢復(fù)mds里的元數(shù)據(jù)緩存
• 重啟mds的時(shí)候會(huì)通過replay的方式從osd上加載之前緩存的元數(shù)據(jù)

mds冷備/熱備：

• 冷備就是備份的mds，只起到一個(gè)進(jìn)程備份的作用抬闯，并不備份lru元數(shù)據(jù)井辆。主備進(jìn)程保持心跳關(guān)系，一旦主的mds掛了溶握，備份mds replay()元數(shù)據(jù)到緩存杯缺，當(dāng)然這需要消耗一點(diǎn)時(shí)間。
• 熱備除了進(jìn)程備份睡榆，元數(shù)據(jù)緩存還時(shí)時(shí)刻刻的與主mds保持同步萍肆，當(dāng) active mds掛掉后袍榆，熱備的mds直接變成主mds，并且沒有replay()的操作塘揣，元數(shù)據(jù)緩存大小和主mds保持一致包雀。
  說明：
  • rejoin把客戶端的inode加載到mds cache
  • replay把從cephfs的journal恢復(fù)內(nèi)存

mds主備切換策略：

• 默認(rèn)每個(gè)standby都一樣
• 指定后補(bǔ)
  • mds standby for name指定一 MDS 守護(hù)進(jìn)程的名字，此進(jìn)程將作為它的候補(bǔ)
  • mds standby for rank此 MDS 將作為本機(jī)架上 MDS 守護(hù)進(jìn)程的候補(bǔ)
• 優(yōu)先級最高standby replay

節(jié)點(diǎn)失效機(jī)制：

• 一個(gè)活躍的MDS定期向monitor發(fā)送交互信息亲铡，如果一個(gè)MDS在mds_beacon_grace(默認(rèn)15s)時(shí)間內(nèi)沒有向monitor注冊才写，則認(rèn)為該MDS失效。

恢復(fù)過程：

• 失效節(jié)點(diǎn)的相關(guān)日志被讀入內(nèi)存奖蔓；
• 處理有爭議的子樹分配問題和涉及多個(gè)MDS的transaction赞草；
• 與client重新建立會(huì)話并重新保存打開文件的狀態(tài)；
• 接替失效節(jié)點(diǎn)的MDS加入到MDS集群的分布式緩存中

resolve階段的事件：

• 恢復(fù)節(jié)點(diǎn)向所有MDS發(fā)送一個(gè)resolve信息锭硼，該信息中包含了當(dāng)前恢復(fù)節(jié)點(diǎn)管理的子樹房资、在遷移過程中出現(xiàn)故障的子樹蜕劝；
• 其他正常運(yùn)行的MDS也要將這些信息發(fā)送給正在恢復(fù)的MDS檀头；
• 恢復(fù)中的MDS根據(jù)收到的子樹信息重建自己緩存中的子樹層次結(jié)構(gòu)。

重建分布式緩存和鎖狀態(tài)：

• 恢復(fù)節(jié)點(diǎn)向所有MDS發(fā)送一個(gè)rejoin信息岖沛，該信息包含了恢復(fù)節(jié)點(diǎn)所知道的接受節(jié)點(diǎn)擁有的元數(shù)據(jù)副本信息并宣稱自己沒有管理的恢復(fù)文件暑始；
• 原來有效的節(jié)點(diǎn)向恢復(fù)節(jié)點(diǎn)發(fā)送信息，告訴恢復(fù)節(jié)點(diǎn)自己擁有的元數(shù)據(jù)副本婴削，并且向恢復(fù)節(jié)點(diǎn)加入鎖狀態(tài)
• 恢復(fù)節(jié)點(diǎn)將自己原本不知道的副本信息加入到自己的緩存中

為啥mds切換導(dǎo)致cpu高廊镜？

• 1. 分析日志(發(fā)現(xiàn)執(zhí)行rejoin_start動(dòng)作只會(huì)就超時(shí))

2018-04-27 19:12:21.909280 7f8268805700 1 mds.0.2665 rejoin_start
2018-04-27 19:12:37.294438 7f826a809700 1 heartbeat_map is_healthy 'MDSRank' had timed out after 15
2018-04-27 19:12:40.961787 7f82656fe700 1 heartbeat_map is_healthy 'MDSRank' had timed out after 15
2018-04-27 19:12:40.961796 7f82656fe700 1 mds.beacon.ceph-xxx-mds01.gz01 _send skipping beacon, heartbeat map not healthy
2018-04-27 19:12:42.294507 7f826a809700 1 heartbeat_map is_healthy 'MDSRank' had timed out after 15

• 2.跟蹤代碼分析(在執(zhí)行process_imported_caps超時(shí)了， 這個(gè)函數(shù)主要是打開inodes 加載到cache中)

  
  
  image.png
• 3. 跟蹤官方bug列表發(fā)現(xiàn)補(bǔ)丁(解決主從mds切換超時(shí)自殺, 以及merge到目標(biāo)版本13.0.0) https://github.com/ceph/ceph/pull/21144
     
     image.png

• 4.跟蹤補(bǔ)丁代碼分析(inode到了1000個(gè)唉俗，mds 心跳reset, 禁止自殺行為)

  
  
  image.png
  
  
  image.png

3.2 mds主從切換open inode沒有釋放

問題：mds主從切換open inode沒有釋放嗤朴，mds集群顯示mds0: Client xxx-online00.gz01 failing to respond to cache pressure
解決方式：(由于inode都緩存在client端,所以必須的想辦法釋放inode)

• 方案1：evict client(主動(dòng)踢出有問題的客戶端)
• 方案2：client remount(有問題的客戶端重新mount掛載)
• 方案3：drop_cache(官方提供的mds 主動(dòng)刪除cache，補(bǔ)丁在review過程中個(gè)虫溜，目標(biāo)版本是ceph-14.0.0) https://github.com/ceph/ceph/pull/21566
  
  image.png