分發具有本地冗餘的網站文件
因此，我們正在考慮將我們的單個專用伺服器（設置為共享 Web 託管）遷移到具有多個負載平衡前端伺服器和單獨數據庫伺服器的架構（由於流量增長和可用性問題）。
TLDR；當文件伺服器出現故障時，我想要某種方式故障轉移到站點文件的本地只讀鏡像。
場景：
- 大約 200 個虛擬主機，每個虛擬主機有幾個別名
- 每個站點基本上只是一個包含約 30 個本地文件的“包裝器”，大部分只是模板文件，其餘的只是包含在集中式程式碼庫中
- 站點基本上是只讀的，除了記憶體目錄（可以在每個主機上分開）
- 沒有第三方訪問站點文件（即不共享）
- 每個站點每月僅獲得 2-10k 次點擊
目標/要求：
- 對因維護或由於錯誤而離線的任何單個伺服器具有彈性
- 定期進行少量文件更新的一些集中方式（手動，只是正常的站點更新），最好是通過 FTP
- 最多 5 秒內將更改傳播到前端伺服器是可以接受的
- 如果伺服器意外離線，我會很高興失去長達 10 分鐘的文件更改
- 在這個階段，我們可能只會查看 2 個全職執行的前端伺服器，以及一個文件伺服器
- 可能會在 AWS 上實施
- 可能會定期添加和刪除更多前端伺服器
我意識到一種典型的方法是通過版本控制進行部署，這在某些情況下我們已經這樣做了，但是我們的員工（非開發人員，主要管理橫幅、文本更新等）非常習慣於“FTP”工作流程，我想改革，但也許還沒有。
以下是我提出的解決方案：
rsync 部署
文件伺服器託管站點文件的“主”副本，可以通過 FTP 訪問並通過 rsync 伺服器公開這些文件。我有某種“部署”界面，它觸發每個前端伺服器 rsync 一個站點並“部署它”。
優點
- 很簡單
- 允許文件伺服器上的“暫存”版本可能有用
- 每個前端伺服器都有自己的文件副本，如果文件伺服器離線也沒問題
缺點
- 有多可靠？
- 可能會混淆已部署和未部署的內容
NFS
具有本地記憶體的 NFS 文件伺服器，定期 rsync 本地備份，然後可能通過將綁定的掛載點切換到本地備份來進行故障轉移。
優點
- 可能支持寫作（沒必要）
- NFS 在某些方面更簡單
- 除非發生中斷，否則它們應該始終保持同步
缺點
- 我不確定本地 NFS 記憶體的效果如何，以及它是否會自動使修改對象的記憶體失效。沒有本地記憶體 NFS 很慢？
- 我很確定我需要某種心跳來觸發故障轉移，並在它重新聯機時掛載主控
格魯斯特等
我對這個選項不是很熟悉，但我相信當你有大量伺服器時這是一種常見的方法。我查看了一些文件，它可能是合適的，但我沒有看到很多人在這麼小的範圍內推薦它。
優點
- 允許讀寫
- 支持記憶體我認為應該比非記憶體 NFS 更快？
- 自動複製、恢復和故障轉移
缺點
- 我喜歡擁有一個可以快照和備份的“主”卷的想法，我認為沒有選項可以在 gluster 中說“這個節點必須有一個完整的副本”？
- 使用如此小的伺服器池，您似乎很容易意外終止兩個恰好擁有某些數據的唯一副本的伺服器
所以，我的問題：
- NFS 真的是我唯一的選擇嗎？
- 我應該考慮其他選擇嗎？
- 這些選項是否最適合我的需求？
編輯：
感謝你們的回复，我開始意識到考慮到我的需求規模（相對較小），我讓事情變得過於復雜。我認為在我的實例中正確的解決方案是我需要引入一個顯式的“部署”事件，該事件會觸發本地文件的更新，來自版本控製或其他來源的乙太。
儘管文件會定期更新，但當分佈在大約 200 個站點上時，現實情況是大多數站點不太可能每月更新一次以上，因此有一種機制可以隨時同步任何文件上的任意更改似乎是不必要的。
複雜的想法……但你可能把事情複雜化了。
想想這個。在什麼情況下您的 NFS 伺服器會“宕機”？您要防止的具體故障模式是什麼？雲託管提供商的儲存和虛擬化平台是否緩解了其中的一些問題？
為此，我是 NFS 的粉絲。請注意，這通常使用裸機儲存硬體，它可以具有足夠的內部彈性來維持正常故障。但是您正在計劃進行雲部署。
因此，我設想在您的 Web 伺服器層前面使用集群負載平衡器，由集群 NFS 儲存支持。NFS 儲存需要向Web 主機提供虛擬 IP (VIP) 。一種常見的方法是使用DRBD和Pacemaker，但還有其他選擇。
可以選擇定期同步到的備用 NFS 伺服器。
如果您失去主記憶體儲，您可以將 DNS 名稱用於您的 NFS 掛載並利用Route 53（手動或自動）更改 IP 目標。
幾個想法。我傾向於避免為 Web 解決方案使用完整的集群文件系統，但它們也可以作為選項。