高可用性和高可靠性需要一種容錯方法來管理硬體和軟體問題。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 客戶端必須：

1. 設定物件名稱
2. 指定一個池

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 使您不必手動執行遷移。有關詳細資訊，請參閱架構部分。