高可用測試目的
為了驗證集群沒有單點故障，一個服務進程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節點。
數據盤替換流程
1、定位故障磁盤(SAS盤：sas2ircu/sas3ircu SATA盤：ledctl LSI-RAID卡:MegaCli64)，*物理硬盤與邏輯磁盤及掛載點的對應關系很重要*
2、停止故障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。
3、刪除故障OSD
從ceph CRUSH map中移除
從ceph 刪除osd秘鑰
從ceph集群中刪除該osd
拔掉故障盤，插入新磁盤()
4、重新組建RAID
5、創建OSD，加入集群(格盤、起進程、加回集群)
觸發backfilling操作
Ceph中查找一個對象的位置
1、上傳一個文件到pool（示例中叫做test）中
rados -p test put cirros cirros-0.3.2-x86_64-disk.img
2、查看pool中剛才上傳的對象
rados -p test ls | grep cirros
3、查看對象的位置信息
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上（兩個副本）。
4、進入到對應osd的存儲目錄，找到對應文件即可。
cd /var/lib/ceph/osd/ceph-3/current/13.54_head; ls
這個目錄下存放了13.54這個pg中所有的object，可以根據指紋9576dc54來定位到具體的文件。
常見故障
Mon空間寫滿，集群網絡不穩定
客戶端不能連接：防火牆
PG故障：擴縮容
進程是否被卡住、重啟進程
故障排查：開啟調試模式、查看日志信息