點 4 盤 E2E 測試指南：拓撲設計、覆蓋范圍與本地運行)
RustFS 分布式 4 節(jié)點 4 盤 E2E 測試指南拓撲設計、覆蓋范圍與本地運行【免費下載鏈接】rustfs2.3x faster than MinIO for 4KB object payloads. RustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.項目地址: https://gitcode.com/GitHub_Trending/rus/rustfs本文是 RustFS 倉庫內e2e-distributed分布式端到端測試車道的完整技術指南。該車道在單臺機器上以127.0.0.1上不同端口真實拉起 4 個 rustfs 進程每節(jié)點 4 塊數據盤用于驗證 S3 語義、對象鎖、版本控制、跨集群復制、配額、池擴容/下線/再平衡、站點復制、混沌故障注入與升級兼容性。讀完本文你將掌握該車道的拓撲表達約束、測試覆蓋清單、與其他 CI 車道的邊界劃分以及如何在本機復現這套 4×4 分布式測試。測試拓撲單機多進程的集群仿真分布式 E2E 測試的核心思想是不依賴真實多主機基礎設施而是在同一臺機器上以127.0.0.1的不同端口運行多個 rustfs 進程每個進程扮演一個集群節(jié)點。這套 in-tree 測試框架對應 crates/e2e_test/src/common.rs 中的RustFSTestClusterEnvironment它負責為每個節(jié)點分配獨立端口、獨立數據目錄并通過RUSTFS_VOLUMES環(huán)境變量組裝節(jié)點的磁盤布局。文檔給出了三種基礎拓撲形態(tài)均通過ClusterTopology的構造函數表達布局構造函數用途4 節(jié)點 × 4 盤單池ClusterTopology::single_pool_multidrive(4, 4)S3、對象鎖、版本控制、配額、可觀測性、并發(fā)、混沌4 節(jié)點 × 1 盤單池ClusterTopology::single_pool(4)雙站點復制共 8 個進程從固定歷史版本做直接/滾動升級1 個單節(jié)點池 × 4 盤隨后三次append_single_node_pool擴容種子池擴容隨后下線 / 再平衡 / 完整性源碼側ClusterTopology位于 crates/e2e_test/src/common.rs除了上述兩個構造函數外還提供per_node_pools(drives_per_node, pools)每個池獨占一個節(jié)點以及append_single_node_pool()向已停止的多池集群追加一個新的單節(jié)點 erasure 池用于模擬池擴容。ClusterTopology::validate()會在啟動前完成拓撲合法性校驗節(jié)點必須全部被分配且只屬于一個池、多池拓撲要求drives_per_node 2服務端解析器拒絕單盤省略號池drive{0...0}、跨多個 localhost 節(jié)點的池不可表達。單機拓撲的表達約束為什么多節(jié)點條帶池不可表達在127.0.0.1上表達多池布局存在一個硬性限制任何跨越多個 localhost 端口的池都是不可表達的。原因是RUSTFS_VOLUMES的 host 省略號語法如127.0.0.1:900{0...1}會強制這些端口共享同一磁盤路徑從而在物理路徑上發(fā)生沖突。因此多池拓撲中每個池只能擁有一個節(jié)點。從源碼看build_volumes_arg()crates/e2e_test/src/common.rs對單池布局逐條枚舉每個 (node, drive) 端點并用空格連接對多池布局則為每個單節(jié)點池生成一個省略號參數http://addrnode-base/drive{0...N-1}。服務端按空格拆分RUSTFS_VOLUMES每個省略號參數成為一個獨立池。多主機條帶化擴容池仍然屬于硬件功能鏈車道backlog #1313 / #1314的職責范圍本車道有意不表達該形態(tài)。此外當拓撲為多盤drives_per_node 1時with_topology()會給每個節(jié)點追加RUSTFS_UNSAFE_BYPASS_DISK_CHECKtrue這些盤位于同一臨時文件系統(tǒng)上服務端的物理磁盤唯一性安全檢查會拒絕啟動必須顯式繞過。數據搬遷用例的 fail-closed 語義本車道對 decommission下線與 rebalance再平衡用例采用了**失敗即關閉fail closed**的嚴格判定策略杜絕空跑通過。文檔明確規(guī)定一個通過的下線或再平衡測試必須同時滿足觀察到成功的啟動響應觀察到 active進行中狀態(tài)觀察到干凈的終態(tài)terminal state移動計數器非零操作結束后對象完整性校驗通過。反之任何不支持的響應、HTTP 5xx、缺失狀態(tài)字段、清理告警或零進度的終態(tài)響應都會導致用例失敗。僅憑操作前后 S3 可用并不能證明數據移動確實發(fā)生過——這對應 crates/e2e_test/src/distributed/harness.rs 中的wait_for_decommission_active/wait_for_decommission_complete/wait_for_rebalance_active/wait_for_rebalance_complete以及 inventory 完整性斷言。具體到測試用例crates/e2e_test/src/distributed/expand_decommission_rebalance_test.rs 中的four_pool_decommission_moves_objects_without_loss先把基線對象、版本歷史和多部分multipart數據寫入池 0隨后擴展到四個池最后下線池 0DECOMMISSION_POOL_ID 0。這樣通過結果證明的是用戶數據的真實遷移而非僅僅一個內部元數據計數器的變化。同樣four_node_pool_expand_preserves_objects_then_rebalance先寫入 64 個 256 KiB 對象構成 inventory逐步從 2 個池擴展到 4 個池每次擴展后都從新節(jié)點和舊節(jié)點雙重校驗對象完整性。池擴容對隔離文件系統(tǒng)的要求池擴容用例依賴每個池報告獨立的容量。問題在于runner 文件系統(tǒng)上的四個目錄返回完全相同的statfs總量RustFS 會據此判定沒有任何池比集群平均值更空閑從而不執(zhí)行任何再平衡。為解決這個問題CI 作業(yè)運行在 GitHub 托管的ubuntu-latest上掛載四個獨立的 1 GiB tmpfs 文件系統(tǒng)并通過RUSTFS_E2E_POOL_ROOTS導出它們的絕對路徑。文檔特別解釋了為什么不使用自托管的sm-standard-4ARC pods這些 pod 無法創(chuàng)建文件系統(tǒng)——mount -o loop因缺少/dev/loop-control報No such file or directorymount -t tmpfs因初始命名空間缺少CAP_SYS_ADMIN報cannot mount tmpfs read-only。帶大小的 tmpfs 仍然會報告不同的st_dev和獨立的 1 GiBstatfs容量足以滿足校驗。對應的校驗邏輯在 crates/e2e_test/src/distributed/harness.rs 的validate_pool_storage_roots()它拒絕缺失、重復、相對路徑、不存在或同設備st_dev相同的根目錄而不是允許一次空洞的移動通過。RUSTFS_E2E_POOL_ROOTS必須恰好包含 4 個絕對路徑。擴容流程本身也遵循嚴格的過程紀律計劃內的池追加以SIGTERM 優(yōu)雅停止所有進程硬殺進程僅保留給混沌故障用例第四個池加入后harness 執(zhí)行一次完整的優(yōu)雅持久重啟這證明擴展后的池映射在重啟后仍然存在并確保只有在每個副本都能加載收斂后的元數據之后移動才會開始擴容夾具是全當前版本二進制的機群因此以文檔化的V3 寫入與機群確認門RUSTFS_POOL_META_V3_WRITEtrue、RUSTFS_POOL_META_V3_FLEET_CONFIRMEDtrue見 harness.rs 的POOL_META_V3_ENV初始化池元數據。該車道覆蓋的測試范圍cargo nextest run --profile e2e-distributed -p e2e_test通過 nextest 的默認過濾器選擇distributed::*模塊見 .config/nextest.toml 中[profile.e2e-distributed]的default-filter package(e2e_test) test(/^distributed::/)。測試源碼位于 crates/e2e_test/src/distributed/模塊清單在 mod.rs 中聲明包括s3_basic_test、object_lock_test、versioning_test、replication_quota_test、observability_test、expand_decommission_rebalance_test、concurrent_data_movement_test、s3_during_data_movement_test、data_integrity_movement_test、site_replication_test、chaos_test、concurrency_stability_test、upgrade_test、extra_test和共享的harness.rs。車道覆蓋的具體行為包括S3 基礎語義put / get / head / list / copy / rename / delete / presign范圍讀與條件讀、特殊字符 key、元數據、標簽、分頁、空對象、multipart 完成與中止對象鎖Object LockCOMPLIANCE、GOVERNANCE 與繞過bypass、legal hold、bucket 默認保留期、非鎖桶拒絕版本控制精確歷史讀取、刪除標記移除、掛起狀態(tài)的 null 版本覆蓋語義跨集群桶復制兩個 4 節(jié)點集群之間復制含元數據/標簽、目標故障重試、硬配額準入與拒絕 key 的缺席驗證可觀測性每個節(jié)點的 ready/live 探針、精確的 4 server / 16 disk 清單、每個節(jié)點的實時指標、關聯的審計 webhook 投遞。可觀測性用例運行在 WARN 級別并掛起兩個節(jié)點進程以模擬無響應對端緩存盤立即變?yōu)?unknown、精確的每節(jié)點 HTTP PUT 增量暴露亞法定人數sub-quorum失敗、本地元數據快照不會虛構寫鎖、恢復的對端允許新寫入且從每個節(jié)點讀到字節(jié)一致的數據——這模擬的是停滯進程而非物理網絡分區(qū)池生命周期池擴容、下線、再平衡、校驗和完整性、版本化與 multipart 數據、移動期間的 S3 可用性雙站點復制雙向收斂以及兩個站點的 enabled/synchronized 對等狀態(tài)并發(fā)與壓力24 worker 的混合 PUT/HEAD/GET/COPY/DELETE 負載、活躍下線期間的并發(fā) PUT故障注入節(jié)點 kill/重啟、完整進程重啟、節(jié)點面向 TCP 黑洞/恢復、跨對端 kill 的進行中流式 GET、以及通過物理xl.meta/ part-shard 盤點驗證的新盤替換列表一致性multipart、跨節(jié)點列表、list-buckets 一致性升級兼容從固定歷史版本做直接與滾動升級之后歷史對象、版本化歷史與 IAM 用戶 AK/SK 仍正常工作。與其他 CI 車道的邊界本車道不替代什么該車道定位是填補 in-tree 的 4×4 覆蓋空白既有的其他測試套件保持不變。文檔給出了完整的邊界對照表既有車道空白rustfs-*-test.yml功能鏈克隆私有rustfs/auto-testing運行在三臺共享 VMvm000–vm002上continue-on-error: true不是合并信號也不是 4 節(jié)點。硬件rustfs-upgrade-test.yml仍留在那里e2e-upgrade.yml單節(jié)點 SSE/multipart/delete-marker 契約加混合版本列表不在 4 節(jié)點集群上固定 IAM 用戶 AK/SKe2e-smoke/e2e-full多數選定用例是單節(jié)點分布式模塊有意由本串行車道獨占e2e-nightly4 節(jié)點集群故障與修復而非 S3/鎖/版本控制/配額/下線矩陣e2e-repl-nightly在 1–3 個單節(jié)點進程上進行站點與桶復制e2e-s3tests.ymlmulti每周對 Docker 4 節(jié)點運行 ceph/s3-tests不含鎖/WORM、下線、混沌或校驗和完整性crates/e2e_test/src/chaos.rs僅單節(jié)點磁盤故障硬件層面的斷電、物理網卡拔除、帶認證的節(jié)點間分區(qū)、固件/介質錯誤與替換服務器供應仍屬于硬件驗證 VM 的職責。本車道提供的是確定性的進程 kill、全新本地卷替換與節(jié)點面向 TCP 黑洞的模擬手段不宣稱物理故障認證。本地運行指南本地復現這套 4×4 分布式測試的完整流程如下cargo build -p rustfs --bins # 擴容/下線/再平衡用例需要四條位于不同文件系統(tǒng)上的路徑。 # 如果沒有四塊磁盤帶大小的 tmpfs 就夠了 # for p in 0 1 2 3; do # sudo mkdir -p /mnt/rustfs-pool-$p # sudo mount -t tmpfs -o size1G,nosuid,nodev,mode1777 tmpfs /mnt/rustfs-pool-$p # done export RUSTFS_E2E_POOL_ROOTS/mnt/rustfs-pool-0:/mnt/rustfs-pool-1:/mnt/rustfs-pool-2:/mnt/rustfs-pool-3 # 升級用例需要固定的歷史二進制CI 會下載它。 export RUSTFS_UPGRADE_SOURCE_BINARY/path/to/rustfs-1.0.0-rc.2 cargo nextest run --profile e2e-distributed -p e2e_test兩個環(huán)境變量都是硬性前置條件缺失時對應用例失敗關閉沒有RUSTFS_UPGRADE_SOURCE_BINARY兩個distributed::upgrade_test::*用例會失敗沒有四條不同的RUSTFS_E2E_POOL_ROOTS擴容與數據搬遷用例會失敗。如果本地運行不檢查升級可以過濾掉升級用例cargo nextest run --profile e2e-distributed -p e2e_test -E not test(/^distributed::upgrade_test::/)升級拓撲使用ClusterTopology::single_pool(4)4 節(jié)點 × 1 盤這與 crates/e2e_test/src/upgrade_compatibility_test.rs 中已被驗證的混合版本夾具一致4×4 localhost 磁盤會被歷史版本的同設備磁盤檢查拒絕。測試成員的歸屬由 .config/e2e-distributed-selection.txt 固定內含 Linux 與 Darwin 平臺的選擇摘要哈希。新增或重命名用例后需要按文檔所述用python3 ./scripts/check_test_wiring.py --update-profile e2e-distributed listing.json platform更新 Linux 與 Darwin 兩條條目以保證 CI 能檢測到成員變更。CI 工作流tmpfs 掛載與失敗告警.github/workflows/e2e-distributed.yml 是這條車道的 CI 載體其設計要點與本地運行一一對應觸發(fā)條件對涉及存儲棧的路徑Cargo.lock、Cargo.toml、.config/nextest.toml、crates/e2e_test/**、crates/ecstore/**、rustfs/**等的 PR、手動workflow_dispatch可選-E過濾器輸入以及每天 05:53 UTC 的定時任務runner 選擇ubuntu-latestGitHub 托管 VM因為 loop 與 tmpfs 掛載在這里可用sm-standard-4ARC pod 兩者都拒絕準備步驟在RUNNER_TEMP/rustfs-e2e-pools下掛載四個 1 GiB tmpfssize1G,nosuid,nodev,mode1777并導出RUSTFS_E2E_POOL_ROOTS環(huán)境變量作業(yè)結束時含失敗統(tǒng)一卸載歷史版本下載從 release 下載固定版本1.0.0-rc.2的 zip 包校驗 SHA-256 后解壓導出RUSTFS_UPGRADE_SOURCE_BINARY成員校驗cargo nextest list --profile e2e-distributed --message-format json生成清單隨后python3 ./scripts/check_test_wiring.py --check-profile e2e-distributed核對成員與 scripts/check_test_wiring.py 中實現的 selection 摘要機制配合執(zhí)行cargo nextest run --profile e2e-distributed -p e2e_test --no-testsfail手動觸發(fā)時可傳入-E過濾器串行化.config/nextest.toml中[profile.e2e-distributed]將整個package(e2e_test) test(/^distributed::/)歸入e2e-cluster-nightly測試組max-threads 1因為每個用例會啟動四個 rustfs 進程和多達十六個數據目錄多個 4×4 集群絕不能同時運行同時設置slow-timeout { period 120s, terminate-after 6 }覆蓋下線/再平衡用例長達 180 秒的輪詢等待失敗告警定時運行失敗時由alert-on-failure作業(yè)通過.github/actions/schedule-failure-issue打開或更新跟蹤 issue并上傳 junit.xml、成員清單與節(jié)點日志供排障。小結e2e-distributed車道把4 節(jié)點 × 4 盤真實集群壓縮進一臺 CI VM通過 distinct 端口上的多進程、RUSTFS_VOLUMES的池布局表達、隔離 tmpfs 的獨立容量校驗、以及 fail-closed 的數據搬遷斷言在合并門禁中持續(xù)驗證 RustFS 的多節(jié)點 S3 語義、數據耐久性與集群生命周期操作。對開發(fā)者而言本地只要備好四個隔離文件系統(tǒng)與固定的歷史版本二進制就能完整復現這條與生產多節(jié)點形態(tài)最接近的自動化測試鏈?！久赓M下載鏈接】rustfs2.3x faster than MinIO for 4KB object payloads. RustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.項目地址: https://gitcode.com/GitHub_Trending/rus/rustfs創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 RustFS 分布式 4 節(jié)點 4 盤 E2E 測試指南：拓撲設計、覆蓋范圍與本地運行
RustFS 分布式 4 節(jié)點 4 盤 E2E 測試指南拓撲設計、覆蓋范圍與本地運行【免費下載鏈接】rustfs2.3x faster than MinIO for 4KB object payloads. RustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.項目地址: https://gitcode.com/GitHub_Trending/rus/rustfs本文是 RustFS 倉庫內e2e-distributed分布式端到端測試車道的完整技術指南。該車道在單臺機器上以127.0.0.1上不同端口真實拉起 4 個 rustfs 進程每節(jié)點 4 塊數據盤用于驗證 S3 語義、對象鎖、版本控制、跨集群復制、配額、池擴容/下線/再平衡、站點復制、混沌故障注入與升級兼容性。讀完本文你將掌握該車道的拓撲表達約束、測試覆蓋清單、與其他 CI 車道的邊界劃分以及如何在本機復現這套 4×4 分布式測試。測試拓撲單機多進程的集群仿真分布式 E2E 測試的核心思想是不依賴真實多主機基礎設施而是在同一臺機器上以127.0.0.1的不同端口運行多個 rustfs 進程每個進程扮演一個集群節(jié)點。這套 in-tree 測試框架對應 crates/e2e_test/src/common.rs 中的RustFSTestClusterEnvironment它負責為每個節(jié)點分配獨立端口、獨立數據目錄并通過RUSTFS_VOLUMES環(huán)境變量組裝節(jié)點的磁盤布局。文檔給出了三種基礎拓撲形態(tài)均通過ClusterTopology的構造函數表達布局構造函數用途4 節(jié)點 × 4 盤單池ClusterTopology::single_pool_multidrive(4, 4)S3、對象鎖、版本控制、配額、可觀測性、并發(fā)、混沌4 節(jié)點 × 1 盤單池ClusterTopology::single_pool(4)雙站點復制共 8 個進程從固定歷史版本做直接/滾動升級1 個單節(jié)點池 × 4 盤隨后三次append_single_node_pool擴容種子池擴容隨后下線 / 再平衡 / 完整性源碼側ClusterTopology位于 crates/e2e_test/src/common.rs除了上述兩個構造函數外還提供per_node_pools(drives_per_node, pools)每個池獨占一個節(jié)點以及append_single_node_pool()向已停止的多池集群追加一個新的單節(jié)點 erasure 池用于模擬池擴容。ClusterTopology::validate()會在啟動前完成拓撲合法性校驗節(jié)點必須全部被分配且只屬于一個池、多池拓撲要求drives_per_node 2服務端解析器拒絕單盤省略號池drive{0...0}、跨多個 localhost 節(jié)點的池不可表達。單機拓撲的表達約束為什么多節(jié)點條帶池不可表達在127.0.0.1上表達多池布局存在一個硬性限制任何跨越多個 localhost 端口的池都是不可表達的。原因是RUSTFS_VOLUMES的 host 省略號語法如127.0.0.1:900{0...1}會強制這些端口共享同一磁盤路徑從而在物理路徑上發(fā)生沖突。因此多池拓撲中每個池只能擁有一個節(jié)點。從源碼看build_volumes_arg()crates/e2e_test/src/common.rs對單池布局逐條枚舉每個 (node, drive) 端點并用空格連接對多池布局則為每個單節(jié)點池生成一個省略號參數http://addrnode-base/drive{0...N-1}。服務端按空格拆分RUSTFS_VOLUMES每個省略號參數成為一個獨立池。多主機條帶化擴容池仍然屬于硬件功能鏈車道backlog #1313 / #1314的職責范圍本車道有意不表達該形態(tài)。此外當拓撲為多盤drives_per_node 1時with_topology()會給每個節(jié)點追加RUSTFS_UNSAFE_BYPASS_DISK_CHECKtrue這些盤位于同一臨時文件系統(tǒng)上服務端的物理磁盤唯一性安全檢查會拒絕啟動必須顯式繞過。數據搬遷用例的 fail-closed 語義本車道對 decommission下線與 rebalance再平衡用例采用了**失敗即關閉fail closed**的嚴格判定策略杜絕空跑通過。文檔明確規(guī)定一個通過的下線或再平衡測試必須同時滿足觀察到成功的啟動響應觀察到 active進行中狀態(tài)觀察到干凈的終態(tài)terminal state移動計數器非零操作結束后對象完整性校驗通過。反之任何不支持的響應、HTTP 5xx、缺失狀態(tài)字段、清理告警或零進度的終態(tài)響應都會導致用例失敗。僅憑操作前后 S3 可用并不能證明數據移動確實發(fā)生過——這對應 crates/e2e_test/src/distributed/harness.rs 中的wait_for_decommission_active/wait_for_decommission_complete/wait_for_rebalance_active/wait_for_rebalance_complete以及 inventory 完整性斷言。具體到測試用例crates/e2e_test/src/distributed/expand_decommission_rebalance_test.rs 中的four_pool_decommission_moves_objects_without_loss先把基線對象、版本歷史和多部分multipart數據寫入池 0隨后擴展到四個池最后下線池 0DECOMMISSION_POOL_ID 0。這樣通過結果證明的是用戶數據的真實遷移而非僅僅一個內部元數據計數器的變化。同樣four_node_pool_expand_preserves_objects_then_rebalance先寫入 64 個 256 KiB 對象構成 inventory逐步從 2 個池擴展到 4 個池每次擴展后都從新節(jié)點和舊節(jié)點雙重校驗對象完整性。池擴容對隔離文件系統(tǒng)的要求池擴容用例依賴每個池報告獨立的容量。問題在于runner 文件系統(tǒng)上的四個目錄返回完全相同的statfs總量RustFS 會據此判定沒有任何池比集群平均值更空閑從而不執(zhí)行任何再平衡。為解決這個問題CI 作業(yè)運行在 GitHub 托管的ubuntu-latest上掛載四個獨立的 1 GiB tmpfs 文件系統(tǒng)并通過RUSTFS_E2E_POOL_ROOTS導出它們的絕對路徑。文檔特別解釋了為什么不使用自托管的sm-standard-4ARC pods這些 pod 無法創(chuàng)建文件系統(tǒng)——mount -o loop因缺少/dev/loop-control報No such file or directorymount -t tmpfs因初始命名空間缺少CAP_SYS_ADMIN報cannot mount tmpfs read-only。帶大小的 tmpfs 仍然會報告不同的st_dev和獨立的 1 GiBstatfs容量足以滿足校驗。對應的校驗邏輯在 crates/e2e_test/src/distributed/harness.rs 的validate_pool_storage_roots()它拒絕缺失、重復、相對路徑、不存在或同設備st_dev相同的根目錄而不是允許一次空洞的移動通過。RUSTFS_E2E_POOL_ROOTS必須恰好包含 4 個絕對路徑。擴容流程本身也遵循嚴格的過程紀律計劃內的池追加以SIGTERM 優(yōu)雅停止所有進程硬殺進程僅保留給混沌故障用例第四個池加入后harness 執(zhí)行一次完整的優(yōu)雅持久重啟這證明擴展后的池映射在重啟后仍然存在并確保只有在每個副本都能加載收斂后的元數據之后移動才會開始擴容夾具是全當前版本二進制的機群因此以文檔化的V3 寫入與機群確認門RUSTFS_POOL_META_V3_WRITEtrue、RUSTFS_POOL_META_V3_FLEET_CONFIRMEDtrue見 harness.rs 的POOL_META_V3_ENV初始化池元數據。該車道覆蓋的測試范圍cargo nextest run --profile e2e-distributed -p e2e_test通過 nextest 的默認過濾器選擇distributed::*模塊見 .config/nextest.toml 中[profile.e2e-distributed]的default-filter package(e2e_test) test(/^distributed::/)。測試源碼位于 crates/e2e_test/src/distributed/模塊清單在 mod.rs 中聲明包括s3_basic_test、object_lock_test、versioning_test、replication_quota_test、observability_test、expand_decommission_rebalance_test、concurrent_data_movement_test、s3_during_data_movement_test、data_integrity_movement_test、site_replication_test、chaos_test、concurrency_stability_test、upgrade_test、extra_test和共享的harness.rs。車道覆蓋的具體行為包括S3 基礎語義put / get / head / list / copy / rename / delete / presign范圍讀與條件讀、特殊字符 key、元數據、標簽、分頁、空對象、multipart 完成與中止對象鎖Object LockCOMPLIANCE、GOVERNANCE 與繞過bypass、legal hold、bucket 默認保留期、非鎖桶拒絕版本控制精確歷史讀取、刪除標記移除、掛起狀態(tài)的 null 版本覆蓋語義跨集群桶復制兩個 4 節(jié)點集群之間復制含元數據/標簽、目標故障重試、硬配額準入與拒絕 key 的缺席驗證可觀測性每個節(jié)點的 ready/live 探針、精確的 4 server / 16 disk 清單、每個節(jié)點的實時指標、關聯的審計 webhook 投遞。可觀測性用例運行在 WARN 級別并掛起兩個節(jié)點進程以模擬無響應對端緩存盤立即變?yōu)?unknown、精確的每節(jié)點 HTTP PUT 增量暴露亞法定人數sub-quorum失敗、本地元數據快照不會虛構寫鎖、恢復的對端允許新寫入且從每個節(jié)點讀到字節(jié)一致的數據——這模擬的是停滯進程而非物理網絡分區(qū)池生命周期池擴容、下線、再平衡、校驗和完整性、版本化與 multipart 數據、移動期間的 S3 可用性雙站點復制雙向收斂以及兩個站點的 enabled/synchronized 對等狀態(tài)并發(fā)與壓力24 worker 的混合 PUT/HEAD/GET/COPY/DELETE 負載、活躍下線期間的并發(fā) PUT故障注入節(jié)點 kill/重啟、完整進程重啟、節(jié)點面向 TCP 黑洞/恢復、跨對端 kill 的進行中流式 GET、以及通過物理xl.meta/ part-shard 盤點驗證的新盤替換列表一致性multipart、跨節(jié)點列表、list-buckets 一致性升級兼容從固定歷史版本做直接與滾動升級之后歷史對象、版本化歷史與 IAM 用戶 AK/SK 仍正常工作。與其他 CI 車道的邊界本車道不替代什么該車道定位是填補 in-tree 的 4×4 覆蓋空白既有的其他測試套件保持不變。文檔給出了完整的邊界對照表既有車道空白rustfs-*-test.yml功能鏈克隆私有rustfs/auto-testing運行在三臺共享 VMvm000–vm002上continue-on-error: true不是合并信號也不是 4 節(jié)點。硬件rustfs-upgrade-test.yml仍留在那里e2e-upgrade.yml單節(jié)點 SSE/multipart/delete-marker 契約加混合版本列表不在 4 節(jié)點集群上固定 IAM 用戶 AK/SKe2e-smoke/e2e-full多數選定用例是單節(jié)點分布式模塊有意由本串行車道獨占e2e-nightly4 節(jié)點集群故障與修復而非 S3/鎖/版本控制/配額/下線矩陣e2e-repl-nightly在 1–3 個單節(jié)點進程上進行站點與桶復制e2e-s3tests.ymlmulti每周對 Docker 4 節(jié)點運行 ceph/s3-tests不含鎖/WORM、下線、混沌或校驗和完整性crates/e2e_test/src/chaos.rs僅單節(jié)點磁盤故障硬件層面的斷電、物理網卡拔除、帶認證的節(jié)點間分區(qū)、固件/介質錯誤與替換服務器供應仍屬于硬件驗證 VM 的職責。本車道提供的是確定性的進程 kill、全新本地卷替換與節(jié)點面向 TCP 黑洞的模擬手段不宣稱物理故障認證。本地運行指南本地復現這套 4×4 分布式測試的完整流程如下cargo build -p rustfs --bins # 擴容/下線/再平衡用例需要四條位于不同文件系統(tǒng)上的路徑。 # 如果沒有四塊磁盤帶大小的 tmpfs 就夠了 # for p in 0 1 2 3; do # sudo mkdir -p /mnt/rustfs-pool-$p # sudo mount -t tmpfs -o size1G,nosuid,nodev,mode1777 tmpfs /mnt/rustfs-pool-$p # done export RUSTFS_E2E_POOL_ROOTS/mnt/rustfs-pool-0:/mnt/rustfs-pool-1:/mnt/rustfs-pool-2:/mnt/rustfs-pool-3 # 升級用例需要固定的歷史二進制CI 會下載它。 export RUSTFS_UPGRADE_SOURCE_BINARY/path/to/rustfs-1.0.0-rc.2 cargo nextest run --profile e2e-distributed -p e2e_test兩個環(huán)境變量都是硬性前置條件缺失時對應用例失敗關閉沒有RUSTFS_UPGRADE_SOURCE_BINARY兩個distributed::upgrade_test::*用例會失敗沒有四條不同的RUSTFS_E2E_POOL_ROOTS擴容與數據搬遷用例會失敗。如果本地運行不檢查升級可以過濾掉升級用例cargo nextest run --profile e2e-distributed -p e2e_test -E not test(/^distributed::upgrade_test::/)升級拓撲使用ClusterTopology::single_pool(4)4 節(jié)點 × 1 盤這與 crates/e2e_test/src/upgrade_compatibility_test.rs 中已被驗證的混合版本夾具一致4×4 localhost 磁盤會被歷史版本的同設備磁盤檢查拒絕。測試成員的歸屬由 .config/e2e-distributed-selection.txt 固定內含 Linux 與 Darwin 平臺的選擇摘要哈希。新增或重命名用例后需要按文檔所述用python3 ./scripts/check_test_wiring.py --update-profile e2e-distributed listing.json platform更新 Linux 與 Darwin 兩條條目以保證 CI 能檢測到成員變更。CI 工作流tmpfs 掛載與失敗告警.github/workflows/e2e-distributed.yml 是這條車道的 CI 載體其設計要點與本地運行一一對應觸發(fā)條件對涉及存儲棧的路徑Cargo.lock、Cargo.toml、.config/nextest.toml、crates/e2e_test/**、crates/ecstore/**、rustfs/**等的 PR、手動workflow_dispatch可選-E過濾器輸入以及每天 05:53 UTC 的定時任務runner 選擇ubuntu-latestGitHub 托管 VM因為 loop 與 tmpfs 掛載在這里可用sm-standard-4ARC pod 兩者都拒絕準備步驟在RUNNER_TEMP/rustfs-e2e-pools下掛載四個 1 GiB tmpfssize1G,nosuid,nodev,mode1777并導出RUSTFS_E2E_POOL_ROOTS環(huán)境變量作業(yè)結束時含失敗統(tǒng)一卸載歷史版本下載從 release 下載固定版本1.0.0-rc.2的 zip 包校驗 SHA-256 后解壓導出RUSTFS_UPGRADE_SOURCE_BINARY成員校驗cargo nextest list --profile e2e-distributed --message-format json生成清單隨后python3 ./scripts/check_test_wiring.py --check-profile e2e-distributed核對成員與 scripts/check_test_wiring.py 中實現的 selection 摘要機制配合執(zhí)行cargo nextest run --profile e2e-distributed -p e2e_test --no-testsfail手動觸發(fā)時可傳入-E過濾器串行化.config/nextest.toml中[profile.e2e-distributed]將整個package(e2e_test) test(/^distributed::/)歸入e2e-cluster-nightly測試組max-threads 1因為每個用例會啟動四個 rustfs 進程和多達十六個數據目錄多個 4×4 集群絕不能同時運行同時設置slow-timeout { period 120s, terminate-after 6 }覆蓋下線/再平衡用例長達 180 秒的輪詢等待失敗告警定時運行失敗時由alert-on-failure作業(yè)通過.github/actions/schedule-failure-issue打開或更新跟蹤 issue并上傳 junit.xml、成員清單與節(jié)點日志供排障。小結e2e-distributed車道把4 節(jié)點 × 4 盤真實集群壓縮進一臺 CI VM通過 distinct 端口上的多進程、RUSTFS_VOLUMES的池布局表達、隔離 tmpfs 的獨立容量校驗、以及 fail-closed 的數據搬遷斷言在合并門禁中持續(xù)驗證 RustFS 的多節(jié)點 S3 語義、數據耐久性與集群生命周期操作。對開發(fā)者而言本地只要備好四個隔離文件系統(tǒng)與固定的歷史版本二進制就能完整復現這條與生產多節(jié)點形態(tài)最接近的自動化測試鏈?！久赓M下載鏈接】rustfs2.3x faster than MinIO for 4KB object payloads. RustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.項目地址: https://gitcode.com/GitHub_Trending/rus/rustfs創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考