在水平擴展的 Web 伺服器之間共享文件上傳目錄的最佳方式
我目前正在嘗試為基於 drupal 的 Web 應用程序指定一個水平可擴展的集群，它看起來像下面的彩色圖表：
負載均衡器實現了粘性會話，因此一旦為使用者分配了要使用的伺服器，他們就會保持狀態。
每個應用伺服器都有以下內容：
- 在前面清漆
- 中間的drupal 6在燈棧上執行
- 記憶體記憶體在後面
兩台 mysql 數據庫伺服器在一個共享 IP 上，並且它們在一個帶有 DRBD 和 heartbeat 的 HA 集群中，因此失去一台不會導致整個平台癱瘓。
有幾件事我不確定，我會感謝您的意見：
文件儲存應該如何橫向擴展？
我正在考慮使用 NFS 在每個應用程序伺服器上掛載共享文件目錄，因此在一次上傳的文件在所有應用程序伺服器上都可用。我正在考慮 NFS，因為它已經存在很長時間了，而且我沒有使用 MogileFS 或 GlusterFS 的經驗，而且它是我們以前使用過的東西，所以我們更熟悉它。
是否有任何指導方針可用於計算以這種方式通過 NFS 共享目錄的明智的伺服器數量？
這裡的共享文件儲存應該如何提供HA？
這裡的一個問題是 NFS 伺服器是單點故障。
我們已經在 Mysql 伺服器上使用了 Heartbeat 和 DRBD，我希望盡可能減少堆棧中涉及的技術數量——如果我對文件使用相同的 HA 策略會有什麼陷阱伺服器也是？
另一種方法
這適用於面向內部的站點，當內部計劃啟動時，少數使用者偶爾會在短時間內非常密集地使用該站點。所以這不需要像某些初創公司那樣無限擴展。
鑑於
- 我們可以預期的流量有上限
- 向文件伺服器添加 HA，並設計一個像這樣水平擴展的設置會引入相當大的複雜性
我還在考慮讓兩個 Web 伺服器更強大，以便它們能夠處理它們之間的峰值負載，並在 cron 作業中在兩者之間設置一致或 rsync，以便：
- 他們的文件仍然同步（粘性會話將使用者保持在他們將文件上傳到的同一台伺服器上）
- 失去一個意味著該站點仍在執行。
這聽起來像是解決任何可能的 NFS/DRBD HA 複雜性問題的可行方法嗎？
謝謝，
C
NFS 伺服器至少必須具有與 MySQL 伺服器相同的配置，因為它們具有基本相同的功能和限制（兩者都是您寫入數據的地方）。我不喜歡 NFS 的多個寫入者的想法，這使得管理文件鎖變得非常複雜，而且我的經驗在這一點上並不順利。
我的建議是將所有寫入集中在一個應用程序伺服器上（可能有一個應用程序伺服器專門用於在 NFS 伺服器上寫入）和多個讀取器應用程序伺服器以只讀方式安裝它（我知道 drupal 有一些動態縮略圖需要可以寫，但您可以將大部分內容保留在 RO fs 上）。您將至少需要第二台 NFS 伺服器（如果您沒有像 SAN 這樣的共享儲存，則使用 DRBD 是最好的選擇）以確保 HA。
最後，看看 Gluster 和其他分佈式系統。