存儲分布式文件系統(tǒng)對象存儲后端高可用【免費下載鏈接】cephCeph is a distributed object, block, and file storage platform項目地址https://gitcode.com/gh_mirrors/ce/ceph點擊查看免費下載Ceph 的 ECErasure Coding糾刪碼后端ECBackend承載了糾刪碼存儲池在主 OSD 上的全部數(shù)據(jù)讀寫邏輯。本文以 ecbackend.rst 為核心結(jié)合 src/osd/ECBackend.h、src/osd/ECCommon.h、src/osd/ECExtentCache.h 等源碼實現(xiàn)系統(tǒng)講解 EC 池的操作約束、shard 尋址模型、整條帶寫與讀改寫RMW兩條數(shù)據(jù)流、兩階段提交與回滾機制以及 ExtentCache 與 RMW 管線的并發(fā)控制。讀完本文你將理解 ECBackend 為什么不能像復(fù)制后端那樣自由覆蓋寫也能掌握其寫入管線在源碼中的完整落地形態(tài)。一、設(shè)計背景EC 池最初只允許可回滾的操作與復(fù)制replicated策略不同EC 策略把數(shù)據(jù)按條帶stripe切分后分散到 KM 個 shard 上任何就地修改都會牽動多個分片的一致性。因此 ECBackend 的初始設(shè)計在沒有啟用 EC overwrites 調(diào)試開關(guān)的普通 EC 池上至今仍然成立將 EC 池的操作限制為可以方便地本地回滾的三種CEPH_OSD_OP_APPEND追加寫追加操作可以本地回滾方法是在 PG 日志事件中附帶追加前的對象大小。CEPH_OSD_OP_DELETE刪除刪除的回滾要求在所有副本都持久化刪除事件之前保留被刪對象。因此 EC 后端在向 filestore 寫入對象時需要在 key 中包含對象創(chuàng)建時的版本號當(dāng)所有副本都提交到刪除該對象的日志事件之后舊版本對象才可被剪除prune。CEPH_OSD_OP_(SET|RM)ATTR設(shè)置/刪除屬性只要在日志中附帶被設(shè)置/刪除屬性的舊值就可以在本地回滾這些操作。日志條目中包含一個描述如何本地撤銷該操作的結(jié)構(gòu)即 osd_types.h 中的TransactionInfo::LocalRollBack與回滾對應(yīng)的正向執(zhí)行結(jié)構(gòu)為LocalRollForward。這一設(shè)計決定了 EC 池后續(xù)所有寫入流程見兩階段提交小節(jié)都圍繞可提交 可回滾來組織。二、PGTemp 與 CRUSH讓 acting set 出現(xiàn)空洞與獨立主分片在復(fù)制池中PG 的 acting set 里acting[0]就是主 OSD。但 EC 池的主分片不必占據(jù)第一個位置且為了在 backfill 新主 OSD 期間讓一個已 up-to-date 的 OSD 繼續(xù)服務(wù)請求主 OSD 需要能申請一個臨時的 acting set 映射PGTemp。ECBackend 因此要求OSDMap::pg_to_*_osds需要單獨返回 primary而不是一律假定acting[0]MOSDPGTemp及相關(guān) OSD 結(jié)構(gòu)需要能同時指定 primary 和 acting set。從源碼看src/messages/MOSDPGTemp.h 中pg_temp為std::mappg_t, std::vectorint32_tacting set 以 int32 向量表達而主分片信息由 OSD 側(cè)從OSDMap::get_primary_shard見 src/osd/OSDMap.h解析既有代碼大量假設(shè)acting[0]即主分片、acting set 每個位置都有效需要清理因為 EC 的 acting set 可能含有空洞holes。三、區(qū)分 acting set 中的分片位置ghobject_t、coll_t 與 spg_t復(fù)制策略下 PG 的所有副本可互換而糾刪碼策略下acting set 中不同位置對應(yīng)糾刪碼方案的不同分片chunk彼此不可互換。更糟的是CRUSH 可能把 chunk 2 寫到一個已經(jīng)存有舊 chunk 4 的 OSD 上。因此 OSD 與 PG 消息必須以pairshard_t, pg_t這樣的類型來區(qū)分同一 OSD 上的不同 PG 分片。由于對象名到 filestore 對象的映射必須是一對一的chunk 2 與 chunk 4 的對象必須擁有不同的名字對象存儲鍵中必須包含 chunk id。對應(yīng)的核心改動在 src/common/hobject.h 中已經(jīng)落地ghobject_t包含shard_id字段見 src/common/hobject.h形如tuplehobject_t, gen_t, shard_tcoll_t需要包含shard_tOSD 的 pg_map 等 PG 映射以spg_t本質(zhì)上是pairpg_t, shard_t為鍵PG 之間的消息也需要攜帶shard_t對于客戶端到 PG 的消息由于同一 OSD 可能同時保存同一 PG 的主分片與非主分片OSD 需要一種方式判斷消息應(yīng)路由到哪個分片。四、對象類Object ClassEC 池上返回 ENOTSUP對象類通常依賴本地對象數(shù)據(jù)的隨機讀取語義這與 EC 分片存儲相沖突。文檔明確對 EC 池上的對象類讀操作通過發(fā)起一次特殊的同步讀SYNC read來返回 ENOTSUP。也就是說EC 池不提供對象類的執(zhí)行語義調(diào)用方會得到明確的不支持錯誤。對應(yīng)到源碼src/osd/ECBackend.h 提供了objects_read_sync、objects_read_local、objects_readv_sync等同步讀入口供需要讀回完整對象的場景使用。五、Scrub逐分片 CRC32 校驗EC 池的 Scrub 不能沿用復(fù)制池的思路——把副本上存儲 chunk 的 crc32 發(fā)給主 OSD 沒有意義因為不同副本存的內(nèi)容本身不同。由于無 overwrites 時數(shù)據(jù)只能通過追加寫入ECBackend 可以在每次追加時維護每個 chunk 的 crc32。于是每個副本計算自身存儲 chunk 的 crc32與本地保存的校驗值比較副本只向主 OSD 報告校驗是否匹配。文檔同時指出一旦啟用 overwritesEC 覆蓋寫在所有 scrub 語義討論清楚之前所有 scrub 將被禁用相關(guān)討論見 proposals.rst。六、CRUSH無法替換成員時保留空洞如果 CRUSH 無法為 acting set 中某個 down 掉的成員生成替換 OSDacting set 應(yīng)在該位置保留空洞而不是把其余元素移出原有位置。這保證了各位置與糾刪碼分片的對應(yīng)關(guān)系不被破壞——這與第二節(jié)中acting set 允許空洞的設(shè)計一脈相承。七、主操作概覽條帶切分與 W ≤ K 模型一個 RADOS put 操作可能橫跨單個對象的多個條帶。ECBackend 必須把應(yīng)用層寫入細分為逐條帶的寫操作若干完整條帶加上最多兩個部分條帶。為了不失一般性文檔后續(xù)只討論單個條帶整條帶或部分條帶的寫入并用符號W表示一個條帶內(nèi)被寫入的數(shù)據(jù)塊數(shù)量即W ≤ K。處理一次 EC 條帶寫入共有兩條數(shù)據(jù)流選擇依據(jù)是寫操作的大小以及所選校驗生成算法的算術(shù)性質(zhì)整條帶寫入/覆蓋Whole stripe write讀改寫操作Read-Modify-WriteRMW。八、整條帶寫入Whole Stripe Write這是最簡單的情況現(xiàn)有代碼在追加寫場景中已經(jīng)實現(xiàn)主 OSD 在 RADOS 請求中收到條帶的全部數(shù)據(jù)計算對應(yīng)的校驗塊parity blocks然后把數(shù)據(jù)塊與校驗塊發(fā)送到各自目標(biāo) shard 寫入。這就是當(dāng)前 EC 代碼的基本形態(tài)。從源碼看src/osd/ECCommon.h 中RMWPipeline::Op的requires_rmw()返回!plan.want_read——當(dāng)ECTransaction::WritePlan不需要讀取舊數(shù)據(jù)即整條帶寫入時requires_rmw()為假走的就是整條帶直寫路徑。九、讀改寫Read-Modify-WriteRMW當(dāng)寫操作只覆蓋條帶的部分塊W K時主 OSD 需要確定 K-W 個不被修改的塊并從對應(yīng) shard 讀取它們收到全部舊數(shù)據(jù)后與請求中的新數(shù)據(jù)合并計算新的校驗塊把修改過的塊發(fā)送到各自 shard 寫入確認 RADOS 操作完成。這就是 EC 覆蓋寫overwrite的核心成本所在一次部分寫必須伴隨一次遠端讀。RMW 的讀取在源碼中體現(xiàn)為ECCommon::RMWPipeline::Op中的pending_cache_ops與cache_ready()回調(diào)見 src/osd/ECCommon.h遠端讀取結(jié)果就緒后把shard_extent_map合并進remote_shard_extent_map然后推進管線狀態(tài)機。十、兩階段提交Commit 與 Rollforward無論選擇上述哪種算法數(shù)據(jù)寫入都是兩階段過程commit提交與 rollforward前滾。主 OSD 在日志條目中描述操作及其回滾方式對應(yīng)osd_types.h中的TransactionInfo::(LocalRollForward|LocalRollBack)。commit 階段就地執(zhí)行寫入可能把回滾所需的信息放到一個旁寫對象write-aside object中。覆蓋已存在條帶時回滾信息表現(xiàn)為一個稀疏對象sparse object其中包含被覆蓋 extents 的舊值——目前通過clone_range填充本質(zhì)上是一個占位實現(xiàn)文檔明確說明在真實環(huán)境中 bluestore 將提供更高效的原子原語。rollforward 階段當(dāng) acting set 中所有副本都提交了 commit 之后清除回滾信息。rollforward 可以延遲執(zhí)行只要所有副本都已提交操作即可向客戶端報告已提交。當(dāng)前實現(xiàn)中每次發(fā)送寫操作時也會指示所有先前已提交的操作進行前滾見ECBackend::try_reads_to_commit如果到達waiting_rollforward隊列時管線里已沒有待處理寫操作就發(fā)起一次 dummy 寫來推動流程前進見后文管線小節(jié)與ECBackend::try_finish_rmw。十一、ExtentCache按 extent 緩存已寫數(shù)據(jù)同一對象上的寫入必須能夠流水線化pipeline為此 ECBackend 維護了一個由可緩存操作寫入的 extent 緩存每個 extent 在被引用它的操作提交之前保持**釘住pinned**狀態(tài)管線保證在讀改寫rmw操作運行之前不可緩存的事務(wù)如 clone 等已從管線中沖刷完畢。源碼實現(xiàn)位于 src/osd/ECExtentCache.hECExtentCache::LRU以(offset, oid)為鍵維護一個受限大小的 LRU 緩存見 src/osd/ECExtentCache.hOp結(jié)構(gòu)記錄 reads/writes、projected_size、invalidates_cache等狀態(tài)見 src/osd/ECExtentCache.h。緩存狀態(tài)與并發(fā)操作何時可引用同一對象的高層不變量一一對應(yīng)頭文件中有詳細說明。十二、Pipelinermw 與不可緩存操作互斥閱讀 ExtentCache.h 能理解操作之間如何重疊。寫入操作的處理涉及多個狀態(tài)其中有一個 PrimaryLogPG 在上層不強制、必須由 ECBackend 自行管理的關(guān)鍵不變量同一對象上不可緩存操作uncacheable與讀改寫rmw操作不能同時運行。為簡單起見ECBackend 強制執(zhí)行任何包含 rmw 操作的操作都必須等待所有進行中的不可緩存操作完成。文檔也注明該處未來仍有優(yōu)化空間。管線狀態(tài)機的具體形態(tài)在 src/osd/ECCommon.h 中RMWPipeline持有tid_to_op_mapOp 歸屬、oid_to_version、waiting_commit隊列、completed_to/committed_to水位以及start_rmw、cache_ready、try_finish_rmw、finish_rmw等轉(zhuǎn)移函數(shù)ECBackend::waiting_*隊列與try_from_to_to系列函數(shù)則對應(yīng)各狀態(tài)的遷移路徑。OSD 側(cè)的ECBackend類定義在 src/osd/ECBackend.h其子寫、子讀消息處理handle_sub_write、handle_sub_read、handle_sub_read_reply、handle_sub_write_reply與submit_transaction共同構(gòu)成完整的寫入閉環(huán)Crimson 側(cè)對應(yīng)實現(xiàn)為 src/osd/ECBackendL.h 與 src/osd/ECCommonL.h。十三、關(guān)鍵源碼索引主題參考文件設(shè)計文檔本文依據(jù)doc/dev/osd_internals/erasure_coding/ecbackend.rstECBackend 類定義與消息處理src/osd/ECBackend.hCrimsonsrc/osd/ECBackendL.hRMW 管線與 Op 狀態(tài)機src/osd/ECCommon.hExtentCache 與 LRUsrc/osd/ECExtentCache.h分片尋址shard_id 內(nèi)嵌于對象鍵src/common/hobject.h主分片解析src/osd/OSDMap.hPGTemp 消息結(jié)構(gòu)src/messages/MOSDPGTemp.h條帶信息模型src/osd/ECUtil.hScrub 語義的 overwrites 后續(xù)討論doc/dev/osd_internals/erasure_coding/proposals.rst十四、總結(jié)與延伸閱讀ECBackend 的設(shè)計精髓可以概括為三條主線可回滾優(yōu)先EC 池早期只接受 APPEND/DELETE/ATTR 等可本地回滾的操作任何寫入都通過commit rollforward兩階段完成回滾信息以稀疏對象clone_range 占位保存分片位置即身份acting set 各位置與糾刪碼分片一一對應(yīng)通過ghobject_t.shard_id、coll_t.shard_t、spg_t重構(gòu)尋址允許 acting set 空洞、主分片獨立指定管線化與互斥ExtentCache 釘住未提交 extent 使寫操作可流水線RMW 管線強制不可緩存操作與 rmw 操作不同時運行。若要進一步深入可以繼續(xù)閱讀同一目錄下的 developer_notes.rst、direct_reads.rst、sparse_reads.rst 與 ec_stretch_cluster.rst它們分別對應(yīng) EC 讀路徑優(yōu)化、稀疏讀與跨域擴展集群等后續(xù)演進enhancements.rst 則匯總了該領(lǐng)域的功能增強清單。贊分享存儲分布式文件系統(tǒng)對象存儲后端高可用【免費下載鏈接】cephCeph is a distributed object, block, and file storage platform項目地址https://gitcode.com/gh_mirrors/ce/ceph點擊查看免費下載相關(guān)推薦Ceph EC 池稀疏讀與邏輯分配保留force_allocated_extents 設(shè)計深度解析Ceph EC 池稀疏讀與邏輯分配保留force_allocated_extents 設(shè)計深度解析 本文基于 Ceph 倉庫中的官方設(shè)計文檔 doc/dev/存儲分布式文件系統(tǒng)對象存儲后端高可用Ceph ECBackend 演進提案解析奇偶校驗增量寫、條帶緩存與可回滾覆蓋寫的設(shè)計藍圖Ceph ECBackend 演進提案解析奇偶校驗增量寫、條帶緩存與可回滾覆蓋寫的設(shè)計藍圖 本文以 doc/dev/osd_internals/erasure存儲分布式文件系統(tǒng)對象存儲后端高可用kinit回滾策略版本回滾與數(shù)據(jù)恢復(fù)kinit回滾策略版本回滾與數(shù)據(jù)恢復(fù) 概述 在現(xiàn)代化Web應(yīng)用開發(fā)中版本回滾與數(shù)據(jù)恢復(fù)是保障系統(tǒng)穩(wěn)定性的關(guān)鍵能力。kinit作為基于FastAPI Vu后端前端任務(wù)調(diào)度認證鑒權(quán)移動開發(fā)創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考