DAOS 依靠大規模分散式單埠儲存。因此，每個 Target 實際上都是一個單獨的失敗點。
DAOS 通過在不同的容錯域中提供 Target 間的冗餘來實現資料和後設資料的可用性和永續性。DAOS 內部的 Pool 和 Container 的後設資料通過強一致性演算法進行復制。然後，通過在內部透明地利用 DAOS 分散式事務機制，DAOS 物件被安全地複製或糾刪碼編碼。本節的目的是提供有關 DAOS 如何實現容錯和保證物件彈性的詳細資訊。
分層容錯域
容錯域是一組共享同一故障點的伺服器，因此很可能同時發生故障。DAOS 假設容錯域是分層且不重疊的。實際的層次結構和容錯域成員身份必須由 DAOS 用於生成 Pool 對映的外部資料庫提供。
Pool 後設資料從不同的高階容錯域複製到多個節點上，以獲得高可用性，而物件資料則根據選定的 Object 類在不同數量的容錯域上進行復制或糾刪碼編碼。
故障檢測
DAOS 伺服器通過基於 gossip 的協議 SWIM 在 DAOS 系統中進行監控，該協議提供了準確、高效和可擴充套件的服務故障檢測。系統通過定期的本地健康評估監控附加到每個 DAOS Target 上的儲存，每當本地儲存 I/O 錯誤返回到 DAOS 伺服器時，將自動呼叫內部執行狀況檢查程式。此程式將通過分析 IO 錯誤程式碼和裝置智慧/健康資料來進行總體健康評估。如果結果是否定的，Target 將被標記為有故障的，並且到該 Target 的進一步 I/O 將被拒絕並重新路由。
故障隔離
檢測到故障後，必須從 Pool 對映中排除故障 Target 或伺服器（實際上是一組 Target）。此過程自動觸發或由管理員手動觸發。
排除後，Pool 對映的新版本將急切地推送到所有儲存 Target。此時，Pool 進入降級模式，可能需要額外的訪問處理（例如，用糾刪碼重建資料）。此時 DAOS 客戶端和儲存節點無限期地重試 RPC，直到它們從新的 Pool 對映中找到替代的 Target。此時，與被排除的 Target 的所有未完成的通訊都將中止，在 Target 重新顯式整合之前（可能僅在維護操作之後），不應再向其傳送任何訊息。
Pool 服務會立即向所有儲存 Target 通知 Pool 對映的更改。但客戶端節點不是這樣，它們每次與伺服器通訊時都會被延遲地通知 Pool 對映無效。為此，客戶端將其當前 Pool 對映版本打包到每個 RPC 中，伺服器將回復當前 Pool 對映版本。因此，當 DAOS 客戶端遇到 RPC 超時時，它會定期與其他 DAOS Target 進行通訊，以確保其 Pool 對映始終是最新的。最終，客戶端將知曉 Target 被排除並進入降級模式。
這種機制保證了全域性節點排除，並且所有節點最終共享相同的 Target 有效性檢視。
故障恢復
從 Pool 對映中排除後，每個 Target 將自動啟動重建過程以恢復資料冗餘。首先，每個 Target 建立一個受被排除的 Target 影響的本地物件列表。該列表是通過掃描由底層儲存層維護的本地物件表來完成的。然後，對於每個受影響的物件，將確定新物件分片的位置，並恢復歷史物件的冗餘（即快照）。重建所有受影響的物件後，Pool 對映將再次更新，以將 Target 報告為失敗。這標誌著集體重建過程的結束，以及此特定故障的降級模式的退出。此時，Pool 已從故障中完全恢復，客戶端節點現在可以讀取重建的物件分片。
此重建過程在應用程式持續訪問並更新物件時線上執行。
相關資訊
GitHub: https://github.com/storagezhang
Emai: debugzhang@163.com
華為雲社群: https://bbs.huaweicloud.com/blogs/254523