文件系統冗餘 + 速度
尋找一些輸入，如果有人用他們有信心的解決方案克服了這個問題。
希望設置一個容錯的 Web 環境。所以設置是負載均衡器後面的幾個節點。現在 web 開發人員可以 ssh 到 1 個伺服器來編輯程式碼等。
我正在考慮 glusterfs，但將 glusterfs 文件系統作為 doc 根會導致網路伺服器可以服務的頁面減少約 20-30%。我希望這是因為我只是通過乙太網而不是 infiband 等。
所以我在考慮使用 glusterfs+inotify。因此，我執行了一個 inotify 腳本來監視 docroot 和 gluster 掛載的更改，並在該文件/目錄上執行 rsync 更改。這樣 apache 可以從本地磁碟而不是 gluster 提供服務，但它會產生通過集群文件系統提供服務的效果。
我唯一的問題是我需要執行 2 個 inotify 腳本和我們正在執行的文件計數，以添加所有我為它們使用大約 700 兆 RAM 的 inotify 觀察者。
所以有人有任何建議或指示嗎？
謝謝！
編輯
把它想像成一個虛擬主機。客戶端 ssh 進入 1 個伺服器，但他們創建/編輯/刪除的文件在所有其他節點上
反之亦然。如果網路伺服器創建文件，它們也需要在所有節點上。
因此，由於它太慢了，所以會直接拋出 rsync 。
哦，哇，我正在回憶過去的工作，在那裡 GFS 被用於你所描述的確切理由。場景：超過 2000 名客戶在多個大型雲上執行他們的應用程序。
基本上，你不能做你認為你想做的事。您無法獲得能夠以接近本地文件系統的速度執行的集群或網路文件系統。讓我強調一下：不能。如果你認為你可以，那你就是在自欺欺人。如果別人說他們可以，那他們就是在撒謊。很簡單的數學運算：磁碟速度 + 控制器 IO + 網路延遲 + 集群 fu必須大於磁碟速度 + 控制器 IO。
現在，歸結為您可能建構它的原因，以及為什麼您想做的事情是無用的：
- 部署的簡單性：部署到一台機器並讓它在任何地方自動執行並不簡單，因為 - 明白這一點 -它不是您要部署到的一台機器。當然，您可能認為只需要複製一個程式碼實例很方便，但是在各種情況下您需要為每個應用伺服器做很多事情。在我個人不得不處理的許多情況下，安裝到共享文件系統上最終會使部署過程變得比原本要復雜的多。“如何部署到多台機器”這個問題的正確答案是“自動部署”。
- 可靠性集群：這對我來說簡直是個笑話。現代硬體如此可靠，而集群技術如此不可靠，以至於集群（尤其是集群文件系統）會增加您的停機時間。我有足夠的數據來撰寫關於該主題的白皮書。現在，有些人會說“我的 EMC SAN 已經執行了四年而沒有出現生產中斷”，但他們為這種可靠性付出了多少？我從未聽說有人以不到 7 位數的價格（以 TCO 為基礎）獲得這種可靠性，而且其中也有大量的專業知識成本。你問這個問題的事實表明你沒有那種專業知識，我敢打賭你也不打算把 7 個數字記下來。
- 容量集群：這可以追溯到我的開場白——任何類型的集群文件系統都比本地文件系統慢。試圖從集群或網路文件系統中提取大量性能是一個失敗的原因。它會讓你發瘋（它肯定對我有用）。
既然我一直是一個螢幕的消極者，你能做什麼？好吧，它基本上歸結為在個性化層面上幫助您的客戶。
您無法建構千篇一律的千篇一律的無限規模託管基礎設施。這就是我熱愛 GFS 的前雇主試圖做的事情，但當時並沒有成功，我相信目前可用的開發和運營技術無法做到這一點。
相反，花點時間評估客戶的要求並幫助他們找到滿足他們要求的解決方案。您不必對每個客戶都進行全面分析；在最初的幾個之後，您將（希望）開始看到出現的模式，這將引導您走向一系列“標準”解決方案。它變成“好的，你有 F、P 和 Aleph-1 的要求，所以你最好使用解決方案 ZZ-23-plural-Z-alpha - 這是我們關於部署這個解決方案的綜合文件集，如果您自己無法實施，我們對這個解決方案的定制諮詢價格最低”。
就細節而言，有太多無法列出，但我會給你一些提示：
- 將程式碼分別部署到每個應用伺服器。
- 如果您真的必須共享動態資產，請使用 NFS。它非常簡單，並且破損率最低。請注意，我說的是共享資產——不是程式碼，不是配置，不是日誌，只是客戶提供的資產。
- NFS 不會永遠擴展（儘管有 NetApp 宣傳）；在某些時候，您的客戶將需要遷移到其他東西（我之前給出的一個範例），您可以通過良好的文件和其他現成的幫助幫助他們遷移到更具可擴展性的解決方案。
- 如果您認為這可能是一勞永逸的業務，那您就錯了。您擁有商品虛擬主機（具有所有優點 - 維護成本低 - 和缺點 - 沒有利潤 - 這意味著），以及專門的虛擬主機（這是您想要做的），後者維護成本高（但利潤率也相應高）。