使用 GlusterFS 和 Windows 避免 SPOFS
我們有一個用於處理功能的 GlusterFS 集群。我們希望將 Windows 集成到其中，但是在弄清楚如何避免 Samba 伺服器為 GlusterFS 卷提供服務的單點故障方面遇到了一些麻煩。
我們的文件流是這樣工作的：
- 文件由 Linux 處理節點讀取。
- 文件被處理。
- 結果（可以很小，也可以很大）在完成後被寫回 GlusterFS 卷。
- 結果可以改為寫入數據庫，或者可能包含多個不同大小的文件。
- 處理節點從隊列中取出另一個作業並轉到 1。
Gluster 很棒，因為它提供了分佈式捲以及即時複製。抗災能力不錯！我們喜歡它。
但是，由於 Windows 沒有本機 GlusterFS 客戶端，我們需要某種方式讓基於 Windows 的處理節點以類似的彈性方式與文件儲存進行互動。GlusterFS 文件指出，提供 Windows 訪問權限的方法是在已安裝的 GlusterFS 卷上設置 Samba 伺服器。這將導致這樣的文件流：
對我來說，這看起來像是一個單點故障。
一種選擇是集群 Samba，但這似乎是基於現在不穩定的程式碼，因此無法執行。
所以我正在尋找另一種方法。
關於我們拋出的數據類型的一些關鍵細節：
- 原始文件大小可以從幾 KB 到幾十 GB。
- 處理後的文件大小可以從幾 KB 到一 GB 不等。
- 某些過程，例如探勘 .zip 或 .tar 之類的存檔文件，可能會在將包含的文件導入文件儲存時導致大量進一步的寫入。
- 文件數可以達到數百萬。
此工作負載不適用於“靜態工作單元大小”Hadoop 設置。同樣，我們評估了 S3 風格的對象儲存，但發現它們缺乏。
我們的應用程序是用 Ruby 自定義編寫的，並且我們在 Windows 節點上有一個 Cygwin 環境。這可能對我們有所幫助。
我正在考慮的一個選項是在安裝了 GlusterFS 卷的伺服器集群上提供一個簡單的 HTTP 服務。由於我們使用 Gluster 所做的一切本質上都是 GET/PUT 操作，因此這似乎很容易轉移到基於 HTTP 的文件傳輸方法。將它們放在負載均衡器對後面，Windows 節點可以 HTTP PUT 到它們的小藍心內容。
我不知道如何保持 GlusterFS 的一致性。HTTP-proxy 層在處理節點報告它已完成寫入和它在 GlusterFS 卷上實際可見之間引入了足夠的延遲，我擔心後面的處理階段嘗試獲取文件不會找到它。我很確定使用
direct-io-mode=enablemount-option 會有所幫助，但我不確定這是否足夠。我還應該做些什麼來提高一致性？還是我應該完全追求另一種方法？
正如 Tom 在下面指出的，NFS 是另一種選擇。所以我做了一個測試。由於上述文件具有我們需要保留的客戶提供的名稱，並且可以使用任何語言，因此我們確實需要保留文件名。所以我用這些文件建立了一個目錄：
當我從安裝了 NFS 客戶端的 Server 2008 R2 系統中掛載它時，我得到一個如下目錄列表：
顯然，Unicode 沒有被保留。所以 NFS 不適合我。
我喜歡 GlusterFS。實際上，我喜歡 GlusterFS。只要你能給它一些專用頻寬，一切都很好。
GlusterFS 最好的事情之一就是將它與 NFS 一起使用。我最近一直在使用的令人驚訝的事情之一是Windows 7 和 2k8R2 上的 NFS。
這就是我要做的。
- 設置 2 台可以導出 NFS 的 GlusterFS 伺服器。
- 在它們之間建立一個心跳連結。
- 也許部署類似 Heartbeat/Pacemaker 的東西？
- 在 Gluster 節點之間設置虛擬 IP (VIP)。
- 使用 VIP 的 IP 地址連接 Windows boxen 的映射網路驅動器。
- 測試你能想像到的一切。
集群 Samba 聽起來很可怕，即使你這樣做了，Samba 仍然缺乏在某些 Windows 網路中可靠執行的能力（所有 NT4 域兼容性，似乎永遠無法超越）。
我認為因為每個 gluster 節點都處於分佈式複制模式，所以理論上你應該能夠連接到其中一個節點並讓它擔心移動你的數據。因此，heartbeatd 應該是執行重定向並控制您正在與之交談的對象。
至於你的
- 文件數可以達到數百萬。
我建議您研究使用 XFS 作為底層文件系統，因為它非常適合大型文件系統，並且受 GlusterFS 支持