我已經在 AWS 上與客戶合作很長時間了，但現在我需要削減成本才能繼續提供服務。在 AWS 上，我使用 RSync 來保持一些資料夾同步，使用 DRDB 來提供高可用性和透明的故障轉移，為每台客戶端電腦始終提供一個可操作且隨時可用的鏡像。
現在我不能繼續使用 DRBD，因為我正在遷移的更便宜的雲端解決方案只是為每台機器提供一個 Ubuntu 14.04 LTS，只有一個分割區並且沒有 LVM，這個雲端平台也成為我的一些客戶的要求。
我正在考慮的解決方案是將shell腳本安排到一側的日常BKP，透過SSH將其傳輸到另一側並恢復BKP，這將變得複雜，容易出錯，並且需要大量的工作來開發和管理。
我的許多客戶只是 Wordpress+Mysql 並接受一天的延遲，我正在尋找提供「高可用性」的替代方案，即使它會帶來一天的延遲，並且不會迫使我為每個客戶開發和管理腳本上下文受限的情況。
答案1
如果您確實無法有效地使用區塊設備（DRBD 在這裡可能會更好，並且您已經有使用它的經驗），GlusterFS 可以為您提供您在檔案層級尋求的複製功能。
Gluster「磚塊」雖然理想情況下是一個單一的儲存設備，其自己的精簡 LVM 堆疊以 XFS 結尾，但實際上可以是節點上任何符合 POSIX 的檔案系統（甚至只是一個目錄而不是專用 FS）。
這些區塊被聚合成一個統一的“卷”，具有“副本”策略，該策略定義現在許多區塊將使用任何給定檔案寫入- 在本例中可能是副本2 或3。的節點上，如果在一切皆有可能。
Gluster 的故障語意不如 DRBD 那樣連貫。裂腦情況更容易實現，因為資料複製是連接客戶端的責任（它將所有寫入的 N 個副本發送到每個 Gluster 節點，而不是寫入到主節點，然後複製資料）。然而，解決具有不同資料的裂腦可能會更容易，因為在使用複製時，每個區塊都是完整的檔案系統，具有完全可讀的資料。
它不會像 DRBD 那樣快，但也許您不需要它？