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