我希望以高效能、低延遲的方式在多個 AWS 執行個體之間共用資料。為所有實例提供唯讀存取權限（除了一個處理寫入的實例之外）就可以了。關於此用例的兩點：
- 附加到磁碟區的節點可能隨時出現和消失（啟動、停止、終止等）。
- 共享資料包括數千個需要列出並檢查元資料的潛在小檔案。
所以我最初嘗試了EFS，但對於需要枚舉或修改100或1000個小檔案的操作來說，它相當慢。
所以現在我正在考慮EBS多重附加。但是，為了防止資料損壞，AWS 建議僅使用叢集檔案系統，例如 GFS2 或 OCFS。這兩者的配置似乎都很複雜和挑剔，而且對於節點可能隨時進出的叢集用例來說也是脆弱的。例如，GFS2如果節點數量從多於2個變成恰好2個，則需要重新啟動所有節點上的叢集軟體；或者，新增節點涉及登入當前節點、執行一些命令，以及可能將更新的設定檔重新分發到所有其他節點。它看起來真的很不靈活，而且有很多額外的開銷。
但是，如果我確定只有 1 個實例會寫入磁碟（或者可能每個實例只能寫入自己的子資料夾甚至磁碟分割），我是否可以為此磁碟區使用 XFS 等常規檔案系統並擺脫它？或者，即使存取在技術上是唯讀的或寫入存取僅限於特定於實例的子資料夾或分區，是否會出現微妙的資料損壞問題？
或者我缺少一個完全不同的解決方案？
答案1
我已經測試過這個（XFS）並且它不起作用。您需要一個叢集檔案系統。最好的選擇是使用叢集檔案系統。請考慮其他選項，例如 Veritas Infoscale。
答案2
共享靜態卷內容似乎可以很好地使用多連接和常規 XFS。對磁碟區的熱「新增」僅對寫入資料的實例可見。確定後，我沒有測試熱“更新”或“刪除”，假設它們也只能由作者看到，但可能會中斷其他實例對該資料的存取。重新啟動、重新啟動和/或重新連線的執行個體確實會看到最新的磁碟區狀態。因此，一個實例很少寫入新資料而觸發其他實例強制重新啟動以最終看到資料的用例似乎是該技術可以支援的用例。