分佈式儲存文件系統 - 哪一個/是否有現成的產品？
在部落格和相關新聞中到處都是Hadoop和CouchDB，什麼是真正有效的分佈式容錯儲存（引擎）。
- CouchDB 實際上並沒有內置任何分發功能，據我所知，自動分發條目甚至整個數據庫的粘合劑根本就沒有了。
- Hadoop 似乎被廣泛使用——至少它得到了很好的報導，但仍然有一個單點故障：NameNode。另外，它只能通過 FUSE 安裝，我知道 HDFS 實際上並不是 Hadoop 的主要目標
- GlusterFS確實有一個無共享的概念，但最近我讀了幾篇文章，讓我認為它不太穩定
- Lustre還存在單點故障，因為它使用專用的元數據伺服器
- Ceph似乎是首選播放器，但首頁顯示它仍處於 alpha 階段。
所以問題是哪個分佈式文件系統具有以下功能集（沒有特定順序）：
- POSIX 兼容
- 輕鬆添加/刪除節點
- 無共享概念
- 在廉價硬體（AMD Geode 或 VIA Eden 類處理器）上執行
- 內置身份驗證/授權
- 一個網路文件系統（我希望能夠在不同的主機上同時掛載它）
很高興有：
- 本地可訪問的文件：我可以使用標準本地文件系統（ext3/xfs/whatever…）將一個節點掛載到分區並仍然可以訪問這些文件
我不是在尋找託管應用程序，而是讓我能夠佔用我們每個硬體盒的 10GB 並在我們的網路中使用該儲存，並且可以輕鬆地安裝在多個主機上的東西。
我認為您將不得不放棄 POSIX 要求，很少有系統實現這一點 - 事實上，即使 NFS 也不是真的（想想鎖等）並且沒有冗餘。
任何使用同步複製的系統都會非常緩慢；任何具有非同步複製（或“最終一致性”）的系統都將違反 POSIX 規則，並且其行為不像“傳統”文件系統。
我無法與其他人交談，但您似乎對“分佈式儲存引擎”和“分佈式文件系統”感到困惑。它們不是同一種東西，它們不應該被誤認為是同一種東西，它們永遠不會是同一種東西。文件系統是一種跟踪事物在硬碟驅動器上的位置的方法。像 hadoop 這樣的儲存引擎是一種跟踪由鍵標識的數據塊的方法。從概念上講，差別不大。問題是文件系統是儲存引擎的依賴項……畢竟，它需要一種寫入塊設備的方法，不是嗎？
除此之外，我可以談談在生產環境中使用 ocfs2 作為分佈式文件系統。如果您不想要粗暴的細節，請在此行之後停止閱讀：這有點酷，但它可能意味著比您想像的更多的停機時間。
在過去的幾年裡，我們一直在生產環境中執行 ocfs2。沒關係，但是對於很多應用程序來說並不是很好。你真的應該看看你的需求並弄清楚它們是什麼——你可能會發現你有比你想像的更多的錯誤餘地。
例如，ocfs2 對集群中將要掛載分區的每台機器都有一個日誌。因此，假設您有四台 Web 機器，當您使用 mkfs.ocfs2 進行分區時，您指定總共將有六台機器給自己一些增長空間。這些日誌中的每一個都佔用空間，從而減少了可以儲存在磁碟上的數據量。現在，假設您需要擴展到七台機器。在這種情況下，您需要取下整個集群（即解除安裝所有 ocfs2 分區）並使用 tunefs.ocfs2 實用程序創建一個額外的日誌，前提是有可用空間。然後，只有這樣，您才能將第七台機器添加到集群（這要求您將文本文件分發到集群的其餘部分，除非您使用實用程序），恢復所有內容，然後在所有七台機器上安裝分區機器。
明白了嗎？它應該是高可用性，這應該意味著“始終線上”，但是在那裡你有很多停機時間……上帝禁止你為磁碟空間而擁擠。您不想看到擁擠 ocfs2 時會發生什麼。
請記住，曾經是管理 ocfs2 集群的“首選”方式的 evms 已經走上了渡渡鳥的道路，取而代之的是 clvmd 和 lvm2。（並且很好地擺脫了 evms。）此外，heartbeat 很快就會變成一個殭屍項目，有利於 openais/pacemaker 堆棧。（旁白：在為 ocfs2 進行初始集群配置時，您可以將“pcmk”指定為集群引擎，而不是心跳。不，這沒有記錄。）
對於它的價值，我們已經回到由起搏器管理的 nfs，因為與我們看到的基本停機時間相比，起搏器將 nfs 共享遷移到另一台機器時的幾秒鐘停機時間或一些丟棄的 tcp 數據包是微不足道的使用 ocfs2 時的共享儲存操作，例如添加機器。