我有一台伺服器，它透過以下方式將包含約 700 萬個檔案（主要是映像）的目錄從本機磁碟匯出到網路用戶端網路檔案系統。
為了 HA，我需要添加第二個，並使其與第一個保持同步，兩者之間的增量盡可能小。
研究建議使用同步或其他inotify基於此的解決方案，但考慮到創建的文件數量inotify手錶需要永恆。同樣的事情同步。
其他可能的解決方案似乎是資料資料庫，或簇檔案系統例如頭孢或者格魯斯特檔案系統，但我對這些沒有經驗，不知道哪一個更合適，可以很好地處理那麼多文件，並且仍然提供不錯的性能。
請注意，該活動主要是讀取，很少發生寫入。
答案1
我傾向於建議與數據無關的複製，例如 drbd。大量的文件將導致在比「區塊儲存」更高層級上運行的任何內容花費過多的時間遍歷樹 - 正如您使用 rsync 或創建 inotify 監視所發現的那樣。
我個人故事的簡短版本支持了這一點：我沒有使用過 Ceph，但我很確定這不是他們的主要市場目標，因為它與 Gluster 相似。然而，過去幾年我一直在嘗試使用 Gluster 來實現這種解決方案。雖然有幾個主要版本更新，但它大部分時間都在運行，但我遇到了無窮無盡的問題。如果您的目標是更多的冗餘而不是效能，Gluster 可能不是一個好的解決方案。特別是如果您的使用模式有大量 stat() 調用，Gluster 在複製方面表現不佳。這是因為對複製磁碟區的 stat 呼叫會傳送到所有複製節點（實際上是“區塊”，但每個主機可能只會有一個區塊）。例如，如果您有一個雙向副本，則來自客戶端的每個 stat() 都會等待兩個區塊的回應，以確保它使用當前資料。如果您使用本機gluster 檔案系統來實現冗餘（而不是使用Gluster 作為後端，以NFS 作為協定和自動掛載器來實現冗餘，但由於stat() 原因，這仍然很糟糕），那麼您也會有FUSE 開銷和缺乏快取的情況。不過，Gluster 非常適合處理大型文件，您可以將資料分佈在多個伺服器上；資料條帶化和分佈效果很好，因為這就是它的真正用途。較新的 RAID10 類型複製的效能優於較舊的直接複製磁碟區。但是，根據我對您的使用模型的猜測，我建議不要這樣做。
請記住，您可能必須找到一種方法在機器之間進行主選舉，或實現分散式鎖定。共享區塊設備解決方案需要一個支援多主設備的檔案系統（如 GFS），或者需要只有一個節點以讀寫方式掛載該檔案系統。檔案系統通常不喜歡在其下面的區塊設備層級更改資料。這意味著您的客戶端需要能夠辨別哪個是主伺服器，並在那裡直接發出寫入請求。這可能會成為一個很大的麻煩。如果可以選擇 GFS 及其所有支援基礎設施，則多主模式下的 drbd（他們稱之為「雙主」）可以很好地工作。 https://www.drbd.org/en/doc/users-guide-83/s-dual-primary-mode了解更多相關資訊。
無論您選擇哪個方向，您都可能會發現，如果不給 SAN 公司大量資金，即時實現這仍然是一個相當大的痛苦。
答案2
在 Proxmox VE 設定的幫助下，我已從 rsync 轉向 ceph。
現在，我透過即時複製在一個叢集中管理 14TB。近4年了。