Ceph 知識摘錄(常見故障、可用性測試)

高可用測試目的
爲了驗證集羣沒有單點故障，一個服務進程down 不影響業務。進程恢復後，集羣狀態正常。(穩定性、可靠性)

可用性相關設計
rgw、osd、Mon(Lead、非Lead) 節點宕機
rgw、osd、Mon 服務進程異常
rgw、osd、Mon 管理、業務、存儲網異常
ceph-rest-api
keepalived 進程異常

三副本模式下：1個PG對應的1個OSD Down
糾刪碼模式下：1個PG對應的1個OSD Down 或者2個OSD Down

Mon 對應的時鐘不一樣步

磁盤故障、更換磁盤(日誌檢查是否disk error 故障，檢查磁盤可否正常讀寫)

運維
版本升級、回退
集羣容量使用率(85%，95%)

破壞性
三副本下，一個PG對應2個Osd被stop
三副本下，一個PG對應3個Osd被stop
糾刪碼4+2，一個PG對應3個Osd被stop
網絡時延、頻繁閃斷

 

Mon節點故障處理

線上環境，Mon的個數是2n+1（n>=0）個，在線上至少3個，只要正常的節點數>=n+1，ceph的paxos算法能保證系統正常仲裁（quorum），若是ceph的Mon節點超過半數掛掉，沒法仲裁，會阻塞對集羣操做，直到超過半數Mon恢復。

解決方法:經過monmaptool導出monmap，初始化新的Mon節點。

 

數據盤替換流程

一、定位故障磁盤(SAS盤：sas2ircu/sas3ircu SATA盤：ledctl LSI-RAID卡:MegaCli64)，*物理硬盤與邏輯磁盤及掛載點的對應關係很重要*
二、中止故障OSD(停進程後,umount掛載點)
      雖然osd的服務已中止，然而他仍然被標記爲IN（集羣中）狀態。只要他的狀態仍是IN，集羣就不會爲它觸發數據恢復。默認狀況下，ceph集羣須要5分鐘來將一個DOWN狀態的磁盤標記爲OUT狀態，而後開始數據恢復。能夠手工將故障OSD標記爲OUT。一旦該OSD被標記爲OUT，ceph集羣會爲該OSD上的PG啓動恢復過程。

• 當某個PG對應的OSD set中有一個OSD被標記爲down時(假如是Primary被標記爲down，則某個Replica會成爲新的Primary，並處理全部讀寫 object請求)，則該PG處於active+degraded狀態，也就是當前PG有效的副本數是N-1。

• 過了5分鐘以後，假如仍是沒法鏈接該OSD，則它被標記爲out，Ceph會從新計算PG到OSD set的映射(當有新的OSD加入到集羣時，也會從新計算全部PG到OSD set的映射)，以此保證PG的有效副本數是N。

三、刪除故障OSD
     從ceph CRUSH map中移除
     從ceph 刪除osd祕鑰
     從ceph集羣中刪除該osd

     拔掉故障盤，插入新磁盤()

四、從新組建RAID

五、建立OSD，加入集羣(格盤、起進程、加回集羣)
      觸發backfilling操做

 

Ceph中查找一個對象的位置
一、上傳一個文件到pool（示例中叫作test）中     
rados -p  test put cirros cirros-0.3.2-x86_64-disk.img
二、查看pool中剛纔上傳的對象       
rados -p test ls | grep cirros
三、查看對象的位置信息       
ceph osd map test cirros       
輸出結果：osdmap e20062 pool 'test' (13) object 'cirros' -> pg 13.9576dc54 (13.54) -> up ([5,3], p5) acting ([5,3], p5) 
這表明pool test中的cirros這個對象位於13.54這個pg中，而且位於osd5和osd3上（兩個副本）。
四、進入到對應osd的存儲目錄，找到對應文件便可。     
cd /var/lib/ceph/osd/ceph-3/current/13.54_head; ls     
這個目錄下存放了13.54這個pg中全部的object，能夠根據指紋9576dc54來定位到具體的文件。

 

常見故障
Mon空間寫滿，集羣網絡不穩定
客戶端不能鏈接：防火牆
PG故障：擴縮容
進程是否被卡住、重啓進程

故障排查：開啓調試模式、查看日誌信息