誰該讀：同時跑 Xcode／CI 與跨 AZ 製品鏡像的平台與儲存負責人。結論先行：副本因子 3 必須跨 AZ 各一 brick，rsync 用有界退避，建置鎖覆蓋最長同步鏈。結構含決策表、七步落地與三條可引用參數。請先從 首頁 確認節點區域，再對照 JuiceFS 矩陣文、MinIO 矩陣文 與 OpenClaw 金絲雀文。
三大痛點：① brick 與實機數不對齊，單 AZ 故障即整卷唯讀；② rsync 無退避，與 gluster self-heal 疊加拖垮建置；③ 只盯容量百分比，忽略 partial-dir 與 heal 暫存把 1TB 碟提前打紅。若你已在物件面採用 S3 協定，仍建議保留 Gluster 掛載作為 POSIX 工作區，避免 CI 腳本大改。
① 副本卷與 brick 規劃
建議卷名 artifacts-rep3，類型 replica 3；每 brick 獨立 APFS 資料碟，勿與系統碟共用。observer 節點只跑 glusterd 與監控，不承載 brick。客戶端掛載建議開啟 performance.cache-size 並限制單檔快取，避免 Xcode 索引與 heal 搶同一顆 NVMe。
| 模式 | brick 佈局 | 適用 |
|---|---|---|
| replica 3 | 3 AZ × 各 1 brick | 生產並聯 CI／共享 DerivedData |
| replica 2 | 2 台實機 | 實驗叢集；無法跨雙機失效 |
| arbiter | 2 資料 + 1 見證 | 磁碟緊張；寫入路徑較複雜 |
② 製品 rsync 退避矩陣
物件面可改走 MinIO／JuiceFS；目錄製品仍以 rsync 鏡像到 Gluster 掛載點。退避 = 降 bwlimit、降併發、拉長重試間隔，而非全停。
| 情境 | 參數起點 | 退避動作 |
|---|---|---|
| 日間增量 | --bwlimit=35000 | 磁碟黃線 → 22000；紅線 → 暫停 delete |
| 初次灌庫 | --partial-dir=/mnt/scratch/partial | 與 heal 錯峰 30 分鐘 |
| CI 尖峰 | 並發 1；--timeout=600 | 連續 3 次失敗 → 退避上限 900 秒 |
③ 多專案建置鎖
以 flock 鎖定 /var/locks/build-${tenant}，TTL 建議 1200 秒。持有鎖期間禁止第二條 rsync 寫入同一 Gluster 子樹。金絲雀放量請對照 OpenClaw 金絲雀探針，磁碟紅線時凍結權重晉升。
- 盤點卷、brick、掛載點與 rsync 來源 DAG。
- 建立 replica 3 並驗證
gluster volume info。 - 寫入開機掛載與 client 快取參數。
- 套用 rsync 矩陣與獨立 partial 碟。
- 部署建置鎖與水位腳本 cron。
- 接 OpenClaw 探針：合併 heal 佇列與碟使用率。
- 演練故障切換：拔一 brick、驗證唯讀與回切。
④ 1TB／2TB 擴容與磁碟水位驗收
擴容優先加 brick 再 add-brick，勿只靠單碟換大；驗收必看 inode、快照與 partial 目錄。
| 規格 | 黃線 | 紅線 | 動作 |
|---|---|---|---|
| 1TB | 約 78% | 約 88% | 降 rsync；排程 heal |
| 2TB | 約 72% | 約 84% | 清 partial；暫停非關鍵卷 |
⑤ 故障切換 FAQ
- 問：單 brick 離線是否仍接受 rsync？答：replica 3 可寫但應立即降 bwlimit；replica 2 建議切唯讀並 fail CI。
- 問：heal 與 rsync 誰優先？答：先清暫存、降同步，黃線以下再開 heal；避免雙峰 IO。
- 問：與 JuiceFS／MinIO 如何分工？答：大物件走姊妹方案；Gluster 承載 POSIX 工作區與增量製品樹。