高可用性和高可靠性需要一種容錯方法來管理硬件和軟件問題。Ceph 沒有單點故障，並且可以以“降級”模式為數據請求提供服務。Ceph 的數據放置引入了一個間接層，以確保數據不會直接綁定到特定的 OSD 地址。這意味着跟蹤系統故障需要找到問題根源所在的歸置組和底層 OSD。
提示 集群的某一部分出現故障可能會阻止您訪問特定對象，但這並不意味着您無法訪問其他對象。當你遇到故障時，不要驚慌。只需按照步驟監控您的 OSD 和歸置組。然后，開始故障排除。
Ceph 通常是自我修復的。但是，當問題仍然存在時，監控 OSD 和歸置組將幫助您識別問題。
監控 OSD
OSD 的狀態是在集群中（in）或集群外（out）；並且，它要么啟動並運行 ( up)，要么已關閉且未運行 ( down)。如果一個 OSD 是up，它可能是in（你可以讀寫數據）或者是out的。如果是 in並且最近移動out，Ceph 會將歸置組遷移到其他 OSD。如果一個 OSD 屬於out，CRUSH 不會將歸置組分配給該 OSD。如果一個 OSD 是down，它也應該是 out。
筆記：如果 OSD 為down和in，則表示存在問題，集群將不會處於健康狀態。
如果您執行諸如ceph health、ceph -s或ceph -w之類的命令，您可能會注意到集群並不總是回顯HEALTH OK。不要驚慌。對於 OSD，您應該期望集群在一些預期的情況下不會 回 顯HEALTH OK：
1. 您尚未啟動集群（它不會響應）。
2. 您剛剛啟動或重新啟動了集群，但它還沒有准備好，因為正在創建歸置組並且 OSD 正在進行對等互連。
3. 您剛剛添加或刪除了一個 OSD。
4. 您剛剛修改了集群圖。
監控 OSD 的一個重要方面是確保當集群啟動並運行時，作為集群的所有 OSD 都在up運行並且是in的。要查看是否所有 OSD 都在運行，請執行：
ceph osd stat
結果應該告訴您 OSD 的總數 (x)、有多少up(y)、有多少in(z) 和地圖紀元 (eNNNN)。
x osds: y up, z in; epoch: eNNNN
如果in的 OSD 數量多於up的 OSD 數量，請執行以下命令來識別ceph-osd 未運行的守護進程：
ceph osd tree
#ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 2.00000 pool openstack
-3 2.00000 rack dell-2950-rack-A
-2 2.00000 host dell-2950-A1
0 ssd 1.00000 osd.0 up 1.00000 1.00000
1 ssd 1.00000 osd.1 down 1.00000 1.00000
提示：通過精心設計的 CRUSH 層次結構進行搜索的能力可以通過更快地識別物理位置來幫助您對集群進行故障排除。
如果 OSD 是down，請啟動它：
sudo systemctl start ceph-osd@1
有關與停止或不會重新啟動的 OSD 相關的問題，請參閱OSD 未運行。
PG SETS
當 CRUSH 將歸置組分配給 OSD 時，它會查看存儲池的副本數量，並將歸置組分配給 OSD，以便將歸置組的每個副本分配給不同的 OSD。例如，如果池需要一個歸置組的三個副本，CRUSH 可以將它們分別分配給 osd.1,osd.2和osd.3。CRUSH 實際上會尋找一個偽隨機放置，它會考慮您在CRUSH 映射中設置的故障域，因此您很少會看到放置組分配給大型集群中最近的鄰居 OSD。
Ceph 使用Acting Set處理客戶端請求，Acting Set是實際處理請求的 OSD 集合，因為它們具有完整且可工作的歸置組分片版本。應該包含特定歸置組的分片作為Up Set的 OSD 集，即數據被移動/復制到（或計划到）的位置。
在某些情況下，Acting Set 中的 OSD down無法為歸置組中對象的請求提供服務。當這些情況出現時，不要驚慌。常見的例子包括：
1. 您添加或刪除了 OSD。然后，CRUSH 將歸置組重新分配給其他 OSD——從而改變了 Acting Set 的組成，並通過“回填”過程產生了數據遷移。
2. 一個 OSD 曾經down，被重新啟動，現在是recovering。
3. Acting Set 中的一個 OSD 正在down或無法為請求提供服務，而另一個 OSD 暫時承擔了其職責。
在大多數情況下，Up Set 和 Acting Set 是相同的。如果不是，則可能表明 Ceph 正在遷移 PG（它已重新映射）、OSD 正在恢復或存在問題（即，Ceph 通常會回顯“HEALTH WARN”狀態並在這樣的場景）。
要檢索歸置組列表，請執行：
ceph pg dump
要查看給定歸置組的 Acting Set 或 Up Set 中的 OSD，請執行：
ceph pg map {pg-num}
結果應該告訴你 osdmap epoch (eNNN)、歸置組編號 ({pg-num})、Up Set 中的 OSD (up[]) 和 Acting Set 中的 OSD (acting[])。
osdmap eNNN pg {raw-pg-num} ({pg-num}) -> up [0,1,2] acting [0,1,2]
筆記：如果 Up Set 和 Acting Set 不匹配，這可能是集群重新平衡自身或集群潛在問題的指標。
PEERING
在您可以將數據寫入歸置組之前，它必須處於一種active 狀態，並且它 應該處於一種clean狀態。為了讓 Ceph 確定一個歸置組的當前狀態，該歸置組的主 OSD（即Acting Set中的第一個 OSD）、與輔助和第三 OSD 對等以就歸置組的當前狀態建立協議（假設一個池有 3 個 PG 副本）。
OSD 還向MON報告其狀態。有關詳細信息，請參閱配置MON/OSD 交互。要解決對等互連問題，請參閱對等互連故障。
監控PG（歸置組）狀態
如果您執行諸如ceph health、ceph -s或ceph -w之類的命令，您可能會注意到集群並不總是回顯HEALTH OK。檢查 OSD 是否正在運行后，您還應該檢查歸置組狀態。您應該期望集群不會在許多與歸置組對等相關的情況下回顯HEALTH OK：
1. 您剛剛創建了一個池，而歸置組尚未對等。
2. 歸置組正在恢復。
3. 您剛剛在集群中添加了一個 OSD 或從集群中刪除了一個 OSD。
4. 您剛剛修改了 CRUSH 地圖，並且您的歸置組正在遷移。
5. 一個歸置組的不同副本中存在不一致的數據。
6. Ceph 正在清理歸置組的副本。
7. Ceph 沒有足夠的存儲容量來完成回填操作。
如果上述情況之一導致 Ceph 回顯HEALTH WARN，請不要驚慌。在許多情況下，集群會自行恢復。在某些情況下，您可能需要采取行動。監控歸置組的一個重要方面是確保當集群啟動並運行時，所有歸置組都處於 active，並且最好處於 clean 狀態。要查看所有歸置組的狀態，請執行：
ceph pg stat
結果應該告訴您歸置組的總數 (x)、有多少歸置組處於特定狀態，例如active+clean(y) 以及存儲的數據量 (z)。
x pgs: y active+clean; z bytes data, aa MB used, bb GB / cc GB avail
筆記：Ceph 報告歸置組的多個狀態是很常見的。
除了歸置組狀態，Ceph 還會回顯已使用的存儲容量 (aa)、剩余存儲容量 (bb) 以及歸置組的總存儲容量（cc）。這些數字在某些情況下可能很重要：
- 您正在達到您的near full ratio或full ratio。
- 由於 CRUSH 配置中的錯誤，您的數據沒有在集群中分布。
**Placement Group IDs**
歸置組 ID 由后跟一個句點 (.) 的池編號（不是池名稱）和歸置組 ID（一個十六進制數字）組成。您可以從 ceph osd lspools的輸出中查看池編號及其名稱。例如，創建的第一個池對應於 pool number 1。完全合格的歸置組 ID 具有以下形式：
{pool-num}.{pg-id}
它通常看起來像這樣：
1.1f
要檢索歸置組列表，請執行以下操作：
ceph pg dump
您還可以將輸出格式化為 JSON 格式並將其保存到文件中：
ceph pg dump -o {filename} --format=json
要查詢特定的歸置組，請執行以下命令：
ceph pg {poolnum}.{pg-id} query
Ceph 將以 JSON 格式輸出查詢。
以下小節詳細描述了常見的 pg 狀態。
CREATING
創建池時，它將創建您指定數量的歸置組。Ceph在創建一個或多個歸置組時會回顯creating。一旦它們被創建，作為歸置組Acting Set一部分的 OSD 就會對等。對等連接完成后，歸置組狀態應為active+clean，這意味着 Ceph 客戶端可以開始寫入歸置組。
PEERING
當 Ceph 與歸置組建立 Peering 時，Ceph 使存儲歸置組副本的 OSD 就歸置組 中對象和元數據的狀態達成一致。當 Ceph 完成對等互連時，這意味着存儲該歸置組的 OSD 就該歸置組的當前狀態達成一致。但是，對等過程的完成並不意味着每個副本都有最新的內容。
**Authoritative History**
Ceph 不會向客戶端確認寫操作，直到Acting Set的所有 OSD 都堅持寫操作。這種做法確保了Acting Set的至少一個成員將擁有自上次成功的對等操作以來每個確認的寫操作的記錄。
通過准確記錄每個已確認的寫入操作，Ceph 可以構建和傳播新的歸置組權威歷史記錄——一組完整且完全有序的操作，如果執行這些操作，將使 OSD 的歸置組副本保持最新.
ACTIVE
一旦 Ceph 完成對等過程，一個歸置組可能會變成 active. active狀態是指歸置組中的數據在主歸置組和副本中普遍可用，可進行讀寫操作。
CLEAN
當歸置組處於該clean狀態時，主 OSD 和副本 OSD 已成功對等，並且該歸置組沒有雜散副本。Ceph 將歸置組中的所有對象復制了正確的次數。
DEGRADED
當客戶端將對象寫入主 OSD 時，主 OSD 負責將副本寫入副本 OSD。主 OSD 將對象寫入存儲后，歸置組將保持degraded 狀態，直到主 OSD 收到來自副本 OSD 的 Ceph 成功創建副本對象的確認。
一個歸置組active+degraded的原因是一個 OSD 可能 active即使它還沒有保存所有的對象。如果某個 OSD 發生 down故障，Ceph 會將分配給該 OSD 的每個歸置組標記為degraded. 當 OSD 重新聯機時，OSD 必須再次對等。但是，客戶端仍然可以將新對象寫入degraded歸置組（如果它是active）。
如果一個 OSD 是down並且degraded條件持續存在，Ceph 可能會將 down OSD 標記為out，並將數據從down OSD 重新映射到另一個 OSD。被標記down和被標記out之間的時間由 mon osd down out interval 控制，默認設置為600秒。
歸置組也可以是degraded，因為 Ceph 找不到 Ceph 認為應該在歸置組中的一個或多個對象。雖然您無法讀取或寫入未找到的對象，但您仍然可以訪問degraded置放群組中的所有其他對象。
RECOVERING
Ceph 設計用於在硬件和軟件問題持續存在的規模上進行容錯。當一個 OSD 過去down時，它的內容可能落后於歸置組中其他副本的當前狀態。當 OSD 返回up時，必須更新歸置組的內容以反映當前狀態。在那個時間段內，OSD 可能會反映一個recovering 狀態。
恢復並不總是微不足道的，因為硬件故障可能會導致多個 OSD 的級聯故障。例如，機架或機櫃的網絡交換機可能發生故障，這可能導致許多主機的 OSD 落后於集群的當前狀態。一旦故障解決，每個 OSD 都必須恢復。
Ceph 提供了許多設置來平衡新服務請求之間的資源爭用以及恢復數據對象和將歸置組恢復到當前狀態的需要。該osd recovery delay start設置允許 OSD 在開始恢復過程之前重新啟動、重新對等甚至處理一些重播請求。osd recovery thread timeout設置線程超時，因為多個 OSD 可能會以交錯的速率發生故障、重新啟動和重新對等。該osd recovery max active設置限制了 OSD 將同時處理的恢復請求的數量，以防止 OSD 無法服務。該osd recovery max chunk設置限制了恢復的數據塊的大小，以防止網絡擁塞。
BACK FILLING
當有新的 OSD 加入集群時，CRUSH 會將集群中 OSD 的歸置組重新分配給新添加的 OSD。強制新 OSD 立即接受重新分配的歸置組可能會給新 OSD 帶來過多的負載。使用歸置組回填 OSD 允許此過程在后台開始。回填完成后，新的 OSD 將在准備好后開始為請求提供服務。
在回填操作期間，您可能會看到以下幾種狀態之一： backfill_wait表示回填操作處於掛起狀態，但尚未進行；backfilling表示正在進行回填操作；並且，backfill_toofull表示已請求回填操作，但由於存儲容量不足而無法完成。當一個歸置組不能回填時，可以考慮incomplete。
該backfill_toofull狀態可能是暫時的。隨着 PG 的移動，空間可能會變得可用。backfill_toofull類似於backfill_wait只要條件改變回填就可以進行。
Ceph 提供了許多設置來管理與將歸置組重新分配給 OSD（尤其是新 OSD）相關的負載峰值。默認情況下， osd_max_backfills將進出 OSD 的最大並發回填數設置為 1。如果 OSD 接近其滿載率backfill full ratio（默認為 90%）並隨命令ceph osd set-backfillfull-ratio更改，這將使 OSD 拒絕回填請求。如果 OSD 拒絕回填請求，則 osd backfill retry interval允許 OSD 重試請求（默認為 30 秒后）。OSD 還可以設置osd backfill scan min和osd backfill scan max 管理掃描間隔（默認為 64 和 512）。
REMAPPED
當為歸置組服務的 Acting Set發生變化時，數據會從舊 Acting Set遷移到新 Acting Set。新的主 OSD 可能需要一些時間來處理請求。因此它可能會要求舊的主節點繼續為請求提供服務，直到歸置組遷移完成。數據遷移完成后，映射將使用新 Acting Set的主 OSD。
STALE
雖然 Ceph 使用心跳來確保主機和守護進程正在運行，但 ceph-osd守護進程也可能會進入一種stuck無法及時報告統計信息的狀態（例如，臨時網絡故障）。默認情況下，OSD 守護進程每半秒（即0.5）報告其歸置組、up through、引導和故障統計信息，這比心跳閾值更頻繁。如果某個歸置組的acting set的主 OSD沒有向MON報告，或者如果其他 OSD 已經報告了主 OSD down，MON將標記該歸置組stale。
啟動集群時，通常會在對等進程完成之前看到stale狀態。在集群運行一段時間后，看到歸置組stale狀態表明這些歸置組的主 OSD down是否正在向MON報告歸置組統計信息。
識別有問題的 PG
如前所述，一個歸置組不一定因為它的狀態不是active+clean. 通常，當歸置組卡住時，Ceph 的自我修復能力可能無法正常工作。卡住狀態包括：
- Unclean：置放群組包含未按所需次數復制的對象。他們應該正在康復。
- Inactive：歸置組無法處理讀取或寫入，因為它們正在等待具有最新數據的 OSD up回來。
- Stale：歸置組處於未知狀態，因為托管它們的 OSD 有一段時間沒有向監控集群報告（由 mon osd report timeout配置）。
要識別卡住的歸置組，請執行以下操作：
ceph pg dump_stuck [unclean|inactive|stale|undersized|degraded]
有關更多詳細信息，請參閱歸置組子系統。要排查卡住的置放群組，請參閱排查 PG 錯誤。
查找對象位置
要將對象數據存儲在 Ceph 對象存儲中，Ceph 客戶端必須：
- 設置對象名稱
- 指定一個池
Ceph 客戶端獲取最新的集群映射，CRUSH 算法計算如何將對象映射到歸置組，然后計算如何將歸置組動態分配給 OSD。要查找對象位置，您只需要對象名稱和池名稱即可。例如：
ceph osd map {poolname} {object-name} [namespace]
練習：定位對象
作為練習，讓我們創建一個對象。使用命令行上的rados put命令指定對象名稱、包含一些對象數據的測試文件的路徑和池名稱 。例如：
rados put {object-name} {file-path} --pool=data
rados put test-object-1 testfile.txt --pool=data
要驗證 Ceph 對象存儲是否存儲了對象，請執行以下命令：
rados -p data ls
現在，確定對象位置：
ceph osd map {pool-name} {object-name}
ceph osd map data test-object-1
Ceph 應該輸出對象的位置。例如：
osdmap e537 pool 'data' (1) object 'test-object-1' -> pg 1.d1743484 (1.4) -> up ([0,1], p0) acting ([0,1], p0)
要刪除測試對象，只需使用rados rm命令將其刪除。例如：
rados rm test-object-1 --pool=data
隨着集群的發展，對象位置可能會動態變化。Ceph 動態再平衡的一個好處是，Ceph 使您不必手動執行遷移。有關詳細信息，請參閱架構部分。