複製的共享文件系統
我正在研究在 AWS (EC2) 基礎設施上設置共享文件系統/文件伺服器，以提供複製和相當輕鬆的故障轉移。該文件系統可能會託管數百萬個大小為幾兆的文件。可以從多個客戶端 VM 訪問（讀/寫）這些文件。如果主文件伺服器發生故障，我希望客戶端能夠故障轉移到副本文件伺服器而不會失去任何文件（即我希望複製是實時的）。我看過幾個選項：
將 S3 與 s3fs 一起使用。我擔心在對數千個文件執行操作時（例如，在複製/移動文件時），每個請求的延遲都會出現問題。我還聽到一些報告讓我質疑 s3fs 的穩定性——不確定是否仍然如此。
在 EC2 實例上設置 NFS 伺服器，使用 drbd 在兩個實例之間複製塊。缺點：
- 過去我在使用 drbd 時遇到過可靠性問題，尤其是在高延遲連結上
- 如果主 NFS 伺服器出現故障，它將關閉客戶端，需要係統管理員干預和/或重新啟動以使它們重新連接到輔助伺服器。沒有自動故障轉移。
有沒有更好的解決方案？
只是一些更新的資訊。如果您和我一樣，並且想要這個功能已經很長時間了，請使用 Amazon Elastic File System (EFS)。它是跨多個可用區複製的 NFS 掛載。
（很抱歉提出這個問題，但是這個答案的Google排名足夠高，以至於有幾個人可能正在搜尋這個解決方案。）
使用 DRBD 進行同步複製和 Pacemaker + Corosync 自動進行 NFS 服務的故障轉移和節點之間的導出（不中斷客戶端訪問），可以在 Amazon EC2 中設置 NFS 集群，但並不簡單。
如果您計劃同步複製（“實時”），則需要兩個 EC2 實例位於同一區域中以限制它們之間的延遲；否則，網路延遲將轉化為磁碟延遲。
此外，不可能在 Amazon EC2 實例上輕鬆分配/取消分配 IP 地址；您需要使用他們的 API（或使用他們的 web-gui）重新分配 IP 地址。客戶端將用於連接到活動節點的浮動 IP 地址需要移動 IP 地址。需要對“IPaddr2”Pacemaker 資源代理進行一些修改才能使其正常工作；這是一個 bash 腳本。