一次ceph心跳機制異常的處理

部署使用ceph集羣的時候遇到一個狀況，在大規模集羣的時候，有節點網絡或者osd異常時，mon遲遲不把該異常的osd標down，一直等待900s後mon發現該節點的osd一直沒有更新pgmap才把異常的osd標down，並更新osdmap擴散出去。

現象：部署使用ceph集羣的時候遇到一個狀況，在大規模集羣的時候，有節點網絡或者osd異常時，mon遲遲不把該異常的osd標down，一直等待900s後mon發現該節點的osd一直沒有更新pgmap才把異常的osd標down，並更新osdmap擴散出去。但這個900s內，客戶端IO仍是會一直往異常的osd上去下發，致使io超時，並進一步影響上次的業務。

緣由分析：

咱們在mon的日誌裏面也看到了和異常osd創建心跳的其餘osd向mon報告該osd的異常，但mon確實在短期內沒有這些osd標down。查看了一些相關網絡和書籍的資料後，才發現了問題。
首先咱們關注osd配置中幾個相關的配置項：
（1）osd_heartbeat_min_peers:10
（2）mon_osd_min_down_reporters:2
（3）mon_osd_min_down_reporters_ratio:0.5
以上參數的之均可以在ceph集羣節點上執行ceph daemon osd.x config show查看（x是你的集羣osd的id）。
問題出現的緣由是什麼呢？
問題現場的集羣部署時每一個osd會隨機選取10個peer osd來做爲創建心跳的對象，但在ceph的機制中，這個10個osd不必定保證可以所有分散在不一樣的節點上。故在有osd異常的時候，向mon報該osd down的reporter有機率不知足ratio=0.5，即reporter數量未過集羣存儲host數量的一半，這樣異常osd就沒法經過osd之間的心跳報活機制快速標down，直到900s後mon發現這個osd pgmap一直不更新才識別到異常（另外一種機制，能夠看作是給osd心跳保活機制作最後的保險），並經過osdmap擴散出來。而這個900s對於上層業務來講，每每是不可接受的。
但這個現象對於小規模集羣幾乎不會出現，好比以一個3節點ceph集羣爲例：

若是與其餘節點osd創建的peer數量小於了osd_heartbeat_min_peers，那麼osd會繼續選擇與本身較近的osd創建心跳鏈接（即便是和本身位於同一個節點上。）
對於osd心跳機制，網上有人總結過幾點要求：
（1）及時：創建心跳的osd能夠在秒級發現其餘osd的異常並上報monitor，monitor在幾分鐘內把該osd標down下線
（2）適當的壓力：不要覺得peer越多越好，特別是如今實際應用場景中osd監聽和發送心跳報文的網絡鏈路都是和public network以及cluster network共用的，心跳鏈接創建過多會極大影響系統的性能。Mon有單獨與osd維持心跳的方式，但ceph經過osd之間的心跳保活，將這種壓力分散到各個osd上，極大減少了中心節點mon的壓力。

（3）容忍網絡抖動：mon收集到osd的彙報以後，會通過週期的等待幾個條件，而不是貿然把osd標down。這些條件有目標osd的實效時間大於經過固定量osd_heartbeat_grace和歷史網絡條件肯定的閾值，以及上報的主機數是否達到min_reporters和min_reporters_ratio，以及在必定時間內，失效彙報沒有被源報告者取消掉等。
（4）擴散機制：2種實現，mon主動擴散osdmap，還有一種惰性的是osd和client本身來取。爲了讓異常信息及時讓client和其餘osd感知到，通常是前一種實現比較好。

總結和啓示：

2個方向能夠作出改變。
（1）對於原有機制中取集羣存儲節點數量的0.5做爲min_reporter_ratio明顯不合理，應該採用的是這個osd與多少host上的osd創建心跳（取host數量），那就由0.5*創建心跳的host總數來做爲判斷依據。
（2）一些場景下，咱們會本身定義一些數據存放的邏輯區域，經過對crush的層級結構的利用，例如在一個ceph集羣中定義多個邏輯區域，一個數據的分片或者副本只存在於一個邏輯區域中，那相關osd創建心跳鏈接的範圍就須要相應精簡和準確。

如今ceph實現的osd心跳機制仍是會有不少問題，不知道後面會不會有新的機制替換當前機制，讓咱們拭目以待。