回到最初的Ceph運維工程師的問題，本系列講述的是傳統運維向新一代雲運維轉型之軟體定義存儲部分的轉型，運維是企業業務系統從規劃、設計、實施、傳遞到運維的最後一個步驟，也是重要的步驟。運維小哥最初的夢想搭建一個Ceph存儲叢集，對接雲服務，底層存儲實作高可用的資料通路架構。其中運維小哥經曆了硬體選型、部署、調優、測試、高可用架構設計等的一系列轉型的關卡學習，終于就要到最後的應用上線了。但是往往在生産環境中除了無單點、高可用的架構設計之外還需要平時做一些預案演練，比如：伺服器斷電、拔磁盤等問題，避免出現災難故障影響業務正常運作。
Ceph運維常用指令
1、檢視Ceph叢集的狀态
[root@node1 ~]# ceph health
2、檢視Ceph的實時運作狀态
[root@node1 ~]# ceph -w
3、檢查資訊狀态資訊
[root@node1 ~]# ceph -s
5、檢視ceph存儲空間
[root@node1 ~]# ceph df
1、檢視mon的狀态資訊
[root@@node1 ~]# ceph mon stat
2、檢視mon的選舉狀态
[root@@node1 ~]# ceph quorum_status
3、删除一個mon節點
[root@node1 ~]# ceph mon remove node1
1、檢視ceph osd運作狀态
[root@node1 ~]# ceph osd stat
2、檢視osd映射資訊&并從中可以得知副本數、pg數等等
[root@node1 ~]# ceph osd dump
3、檢視osd的目錄樹
[root@node1 ~]# ceph osd tree
4、在叢集中删除一個osd的host節點
[root@node1 ~]# ceph osd crush rm node2
5、把一個osd節點逐出叢集
[root@node1 ~]# ceph osd out osd.3
6、把逐出的osd加入叢集
[root@node1 ~]# ceph osd in osd.3
1、檢視pg組的映射資訊
[root@node1 ~]# ceph pg dump
#其中的[A,B]代表存儲在osd.A、osd.B節點，osd.A代表主副本的存儲位置
2、檢視PG狀态
[root@node1 ~]# ceph pg stat
3、查詢一個pg的詳細資訊
[root@node1 ~]# ceph pg 0.26 query
4、檢視pg中stuck的狀态
[root@node1 ~]# ceph pg dump_stuck unclean
[root@node1 ~]# ceph pg dump_stuck inactive
[root@node1 ~]# ceph pg dump_stuck stale
5、恢複一個丢失的pg
[root@node1 ~]# ceph pg {pg-id} mark_unfound_lost revert
1、檢視ceph叢集中的pool數量
[root@node1 ~]# ceph osd lspools
2、在ceph叢集中建立一個pool
[root@node1 ~]# ceph osd pool create devin 100
#這裡的100指的是PG組
3、在叢集中删除一個pool
[root@node1 ~]# ceph osd pool delete devin devin –yes-i-really-really-mean-it #叢集名字需要重複兩次
技能描述：
由于原叢集存儲空間不足或某種原因需要擴充叢集，本技能主要是添加OSD節點和MON節點。
1.給新增OSD節點進行配置hosts檔案
2.配置yum源
3.設定免密碼登入
4.在admin節點開始進行安裝
5.blabla….
有沒有覺得上面操作很熟悉，是的沒錯，跟開始安裝Ceph的時候步驟是一樣的。
唯一需要注意的就是，安裝完之後需要更新Crush Map資訊。例如：
root@lnode1 ~# ceph osd crush add-bucket node4 host
root@node1 ~# ceph osd crush move node4 root=default
root@node1 ~# ceph osd crush add osd.$i 1.0 host=node4
#标注此處osd.$i的$i代表osd序号，1.0代表osd的權重
具體操作可以檢視官網，這裡就不在贅述了。
随着叢集和磁盤的增多會給運維帶來很多煩惱和壓力，本技能主要是易于管理磁盤和叢集。
1.利用udev增強對Ceph儲存設備的有效管理
預設情況下磁盤可以使用by-id/by-partlabel/by-parttypeuuid/by-partuuid/by-path/by-uuid等多種形式的名稱對磁盤裝置進行管理，但是在Ceph中，如果磁盤數量過多，加上為了更好差別每一個OSD對應的磁盤分區用途（比如filestore or journal），同時確定實體磁盤發生變更（故障盤替換後）後對應的名稱不變，對OSD對應的磁盤裝置命名提出新的管理需求。
2.OSD狀态管理
這裡簡單講述下OSD的各個狀态，OSD狀态的描述分為兩個次元：up或者down（表明OSD是否正常工作），in或者out（表明OSD是否在至少一個PG中）。是以，對于任意一個OSD，共有四種可能的狀态：
—— Up且in：說明該OSD正常運作，且已經承載至少一個PG的資料。這是一個OSD的标準工作狀态；
—— Up且out：說明該OSD正常運作，但并未承載任何PG，其中也沒有資料。一個新的OSD剛剛被加入Ceph叢集後，便會處于這一狀态。而一個出現故障的OSD被修複後，重新加入Ceph叢集時，也是處于這一狀态；
—— Down且in：說明該OSD發生異常，但仍然承載着至少一個PG，其中仍然存儲着資料。這種狀态下的OSD剛剛被發現存在異常，可能仍能恢複正常，也可能會徹底無法工作；
—— Down且out：說明該OSD已經徹底發生故障，且已經不再承載任何PG。
3.時間同步
不同節點間時鐘應該同步，否則一些逾時和時間戳相關的機制将無法正确運作，Ceph也會報出時鐘偏移警告等，是以在開始之前我一直強調要安裝NTP來同步時鐘。
任何一個軟體都無法回避的一個問題，監控是運維人員必備的技能，可以随時掌握系統是否出現問題，以及如何定位問題。本技能主要是叢集方面的監控。
1.叢集監控狀态
2.檢視Ceph的實時運作狀态
3.blabla…
這些指令我在文章開始就已經講述了，這裡不再贅述。
下面說下監控軟體，目前主流的Ceph開源監控軟體有：Calamari、VSM、Inkscope、Ceph-Dash、Zabbix等，下面簡單介紹下各個開源元件。
Calamari對外提供了十分漂亮的Web管理和監控界面，以及一套改進的REST API接口（不同于Ceph自身的REST API），在一定程度上簡化了Ceph的管理。最初Calamari是作為Inktank公司的Ceph企業級商業産品來銷售，紅帽2015年收購 Inktank後為了更好地推動Ceph的發展，對外宣布Calamari開源，秉承開源開放精神的紅帽着實又做了一件非常有意義的事情。
優點：
q 輕量級
q 官方化
q 界面友好
缺點：
q 不易安裝
q 管理功能滞後
Virtual Storage Manager (VSM)是Intel公司研發并且開源的一款Ceph叢集管理和監控軟體，簡化了一些Ceph叢集部署的一些步驟，可以簡單的通過WEB頁面來操作。
q 管理功能好
q 可以利用它來部署Ceph和監控Ceph
q 非官方
q 依賴OpenStack某些包
Inkscope 是一個 Ceph 的管理和監控系統，依賴于 Ceph 提供的 API，使用 MongoDB 來存儲實時的監控資料和曆史資訊。
q 易部署
q 靈活（可以自定義開發功能）
q 監控選項少
q 缺乏Ceph管理功能
Ceph-Dash 是用 Python 開發的一個Ceph的監控面闆，用來監控 Ceph 的運作狀态。同時提供 REST API 來通路狀态資料。
ZABBIX的Ceph插件可以在github上查找“Ceph-zabbix”
借用Ceph中國社群群友的截圖，出現以下問題”error connecting to the cluster”一般都是因為Ceph叢集節點時間、網絡、Key等問題。
解決辦法：
調整叢集節點時間或提前設定好NTP服務，檢視節點網絡通信、網卡等是否有問題以及Ceph的Key。
機器更換IP位址重新開機後，Ceph mon程序出現異常，無法啟動
很多新手在 初次搭建Ceph叢集環境時，由于限于節點數和OSD資源的限制，叢集狀态未能達到完全收斂狀态，即所有PG保持active+clean。排除OSD故障原因，此類問題，主要還是crush rule 耍了小把戲，隻要我們看清本質，Ceph就服帖了。
因為預設的Crush Rule 設定的隔離是host 級，即多副本（如3副本）情況下，每一副本都必須分布在不同的節點上。如此一來，當節點數不滿足大于或等于副本數時，PG的狀态自然就不能 active+clean ，而會顯示為“degraded”（降級）狀态。
解決這個問題，可以從兩方面入手：一是修改副本數，二是修改Crush Rule。
1.通過tell 指令線上修pool的副本數，并修改配置檔案且同步到所有節點。 #保險起見，最好把MON和OSD關于副本數的選項都修改。
2. 修改預設crush rule，把隔離域換成 OSD。 #也就是Crush Map裡面的rules選項。
好了，最後一篇文章到此結束，在本系列開頭講到随着雲計算、大資料以及新興的區塊鍊等技術體系的迅猛發展，資料中心的擴容建設進入高峰期，雲資料中心運維需求應運而生。傳統的運維人員，以往接觸的更多是硬體，如伺服器、裝置和風火水電；但是在雲資料中心時代，運維人員已經從面向實體裝置，轉變為面向虛拟化、雲的管理方式。
是以，雲資料中心的運維對于傳統的運維人員提出了新的能力要求——不僅要熟悉傳統硬體裝置，同時要掌握虛拟化、雲系統的部署、監控和管理等運維能力。
通過九篇文章簡單介紹了下傳統運維向雲運維或者說是傳統運維向SDS運維的轉型之路。文章涉及的比較基礎，主要講述了 一般企業使用Ceph經曆幾個難度關卡：硬體選型–>部署調優–>性能測試–>架構災備設計–>部分業務上線測試–>運作維護（故障處理、預案演練等），加上作者水準有限，希望本系列文章能夠給予Ceph新手參考。
本文轉自Devin 51CTO部落格，原文連結:http://blog.51cto.com/devingeng/1884398